Learn Once, Work Anywhere (with Choice) an impression of J-Fall 2005

On October 12th I have visited J-Fall 2005 conference of Java Usergroup Netherlands (www.nljug.org). There have been held many presentations, attended by a large public and it has been quite interesting. Amongst the contributions I noted a heavy weight by Oracle. ADF Faces received much attention by the oily marketing machinery – as we are used from Oracle. In this respect I found it a bit pity that Spring WebFlow stood too much in the shadow of ADF Faces by a lack of presentation power. Below I like to share some notes I made during this day, though these notes declined at the end of the day due to the massive stream of information.

The conference started with the subject Java Technology and Smart-Dust: Building Intelligent Sensor Networks by Simon Ritter. Smart-Dust is tiny, low power, wireless sensors that monitor the world. These mm2 – sized devices form a self configuring, self healing, and dynamic routing network. They can be applied for numerous purposes, like controlling the lights of a large office building (40% of the costs of running an office), earthquake warning systems, all kinds of security systems, manufacturing processes of industrial products, and much more… (See also www.spaughts.com). The reason why this technology was presented at J-Fall, is the fact that the Smart-Dust researchers experienced benefits by using Java to operate these devices. Using Java had increased the development speed up to four times faster than C. The Java VM protects the hardware. The VM makes it possible to abstract from lower level details of these Smart-Dust devices, which means – when I understand this correctly – that it makes no difference for a Java programmer if he or she creates code for a J2EE application or for embedded systems…
This last statement proves – according to Onno Kluyt of Sun in his contribution on Java Community Process – the validity of the adagio: Write Once, Run Anywhere, and also: Learn Once, Work Anywhere! An important factor of the success of Java is the development of standards. Because of standards one can easily integrate with .class files provided by others because it behaves as expected. This made possible network computing. Different software parts cooperate without ever having met each other. The Java Community Process has been very productive. Many Java Specification Requests have been completed.
In Java Server Faces – One Step Beyond, Duncan Mills of Oracle shared some key lessons from ADF Faces projects he has been conducting during the last year. Good practise is the use of style sheets and resource bundles. One of the key lessons is that one shouldn’t pollute the JSF code with: HTML, JSP/JSTL or EL. In stead one should keep a strict component determined page. For example, don’t use but in stead use the regular
. Duncan advises to have a one-on-one relationship between page and backing bean. Coding the JSF way means that the developer stays away from the Servlet. Because of Spring integration and state injection, constructions like getExternalContext().getRequest().getParameter() is no longer needed. In JSF validators can be added very easily. Same is true for converters, e.g. getAsString() or getAsObject(). Specified in an XML file, they can be applied on attribute-level or class-level. This is all simple. But what Duncan found out to be more difficult during his projects, is to create a list of objects. The way to go is to inject collections of objects in the bean (Spring-wise). Another difficulty that Duncan encountered was how to deal with the refresh from model problem. For this there was no regular JSF solution, so he had to refer to a non-JSF solution. In JSF 1.2 new event listeners will be supplied that address this issue. Another upcoming feature is the introduction of EL extensions that serve security purposes. There will be a new EL scope, namely #{securityScope}. It will be packaged in jsf-security.jar. Another interesting subject is facelets. More info can be found at www.groundside.com/blog.
Another very interesting presentation that I attended was Profiling Your Build by Erik Wiersma of JTeam. This dealt about the process of software engineering. It especially focussed on the cycle of (i) compilation; (ii) deployment and (iii) test after code changes have been made. During a very simple example project involving a database and a mail server, these steps were timed. The total performance of the cycle was 73 seconds. By elimination of container dependency (decoupling like Spring), the correct use of unit tests (use of Mock objects in stead of integration tests) and use of the IDE to just test the modified code only, this could be reduced to 3 seconds, which is about 4% of the original time.
This was followed by a steamy presentation by Ted Farrell of Oracle called Productivity with Choice, which is also the slogan when you start up JDeveloper. Ted provided nice demos of JDevelopers possibilities and its flexibility and choices that are available to the developer. I especially liked the demo of EJB3 and the demo of the rendering kits. A very cool UI was showed in which the end-user does not need to follow the classic sequence of wizard-dialogues, but enter all on the same page. A real time changing graph (on the same page too) was also quite impressive.
Then Spring Web Flow by Steven Devijver of Interface21 came along. This subject is one of my favourites. It was bit pity however that Steven was running out of time during his presentation. He started to elaborate on the role of page flows. A page flow mirrors a business process. According to Steven, implementation of workflow constraints is often a painful process in classic MVC frameworks. In Spring this is easy (though I forgot to note why). Important and interesting difference with the classic frameworks is that in Spring it is possible to re-use page flow! Workflow is defined declaratively in a XML document:

It is possible to define and re-use subflows!
I was also very curious for the last presentation that I attended, namely An Introduction to JSR 227 by Duncan Mills. This contained a very clear explanation of the model layer in ADF Faces. Between the data services and the View/Controller layer there is the mysterious layer called Model. JSR 227 has been introduced to re-organize the messy stuff here. It was messy because conversations had to be set up with distinct types of data services, like EJBs and web services for example. Different providers require a different approach. JSR 227 provides a standard data access and data binding facility for J2EE. When developing a view component it is no longer needed to worry about the question how the data is stored et cetera. The new layer that is introduced by this decoupling of the data service, consists of two sub-layers (which in its turn repeats again the MVC model on this level), namely (i) data controls and (ii) data bindings. Data controls are abstract definitions of the data services. It consists of interfaces which are implemented differently for the diverse types of persistency. They provide hook points for: meta data like field labels and hints, declarative validation and security. Data bindings: each view unit (page, panel or region) can have its own binding container, which is a map of bindings. There are different types of bindings. The bindings will be packaged in javax.binding.