John Reynolds's Blog

Java EE should be an implementation

There, I've put it in writing... Enough of this madness. Java EE should be an implementation, not a spec.

Joseph Ottinger has posted an interesting editorial over on TheServerSide entitled: "Where Java EE goes horribly wrong." In the blog, Joseph relates what a pain in the butt it is to port an application from one Java EE implementation to another.

Joseph's experiences seem all too familiar... and all too unnecessary.

Do we really want Java EE to be a spec?

Do most of us really benefit from a slew of Java EE implementations?

Wouldn't most of us really rather forgo the pain and have one official Java EE implementation?

In my thinking, Java EE has become an integral part of the Operating System. My products require it's presence, and the line between features provided by the OS and those provided by the Java EE app server is very blurry to my clients.

Back in the 80's there were a multitude of Unix implementations (most of which were tied to a vendor's hardware platform)... and all of them had quirks. Things got so bad that a truce was declared and the Unix vendors tried to collaborate on a common specification called System V. These unification efforts never really overcame the perception that Unix was fractured, and the door was left wide open for Windows NT and Linux to dominate the Server OS landscape.

Today, a multitude of Java EE implementations (with all the unavoidable porting quirks that go along with multiple implementations) is leaving the door open for implementations (products), such as Ruby, to perhaps take the lion's share of the market.

As with Unix and System V, it may be too late for Java EE to formally consolidate on a single implementation... but I sure would like to see a single Java EE implementation dominate in the same way that Linux dominates the Unix world.

Comments

• Uhh... those who can't program worth a damn write specs? etc..
  

  Posted by: varan on April 08, 2007 at 01:08 PM

• I'll bite on this one.

  Suppose Sun came out with Java on Luge Tracks without a backing specification. What would be its goal? To host applications? Don't all of the application servers on the market host applications well in their own way? For different companies and users, isn't there a myriad of reasons to pick one over the other?

  To put it another way, why does a company typically, in its RFP process, require that a vendor be at least able to claim that they are SQL-based but database-independent? I think the answer is: the specification (SQL 92 or SQL 99 or...) insulates that company from a certain level of risk, viz. the risk of parking on top of a data platform for which there is no "accepted" specification (think object databases or, for the moment, RDF). I think the company also knows that there will always be porting issues, and there will be costs associated with those issues, but that in the long run said porting issues cost much less than the risk associated with lifting an application wholesale off of one platform and rewriting it for another.

  To belabor what I hope is the obvious, that's the win from JavaEE's being a specification. As a purchasing company, you are at least guaranteed that (ostensibly) the thorniest issues are covered already by all conformant platforms, and that only the (ever-present, unavoidable) porting issues remain.

  So, if JavaEE were just an implementation--and by that I assume you mean Just Another Application Server, i.e. Glassfish without the bureaucracy--I think it would actually lose customers, not gain or help them.

  Best,Laird

  Posted by: ljnelson on April 08, 2007 at 01:50 PM

• Very well put Laird, and your analogy with SQL is a good one. Porting non-trivial applications between different DBMS systems is as much of a pain as porting between Java app servers.

  I think that the key difference is that SQL was well established long before Open Source became prevalent... Linux isn't scary. If you don't like one vendor, you can choose another.

  I think that the fear of vendor lock in is a fear of economic blackmail, not of technical merit... With an open source license, you really don't have to fear economic blackmail.... so I don't think your prediction of lost customers would come true.

  John

  Posted by: johnreynolds on April 08, 2007 at 05:56 PM

• I guess my point is more that look, JBoss (to take an arbitrary example) has been out there for a long time. It does many things differently, and many odd things well. If you close your eyes to the fact that it happens as almost a side effect to implement parts of JEE, it is a great application server that hosts applications well. It is open source, it has ways to address what the JEE specifications deliberately omit, etc. etc. It even has lots of market share. And yet it is not the de facto standard behind which I think you are advocating people get behind. So what have they done wrong, that does not render them the "implementation" of which you speak?

  Best,Laird

  Posted by: ljnelson on April 08, 2007 at 06:32 PM

• Laird,I think that JBoss labored under the burden that they had to comply with "someone else's specification".Sun defined J2EE... JBoss merely implemented it (more or less).Linux does not suffer from the same problem, because Linus controls the "spec" and the implementation.With Open Source Java EE from Sun itself we now have a situaton much more like Linux.It may be too late for Java EE, but maybe not.John

  Posted by: johnreynolds on April 08, 2007 at 06:38 PM

