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.)



Guido Amabili replied on Wed, 2010/03/03 - 3:11am


if you are looking for the specs, you can find them on the JSR website.

I highly like JEE 6 SDK.

If the Spring enterprise sdk solves your problem, stick with it.




And Bod replied on Wed, 2010/03/03 - 4:37am

Good God, i registered just so i can comment on your retardness. Have you spend more than 18 seconds on the Sun site? It has a huge JEE 5 tutorial centered on the SDK & Glassfish. The Glassfish site has tons of documentation both downloadable and in wiki form. How can you just download something and make such retarded assertions, without taking 5 seconds to actually look around and get some idea of what you're talking about.

And what does Spring  have to do with what you're saying here? Its a different take on things. It's just as well documented as Java EE itself. Has alot more bugs than Java EE (I only have to think about Spring LDAP and Spring WS to shudder a little). 


What the hell are you saying buddy. You've used Spring since '05 and now you're stumped at everything else. God damn I still can't believe someone who calls himself a developer can write something like this on a development related site.


I'm gonna remember your name, make sure I NEVER read or even take a second glance at anything written by you or related to you. 

Jan Vissers (ak... replied on Wed, 2010/03/03 - 5:16am

I find it striking to see more and more posts in the blogosphere that try to downplay JEE6, only claiming that Spring is so much better. Don't get me wrong - I think Spring is a great piece of work and have used it several times, but I also like JEE6 (very much so) and think it is great news for the Java community.

In my opinion credit has to go to the Spring Framework (and other great Open Source frameworks) for raising the bar for the JEE platform as a whole. In the end we should be glad for this interaction between community and standardization - it shows us how healthy Java/JEE really is.

In the mean time Spring fans should try to keep an open mind about things. This post was clearly not written in that sense.

Fab Mars replied on Wed, 2010/03/03 - 7:16am in response to: And Bod

bart6425: +1 :)

OK, Wikipedia defines a SDK here: http://en.wikipedia.org/wiki/Software_development_kit

The JEE SDK contains the approved JEE API's, docs, samples, the java compiler, the reference implementation of EE (Glassfish) allowing self learning, development, and deployment. Compliant.

Random API yourself...

Piotr Kochanski replied on Wed, 2010/03/03 - 7:18am

What you need this SDK for in practice? If you need JEE SDK to compile your project use Maven or whatever dependency managent tool you like. If you really need, you can search manualy for JAR-s in Glassfish directories or JBoss directories, but why - any IDE would do this for you, IDEs are designed for it after all.

SUN gives away spec, which is very, very good, since there are many possible SDK implementations (14 certyfied for JEE 5). This is huge advantage of JEE: no vendor lock-in, ability to choose what we like, for instance Spring, which lives as a layer on some JEE APIs. Think of Spring from that point of view. Spring is a different beast then Java EE. If you prefer Spring, that's great, you like Grails, cool, they all share the same root - Java EE.

SUN shows reference implementation, as JCP demands, but you might not like it, as you do, just download JBoss, WebSphere, Weblogic, maybe they have better organized directory structure.

Besides, I work with Glassfish for some time and I have got used to its directory structure, it even makes sense for me (and for other OSGI users too, I guess).

Artur Karazniewicz replied on Wed, 2010/03/03 - 9:28am


 My friend. Just calm down :). I said - it's maybe only me. I don't know. Maybe I'm old school. Or maybe You didn't read my post (only little bit exageratted headline). 

 I assure You I've spent not only five seconds but lot of more time. And that's the problem. Everytime I had to find all JARs, which btw. are somewhere in the SDK bundle. And I still don't believe that forcing everyone on such a huge bundle, just to get JEE up and running is good idea. What if I just wanna play with JMS API, Servlets 3 API and some DI using Apache Tomcat? I don't need Glassfish to do this. Sure, as I said, I can easily find all required stuff on SUNs site. No problem. But isn't SDK the right place to put all this stuff? In my opinion it is. Maybe it's only me. But why the heck I *have* setup all maven or ivy just to play with some stuff, which I have just dowloaded few minutes ago along with SDK?



And Bod replied on Wed, 2010/03/03 - 10:51am in response to: Artur Karazniewicz

WTF are you saying, just shut the hell up. You're not making any sense:


"forcing everyone on such a huge bundle, just to get JEE up and running is good idea."


1. how do you "get JEE up and running" . Is it a game, an iPhone app or what

2. Do you think that  making a JEE application, such as a web-app  implies downloading the JEE SDK Bundle?

3. Who exactlly is forcing you to do anything. This is some free software that you can download or not. A great deal of what you can do with it you can just as easily accomplish with Java SE and other 3d party frameworks.


" What if I just wanna play with JMS API, Servlets 3 API and some DI using Apache Tomcat?"


