Atlanta Java Software Symposium: The Anti-EJB
I'm sitting in Hartsfield Airport, waiting for my flight back from NFJS Atlanta and trying to patch together a somewhat exploded brain. Once again, the best parts of a conference are the hallway conversations and the bar conversations afterwards. Nothing completely new came up (though details of a lot of things I had seen on the periphery and have been on my to-do list to investigate) came up. The feeling of the conference is the brain exploding bit, and the after-hours conversations. So to try to hit the high and interesting points.
The first feeling coming out of NFJS is if the adage that "what doesn't grow dies" is true, Java is dieing. It will be "dieing" like C++ died in the 90's. It will have a long and productive twilight and eventually reach a Cobol-like senescence I am sure, but it is expanding (in the waistline), not growing. The theme of the conference could have been "How to be productive despite J2EE (and a few well aimed shots at Tiger)." At least half of the sessions were on abstracting, fleeing, dealing with, building, etc deployment descriptors. The other half were on how to program well. The former were great sessions on using cool open-source tools. The latter were frequently direct, or thinly veiled, Ruby adverts. I know of at least two attendees who went home Saturday night, downloaded Ruby, and came in Sunday morning as converts. Go Ruby!
Digression really quickly. Multiple people observed (so many it was like a blog-meme in real-time where everyone pretends to have invented the idea) that the primary thing the presenters/panelists/etc were saying was "OS X and Ruby are where it's at." Dave Thomas (Pragmatic, not chickens) and Stuart Holloway were the most forthright about this. The OS X thing came from the fact that they all (but two) toting around their TiBooks. Digression over.
Java does offer a more full, and easier to staff, environment so despite my agreement that Ruby is where it's at I am not giving up on Java quite yet. Call me stubborn.
Looking at the first topic, that half of the sessions were on how to get around J2EE and be productive despite it, I think that Bruce Tate has the best approach -- focus on the alternatives. He is, apparently, a big Spring and Hibernate fan. I introduced him to Apache OJB (we need to get more press) and am working on converting him. It will probably be tough as Hibernate is riding a popularity wave at the moment, and popular frameworks sell books -- which he writes. Anyway I had a few discussions, and need to continue offline, about the real value-add that J2EE gives you. Or rather, what people are trying to get from it. The conversation that started there spread through most of the conversations I had with people through the conference.
I have a lot of thoughts on "Faster, Simpler, Better Java^H^H^H^H^H Programming" (to paraphrase Mr. Tate viciously) and how to do it... and help others do it. They are digesting now, but they are coming eventually -- each of the points is addressable, but apparently finding all the pieces is not easy yet. Another itch, great.
As I am rambling, back to the top idea. Languages, in any form, peak and wane. They can be spoken languages, programming languages, any type of language. As long as the primary problems being addressed are best addressed in a given language it is the lingua franca of the field. Java is the lingua franca of enterprise development right now. C# is too little too late. It is revitalizing Java (pushing metadata out of XML and XDoclet and into the language, mostly) but that is about it. The lack of competition allowed the JCP lack-of-design-by-committee to flourish. Competition now favors the open source tools that emerge, flourish, spawn new tools, and become "Struts." (Digression, Struts is already passe for the "in" Java crowd, how absurd is that?) Open Source holds onto bad ideas almost as tightly as proprietary vendors, but OSS software produces offspring, copying ideas and code much faster. Entity Bean -> Cocobase -> TopLink -> Apache OJB/Hibernate (and JDO, which is as bad in a lot of ways as everything else coming out of the JCP).
Java isn't growing, it is just getting fat. Many new "features" aren't even features. As Dave Thomas said, how many @ClassCastException@'s do you get coming out of a Collection? If you know the difference between a Hashtable a HashMap and a Map then the answer is none. Someone who is very not-careful will prove this wrong, of course, but adding uglier templating to Java than even C++ has isn't going to solve a single real problem. Wheeeee.
What's growing? Ruby, Python, Java as platform (not the language). The scripting languages need no explanation. The Java as platform might: the most real innovation happening in Java is not happening in the Java language, but in other languages that run on a JVM. AspectJ is the best example here.
writebacks...
Hi Brian, Would you be interested in OJB support within the Spring Framework? I'm responsible for the Hibernate and JDO support in Spring; I would be pleased to assist anybody that attempts adding support for other O/R mapping tools. As a starting point, you could have a look at the current Hibernate support in the org.springframework.orm.hibernate package. Basically, this would mean creating an OjbTemplate class with an OjbCallback interface, offering IoC-style resource handling and conversion of exceptions to Spring's generic DataAccessException hierarchy. An OJB transaction strategy (implementation of Spring's PlatformTransactionManager interface) and support classes for setting up OJB resources in a Spring application context (a la LocalSessionFactoryBean) would complete the effort. Juergen
Hmm, emailed your sf.net account. Bruce Tate convinced me (wasn't too hard) to take a look at Spring. Will chat offline or on Spring mailing lists.
I'm pleased to see that you're interested! Haven't yet received your email to my sf.net account, though. I'm looking forward to seeing you on the Spring user mailing list or one of the forums! Juergen
There does seem to be increasing convergence to * a need for a simplification of J2EE for application developers (e.g. PicoContainer, AOP stuff etc) * pushback on the complexity of Tiger * a need for a simpler, powerful scripting environment While I really like Ruby (apart from its Perly bits), I'd also like the Java platform to have a great scripting language of similar style to Ruby / Python which avoids us having to switch platform and throw all the great reusable Java code away. Its with that in mind that the Groovy project started - an effort to get all the benefits of a rich & powerful scripting language like Ruby but running on the Java platform reusing existing Java code. http://groovy.codehaus.org/ Its still early days in the project but already we've a groovyc (like javac but for groovy) which can generate java bytecode for Groovy source files with support for closures, auto-boxing, nice for loops, concise syntax for lists & maps and GroovyMarkup for working with structured data like XML, Ant tasks or Swing UIs.
James, I didn't realize Groovy compiles to bytecode as well as being interpreted. Hmm. That is *very* powerful. Now, if it can do Lisp/Python style not caring about what is compiled and what is interpreted that will be awesome. Methinks I need to go download latest CVS of Groovy and start playing.
comment...