• 
  Hi John. Usually I agree with you but, on this one, I disagree. Here are some arguments pro-specifications, not trying to be exhaustive..:

  A functional specification is required for backward-forward compatibility. The specification is necessary not just so that you can verify that new implementation changes are acceptable to the users/customers, but also so that users/customers know what the APIs do, and which APIs have a long-term commitment, which do not, etc.

  Having a single implementation is a bad idea. It stiffles innovation and competition. This is bad for the quality of the implementations, and for the customers. Open Source does not change this.

  I also find value in having a clear separation between the "more stable" Specs (like the JCP) and the less stable APIs (say Tomcat) that change more quickly and can more easily break compatibility.

  ... this is not to say that having specifications do have some disadvantages. They do... But, overall, I think they are a win.

  And I would advocate for the same even if GlassFish already had the majority of the market share :-) - eduard/o
  

  Posted by: pelegri on April 08, 2007 at 07:40 PM

• Eduardo,Thank you for your comments... but please elaborate on why a standard implementation would stiffle innovation and competition.The only invovaton that is possible, within Java EE itself is in how the specification is implemented... and unfortunately much of this "innovation" is due to differing interpretations of the spec.The remaining "innovations" that vendors trumpet are features that are not covered by the specification.... and it is generally these "features" that make switching Java app servers a pain.In my experience, customers would be better served if the differences between Java EE implementations were erased... so either the specification grows to cover much more, or we go the Linux route and use the same source.

  Does that make sense?
  John

  Posted by: johnreynolds on April 09, 2007 at 05:22 AM

• 
  re: features not covered by the specification -
  I agree there is value in a complete specification, with the caveat that there is a danger in over specifying (so only one implementation approach can be used) and in specifying too early (and making mistakes / missing opptys).
  The intention in the Java EE series of specs has been to steadily expand the envelope of what is defined in the spec as the community understands best how to do that. Sometimes it is not going as fast as we want, though. There are ways to try to balance that, and one of the goals of Java EE 6 (extensibility) is trying to address that.

  re: Standard Implementation & Innovation -- My main point was why you need a specification, not just a standard implementation. But, on your question on whether innovation can be acheived in a "standard implementation" -- Yes, it can...

  To allow innovation (in implementations) you need to be able to transparently move existing Apps from the old implementation to the new one. That is very hard without a carefully designed API (i.e. a Spec); otherwise you get all these dependencies creeping in, often without the App designer realizing it. In some Apps you can say: "just rewrite the dependencies", but that is usually not an option. That's why I say a good specification is needed for innovation.

  Now, if your standard implementation has well defined APIs (a spec) *and* the implementation is defined in a way that those modules can be replaced *and* the social dynamics are such that these alternative implementations are given a chance to be tried, *then*, competition & innovation can be achieved by having "competing" / "alternate" teams trying to do innovate around those well defined boundaries. That is one of my goals for GlassFish; some in v2 and more in v3.

  But those *and* are big ones. And even when the implementation is trying to be pluggable (which we are going to try hard in GF v3), there will be assumptions that will need to be done, so, I personally, see benefits in having a few good implementations competing in the marketplace of ideas.

  A separate point goes around Innovation in APIs.
  I think Java EE 6 will help with its themes of extensibility and profiles, we will see. GlassFish v3 is build on a modular system, to support this type of approach.

  How does all this sound? :-) - eduard/o
  

  Posted by: pelegri on April 09, 2007 at 06:33 AM

• 
  Linux does not suffer from the same problem, because Linus controls the "spec" and the implementation.

  If Linux "controls" something, it's the Linux kernel. But an OS is not made only of a kernel, you need libraries, applications, GUI, etc...

  Please, don't use that analogy, or you will summon the whole 'GNU/Linux' discussion...

  Posted by: felipeal on April 09, 2007 at 07:43 AM

