BT

Richard Monson-Haefel: It's too late to save Java EE

by Floyd Marinescu on Jul 11, 2006 |
Richard Monson-Haefel's recently released Burton Group analyst report "Java EE 5, the beginning of the End" has set off a storm of controversy. But what did Richard Monson-Haefel, well known for his popular books on EJB, actually say? Richard summarized the main points from the report on a podcast, summarized here.
Java EE has become the imcumbant technology in a disruptive market.  Although JEE 5 is somewhat similar to previous versions, the simplification is not enough. "JEE5 was a step in the right direction, but clearly it's too little too late to save the platform. Over the course of the next few years, more and more developers are going to move to different kinds of platforms which provide much easier development environments and we'll slowly see Java EE 5 whither on the vine as a standard for enterprise development... organizations should look elsewhere when considering new enterprise development and plan for the eventual sunset of Java EE as an enterprise solution.
What does RMH mean by too complicated?  RMH makes the following points in the report/podcast:
  • Java EE tries to do everything in one platform which makes things too complex
  • The number of Java EE API's "have not been simplified, merged, or been eliminated; they remain in place and continue to be necessary."
  • Java EE's programming model has changed significantly for the 3rd time
  • The API's for supporting Web Services have also changed
  • The "extensive and complex web development framework JSF was added to the platform"
  • The platform has gotten more complicated and intimidating
  • Configuration is not significantly simpler than previous versions
    • Rather than reduce the number of facets that can be configured, the new platform simply shifts the complexity from xml deployment descriptors to source code annotations
    • Developers still need to understand "all the configuration options and their impact on production code" but now can do it in source instead of XML
    • "Rather than have one complex  mechanism for configuration, JEE5 now has two separate but interdependent  mechanisms"
  • "Ease of development has been ignored in favour of breadth of functionality and flexibility. Java EE's primary value proposition has become it's achiles heel."
The report has received a lot of  press coverage and caused a number of discussions. InternetNews and Steve Anglin on O'Reilly discussed if Java EE is light enough.  TSS today commented on an article from SearchWebServices quoting RMH and other analysts on Java EE not being suitable for implementing SOA, so the emergence of SOA will contribute to Java EE becoming the next Corba (dead).  

An important point however is that RMH attacked Java EE, not SE.  "I think the Java programming language is going to continue to thrive and be the mainstay for most enterprise development for years to come." 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

supre by Joost de Vries

Ok, no respone for a considerable while. This is my take on the death of JEE.

I'd like to propose the word supre from the preposition supra- as meaning the inverse of hype, as in the Gartners trough of disilussionement.
J2EE has been the snake oil that would cure everything. Now it's shortcomings are enlarged to visions of it's impending death.

I think a distinction should be made between parts of JEE that are pretty definitive and are used by most alternatives. In this respect JEE is the giant where alternatives are standing on: servlet api& wep app defintion, jms, jta&jts, jdbc(not strictly jee of course). Maybe jsp.
The other category are the ones where I think the specifications tried to standardize where there was not a best solution in the field yet. There where some dunces in this category; entity beans obviously, heaps of xml without defaults. I think JEE suffered in this category too from being vendor driven and hardly developer-driven.

Some parts I find hard too place in those categories; I'm not convinced JSF is as bad as people say. It has been too long in the making of course.

I think JEE suffers now from the fact that it rose to prominence in an atmosphere of a lot of money to spend on development and not a lot of hard questions about the effectivity of these investments. This resulted in patternitis (Core J2EE Patterns that really where workarounds), superfluous abstraction layers, sumptious configuration files. Coding for the sake of coding.

Still JEE has provided a large benefit: it provided some unification of knowledge across vendors and the advantages of scale that come with it. Yes, you can hire a java/j2ee developer and have him being productive on an appserver he has not worked with in a short time. This has been a crucial counterweight to the fragmentation that comes with the endless proliferation of frameworks. Non JCP de facto standards will be able to provide this too of course.

To summarize; the pretty girl with the blinding smile is middle aged now and has a history and shortcomings. And the so called thought leaders and visionaries have left.

I think the combination of the good core parts of JEE and some de facto standards can remain a great development platform and be able to respond to the challenges of .net and ror.

