FactoryFactories

Something somewhere went terribly wrong and we ended up with APIs like this.

http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html

The default RequestProcessorFactoryFactory is the RequestProcessorFactoryFactory.RequestSpecificProcessorFactoryFactory. It creates a new processor instance for any request. In other words, it allows the request processor to have some state. This is fine, if the request processor is a lightweight object or needs request specific initialization. In this case, the actual request processor is created and invoked when calling RequestProcessorFactoryFactory.RequestProcessorFactory.getRequestProcessor(XmlRpcRequest).

The really sad part is that in the Java world this specific example cannot be considered that extreme any more.

FactoryFactories indeed.

Eclipse TPTP is a waste of time

I wasted many hours of my precious weekend to get the Eclipse TPTP Profiler to work. My scenario was a simple standalone Java application.

Conclusion: it's not worth it, trying TFTP to work is an extremely frustrating experience. My life's too short for this kind of thing and I'm not the only one.

The Java closures controversy

Although I didn't have time yet to study all the alternatives in detail, I've read a few blog posts and watched the video of Joshua Bloch's presentation at Javapolis about the BGGA Closures proposal.

I tend to agree with him. Rushing into a closures implementation and adding yet more complexity to Java is a great chance for the Java community to shoot itself in the foot and turning Java into another C++. In my opinion one strength of Java has always been the ability to say no to new features until there was a convincing solution.

Dalvik: Google's workaround for Sun's JVM

Mobile programming suddenly got a lot more interesting

Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME

Dalvik is a virtual machine, just like Java's or .NET's.. but it's Google's own and they're making it open source without having to ask permission to anyone (well, for now, in the future expect a shit-load of IP-related lawsuits on this, especially since Sun and Microsoft signed a cross-IP licensing agreement on exactly such virtual machines technologies years ago... but don't forget IBM who has been writing emulation code for mainframes since the beginning of time).

The Android SDK does not compile your Java source code into Dalvik's bytecode directly, but it first uses a regular java compiler to generate regular java bytecode (say, javac or the built-in Eclipse compiler) and then converts that bytecode into Dalvik's bytecode (the "dx" tool does this: convers .class/.jar into .dex files).

[...]

there is no need to ship a java virtual machine on your Android-powered phone and you can use your regular Java standard edition to develop your phone application (means, you don't need to use Java ME anywhere at all).

Passed the SCJP exam

Many years ago I wanted to get an SCJP exam, but changed jobs before I could take it and later forgot about it somehow. Last month I decided that I'd take care of this unfinished business.

It took me a bit less than 2 weeks to prepare spending about 1 hour a day on average reading the book and solving example questions.

The exam is not hard if you have a lot of Java experience (I started developing in Java back in 1997 with JDK and 1.0 and Applets...) but it does have a few trick questions. The format is typically: what does this program print, but since "compilation fails" and "an Exception is thrown at Runtime" are almost always among the possible choices you have to look at the code carefully.

Some of the things I learned during the preparation are pretty much useless, like watching out for silly mistakes that modern IDEs, such as Eclipse catch for you immediately as you type the code.

Other questions test your knowledge of corner cases in the language that I've never encountered in my many years of coding, such as whether catch (Exception e) will catch AssertionError or whether this abomination compiles:

long[][] a[] = new long[3][][];

(It does.)

So now I'm certified (I got 90%) and know much more about the java.util.Scanner class than I'll ever need to. :)

The 30 Days IDE Swap Experiment (NetBeans / Eclipse)

I just found this interesting experiment in the JavaTools Community Newsletter. Developers are asked to switch IDE's (NetBeans/Eclipse) for 30 days. It's interesting to see what they said in the Q/A section (the rest I skipped).

To me the take away message is that when I need to do Swing / JSF work it's going to be worth looking into NetBeans.

For me, the evolution of my Java development environment of choice over the years was: vim -> XEmacs -> NetBeans (for Swing) -> Eclipse.

What I like most about Eclipse are the refactorings and the "quickfixes" (suggestions for fixing the code) and the cool code navigation features. Another big part of the Eclipse experience is that I can just start typing code without thinking about details, such as imports, field or superclass declarations, keep hitting Ctrl-1 and the IDE does all the busywork. Oh yeah, and the integrated JUnit support is also very nice.

Recently I had the misfortune of working on a C++ project in Visual Studio for a while and the pain was almost unbearable every time I had to go through a save / compile / link cycle to catch silly mistakes. Things that are instant in Eclipse took minutes.

OpenJDK: Java has been open sourced

A couple of years late, but it's finally here*.

* Well, only javac and the HotSpot virtual machine for now, the rest is hopefully coming soon.

I wonder what the patent situation for the full Java stack really is and if it is any less alarming and confusing then with .NET and Mono.

• InfoQ: Sun open sources Java SE, ME, and Glassfish under GPLv2
• eWeek: Sun Pours Out Java Cup