henk53

single, self contained deployable

EE doesn't exclude that model at all.

For the most part, maybe like 99%, the Jakarta APIs are agnostic of what the deployment model is. They are APIs to validate input, service HTTP requests, store data in databases, look up roles, connect to identity providers, etc etc.

I thought that was Tomcat or was Tomcat just the servlet reference implementation

Tomcat itself has never been an official reference implementation of anything.

Tomcat implements various Jakarta EE APIs, most centrallly Servlet indeed, but also JSP (Jakarta Pages) and JSTL (Jakarta Tags), WebSockets and Jakarta Authentication.

The initial Tomcat was donated to Apache, then used back in GlassFish. GlassFish WAS the reference implementation of Servlet (among others), so indirectly Tomcat kinda was the reference implementation indeed. But just a fork of its code via GlassFish.

Spring won. Why would anyone want to learn the standard aside from it being a standard that few people use?

People don't really talk about Jakarta EE as "the standard". Haven't been doing that for quite some time.

You learn it so you don't hand Spring the ultimate monopoly. I thought we all didn't like monopolies? Why give Broadcom one?

IBM already owns Red Hat, but for a few years it operated as a largely individual company still.

Spring is just a framework, not an application server with isolated classloaders that the JaveEE application servers were based on.

But Spring Boot with its embedded HTTP server and internal infrastructure is certainly more than just a framework. It has its own class loade (launchedurlclassloader). See https://dzone.com/articles/spring-boot-classloader-and-class...

Piranha Cloud on the other hand runs Jakarta EE code without any class loader of its own. See https://blogs.oracle.com/javamagazine/post/you-dont-always-n...

JavaEE somehow associates with managing applications through the Application Server’s admin panel,

That is a wrong association really.

Even in the really old versions of GlassFish and JBoss such an admin panel was just an extra (I hate them too, btw).

You could always, Tomcat style, just copy your .war to a deployment folder. If you wanted, you could also zip up GlassFish with the war already in that folder and deploy that.

registering EJBs with deployment descriptors

That was required for the last time in J2EE 1.4, from 2003 or so. Already in Java EE 5 from 2005 that wasn't necessary anymore. Also don't forget that spring beans needed to be registered in very similar deployment descriptors (huge xml files) just as well.

Java EE 6 was pretty decent really. It came with JAXRS, CDI, Bean Validation and JSF 2.

If you used J2EE in 2012, did you happen to get that idea from a very old book?

J2EE ended in 2005. So if you used it in 2012 it may explain something.

Isn't this very article about directly running GlassFish from Java SE?

You could also say btw that GlassFish doesn't need any WebSphere or JBoss. Or you could say that WebSphere doesn't need a JBoss or GlassFish.

Also, WebSphere is legacy within IBM. Their new and much much better server for some time is called Open Liberty. It uses some components from WebSphere, but in a highly modularised way, and the overal runtime is totally different.

LOL - I wondered if I had just travelled back to 2001 when I saw this.

In 2001 the product wasn't called GlassFish yet, and even the Sun ONE Application Server name wasn't there yet.

The name GlassFish wasn't introduced until 2005 and had its first release the year after that.

Also, for a very long time, Spring Security had native integration connectors for JBoss and maybe some other EE servers. They only removed these much later.

Last worked in EJBs in 2002. There’s still a bad taste in my mouth.

Although EJBs got improved so much in 2006 it was nearly a different technology, EJBs by themselves have been largely deemphasized in Jakarta EE. The main bean model is CDI and has been for some time.

There's a 3. really, which are products using Jakarta EE APIs extensively (maybe even all of them), but aren't application servers.

Oracle themselves (they create such runtime, called Helidon) have a blog post out about just that:

https://blogs.oracle.com/javamagazine/post/you-dont-always-n...

Why would you ever run Jakarta EE nowadays instead of the defacto standard Spring Boot

Didn't that exact thinking got us into trouble over and over?

Why would you ever use any other browser instead of browser X? What follows is the browser X getting 99% of the market, and the vendor of X becoming lazy and ruining X completely.

and you can AOT compile it with graal!

You can do that already (and have been able to do so for some time) with Quarkus (a partial EE implementation, related to JBoss/WildFly) and things like Piranha Cloud.

Helidon (another partial EE implementation) has been working on virtual thread support with a custom HTTP engine build in cooperation with the JDK team.

It's Jakarta Faces now ;) And it's still relative active with a major new version (Jakarta Faces 4) in Jakarta EE 10. Of course the entire concept of server side rendering is not as much used as it once was, but that said it's still used.

