JEE SDK – Loathe it or ignore it. You can’t like it.
February 17, 2010 by karaznie · 5 Comments
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:
.org.opensolaris,pkg
bin
glassfish
install
javadb
mq
pkg
uninstall.exe
uninstall.sh
updatetool
var
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?
Well said! I had thought it was just me being too fussy… but clearly there’s at least two of us!
Here’s another problem with it.
If you look at javaee.jar for the actual JavaEE API definitions themselves (it’s in /glassfish/lib), this no longer contains the API classes but instead just uses its manifest’s Class-Path to point to all the separate jars that contain the individual APIs. Of course this has to give their paths as relative paths from the javaee.jar’s own location.
You’d think that given the need to use relative paths, and that these are the standardised API definitions for which this is supposedly the SDK, it would make sense to put all of these jars in the same directory as javaee.jar, or in a single subdirectory within that. Or ideally to put all of this into a dedicated directory on its own (e.g. a /javaee-api or /glassfish/javaee-api directory).
Not a chance! Most of the jars are in /glassfish/modules, which is a sibling of javaee.jar’s parent directory, but one or two are in entirely different locations elsewhere in the Glassfish directory structure. For example, /mq/lib/jaxm-api.jar. That’s right, javaee.jar has to specify this using a relative path of “../../mq/lib/jaxm-api.jar”.
Apart from being unclear and confusing (at least to my mind), this gives us a javaee.jar that’s tied not just to how the various Java EE API files have been organised, but also to the broader Glassfish directory structure (and vice-versa – if they decide to reorganise the Glassfish directory structure at any point, the contents of javaee.jar will have to be changed accordingly).
Of course, just to make things even more of a mess, the individual API jars are mixed in with lots of other jars and various other files.
This really can’t be the right way to structure the SDK and javaee.jar!
And don’t get me started on “.org.opensolaris,pkg” and the discussions about it…
It’s nice to find a place where I can complain on JavaEE
It’s sad to look at JavaEE SDK – but have you looked at Maven repositories?
It’s my story – I wanted to look at Servlet 3.0 spec and as always I’ve created standard Maven2 project and added javax.servlet:servlet-api:3.0 dependency. And what? Nothing – there is no such dependency in all maven repositories! I’ve looked in:
– http://repo2.maven.org/maven2/javax/servlet/servlet-api/
– http://repository.jboss.com/maven2/javax/servlet/servlet-api/
– http://download.java.net/maven/2/javax/servlet/
– http://download.java.net/maven/1/javax.servlet/jars/
Then I’ve found 3.0-alpha-2-SNAPHSOT in http://download.java.net/maven/glassfish/javax/servlet/servlet-api but now we’re 2 months after official JavaEE 6 release, so I’m not interested in alphas.
Finally I’ve found proper JAR (+sources! that’s rare with JavaEE jars) in … http://download.java.net/maven/glassfish/org/glassfish/javax.servlet/3.0/ but wait – groupId = org.glassfish and artifactId = javax.servlet. So if I want to build, say, a framework based on asynchronous servlets, I have to express a dependency on org.glassfish?
The most official artifact is located in http://download.java.net/maven/2/javax/javaee-api/6.0 – but with NO SOURCES! And again – does my new, hypothetical framework have to use javax.javaee-api as a required dependency? JMS, JAXB, JAX-RS, JPA for an asynchronous processing framework!?
So as always with STANDARDS – there are lot of (JARs) to choose from – every app server has its own version of servlet-api: Tomcat, Jetty, Glassfish, … Just try to download servlet-api-2.5.jar from few repositories and then from jcp site and then from java.sun.com site – they’re ALL different.
That’s why I like “non-standard” frameworks – Spring is just predictible. spring-core-3.0.0.RELEASE.jar is the same across repositories AND springsource.org site.
Maybe someone likes the diversity in servlet-api-2.5.jar, but I don’t…
best regards and lets wait for JavaEE 7
I think you have a point about the blurred line between the API and the implementation (in which case maybe these Maven API artifacts to be used in “provided” scope can help : http://repo1.maven.org/maven2/javax/javaee-api/6.0/) but I’d argue that an SDK’s goal is to enable easy development of applications which I think this one does well.
Also you should probably depend on a platform set of APIs (Java EE 6 or its Web Profile) rather than on a set of individual APIs.
I also think “lightweight” more of an implementation feature with “rightsized” more appropriate to describe Java EE 6 IMO.
@Mike
I have exactly the same feeling! Lots of things scattered all over the distribution. And worse – I’m not sure what’s inside exactly.
ps. I haven’t looked into Manifest in javaee.jar. At least I have found jms and jta APIs… in, well, open mq distribution bundled with glassfish
. Thanks!
@Grzegorz
That was my plan: to check maven repositories. Seems thing are not much better here
. Thanks for Your hints.
@Alexis MP
As I said. It could be only me complaining (+ Grzegorz and Mike
. I don’t know. Seems not much people care too much. I cannot find almost anything concerning SDK – thus this rant.