A rant on Java standards

So, I like a Java as a language and I like the whole Virtual Machine thingy. I even dare to say that I like building web apps in Java! Now, everything has limits and JEE sometimes pushes mines just a bit too far.

The thing is Java is growing too much in too many areas. Many people have already started to complain about the number of features (and idioms) in the language itself, probably because Java 7 will bring in some more. I have to say that I was not joining that bandwagon (and I still wait with eagerness the closures support) but I've spent my last three months fighting (there's no better word!) some Enterpise Edition specifications and I'm fed up.

Just take a look at the Java Community Process to get an idea of what is Java today. To me the problem is not the number of technologies or the number of specifications. Nor the fact that Java tries to compete in every possible market niche. I don't mind. The problem is the integration between them! Specially when you group them together and call it a platform.

How can something like JSF be promoted to be the standard? A component framework that lacks even one interesting component! That relies on third party libraries (many OSS) that are, of course, incompatible between them. Each one with a different AJAX approach (as the specification says nothing on the topic). And, worst of all, incompatible with JSP/JSTL and portlet development.

So, if even the Spring people can't get WebFlow to work properly in a JSF + Portlet environment how are we supposed to do so? Do you know that you need to configure JSF RI(or MyFaces) + Facelets(or JSF Templating) + Richfaces(or IceFaces, Tomahawk, WoodStock) + Portlet Bridge(JSR-301 is in draft yet!) + JBOSS EL(you want method invocations right?) just to start developing a page? Can you guess the number of IDEs that support that kind of configuration? Or the number of context-params in web.xml descriptor? Let me assure you something, your first try won't work. Nor the second. From there it will depend if you are mixing something more like say...Spring or, God forbid, WebSphere Portal (or even other EE technologies like JAX-WS or JPA). Can you imagine trying to explain all the gotchas (nightmares actually) to a junior developer???? Or the client????

I'm amazed that some people still have hard times determining why the adoption rate of EJB 3 is still so low (I'm stupidly optimistic and I still have hopes for EJB 3.1...and, yes, JSF 2.0) but I just know that a client side JS framework (choose your destiny!) paired with DWR and a Spring centric backend just happen to work (in a fraction of the time).

DWR 3.0 conversion features

So DWR 3 is slated for late September around the Ajax Experience conference (tentative dates, of course) and it's loaded with new features. I've already talked about some of them (like Spring) but right now there's a lot of work being done with converters so I'd like to share some of it a little.

Before, of course, a little explanation to inform clueless people. A converter in DWR is an object that transforms Java to Javascript and vice versa. This is usually transparent to the user as DWR out-of-the-box includes converters for primitive types, arrays, collections, beans and more. Of course, for security reasons not all of these converters are enabled by default and some require a specific declaration (like bean or exception). The conversion procedure is composed of two stages, the inbound conversion that transforms method arguments from JS (using a internal protocol named DWRP) and the outbound conversion of the response (or the method return type).

Advanced users know the use of class mappings as well. These serve two purposes, first they allow a Java to JS object correspondence and (internally) they also add runtime information to each call.

We can look now into the new features 3.0 offers. But first remember (a little disclaimer) that they are currently under heavy work so many are not yet ready but in the working copies of the developers boxes. No more delays, here they are:

• New converters
  An obvious one, more out-of-the-box converters mean less work for each developer. The interest relies in the functionality though. These ones allow file and image transfers using AJAX calls. That is, uploads and downloads using asynchronous calls and progress listeners.
• Dot syntax support
  To date JS objects mapped just the name of the Java class but omitted the package. This has been enhanced to support the fully qualified name. An example that shows hierarchies as well:
  
  
  var baz = new foo.bar.BazImpl
  ...
  if (baz instanceof foo.bar.Baz) {..}
  
  
• Classpath scanning
  Before now, each converter required its own declaration. From now on the match clause accepts wildcards to define converters in batch during boot time. They syntax is pretty clear match="foo.*" will locate any class under the foo package while match="foo.bar.**" will, in addition, recurse subfolders.
• Javascript wildcard expansion
  In the same manner as the previous point the javascript attribute of a converter will allow wildcards (both * and **) that will be expanded to the corresponding class name. Thus, * will map to the matched class simple name while ** will be mapped to the fully qualified named (thanks to the dot syntax support). Expect definitions like:
  
  
  <converter type="bean" match="model.**" javascript="foo.bar.*" />
  
  to remote all the classes under the model package (including subpackages) under the JS identifier of foo.bar.<SimpleClassName>.
