The SquizLog

Sun Developer Days - Day One

This year's Sun Developer Days conference started in Sydney today and I was lucky enough to gain some insights into the evolution of the Java Standard and Java Enterprise Editions via a couple of excellent presentations.

Java SE: Tiger, Mustang and Dolphin

Having listened to Matt Thompson's American accent as he presented his keynote (Changing the Landscape of Software Development - the emergence of open source communities) my ears pricked up as Simon Ritter began speaking in his English accent. [No offence to Matt intended, it's just that I prefer British accents.]

After Simon talked a little about various new more open licences and the main features of Tiger (J2SE5.0), he moved on to elaborate on the JSRs that have been included in Mustang (JSE6), which is currently in beta. A major theme for Mustang is to make Java development easier. Three features that appealed to me particularly were:

1. The File class has had useful methods such as getUsableSpace() added so that a Java program can determine how much free disk space is available;


2. It is now, after all these years, possible to include all jars from a directory in the classpath in one go via a wildcard (i.e. *.jar). Hooray!


3. JDBC 4.0 (JSR 221) removes the need to define the database driver and then load it via a somewhat unintuitive Class.forName() statement.

Other features that Simon mentioned were JSR 202 (Class File Update), JSR 199 (Compiler API), JSR 269 (Annotation Processors), JConsole improvements and java.awt.{SystemTray, TrayIcon}.

Mustang's successor, Dolphin, is still in the planning stage via the JCP so it is too early to be sure of its contents. However, Simon described some possibilities. The first, language support for XML, he was not entirely enamoured with. As he pointed out, the syntax chosen with Tiger's introduction of Generics has made the job of supporting XML syntax problematic. Angle brackets have already been taken! An alternative syntax that Simon showed looked counter-intuitive to say the least.

Of particular interest to me is the intention to support dynamically typed languages like Ruby and Python. Part of the solution for this will involve adding a new invokedynamic byte code.

Persistence for Java SE & Java EE Applications using the Java Persistence API in EJB 3.0

After lunch Rima Patel provided a change of focus and a change of accent. I'm not sure how long she's been in Boston but Rima still has an unmistakable Indian accent and I enjoyed her use of cricket in the analogy she chose to introduce her presentation about the Java Persistence API.

As Rima enthused, when compared with Entity Beans in EJB 2.1, the Java Persistence API (JPA) is like a breath of fresh air. Whilst TopLink and JDO have also influenced the specification (now in public final draft phase), much of what Rima presented was very reminiscent of Hibernate.

JPA uses a POJO (plain old Java objects) model, referring to POJOs as entities - not to be confused with Entity Beans. It introduces the notion of a persistence provider. The chosen provider (e.g. Hibernate) must conform to the API. Entities make heavy use of annotations. For example, at the most fundamental level, @Entity denotes that a class will be treated as an entity via JPA. A primary key is denoted by the @Id annotation. Relationships to other entities are defined using annotations e.g. @OneToMany.

JPA introduces an EntityManager type that works in the same way as Hibernate's Session. Associated with this is a PersistenceContext or ExtendedPersistenceContext, the latter appropriate for use with Stateful Session Beans. And speaking of session beans, they are also simplified by the use of annotations. Indeed the presentation could have been entitled "Death by Annotations" such is their prevalence!

Rima also discussed cascading behaviour, transactions (local and XA), embedded objects, composite primary keys, the simplified life cycle (New -> Managed -> Detached -> Removed), entity listeners and callbacks, entity inheritance, EJB-QL enhancements, dynamic queries and named queries.

Her enthusiasm was well founded. Perhaps it's time to take another look at using EJB. However, as Rima emphasised, the JPA is not limited to use within EJBs. It can be used with JSE applications.

Posted to Software Development by Keith Pitty