Comments on: On the Death of Java EE, aka, J2EE

By: People Over Process

People Over Process — Thu, 07 Sep 2006 23:01:54 +0000

El Rey de Café

As tbray mentioned, Sun hired “The JRuby Guys” today (rather, announced that they had). We were discussing the announcement in #redmonk (you were there, right? If not, check it out), and most folks seemed quite happy with it. I, of…

By: Cote'

Cote' — Thu, 20 Jul 2006 15:47:37 +0000

Don’t forget XML. The Java Inquisition also employs the might XML in it’s arsenal of devices.

By: Anonymous

Anonymous — Thu, 20 Jul 2006 02:59:20 +0000

NOBODY expects the Java Inquisition!

“Java EE programers want two things: transactions and scalability” …and tools…. Our *three* wants are transactions, scalability, and tools…and an almost fanatical devotion to the UML…. Amongst our weaponry…are such elements as transactions, scalibility, tools, UML, and… nice IDEs – Oh damn!

By: Cote'

Cote' — Wed, 19 Jul 2006 23:02:54 +0000

Hah! ;) Of course, you’re right, Alexis. I didn’t mean to exclude that. Those are just the two, you know, “primary” things that always jump out at me about JEE coders.
I’ve heard good things about Phobos but haven’t checked it out hard-core yet. I’ll have to short-list it. Maybe I can get a briefing from Sun.
Thanks for the kind words on the podcasts.

By: Alexis MP

Alexis MP — Wed, 19 Jul 2006 21:35:01 +0000

Java EE programers want two things: transactions and scalability They also probably wouldn't mind some "productivity" with that :-) On the dynamic languages, Sun is doing interesting (IMHO) experiments such as the server-side scripting Phobos project. Great podcasts btw (both of them). Thanks.

By: Cote'

Cote' — Wed, 19 Jul 2006 16:25:22 +0000

I agree. Bloat is due to the curse of backwards compatibility. Java and JEE will never cut fat just in case someone is using that fat.
Cutting fat would give crazy cool simplicity, but as Bloch pointed out in his API design advice (here, among others), once you add public code in a “public class,” you can’t ever take it back.
The cure for this when I do and think about JEE is to just ignore all that crap. That’s not a good cure but it’s what people did for years, ignoring EJB.
As you point out, that means that you have to start using “all of the really slick, low-code APIs” which makes you think, “am I really doing JEE?” Perhaps not: you may just be treating JEE as a runtime/container, for JTA, servlets, JSPs…that is, treating JEE as a buffet to pick and choose from, just like you’d do from Jakarta, Codehaus, etc.
And your JDOM vs. example points out the Red Headed Step Child point of discussion. It’s simply crazy when Java and JEE ignores existing de facto API standards in favor of newly created things. For example, I’m not really sure why Hibernate wasn’t just sucked into JEE. Well, I know why — vendors on the JSRs didn’t want to — but it seems like reinventing the wheel.
Open sourcing Java and JEE might help cure things like that. Of course, in the gloom and doom open source scenarios, it just causes more bloat. Hmmm…something to think on.

By: Scott Mark

Scott Mark — Wed, 19 Jul 2006 07:14:46 +0000

I still need to read that report, but I think the fundamental principle that JEE is bloating is correct. It's insane to me that by this stage, scripting or *at least* and interpreter (Groovy, BeanShell) hasn't become integral. It's also amusing that all of the really slick, low-code APIs (think JDom vs. Xerces) come out of small incubators.

I still think Java has a lot going for it, but simplicity is not a feather in it's cap (was it ever?).

Scott