• Method overloading
  Till today, DWR just politely asked the developer not to overload methods (on the server side). New enhancements in the inbound conversion process allows better identification of the target method and thus overloading.
• Var args support
  3.0 will offer support for Java varargs using JS arrays as the last parameter of a method.
• Interfaces as method parameters
  It will be possible to declare method signatures that include interfaces (or abstract classes) as long as there is at least one converter declared that implements the contract and runtime type information is delivered with the request (class mappings are mandatory). This is an example of why the library prefers DWRP over JSON to transfer data.
• Separated class mappings
  Class mappings are currently defined in every interface file. This leads to duplication and overall worse performance. Next version maintains this behavior for compatibility reasons but adds the possibility to generate class mappings gropued in a external file (to be used with JAWR for example) or just one per file
• Improved serialization
  Next version will detect and avoid the serialization of JS properties that are not mapped in the Java counterpart.
• Constructor injection
  JS classes will be instantiated from a map in addition to the usual setter injection.

And there are some more (like property overriding in conversion) but they may not be ready for 3.0 and will have to wait until the following release.

Technical Reading

August is a good month to practice some reading, even more so if, as is my case, you have to stay at work. Between novels and Terry Pratchet I always try to drop in a technical book or two. This summer I finally had the time for two that had been sitting on my TODO list for ages: Java Puzzlers and Effective Java (2nd ed). Both from Joshua Bloch, one of the fathers of Java.

Java Puzzlers is a book that deals (as the name implies) with traps, pitfalls and corner cases. And good practices! An example can clarify things. Look at the following code snippet (taken from puzzle #1):

public boolean isOdd(int i) {
   return i % 2 == 1;
}

A quick glance reveals a standard use of the modulus to determine if a number is even or odd. Can you spot the problem? I didn't really. In fact, the code does not work for negative odd numbers or rephrased it the method fails in a 25% of the situations. You can test it (I recommend using the Groovy console for testing quick scripts like this). A correct version would look like:

public static boolean isOdd(int i) {
   return i % 2 != 0;
}

The author explains concisely why it fails even proposes a better (faster) version (using the logical AND operator). The book is made of nearly one hundred puzzles grouped in ten chapters covering operators, casting, exceptions, loops, classes et al. The cases are sometimes very convoluted and well beyond the scope of day to day coding but are also important to know. If anything, the book will just make the reader aware of the importance of unit testing and code coverage (although it doesn't mention them explicitly). Even one liners like the above must be matched by a test.

Effective Java is a book on advanced Java programming. You may think that I (or you) don't need a book on the topic any longer. In the end, we are expert coders! Great! Read the book and tell me :-) IMHO this is the definitive Java guide. I was impressed (and probably you will be also) by the depth of the knowledge showed in every chapter. Even those that deal with commodity topics (and this is subjective) like exceptions or some Java 5 features. There's a sample chapter (generics) available for free reading here. You get the idea. Now imagine equal dissertations over Serializable, Concurrency, Composition or Performance. I bet most people don't know the subtleties of the static reserved word and how it interacts with several other language features like, say, private inner classes. If you want to go to that level of depth this is your book.

All in all, I liked both books, though the second is way more useful. Probably they're not as easy to read as something like The Mythical Man-Month or The Pragmatic Programmer but they also offer an understanding of the Java language that you won't get in any other place. So...highly recommended lecture!!

Joining the FishCAT program

I've been invited by the Glassfish team to join FishCAT, the GlassFish Community Acceptance Testing program. The main goal there will be to test in depth the new modular version of Glassfish 3, called Prelude.

As a long standing Glassfish user (I have to admit I joined the community with the first v2 betas) I'm quite happy to be of help. I'll be testing thoroughly the Web Tier (JEE5, AJAX), part of the business tier (at least JPA), the Netbeans plug-in and Groovy. Of course, that's a lot of work but I'll try to touch everything.

The program is scheduled from August to September 2008 (about four weeks) and it's open to everybody, just need to fulfill a simple registration form. I encourage everybody interested (probably all Netbeans/Glassfish users) to take the step and join the effort. Glassfish 3 looks promising and here's your chance to contribute!