It also involved giving us their reference implementation, which we named Apache Tomcat.

Did any of the Apache JServ code make it into Tomcat? There still is the Apache JServ Protocol (AJP) still, which is at least one thing related?

That was the case before, but now GlassFish has been picked up again and is very active once more:

https://github.com/eclipse-ee4j/glassfish/graphs/contributor...

It's been around longer than Jakarta

Not really, Jakarta came from Java EE, which came from J2EE, which was released early 2000. Spring is from 2003 and started essentially as a framework for J2EE.

and influenced it a lot.

It goes both ways.

Spring for instance started calling code "configuration" and wanted us to put it in huge amounts of XML. Java EE started with using annotations for bean definition and injection. Spring was initially against this idea, arguing configuration should be external and not embedded in the code. Citing that you would otherwise needed to recompile your code in order to change configuration.

Many years later Spring projects barely use those huge XML files anymore and its all autowire.

that has no serious rival in breadth/depth/ease of use balance.

What about Jakarta EE?

I'd have a small preference for Eclipse, mainly because some specs are already there (like EclipseLink).

Apache already has their own implementation of much of Java EE (via the Geronimo project, TomEE and Tomcat, among others).

In my opinion it would be slightly confusing to have say 2 JSF implementations at Apache (Myfaces and Mojarra). Not really terrible, but my gut feeling says Eclipse would be a better home.

This has the ability to have a huge impact on the industry, depending on how the transition goes and under which processes things are being governed.

Java EE is somewhat different from .NET in that it involves multiple vendors cooperating.

It's one of the closest living related languages to English.

One the closest indeed, although Frisian is technically even closer. If I'm not mistaken it's really quite close to old English, but a modern English speaker wouldn't be able to understand it at all ;)

good luck speaking English on the German countryside.

It differs, in generally people either speak it there, and then do so reasonably, or they absolutely don't speak it, not a single word.

This is quite different in The Netherlands. In Amsterdam people in shops etc will often address you in English and are rather fluent, but even in the most remote villages of the Dutch countryside everyone speaks some amount of English. It may be with a very heavy accent and not fluent at all, but generally it's enough to at least have a basic conversation.

Frankfurt has very good train connections as well. Specifically to Cologne which is via the hi-speed tracks, but also to Amsterdam and Vienna.

One big advantage of Frankfurt is that Germans are much more open to speaking English than the French, and this is an advantage that should not be underestimated. If you don't speak German, but do speak English it's possible to live in Frankfurt. To live in Paris, you have to speak French.

Only Amsterdam (which has English as its official language next to Dutch) is better in that regard. In Amsterdam you don't even have to ask if someone speaks English (that's considered an insult, on the same level of asking someone whether they can read and write).

But I have a feeling that author is judging about whole set of EE technologies by JSRs that loose their popularity at the current time.

That would have been a viable explanation, I agree.

Unfortunately, this isn't the case. I follow all the Java EE specs very closely, and this inactivity by Oracle concerns each and every spec. JPA as pure backend technology didn't even get an update, then after much asking a maintenance release was scheduled, but that's completely quiet again. JAX-RS, same deal. Spec lead didn't show up for months, and then occasionally he shows up saying little more than: "no! we're not going to do that"

And the same thing is true for brand new specs like MVC and Security. They were started with much enthusiasm, and then at exactly the same time as the graphs in this article shows (just after JavaOne) commits and mails from the spec leads completely plummeted.

I've seen GC utilization in JSF under a big load. It wasn't nice.

I've actually seen the reverse. Which version and implementation of JSF was that?

See for instance this: http://jsfcentral.com/articles/understanding_jsf_performance...

The GC churn of JSF is rather good, and better than for instance Spring MVC + Thymeleaf, which people somehow expect to perform better.

Also, JSF/Portlets' APIs are mostly synchronous.

In what respect? Many JSF applications uses AJAX quite intensively. And WebSockets is used a lot too. PrimeFaces has its own Atmosphere based implementation for a long time, while JSF 2.3 will adopt the approach introduced by OmniFaces which is more Java EE standards centric.

But while an interesting discussion, I'm pretty sure client-side vs server-side is not the main thing the article is about, which is really about Oracle silently and without giving any reason all of a sudden doing almost nothing anymore.

Society has shifted from the client to the server and back again a couple of times before, and don't forget that one of the biggest web sites out there (Twitter) has switched back from the client to the server.

