Sunday morning, Schiphol Airport. It is almost time to depart for San Francisco, for this year’s JavaOne conference. Apparently the weather is great in SFO, so it is going to be a hot week, one way or the other. Last week I had to schedule the sessions I intend to visit. And I ended up picking a pretty broad selection of sessions and BOFs covering a wide range of topics, from JEE, Services & Integration to Scripting and RIA. These sessions represent this year’s primary magic numbers for JavaOne: 6, 5, 3, 2, a touch of 4, and of course the big 1.0.
So what are these so called magic numbers? Easy enough:
most of them are releases, some are JSRs. The biggest topic for last year’s JavaOne clearly was JEE 5. This year’s most visible number has to be 6, for the J2SE 6 release of late 2006 will pervasively be present in many sessions.
Mustang has bolted from the stable, quite a while ago actually. Beta releases have been around since early 2006 or before, the production release has been at the end of 2006. Of course many of its features will be discussed during JavaOne 2007, as only now people start using it – tentatively at first.
The key themes of J2SE 6 have been discussed many times before: Performance (50% gains over J2SE 1.4), Desktop, Integration with Scripting, Security, inherited from JEE 5: support for JAX-WS 2.0 (Stax Parser, JAXB 2.0), JDBC 4.0, ), Java Compiler API, Management (JMX, jConsole, jhat, jmap, jps, jstat).
The integration with scripting languages, at the core programming level, may open a new round of discussions about whether Java developers should ban scripting languages, move over to them completely – as some formerly Java ‘gurus’ would have us believe is right – or add them to the toolbox for special occasions. Of course the same question now asked at the J2SE level can be asked for Web Application Development.
FileReader reader = new FileReader("src/main/js/format.js");
ScriptEngineManager manager = new ScriptEngineManager();
engine.put("days", new Integer(10));
engine.put("hours", new Integer(16));
String result = (String) engine.eval("formatDate();");
The Java Compiler API – while clearly not a mainstream topic- intrigues me. Even though at the present I cannot grasp all it can mean to us, I will look into it. Being able to intercept the compiler’s actions should open up interesting avenues. But where those will lead, is to be discovered yet.
Number 5 is still a magic number, as a lot is still to be discussed about JEE 5. Having seen the production release of JEE 5 about a year ago, the effects of many of its constituents are widely visible and will continue to reverberate for some time to come, including thus year’s conference.
Java Server Faces is one the most visible elements of JEE 5. Even though the JSF 1.0 specification was released almost three years ago, the hype really took off during the past 12 months. AJAX powered JSF frameworks are springing into existence all around. Take for example the JBoss RichFaces, RC Faces, SUN Ajax JSF BluePrints, the jMaki initiative and many more. JSF implementations that have been around for much longer have been open sourced, starting with Oracle’s ADF Faces that became Apache MyFaces Trinidad and including ICEFaces that was donated to OSS late 2006. While there are still issues with the interoperability of some of these JSF libraries – many cannot work with one another – it is clear that an ever strengthening palette of JSF components is at the fingertips of JSF Web Application developers, allowing them to very productively develop standards based attractive applications. I expect to learn more next week about the JSF implementations, there future direction and their interoperability. With the discussions recently opened for the 2.0 release of JSF, I expect to get a good grasp on where those discussions and that release will lead us.
One extremely important element of JEE 5 takes us to the next magic number:
One of the key parts of the J2EE platform always has been Enterprise Java Beans, initially to the benefit of the platform, but increasingly over the last few years as a liability (ask Rod Johnson and his crew). JEE 5 is more about the redemption of EJB than anything else. EJB 3.0 has to overcome the complexity, lack of productivity, overhead, etc. of the 2.1 release. Simplicity, configuration by exception, intuitiveness, absorption of popular and successful ideas from the world of Object Relational Mapping are all key for the longer term survival of EJB. It seems that the 3.0 release – while still in its early days and with limited support from the main Application Servers – has done a pretty good job of it. The EJB 3.0 JPA – Java Persistence API – has rapidly gained a lot of support. Organizations previously using ORM frameworks such as Oracle Toplink, Hibernate or KODO are starting to use EJB 3.0 JPA as their primary way of doing ORM – or looking that way. Underneath the standard APIs they continue to use their favorite implementation, but now with much more interoperability and easier bringing in of new developers.
Full support of EJB 3.0 and JEE 5 in all the major application servers will further stimulate the success of EJB 3.0 and JPA. As will the recent donation to the Open Source domain by Oracle of their Toplink product, formerly of WebGain. Already partly open source as Toplink Essentials, the Reference Implementation of the EJB 3.0 JPA, this open sourcing of all of Toplink, arguably the most advanced Object Relational Mapping Framework around – and around since 1994! – will have a serious impact on the ORM landscape. The main – probably only reason – for choosing Hibernate over Toplink, has disappeared. While many organizations may not immediately have a need for some of the most advanced Toplink features and therefore not migrate in droves from Hibernate to Toplink, many others will. Anyone getting into serious ORM need not look further: EJB 3.0 JPA with Toplink as the implementation seems to be the most logical choice now.
With the EclipseLink initiative, that seems to shoot for ‘world domination’ through the creation of a (de facto) standard for the more advanced ORM features not yet covered in EJB 3.0 JPA, even more groundbreaking events seem to unfold. EclipseLink is definitely on my list for JavaOne to find out more about. If I do (well, when I do) so, I will let you know on this blog.
Not the most important number this year, but still 4 or rather 4.0 has some meaning: JDBC 4.0, JBoss 4.0.x, Debian 4.0 (Etch) are pretty relevant releases. The main JDBC 4.0 improvements: support for SQL/XML and XMLType, Rowid, more extensive support for CLOB/BLOB and an integrated Java DB (Derby DB) in the JDK – mainly for development ease.
You may think: Web (2.0). While that is probably the most visible 2.0 association, there are quite a few other 2.0 releases worth looking into: Spring Framework 2.0.4, DWR 2.0, JBI 2.0, BPEL 2.0, WSRP 2.0, GlassFish 2.0, FireFox 2.0, Alfresco 2.0,â€¦.
Web 2.0, the Ajaxification of the Web, Rich Internet Applications, are of course all the rave – and have been for the last year and a half or
aries, JSF related frameworks and also non-HTML browser technologies, both commercial and open source, has been overwhelming – as avalanches tend to be. It is not difficult to find a framework, but to pick one – especially the right one. Preferably one that will survive beyond the next year. And that is a lot more difficult. For one of our projects for example, we started out with Qooxdoo, then later on switched to DOJO, partly because of the functionality, but primarily for the better looking future of DOJO. Getting stuck on yesterday’s favorite in a world where very small teams of developers can create very visible frameworks is a danger for the mid-term maintainability and ultimately success of your applications.
One serious question to deal with: should we – and if so under which circumstances – make use of non-HTML technology for creating really rich web applications. Technology such as Flex or OpenLaszlo? With the HTML based frameworks, both plain JS as well JSF, getting richer all the time, do we need the additional edge from RIA technology? Then you see a Flex or OpenLaszlo demo and you start to wonder again. Another question to try to get some answers in San Francisco.
One other omnipresent number during JavaOne undoubtedly will be 1.0 – and not yet quite 1.0. Let a thousand flowers bloom. And that is how it is with open source projects. Dozens are started every month, hundreds perhaps. For many, their bloom is short and their demise sudden. Many linger on in a semi-comatose condition, never to be heard from again. And some really make it, far beyond the 1.0 release. The real challenge of course is to spot those few, early on. Among the candidates in the 1.0 range are DoJo (0.9), jMaki (0.9), Apache (MyFaces) Trinidad, JBoss Seam 1.2.1, Wicket (1.2.6), SDO en SCA, BPEL4People, Google Web Toolkit (1.3), Dolphinâ€¦.
For people like me who are to some degree emotionally attached to the Oracle technology, this year’s magic number is 11. And to be exact: 11g, the release label for the next wave of Oracle Technology products, from the RDBMS to the Application Server, the Fusion Middleware such as the SOA Suite and WebCenter and of course JDeveloper. We have been fortunate enough to work with the 11g Beta release for the database and for the past weeks I have also had access to the 11g Technical Preview of JDeveloper.This week will be an opportunity to find out more details about these releases that will probably appear starting in the Fall of 2007 (Oracle Open World).