Today was the first day of JavaOne proper and it was packed! There are so many people here! I arrived for breakfast at about 8am and already a queue was forming for the opening keynote general session. By the time I joined the end of it it had stretched the length of the Moscone Center. When I got inside the massive hall it was more like a rock concert. Loud music was pumping and some awesome break dancers were performing on stage. Then just before the keynote was to start James Gosling started firing t-shirts into the crowd using a giant slingshot held between two other people.

So the first general session was on the theme of the whole conference; “Java + You”. There were lots of demos of how Java is being used on the “four screens” of your life (I think these are your PC, phone, TV and car). Probably the coolest demonstrations were of JavaFX, used for creating rich internet applications similar to Adobe’s flex and AIR. You can make some cool applets using JavaFX but the coolest thing is you can drag these applets off the web page and onto your desktop and they continue to run. In fact you can then close the web page and keep the applet locally to be run on its own whenever you want. That’s cool!

The first technical session I attended was on IBM’s WebSphere sMash and ProjectZero. This is a “commercial project with a transparent development process” and is a rapid application development environment that is geared around developing RESTful mash-ups and Web 2.0 apps. It supports PHP, Groovy and Java and contains a PHP interpreter written in Java. At the moment this interpreter runs an intermediate representation of the PHP code but in future they plan to compile it to byte code. It contains its own web-based IDE and the application that is produced contains its own web server. So you can have a number of these applications running and they are started and stopped using an inetd type service. It looks like it is targeted at the enterprise developer who wants to throw something together quickly for internal use.

Joshua Bloch, Chief Java Architect at Google, gave an interesting talk on ‘More Effective Java’ which was a selection of points from his new book. He spent quite a bit of time on hints for using enums. For example, replacing bitfields with enums. There are lots of problems with bitfields: not typesafe, no namespaces, printed values are cryptic, eg ’12’, don’t scale – if number of constants grows beyond 64 you’re screwed. A solution is to use EnumSet and you end up with nicer code like text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC)).

Rod Johnson from Spring gave a session on new features of Spring 2.5. He listed a whole heap of new features like:

• overhaul of Spring MVC
• enhanced testing support with JUnit4
• extended SQL error code mappings for popular RDBMSs
• integration with latest versions of JavaEE 5 APIs (Servlet 2.5, JSP 2.1)

but he focussed mainly on annotations.

Using annotation based DI can reduce the external config required and is more concise but downsides include:

• per-type not per-instance
• won’t work for legacy code
• need to recompile java code to change configuration
• not suited to externalizing simple types

Even so, Rod suggested fairly extensive use of annotations. You can use the @Autowired annotation which is Spring’s own syntax and uses the default autowire by type behaviour. This is the same as using autowiring in xml files but by using annotations you can be more selective. Of course the downside is you are using a spring specific annotation. If you don’t like this you can use the @Resource annotation although it is not as powerful as @Autowired so is not a best practice.

Rod also went through some of the other annotations like @Component which allows component scanning (where Spring scans your classpath for annotated classes). I can see how annotations are nice but it also means you lose your ‘application blueprint’ when all your beans are defined in xml.

Bill Pugh gave a really interesting talk on “Defective Java Code: Turning WTF Code into a Learning Experience”. Bill is responsible for the cool FindBugs static analysis tool and he had good tips for some common errors. He spent quite a bit of time discussing the equals method which can be trickier to implement than it might seem. The following must be true when implementing the equals method:

• equals(null) returns false
• if x.equals(y) then x.hashCode() == y.hashCode()
• equals is reflexive, symmetric and transitive

Symmetry is very important as non-symmetric equals can produce confusing and hard to reproduce results. He also discussed the debate of using instanceof or getClass() when implementing equals. Basically, both have problems. if you use instanceof and override equals you may break symmetry. If you use getClass then you cannot have a subclass equal to superclass. However you only need to worry about this when designing with subclasses.
Bill described different types of equality:

• Object equality (the default and useful more than you would suspect)
• Value equality (eg ArrayList and LinkedList representing {1,2,3} are equal)
• Behaviour equality (objects are equal if you can’t distinguish them based on behaviuor) – more subtle

Use of getClass will cause any subclasses to break equality. Also, use of getClass in hibernate objects will cause failures. However, if you use instanceof and override it you must not change the semantics of equals – all you can do is use a more efficient algorithm or instrument for debugging/performance monitoring. getClass is sometimes used in abstract base classes (eg BasicPermission class). If you use instanceof consider declaring the equals method final. Basically the moral is you should document your equals semantics. FindBugs can detect common problems with equals methods, for example, there are two equals methods in the JDK and four in eclipse that always return false plus one in eclipse that always returns true.

After the Rails stuff from yesterday I was interested to hear Guillaume Laforge talking about Groovy and Grails. This is a cool platform that uses Groovy in a Rails-type framework. What’s interesting is that it makes use of such projects as Spring and Hibernate yet simplifies their use so there is much less configuration required. For example, you don’t need to create hibernate mapping XML files.
The syntax is very Java-like (unlike Ruby) and integrates tightly with Java at every level. You can reuse legacy code and while Grails comes with jetty for development it is simple to package it as a war file for deployment on tomcat or some other app server.