1. Um then you can get just he servlet (possiblly also JSP) API, and/or JMS API and/or Tomcat and/or Spring?

2. What the hell is Servlets 3 API?


"But why the heck I *have* setup all maven or ivy just to play with some stuff , which I have just dowloaded few minutes ago along with SDK? "


1. Um possiblly because it's easier to work with those tools, NOT because they're mandatory? 

2. Or maybe because you don't know how to set up a project otherwise. Netbeans (which comes with the SDK), can really help you do all the stuff you wanna do with any extra hussle. Check the video tutorials on the netbeans site, as I gather you're not quite the reading type.

Alex(JAlexoid) ... replied on Wed, 2010/03/03 - 11:41am

Unfortunately everything in this world fails the 5 second usability test. That is the worst "test" you could have applied.

And actually Spring is far more confusing out of the box than Glassfish, for any new user.

And the SDK is in fact an SDK. Glassfish is the official RI, so it makes complete sence to have the official RI in the SDK.

And ifyou would have actually read the site you were downloading from(http://java.sun.com/javaee/sdk/) you would have less reasons to write this rant

As a reult, your post presents you as ignorant and, to some degree, arrogant. But, hey, ignorance is bliss...

Nicolas Frankel replied on Wed, 2010/03/03 - 11:47am in response to: Jan Vissers (aka Pojo)

+1 for the POJO. Factual and non-polemical.

Artur Karazniewicz replied on Wed, 2010/03/03 - 12:24pm

@POJO A actually agree. I like Spring and I do like JEE 6. As I said at the same begining of my rant - I'm not talking about JEE 6. I'm talking about shape of *SDK*, not about JEE 6 per se. I regret I gave Spring as a example ;). I should have used Hibernate or something else as a better SDK. My intention was far from fuelling flame war. I do not downplay anything. regards Artur

Artur Karazniewicz replied on Wed, 2010/03/03 - 12:19pm in response to: Alex(JAlexoid) Panzin

@ Alex I said about 5 *minutes* usability test ;). I have nothing against glassfish. I'm fine with this :). Just don't use glassfish and I would prefer have choice. Just simple, lightewight SDK - all required APIs, documentation and examples bundled together and nothing more. And, separate RI. Oh, I could even live with RI as a integral part of SDK. But at the same time I would like just pick some jars from the SDK and start experimenting with APIs. I don't want spend half a day configuring maven POMs (see: http://www.restfusion.com/blog/2010/02/jee-sdk-loathe-it-or-ignore-it-you-cant-like-it/comment-page-1/#comment-33). That's only thing I'm complaining. Ah I don't use Netbeans like probably 80% of developers, I expect, so I don't buy arguments that Netbeans ships with JEE 6 APIs :).

Artur Karazniewicz replied on Wed, 2010/03/03 - 12:22pm in response to: And Bod

@bart Sorry I should not discuss with random anonymous guy shouting at me without any reason. I should not respond to Your fist post. Have nice live :). Artur

Daniel Haynes replied on Wed, 2010/03/03 - 12:26pm in response to: Artur Karazniewicz

My God, these JEE6 fanboys are sensitive souls... and quite impolite!

Reza Rahman replied on Wed, 2010/03/03 - 2:11pm in response to: Artur Karazniewicz


I am truly struggling to understand the point of your post. If you are complaining about the GlassFish code organization, I am not sure most developers care about that. If you are complaining about the download size, try using the Web Profile instead. I don't understand the complaints about documentation or samples either. Take a look at the Java EE 6 tutorial and the SDK samples. Try making sensible suggestions most people are about and not making up flame-bait titles if you really want to avoid needless "Spring vs. Java EE" conflict. If you are stuck in the mindset of being at the runtime jar level, you miss the point in Java EE being a platform. The point is to write applications and deploy them without worrying about low-level plumbing like jar organization/dependecies/implementation. Making a parallel to Java SE, no one really cares how the JDK is organized or what jar files it has, just that you can run your code on it with minimal configuration.



Andy Gibson replied on Wed, 2010/03/03 - 2:10pm

This post is somewhat silly, you want to use JEE, but outside of the JEE container? Ok, I'd like to run my app using spring facilities outside of the spring container,  any suggestions on how I can incorporate spring MVC without having to bundle the rest of Spring with it?


 There you go, there's a JEE 6 example that can pass your 5 minute test. If you don't want to use glassfish, or some other Jee 6 container and want to roll your own environment then fine, but don't complain because JEE 6 doesn't work in a way that was never intended. 




Artur Karazniewicz replied on Wed, 2010/03/03 - 2:39pm in response to: Reza Rahman

