I'm a software developer particularly invested in REST and distributed systems, service oriented architecture, and software architecture in general. I work and live with my family in Poland. Artur has posted 2 posts at DZone. View Full User Profile

JEE SDK – Loathe It or Ignore It, You Can’t Like It

  • submit to reddit

It’s only me who think JEE 6 SDK is complete mess? Don’t get me wrong, I’m not saying JEE 6 is mess. It’s SDK which brings accidental complexity, the hard way. It failed my five minutes usability test, and it continues to fail still, after few months.

The problem with SDK

It’s not SDK actually; it’s just Glassfish bundled with some documentation, examples and random APIs. That’s it. Here’s what You get with JEE bundle:


Ascetic, isn’t it? Expected some standard stuff like lib or, better, dist directories? Some jars or APIs? Or some form of readme, or docs? It’s SDK, the Software Development Kit, right? It should have all that usual stuff somewhere. Well, sort of. If You’re stubborn enough and lookup Glassfish directory, even though don’t expect too much.  This is “enterprise” stuff,  it can’t be just as simple as picking some jars and start working with it ;) . So where are all expected JEE APIs?  I’m not quite sure, except some mere suspicion. After quick bashing it turned out that $SDK_HOME/glassfish/modules contains most interesting bits. Most… except, believe me or not, JMS and JTA APIs. Surprised? Most probably. SDK comes without core stuff like: JMS and JTA APIs. Or again, maybe it’s just me who failed? Would love someone point out I’m wrong. I know, I know: I can find all this stuff here. But isn’t it SDK supposed to come with?

Even though $SDK_HOME/glassfish/modules contains something… it’s Glassfish runtime, and I have no confidence what all those jars actually are. Are they official APIs, or maybe OSGI bundles, or is this Glassfish specific stuff, RIs, or something else? I’m not sure, neither my google is. Anyhow I don’t think server runtime is the best place to throw APIs in. Thanks God SpringSource guys didn’t mix Spring Framework with Tomcat distribution.

How it should look like, then?

Enough ranting. How to fix it? Take some time and take a look how does competition work. Just create simple, lightweight SDK (“lightweight” is the main theme behind JEE 6 after all, isn’t it?). Just bundle APIs, documentation and samples (and keep separate Glassfish bundle, of course). That’s it. JEE is supposed to be portable and universal; not everyone is interested in full Glassfish distribution. Make it simple for beginners and give a chance the JEE SDK passes 5 minute usability test. That’s all.

Hope “Do more with less work” would work better next time… or it’s only me? Should I RTFM? Anyone care to comment?

From http://www.restfusion.com

Published at DZone with permission of its author, Artur Karazniewicz.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Reza Rahman replied on Thu, 2010/03/04 - 11:46am in response to: Artur Karazniewicz


This is really getting silly. Please do some basic research on Java modulraity/jars to understand how jar file organization works and how to reference jars in a classpath (these are things you will need to properly understand if you do not use an IDE/Ant/Maven). You need to reference javaee.jar in your classpath from the runtime directory. That is dead easy to do in both Ant and Maven (I use Ant because I am very adept at it and have tons of ANT scripts I can re-use). It is even easier in Maven because of the Maven WAR and EAR plugins. Adam Bien described how to do this with Java EE 6 not that long ago: http://www.adam-bien.com/roller/abien/entry/java_ee_6_ejb_31. The GlassFish jars, including javaee.jar are available on the Java.net maven repository as well: http://download.java.net/maven/2. If you still want to do a mechanical copy and paste for some strange reason, you'll need to look into the manifest content I posted and copy those jars manually. Keep in mind, copying Java EE/Java SE APIs into JAR, EAR and WAR files is very problematic for the target runtime and unneccesary since it is already included in the classpath.

You continue to miss the point that Java EE is a platform, not a random set of libraries thrown together. When you are dowloading the Java EE SDK, you are downloading the runtime and cannot expect to "hack" it and expect things to work. If you are interested in the pluggable parts of Java EE and not the platform itself, you can download those "libraries" separately from their respective sites. For example, you can download the JSF 2 reference implementation and API here: http://java.sun.com/javaee/javaserverfaces/.

Frankly, you seem to be spending more time making ill-researched posts than simply spending a little more time learning a tool you are apparently rather unfamilar with. If you are really that unfamilar with the developement platform/runtime concept (Java SE, Java EE, .NET, RoR) it will obviously take more than five minutes for you to understand it and shift your mind-set (and a lot of people from a C/C++/Spring heavy background but doing enterprise Java development are in this same boat). No .NET, Java EE or RoR developer would ever think of copying the platform's components into their code instead of simply referenecing them into their developement/build environment...



Henk De Boer replied on Thu, 2010/03/04 - 5:48pm in response to: Artur Karazniewicz

What's so silly running it without JEE container?

As others have tried to explain to you too, the silliness originates from your assumed idea that everything should exist primarily as a collection of independent add-on libraries for the most holy piece of software ever written: Apache Tomcat.

This is not necessarily the case for Java EE 6. The power of Java EE mainly comes from it being a very well integrated platform. Your question would be a bit similar to asking what's so silly about running individual Java SE classes without a JVM. Now technically this might be done, there are some projects that allow some individual Java SE classes to be used in say a .NET environment or even in a C++ application. But this is simply not what Java SE by default is about. Java SE is not primarily a collection of independent classes (or packages if you will) for C++, but is a platform existing out of a JVM, language, and standard library.