That is unless RMH and other consultants will create a consistent supre and decision makers will start to say 'we must not use JEE because that's bad' where they used to say 'we should use J2EE because that's good. Or if the major backers of JEE should defect as a result of the backlash.

It will be interesting to see what products will become dominant in the non-flexible productive space where ruby on rails challenges java.

Personally I think the really substantial shift will have to come from a truly different way of developing that does not entail so much senseless (from a business perspective) coding, not from the renaissance of Smalltalk. Ruby to me means just a continuation of old fashioned object-oriented coding with a slightly different syntax.

disagree, and perhaps .NET is a good example by Floyd Marinescu

I disagree with some of RMH's points about why Java EE is too complex. He says now we have more APIs. Well of course, the platform is doing more things, that's natural.

He complains that the platform has changed significantly for the 3rd time. Well yeah, it changed to become simpler.

I also don't get the criticism of annotations. It is a step forward to have all the simpler way to configure, not a step back. You need to also support XML in order to provide choice and backwards compatibility. The point about developers still needing to understand all the config options and their impact on production code isn't anything wrong with JEE, it's something developers should know regardless. I'd imagine that even in RoR developers need to know the impact f what the 'default' configuration is.

But back to the subject at hand... I think part of the problem here may be the packaging. Java EE as a big umbrella JSR will be attacked for being too big, doing too much. It's size in some ways slows things down because rather than evolve each sub-jsr quick and nimble, they need to all wait after each other for a full Java EE release. Because Java EE is a complete platform that is tied to the notion of an application server, it presents a very obvious target. This may have been needed back in 1999 when you needed a complete platform to compare against the 30+ appserver vendors, but now it is not.

Perhaps a lesson is to be learned from .NET land. In the .NET world, ASP.NET, Windows Workflow, Windows Presentation Foundation, ADO.NET, etc - these are all separate groupings of functionality (both from an api and marketing perspective) and can evolve somewhat separately. They do not have a big umbrella standard to tie it all together, but they do make sure everything works together.

If we were to follow that model here, we would eliminate Java EE as an umbrella spec and also eliminate the need for appservers to implement full blown JEE. Instead, there could be a Java EE 'baseline' consisting of JTA, Servlets, key infrastructure stuff like that) and then other standards like JSF, JSP, EJB, etc - could evolve on their own timetables.

This would give us a lot less to complain about. Java EE baseline would be the slow-changing underpinning for many other specs, and then programming models for different use cases can evolve separately. Something on the 'low-end' to compete with RoR could evolve quickly and on it's own, and EJB, JMS, and others on the high end could also evolve separately.

Given that appservers have now been commoditized, is the need to have a market place of EE compliant application servers still important? It was important when J2EE first came about, but today it seems like a liability. Perhaps we're better off following a model more like .NET.

Re: disagree, and perhaps .NET is a good example by Tiberiu Fustos

I fully agree with Floyd's opinion. If you look at how companies use J2EE today, this is exactly the model: all rely on the "baseline" represented by servlet engine, transaction manager, JDBC etc. and then the other components are picked and integrated into the platform based on the skills of the developers or specific problems to solve - for example it's very often that in Enterprise environments people don't use the JMS implementation that comes with the app server, but rather the one that is standradised at Enterprise level - not to mention the multitude of frameworks for web applications, web services, business layer etc.

This pattern of using J2EE today makes frameworks such as Spring very valuable, because one can write against a de-facto "portable" layer while still making use of platform-specific enhancements (something that is also well done in Hibernate).

Evolution is good - of course we are all overwhelmed at times with the speed of it - so I also have to agree that the industry (I mean businesses) and the professionals are crying for simplifications. I am just not sure if the software industry has its interestes aligned (I have some examples I will not quote in this thread because they are heavily debated in other areas - just some acronyms: ESB, SCA, SDO, JBI :-) ).

Re: disagree, and perhaps .NET is a good example by Les Walker

Your assumption here seems to be that J2EE is nothing more than a collection of API's. Under that assumption I have to agree with your conclusion about packaging. However, if it's just a collection of API's then what good is J2EE as a brand? .NET (starting a sentence with a period, sigh) is a set of products, not API's.