My bad. I should not have used Spring in this context. But this is unimportant piece of my rant. I don't actually know why so much people concentrate on this. This is just example. I could easily use Hibernate, Struts2 or whatever here. On the other hand I stated, to be completly clear, that wery probably I might by only me having problems with SDK.

Size of the SDK doesn't matter. What matters is what's inside. I really like JEE 6. It has lots of interesting things inside i truly want comprehend. And I do this. But I also had some frustrations with it. And this rant is about my experience. Try it Yourself: Download SDK, and try to develop simple jsr-315 servlet and, say, message driven bean, and wire the two (use JMS APIs). Unless You use Netbeans (I for one don't use Netbeans) You need APIs to compile whole stuff, right? Now my point is - this should be *trivial* to pick those jars right from the SDK (it's what Software Devlopement Kit (not runtime kit) is all about). Sure I can use Maven, or my other favourite dependency management toolkit, pick jars from SUNs site etc. But wait... all this stuff *is* in SDK. The problem is... it's completely unclear, where it is. I could even live with this, provided there is minimal piece of documentation where I can find required JARs in SDK. Or even ready to use POM, or... whatever. Just this.



Artur Karazniewicz replied on Wed, 2010/03/03 - 2:37pm in response to: Andy Gibson

What's so silly running it without JEE container? I do this for years with success. JEE is not monolit. Most of the components (if not all, especially in JEE 6) *can* be used outside JEE container. And what if I wanna run it in JEE container but not Glassfish? Why should one download Glassfish even though it won't be the target runtime, or even run inside something else, like Tomcat, Jetty or something similar?


Reza Rahman replied on Wed, 2010/03/03 - 2:51pm in response to: Artur Karazniewicz


The problem here appears to be that you are bound to a very specific jar-centered mind-set. The simple fact is that no jar dependency management gymnastics are necessary for Java EE. If you are using Eclipse, it is a simple matter of using the Java EE plugins, registering GlassFish as a server and specifying GlassFish as the target runtime for your project (just as you would for Tomcat, for example). Here are the general steps for that: http://weblogs.java.net/blog/2008/06/27/glassfish-eclipse-ganymede. I just developed a simple Java EE 6 application on Eclipse with GlassFish and it is trivial. NetBeans developement is even more brain-dead simple.

As to compile time dependecies, the only dependecy you should have with Java EE is javaee.jar, which is included in GlassFish/lib. That is it. The rest is all included in the runtime you are deploying to and not something you need to worry about.

Hope it helps,


Reza Rahman replied on Wed, 2010/03/03 - 3:07pm in response to: Artur Karazniewicz


You seem to have some misconceptions here as well. If you wish to use Java EE pluggable APIs like JSF 2, JPA 2, JAX-RS, bean validation, etc, implementations of each of those APIs include jars with just those APIs. There is no need to use GlassFish in that case. For example, EclipseLink 2 will include javax.persistence.jar in addition to eclipselink.jar.The tradeoff is that you will be back to doing jar dependency gymnastics that such an ad-hoc configuration approach makes unavoidable (although it seems that is OK with you because of your particular development background - which is fine unless you've never tried the alternative aand seen first hand how much more headache free it is).

Hope it helps,


Artur Karazniewicz replied on Wed, 2010/03/03 - 3:08pm in response to: Reza Rahman

Well actually I am ;-). Having plugins is nice, cool and all. And I'm probably bound to jars mindset as You said, probably because I'm bound to IDE neutral way of thinking :-). I work usually in quite big teams, using different IDEs, and at the end of the day, project has to build in CI server, without IDE . In this manner I'm bound to jars - that's true. But, hey, isn't jar, well, quite usual stuff in java? :-)

ps. javaee.jar doesn't work for me.

arturs-macbook:lib karaznie$ jar -tvf javaee.jar
     0 Wed Dec 02 21:42:48 CET 2009 META-INF/
   905 Wed Dec 02 21:42:46 CET 2009 META-INF/MANIFEST.MF
     0 Wed Dec 02 21:42:48 CET 2009 META-INF/maven/
     0 Wed Dec 02 21:42:48 CET 2009 META-INF/maven/org.glassfish.extras/
     0 Wed Dec 02 21:42:48 CET 2009 META-INF/maven/org.glassfish.extras/javaee/
  2930 Wed Dec 02 21:20:04 CET 2009 META-INF/maven/org.glassfish.extras/javaee/pom.xml
   114 Wed Dec 02 21:42:48 CET 2009 META-INF/maven/org.glassfish.extras/javaee/pom.properties

Artur Karazniewicz replied on Wed, 2010/03/03 - 3:13pm in response to: Reza Rahman

I want to experiment with JSR-315 servlet with JMS API on Tomcat and jetty. What's so unusual with this?


