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

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.

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.

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

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?

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.

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.

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?

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

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.

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

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