J2EE Is Dead - Completely Dead | Hacker News Reader

J2EE Is Dead - Completely Dead

adam-bien.com

38 pointsGarbage43 comments

copy pasta because the server is dead (completely dead) ;)

J2EE 1.4 or officially: "JSR 151: JavaTM 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification" was released at 24 Nov, 2003 and was designed to be used with JDK 1.4, J2EE 1.3 was released at 24 September 2001 and is more than 9 years old now. In JDK 1.4 there were no annotations available, so you had to configure everything with XML. J2EE 1.4 is more Configuration Over Convention, than the current - more reasonable opposite principle of Configuration by Exception or Convention over Configuration. If I read or hear "J2EE" I always have to think about xdoclet with about 50 lines of XML, a Home Interface, Remote Interface and an unrelated Bean class just to implement a helloWorld() method. ...with Java EE 6 a helloWorld() takes exactly one line of code - as it should be.

Even JDK 1.5 is End of Service Life and so officially dead for greenfield projects as well. Most of the J2EE 1.4 application servers were not even officially supported on JDK 1.5, so it is truly ancient technology. However: there is more interests in Java EE 6 - measured in number of session attendees at conferences, blog statistics, number of sold books :-) and project requests, than ever. What also amazed me was the result of my informal surveys after talks at various conferences (JAX, W-JAX, JavaOne and Devoxx). The majority of attendees do use Java EE 5. The minority is using J2EE 1.4. Even the number of Java EE 6 projects seems to be slightly higher, than J2EE. ...and Java EE 6 is only one year young... So J2EE is dead, but Java EE 6 rocks.

I always have to think about xdoclet with about 50 lines of XML, a Home Interface, Remote Interface and an unrelated Bean class just to implement a helloWorld() method

It amazes me that when people say "J2EE" they're really describing "EJB"

And not everyone was using xdoclet.

One lesson from that fiasco: Just because all the giants of the day are supporting something doesn't mean it's any good.

Struts comes to mind, possibly one of the worst web frameworks ever created.

So before anyone thinks he is referring to Java on the enterprise in general; he is not.

Java EE 6 is the current Java enterprise solution.

J2EE is the old, e.g. 1.4 or 1.5. Java EE 6 is far better, and technologies like JPA and JTA are quite powerful. There's also a lot less boilerplate code than before. As another poster said, Java EE 6 rocks for enterprise development, particularly with large teams.

I tried out Java EE6, I was impressed on the improvements they have made. Once you set it up correctly, you get quite a lot of stuff for free.

Anyone else noticed this: when you Google for Java related stuff, Google's magic stops working, and you get into a sea of outdated and confusing pages from all kinds of sources.

Also, for most of those results, you'll get some horrible unusable web site, probably with serif fonts to compliment.

Yes. You can choose to view only results from the past year which helps but Google really need to fix the problem of previously highly ranked pages becoming obsolete over time.

This is more a reflection of the whole Java ecosystem. I am currently maintaining an application that runs - and will continue to run until it's EOL'ed - in Java 1.5. Not that 1.6 is that much better.

Also, there are lots and lots of people who learn just enough Java so they can get jobs in programming. Body shops hire them because they are cheap and because none of their clients, who demand their products to be written with enterprisey brands they read about in enterprisey magazines, will ever look into the code they write. Unfortunately, most of them also learn HTML and build websites.

And that creates the problem you see.

I haven't noticed this. Do you have any example search terms?

This happens with ruby and python as well, though not as often. As always, limiting to things from at most two years usually does the trick.

For a few reasons, I had to take a job maintaining/enhancing some huge government Java applications (largely Oracle based). I thought that there was some interesting things going on in the ecosystem because of what I read about all of the JVM-based hacking. I thought that because all of this hacking there would be a lot of solid, well integrated tools and good documentation.

I had successfully avoided Java for most of my career, so it was also an opportunity to learn something new.

That was a terrible mistake. It's almost impossible to find answers that are relevant. There is very little readable documentation, even directly from Oracle. When you do find a relevant bit of information on a forum or blog, it's either outdated or useless because the author doesn't specify what their environment is.

I asked my colleagues for books, blogs or other resources to help me get up to speed. They pretty much laughed and said I'm out of luck.

I won't complain about the tooling. It's bad, but that may be more a matter of taste than anything else.

I have to respectfully disagree. The docs of just about every java library or framework I've looked at or used have been extensive, detailed and complete.

But are they readable? Relevant? Useful? They're certainly better than nothing, but there's more to good documentation than completeness and detail.

I wonder how much overlap there is between the packages I've used and the ones you've used. I've only been in the Java world for about 3 months, so my perspective is definitely raw and incomplete. Maybe we just have different criteria for what we consider good documentation.

No, I never noticed that. It's weird how everyone in the startup community hates on java, when it's probably the most popular language in use today (source: SO tags) - far outstripping trendier languages like ruby, python, erlang, go, or this seemingly insatiable desire to re-write every framework in javascript.

It seems to me that the number of third-party OS libraries and frameworks available in java, both in terms of breadth and state-of-the art, far outstrips the resources available in other languages. It's virtually the default choice for enterprise systems, and a vast array of academic research is also java-based, resulting in a hugely rich eco-system.

I just don't understand why java is not better embraced or more widely adopted amongst the startup community.

I just don't understand why java is not better embraced or more widely adopted amongst the startup community.

Because other languages are faster for rapid prototyping.

Prototyping Webapps? Maybe. But with Wicket or Tapestry the dev cycle is pretty quick.

Only when comparing to other J2EE frameworks.

After 6 years as a java dev Tapestry 5 was what made me give up on java and move to rails.

I didn't get that from his comment. I used Java at a startup (shocking I know!), and most of my Google searches returned stuff for Java 1.4.

