JavaPolis: Great conference!

I am back again from JavaPolis 2006. It has been a great conference. Belgium is always worth a visit if you like good food, chocolate and beer but JavaPolis is definitely also worth a visit.

The contents of this year's conference was really good (although I have already complained about the lack of Eclipse content :-) ).

The JavaPolis team had improved a lot on the practical matters:

• Short breaks had been scheduled between the conference sessions so that it was actually possible to get from one room to the other in time


• The speakers were kept on a tight schedule - they weren't allowed to exceed their time slot


• The food was a lot better and in adequate supply


• There was wireless internet (although the quality was questionable - they already know this...)


• There were tables with power outlets where you could use your laptop in the breaks

I have a few suggestions for next year's conference:

• Set up LAN cables at the tables. This might lower the load on the wireless network


• Clearly state in the conference program whether a speaker represents a product. I attended (at least in part) several sessions which were in fact product presentations in disguise (the talks were not on the Partner track where this is to be expected). This is quite annoying! It is OK when you know in advance what you are in for (I saw an excellent presentation on Adobe Flex).

Thanks a lot to the JavaPolis team for a great job!

JavaPolis: Where is Eclipse?

I'm a bit amazed to see the number of sessions on Eclipse on this year's JavaPolis.

A search through the conference guide shows three sessions which include the word Eclipse in the description. Of these, two are product presentations on JBuilder 2007 and the Adobe Flex 2.0 development tool (which are both built on Eclipse). The third is on a framework based on Eclipse RCP. Erich Gamma might be expected to mention Eclipse in his keynote on Thursday.

Apart from these sessions there is nothing on Eclipse. I know that there are conferences specifically on Eclipse (EclipseCon, EclipseWorld, both in the U.S., and Eclipse Forum Europe), but still I would have expected to see more Eclipse related content on a general Java conference.

Considering the amount of work taking place in the Eclipse community and the number of projects (a quick count shows ten top-level projects), I wouldn't say that everything has been said on the subject. OK, maybe I'm just a bit disappointed...

JavaPolis: Dynamic Languages Are A Hot Topic

Apparently, dynamic languages in Java are a hot topic. At least if you judge by the size of the audience in the JSR223 - Dynamic Languages on the Java Platform University talk at JavaPolis today. The room was quite packed with people.

The talk was quite interesting. Geert Bevin did the first part on scripting features in Java (he claimed that he was just a stand in for someone else who had made the slides - he did a good job anyway.) Charles Nutter and Thomas Enebo presented their work with JRuby and presented a short demo with JRuby on Rails which is pretty much up and running. Finally, Dierk König presented some of the features in Groovy which is finally approaching its 1.0 release in the end of December - this year :-).

It is interesting to see the movements in dynamic languages on the Java platform. With JDK 6 just released, scripting (in the shape of Javascript) has been integrated into and comes bundled with the JDK itself. More scripting support is coming in future versions of the JDK. It is clear that Sun is putting some focus on the matter by hiring the JRuby guys. As they mentioned, currently they're working on JRuby but in the future they might on scripting support in general.

The ability to actually run Rails in a JVM is also quite interesting. This might make Rails more acceptable for some organizations which would never allow something like Rails on its production environments. When deployed on a Java application server it is basically just Java. Furthermore, JRuby comes with a database adapter for JDBC which adds database support for even more databases than Rails itself. As Thomas and Charles mentioned, you can now run Rails on a mainframe - quite an interesting thought :-)

Groovy is also an interesting language. I have used Groovy in small scale for some time now and have been quite happy with it (apart from the many changes since its inception). Groovy has the advantage over JRuby (and most other scripting for Java) that it is much more Java-like. Also, the Groovy scripts can be compiled into Java classes which allow them to be used from Java code without you noticing it. JRuby doesn't have this ability yet (although the feature is planned.)

There is a talk on Grails on Thursday that I consider seeing. I could hope that Groovy will get the same momentum with its companion web framework, Grails, as Ruby has had with Rails (although I doubt it.)

Quickmarks v3.0.2 released