Now for Java EE, implementations of several of its constituent APIs might be useable standalone. That is, they might be useable on top of Java SE, and thus also on top of The-One-AS-That-Is-So-Lightweight-It-Almost-Floats (Tomcat). But this is not a primary concern of the Java EE specification, but is more of a concern of the individual APIs or more often of the specific implementations of said individual APIs. Java EE precisely exists to specify a whole platform; a fully functional, richly featured application server.

So, seen in the light of the main purpose of the Java EE spec, yes, it's a little silly to expect that a random Java EE implementation consists of a neat collection of individual API jars (jsf.jar, jta.jar, jpa.jar, ejb.jar, etc) that are readily and directly useable from any Java SE app in the way one would use e.g. Apache Commons libraries.

Now I'm not exactly saying that this is a silly wish by itself, but you're clearly not understanding what the concept "Java EE" is about. Apparently the demand for such a thing you wish for is not really that big. Most people who want to use Java EE just download and use any of the many high quality Java EE implementations (JBoss, Weblogic, Glassfish, etc). Most of them have various mechanisms for disabling stuff you don't need, if that is what bothers you (many people don't bother, but it's your right to do). For the few of you who are really anal about building every piece of your software stack yourself, there are already more than enough options. You do have to hunt for the pieces yourself a little (e.g. for JSF you go to the MyFaces or Mojarra site, for JPA to the Hibernate or Eclipselink site, etc), but that's the price you pay for building your own stack bottom-up.

Henk De Boer replied on Thu, 2010/03/04 - 6:03pm in response to: Artur Karazniewicz

I dont wanna embed grizzly or open mq into tomcat. I just wanna use client APIs.

C'mon are you a programmer or not?

  • Download and install Glassfish
  • Download and install Eclipse Java EE
  • Startup Eclipse, point the server adapter to Glassfish
  • Create new Java EE project.
  • Happily code against any Java EE client API you want to use.
  • Publish (deploy) your project to server runtime and start it
  • Voila, your code runs...

Substitute e.g. Glassfish for JBoss AS if you wish or Eclipse for Netbeans...

Artur Karazniewicz replied on Fri, 2010/03/05 - 1:12pm in response to: Henk De Boer

Hank Is this really that hard to understand that it would be nice to have exactly the same shape of SDK that everyone used to for the last 15 years in the java world? Just put API/client jars into lib or dist directory? Is this *that* unusual and 'ill-minded' approach? If yes tell me why 99,999% frameworks and SDKs reuse this pattern? I'm too much locked to jars? Huh? C'mon last time I checked all libraries in the java world are distributed in the form of jar. Not plugins or RIs or messaed up together with application server.

I *don't* wanna plugins. I don't trust them if this comes to *libraries*. They have completely different release timelines than APIs and libraries. For example plugins usually comes out at best few months after release of new version of JEE. I do *want* one, clear set of APIs in the form of jars provided by the vendor like 99,99999% vendors do. For me IDE is just helper. At the end of the day I have to *have* build independent of the IDE. That's real-life. I have not seen any serious project based exlusively on given IDE and it's plugins. And, sure I can sacrifice and hour or two to setup Maven or ANT. And I actually did this.

I'm actually really puzzled that's sooooo hard to understand that it would be just nice to have simple lib directory within the SDK with all *APIs*. That's all. You know - kinda stuff everybody seems to follow: hibernate, struts, spring, except, well JEE. Tell me what's so different with this? How it is fundamentally different form spring distribution? Now You belive that it would be nice that Spring guys put their stuff into some random places of Tomcat distribution? Huh? Really? An, sure, then You could say... download STS or Spring IDE and happy coding... 

ps. I don't wanna enter into Spring vs. JEE flamewar. I'm not talking about frameworks. I'm  talking about packaging schemes. That's all.


Artur Karazniewicz replied on Fri, 2010/03/05 - 1:05pm in response to: Reza Rahman

Reza Let's focus on merit instead focusing on kinda personal remarks. Your 'the thing is superb, you guys are just too stupid to comprehend'-kinda approach is exactly what I called 'enterprisey' in my rant. Now I learned from Your story that I'm ill-minded, have very narrow approach and focused on jars, and actually don't know what I'm talking about etc. Well, maybe working with this stuff for lat 12 years, including 6 years of doing architecture is not enough to comprehend this enlighted form of distibution :). Now I'm looking Struts2 guys put their framework into some random locations of Tomcat and Hibernate put this into some form of mysql bundle. Jars are soooo boring. Maybe I missed something, and now looking for a jars is ill-minded... I don't know. Maybe I should base all my builds on IDE and some plugins. And throw out my CI server since I don't have nice JEE 6 plugin for my Bamboo and should convince my developers to press f9 to initiate build (seems soooo cool...wait...it reminds me 1995...) ... But actually last time I checked, the standard form of distributing java libs was jars... no?

Back to javaee.jar. Well believe me or not i *do* know how to resolve classpath in java. But, i guess, unlike You actually *tried* to use javaee.jar from glassfish. And I *do* know this *desn't* work. And I'm not alone: http://www.restfusion.com/blog/2010/02/jee-sdk-loathe-it-or-ignore-it-you-cant-like-it/comment-page-1/#comment-31

The problem with this is that those paths in manifest in javaee.jar are *realative* and *glassfish* specific and *will* *not* work with different directory structure... Have You tried it? I did and I know what I'm talking about. Artur

Nmatrix9 Nmatrix replied on Thu, 2010/03/18 - 1:55pm in response to: And Bod

I also have to disagree with some of the statements made in this article, but bod lets keep it civil here try and act like a grown adult and stop the name calling.

Henk De Boer replied on Sun, 2010/03/21 - 7:54am

I agree! Great comment N-Matrix 9.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.