6

Lately I am seeing quite a few application development job ads asking for experience with this or that Java EE server. I can understand this if it is for a server administrator, however I find it stupid and ridiculous to ask for some one with a specific server implementation experience when the job is Java software development. The whole idea behind Java EE as I studied in my initial days was for development of standards and to deploy to any platform of choice that including servers, OS, etc.

My question is, are the various Java EE application container implementations so vastly different that they can be considered their own career path for development? What kinds of features exist amongst Java application containers that require such specialized skill that I might not want to not consider applicants with otherwise impressive software development qualifications?

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
Kalyan
  • 79
  • 3
  • 4
    As was currently worded the question was too focused on career path and technology choice. I edited the question to focus on what features of Java EE application containers would require specialized skill for software development. – maple_shaft Feb 25 '13 at 12:02

2 Answers2

6

This is where I feel the Sun enterprise vision for Java failed. The idea is that application servers only vary by implementation and any Java app can be dropped into any container and "just work".

If you read their literature from the early days, they also had specific roles called out, like developers who just wrote beans, assemblers who just took beans and assembled them into ejb jar's and setup deployment descriptors, and of course, system admins who manage the application server itself, which as previously stated, is completely decoupled from the apps within it.

In reality, it never works out that way. There always needs to be something different about the app to deploy it into another container.

Examples:

  • Database connection pooling - every app server is different. Some web apps even do it themselves.
  • Caching - JBoss in particular has classes within its packages that facilitate cluster-wide cache invalidations. Can't just drop your code into Jetty anymore.
  • Testing - if ops wants to upgrade Tomcat, what needs to be tested? Is it safe? Only engineering can tell and QA can verify.
  • Configuration management - because container configuration is not part of the Java EE spec, configuration files are always container-specific. It's very common for application installers to configure the container for you, by either checking configuration files into source control or writing scripts to update the container's config files.
  • Class paths - where do all of your JAR's go? I know they say to put everything into WEB-INF/lib and WEB-INF/classes. Hah. What about JDBC driver? Oh yea, that goes under $TOMCAT_HOME/lib. Or $JBOSS_HOME/server/servername/deploy/lib or something like that. Then you upgrade JBoss and now it's $JBOSS_HOME/standalone/lib. Don't expect ops to upgrade that without dev. And don't get me started on log4j classpath issues.
  • Containers often have prebuilt ways to solve problems for you, but you sacrifice portability. For example, I often see HTTP compression handled at the container or web server level If, as a developer, you want to enable this, would you setup a servlet filter within your web app for it, or "flip the switch" on your container and/or web server?

My list could go on and on.

Brandon
  • 4,555
  • 19
  • 21
  • i guess this should be publicised on grand scale...choosing java as career path is a bad choice as its too fragmented, and ensuring a marketable skill is much more challenging. On the contrary .NET platform is better choice with clear skills in need both for career development as well as for recruiters. Its an unfortunate truth I realised after fair amount of experience as JavaEE developer. – Kalyan Mar 02 '13 at 09:49
5

I find it stupid and ridiculous to ask for some one with a specific server implementation experience.

Based on my limited experience, our development team is also responsible for the J2EE container. We make sure that the code and server together solve the problem we're working on. Who else would have such insight as to what tools or frameworks are needed for the code to run effectively? The sysadmin is then responsible for the machine itself and for making the J2EE container play nice with everything else (firewalls, etc.).

What kinds of features exist amongst Java application containers that require such specialized skill?

I think it comes down to frameworks here. A codebase built upon Struts and Hibernate need not care, really, which container it's running on.

In the end, experience in a specific J2EE container need not matter so long as the application or the frameworks it's built on handle the differences for you. Yet, even if this is true, experience with that container could still be seen as a plus.

(3+ years developing on JBoss)

clintonmonk
  • 261
  • 1
  • 6