Well, it’s spring again, so time for another NLJUG J-Spring event! The NLJUG J-Spring/J-Fall is the biggest Java event in the Netherlands, a one day conference held in Bussum. I am a regular visitor on this conference, interesting sessions, a good indication of the Dutch Java scene, and it’s great to meet up fellow Java developers again. The conference was “sold out” (entrance is free to NLJUG members), but because it was nice weather outside, it was less crowded inside during the breaks than usual.

Data Context Interaction

For me, the conference started out with a talk on “Data Context Interaction” (DCI). Basically, this is supposed to be solving the problem that “typical” object oriented (OO) design mixes all kinds of stuff inside your domain objects. DCI completely separates each interaction, using simple techniques like a decorator, or a full-blown new programming environment called Object Teams (unfortunately, only the latter was demonstrated). I had a bit of trouble with the initial problem statement. In “good” OO principles (like SOLID, for instance), mixing unrelated stuff in the same object was already considered very bad! I agree with the stuff DCI proposes, but I do OO design this way in plain Java for years already, without needing fancy new languages or confusing new acronyms. As a research effort though, I am really interested if something useful will evolve from this new emphasis on a cleaner separation.

Web Beans

Next was a talk on the JSR-299 “Web Beans” specification. Basically Web Beans is the best of Guice and Seam (both inspired by Spring), mixed together in a single Dependency Injection standard. This talk was a real meat grinder, the speaker had little mercy for any listener that did not have intimate knowledge of Seam/Guice, and crammed the entire spec in the talk (and the spec is pretty big). Fortunately, I did know enough about Guice and Seam and managed to keep up the entire session. Web Beans will be great when it’s done (no date is set on that, but not likely this year), especially if it works on Java SE as well. It’s a nice clean spec so far: easier than Spring and Seam, more powerful and complete than Guice.

Pragmatic Model Driven

The revival of model driven development was apparent on this J-Spring too. Jos Warmer did the afternoon keynote on a new framework called Mod4J, which is basically an out-of-the-box DSL and code generation tool to work model driven using predefined DSLs. Another talk by Richard and Tony in the afternoon relied on a more low-tech technique by using out-of-the-box Enterprise Architect capabilities in conjunction with Freemarker templates. Both approaches each have their pros and cons, but both did model driven only for the simple boilerplate code, no ambition to replace coding completely, or rely on very abstract models written by non-programmers. Very interesting stuff, meta-models seem pretty easy, especially in Enterprise Architect, so basically, this stuff relies on easy to understand code generators to be accessible to the average programmer. I talked a bit with some of the model driven guys, but since they have been investigating and experimenting with this stuff for years, to them, everything seems easy.

The demise of the Swing JSRs

Finally, I visited a talk on the JSR-296 “Swing Application Framework” spec, by Karsten “JGoodies” Lentzsch. Karsten is a great presenter and a real Swing guru so I never miss one of his talks. This talk was especially interesting though, because although he did explain the spec, he basically said that it was dead. Sun re-prioritized on JavaFX, and abandoned some important Swing JSR specifications. According to Lentzsch, you’d be better off right now if you roll your own framework for serious Swing applications instead. It’s surprising to hear a member of a spec expert group say: don’t use this spec! Refreshingly honest though, which is loads better than hollow promises of Sun on this subject.

Still, the JSR is a great inspiration for solving common problems, although Karsten pointed out some things he did not agree upon (like resource bundle injection). Karsten did say some nice things about Eclipse RCP too, stating that as the only real alternative for plain Swing for now, interesting to hear from a Swing guru (both Netbeans RCP and JavaFX were mentioned). Finally, he did mention the Eclipse JFace data binding too, as a cleaner and more powerful alternative to the JSR 295 “Beans Binding” spec (dead now, too). Since JFace data binding is pluggable, it can be used outside Eclipse as well, and Karsten mentioned the UFace project (Swing and GWT bindings) as something very interesting to watch in this space. UFace, though, has not released any downloads as of yet, so right now, you have the choice between a JSR that is dead, a new generic framework that is not yet available, or just plain old JGoodies for Swing data binding.

