JavaOne day one, part 2

Next session for me was Java Platform Roadmap: The Big Stuff, Today and Tomorrow. It was to some extent just a rehash of what I've had online for quite a while, but I did pick up some extra things:

• There are 12+ scripting plugins following JSR 223, i.e. the number of languages that plugs into that API
• Targeting support for Windows/Vista and GNOME, i.e. no support on that level for KDE, which is kind of disappointing
• Anti-aliasing support
• Java2D acceleration 10-60% faster, typically 30%
• They will back-port Vista support to JDK 1.4.2 and Java 5.0, when Vista ships in November (hehe, we'll see about that)
• Petshop implemented in Java EE 1.4 was 3284 LOC. Implemented in Java EE 5 it became 2777 LOC.

Dolphin details:

• Direct support for XML: XML talk = <talk> { name } </talk>;
• Super packages - bleech!
• Beans Binding, JSR 295
• Swing application framework support, JSR 296. Seems to be a framework that will make it quicker to build a typical Swing app.
• Java module system, JSR 277 (this also has support for package repositories (a la Maven ?))
• BeanShell, JSR 274
• New bytecode support for dynamic languages, JSR 292

We then saw a demo of Visual Basic code being executed on a Java VM. We'll see how useful that is. Also demoed was Project Phobos (a greek god, as well as a moon around Mars, shaped as a potato, as well as a character in Dan Simmons Ilium/Olympos books - wich one did they think of?) where JavaScript is executed on the server. Not sure what it was good for, but I guess I'm just conservative.

Then I went to the session called Mastering Mustang and Developing Dolphin. Dolphin is claimed to be significantly faster as a server VM compared to Mustang. Of interest:

• They've dropped JSR 260 (Javadoc Tag Technology Update) and 268 (Java Smart Card I/O API)
• They've also dropped reflective access to parameter names (unfortunate, I think, but I had the impression it was a bit complex, or invasive, to implement)
• Added support for javax.swing.GroupLayout
• Class-path wildcard (why didn't anyone think of that before?)
• Free disk-space API
• Language support for properties to get rid of get/set functions (I dearly hope they don't make them similar to C# properties)
• Method references (Yikes, is it really such a pain to use classes?)
• Block closures
• ... and more stuff he went over so fast I had no chance to jot down ...

Relese candidate in September, release in October.

Mustang from Sun will co-bundle Derby, but it is not a required part of Java SE 6, which confuses me a bit.

Next session for me was the What is Happening with SOA in Open Source panel. First out was Mark Little from JBoss, which has worked with this for about 5 months. Then came Peter Walker from Sun, talking about OpenESB. It is supposed to be released early fall this year. Next up was a guy whose name was gobbled up by the PPT presentation. Poor guy, didn't hear the name of him, his company, or the products name. Celtix? Mentioned SCA. Others mentioned JBI. Does that mean we can trust these letter combinations to hang around for at least a year? Then my old colleagues Jeremy Boynes described Tuscany, which is an incubator project at Apache. Code contributed from IBM and BEA. The spec for SCA can be fetched from IBM. SCA seems to be tied to SDO. Will be shipped in May this year. Then, finally, it was Glen Daniels from Sonic Software (but he also works for Apache, I think). They have a framework called Synapse, which is a WS Mediation Framework. Now, what is that? It runs messages through to each mediator until told to stop. OK... huh? Built on top of Axis2. Then, finally finally, was James Strachan from LogicBlaze, of ActiveMQ fame, if I remember correctly. Never seen him before, so that was interesting. Anyway, LogicBlaze has a product named Fuse, which seems to be tons of Apache software licensed products bundled together.

Then some random questions were paired with less than random answers, in not too interesting ways. What I came away with after this session is:

• There are more open source projects in this area than I thought
• They seem to be pretty committed to compatibility with eachother
• They even know eachother pretty well, which is good news, I assume
• Lots of things are still really unclear about how these things will work in the end
• There was quite a bit of agreement that BPEL perhaps wasn't always the best way to write your business wiring. Perhaps Java might just work (gasp). A problem is joins, though, since there is no direct Java language construct supporting it.

I have a feeling that there's a lot of politics in this area, and none of that got any cleared after this session. I guess I have to punch Jeremys kidneys to get some truth out of him. ;-) Maybe beer works too, but that takes longer time.