It is a fact: JavaOne 2008 unofficially started today! CommunityOne kicked off at 9:30 with a general session. At 11:00 the first parallel sessions started. Here is what I think of today.
General Session
During the general session Ian Murdock, Vice President of Developer and Community Marketing at Sun Microsystems and “ian” in the name of my favourite Linux distribution (Debian), drew a comparison between Linux on the one side and Sun and Open Source on the other side as modular systems. Whereas in Linux the packages are the modules built and installed around a core, we, the developers and users of Sun and Open Source software, are the modules around those Sun and Open Source software.
Next, Matt Asay, General Manager and Vice President at Alfresco, led a panel of four illustriou session suggested s people in a discussion of the value of the community to Open Source software. It became clear that theOpen Source community plays an extremely important role by using, submitting code and bugs and blogging about Open Source software.
Finally, Rich Green, Executive Vice President of Sotware at Sun Microsystems, talked us through the new and exiting features of OpenSolaris. We had to leave this session since the parallel sessions were starting.
First parallel session: Getting started with OpenDS
OpenDS is an Open Source Directory Server. The session summary in the CommunityOne booklet suggested a look into the APIs available to extend the capabilities of the server. After that, a deep dive into Penrose, an Open Source Virtual Directory Server, was on the programme. Unfortunately, the look into the APIs only proved to be a list of available methods and a brief oral explanation on how to use them. The Penrose server was only superficially skimmed. I hoped for more code examples but the total amount of code examples was exactly zero.
Second Parallel Session: OpenOffice.org Extensions Development
Jürgen Schmidt, OpenOffice.org API Project Lead, presented a nice session about the OpenOffice.org API and the OpenOffice.org plugin for NetBeans. In the past I have attended several of Jürgens presentations to keep track of the new features that the API and the plugin offer. It is a shame that only about 20 people attended this session. It was clear from the look on Jürgens face that he wasn’t too happy about this too. Next Friday, Jürgen will present a hands on lab and I’d suggest to anyone to attend this session. The main thing I remember from the session is that the API is slowly changing. Where in the past UnoRuntime.queryInterface was a common call in almost any OpenOffice.org API operation, slowly new service providers make their way into the API so more natural Java methods can be used to get hold of properties and interfaces of OpenOffice.org components.
Third Parallel Session: OpenSSO
What was announced as a workshop proved to be a presentation about OpenSSO, the Open Source Single Sign On project. Pat Patterson and Daniel Raskin introduced us to the main goal of the OpenSSO project, which is to provide an Open Source Single Sign On solution for federated access to any web application, both hosted inside and outside companies. Speaking of federation, Pat explained that this basically is using the same user indentity to authorize that user over different systems. See also this wikipedia page about federated identity.Next Pat introduced the FedLet: a small component that enables applications to support federated identity with Sun tools. Finally, we got some details about how to enable federated identity on GMail and SalesForge. See my colleague Lucas Jellema’s post about this session for more info.
Fourth parallel session: EclipseLink
The final session I attended today was about EclipseLink, the Open Source version of TopLink. First and foremost, EclipseLink v1 is to be expected in June 2008. Besides that, Doug Clarke and Shaun Smith, both working at EclipseLink at Oracle, gave an excellent outline of what EclipseLink is and what it adds to the reference implementation of JPA. EclipseLink will be the JPA provider in GlassFish v3, so if you haven’t had a look at it now is a good time to do so. Besides implementing JPA 1.0, EclipseLink has a set of annotations (or equivalent XML configuration options) that enhance JPA for better Cache configration and advanced mappings, such as @Converter, @BasicMap and @NamedStoredProcQuery. Doug and Shaun did a nice and deep technical session on EclipseLink and it got me really excited about it.
Conclusion
Despite feeling slightly ill today and skipping the middle part of the sessions to take a nap back at my hotel, CommunityOne proved to be a good warm up for JavaOne. It was great to be there and if you haven’t attended this year but will attend JavaOne, be sure to attend CommunityOne next year as well!
Wouter,
Thanks for a great write up. I would like to add one or two observations on EclipseLink. I have the feeling that the TopLink team simply do not grasp why the Java Community is so slow in recognizing that with EclipseLink they have been offered nothing short of pure gold. Sure, in the past you had a choice when it came to the persistence layer. TopLink was not free, so if you had no or a tight budget, you could consider using Hibernate or even some other ORM framework.
But now that EclipseLink – mind you that is all of TopLink, nothing held back! – has been open sourced, you do not need to choose. TopLink is by far the superior persistence product, much more advanced than Hibernate and any other tool. With advanced caching support (L2 cache that shares objects across all sessions – the entire JPA Persistence Unit – instead of an L1 per EntityManager or per session cache) that gives much better performance and smaller resource usage. With advanced configuration options for native database features leveraging the best of most popular databases, with advanced support for using Stored Procedures, special data types such as XMLTypes and user defined database Object Types, etc. etc. Besides plain old database to object mapping (JPA 1.0), EclipseLink provides SDO 2.1 and JAXB support for alternative mappings. Why would you ever consider not using EclipseLink?
It is an honest puzzlement that sometimes can grow into frustration. Why does the world not (yet) recognize what is plain to see? Well, of course they realize that they have to catch up in building a community. Doug Clark I believe said something to the effect of: “what we lacked in developer involvement, we made up for in functionality”. And now, they realize, is the time to build that developer and community involvement.
What not seems to help is the name: EclipseLink sort of suggests a PlugIn for the Eclipse IDE – which is very much not what EclipseLink is. It is a full blown ORM framework that can be used just like Hibernate is used. And the fact is that TopLink is not as well known as Hibernate. I for one hope that Java developers and technical architects will take the opportunity to take some time for a second – or perhaps even a first – look at EclipseLink. It really is powerful and solves a number of common problems with Persistence Layers in a very elegant way. Having a growing community would mean having more resources, developer guides, WIKI entries, blog articles, case studies, etc.
EclipseLink can be found at http://www.eclipse.org/eclipselink/. You will find a Wiki, downloads (milestones that are picked up for GlassFish V3 milestones), a newsgroup slowly growing in activity, etc. There is also the EclipseLink team blog at http://eclipselink.blogspot.com/.
Plans for the immediate future – to timeline yet – include support for JPA 2.0 of which EclipseLink will provide the Reference Implementation, support for Database WebServices – which I understand as “EclipseLink publishes WebServices for Database resources” ( in the words of the original EclipseLink project proposal: “EclipseLink-DBWS will provide a web services capability for developers to easily and efficiently expose their underlying relational database (stored procedures, packages, tables, and ad-hoc SQL) as web services. The metadata driven configuration will provide flexibility as well as allow default XML binding for simplicity.”.
One final note on what I liked in the presentation: the callback features that you can configure in EclipseLink. Hooks – very much like database triggers such as the After Logon trigger or the After Startup trigger in addition to more common DML triggers – that we can use to instruct EclipseLink to call our handlers on specific events in the Persistence Unit and/or Entity lifecycle. In a simple, annotation (or XML configuration if that is what you prefer) way, you configure those callbacks, such as SessionCustomizer and DescriptorCustomizer.
With over 40 committers – most of the staff from Oracle and Sun – and a history that started in 1992, EclipseLink is a very mature product, even though we still have not seen its 1.0 release! The challenge for the EclipseLink team is primarily to grow that community, to get airtime and the visibility the product deserves. I have no doubt that we will make some contributions on our weblog, as we clearly see the potential for EclipseLink.
regards, Lucas