Darn. I missed the beginning of IBM's morning keynote. Typically it wouldn't be a big deal as the keynotes, especially the non-technical ones, are mostly marketing talk and thus not-so-interesting for me, but this time it was really good: IBM walked through the whole development process of Eclipse, showing loads of plugins they are using, the testing systems etc. Eclipse may not be *the only IDE* anymore, as NetBeans and IntelliJ IDEA have been making some waves recently, but Eclipse's development and shipping track record is incontestable. From Eclipse WTP 0.7, every milestone build has shipped at the exact date decided a year or more earlier, there are no build re-runs because of issues emerging after the release and the milestone builds tend to be highly usable very early on. It's quite a lot better than our track record... Anyway, they call the development environment Jazz and some of the plugins are already publicly available and some others undoubtedly will be released sooner or later - I have to see if there's anything we could use.
I tend to choose sessions that are *really* bleeding edge and I don't have much knowledge about. I see no much point sitting in standard EJB 3 best practices or web application frameworks smackdown sessions as they don't offer me anything new or anything I couldn't just read on the web. So logically, I found myself in many Mustang/Dolphin (Java 6 / Java 7) sessions, one of them being "Dynamically typed languages in Java platform". This session was held by Gilad Bracha, obviously a _very_ senior engineer working on JVM development at Sun and leading some of the JSR proposals (Same guy that held the controversial super packages session the previous day). He has very dry, but entertaining humor, take these quotes for example: "So some people are asking why do we need these dynamic languages, and, because they've lived in this dark cave for all their lives, they have no idea of what they could do with them" or "and I proposed this several years ago, but customers weren't asking for it at the time... of course, entirely different matter is customers weren't asking for Java either, but sometimes the customer just doesn't know what's good for them". Anyway, a scripting/dynamic language support inside JVM is a good thing, and much less of a controversial topics as super packages are. I really like dynamic, untyped, late-binding languages, but after some years of LotusScript, JavaScript and ActionScript hacking, I do know their limits as well. Most of the dynamic scripting languages tend to be classless, prototype-based languages today, which I view as a good thing.
I had to go to "Advanced JavaServer Faces Custom Component Development", but I knew I'd be disappointed. People are hacking together some cool components, like SVG rendering for charts and bars - boy, it's a doom's bell for Flash - but overall, writing JSF components look like how servlets were done 10 years ago, outputting HTML directly from a servlet, or writing SQL without any persistence layer (JDO, iBatis, Hibernate). It works on a higher abstraction layer, but developing and maintaining the component code is a mess. XSL transformation approaching would have been a much cleaner approach, albeit likely slower.
DOJO session was next - Dojo is making its way to become the de-facto Javascript framework for server-side Java web application framework, both used in MyFaces subprojects and Tapestry. This is one of the key thing and problems with prototype-based languages: because they are so flexible, any object can change the run-time behavior of object ancestors and happily overwrite critical properties or operations. This is why a single (or only a few) framework that's good enough is so important for any high-quality Javascript implementation, much so than for a statically typed class-based language. It's also where Macromedia went so wrong with ActionScript 2.0 by adding class-like features into an inherentely prototype-based language. DOJO is cool.
In the evening, I attended the MyFaces party organized by Oracle and CA. Among others, even Craig the man, err, McClanahan was there, and of course a lot of other people I knew only through mailing lists before. It's nice to put faces on names. One of the topics I discussed with Craig, and complimented him on improvements in NetBeans (he's leading Java Web Studio Creator at the moment) and of course, we glanced off the touchy subject of Sun possibly ever collaborating with IBM on Eclipse. Craig's response was expected: "You know, for starters, they'd need to change the name" ;)
The last session of the day/night was Trails (starting at 10:30PM!), I just really wanted to go see it and meet the guy behind it. In short, Trails is domain-driven development model in Java along the lines of Ruby on Rails and NakedObjects, only better (subjective opinion of course, but because it combines best of breed frameworks already existing in Java).
Oracle opened the day with their keynote, and they naturally talked a lot about JSF. They made one new announcement about contributing more code to open source, a JSF/Javascript drag and drop framework they were demoing and then continued with BPEL, but I found the general session somewhat boring. At least for me, the session of the day was Gavin King's "Introduction to JBoss Seam". Java EE 5 implementation with some open-source but proprietary components as has traditionally been the "JBoss way". Gavin's a *really* good, entertaining speaker and I really enjoyed his talk complete with Spring and Struts bashing remarks. The biggest innovation in Seam is the notion of conversations - i.e. a transaction that spans through several requests but is not bound to a session. The EJB 3 persistence annotations together with an Entity manager is already a huge leap forward, but Seam just builds on top of that offerering a tight integration with JSF and because of the conversation scope, reduces the "boiler-plate" code for fetching and attaching the persistent business objects. As a simple example, in conventional JSF, you'd have a bean property to get / set an id of say, a user profile, then in "edit" action method you'd fetch the object, navigate to an edit page and in a save action you'd store the bean (values). The lifetime of the bean would be in a separate configuration. Now, in Seam you'd instead start a conversation with @Begin annotation in the get method, fetch the bean and end the conversation with @End in the store method. The scope and lifetime of the bean is managed with these annotation automatically and it eliminates the need for action binding, resulting in big reduction of lines of code you need to write.
Also, I attended "super packages" session, a possible new language feature in Dolphin. It's quite interesting and I can see many useful purposes for it, but still it spurred some heated discussion, because it's not absolutely necessary language feature, and frankly, I don't like the new "module file" compilation unit the current JSR is suggesting.
Another interesting session was JUnit for by Kent Beck, especially considering I had attended the TestNG session the previous day. JUnit4 annotations look pretty much the same as TestNG, so I suppose there's even less incentive in moving away from JUnit. One interesting thing he showed was an Eclipse plugin that runs your unit tests automatically every time you make a code change. Kent has some good points about unit testing in general, and that even though now everybody's talking about it, still a minority is doing it in practice. Still, Kent's unit testing dogmas, fast, flexible and completely isolated have always been controversial to me: Integration tests depending on the database and servlet container just cannot be run fast if they run in a complete isolation, starting up and stopping everything before and after every unit test. I asked about Kent's opinion on TestNG in which the isolation principle is somewhat relaxed, but he refused to comment on it. Software, like anything else is just big boys playground, and you sure can't go and take over somebody's elses sand castle.
I'm back at JavaOne after signing up at the last minute. And I'm quite happy to be able to attend JavaOne again this year. Really everybody who's anybody in is Java here. At the key note, you can clearly see the mobile push Sun's continuing (Motorola's on stage showing some new models) and at the moment, Java's has a pretty good momentum going for it. They showed some VB (Visual Basic) integration and talked about open sourcing the whole JVM, both obvious signs of Sun feeling very strong of Java's current position and market share. One worth number mentioning is that according to some stats Sun was showing, is that 41% of all Java developers are working on Java client applications. To me, it's surprising because Java's still not on the desktop and guess I've been working on the server side Java apps for too long.
I attended some Mustang/Dolphin (Java SE 6 and SE 7, respectively) sessions to gather some info on what's happening in Java's future. I'm actually much more enthusiastic about Mustan's features now, earlier I had been thinking that it too useful release. One thing that was complete news to me is that Sun will offer Derby (originally Cloudscape pure Java DB) as a bundle together with a final Mustang JDK release. That notion got me into attending a Derby session later that day. Some things that are meaningful for us is that Apt (Annotation Processing Tool) and annotation processing will be handled by standard javac - definitely a good thing. Another useful thing is improvements in ResourceBundle implementation, e.g a resource cache; improvements that are long due. The final Mustang release is just around the corner.
Also, I managed to get into TestNG session (Beyond JUnit), I swear the line to the session was half a mile long, never seen anything like it. Either there must be a lot of people interested in unit testing or unhappy about JUnit, or both. TestNG is quite interesting though: it fixes some of the annoyances in JUnit, is based on annotations and just does everything a little bit better than JUnit, but doesn't offer anything major over JUnit.
As said, I went to the Derby session because of the earlier Mustang session and I must say Derby is much better than I thought. I've used HSQLDB before and I thought it's pretty much comparable to it, but I've been wrong. They claim Derby's faster than MySQL on large data set and overall, it's both very mature, "commercial-grade" and small. At the presentation, they've positioned it as embeddable database and showed several demos of that, but it could do much more. Now I'm thinking this should be the database you deploy before running your db unit tests because being 100% Java DB, it's just so simple to do that.