Choice is not the problem with Java

Much has been said recently in the Java world about the problems with Java, particularly the problem with choice.

In Java Succumbing to .NET in my Organization Neil Chaudhuri says that there are two many frameworks, too many IDEs, too many app servers etc. and that is why his organization is moving to .NET. According to Neil choice is a bad thing.

His answer, at least to the IDE "problem", is more standardization, but I believe the source of the standard must come from something that already works, a de-facto standard not a committee standard.

The problem with Java is not choice, but rather that the early standards were created by committee and Sun's "Not invented here" mentality.

Take, for example, EJB.

EJB 1.0/.1 was a fairly pitiful effort. Just horrid, like they gave the job of designing it to an intern. All sorts of (anti-)patterns were born out of 1.1.

EJB 2.0 is a classic example of something born from committee. It mostly did what you wanted to do, but the extra 10% was hard and messy. It promised so much, yet did not deliver and people turned to alternate persistence mechanisms such as Hibernate.

Now with EJB 3.0, Sun has done the right thing; taken something (Hibernate) that works, that people like and makes them productive and turned it into a standard. Yet, they still try to re-invent the wheel with respect to Dependency Injection.

Another example of this is JSF. They formed a committee to define a new web framework, cocked it up and now are already up to 1.2 of the specification. (It probably didn't help that they had the creator of the worst web framework of all, Struts, on the committee).
Why couldn't they have taken something like Tapestry and made it a standard ?

The underlying problem is that Sun have had a real "Not invented here" mentality. They realised a while ago that they couldn't implement anything that was usable (e.g. AWT, then early Swing) so that they started going specification mad. Yet they failed to realise that writing specifications is really hard, harder in fact than writing an implementation.

What should they have been doing all along ? Adopting open-source projects that are de-facto standards and making them into official standards.

----------
Objectopia.org

Google Web Toolkit Angst

I've been using Google Web Toolkit for the last week or so. I'm really liking it, it is really productive and once you getting it working everything is sweet.

The problem is, getting it working is kinda hard, particularly if you want to use Eclipse. I struggled for a day or so to create my own project from scratch but gave up and just copied the DynaTable example and changed a few things. All this is because GWT has these unwritten conventions for stuff that is almost impossible to figure out without days of trial and error.

GWT tries to be all Rails like with "Convention over configuration", which is fine, if you can find out what the convention is.

Another thing that is annoying is the self-righteousness of the tools :

c:\dev\gwt-windows-1.0.20>junitCreator -junit c:\dev\eclipse\plugins\org.junit_3.8.1\junit.jar -eclipse project -out c:\dev\workspace\project com.xyz.project.DataImportViewTest 'com.xyz.project.DataImportViewTest': Please use 'test' as the final package, as in 'com.example.foo.test.MyTest'. It isn't technically necessary, but this tool enforces the best practice.
Google Web Toolkit 1.0.20

Whose best practice are they referring to? I hate the term "Best Practice" - it implies that the currently accepted best way of doing something is the final say on the topic, so don't even bother trying to think of something better. It is arrogant and is like saying "trust us, we are bigger and better than you, go away and leave the real thinking to us".

Anyway, I had thought that this ".test" package style had gone out of favour a long time ago, but it doesn't matter really whether it is best practice or not, what is with the arbitrary conventions ?

I'm sure (and hope) , over time Google will listen to the criticism and make GWT better. It is very good at the moment, but I think it is probably only about 95% there. Another 5% with Maven, Eclipse integration and more configuration options (with sensible defaults ) will truly make it rock !


----------
Objectopia.org

Back into AspectJ

I'm getting back into using AspectJ after a long hiatus. AJDT was pretty dodgy at one point so I had to stop using it and without proper IDE support, doing stuff AspectJ is fiddly because I like to get feedback on what exactly is being advised.

As Howard Lewis Ship has noted, AJDT seems to work mostly except that occasionally the "advises" arrow don't reflect what is actually be advised (tends to say that a pointcut isn't being matched when it is). Like HLS says, a fuild rebuild will usually fix this but this can get a little irritating after a while. I also get the disappearing aspect thingy happening. All these things seem to stem from the AJDT plugin not AspectJ itself. Its getting much better from what it was, I'd say it is in the high 90% complete whearas, late 2005 I guess it was somewhere in the 80%-90% mark.

I'm always of the opinion that if an open source project has problems, you should never whinge about it, rather find something better or make some sort of contribution so that it can get to where it is useable for you, even if this just means filing a bug report. If you've got the skills then supplying a patch is a lot better. You can't have your cake and eat it: you're getting something for free, don't expect the developers priorities to be the same as yours.

Anyway, I'm pleased where AJDT has gotton to. It works (most of the time) and doesn't give throw random NullPointerExceptions everytime you want to do a build. It also seems reasonably snappy on my PowerBook now.

----------
Objectopia.org