The open source version of Java Enterprise Edition (Java EE) has been renamed Jakarta EE to satisfy Oracle's desire to control the "Java" brand.
The renaming became necessary after Oracle moved Java EE to the Eclipse Foundation, a shift it hoped would see developers become more engaged with the project.
But Oracle wouldn't …

Re: A turd by any other name

Re: A turd by any other name

Have they cleared the name with the Indonesian Government and/or the city fathers? Or is this a case of the Eclipse Foundation being American and there is no place with that name in the states they think they can use it with impunity.

Reminds me of a while ago when lawyers were apparently firing off take down letters to anyone using the name of "Java" in business. The apocryphal story is that there is now a tourist island "formerly known as Java"

Do-over?

Java EE is a mixed bag. It got started back in the dark days of "we should replace code with XML" so parts of it are incomprehensible configuration gibberish. It lived through the "abstract the abstractions" darks days so it has factories for factories and objects so completely abstracted that they must claim to do nothing at all. It seems like a lot of "EE" could be frozen for legacy apps and replaced with more modern libraries for new apps. RMI would be a good place to start since microservices are all the rage now.

Re: Do-over?

Sad times...

Well, sort off. I still think the Glassfish project, as started by Sun Microsystems, is an impressive one and I also think it's somewhat of a shame to see it go down like this (no offense but I'm not very confident about the outcome). Typical Oracle mindset, let's not call it for what it is because there may still be some money left to squeeze out.

Oh well, for me these are times long past and in my opinion Apache is the better choice. The Apache HTTP server for the web layer, Apache Tomcat as my servlet container and finally Apache TomEE as the EJB container. The best part (in my opinion) is that because these are three separate processes you basically get a more "real" container separation than when you run the whole kaboodle within Glassfish.

Now, Glassfish also has very good tools for fine tuning but in my opinion nothing beats having physically separate processes so that you could even apply limitations on the OS level if you wanted to.

It takes getting used to, especially if you're used to Glassfish, but once you get your fingers behind it you'll soon discover why many Java developers would have preferred to see this project being hosted by the Apache foundation. Time will tell I suppose.

For legal reasons

Do-over

Kevin McMurtrie wrote: "... It lived through the "abstract the abstractions" darks days so it has factories for factories and objects so completely abstracted that they must claim to do nothing at all ..."

—and provided a ghastly reminder of some horrifying modern coding habits. I know of people—who were never particularly good coders, but always imagined that they were brilliant—who, if poorly managed (i.e. working for an English-speaking Anglo-Saxon company), would choose to find work they liked rather than what the business really neded to be done. That work would ofttimes be trivial cosmetic stuff that had neither importance nor urgency. Sometimes it would be trivial exercises like writing reports for the business users—which the latter were supposed to be doing themselves already.

But, when denied these opportunities to squander their (often quite generous) salaries on needless tasks, they would turn to the wealth of make-work offered by Abstraction. A piece of code, an API, a service, some kind of interface, anything at all really, would be targeted for "improvement" and, before you know it, something that had worked perfectly well for months or years would abruptly vanish behind another layer of calls, wrappers, settings, interface addresses, logins, authentications and wotnot. Pompous emails would arrive informing us that such-and-such had been "deprecated" and that a "refactored"¹ or even "new" version must be used (causing 27 other systems to require changes to preserve interoperability), citing mysterious enhancements and improvements which, even if no immediate advantage could be discerned, would make the business ready for whatever IT-BS-phrases would be fashionable next year.

No useful additional functionality would appear; sometimes it would disappear; new bugs would emerge; everything would now take a little longer, dramatically so if a cluster of witlessly recurring and poorly tested "checks" were included; here and there would be plastered long and important-sounding new names and labels for things; release notes—lacking important, pertinent information—would nonetheless feature the author's name and assorted samples of the current buzzword drivel thus "cloud-enabled", "AI-compatible" with "high-volume messaging potential" and "enhanced security".

You end up with endless layers of utterly valueless complexity, as abstractions of wrappers conceal layers of indirection of wrappers in thickets hiding jungles of abstractions of code wrapped in wrapstractolayers. Sometimes the only bit that was well-written, after you'd churned through 39,231 lines of wrapping, was the original 207 lines of core code.

Observing this behaviour (in other people's teams, I promise you) I went through various stages of disbelief, disgust and even anger, but eventually came to understand this by a simple analogy.

Bad coders, under-tasked, under-trained and under-managed, gravitate to pissing on things ... just like dogs. "Look how important and clever I am: I just peed here!" It really does seem to be that simple. (And explains some other habits of mediocre male coders.)

¹My term for this process, now cautiously adopted by those unfortunate enough to have worked with me, is "refucktoring". As in, "Chris refucktored the code for SystemTwo and now it keeps barfing".

Re: Unsurprising outcome

When you want to force the use of a particular name which you've already decided on in committee, you give the greater group a choice between the one you want and something or somethings completely unpalatable.

Krakatoa East Of Java

Re: Krakatoa East Of Java

Well, yeah. And no. Krakatoa is more or less the Portuguese spelling of it, and the Indonesian name is Krakatau, but technically if you go far enough east of Java, you would end up at (now anak-)Krakatau. You'd hit Zanzibar before that actually.

Jakarta vs Java

Java is known for overly engineered APIs

I haven't been doing a lot of Java programming as of late, but, I seem to recall one of my favorite APIs/classes was XMLGregorianCalendar. It didn't have a constructor. You had to use a separate factory to create it. And on top of that the factory method threw a checked exception that occurred if there was a problem with the configuration file. That should have been an unchecked exception because there would be no way to recover from it. Also, does a Gregorian calendar class really need to be pluggable? Never mind, I have no idea why that class should be needed to begin with. It should just use a standard Date class. It seemed ridiculous to me. Java was already starting to have issues keeping up with .NET before Oracle. LINQ for example left Java in the dust. Once Oracle bought out Sun, it hasn't gotten better. I wish that Java EE were more successful than it is. For example JavaServer Faces. It had it's own issues, but, eventually they were mostly sorted out. However, no one seems to use standard anything in the Java world. It is just a potpourri of different open source frameworks/libraries where one developer is doing one thing and another is doing something else. A few other lame things about Java include longstanding issues like memory leaks in commonly used software such as Tomcat. I thought it was ridiculous that that was never fixed. And more recently, Oracle released Java 9. And their own IDE, NetBeans doesn't even support it. It is pathetic.

They missed a chance there

The Jakarta name has a loooong association with Java

Being home to some successful Apache Foundation Java projects such as Xerces and Xalan, some promising but ultimate failures such as Batik and many many things that were simply a bad idea; a lot of Java/XML crossovers. Very mid-2000s.