Reza Rahman replied on Wed, 2010/03/03 - 3:16pm in response to: Artur Karazniewicz


You seem to be stuck in a very low-level mind-set here as well. Who cares how the internals of javaee.jar is organized as long as you can use it to compile your code? As I said, if you are using just the pluggable APIs, go download them separately.



Reza Rahman replied on Wed, 2010/03/03 - 6:03pm in response to: Artur Karazniewicz


Servlet 3 (JSR 315) is not a pluggable API, you will need a Servet 3 container for that, which Tomcat currently is not and neither is Jetty. Resin 4 is a Servlet 3 container as is Grizzly (GlassFish). JMS is similarly not a pluggable API, but the JMS APIs are shipped with ActiveMQ that you can use with Tomcat (the JMS API has not changed in Java EE 6). EJB 3 (message driven beans) is not a pluggable API either but the APIs ship with OpenEJB which you can use with Tomcat. CDI is similarly not a pluggable API but Weld/OpenWebBeans runs on Tomcat and include CDI jars. Other than this small handful, a majority of Java EE APIs are pluggable. However, again integrating all of this one-by-one on Tomcat is just a pain. If you are using a majority of Java EE 6 APIs, you are much better off simply running on a Java EE 6 platform like GlassFish, JBoss, Resin, etc.

The problem with your post is that it is just not that well researched and you seem to trying to fit your round peg mental development model into a square hole (I mean that very kindly and in a constructive sense). I would suggest changin your perspective just a little in terms of a platform mentality with minimal jar management. You may find like many of us using Java EE 5 and Java EE 6 that it will make life a lot easier.



Reza Rahman replied on Wed, 2010/03/03 - 4:20pm in response to: Artur Karazniewicz


Not to beat this to death, but if you look inside the manifest declaration for javaee.jar shipped with GlassFish, you'll see the individual API jars that have been modularized:






















If you are really that opposed to simply including javaee.jar in your compilation classpath and be done with it, you can include these jars yourself. Frankly, this is much farther than most application servers go - most just put all the APIs right inside javaee.jar.



Andy Gibson replied on Wed, 2010/03/03 - 5:35pm

> What's so unusual with this?

 I want to use the light from my car headlights to light my dining room. Since bulbs, like jars are portable, I can just take it out and put in in another lamp can't I?

 You have an absurd naivety that everything should just work well together, and to some degree it can with a good dose of configuration and making up for those things that are missing since you choose not to run it in the environment it was built for. (you know, the stuff you do in all apps)

 Perhaps you should address the points to Tomcat , Jetty and Co as to why their platform isn't supporting the JEE 6 standard web profile. Would you blame spring or Howard Lewis Ship if your spring config or tapestry app isn't working out of the box in the container?

Jeroen Wenting replied on Thu, 2010/03/04 - 3:30am

The download is relatively small (for contemporary standards) at under 70MB. But indeed things like documentation and libraries could have been easier to find in the rather large installation tree.
And being forced to download and install Netbeans and Glassfish just to get the API docs (which I might want to use in conjunction with another application server) is IMO not a good idea. It's even worse the download site prompts you for a host of personal information to download the stuff (without making it clear that providing that information is optional, I've encountered quite a few people who refused to download and install it because of that).

Reza Rahman replied on Thu, 2010/03/04 - 10:48am in response to: Jeroen Wenting


I am note sure any of this is valid either. The docs are simply under GlassFish/docs! And "libraries" in terms of the Java EE platform makes no sense whatsover. Like .NET and RoR, Java EE and Java EE are runtimes, not libraries. You can very easily download GlassFish without NetBeans: http://java.sun.com/javaee/downloads/index.jsp. And the registration page is no different from what companies like SpringSource/VMWare have. It is pretty clear you can proceed without registration (as I did).

A lot of this frankly seems like frivolous complaints.



Artur Karazniewicz replied on Thu, 2010/03/04 - 10:54am in response to: Andy Gibson


Your analogy is good, but should be applied other way around. It's like ligting company shipped their light bulbs together with cars. And to get installed in Your own car, You are forced to find and unisntall it from Reference Car ;).

The problem I see is that You don't differentiate between the platform and the API (or SDK). And Yes, I would definitelly blame Howard, or Spring if they ship their APIs together with Tomcat for exapmle. Or Hibernate shipped together with mysql. 

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

Reza - have You tried to put this into Your classpath? It's glassfish specific. I for one dont have ../mq/lib/jaxm-api.jar, nor 'modules' in my project.



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

I dont wanna embed grizzly or open mq into tomcat. I just wanna use client APIs. The problem is I have not idea where those APIs are actually located in the SDK. That's all. It as simple as putting it all together into lib directory as in 99,99% SDKs. Nothing more.

Comment viewing options

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