JEE not J2EE

A quick pointer for information technology recruiters and job seekers:

It isn’t called “J2EE” anymore.

“J2EE” meant Java Version 2 ( also called 1.2 ) Enterprise Edition

The term “J2EE” hasn’t been used since 2004 with the release of Java 5 ( 1.5 ).

The proper name is

Java EE <current version number of Java>

So, what is the “Java Enterprise Edition”?

Many recruiters as well as developers think it is a separate, advanced version of Java or a version of Java you have to pay for. Not true.

The Java language is not enough to build a server side application. You also need to use tools like a database, a database bridge, a transaction manager, a security system, a web server and/or directory services. A number of different vendors created “application servers”, software that integrates all of these services, the way Microsoft integrates all of their things into one platform. Very good idea, but each vendor created their own unique API that developers had to code. This made the resulting code useless and not portable without that application server.

“Java Enterprise Edition”(JEE) was created as a standard that application servers have to conform too. Compliant application servers must support specific APIs and a specific set of services & libraries which include, but are not limited to:

  • RMI
  • Servlets/JSP
  • JNDI
  • JTA ( transactions )
  • Java Messaging

So there you have it.  It isn’t called “J2EE” anymore.  It is “JEE” a set of standard APIs that Java compliant application servers must support.   It isn’t an advanced version of Java or a version of Java you have to pay for.

 

 

Similar Posts:

    None Found

2 thoughts on “JEE not J2EE”

  1. I think we’re using Java 8. I don’t even hear Java EE or the word Enterprise associated with Java much anymore. I associate the word with Star Trek again.

    Sad news for Java. I read an opinion piece talking about how Java is the modern COBOL. Having avoided COBOL for most of my career (and mostly successfully), i have to agree. I currently avoid Java for many of the same reasons i’ve avoided COBOL. At least Java thinks it has a stack.

    But having written a C library for doing web based apps, supporting several databases, and lots of the normal things you’d need, i’ve been looking for a new favorite language. Don’t get me wrong, C is fast. I rewrote twenty Perl web apps and achieved around 30x performance improvement for everything. Not all of this was C vs Perl, which enjoys a 300x benchmark advantage. Some of it was terrible design. It’s like they designed these apps to look good for the first week, but age badly on purpose. I’m exploring Julia, go (golang) but also NOSQL databases like Cassandra and Neo4j. So far i’ve learned that go compiles to an executable that has it’s own runtime built in, and it’s very fast – 2/3rds the speed of C (where Java is half or less). And NOSQL doesn’t mean “doesn’t have SQL”, but rather “No Only SQL”. The Cassandra book explains the application spaces the best, at least so far.

    1. It is kind of natural that PERL scripts would be poorly designed, being scripts.

      I’ve heard about Java being doomed and sundry trash talk about it since the 90s.

      It keeps growing, both in APIS and job opportunities.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.