On the Rails Again
Back from JavaPolis, and seeing the Rails book lying where I’ve left it last Tuesday, made me pick it up and continue reading — instead of looking into GlassFish, the new persistency API, JSF and all the other new stuff I’ve seen in Antwerpen. It’s all alpha, beta, preview releases; and even if it isn’t it’s still so far away: Jeroen (colleague also attending JavaPolis) and I figured we’re lucky if we’ll be able to use Java SE 5 in our daily work (read: in BEA WebLogic) by the end of 2006 (when Mustang, Java 6 is already out), and Java EE 5 by the end of 2007 (when Dolphin, Java 7 is out). Two years and two more Java versions before we can use the technology we’ve been presented this week! So I’ve more or less lost interest momentarily and gone back on track with Rails.
There was very little mention of Ruby at JavaPolis. None of the people I spoke with had actually done anything with Ruby. What I did see:
- Graham Hamilton, Sun VP, announced in his keynote on Thursday that Java 7 may support ‘new JVM bytecodes for dynamic languages like Ruby’. This would make it possible for Ruby code to be compiled into JVM bytecode.
- A lot of presentations I saw, about Java EE 5 (GlassFish) but also for instance about Spring, stressed that everyone now focusses on EoD and ‘code by exception’, meaning: only having to code the exceptions to the default behaviour. For example, take the new persistence API (which is to be decoupled from the EJB3 JSR). Coding a persistent class is now as easy as adding two annotations: one (@Entity) to specify that the class is persistent, and one (@Id) to specify the key field. By default, the table name is assumed to be the same as the class name, and the column names to correspond to the class field names. You do still have to include all field declarations and getters and setters in the class. And why, as Jeroen asked me, didn’t they take one extra step to assume the key field is named ‘id’ in the database?
Of course, code by exception is not something exclusive to Ruby on Rails, but I did think it’s nice to see it’s becoming quite a trend in the Java world also. - Then there was a meters long whiteboard with the Java timeline, starting with the inception of Lisp in the 50s, up until 2005 and beyond: the future of Java. Someone had written a wishlist for Java’s future, including dynamic typing and method parameters. Method parameters was actually mentioned by Graham Hamilton as a possible addition to Dolphin (Java 7), so there is hope. We’ll only have to wait until 2008…
- And a nice visual joke that only few people seemed to pick up, in the presentation by Thomas Huusom Christensen on ‘Zero Calories J2EE’. He told about his company’s search for the best minimal set of Java frameworks to use in their new projects. He then showed a slide titled ‘Still we clearly need a trim’, with a photograph of two stacks of books: on the left, a huge pile of books on Java frameworks; on the right, only two books: Programming Ruby and Agile Web Development with Rails. Too bad the presentation is not yet online, I’d love to show the photo here!
[Edit] Thanks to Rick Bradley (see comments) for providing the link to the photo I mentioned:
It’s not a completely fair comparison; Fowler’s pattern book should be on the right stack as well; although on the left side you could add books on Spring and JSF. And it still is a great photo to show at a Java conference!
2005-12-17. 8 responses.
Thanks for the update. Glad to know there is progress in Java-land.
Danny,
The picture you’re looking for can be found at http://www.garbett.org/?q=node/25 . My coworker, Shawn Garbett took that photo when we finalized our decision to move from Java to Ruby on Rails for our so-called “enterprise” project. If anyone wants to buy some Java books, cheap, drop him a line.
Best,
Rick
What are ‘Method Parameters’?
[…] Danny’s Blog has some good perspectives from a Java guy who just went to JavaPolis, but who is also On the Rails Again. He did pick up on a general meme of EoD: […]
Gary,
Method parameters is when you can send a reference to one method as a parameter to another method. The second method can then call the first method, without knowing beforehand which method that is. In C and Delphi you could do this by passing a pointer (memory address) to the method. In Java we don’t have pointers, so there would have to be some way to reference a method.
I’m not sure how this is done in Ruby, by the way (should have bought the language book ;-)). It’s possible to pass a block of code to a method (see Programming Ruby), and that block could contain a method call; but that’s not quite the same as a method reference, in my book. But don’t ask me, I’m a beginner with Ruby. Any of the experts know more about this?
Yes, credit for the excellent photo goes to Garbett. It points out all too clearly that we in Java land either how a long way still to go or are backing up the wrong tree.
Cheers
Thomas
[…] In Thursday’s keynote, JavaPolis founder Stephan Janssen asked whether JavaPolis should grow even bigger, and because of that, move to a bigger location. According to the official site this year over 2100 people attended the conference. I don’t think there’s a clear answer to Stephan’s question. JavaPolis had a very friendly, cosy atmosphere; I never had the feeling there were 2100 people around. All the stands were well accessible, there was always a seat left even in the most popular sessions. Maybe 2100 is just right. On the other hand, if JavaPolis really wants to be ‘the European JavaOne’ (as I’ve heard people say more than once) I think it’s not nearly big enough. I would expect much more sessions, high-quality sessions even on Friday (see below), more big names in the speakers department and a bigger exposition room with more companies and bigger stands. I wouldn’t mind paying a little more either if it were that big. Friday, the final day of JavaPolis, was a bit of a letdown. The exposition room was being cleared, the buzz and the excitement were gone, we were just a bunch of stray people in the three remaining conference rooms. I saw two interesting presentations: * Web service architecture, highlighted some best practices in designing _and_ maintaining web services, like: ** “Keep your XML schemas simple, because not all implementations implement all schema features the same way”; ** “Favour a coarse grained web service definition, because of the high cost per call”; ** “ESB allows you to use existing components (EJBs) as if you have a SOA; usefull for a transition to SOA but it won’t take you all the way”. * Zero-calories J2EE: about a Danish company’s (Nordija) research into setting up a standard framework using Spring, Hibernate and Tapestry. I couldn’t agree with all their advise, like using domain classes containing business logic instead of data transfer objects to communicatie with the web tier; or identifying objects not by their database id field (because that’s empty until you’ve committed) but by some other identifying attribute or combination of attributes; by the way, Martin Fowler has an extensive discussion of this seemingly simple matter of identity fields which is worth reading. But I appreciated them showing that photo! […]
The online keynote from Graham Hamilton is now online @ http://www.javapolis.com … enjoy 🙂