(ex. I just googled system.out.println and it pulls up Java 1.4.2)

Because it's simply more painful to do many things that should be trivial. I have about 8 years of java under my belt and I rarely use it anymore (only a few times in the last 3 years). Instead I use one of those trendier languages... all of which you list are long past the possibility of being only a trend.

There are definitely some great reasons to use java for certain tasks, specifically due to the wide range of library support. If I had to use Java for a greenfield project though I'd probably take a serious look at groovy.

I know of a startup using Java and SEAM Framework: http://seamframework.org/

They're doing pretty well for themselves too.

I didn't strike out on my own to write in a language that doesn't make me happy, with thousands of over-engineered libraries that don't do anything I want to do, that's owned by a company that's running around suing people.

After a certain point, there's a base of libraries that is Large Enough. I've never really been wanting with Ruby, at least not in the 'oh, but there's this Java library that does exactly what I want' sense.

Even then, JRuby would make it Just Happen, or maybe even SOA.

There's a hell of a lot of stuff out there written in C as well, that integrate quite nicely with PHP, Python, Ruby and other 'trendy' languages.

Having GD embedded in PHP makes many image processing tasks far easier and less painful than trying to do stuff using Java image libraries (for example).

"It's virtually the default choice for enterprise systems" then "I just don't understand why java is not better embraced or more widely adopted amongst the startup community"

"Startups" and "enterprise systems" are, in many (most? all?) cases, worlds apart in terms of needs.

I say this as someone who's done PHP for 14 years and Groovy/Grails for 3.

> "Startups" and "enterprise systems" are, in many (most? all?) cases, worlds apart in terms of needs.

Sorry, I didn't mean to imply that they were; more that the wide adoption by both enterprise and academia has driven the development of a great number of world-class libraries and platforms in java.

I know I have contributed to the java questions on stackoverflow. I have worked in java on and off for 14 years, but the java frameworks, e.g. Axis (of Evil), are often quite over-complicated. The questions are there because of employment and difficulty, not interest and ease.

That said, when I am prototyping, or doing a quick tool, it's usually in Perl. Quicker to write, and runs quicker as well (when single threaded). At least if "quicker" involves I/O, caching in hashes (maps) or sorting/searching. Java is quicker than Perl if you are twiddling ints, or throwing all your data away just after the network gives it to you, though :-)

Ruby is nice too, but I have done quite a bit less of that.

I do use Clojure for my startup.

Nope I use Duck Duck Go

It's like that for pretty much every language, and really bad for Microsoft technologies. When you are looking for C# advice, apparently Google can only find outdated advice from terrible sites like CodeProject and ExpertsExchange.

I've seen some good results from StackOverflow, but this is pretty spot on. If it doesn't link to either of those two sites or SO, then it may link me to some random programming thread where the problem in question was brought up 4 years ago(or more!) and was bumped 3 times by the author with no or near useless answers.

Ok. Can we please, please, please, please stop proclaiming things dead.

In the past year i have read at least half a dozen articles proclaiming various technologies dead.

The Web, Grails, Java, Telephones, ect...

PS I declare that declaring preemptive postmortems to be dead!

Sadly so is the web server.

Google Cache seems to have it, but it's overall rather thin: http://webcache.googleusercontent.com/search?q=cache:Fbn8cjc... Something along the lines the king is dead long live the king.

Sigh, more sensationalist headlines that really have no content.

Unsurprisingly, old technology is old and new technology is new.

Seems that link is completely dead.

Maybe it's getting DDoSed by a disorganised horde of anonymous pro J2EE teenagers.

I agree, Java EE 6 is a huge improvement to older J2EE versions. I am going to spend some time next year helping a friend's company with a Java EE 6 project so I have recently spent a few evening brushing up on for a much improved platform. Not at all what I would consider to be agile but solid infrastructure that saves time on projects that require many components, high level error handling, uniform messaging, etc., etc.

Thank god for that. As a funny related story: a former boss once made me (told me to) give a talk about J2EE, and I had NO idea what I was talking about. I was a PHP developer. My first year employed on the web. I should have refused, but was too unexperienced. If you were there (Scotland 2001), apologies!

Wow! Sounds like a scene from a (nerdy) sitcom. What'd you do?

I gave the talk. Died a little inside that day.

J2EE is dead because Spring/Hibernate have replaced them because they are the lightweight transactional enterprise application framework that J2EE never was.

We have come a long way from the Java Pet Store.

Can anyone show the one line hello world?

The author links to a page that's not accessible. The google cache shows this page: http://webcache.googleusercontent.com/search?q=cache:3cGnLJF...

copy/paste from the link above

=================

@Stateless

public class SimpleSample {

    public void doSomething() { /*business logic*/  }

}

How to compile:

You will need the the EJB 3.0 / 3.1 API in the classpath, or at least the @Stateless annotation.

How to deploy:

Just JAR the class and put the JAR into e.g: [glassfishv3-prelude-b23]\glassfish\domains\domain1\autodeploy

How to use:

e.g.:

import javax.ejb.EJB;

public class MyServlet extends HttpServlet{

@EJB

private SimpleSample sample;

}

And: there is no XML, strange configuration, libraries, additional frameworks or jars needed...

=================

Looks a slight bit more than 1 line to me. Note: the page was linked to from another page indicating you can do 'hello world' in JEE6 in 'one line' of code. Java people have a funny way of counting lines sometimes.

He should have left out that "exactly". The main point is something he highlights at the beginning, J2EE was the triumph of configuration over convention, it had a lot of xml descriptors and interfaces/utility classes to be implemented (this caused by the some architectural decisions that remind me of CORBA). This stuff was usually auto-generated but you still often had to tweak these file manually. The polar opposite of modern web frameworks.

Reply on news.ycombinator.com