
Oracle and the fall of Java EE - SanderMak
https://techsticles.blogspot.com/2016/07/oracle-and-fall-of-java-ee.html?utm_content=bufferf1a2e&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer
======
StevePerkins
Amen. Be it Hacker News, or the /r/java subreddit, or wherever, it feels like
the bulk of Java chatter revolves around...

1\. Security vulnerabilities

2\. The Ask.com toolbar

3\. Oracle abandoning Java EE

... which is extremely frustrating because...

1\. Virtually all of the "security vulnerabilities" deal with the browser
plugin for using applets, which hasn't been widely used in 15 years

2\. The toolbar malware, while stupid beyond measure, only applies to the
consumer Java installer, which nobody installs anymore due to item #1 above.

3\. Java EE is legacy tech. While deeply entrenched, most of the work out
there for it today consists of maintenance or migration to more service-
friendly approaches like Spring or Dropwizard.

Java is certainly not perfect. It's also long in the tooth, and is associated
with "the enterprise", and so it's not seen as "sexy" by young developers. But
for business software, large-scale data processing, and web/REST backends,
I've yet to find anything on the horizon that seriously competes with it.

Every year I get bored and go exploring a new alternative language in side
projects. Every year I come back, more appreciative of what I have.
Python/Ruby/Node have their beginner-friendly charms, but are limited by the
lack of type checking and/or chaotic ecosystems. Golang seems really
promising, but has a long way to go. C# seems like the most credible
challenger for business systems, but the .NET Core ecosystem is probably still
years away from being where Java was in 2005.

I don't mind discussing Java's shortcomings. But I'm tired of hearing about
_irrelevant_ shortcomings such as applets and Java EE. Because that's just a
way to keep a "language war" going without having to point at a serious
alternative.

~~~
ufmace
I've worked on the Microsoft stack for most of my career, and I'm curious what
Java has/does that the .NET stack doesn't. Or is that more about the .NET core
stuff for running on Linux-based systems?

~~~
sigzero
The JVM runs on just about everything. The .NET stack doesn't.

~~~
woogy
The latest .NET version is fully cross platform.

~~~
soundoflight
And runs on more platforms than Java.

~~~
jinst8gmi
Care to name some of these platforms which Java doesn't run on which .NET
supports? I'm having a hard time coming up with even a very short list.

~~~
soundoflight
Also, Xamarin makes .NET runnable on Android with their runtime and compile it
down for iOS.

.NET Microframework makes it runnable on IoT.

~~~
jinst8gmi
I don't think Android is a good example of a platform which .NET supports
which Java doesn't since Java is the primary development language for Android
apps...

I'm also pretty sure that embedded Java is widely deployed in IoT
applications.

------
sandGorgon
Is it fashionable to bash java ?