• 
  You know, it's hard for me to even imagine where Enterprise Java, much less Java itself, would be today without the assorted JEE specifications.

  If anything has driven Java to be a primary development platform on the planet, the JEE specs are most probably the front of the line.

  
  Where was Java before the JEE specs came out? (And I'm being inclusive not simply JEE itself, but also the Servlet spec before it was integrated with JEE)

  
  It certainly didn't have the traction and scope that it does today, and I'd argue that it wouldn't be as popular as it is today without the specs.

  
  Why? Imagine if there were no servlet spec in the beginning. Look where we are today in terms of Web servers: we have 2 -- Apache and IIS. Sun has the Netscape server but it certainly doesn't have the mind share of the other two, specifically in terms of 3rd party applications that run on top of the server save via CGI.

  
  Yet how many different servlet containers do we have today? Tomcat, Jetty, Caucho, IBMs, BEA, JRun, Glassfish, Sun Web Server, Orion, Oracle, and I'm no doubt missing others.

  Yea, some of those were forks from Tomcat, but certainly not all of them.

  Each of those fills some niche somewhere.

  But do you really think that there would be that kind of room for that many DIFFERENT Java web based application servers? Each one with a different model? Each one presenting a different API?

  Heck no. These exist and have place in the market because of the specifications, not in spite of it. Because of the specification these providers can sell their software on THEIR value, on the areas where their servers stand out from their competitors. Value, performance, support, documentation, management, integration, whatever. Rather than all of these providers recreating the wheel, they leveraged the "Wheel -- Now with axles in 2.0" spec, and built carts on top them instead.

  How is this a bad thing?

  It's not like there weren't application servers before JEE. They didn't make this specification up out of whole cloth (despite what many may think ;-)).

  But what the specifications did was not just level the playing field, it's raised it as well. Here's the basics of ANY app server. Here's the minimal expectations. You need to deliver at least this much to even play the game. But if you do deliver it, you'll be able to play with everyone.

  
  We don't have "Weblogic" programmers, or "Websphere" programmers. We don't have JBoss, Glassfish, Oracle, or any of the other mutlitude of JEE servers "programmers". We have JEE programmers that may have more experience with a particular implemenation. Who may be specialists in in BEA or Geronimo. A SAP specialist knows the details of the implementation above and beyond the specification to gain that extra bit of performance or functionality from an application deployed there.

  But at their core, they're JEE programmers. Those skills used to make Websphere sing can still work on Glassfish.
  But back in the day, all of your Tuxedo knowledge was essentially worthless against Borlands App server. Java or no Java.
  And that's where we would have been without the JEE spec.
  We'd have a bunch of diverse, unrelated Java servers. A scattered knowledge base, and a completely fragmented market.
  Any decision you made had far reaching consequences because of how tightly you'd be bound to app server. You'd have pretty much zero portability. For example, I know of a fine App server you can program against in "Java" -- It's called .NET and you can use Visual J#. Now imagine a dozen of those.
  But we don't do that today. It's insane. The closest we come to today is Spring, but it at least uses the Servlet container. Do you think Spring would be as popular as it is today if they wrote their own web tier stack? I don't.
  And with the adoption of many of Springs tenets in the latest JEE specification, Spring is more marginalized as an independent implementation, with JEE moving it in to the mainstream.
  But see, that's the power of the specification. Before only if you used Spring could you get its benefits. Now "everybody" gets some benefit from what little of Spring has crept in to the JEE spec.
  And the same with JPA. Before Hibernate was a popular library, but now it's bundled. Now there's "no excuse" to not use it, so everyone benefits.
  The JEE spec, warts and all, gives the entire community a mechanism to grow and innovate. No, it doesn't move as fast as the individual projects, but that's not a bad thing. Corporations tend to not move that quickly either.
  In summary, if JEE were a single implementation, it would be nothing. It's not THAT good. If JEE were a single implementation, we'd have a lot of OTHER implementations. Incompatible and fighting over the market share and developers.
  But as a single specification, with wide adoption, it's a powerhouse of value to the entire Java enterprise market and the folks who work in it.
  As a single specification, it's an engine of wide spread innovation, since every change get vast exposure.
  As a single specification, it has to move slowly. It's obviously designed my committee, it's obviously surrounded by bureaucracy. All of those warts come through.
  But, like Congress, despite the madness of the process, the compromises, details put off or lobbied for by "powerful partners", overall it's not that bad. Tho the JCP is "all powerful", it's still the market and the developers that have the final say on anything they put out. And they know that. An unadopted specification is no specification at all and all of that time would be wasted.

  So, I'm a "Rule of Law" kind of person. I LIKE specifications that are widely accepted, and the JEE specification is a good thing for everyone in the Java community.
  

  Posted by: whartung on April 09, 2007 at 10:29 AM

• Whatung,Thank you for your thoughtful reply... but let me offer a different perspective.Back in the old days, before the IBM came to dominate the world, there were dozens of competing operating systems. When IBM sledgehamered the world into using a single operating system (which wasn't very good) it opened the floodgates to create applications on top of that operating system (the dawn of "shrink wrapped software").For a few years there were attempts to create operating systems that were compatible with the beast known as MS-DOS, but the fact was that there were inconsitencies, and vendors wouldn't certify that their applications would run on anything else.

  In Java EE land, we really do have Weblogic programmers and JBoss programmers and Websphere programmers. As a Java EE product vendor, we have to staff our support groups with Weblogic gurus and JBoss gurus and Websphere gurus.I don't want to overstate the problem... the differences between Java app servers can be dealt with... but don't underestimate the problem either.Most customeres are locked in to whichever Java app server they happen to choose... Just ask the JBoss and Oracle folks how hard it is to get a company to switch.
  It's time for us to stop focussing on innovations at the relatively lower levels of the Java EE infrastructure and to start focussing on innovations at the higher levels that are of more concern to our paying customers. Perhaps my suggestion is way off the mark, but it certainly would make things easier for those of us who sell products that aren't middleware.

  Thanks again for sharing your perspective, it's certainly as valid as mine.

  John

  Posted by: johnreynolds on April 09, 2007 at 03:18 PM

• I dont think the differences between platforms are that huge.. Sure you do need to choose not to use the vendor apis, and this can seem limiting at times, but IMO the benefits of taking the party line makes life easier..

  I've ported j2ee apps from websphere to jboss, and it wasn't as painful as I would have imagined (xdoclet was a big help).

  I think there's a general problem with using too many open source solutions together, they tend to have different apis, emply different idioms. Not to mention all the jars, and hoop-jumping. Use plain jee at much as possible and these problems are reduced.

  The jpa EntityManager hits the note just right. Working between toplink and hibernate things so far seem like most things are supported in a pretty standard manner.. Its not like servlets have ever really presented huge porting problems.. The only thing that I think smells a bit with jee 5 is jsf, I'm not sure how it made it into the spec when there are still so many rough edges..

  Mark

  Posted by: melowe on April 10, 2007 at 12:32 PM

• I saw this in a blog by Cringely:
  "This reminds me of the problems Silicon Graphics (SGI) and NeXT Computer had making their machines work with the Network File System (NFS) protocol back in the late 1980s. NFS was invented by Sun Microsystems and published as an open standard for accessing data on other systems using a remote procedure call. Dozens of vendors supported NFS, but SGI and NeXT couldn't get their machines to interoperate. What turned out to be wrong was that SGI and NeXT both wrote their NFS code from scratch using Sun's published specification, while all the other vendors generally lifted Sun code and concentrated on making their implementations interoperate with Sun's, the de facto standard. BUT SUN'S NFS CODE WASN'T COMPLIANT WITH ITS OWN SPEC."
  So much for specs....
  John
  

  Posted by: johnreynolds on April 13, 2007 at 05:24 AM

• John,
  I think your analogy to linux platform is reasonable. They have quite several similarities. Individual organizations implement the so-called spec, but don't stick to it, and never tired to make their own implementation migrate well to or from others'.

  MS's centralized development has its advantage. Everything seems to be coherent, users can immediately see what's in it, and don't need to waste time finding this or that. Legs and arms are always function together, because they are created together. For most of users, their need are met well by a centralized development team.

  How about the less common requirements? A centralized team has enough money (because this team is made for money) and time to consider any needs from any COMMON user, but if a requirement is not so popular, the team will take caution and think what it can get from fulfilling the requirement. And eventually it may just drop it.

  This is where a distributed team come to handy. In a community, whether a requirement is common or not, if people feel that's useful, however small the implementation is, someone will do it. So the software distribution in a distributed team is really diverse. Theoretically, you can always find what you want, because there must be someone has the similar problem as you have.

  In a distributed team, the problem is you always have to search. These pieces of software are just independent, and no one bother to tie them together, and no one could guarantee they function together, because they are created independently.

  However, the truth that these software are not tied together doesn't mean they won't. A distributed team always has people to fill the required niche, but only when the niche is there. If at a point of time, the requirement of being coherent is so urgent, some one will do it.
  Make tomcat project work correctly in glassfish, a simple program(or script) might do the trick, but there must be someone to do it.

  Think about ubuntu in linux world. Before it linux was still so hard to use, and installing software always needs lots of searching and adjustments, and if error occur, there should be more searching and adjustments. Softwares don't function together with softwares, because linux softwares are developed by a tremendously distributed team. It will be too much effort to let each team member to take care of compatibility to all others. But eventually some one (Mark Shuttleworth) was there to put them togeher(sorry I ignored redhat, etc. 'coz I don't use linux regularly until ubuntu), Why wasn't there any-buntu years ago? I think that's because the niche was not clear yet, and the utility niche has not been filled enough to make the tie easy to do. If there wan't nfts-write support, if there wan't pnp support, if there wan't java's open source, etc, it'll never be so much fun in linux like today, even if Shuttleworth has the same thinking and programming power.

  The same saying goes for JEE here, as more and more small niche are fulfilled, at a point of time, tie will become so easy that eventually some one will do it, I believe.

  Though, I hope, I can live to see it. :-)

  Posted by: zaya on June 20, 2007 at 08:46 PM

This work is licensed under a Creative Commons License.