I’m using Java EE and I’m proud of it

Ever since I started working with J2EE as it used to be called, I have been reading articles about how bad it is, and how many nice solutions exist that replace the need for the Java Enterprise Standard.

Look at this article at the JavaLobby, for example. (disclaimer: I am a big supporter of the JavaLobby , and I read the columns and discussions as much as I can).  According to the article, the JEE wars are over and Spring has won. Excuse me? I wasn't aware of a war. I am working with JavaEE and I am happy with it, some people I know (many people, I agree) are working with Spring and they are happy too. More important, we still live in peace. 

I strongly do not believe in a one-framework-fits-all-for-everybody concept. Even stronger, I don't believe in a one-language-fits all. Some people like PHP and are extremely skilled in it. That is good, they should develop things in PHP. I am very bad with PHP (not that I work with PHP, but if I would, it would be very bad). I like Java, it fits my way of algorithmic thinking, hence I use that language and platform to achieve my goals.

The same holds for Java Enterprise. I see lots of cool things that are created using Spring. That is excellent, and I encourage people to continue doing so. But again, Spring and myself isn't the best match. I like the EJB 3.0 spec. I even liked the EJB 2.1 spec! I agree that EJB 2.1 was a huge barrier for novice developers, and I believe EJB 3 is much easier.  

At LodgON, we've created a number of applications on top of JavaEE 5. One of the most important things for me is the fact that Glassfish is the reference implementation for Java EE 5. I don't have numbers about market share or adoption, but Glassfish is one of the coolest projects I've ever seen in Java. I wish I had more time to play with Glassfish v3. I will investigate v3 in the near future, I believe that together with JavaFX, Glassfish v3 is one of the most important activities inside the Sun Java divisions.

Look at DaliCMS, it is a complete CMS on top of Glassfish (or any JavaEE 5 compliant appserver). It leverages a number of Java EE capabilities: persistence API, transaction management, resource management, JMS, Mail API.

We've build a survey system for a major telco/cable TV operator, where a very large number of users got a popup on their TV screen all at the same moment. Served with Glassfish, ran without any problem.

We created many proprietary systems for customers, most of them running on Glassfish.

Does this mean that I would suggest all Spring developers to migrate to Glassfish? No (although I would recommend them to give it at least a try). But please, stop bashing Java EE and let the developers that are using JavaEE and Glassfish and that are happy about it at least in their dignity. When I read some of the anti-JavaEE articles, I feel like I should be ashamed. I am proud to say that I'm a happy Java EE 5 developer. 

 

AtomPub

I am writing this entry using the Atomic plugin for Firefox.

DaliCMS , the Web 2.0 ready Open Source Content Management System created by LodgON , has now build-in support for AtomPub. As a consequence, we have a servlet listening for requests in the AtomPub format.

One of the cool things about this is that you can use a third party client (like the Atomic plugin for Firefox or Windows Live Writer) for adding entries to your DaliCMS blog. The AtomPub protocol is a very recent specification, describing the publishing process for Atom entries.

Check out this entry at the DaliCMS.org blog for more information.

I really hope that other CMS systems will implement the AtomPub protocol as well. A thight coupling between blog-client and blog-server slows down adoption.

Up to the next protocol!

Java Web Start and OSGi

Recently, I am working on a project where we use Java Web Start and OSGi technologies. For both technologies, you have believers and you have non-believers. As for many Java technologies, I became pragmatic in using them.

Java Web Start is really cool for distributing my application. I don't have numbers on this, but it seems that the installed base of Java Web Start (JWS) is peaking. Which is great. The "Web" in "Java Web Start" is misleading, though, since it has nothing to do with a web-framework. However, the word "Web" is important since JWS allows you to distribute your applications via the Web, by serving a JNLP-file. But that's basically all it has to do with the "Web" as most people know it. Or not, since I recently discovered a cool feature. My JNLP-served application needed to download jar-files from a http-password based web directory (as part of the OSGi solution). The cool thing is that I don't have to add code in my application for doing the authentication, you automatically get a nice box that allows you to authenticate yourself. 

The OSGi Framework is great for managing the lifecycle and dependencies between different modules that make up an application. OSGi defines the concept of Bundles and Services, see http://osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf for some basic information. Using OSGi, you can develop an application in a very modular way, where third parties can develop modules that are based on your modules and vice versa. The old idea of separation between interface and implementation really happens in an OSGi environment. Applications that leverage the OSGi framework depend on pieces of code that can come from various sources. They ask the OSGi Framework for "an" implementation of a particular interface, and it is up to the Framework to provide the caller with the best matching implementation.

I am not religious about Java Web Start nor about OSGi. Both technologies have their merits and disadvantages. If you use them in a proper way, your applications can benefit from them. None of these technologies claim to solve all potential problems, and that is what I like: I don't believe there is a single framework/technology that fits for all scenario's.  

Java and performance

Last week, I attended the PhD defense of Dries Buytaert , creative cohort and Drupal founder (in that order). I had the pleasure to be in his thesis committee, and that allowed me to ask some nasty questions. I was in good company, with James Gosling and Michael Hind being members of that thesis committee too. 

The topic of the dissertation is "Profiling Techniques for Performance Analysis and Optimization of Java Applications". I have the impression that this subject receives less attention than it would have received 10 years ago. In the beginning days of Java, the major complain was that "Java is sooo slow". Today, the Java platform and the hardware have evolved in such a way that it is now possible to write Java programs that allow for a very fast runtime execution. However, this does not mean that performance is no issue anymore. At the contrary, I see enough reasons why performance is still important:

• there are a number of devices out there, ready to be Java-powered, but with less resources than daily PC's and servers.
• performance problems are in some cases related to logical/algorithmic problems. Not solving the performance issue (or solving it by adding hardware) does not eliminate the side problems
• customers are getting more and more demanding
• low performance == high energy
• …

In the public presentation of his PhD defense, Dries compared the performance of a Java program with the consumption of energy/electricity in a household. People don't want to consume too much energy, and they want to know when they are consuming too much, and how this can be optimized. A very good analogy today, where more and more attention is paid to optimizing energy,

Dries deals in his work mainly with 3 procedures for measuring and/or optimizing the performance behavior of Java programs. Especially the third method, where Hardware Performance Monitors are used, is very promising – at least in certain environments where startup cost is important and execution time is rather short.

An important personal remark, however, is that avoiding performance problems is even better than solving them at runtime. Therefore, I am personally more interested in the measurement of performance, rather than in the capability of the runtime environment to optimize the performance. There are enough techniques that allow one to degrade the performance of a Java application. When developing a program, the developer does not necessarily knows how his program will be used in practice. If the first use of a program is monitored (e.g. using Javana, one of the 3 procedure Dries describes), the developer can use that feedback to determine where potential performance gains can be achieved.

It was an excellent PhD defense. Congratulations to Dries, and I hope he will keep on using his ideas for helping the Java community.

 

To Blog Again

I had a few blogs in the past. These blogs were mostly linked to some test projects, though.

The blog I am starting now is linked to LodgON, and I will write about things that I consider to be important for LodgON and for the things we are doing. Since LodgON is mainly working on communities, what I consider to be relevant might be relevant for lots of other people.

LodgON is doing a number of projects for companies we signed an NDA with, and I have to be careful not to violate the NDA's I signed. However, the more open projects I am involved in are often very interesting, and they provide lots of interesting stuff I can write about.

So keep watching this blog for my opinion and experience with new technologies. Topics that I will definitely cover in this blog are Java, Flex, JavaFX, location-based services, OpenSocial, GData,… Stay tuned.