Looking back

A lot has happened in the last 5 years in the Java EE world. Developing EJB 2 applications was really hard and as a result a lot of opensource projects appeared addressing these problems. In particular, Spring and Hibernate had a lot of influence. 

Spring initially had a clear philosophy of using dependency injection/inversion of control instead of using lookups and singletons (the (in)famous JNDI in EJB2), and of separating the platform from the implementation of the functionality. I.e. no longer tying business functionality to platform interfaces such as SessionBean and EntityBean.

Hibernate on the other hand solved a lot of problems with entity beans, allowing a more object-oriented style of development supporting persistence of (almost) arbitrary structures of objects. Together, Spring and Hibernate identified a lot of pain points in EJB 2 and greatly improved testability and productivity in Java EE. 

Current state 

Now, Java EE standardisation has incorporated many ideas like using dependency injection and Java Persistence API, the latter of which is basically the standardized Hibernate and Toplink API. 

Unfortunately, it remains to be seen whether the situation has now really improved. In particular, Spring has become sort of a one-stop-shop for applications and has become a big utility library. In practice, many companies are now really tied to the Spring framework since they use it almost everywhere for everything.

In the Java EE standard there is now EJB 3 which adds dependency injection through some annotations and (optional) XML configuration. Nevertheless, this is also not such a big improvement. In particular, testability of session beans in a standalone environment (one of the main triggers for what happened in the last 5 years) is problematic. Also, from a maintenance point of view, it is difficult to get a grasp of a given EJB 3 application because it requires looking through a lot of different source files to see how the application is tied together. Spring in this regard is more explicit but this quickly leads to a big XML configuration that is also difficult to understand.  

Taking a step back, Spring and EJB 3 are trying to solve the same problem of programming to interfaces. In other words, at a particular place in the software I want to use an interface without knowing the implementation and the framework somehow injects the implementation where the interface is expected. This is a generic problem that is also being attacked by other IOC containers like pico container and Guice. 

Some of these frameworks have big marketing engines behind them, such as google's guice, and as a result that framework is also gaining some popularity. Admittedly, Guice and picocontainer are a lot simpler than Spring and a lot more focused in the problems they solve. The unfortunate thing is that these frameworks all work well with a singleton type of approach where, for a given interface, there is precisely one implementation. 

Trends, component based development

In parallel, however, it looks like OSGI is gaining a lot of popularity. In particular, there is now a spring source application server based on it, Jonas uses an OSGI kernel, Glassfish v3 will be based on OSGI, IBM Websphere 6.1 uses OSGI, BEA is also using OSGI for some of its products and is investigating integration in its application server, and JBoss is also going in that direction. Not to mention of course Eclipse which is built on Equinox, an OSGI R4 implementation. 

I like the component idea. Basically, a component provides a number of interfaces an requires a number of interfaces. Then in a given running system, the provided and required interfaces must be linked together to form an application.  A component in this case might be realised through various objects. For example if a component provides two interfaces, then these interfaces can be provided by two distinct objects that are part of the component. As a special degenerate case, supported by existing IOC containers, this corresponds to a single object that implements both interfaces.

Of course, OSGI also allows different versions of the same component to be deployed at a given time in a system. This concept provides a lot more flexibility than an all Guice or all Spring application. In particular, subsystems can be realised as Guice or Spring applications but exposed at a higher level through OSGI bundles or components. In this way, a big monolitic approach where an application has to be all Spring or all Guice can be avoided and this reopens the possibility of traditional software architecture where a system is decomposed into smaller subsystems.

My guess is that an approach like this will eliminate the need for frameworks such as Spring and Guice alltogether since hand-wiring a few objects together in a few lines of code is easy. In my view, frameworks such as Spring and Guice only help if you are creating a big monolithic application.

Experiments

For this reason, I am currently experimenting with a small IOC container of my own that implements this component concept. Frameworks such as Spring, Guice, and picocontainer do not offer this component concept since they focus on objects and not on components.

At this point I am already using this component concept in my own projects to avoid a Spring nightmare where loads of XML files are loaded in one big application context. As a result, I can now more easily reuse existing Spring configurations as components that are connected to each other through interfaces and not through application contexts. One application of it is testing persistence out of the container which has now become very easy. The next step is diving deep into OSGI and providing an integration of this component concept with OSGI. 

Over the last weeks I have been preparing for the move from JBoss to Glassfish application server. The reason for this was to have full Java EE 5 capability instead of having to depend on a patched JBoss 4 server. 

This migration has caused me a few problems though. I started with the most difficult application where I did a lot of work on security with JBoss. This was an application where I integrated J2EE declarative security with JAAS and tapestry. A lot of work. 

The application used authentication to a database so looking for support in glassfish, I found the JDBC realm. Unfortunately, that was a bit restrictive because it placed all kinds of restrictions on the data model. So the first thing I had to do was to write a new flexible JDBC realm that could be configured with the same flexibility as that in JBoss. Of course, that didn't work out of the box and I encountered an error. Finally, however, I managed to work around this problem. See this thread for details.

