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.
J2SE 6
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();
ScriptEngine engine = manager.getEngineByName("javascript");
//init .js file that creates a JavaScript function called formatDate()
engine.eval(reader);
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.
JEE 5
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:
3.0
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.
4
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.
2.0
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
so. The avalanche of JavaScript libr
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.
1.0
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….
11
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).
Lonneke Dikmans, Oracle ACE and Regional Director Fusion Middleware, gives an overview on her blog of the statistics for JavaOne2007: how many sessions for each topic. See http://www.approach-alliance.nl/. It seems that apart from J2SE 6, the winner is: AJAX?! The overall number of sessions is not as large as I had anticipated. Wrong expectations I suppose. Let’s see whether the quality is as I hope and expect.
Thanks Lucas for these guidelines. I will continue with ADF BC and I see great opportunities with working with data outside RDBMS like webservices, ldap etc…
My developers come from traditional C/S in a 4GL fashion (not Forms but WinDev which is famous in France). So it makes sense for us to stick with ADF all the way (BC, Model, Faces).
Seb,
That is a very good question and one that is not too easy to answer in very generic terms. Putting it very black and white, it would seem that for developers with a strong background in SQL – for example because of past Oracle Forms or PL/SQL programming experience, ADF BC gives a much easier learning curve and makes you much more productive than the more truly OO approach you can take with EJB 3.0, powered by for example Toplink.
When the application you are developing is very much data oriented, almost CRUD-like (Create/Retrieve/Update/Delete) – as is by the way the reasoning for many of the Ruby on Rails adepts – ADF BC will be easier and more productive, especially when you are leveraging the ADF Model (Data Binding) framework. It is exactly because of this reason that most of Oracle Fusion Applications will be built on the stack ADF BC (+ ADF Model) + ADF Faces.
When the application is not so much RDBMS oriented, possibly because there are multiple or at least different data sources to work against or because the application works against data services behind which a database may be lurking but which is not accessed directly or because there is a lot of middle tier business logic and relatively little DML activitiy, then a strong, sound OO domain model is probably the best way of working, and Toplink is the best option. Another consideration for using Toplink can be its advanced, shared cache: this allows for middle tier caching of (largely readonly) data that can help speed up performance and lower the load on the database. However, it is a complex business getting the best setup for high performance and scalability.
While a few years ago, a robust (and frequently complex) Object Relational Mapping was very much in vogue – to put it mildly – with a Domain Model (OO) created completely independently of the underlying database design and the ‘impedance mismatch’ overcome using fairly complex ORM frameworks, from EJB 2.1 to Hibernate and Toplink, it seems that these days a more pragmatic approach, accepting the database design as it is as the driving force for data operations, using simple Data Access technologies such as iBatis or even (Spring) JDBC or indeed ADF BC is much more done. And as I said, many advocates of the Ruby on Rails approach are ecstatic about this light weight approach to database access.
Of course this is only a very crude, short cut, off the cuff reaction. There are much more subtle considerations and factors in play. I am sure many others can add their 2 cts worth to this discussion.
regards
Lucas
At the moment it is actually Studio Edition Version 11.1.1.0.0 (JDEVADF_MAIN.1JAVA_GENERIC_070430.2213.4517), but that is just the internal Build number for the just before Technical Preview release. I am sure some other exotic number can be conceived of to make all of use happy again….
Hi Lucas,
Nice overviews and thoughts. In an Oracle shop as my company, what would you suggest between EJB 3.0 JPA with Toplink and Oracle ADF BC ? Do you have any recommendations for when and why to switch to one or another ?
Thanks,
Seb.
Are you sure it is “11” for JDeveloper…?
A version number like “11.0.4.0.2-112-patch2” would be more like an actual Oracle version number 😉