All in all, an interesting and surprising day at J-Spring. See you next J-Fall!

5 thoughts on “J-Spring 2009, full of surprises

  1. I unfortunately missed the talk on JSR 296 because another talk had a higher priority. My idea when reading about it is that is an interesting improvement for Swing apps, but that it is only a very rough application framework that does not provide much extra functionality especially compared to Eclipse RCP.

    It is interesting that a Swing guru should recommend Eclipse RCP. Does that mean he thinks it is better than Netbeans RCP?

    For our project we will need to make a choice for a framework that is easy to use for our end users and being able to use Swing (which has a larger tool support than SWT) would be useful.

  2. The reasons Karsten mentioned were maturity and user base, where Eclipse RCP is better documented, more examples, and more users. Where Eclipse RCP is used by major companies, Netbeans RCP is not used as much for very large applications. This is especially true in the German market where Karsten is coming from.

    Also Karsten took into account the position of Sun as a company at the time. When Sun would be bought by IBM, this would mean the end of Netbeans (IBM is a heavy user/inverster in Eclipse). Now that Sun is bought by Oracle, Oracle has three tooling stacks, and will likely need to make a cut as well.

    Info Support does both Swing and Eclipse RCP projects. Eclipse RCP has impressive tool support for the platform when building modular clients (using plug-ins), but can be a daunting platform to use because everything works using extensible abstractions. Swing is built-in into the Java runtime, and has better features for custom graphics.

    If you are looking for tool support for drag-n-drop design tooling, take a look at WindowBuilder: http://www.instantiations.com/windowbuilder/index.html

    They offer great tools for both SWT and Swing, with a much more flexible tooling strategy than the Netbeans designer uses.

    If you’d like to talk some more about this topic, feel free to drop me a note using the “Contact” option on my blog, and we can discuss this by e-mail or phone.

  3. Hmm. Whether or not IBM had bought Sun, NetBeans would continue to exist… since it is an open source project that many VERY large companies depend on!

  4. Hmm, interesting to see these kind of pinpoint reactions to isolated out of context “anti Netbeans” sentences, half a year later. Also, please don’t call me (or Karsten Lentzsch) an idiot without anything more than a link to generic Netbeans propaganda. I will remove such comments in the future.

    First of all, the above comments are not meant as an attack on Netbeans RCP as a platform. I have the “Netbeans RCP” book at home, I built some examples with it, and it basically is all just a bit easier and nicer to use than Eclipse RCP. Of course, some things are better in Eclipse RCP too, overall, there is no clear winner when it comes to basic use and capabilities today.

    Sure, Netbeans is used a lot as well, and would still exist based on community effort. Without the strategic leadership and contributions by Sun, however, Netbeans will not able to stay current for long, in competition with Eclipse, .NET and other solutions. As I see it, there is no other software company that would take over strategic leadership and/or the major contributing role of Sun. If you would know which company would, please tell me. Likewise, I would think that Eclipse would have major issues if IBM would decide to step out. IBM however, based all its products on Eclipse, ranging from Websphere to Lotus to Jazz.

    I genuinely share the frustration of Lentzsch that Sun is dropping the ball on important desktop capabilities like a basic application framework and databinding. Although Karsten warned in April that JSR 296 was dead, Sun officially dropped it only weeks ago. It is evident that Sun cannot power innovation in both Swing and JavaFX at the same time, and is choosing the latter. At the same time though, Eclipse RCP is moving forward with data binding, forms support, enhanced web browser integration, provisioning and proxy/security support. Microsoft is picking up the pace with WPF and Silverlight. And Swings best option is still a one-man job performed by a crazy German that you guys call an idiot for speaking reality.

Comments are closed.