After this problem, it was relatively easy to move over all the other applications. One final issue I encountered was the automatic restart of glassfish at a server reboot. Here, SUN recommends a non-standard approach by editing /etc/inittab directly. This is cumbersome since that file is managed by yast2 on SuSE so I added a init.d script for glassfish instead. This fits much better in the way that services work on SuSE. 

Now everything is running on glassfish and jboss has been shutdown. Migration successful!

Ok, so after years of investigation, it seems that the greenhouse effect is real. There is real climate change and this requires a joint effort of all the nations in the world to limit its effects. If it continues, large parts of the world will be flooded and many people will die because of hunger and disease. 

But, nonetheless, what is happening? Well, as a result of the greenhouse effect, the North pole will become ice free before 2050 and the north pole has huge amounts of resources such as oil. So, instead of figuring out what to do about the greenhouse effect, nations are fighting over the north pole. So far, the United States, Canada, Danmark, and Russia are laying claims on the north pole. 

So who wants to bet? Will the earth's nations work together to come up with solutions to the worlds problems or will humanity just self-destruct in a pointless war about the north pole?  (whose resources are also finite).

After more than 4.5 years I felt it was necessary to get another car. Well... here it is (at least a picture of it).

It will still take a couple of weeks before I actually get to pick it up. 

Joomla was nice, at least to get to know the concept of a CMS. Unfortunately, joomla itself is a really bad piece of software. It is a so-called model 1 architecture with both view and code in one file, much like JSPs with scriptlets are.

This model 1 architecture basically means that the code is totally unmaintanable and that it can contain a lot of problems hidden in the complexity of the code. One of those problems is that in some parts of the code, joomla actually uses commands encoded in URLs that will be executed by joomla when an HTTP request for such a URL is done.  This, in combination with default settings of PHP on my linux distribution allowed the server to be hacked some time ago. I detected this only because my local network stopped functioning.

What it did was download a perl script using wget and then execute it locally. The script itself then launched a denial of service attack but instead of doing this quietly so as not to be detected, the attack was done so aggressively that my modem could not handle it any more and since it was also managing DNS in my local network, this resulted in a breakdown of the local network. In a way I was lucky that the attack itself was so stupid because otherwise the attack could have gone unnoticed. 

Of course, some configuration settings of PHP can reduce the risks a little but still the problem is there and who knows what other creative ways there can be to use joomla to hack a server. Therefore, in a few weeks time, it will be goodbye Joomla. I am replacing it with Alfresco, a more professional CMS that I can simply run on the application server that I am already running a lot of applications on. And, given the professionality of the Java community, which I trust much more than the PHP community, this should be a much better solution. 

Thinking about it some more, the real problem with PHP is perhaps not even in the language itself. For instance, it is also possible to use model-1 architecture in Java and to execute commands encoded in request URLs. I don't think the security settings in my application server would prevent the execution of commands so in theory I am in equal danger with Java. Except of course that no-one in his right mind in the Java community would ever implement something like this. Model-1 was basically banned even before anyone really used it. Also, the general security awareness of Java is high so no one would ever try to write an application that executes commands encoded in URLs.

No, I think the real problem with PHP is, paradoxically, that everyone can understand it. One could call it a "people's programming language" since almost no development environment or tools are required and because simple results can be obtained quickly (Just as one can with JSP and scriptlets). As a result of this, many people without any mentionable design experience can hack together something in PHP. And that shows. I recently saw some small PHP pages for a project, and the same there, unmaintanable code from the first version that was written. 

Wasn't it Knuth who said that "Premature optimization is the root of evil"?

Antipattern name: System-Idle Optimization

Also known as: Premature optimization

Most frequent scale: Individual developer.

Refactored solution: Reduce complexity be implementing a simpler solution that is works when the system is idle and is still efficient when it is really busy.

Root causes: Not being able to look at a system from the outside and determine which actors/stakeholders would actually benefit from the optimization. Low level focus.

Unbalanced forces: Low level technical competence, lack of system overview.

Anecdotal evidence: "It is clear that this is a performance problem "

A developer, usually a technically competent one, designs a piece of software without any technical overview and creates optimizations just for the "design fun" of it. The design is supposed to be more efficient without however
doing any computations or measurements.

When thinking about the different actors and stakeholders involved (e.g. administrator, end-user, developer, project manager, product manager), it becomes clear that most actors/stakeholders do not observe any change as a result of the optimizations, except of course for the project manager who sees additional costs both for development and maintenance.

Strikingly, in many cases the software has some true performance problems that can only be found by looking at the system behavior as a whole. In other words, the effort to optimize performance was totally misdirected.

Some examples:

• A system that tries to create the services it exposes at runtime on demand, usually defended by the idea that this would be more efficient. Nevertheless, during the lifetime of the system all services will certainly be used so in effect the solution does not really optimize anything. The only thing it does is postpone errors in services until a point in time until they are first used which can be long after deployment. And would that be an advantage? Guess not!
• A system that uses thread pools and aggresively tries to keep the number of  threads minimal at runtime, saving memory and resources. Of course, only saving memory and resources when the system has almost  nothing to do, and ensuring that additional resources are used for creating these resources again once they are needed. Not to mention of course the additional complexity involved in comparison to a thread pool of fixed size.
  