What about
[https://github.com/graalvm/truffle](https://github.com/graalvm/truffle) or
[https://bitbucket.org/allr/fastr/wiki/Home](https://bitbucket.org/allr/fastr/wiki/Home)
or
[https://www.youtube.com/watch?v=OUo3BFMwQFo](https://www.youtube.com/watch?v=OUo3BFMwQFo)
? There is serious innovation happening in java land (through Oracle - without
talking about Clojure, etc.)

Java EE exists because of the need to support large legacy, enterprise
customers.

For those who are starting out in Java web frameworks, people usually use
Spring or Spring Bootstrap (and sometimes the newer Java 8 only
[http://sparkjava.com/](http://sparkjava.com/)).

~~~
chvid
It has been fashionable to bash java for the past +10 years.

~~~
mohaine
Yes. And Spring is a large part of the of the reason, not the solution. Every
time you see somebody making fun of Java for AbstractSingletonProxyFactoryBean
and its like they are actually making fun of Spring, not Java.

Btw, that is a real class, not a made up example.

[http://docs.spring.io/spring-
framework/docs/3.0.x/api/org/sp...](http://docs.spring.io/spring-
framework/docs/3.0.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

~~~
sandGorgon
again, it is the enterprise market.

But then there is spring-boot [http://projects.spring.io/spring-boot/#quick-
start](http://projects.spring.io/spring-boot/#quick-start)

------
ufmace
I do mostly C#, and don't know very much about the Java ecosystem, and I could
barely understand anything in that article due to all of the Java jargon. Can
anybody summarize what the point is for somebody who hasn't spent their career
knee-deep in the Java ecosystem?

~~~
jomamaxx
Java EE is basically the official java server-side container. It was designed
to scale, it kind of forced a designed pattern (something called 'Enterprise
Beans' \- one bean for dealing with requests, stateful beans for dealing with
sessions etc.)

It got huge and bloated.

Some people came along and created some lighter frameworks.

Arguably - Node.js - the javascript container is the real extension of this:
it's incredibly light, can handle zillions of connections, you install the
packages you need, it's totally open source. And it's in javascript which is
uniquely well positioned to do a lot of 'asynchronous' stuff. Passing
functions around with callbacks is possibly in Java but it's just bulky.
Mostly due to the nature of typing. It's even kind of bulky in Apple Swift,
for example.

Java is a great language, that has made some improvements with lambdas etc.

~~~
BigJono
Does Java have an equivalent to the Promise system in Javascript? I find it
much more usable than callbacks for async-heavy applications.

~~~
jomamaxx
No Promises in Java.

Sadly - the language is really not quite as 'async' as we would like it to be.

Java scales much better than Javascript though, and I mean that in the
architectural sense.

Past 50K lines of code - the lack of typing in JS can start to be hell, unless
you really know what you are dong.

Of course, you move much more quickly early on in JS and that's actually
important: you need to be able to 'iterate and adapt' in todays world. So it's
kind of a paradox.

If you're building a bank, you do it deliberately with Java or something like
that.

If you're building a nimble startup, you can start with Node and if there are
systems that reach a certain degree of maturity and the uses/cases and data
model start to settle you can fold over systems to Java or something like
that.

A great team can use anything in the end though - that said, it's really hard
to find super talented and responsible people across the board.

------
geodel
Java EE is described by some as old, heavy, over engineered technology as
opposed to Java SE + simple servlet containers with some Spring or other
'lightweight' frameworks.

However in my opinion there is something about Java/Java designers at
Sun/Oracle/IBM that lead to over designed APIs and code. Looking at just Java
servlet api, it is described in most elaborate manner. It is not about
supporting Http Listeners endpoints + some additional features but about any
kind of servlets possible for past and future protocols. It is awkward and
lacking features for practical Web based applications but still has 74 class
just for specifying servlets and no implementation.

So arguments about Java SE vs Java EE vs Spring vs Other hot Java framework
seems facile to me. Java it self has set the tone to describe things in most
elaborate manner, not most succinct manner and anything on top of that more or
less follow that tradition.

~~~
krylon
About eight years ... nine years ago, I was between jobs and thought I might
use the large amounts of free time I had at my hands to learn something that
might improve my chances of finding a new job. Lots of companies use Java EE,
right?

So I downloaded the JDK, Glassfish and a PDF of a book called "The Java EE
tutorial" from Sun.

I found it slightly disturbing that Glassfish (or was it JBoss? It was so long
ago...) used ~400-450 MB of RAM before I had done anything to it.

And then I started reading the so-called tutorial. The fact that it had ~1100
pages should have tipped me of, but it did not frighten me. When I looked and
the Table of Contents, however, which came with a freaking flow chart on how
to navigate your way through the book depending on what you already knew, I
ran away screaming. ;-)

And to be fair, in my brief attempt to learn C++ I, too, looked at my first
slightly-nontrivial-toy-program when it was finished and found it incredibly
over-engineered. So I know how easy it can be to give in to that temptation.

Also, there is this old saying that a given piece of software will reflect the
organizational structure that created it, if large corporations send hordes of
programmers to attack such a problem as creating Java EE or the servlet API,
it is not a surprising result.

In a way, .Net has the same problem, to a degree. I have not used it much, but
one of my first toy programs was an address book that got its data from the
Active Directory, and the LDAP API was significantly more complex than, say,
Net::LDAP in Perl. Not unusable, but the difference is noteworthy.

~~~
geodel
I have seen those massive J2EE tutorials and blueprints. They came directly
from Sun and used to be(still are?) taken very seriously.

Java/EE slogan is 'RAM is so cheap nowadays!' for anyone questioning why
applications seems so bloated. If you had temerity to probe further they would
drown you in blizzard of serious sounding technical/business buzzwords.

~~~
krylon
I got a away with the impression that some of those large, enterprise-ey
applications are so large and convoluted in the way they are specified that
the bloat Java EE adds appears negligible.

After I had the honor of writing a few simple-minded Perl-CGI-script to give
my boss an overview of projects our company is working on and their respective
profit margins, I begun to understand why. If somebody tells me computers are
complicated, I tell them that computers are trivial compared to accounting. Or
my brain is just wired that way... Listening to our accountants always makes
me feel like me IQ just dropped by fifty percent (or more). So if somebody
writes a piece of software that is somehow involved with accounting, it is
bound to be very complex with lots of special cases and exceptions.

I have nothing but the utmost respect for our accountants who manage to deal
with this insanity without sacrificing a goat to Cthulhu or something.

TL;DR - once one reaches that level of complexity, the complexity JavaEE puts
into the mix is probably fairly tame and one has bigger fish to fry or escape
from.

~~~
geodel
I'd slightly disagree because considering we are discussing impending fall of
JavaEE where as enterprises seems as complex as ever. So it would mean JavaEE
is not really proved right solution to complex enterprise problems.

I feel JavaEE is very large orthogonal complexity which somehow neither solved
nor reduced enterprise complexity. It added a jargon speak and multiple layers
to bury enterprise problems and reduced net understanding of issues.

------
_Codemonkeyism
I may wrong you, but I won't click on a link to "techsticles"

~~~
douche
It's not Jamie Zawinski, so I assure you, you won't end up seeing an actual
"techsticle"

------
itaysk
Java always had an awesome open source community around it that produced
frameworks, libraries and tools that inspired many other communities. but at
it's core, Oracle was and still is the exact opposite of open (JVM, J2EE as
examples). That makes me wander why Java was always considered the icon of
open source.

~~~
StevePerkins
I would argue that Java's success owes more to Maven Central that it does to
anything Sun or Oracle did with the language itself.

Maven Central is Java's CPAN, and that's what you need in order to build a
thriving open source ecosystem.

------
huherto
I dislike Oracle as a company. I whish Sun had been acquired by Google
instead.

But the Java ecosystem is awesome. The language is great, the JVM is great. As
long as you know what you are doing.

~~~
krylon
As far as I remember, Google was not even interested in buying Sun (at least
not wholesale). The other company that was engaged in negotiations was IBM,
which could have gone either way, I guess, if they had bought Sun.

------
brown9-2
Realistically, Java EE "fell" a long time ago, once people realized you could
use Spring or Guice or other frameworks to help organize your code without
relying on terribly designed APIs from Sun/Oracle for simple things like "I
want to handle a http request".

------
mianos
Sure, technology changes. I this case it is positive, moving away from
monolithic bags of tricks to lighter services. That is all good for Java. But,
we will be looking to moving away because Oracle can no longer be trusted.

~~~
dozzie
To monolithic, interdependent bag of lighter tricks. Microservices don't
magically make developers know how to design.

~~~
bognition
There is nothing magic about microservices and people who think they are run
the risk of getting burned bad. Even though each individual component is
smaller and easier to reason about complexity still exists but its usually
hidden in the interactions between the services. That said there are
tremendous benefits of being able to develop/test/deploy incrementally, its
all about balancing the trade-offs.

------
elgabogringo
Everybody hates Oracle, but people still give them so much money! One has to
wonder when it will end now that there are alternatives.

~~~
nickpeterson
Remember that sales is mostly about relationships. Your CEO will hand a few
million to someone they trust. Oracle projects an image of being the large
company that other large companies trust. SAP has a similar vibe. Your C-Level
people don't want to play dice with tech because to them it's often a cost
center whose disruption can be terrible for business.

You'll notice most engineering focused companies don't use Oracle because they
decide on tech based on different criteria and allow more input from
engineering and don't mind building things. They have to bet on tech or else
they have no reason to exist.

~~~
sievebrain
Last time I looked around it seemed a lot of "engineering focused companies"
like tech startups were using garbage like MongoDB, the famously lossy
database. I wouldn't assume that big companies are automatically incompetent
and "tech focused companies" ignore Oracle for good reasons. It can as well be
just fashion and/or groupthink and/or cost reasons.

~~~
nickpeterson
Web development and engineering are different. I believe we're in agreement.

------
markokrajnc
Java EE is a set of mostly bad libs for Java SE. Unfortunately the upper
management has seen it as a "better Java SE"...

~~~
agumonkey
Sadest part is that it diffused into education.

~~~
Synaesthesia
Agree! Over here we're teaching it to high school kids, when I think Python
will be a lot more suitable and enjoyable.

~~~
agumonkey
Please introduce value oriented recursion (not just pretty printing). Like
powerset, or countdown functions. Link them to Pascal triangle and then
recursively defined series. Combinatorics, factorials, (1+x/a)^n .. etc etc.
Tell them it looks fucked up dull and alien, for now.

------
niftich
The author's recommendations are:

> 1\. Drop the profiles. They are useless and pointless waste of time.

This is true, but profiles exist mostly for the benefit of vendors, not
developers. Developers only care about modularity, see #2.

> 2\. Make Java EE a conglomeration of technologies that are known to work
> together (i.e. JPA, JTA, JMS), but don't force their full installation. Let
> the use pick and choose what they want. Just be sure that they work together
> in pieces or in totality.

You can do this today, if you use good implementations for those APIs (JMS,
JPA)

> 3\. Make it modular. Start with zero and let people add what they want to
> use.

Same as #2, plus Jigsaw.

> 4\. Get rid of the tree class loader. You need it matrix based. OSGi is
> fine. Jigsaw is fine. But it needs to have classes that can be loaded and
> unloaded without an impact on the container. > 5\. The container itself
> should be a thin shell with remote capabilities (again OSGi/Karaf looks
> really good here)

The OSGi spec gets a bad rep for complexity, but it actually solves a hard
problem. Karaf's default UI, on the other hand, is terrible.

> 6\. Make it cloud friendly. Microservices needs to be core functionality,
> lightweight, and run in the cloud.

Uhh, it's pretty cloud friendly now. Not sure what the author wants here.

Ultimately the author says, if you're invested in the Java EE ecosystem, you
can't rely on Oracle to move it forward, but you shouldn't let their inaction
lead to your inaction. However, due to IP reasons and a perceived past
overengineering, the community has nearly given up on Java EE and focuses on
Java SE instead. This means that they've adopted points #1, #2, #3 and #6, and
are actually moving the ecosystem forward, just piecewise and no longer under
the 'Java EE' name.

------
kol
The wait is over, here is Oracle's official response to the rumors:
[http://arstechnica.com/information-technology/2016/07/not-
de...](http://arstechnica.com/information-technology/2016/07/not-dead-yet-
oracle-promises-big-plans-for-java-ee/)

------
johan_larson
What are the current best bets for writing web apps in Java? Play! is
convenient, but how does it compare to Spring Boot?

~~~
kitd
If you simply want to serve a web ui, Play and Spring Boot are good. Play is a
bit more self-contained. It provides a lot but doing something a bit out of
the ordinary can be challenging. Spring Boot is more agnostic in that respect
but relies (obviously) on Spring for dependency handling.

As well as those 2, Dropwizard is excellent if you're writing REST apis and
provides many enterprise-friendly features out of the box.

SparkJava (don't confuse with Apache Spark) is a very lightweight
Sinatra/Flask-like framework using Java 8 features, and good for REST apis
too.

2 more to consider IMHO: Vert.x, and Comsat from Parallel Universe. Parallel
Universe have one of the most interesting technologies in Java-land IMO. They
provide a library called Quasar that adds suspendable green threads (similar
to Erlang processes) to your code using bytecode instrumentation. This allows
a single server to handled a huge number (think 00,000s) of concurrent
connections. Vert.x has support for Quasar too.

I'm sure others have favourites too.

[https://www.playframework.com/](https://www.playframework.com/)

[http://projects.spring.io/spring-boot/](http://projects.spring.io/spring-
boot/)

[http://www.dropwizard.io/0.9.3/docs/](http://www.dropwizard.io/0.9.3/docs/)

[http://sparkjava.com/](http://sparkjava.com/)

[http://vertx.io/](http://vertx.io/)

[http://docs.paralleluniverse.co/comsat/](http://docs.paralleluniverse.co/comsat/)

~~~
FuNe
Also [http://www.ninjaframework.org/](http://www.ninjaframework.org/)

------
altendo
I understand the viewpoint put forth here, but I think the big issue is making
sure Java EE continues even as Oracle decides it's no longer worth the
investment. I don't know how easily a group or organization (like Apache) can
take charge of it given trademarks, patents, and the like.

------
dboreham
I think that as with many things, you need to follow the money:

Someone has to pay for the talented and expensive people needed to develop,
maintain and extend a language/ecosystem ("community" does not == free of
cost).

It isn't obvious to me what the underlying motivation would be to drive the
investment required. For Swift/C#/Golang it seems to be roughly "Platform
Entrenchment" or perhaps "if not this then we're owned by $otherbigco". Oracle
doesn't really have a platform to entrench these days.

------
patrick_vbn
Wildfly Swarm ([http://wildfly-swarm.io/](http://wildfly-swarm.io/)) seems
like the exact adaptation the author is looking for. "Swarm offers an
innovative approach to packaging and running JavaEE applications by packaging
them with just enough of the server runtime to "java -jar" your application."

------
einrealist
Nice post! I have the same opinion.

I guess, most people who make a scene about Oracle's stance think that Java EE
is the same as the JCP. The JCP will go on and JSRs that are part of EE will
continue to evolve. Its just a question of which JSRs still have value in a
world of fast changing cloud / compute infrastructures.