Under your approach, an application server that doesn't implement a popular extension API will eliminate a segment of the market. The market will decide which API's are the baseline, not the J2EE brand. If you just cut the API's loose from the umbrella, the application server market will experience some disruption and then stabilize. I suspect that it would stabilize on application servers dedicated to specific niches like OLTP, DSS, embedded systems, etc.

Further, the death of J2EE seems to have begun with the admission that it's just a set of API's. There was originally this "gestalt" that this set of API's when combined together gave you a new way of writing programs. But that new way of writing programs was fundamentally flawed. The notion of gluing together a resuable set of business objects never caught on for a variety of reasons.

I'm confused by the relationship between portability and interoperability. The statement seems to be made that now that we have interoperability (SOA) we don't need portability. (J2EE) That seems completely fallacious to me. Interoperability has taken the spotlight away from portability and thus there is less "buzz" around the JVM and standard API's. That doesn't mean that being able to replace one API implementation with another is less important. What am I missing here?

The rebuilding trend by Stuart Charlton

This really is an argument that we don't have enough knowledgeable people to support the platform, and it's too intimidating for people to learn, whether new college graduates or career-shifters. And this arguably is true with any major platform from yesteryear (CICS, IMS, Oracle, SAP, etc.).

It's utter bollocks to suggest that Java EE will go the way of CORBA, as CORBA never really was widely deployed to the extent that Java EE is, and it represents only a fraction of what Java EE is (RMI and JNDI!) Let's also note that many Java EE shops still have a fair amount of C++/CORBA sitting around too.

I think Java EE folks, even the ones now trashing it, have a special set of blinders on, partially due to Sun's old "100% Pure Java" marketing in the late 90's. They see everything through the Java lens, and never saw the worlds in shades of grey. So it's utterly novel to them that there might be other ways of doing things! Thus, Java EE's death being greatly exagerrated.

Yes, Java EE is the dominant programming environment, but there still is tremendous competition. .NET is hugely popular, especially for Windows client development. Sybase and Oracle expertise out there driving major applications through stored procedures. There's still lots of COBOL being developed. I just saw millions of dollars poured into a C++/Vitria project.

Java EE has never been the only game in town. Its dominance is fading, but that doesn't mean that IT is fading. Let's not forget that $$ billions $$ are spent on Java EE with IBM, Oracle, BEA, and the like, and those companies are still *growing* their license revenue, albeit slowly, and more on the integration side of things.

The question is whether there will be another dominant platform like Java EE. Microsoft will always have a huge marketshare for its development environment. Likely there will always be a #2, and likely it will remain Java for the next 5+ years. But it's unclear what, if anything, will unseat it, unless it's "death by a thousand cuts". Windows was the prior dominant platform, which rode the PC wave. Java rode the Internet & web wave. We would need another such wave to create a new dominant environment.

IF SOA is this next wave, then I think we'll see a new pluralism in development languages & tooling, with no dominant standard. Java will continue out of inertia, as It will be cacaphonous in some ways -- few will know what the other is talking about, Ruby people vs. .NET people vs. Java vs. C++ vs. Oracle Pl/SQL vs. PHP vs. Python. But it also will have a great way of balancing autonomy of tooling & innovation with service agreements & contracts -- an approach that Werner Vogels, the CTO of Amazon.com, has said has worked well for them.

Or, it could be that Ruby is the next big wave, but it likely will succumb to the overloading of frameworks & libraries that both .NET and Java have. Or it may go the way of Smalltalk (in the positive sense) if a great IDE is to emerge for Ruby to control the evolving library complexity. And for those who say "I don't need no IDE", I say "see you in 3 years". ;-)


.NET is also making some very innovative moves, and is gaining traction at universities & colleges.

The future will really be about what people spend time to learn & master. Few frameworks have the richness of .NET and Java because they don't have the resources to create such richness. The downside of that richness is complexity, but frankly, there's only so many times you can go "meta" to rebuild your toolset before you have to get real work done. And we're all human - there's no guarantee the next toolset & language du jour will not suffer the same fate.

Re: disagree, and perhaps .NET is a good example by Floyd Marinescu