Pure client-side technologies have many disadvantages, including a long initial load time, high local memory usage and high CPU usage. Ironically, a browser tab in Chrome can easily take up a magnitude more memory than a Java EE server takes up.

And don't forget that the client-side ecosystem is anything but stable. Google the phrase "javascript framework of the week" and the term Javascript fatigue.

Even if you do want to go with client-side UIs, there's a wealth of technology in Java EE to back these; JAX-RS, WebSockets, JSON-P, Bean Validation, JPA, JTA, etc etc.

Some resources have been taking away from Valhalla and Panama, and Java 9 has been delayed.

But that is NOT what TFA is about. That is about Java EE, which Oracle suddenly stopped dedicating resources to, but in a completely silent way.

Java SE may be next. We don't know that yet. There are some signs, but they don't matter at the moment. What matters at the moment is Java EE.

The reason here is Java EE and Oracle not doing much for it at the moment. Reza was the Java EE evangelist and a big proponent of the technology.

I can imagine his job being hard, still officially having to evangelise Java EE, while simultaneously knowing all his work is for nothing.

The problem is that it has been brewing for some time that Oracle is severely neglecting Java (EE). See

* http://www.infoworld.com/article/2987529/java/insider-oracle... * https://jaxenter.com/oracle-and-javas-planned-obsolescence-1...

A little while earlier the Java SE evangelists had been let go:

* http://fortune.com/2015/09/07/oracle-cuts-java-execs * http://www.infoworld.com/article/2980686/java/sources-oracle...

But, the infoworld articles mentioned unnamed former Oracle employees. And people brushed them off as being FUD spread by Pivotal (the Spring company, Java EE's major competitor).

But now we have for the first time I belief an actual name of an actual Oracle employee, and also not just any employee. He may not be as direct about it as we all wish, but IMHO it gives much credibility to the previous reports.

If you're interested in the topic, look at the various Java EE mailing lists, and look in the repositories for the implementation code. You'll see there's plenty of evidence of Oracle suddenly doing very little for Java EE:

* https://github.com/spericas/ozark/graphs/contributors * https://github.com/javaserverfaces/mojarra/graphs/contributo... * https://twitter.com/jms_spec/status/689762921988132864 * https://jcp.org/aboutJava/communityprocess/ec-public/materia...

And then look at the GlassFish 5 (Java EE 8 RI) builds, an automated zombie process with not a single Java EE 8 commit yet, and frankly almost none commits at all (see changes file for every build):

* http://download.oracle.com/glassfish/5.0/nightly/index.html

The story is the same for no matter what Java EE list or repo you look at, with the exception of CDI which is lead by Red Hat.

The spec has to be "perfect" for 3 to 4 years because there is no way to fix it.

This is absolutely not true.

There's the MR (Maintenance Release) for that. See for example JSF 2.1 and CDI 1.2. They were intermediate quick releases between major Java EE versions.

Even the platform spec itself can have a MR. Currently there's an MR for Java EE 7 in the works. See https://java.net/downloads/javaee-spec/JavaEE_7_Platform_MR_...

Because it's a spec, naturally more consideration has to go into it. Many implementations depend on it to be stable. In case of Spring there's only one Spring. Take it or leave it. Not having a spec behind you can be an advantage (change things whenever you want), but is a disadvantage as well (the implicit specification of how things work is in the code, but Java is not declarative and it's always a guess if specific behavior is just an implementation side-effect or an intended one).

Even changing things whenever you want can be a disadvantage. A spec naturally favors stability, which means I can run my old code with minimal or no changes at modern Java EE. Try that for regular open source libraries (be it from within the Java EE universe, Spring universe, or whatever). Chances are that the APIs and config files have changed 10 tens in the meantime.

The matter at hand here was pull requests and the implied notion that those didn't happen in the Java EE universe, which I proved (again) was not true.

Instead of just acknowledging that in whatever way you're just evading the issue (again) and switching to another topic.

But to reply this new topic, TCK has been a thorn in the JCP process indeed. Not every spec has a closed TCK. CDI and Bean Validation have open ones, based on Arquillian, with an open source (OSI) license, and an associated issue tracker where everyone can open issues against it.

Now funny thing here is that CDI is rapidly becoming the underpinning of everything in Java EE. It's the core of Java EE's core.

For some other specs like JSF the TCK is unfortunately closed, but the RI (Mojarra) has such an extensive set of effective TCK tests that I wonder if there's anything at all in the TCK that's not covered by the RI tests.

Still, opening up the TCKs is another battle worth fighting.