Friday started off as usual with General session. But it was pretty boring. Noteworthy was that both Scott McNealy and John Gage talked about poverty and malaria being the real challenges for us. Every day 3000 children dies in malaria! That disaster dwarfs 9/11 by comparison.
Next up for me was JSR 235 and Service Data Objects (SDO) by a bunch of people from IBM, BEA, SAP, Oracle and Xcalia. I had the impression it could be a competitor to both JDO and EJB 3.0 Entity Beans (a.k.a. Hibernate), but I no longer think so. It is all about being able to transfer data around a SOA application in a platform neutral way, so it can be consumed by services implemented in Java, C#, VB, C++ and what not. Lots of companies doing this, but there are also some open source implementations, most notably the Apache Tuscany project.
Data comes into a SOA system through a Data Access Sevice, where it assembles data from any kind of source. If a client in such a SOA application changes data in a SDO object, then it needs to be passed back to the Data Access Service to be persisted.
Generated data APIs are plain POJOs. You create an interface for the POJO, and then you can get a subclass generated on the fly. You can also do it by creating a schema and get a dynamic SDO from it.
A really cool feature is that you can access data through an approach similar to XPath or OGNL. I wasn't fast enough to type down the syntax used, but it was pretty straightforward. I've been asking for this, and it turns out it exists!
Something that bothers me is how they misuse the word POJO. SDO objects aren't POJOs, they are just structs of data. Sure, an object can contain other objects, but that is to some extent also true for structs (pointers in C++, for example). I mean, it is a bit like talking about the data held in an XML document as a POJO. There is no behaviour here! You can't, for example, validate data in any other way than what is supported in XML Schema. Sure, that may in many cases be all you need, but if it isn't, then you could be in trouble.
The unique feature of SDO seems to be the dynamic nature of the data. You can access data without statically knowing the exact nature of the data. In this respect it is different from JDO and EJB 3.0 Entity beans.
Tuscany implements SCA, SDO and DAS (Data Access Service). It exists for both Java and C++. In the works is also a PHP implementation, but done outside the Apache umbrella. Will probably be released by the end of 2006.
I briefly attended the Effective Java Reloaded session by Josh Bloch. Good session. There sure are lots of whacky generics gotchas. During the Q&A session I pointed out a potential flaw in the design of one of his classes. I should get a free book for that! :-) Update: Read Bloch's comment below for details. It turns out the flaw can be seen as a feature.
Next up was JSR 170: The Content Repository API by a few guys from Day Software. They claimed there were 800+ ways in which people accessed content in JSP pages.
They then described the way you normally get a repository and access data from it, and the API sort of resembles LDAP. The types supported are string, binary, date, long, double, reference, name and path. You can get data by traversing the tree by looking at the nodes, or access objects directly by using paths, or by using UUIDs. It is also possible to access nodes by using a subset of XPath.
They showed a kind of data definition language for defining note types. It looked pretty straightforward.
Apache Jackrabbit is the open source reference implementation of the JSR 170 specification. It was just released as version 1.0, so I guess it is reasonable stable. Finally had a demo showing the product from Day Software. A neat feature was that they had a WebDAV interface to the repository, so he could use Windows Explorer to just drag and drop files to the nodes in the repository.
During the Q&A session I heard that JSR 283 will be "version 2.0" of JSR 170. It will be upwards compatible. A good session, I'd say, as a brief introduction to this JSR.
My final session at JavaOne was How to write APIs that stand the test of time.
A few things I picked up:
- Do a modular design, i.e. compose applications from smaller chunks
- Be explicit about what dependencies you have, e.g. JDK > 1.4.2+
- Use an execution container like NetBeans (I have no idea what they are)
- An API is a promise about compatibility
- Use cases --> scenarios --> JavaDoc
- Be consistent in your API - better to be consistent than be optimal
- Be simple and clean - expose only necessary functionality
- Think about future evolution
- Use stability categories
- Be customer centric --> easy to use APIs
- Be diligent about test coverage
- Optimize the API for the maximum number of users
- People often learn an API by using code completion in the IDE, not by reading JavaDoc, so method names must be very good
- Factory methods gives you more freedom, by getting rid of constructors
- Do not expose more data than is necessary
- Split API classes into one package and hide the rest
- Restrict access to friends
- They recommended a new class called ServiceLocator in Java SE 6 (Mustang). Never heard of it before.
- Do not call functions in constructors that can be overridden. The solution is to use factories and have lightweight constructors
- Ajax was the most popular subject! Two of the top four sessions had Ajax in the title!
- There were many many sessions about EJB 3.0 and Java EE 5
- Sun claims there are now 5 million Java developers. I'm a little bit skeptical - I remember it was 3 millions just a few years ago.
- Not much excepting was to see at the expo. Not sure why, but perhaps most innovation right now is done in open source, and they can't pay for a booth.
- SOA/JBI/SCA and the whole paraphernalia around them was hyped a lot