Spring Anti-Patterns, Pt. 1

This here's real talk: Spring is a direct attack on the J2EE platform. That's a good thing as far as I am concerned. So this post is written not with hatred, but with love. 

A typical stack of technologies used in small scale Java web development shops is the following: 

• JPA
• Spring
• Some MVC web framework like Struts, Spring MVC or Wicket.

JPA allows easy ORM without XML configuration through its wide selection of annotations. Spring makes it all work by configuring the MVC framework, Data Sources and the JPA Entity Manager, among other things.

The problem though, is the way Spring documentation is worded, it pushes the wrong approach for many web application engineers. I am looking at you LocalContainerEntityManagerFactoryBean! According to the Spring docs, this is the "most powerful" way to configure an Entity Manager. My reaction: O Rly?

The issue is that such an Entity Manager necessitates the use of application level transactions. Most people read the Spring documentation and say: "Hmmm, do I need transactions in my code? Eh, sure why not." That's is the wrong assumption. Very few of the service layer calls in typical, small-scale web applications actually need application level transaction support, because they mostly are atomic operations (insert, update, delete, select). 

This is actually one of the chief reasons the J2EE platform has not been as successfull in small scale agile environments: their obsessive focus on transaction support, and specifically, distributed transaction support. This focus resulted in the notoriously slow EJB standard. Spring solves much of the complexity of J2EE. As part of their attack strategy, they market their product as a non-invasive alternative, but engineer it to be a full replacement. An engineer reading "most powerful" in the docs will use that Bean instead of the much better suited for small apps LocalEntityManagerFactoryBean. Unfortunately, that bean type cannot be configured with different data sources, prompting even more people to use the Local Container Entity Manager Bean.

The point is, you do not lose database transaction support if you go with the LocalEntityManagerFactoryBean. Why? Because they are not provided by Spring, they are provided by your database server. You can still .begin() and .commit() as well as .rollback() transactions through your JPA Entity Manager's getTransaction() method. This means you can add transaction support for a small subset of your service layer database calls, and everyone's a winner!

A Small Note

Hi.

May I have your attention, please. Thank you. PLEASE FEEL FREE TO COMMENT on these blog entries. I would like there to be more discussion rather than just me blabbing.

That's not to say theres anything worthwhile to comment on :) but just wanted to throw that out there.

<paranoia>Also, keep in mind this is public so don't put too much personal info about yourself (or others (or me)) in your comments.</paranoia>

You may now resume your brainless web surfing, Thank you!

- Null, Author

Secret Project Revealed!

First, before we start, a koan:

"When a tree falls in the forest, and there is no one around to hear it, does it make a sound?"

Let us reword that for relevance:

"If a game software development project is secret, but no one cares, is it still a secret?"

Answer: Buddhists, get out. Of course trees make a sound when they fall alone and of course an obscure project can be secret. But no longer! (the secret part, not the sound part)

For the past several weeks, I have been (secretly!) engaged in creating what I present to you now, in unfinished form. The project is tentatively called "Trista," which means "Three Hundred" in some obscure Slavic language. This game is still in early stages of development, but there is a build, and it is up and running. Some posts below feature content preview screenshots. This is stuff I am working on and will appear differently within the game, but it gives a good idea of what to expect visually.

As far as what to expect otherwise, I will describe the ideas in the near future right here. Next up: Game Space Concept. For now, here is a screen shot:

Preview Part 2

Sun Tzu Said:
Regard your soldiers as your children, and they will follow you into the deepest valleys; look on them as your own beloved sons, and they will stand by you even unto death.

Lazier DDL with Spring's HibernateJpaVendorAdapter

Ok, so let's get one thing straight. I am an extremely lazy guy. And no, I am not talking about only loading collections of my friends after someone tries to access them directly. No.

I am talking about procrastination.

At my levels (software engineering) it is an art form. For example, today I had to write some SQL code - code that creates a new table in a database. Here's how I did it:

1. Create a new class, and annotate it with @Entity (javax.persistence.Entity)
2. Add fields. As many as you want.
3. Use IDE to generate getters and setters for those fields.
4. You're already using HibernateJpaVendorAdapter. You're not???! Beat it, man. Ok now just call the method .setGenerateDdl(true) on it.
5. The eeeennnnnd.

Well, that took 30 seconds!

A Bit of a Preview

So, check this out:

My own creation. Stay tuned, eheheh.

Oh woe is us Java fossils

This is a nice tour de force of technology. It definitely extended my mental picture of what Javascript is capable of. Well, rather, Javascript and smart guys with too much [free|corporate guerrilla marketing] time. Coupled with others, looks like the browser is really going to be an application delivery system after all. 

Yay so happy?

No, not really. Kids these days, with their dynamically typed, object oriented, closure supporting languages. Why back in my day, I had to.... hm. Actually, my day sucked, so I take it back.

Yay so happy!

Ubuntu 9.04 Jaunty OpenAL and how it almost ruined Puzzle Pirates

I'm going to be upfront about this. I play Puzzle Pirates. Now you know why this blog is anonymous.

One interesting thing about the game is that it uses LWJGL for its Linux implementation, something I consider an important fact.

A while ago I grabbed Puzzle Pirates, and it worked immediately (on Linux!). Except for sound. Sound is not a big deal in that game, but it kept eating away at me. A couple of days spent posting on the Puzzle Pirates boards netted me the location of the game's log file. Then my mind pieced it all together.

LWJGL uses OpenAL for sound! So the whole setup goes something like Puzzle Pirates -> LWJGL -> OpenAL -> Operating system sound system (ALSA or in my case pulse audio).

My bundled OpenAL drivers were 32 bit, NOT 64 bit. I am running the 64 bit version of Jaunty. So I pulled up the Synaptic Package Manager application, and did a search for OpenAl (libopenal), installed the package, and lo and behold sound was working.

Every single application that uses LWJGL potentially won't work, I hope Canonical does a better job packaging in the future.

Moo 2 Under Ubuntu 9.04 Jaunty with Wine

There is an option in wine that enables you to run moo2 (the orion95.exe ) from linux. It is the "Emulate Desktop Environment" option. Couple of problems I ran into though - if you choose a resolution other than 800x600, wine seems to grab the entire desktop. Also a post I read claims there are issues with other programs running under wine with that option.

Silicoids!