The market will decide which API's are the baseline, not the J2EE brand. If you just cut the API's loose from the umbrella, the application server market will experience some disruption and then stabilize. I suspect that it would stabilize on application servers dedicated to specific niches like OLTP, DSS, embedded systems, etc.

I think that would be a positive thing development. Let each niche have it's own built-to-suit solution that is based on standard API's. This is happening somewhat in the telco space with OSS/J, which defines new API's and datamodels specific for that niche, but which use components of Java EE itself as the baseline.

The notion of gluing together a resuable set of business objects never caught on for a variety of reasons.

Agreed!


I'm confused by the relationship between portability and interoperability. The statement seems to be made that now that we have interoperability (SOA) we don't need portability. (J2EE) That seems completely fallacious to me. Interoperability has taken the spotlight away from portability and thus there is less "buzz" around the JVM and standard API's. That doesn't mean that being able to replace one API implementation with another is less important. What am I missing here?

I don't think you're missing anything, and I also agree that the notion that interoperability creates less of a need for portability is silly. I think we're just witnessing a hype wave around SOA and interoperability (not necessarily unjustified) but that doesn't mean that JVM's and standard API's are not important.

Re: disagree, and perhaps .NET is a good example by Werner Keil

I fully agree with Floyd's opinion. If you look at how companies use J2EE today, this is exactly the model: [...]
software industry has its interestes aligned (I have some examples I will not quote in this thread because they are heavily debated in other areas - just some acronyms: ESB, SCA, SDO, JBI :-) ).


Unlike Floyd you still keep using the term "J2EE" which with Java Enterprise 5 is really dead ;-)

I agree, for certain purposes, only parts of the Enterprise Java "stack" or other frameworks e.g. Spring can often save a lot of time, trouble and money.

Nevertheless, taking .NET is not really the best example. I just came across a case myself, where Microsoft has just added some "built-in" OS features to .NET sometimes making calls to APIs (like Security and X.509 Certificates in this case) sometimes seem easier. Especially if projects are required to port applications (Rapid Prototypes) from .NET to Java (in our case it is still J2EE ;-) people often wonder, and ask why this is not done 100% the same in Java.

So let me quote myself from an internal memo on this issue

As their (Microsoft's) APIs are bound closely to their own OS, they usually force
those APIs onto developers and something just introduced roughly a year ago (documented May 2005)
by Microsoft becomes a standard there.
With the more federated group of companies like IBM, BEA, Oracle, etc. standards in Java and XML often
take up to 5 years (see SAML 1 which goes back to almost 2000 and is just introduced into BEA 9 now!)

So what SUN documented recently (Feb 06) we require exactly like that from BEA to proceed as in the .NET.


Regarding the applications and servers based on Java Enterprise, a lot of vendors however, are not too different from Microsoft, when it comes to UI and User Experience consistency.

Take BEA's WebLogic and Portal 9.2 as the best example. Sure, version 8 was some time ago, but the changes of their own console and administration tools are so radical no marketing initiative can really justify user's and administrator's burden with that.

Compared to that, you really have to take one's hat off to Google and a few other pillars of simple and self-explanatory design.

Your own (InfoQ's) design and CI is btw also quite friendly. The pop-ups for replies are sometimes a bit awquard and funny (e.g. they appear in different places) but other than thet keep on like this.

And please don't change a less than 2 months old's L&F with every minor version now being 0.7 ;-)

Maybe by Oliver Widder

I don't agree, but who knows?
I think in the IT-realm analysts have a really hard job.
I made a small cartoon.

Bye,
Oliver

totally disagree by Priya Ranjan

<quote>"Over the course of the next few years, more and more developers are going to move to different kinds of platforms which provide much easier development environments and we'll slowly see Java EE 5 whither on the vine as a standard for enterprise development..."</quote>




First of all it's not the developers who call the shot, it's enterprise, the customers.



Second Java could be outdated, but there is no alternative which can scale and match upto enterprise expectation.



Third Java is more of standard and is successful in maintaining that ( JCP ), and any sane enterprise will go for
a standard based platform than some other where a integer could be 8,16 or 32 bit could result in system failure.



Last but not the least it's constructive criticism that benefits anybody, simply saying Java EE is dead without providing an alternate sounds like a Microsoft rant.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT