Jakarta EE 9 Specification Release 'Marks the Final Transition Away From javax Namespace' (adtmag.com) 13
An anonymous reader quotes ADTmag:
The Eclipse Foundation this week announced Jakarta EE 9 Milestone 1, the final version of the enterprise Java specification before the first Release Candidate (RC). The Jakarta EE 9 release marks the final transition away from the javax.* namespace (which Oracle refused to give up) to Eclipse's jakarta.*. This release updates all the APIs to use jakarta.* in package names. In fact, Mike Milinkovich, executive director of the Eclipse Foundation, says that transition is really what this release is all about.
"The main purpose...is to provide a release that is very similar to Java EE 8," Milinkovich told ADTmag, "with everything converted to the jakarta.* namespace. We're providing a stable technical conversion platform, so all the tools and frameworks in the ecosystem that are using, say, javax.servlet, can make the change with confidence." Giving the ecosystem solid footing for the transition from the Java EE coffee cup to the Jakarta EE sailboat is the Foundation's way of setting the stage for rapid innovation, Milinkovich said, once the transition is largely complete.
"These technologies have been around for an awfully long time," he added, "and we had to provide folks with a stable platform for the conversion. At the same time, thanks to a contribution from IBM, we have the Eclipse Transformer Project, which is going to provide runtime enablement. If someone has an application they don't want to recompile, and that application is using the javax.* namespace, they will be able to run it on top of a Jakarta-compatible app server. That's going to provide binary compatibility for apps, going forward..."
"The main purpose...is to provide a release that is very similar to Java EE 8," Milinkovich told ADTmag, "with everything converted to the jakarta.* namespace. We're providing a stable technical conversion platform, so all the tools and frameworks in the ecosystem that are using, say, javax.servlet, can make the change with confidence." Giving the ecosystem solid footing for the transition from the Java EE coffee cup to the Jakarta EE sailboat is the Foundation's way of setting the stage for rapid innovation, Milinkovich said, once the transition is largely complete.
"These technologies have been around for an awfully long time," he added, "and we had to provide folks with a stable platform for the conversion. At the same time, thanks to a contribution from IBM, we have the Eclipse Transformer Project, which is going to provide runtime enablement. If someone has an application they don't want to recompile, and that application is using the javax.* namespace, they will be able to run it on top of a Jakarta-compatible app server. That's going to provide binary compatibility for apps, going forward..."
Re: (Score:3)
This is why you need to read and understand the terms of the licenses for all the software components you use. Proprietary is OK. At least you know who owns your soul up front*. GPL is good. You can always grab a copy and head out on your own. Lots of stuff in between was written to sucker a critical mass of developers/users in. But then provide the creators with the means to monetize their users by selling them down the road for huge profits.
*At least up to the point where they sell you down the road to a
As if Java didn't have enough libraries and APIs.. (Score:1)
...here comes yet another that duplicates functionality but hey, it's got a new name! Oh, and raspberries can be blown at Oracle. This is really no way to "improve" a language that is already frankly a complete mess. Glad I stuck with C++ despite being told Java was the way of the future numerous times back in the 00s. Well that future is looking pretty ropey these days.
Re: (Score:1)
Since Java as a language is pretty bad, libraries are the only thing it has going for it. Hence its fans create more and more.
java is total crap (Score:2)
It used to be OS/CPU independent; I could build a portable jar *on any OS* that ran anywhere. That was the whole selling point.
Not any more. Oracle has ruined the only "good" thing about java.
Which is hilarious, because golang and rust (for example) could do that from the start.
jpackager, javapackager et al are garbage. None of it works right. Building on OS/CPU independent, coherent CI/CD pipeline is basically impossible.
Re: (Score:1)
your hate of Oracle blinds your poor soul of all objectivity.
I just released a Jar and it works on Windows/Mac and Linux.
So rust provides a GUI toolkit that will run exactly the same on both windows/macos/linux like Java Swing?
Java Swing achieved this feat as early as 2000s.
If anyone is reducing the power of Write Once/Run Everywhere of Java is Google and Apple by building walled gardens. MS tried it before with J++.
Re: (Score:2)
You can no longer build cross platform installers from any OS.
Re: (Score:1)
ok you might be right about that.
Can you tell me why? Was it even possible in the first place? Installers are inherently platform dependent.
Re: (Score:2)
This is a library translator. Where in the hell do you get the notion that it is architecture or OS specific?
Glad you don't work on any team I'm associated with. You appear to either be illiterate or suffering severe brain damage.
Re: (Score:2)
I'm talking about java as a whole, not jakarta.
Re: (Score:2)
I have no issues running my Java binaries on multiple systems.
Java problem or HR problem? (Score:2)
jpackager, javapackager et al are garbage. None of it works right. Building on OS/CPU independent, coherent CI/CD pipeline is basically impossible.
Works great for me and nearly every fortune 500 company. Maybe Java is not the issue in this equation. Some problems are technology problems, some are HR problems.
Re: java is total crap (Score:2)
You're casually mixing platform independent jar files with some platform specific installer/JRE bundle artifacts you build from them like you don't know the difference.
I did not know you even could produce a MSI installer that wraps your Java program, from a Linux build server, but I can tell you for certain anything platform specific was never on Java's strong side, and that is not what most people mean when they say cross platform. They don't mean cross-compiling some platform specific install wrapper at