Monday Keynote
This presentation was made by three engineers from the Swing team, and it was a bit disappointing. Each of them addressed a different domain: high-level Swing, performance in repaint and hardware acceleration.
The first part mentioned some obvious tricks such as writing your own custom model whenever it's appropriate, and also gave some overview of the new API's introduced in the JDK 1.4. The following two parts were very low-level and probably only of relevance to people doing imaging.
One thing worth noting is that JDK 1.4 introduces the EventHandler as a way to create listeners. This class belongs to the dynamic proxy package but it's being reused in this context in order to avoid the proliferation of anonymous listener classes that simply "bounce back" control to the callers. I'm happy that Sun finally acknowledged this problem but...
Does the concept remind you of something? Right. Delegates. One of the two reasons why Sun sued Microsoft in the first place: because Microsoft had introduced this concept in their own virtual machine and it was not Java. At least they finally acknowledged the soundness of it (I've been asking for them ever since I started using VJ++).
My impression is that most JFC users are more into high-level interfaces than low-level 2D and 3D graphics, and I was hoping to get more insight about performances at this level, but I came back empty-handed.
EJB 2.0: 20 things you've never seen
Tyler was giving this presentation, which attracted a very compact crowd (people were sitting in the aisles). He proceeded in dispelling all the myths that have plagued EJB because of the deficiencies in the 1.1 specification and then emphasized how an improvement EJB 2.0 was, even over solutions like Stateless Session Beans + JDBC.
The crowd was riveted. I was checking regularly around me, and they were busily scribbling notes and following every word Tyler was saying. The funny anecdotes that he dispensed here and there definitely contributed to make people relate to the problems he was addressing. There were a lot of questions after the presentation and he was still being harassed on his way back to the booth :-)
I have no doubt that all the attendees to this session will go back to their company and try to buy everyone around them into EJB 2.0.
JDO with Entity and Session Beans
Craig Russell, the JDO spec lead (although, not exactly any more) gave this presentation. Before I dig into it, some background about the JDO story.
The JDO effort started in a typical Sun way: a skunk work by a little group which, after a little while, received enough visibility within Sun to become a full project. By the time Sun realized its mistake, it was too late: JDO was competing against EJB and the customers became more confused than ever. Sun never explained in a convincing manner what their position was, except maybe by being clear on the fact that as of today, there was no plan to include JDO in J2EE.
Time went by, and when it became obvious that JDO was nowhere near replacing EJB, Russell changed his angle, in a purely "if you can't beat them, join them" fashion. The message he has been pushing these past months was "JDO can be an alternative to persist Entity beans". Hence this talk, and my great interest in it.
Craig opened by enumerating all the ways that Java objects can be persisted: File I/O, Serialization (I'm unclear on the difference between these two), JDBC, CMP and JDO. The way he sees JDO plugging itself in EJB's is by the use of BMP.
While it is indeed the only approach that makes sense, it makes me very puzzled. As CMP is finally getting the recognition it deserves with EJB 2.0 and when we are finally about to see J2EE users embrace it in full, Sun makes the same mistake again by pushing a technology that will do nothing else than confusing its customers more, and for a result that is far from being overwhelmingly better. But let's leave the controversy for now and focus on the technical side.
Then again, the presentation fell very short. First of all, advocating BMP to push a persistence mechanism is a huge step backward to me, and I don't think I need to explain why it is a bad idea to suggest to customers that they should implement their own transaction marks, handling rollbacks, etc... But most of all, when showing different pieces of code illustrating the different approach (CMP vs BMP/JDO), the difference wasn't very striking to me.
Basically, with CMP, you look up the JNDI name of the home, perform a findByPrimaryKey() and then act on the result. With JDO, you look up the JDO persistence manager, retrieve the object by its key and then do something with it. Admittedly, the implied deployment descriptors are overlooked, but this is more a matter of having good tools (e.g. WebLogic Builder ;-)) rather than a deficiency in the technology.
There are two interesting things to say about JDO, though, but the funny thing is that Craig is pushing the one that seems the least useful to me:
After doing SQL and EJB QL for a while, I would certainly feel relieved to write my queries in Java.
The biggest disappointment came when the session ended when I expected that we were finally getting to the interesting part. I can't really understand why Craig thinks that EJB users will be thrilled to use BMP and JDO, but maybe I'm just missing something.
WebWorks
Later that day, I met with Rickard at a pub, who was hanging out with some of the WebWorks developers. WebWorks is a competitor to Struts, and while I think it will be an uphill battle for Rickard and his team, there is certainly room for competition in this area. I didn't have a lot of time to drink more beers with them because I had to head out to the session that I definitely was looking the more forward to...
Eclipse
The OTI team had reserved the Thirsty Bear on Wednesday night to showcase Eclipse and get feedback from users. For those of you who don't know Eclipse, in a nutshell: it's a pluggable IDE developed by OTI (acquired by IBM) and which is the foundation for WSAD (WebSphere Application Developer). Eclipse features an extremely slick UI (not Swing) and a very powerful and well-documented plug-in back-end (a lot of external plug-ins already exist, with a lot more to come).
Simply put, I was blown away the first time I tried Eclipse six months ago, and things are only getting better.
Erich Gamma, of Design Patterns fame (you should know him, or you shouldn't even be allowed to read this) started by demoing the basic features of Eclipse. In short: intelligent editing, debugging (including hot replacing of code), refactoring (very neat, especially if you like Beck's books and the principles of XP in general, or just if you have ever wanted to rename a method across a whole project or "pull up" methods in a hierarchy of classes), smart diff and merging of files, support of version control systems, history snapshots, etc...
It's hard to communicate why Eclipse feels so good to use, because a lot is due to little details that manifest themselves to you as you use the tool.
After Erich, another OTI member stepped up and asked what was the platform that users wanted most for their next porting effort. Four hands came up and clamored "MacOS" (no surprise here, it's pretty much the only platform not on the SWT porting list yet). Well, surprise, OTI unveiled a Mac laptop and showed Eclipse running on it. It's probably still in beta, but Eclipse will definitely appear on MacOS X in a very near future.
Then the session broke down to questions and answers, most of which were hard to follow because the upper floor of the Thirsty Bear is very noisy, but I ended up talking with John Wiegand, who is the lead architect for the IDE, and exposed to him some of the problems I encountered with Eclipse (mostly due to the way they manage their filesystem). Not only did John pay careful attention to the problem I was bringing up, and he immediately understood its importance, but he also remembered my name from seeing my postings on the newsgroup. The newsgroups receive something like two hundred messages every day and I've only posted there a few times... I think this explains a lot why the support provided by the OTI team there is top-notch.
Keep a close eye on Eclipse, it's going to change the way we write code.