I am not much of a tools person,  because I think the most important thing is object-oriented design, which is (or should be) more or less indepedent of the specific tools that are used.

Having said that, good tools are indispensable if you want to focus your efforts on design instead of the technicalities of a particular technology or on your development environment. I really hate it when I spent time configuring stuff or dealing with technical problems that are not part of the real problem that I want to solve. One big problem in this respect are the technologies for developing web based user interfaces. In the past I have used plain JSP and servlets, struts,  java server faces, and Tapestry, with the last being the most successful to date. Also, a recent experience of mine with JSP based development confirmed the idea again that using JSP somehow is like assembly programming.

So I decided to upgrade one of my projects from Tapestry 3 to Tapestry 4. Now, forget it. Huge amounts of compilation errors, and a total redesign of Tapestry which would require a redesign of the application. In this case, one would expect good documentation to help you. Again wrong, where are the migration guides? Leaving people completely in the dark to deal with major changes is not nice. They claim to have simplified the framework, yet they have introduced a dependency on another new framework (Hivemind I believe), a framework a-la Spring, where unfortunately knowledge of that framework is required to use tapestry. 

So Tapestry is out, what next? I already looked at Wicket some time ago and I liked the concept very much, so I decided to use that for a new project: the trackdetective. Compared to Tapestry, Wicket implements basically the same concept but in a much cleaner way, requiring very little framework knowledge, and basically without any configuration files (you don't need them!). In other words, the conceptual surface (as they call it) of Wicket is very small. Wicket, being a relatively new framework, there are no written books on it yet (although Pro Wicket will appear this month (for Wicket 1.2)), and Wicket in Action is being written (focussing on the upcoming wicket 2). Fortunately, the web site itself is really good and they have a quickstart application so I downloaded that. Now this was a special experience. I looked at the web.xml and there it was, a very simple web.xml with a servlet, a servlet config param for a web application class, and a servlet mapping. Couldn;t be simpler. The configuration parameter points to the quickstart application class which extends WebApplication (sounds logical), this class has a method getHomePage() which returns Index.class (also sounds logical), and provides access to a factory for creating (typesafe) Session objects for storing information in session scope. Try doing this with any other web framework and I guarantee that you will get lost right away. 

And as it turns out, the deeper you dive into the framework, it simply stays logical. For instance, today I found two issues with Spring integration and managed to solve them myself.  After reporting them on the mailing list, a few hours later the changes were already incorporated into subversion. This user community is really good. 

After only running the server for a month or so, I already have my first disk failure. In fact, I think the disk failure wasn't even due to the heat of the last weeks, because I had problems with it from the start. Oh well, just sent it back today, 3 years guarantee no problem and the other two disks are still functioning ok. As soon as I have a replacement, I will submit each of the disks to a powermax test. 

 Luckily I have RAID otherwise I would have had a big problem. 

One of the funniest things I have seen to date, the I-Hate-Oracle-Club . This is the original message from the founder explaining why he created it: 

Why? Because I hate Oracle. I hate how it works. I hate its name. I hate the logo. I hate Larry Ellison. I even hate The Oracle from The Matrix.

 Really nice and over the top. You can even get T-shirts. 

OBSTACLE 10g, 1/2 the productivity, 2x the cost

heh, heh....

Many people who have read J2EE Core Design Patterns are using value objects with shitloads of getters and setters, making it impossible to provide any guarantees about the sanity of the object..

Just consider that every field may be zero and that an object may be changed by almost anyone at any time. Also, many of the big value objects in a typical system actually carry process information which is gathered over time, so many of the fields are null initially and are set as the process progresses. Even worse, many value objects actually represent multiple types of real objects (concepts). This is because inheritance is not really supported by entity beans and value objects typically represent rows in a database table.  For example, if a Package has a quantity > 1, then it represents a group of packages and if it is 1 then it represents a single package. In the latter case only, the package may have a unique label by which it can be scanned. In other words, there is a distinction between a package group and a single package. 

As a result, writing simple functionality can become incredibly complex because:

• fields may be null depending on some conditions. As a result, knowledge of which fields are null in which circumstances is duplicated throughout the system. 
• depending on the value of one field, the value object all of a sudden represents a different concept requiring a different treatment. This leads typically to many similar if statements throughout the code. 
• behavior is located in (big) services separate from the value objects

Sometimes one would wish designers would view a design from the perspective of a user. Take for instance the Senseo coffee machine. Excellent concept, really useful for people who don't want any hassle and just want to make one or two cups of coffee.

But why then is there a separate button for switching the machine on? Now, when I first have to switch it on, then wait until it is heated up, and then press another button to get a cup of coffee. As a user, my goal is to get a cup of coffee. So, with all this modern technology why should I be managing the process of the coffee machine? Couldn't it figure out by itself that in order to make a cup of coffee it needs to make sure the water is heated?

Looks like the senseo was designed from a technical perspective instead of from the perspective of user goals.