Category: Coding

I just had a read of this article over at OnJava.com, rounding up the most popular articles of 2005 published on that site. In a nutshell, the popular subject areas seem to be mainly Hibernate/EJB 3.0, Spring, Ajax, Eclipse, and Ruby-On-Rails/Python/whatever. After reading the article, I decided to round up my personal technological high points of 2005:

• Finally getting to use Java 5. For the last year or so, I’ve been working on real-life projects based on a Java 5 platform inside two large banks. The general technology stack has been Spring, Hibernate 3.0 (plus Hibernate annotations), Java 5, and Tomcat 5.5. The experience has been positive and enjoyable. For starters, you get a performance boost “for free” by switching to JDK 5.0 and Tomcat 5.5. Once you get used to them, annotations feel like a natural way to define Hibernate persistence mappings. And the various bits and pieces of syntactic sugar in JDK 5.0 (such as the enhanced for loop and generics) are a definite plus.
• Hibernate 3.0. I’ve always liked Hibernate, but one aspect of Hibernate that I have never taken to is that it has always been a framework that enforced an “ivory tower” view of how things should be done, and made it difficult for anyone to make it work any other way. One example is how Hibernate traditionally did not support mapping a single persistent entity to multiple tables, because the prevailing view was that this was a bad example of data modelling. In Hibernate 3.0, this has been rectified (although Gavin King says he put this feature in merely to keep the JDO camp quiet), and it’s a great, pragmatic addition to Hibernate’s functionality. There are many reasons why you may want to do something like this, particularly when mapping to legacy data. There are other features, such as better support for native SQL in Hibernate 3.0, that take Hibernate down from the ivory tower and firmly into the pragmatic real-world category. Hibernate is now not just for greenfield projects, but is flexible enough to be slotted in to almost any legacy environment.
• Acegi Security. Writing a comprehensive security framework is difficult. Particularly if you want features like declarative security on the view tier, and comprehensive ACL-based access control functionality. It takes a lot of time and testing, and the consequences of getting it wrong can be serious. That’s why Acegi Security is a godsend. It is a comprehensive, well-tested framework, that provides granular ACL support at one end, and a host of features specifically for Web-based applications at the other. The reference documentation is of high quality, although what it lacks are a decent set of introductory follow-the-numbers type tutorials. If they can get NTLM support in for 1.0, it will be perfect.
• Eclipse 3.1 was released earlier this year, with full JDK 5.0 support. It is an awesome development environment. But it is big. And can get very, very, slow. However, the Eclipse “family” of plugins is developing nicely, particularly the Web Tools project.
• JSTL.

I know it’s not new, but it is excellent. Velocity is fantastic, but why do we need it for Web-based apps any more?

I have to admit feeling a little left out of the whole Ruby-On-Rails/Python vs. Java debate. I downloaded Ruby and wandered through some of the language feature tutorials, but due to time constraints, I didn’t get as far as U would have liked. I am a huge Perl fan, so parts of Ruby appeal to me immensely. The Ruby-based development environment that comes with the default install is still too flakey to be reliable, but I would like to revisit it again when I get the chance. I did also get the chance to play with Jython and found it to be interesting as well – it seems like it could have a lot of potential for test scripting, for instance. To me, however, a lot of the hype surrounding “Framework X vs. Java” is because Java just isn’t new and shiny enough any more – it’s too safe and “corporate”, and hence attracts criticism because it is seen to be stagnant and not evolving.

I recently was looking at the JavaBean-related XML serialization functionality (see the XMLEncoder class for details). While I was at it, I also decided to see how this was handled in .Net.

For starters, check out the following C# classes:

using System;
using System.Collections.Generic;
using System.Text;

public class MyOtherClass {
public string name;
}
}

And their Java equivalents:

public class MyClass {
private String name;
private MyOtherClass other;

}

Native XML Serialization in .Net is as easy as this:

MyClass clazz = new MyClass();
clazz.name = "Hello World";
clazz.other = new MyOtherClass();
clazz.other.name = "Test";
System.Xml.Serialization.XmlSerializer writer = new System.Xml.Serialization.XmlSerializer(clazz.GetType());
writer.Serialize(new System.IO.StreamWriter("c:\\temp\\test.xml"), clazz);

On the Java side, it is also pretty trivial:

MyClass clazz1 = new MyClass();
clazz1.setName("Hello, World!");

XMLEncoder encoder = new XMLEncoder(new FileOutputStream("test.xml"));
encoder.writeObject(clazz1);
encoder.close();


The XML file produced by .Net serialization looks like the following. Note that it does not contain any datatype information, relying solely on reflection in order to determine the correct datatypes.

<?xml version="1.0" encoding="utf-8"?>
<MyClass xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<name>Hello World</name>
<other>
<name>Test</name>
</other>
</MyClass>


The Java-produced XML file looks like this. It is generally more verbose than the .Net equivalent, and contains package and datatype information. Note that XMLEncoder will also ignore transient fields.

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.5.0_05" class="java.beans.XMLDecoder">
<object class="uk.co.researchkitchen.soap.fx.MyClass">
<void property="name">
<string>Hello, World!</string>
</void>
<void property="other">
<object class="uk.co.researchkitchen.soap.fx.MyOtherClass">
<void property="name">
<string>Testing</string>
</void>
</object>
</void>
</object>
</java>

Overall, the built-in Java serializer seems to be more powerful, or at least more customizable than, its .Net counterpart. It follows from the above tools that, in theory, you could implement a cheap Java/C# serialization system using nothing more sophisticated than the built-in serialization classes and a couple of XSLT stylesheets.

Okay , I admit defeat. Static imports are not that bad. Particularly when you are using libraries like ASM and you have to deal with tons and tons of constants. It’s nice to be able to CTRL-SPACE in Eclipse and get the constant name without having to explicitly type the enclosing interface name every time, just by adding the static modifier to the import:

import static org.objectweb.asm.Constants.*;

That saves quite a bit of typing in the average ASM client program.