
Analysis shows major decline of Oracle's involvement with Java EE - henk53
http://jj-blogger.blogspot.com/2016/04/java-ee-8-what-is-current-status-case.html
======
nobullet
As for these JSR's: I have a strong feeling that Enterprise Edition has become
a little detached from the real world.

Java SE is fine but the audience and industry is becoming not interested in
Java Server Faces and Portlets as society is shifting to client-side
technologies to do same stuff with JavaScript, TypeScript, etc. Java SE is
enough to work on server providing RESTful interfaces to the outside world.

Regarding JMS: may be it is a variety of Java asynchronous processing/storage
tools that don't need EE at all (like Actors, Hazelcast, Hadoop, Redis, etc).

~~~
henk53
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.

~~~
nobullet
You are right about JAX-RS, WebSockets, JSON-P, JPA, JTA, etc: there are no
replacements for these Java EE technologies in client-side technologies.

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. I've provided
explanation for that.

As for Chrome: the lifecycle of the UI in Chrome is different than UI
lifecyclein JSF/Portlets. JSF/Portlet builds the DOM in memory, sends the
output, GC cleans up after. This happens per request. But I've seen GC
utilization in JSF under a big load. It wasn't nice. Also, JSF/Portlets' APIs
are mostly synchronous.

Also, browsers are evolving. Client-side technologies are easier to learn.
Server-side is harder. That's why I don't believe in major shift back to
server-side. Twitter is relatively simple application. This is an exception, I
think. There will be cases when server-side rendering is more efficient. But
UI will be much simpler (no templating support, for example).

~~~
henk53
>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...](http://jsfcentral.com/articles/understanding_jsf_performance_3.html)

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.

