13 June 2005
It is no surprise that Sun's implementation of the Java Runtime Environment (JRE) is perhaps one of the most popular implementations (for Windows. Linux, and Solaris). There are several others, however, that are worth mentioning, namely, IBM and Blackdown. The number of JREs is very correlated to the number of architectures in which the JRE is to run on, which makes sense: it is a good thing to have one version of the truth! (the truth being the interpretation of the spec:-) These standards help the developer create better code that can rely on consistent implementations of the JRE.
The number of J2EE application servers, on the other hand, is quite large. One good thing about this myriad of app servers is that it promotes competition to create increasingly better infrastructure code. Good. However, sometimes it seems as though this could be a double-edged sword in that this competition promotes vendor-specific functionality wherein code deployed on such a server may have a tendency to be more dependent on that implementation rather than the spec. Bad. Of course, one could mitigate these dependencies with certain designs, IoC, in particular. Yet, frameworks like Spring, that make heavy use of dependency injection, tend to act as their own app server that can be deployed in a container. From a developer's perspective, the more that the infrastructure can increase productivity, the better, yet, not at the expense of interoperability. In this light, frameworks like Spring really excel.
So, what does the advent of GlassFish, a J2EE app server community driven effort sponsored by Sun, mean for the J2EE development landscape? Since Sun is driving this effort through the community in an open way, will GlassFish become the de facto J2EE application server? Is a de facto higher up the application stack a good thing? Or, will lightweight, ad-hoc application servers like Spring, in concert with persistence engines like Hibernate, prevail?