Java EE Profiles ... aka ... Problems Ahead

Today I want to share my thoughts about the upcoming Java EE 6, or more specifically, one part of the JSR-316: Profiles.

Up to this day we've gotten used to the fact that if we are using a J2EE/JEE-compliant server, we can also use the features Java EE provides. In the future, this is not so clear-cut. You may find yourself coding a Java EE-app and realize too late that you accidentally slipped in "unsupported territory".

At most companies there are developers that range from superstars to entry-level developers and while most developers will be very well-informed about current technologies, some may still be learning and will realize too late, that the newly created component will not run on the Java EE container chosen as the target environment. Simply, because there was confusion about whether this particular line of code actually uses some part of the specification, which isn't present on the production server.

Sure, there are many test-cycles before the app is actually going to be deployed, so the problem is of theoretical nature. Still, most IDEs don't necessarily require the appserver libraries to be on the classpath during the implementation phase, they simply provide a generic javaee-api.jar which contains everything.

There is another problem. What, if the developers aren't the decision makers (quite common at bigger companies). What if management told the Devs to use JEE and while they are working management discovers Tomcat? "Uhh, Tomcat is JEE-compliant and there are lot's of books on it so there is market acceptance... and the best thing is: it's free!". In this case you'd probably end up in a pretty sticky situation indeed! (No, I am not bashing Tomcat, I used it as an example.)

Last but not least. In these days, outsourcing is quite common. Both for development and even more so: Application Hosting. One day you find yourself using a webhost providing a fully Java EE-compliant servers and the next day management wants to save some money instructing the IT-department to move to another webhost. Of course, the new host claims to JEE-compliant servers, which just happen to not be compliant to your Java EE-application. Bummer...

This may not be a problem. Yet, it could become a problem... After many years of development with J2EE 1.3, 1.4 and Java EE 5.0, JEE developers have become accustomed with the idea of having the full collection of JEE-specs at their fingertips. Therefore, I would prefer if there is one Java EE 6.0 profile. It doesn't hurt to have some extra functionality in your appserver, you never know when you gonna need it.

Now the big "But"... I am a little bit like Twoface (you know, Batman's nemesis) as I do see some advantages with profiles. In theory, your application may be more performant for every service which the appserver doesn't have to have in memory. Also, it may be more secure the fewer services the application server provides (smaller attack surface). Then again, what are firewalls for? :-)

I myself "personalized" many JBoss installations to exactly fit my applications' needs and therefore I have an idea for the Java EE 6 Expert Group. Instead of implementing profiles, enforce the rule that JEE6 services can be enabled/disabled. Thus, all Java EE 6-servers support everything, when needed. In reverse, you could disable the services which aren't needed.

Ultimately, I think that the concept of profiles is beneficial only to vendors and perhaps Sun itself (do I smell licensing fees?). Soon just about any container that can run a subset of EE-related technologies may be called a Java EE-compliant server and may cause problems of the sort I previously described.