I have just released a new version of the Quickmarks plugin for Eclipse 3.x. This release is purely a bug fix release, correcting two bugs (#1033426 and #1413468) that have been there for almost two years. Finally, they're out of the way... :-)

The new version has been tested on Windows XP with Eclipse 3.0.2 and Eclipse 3.2.

The new version of the plugin can be downloaded here: Quickmarks plugin

Stripes - a lightweight web framework

During my continuing search for alternative web frameworks, I came across Stripes some time ago. It looked quite nice and has even gotten nicer with the recent release of version 1.2.

What I like about Stripes is that it is simple. It may not be the perfect web MVC framework capable of anything, but for most simple (and I don't mean simple as in trivial) web applications, it looks good.

Stripes has practically no external configuration. Most of the configuration (and not much is needed) is written as annotations in the ActionBeans (which, by the way, do not have to extend a specific base class). For instance, the @UrlBinding annotation on the class states the URL, the action is bound to. The @DefaultHandler annotation on a method specifies that this method should be invoked if a specific event has not been specified. The @HandlesEvent("eventName") registers a method that should be used to handle the eventName event. Of course, it does add a number of @annotation elements to your code, but due to the simplicity of the framework, it won't be so much, that it renders the code unreadable.

Stripes has the basic features you would expect from a modern web MVC framework (the items below are just a subset of the functionality. For the full list see the Stripes documentation):

• Validation. There are a number of standard validators (annotation driven) and you may write your own validate method (which will be called if you implement the Validatable interface


• Type conversion from HTML input elements to Java objects


• AJAX support. There is built-in support for calling methods on ActionBeans from AJAX functions


• Localization


• Reuse of layouts. A templating mechanism allowing you to get a uniform layout without duplicating a lot of code


• Integration with Spring. Adds the possibility to get dependencies injected into ActionBeans from the Spring context.

Version 1.2 has added a number of nice new features (among other things):

• Wizard forms. Handling of the very typical usecase of wizard style dialogs.


• Flash scope. The ability to support the redirect-after-post pattern while retaining the parameters from the post.


• Smart defaults. A new feature in version 1.2 enables Stripes to automatically determine the URL bindings based on the class name and some default naming conventions

Stripes does not attempt to deliver lot of functionality outside of the core framework. There is no CRUD functionality, no support for sending mails etc. However, I don't see this as a negative thing - you might not need it.

One minor drawback is that Stripes requires Java 5, which may not be an option for you (if you use Websphere, for example). But then again, why not try to go with a simpler set-up in that respect too :-).

In conclusion, Stripes does seem to deliver on the functionality that is actually included. I'm really looking forward to see, how Stripes will progress in the future.

The Problems Of Reuse

Danny Lagrouw has commented on a blog entry called Reuse is vastly overrated by David Heinemeier Hansson. Basically, the conclusion is that often reuse is simply not worth the struggle.

I couldn't agree more. I have seen so many examples of efforts of trying (too hard) to "design something for reuse since reuse will save us so much time and money". Designing something to accommodate for future business requirements is extremely difficult since these requirements tend to be changing rapidly. You almost never know in advance the exact requirements of future uses of your code.

There are several problems with designing for reuse:

• Trying to design for generality in advance typically leads to overdesigning in a very non-XP way. This in itself might increase the costs of developing the general solution which can then be reused.



• There are always little twists which make two seemingly similar usecases different. These little differences tend to make the general design jump through loops in order to cater for the differences. It typically makes the general code less easy to read and maintain due to the handling of the differences and it definitely adds to the costs.


• Even when to usecases are similar when developed, I have seen many examples of business requirements "drifting apart", requiring the general code to adapt to the new gap between the usecases. Adapting to changes in one usecase may prove to be difficult as the changes apply to the general code. You need to be really careful with changes to the general code as it affects all the implemented usecases. And we're not even talking by the extra efforts in testing, since all the implemented usecases must be re-tested.
  

This is not an excuse for not creating quality design. I'm not saying that you should just copy-and-paste your way through the application - the DRY principle (Don't Repeat Yourself) still holds. However, I think it is important to really think carefully of whether reuse is feasible and find the right spots to reuse.

WebWork 2.2 released

WebWork 2.2 has just been released. I'm really looking forward to see the progress in Struts Action Framework 2.0, now that the WebWork developers have gotten this thing out of the door.

Nominated for Top Contributor Eclipse Award

This is so cool!

I just discovered that I have been nominated for the
Top Contributor Eclipse Award.

While I hardly think that I'll win the prize since the other contributors mentioned in the Bugzilla entry deserve far more recognition than me, it's still really nice to feel that people value my work (even though it's some time since I released any changes to my plugins).

Why does it have to be so complex

I know, it's been said so many times before... But why does web development with Java EE have to be so complex?

I have previously worked with EJB 2.0 which felt like a pain... The turnaround time was horrible (the compile, deploy, test process took about 2 minutes). And it felt especially bad since most of the functionality offered by EJB was not even necessary for the project. It was a great relief to switch to another project where Spring Framework was being used.

Still, however, the complexity of doing simple things is rather high. At my current project, we use Struts, combined with a homegrown framework (which itself adds to the complexity while adding some functionality). Adding a new page involves so much XML configuration and boilerplate code that you wonder when you're going to do some real coding.

This is one of the main reasons why I have been smitten by the Ruby on Rails bug.

I think Rails has a sensible, pragmatic approach to web development. As David Heinemeier Hansson has often stated, Rails is not everything for everyone. The purpose is not to fulfill all needs for every possible web application but rather to ensure that it makes life easier for the bulk of applications. IMHO, this is a very healthy way of seeing things.

I think many Java developers -- myself included, although I'm working on it :-) -- in general have a tendency to want to do everything the "right way" from the beginning and always with the approach that "what if the customer/framework user/etc. want to do this in the future..." This is so non-pragmatic!

I think a problem in the Java world is that there are simply too many options. I like the fact that Spring is able to integrate multiple APIs for the same purpose (ORM APIs, for instance) with a more or less common interface. I know that these APIs fill different niches on the ORM market (perhaps quite large niches), but it just adds to the complexity. Sometimes it would be easier to stop and think whether you really need it all. As Java developers we have a tendency to want a framework be able to do everything for everyone, preferably being configurable (in XML) for any possible situation. I don't think this is a bad thing in itself, it just complicates matters. There is no way this is ever going to be simple (Anders Hejlsberg calls the phenomenon simplexity when you try to take something complex and try to "pretend" that it is simple by wrapping it in something simple).

One of the extremely nice approaches in Ruby on Rails is the focus on "Convention over Configuration" (i.e. using defaults as long as you adhere with the conventions, eliminating the need for configuration). This is so obvious and yet so powerful. Very often, I have had the feeling that I'm just repeating something that the framework should have been able to figure out itself. Basically, the use of "smart defaults" could eliminate so much of the configuration (if not all) as well as a whole lot of boilterplate code.

So far, I have only used Rails on a small pet project, but it really feels right. The defaults chosen by the framework are sensible and intuitive and really makes developing web applications more fun!

I really hope to get an opportunity (i.e. an excuse) do some Ruby on Rails development on a real-life project so I can see, whether the promises and my initial impressions still hold true.

In the Java world, I'm pleased to see that the focus on simplifying things is increasing. Spring 2.0 will bring a simplfied syntax for a number of typically used configuration cases (such as JNDI lookups, transaction configuration and AOP pointcut definitions). Also, they are focusing on adding smart defaults for obvious settings.

A project I intend to follow closely is the new Struts Titanium (Struts Ti) which is the "merger" of the WebWork framework with the Struts framework (in reality, it is basically a rebranding of the WebWork name). What is interesting, beside the fact that this completely different implementation of Struts should still be able to support legacy Struts web applications, is that the team is focusing closely on simplifying development of Web applications along the lines of the Ruby of Rails framework. There is much focus on intelligent defaults based on naming of actions, pages etc.