
Java EE Is Moving to the Eclipse Foundation - javajocky
https://adtmag.com/articles/2017/09/12/java-ee-moving-to-eclipse.aspx
======
shagie
This is IBM finally beating Sun over control of enterprise Java - something
they've been fighting for for well over a decade (and much closer to two). IBM
has been trying to get the Java process away from Sun - and they even backed
an IDE to compete with NetBeans.

Eclipse... of the Sun (Microsystems).

Apparently, Oracle has finally gotten tired of IBM (through Eclipse) saying
"we can do it better" and trying to manage it and said "ok - you can do it."

~~~
needusername
Nope, this is Oracle stop caring about Java EE. They are not doing this for
Java SE as long as they are caring about Java SE.

I also doubt IBM still cares about Java EE. Their last JSR (Batch/JSR-352) was
particularly disgusting and seems to be abandoned already.

~~~
topspin
"JSR (Batch/JSR-352) was particularly disgusting"

Good grief. Another mountain of XML programming. It's like the last 10+ years
of software engineering never happened.

I wonder how many half completed JSR-352 implementations will emerge.

~~~
skocznymroczny
Just replacing XML with JSON doesn't make anything modern.

~~~
mseebach
No, but replacing "programming-in-configuration-files" (whether those
configuration files are XML or JSON or something else) with programming in an
actual programming language (see eg Maven -> Gradle) _is_ , IMO.

~~~
_pmf_
I've always thought of Gradle as a slow Maven with a slightly disgusting
syntax[0].

[0] No offense to Groovy; I'm only hating on Gradle's usage here

~~~
crummy
I thought Gradle is faster than Maven these days.

~~~
pjmlp
Only with the help of a background daemon to catch its data model, a few GB of
memory and SSD, to achieve what Maven has doing without daemon help on plain
HDDs.

------
exabrial
This is awesome. CDI, JAXRS, JPA, JTA, and JMS are brilliant technologies but
are held down by the weight of legacy technologies. Maybe we can finally see
Java EE based solely on CDI, which would kick every platform out of the water.
Scopes take dependency injection to the next level and finally fulfills the
promise of modular, testable, reusable code.

~~~
strictfp
You really drank the coolaid I can see. I think dependency injection
frameworks are a bad idea in general, and it seems as if the current trend
goes against using them. Also I won't be expecting much good to happen after
Eclipse takes over, they tend to complect implementation and not really drive
development IMO.

~~~
cjsuk
Where is this sudden DI framework hate coming from? It's just magic object
glue that assembles everything based on contract.

It's that or factory factory factories or sticky tape. Those are much worse.

All the Java EE tech is just a set of contracts really with some canned
implementations that magic object glue sticks together.

~~~
lolive
Factory factory factories... ;)
[http://discuss.joelonsoftware.com/default.asp?joel.3.219431....](http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12)

~~~
cjsuk
That was a nod to that article actually.

No one does that now. Someone does some thinking, writes a strong interface,
then builds the code behind it. There's usually only one implementation. The
advantage comes at the testing phase when you have strong interfaces to mock.

I can count on one hand the amount of things we do with multiple
inplementations and that's mainly switching cache and file store
implementations out depending on who paid for what.

~~~
barrkel
Testing using mocks usually (a) over-specifies the code under test (e.g.
mandating method call order and call count), and (b) under-tests the
integration across the boundary - i.e. there's no guarantee that the mock acts
the same way as the concrete implementation.

I prefer composition through more general abstractions like iterators,
consumers, functors etc. where possible. With more general abstractions,
there's both less need to mock (there are concrete implementations that are
simple enough to use in tests) and the contract is trivial enough to be
implemented consistently.

Converting control flow (where modules interact through a rich protocol of
method calls) into data flow (where modules interact by consuming data and
producing data) promotes both a more functional style, and naturally leads to
more testable code with fewer of the downsides of mocks. It also reduces the
number of interface-implementation redundantly paired types throughout the
system.

~~~
UK-AL
"mandating method call order and call count)" \- Very few people use mocks
like that.

Most people use them glorified stubs for returning data. Personally these days
I just in memory datastores.

~~~
cjsuk
We do use mocks like that. How else do you test that a complex piece of logic
doesn't try and perform the same operation twice, such as a trivial case of
sending only one message to a queue?

Without the assertion, you are left with an assumption, which from experience
isn't reliable and keeps you up at night.

~~~
UK-AL
Because it makes refactoring very difficult. One of the original intentions of
TDD and Unit testing was to make refactoring much easier.

If you start testing the internals of function, it makes it very difficult to
refactor without breaking tons and tons tests.

We only test on publicly exposed functions, and check the changes on the data
or external services.

It means we can do major refactoring's of internals, keep public functions the
same but tests will still pass.

One of the biggest mistakes that happened was that kent beck was
misinterpreted and Unit was considered a code unit, when really it means a
unit of behaviour.

~~~
lolive
I don't disagree with your explanation. But the core point of objects is to
bind a state and some method implementations.

Mocking the state sounds mandatory to test the method implementations in such
a paradigm.

What you propose seems more like functional programming oriented testing.

------
dfabulich
My impression is that nobody uses any of the code shipped in Java EE. People
use Servlet containers (Tomcat and JBoss) but the problems you can solve with
EJB, JSF, JPA, JMS, etc. are all better solved with open source libraries,
e.g. Guice, Spring, and Hibernate.

~~~
lockje
Many of the open source libraries are concrete implementations of the Java EE
specs. Hibernate uses JPA, GUICE standarized the CDI implementation
([http://googlecode.blogspot.nl/2009/05/javaxinjectinject.html](http://googlecode.blogspot.nl/2009/05/javaxinjectinject.html)).
And many of the technologies offered by Java EE are standarizations of
concepts. This is highly valueable for reuseability and not having 10
libraries completely reinventing the wheel.

~~~
jacques_chester
> _This is highly valueable for reuseability and not having 10 libraries
> completely reinventing the wheel._

This was a problem in the days when the only available platforms were closed-
source. Standardisation was pushed onto vendors by buyers in an attempt to
weaken their lockin power. It never really worked very well. No matter how
flawless the standard, no matter how miraculously identical the behaviour of
the implementations, nobody is going to bet their career on a move that bets
the company on a different vendor. Too expensive, too risky, too long.

OSS changes that equation entirely. Say you pick Guice. Will Google behave
like Oracle and extract everything up to one dollar less than your "fuck this,
let's migrate" price?

They can't.

Say you pick Spring. Will Pivotal burst through the door demanding licensing
fees, support fees, sales fees, fee-collecting fees, fees to the power of
fees, also à la Oracle?

They can't.

So you're left with technical lockin. _Which you always had anyway_.

The economics have changed. For _libraries_ , for code running inside a single
process, standards are now largely irrelevant, because you'll rely an OSS
framework or library in which there is no risk of vendor lockin.

The frontier of standardisation has moved to formats and network protocols.
The most widely-used network protocols actually foreshadowed the triumph of
opensource.

Similarly, file formats we've all pretty much settled on a handful of open
formats for the vast majority of greenfield and brownfield integrations.

These protocols and formats have standards, but as a guide to cooperators, not
as a shield against vendor bloodsucking.

Java EE matters a lot, insofar as the majority of Java code written somewhere
passes through a JEE-defined interface. But it no longer controls the destiny
of Java programmers. That now lies with the OSS contributors and their
sponsors.

Disclosure: I work for Pivotal, we sponsor Spring.

~~~
watwut
It is not so much that you replace existing project, but more that you start
using different technology for new one once you are fed up with old. It makes
learning it easier since the bulk of it is the same. Same with hiring people
who have experience with different vendor. Also, it gives you shared
documentation.

At least that is something that I perceived to be different against js world
where exact technology match is often required and documentation weaker.

------
campuscodi
Statement from Red Hat: [http://middlewareblog.redhat.com/2017/09/12/java-ee-
moves-to...](http://middlewareblog.redhat.com/2017/09/12/java-ee-moves-to-
eclipse/)

~~~
moocowtruck
considering redhat has large stakes on java ee craps i wouldnt expect any
other kind of statement

------
wocram
Isnt the eclipse foundation where projects go to die?

~~~
rectang
Sheesh, there's always someone with this take on foundations. I've heard the
exact same phrase many times with "Apache" (where I used to be very active)
instead of "Eclipse". :\

Large projects tend to end up under the various foundations because large
projects have lots of common problems that the foundations help solve and it
doesn't make sense to reinvent the wheel every time (e.g. by starting your own
foundation).

Once there, lots of stakeholders are more comfortable committing lots of
resources because the governance rules are predictable and well understood. So
the projects tend to cater to those stakeholders, putting a higher emphasis on
backwards compatibility and evolving more through extension than through
revolutionary, breaking changes.

Projects which go to foundations live for a long time. And they don't stop
innovating, either -- they just innovate more at the edges than at the core.

~~~
mrmondo
I would tend to agree with those that say the Apache foundation is where
projects go to die, to me the Apache foundation feels like a library of legacy
often heavy code. OpenOffice (LibreOffice by comparison is doing ‘well’),
Wave, Zookeeper, Apache itself etc...

~~~
nly
Thrift. Facebook handed it over to the Apache Foundation, and then released a
new fork on GitHub a few years later that with a tonne of new dependencies.
It'll likely never be merged.

------
csours
Can someone explain what Java EE really means? I tried to parse the bundle and
license the last time this came up, and I didn't really get anywhere.

~~~
camus2
> Can someone explain what Java EE really means? I tried to parse the bundle
> and license the last time this came up, and I didn't really get anywhere.

It's no different than Web standards between browsers, it's a collection of
API specifications describing how web applications should be architectured in
Java. Then different libraries can follow the spec. JavaEE also has a
reference implementation which used to be done by Sun/Oracle.

The problem with JavaEE is, by being too broad and generic, it is incredibly
complex and often fails to solve today's developers problems. I mean who cares
about JSF(java server face, a way to describe "HTML GUI widgets" in XML) when
most applications use a RESTful architecture? Beans session persistance? ...
JEE has a lot of technical debt, the word is definitely appropriate here.

~~~
pjmlp
Most enterprise shops do care about JSF.

I know of many greenfield projects using it, mainly PrimeFaces.

~~~
tannhaeuser
They do for legacy apps only, though, since JSP, JSF and everything on top of
it, such as portlets and faces component libs, has been obsolete for many
years now. Handling UI state on the server just doesn't make any technical
sense when there are React, Angular and Co as mainstream GUI kits.

I guess there are still those shops maintaining intranet apps, and for whom it
is a priority that everything is 100% Java, or who can't or don't want to
invest into JavaScript or another web stack, but I think a responsible
consultant should tell these customers that their stack is on life support
now.

~~~
cjsuk
A lot of enterprise companies aren't buying in JS frameworks because the
velocity of those frameworks is too fast. I kind of agree. When you have
50,000 desktops, a 6 month lead dragging a pile of apps over to a new browser
is a nightmare scenario. All it takes is one app which the vendor doesn't give
a shit about and one internal app deprecating an IE version used by 50 users
due to a JS framework change in a branch office and there's a headache from
hell on your plate.

Fortunately they're all starting to kick out chrome for business now.

~~~
tannhaeuser
Maybe for those customers it might make sense to donate to the Eclipse
foundation to keep JSF etc. alive and to keep Java-only devs afloat? But then
maintenance of J2EE has ceased because it's not economically feasible.

~~~
cjsuk
It probably would but it won't happen. It's difficult getting anything like
that through the layers of purchasing hell.

If they provided a web site with pictures of boxes of software for min $2000
that never arrived and didn't do anything it might work better. The moment
someone says "donate" the bean counters start sharpening their pitchforks.

~~~
eecc
How about labelling that button "support" or "maintenance contract"?

~~~
cjsuk
That just gets the legal guys on the case.

------
damagednoob
Not sure if I'm mistaken but isn't the major thing about this the TCKs? As far
as I'm aware they are the keys to kingdom for alternative Java
implementations. Never shared by either Sun or Oracle so if and when this
happens it will be a good thing™.

~~~
needusername
You're correct. In the old days that was the case. They were shared but only
for money. These days Tomcat, TomEE and Payara can't claim Java EE compliance
because they don't have a TCK. It is not clear to me wether this would also
retroactively include the Java EE 8 TCKs. It is important to note that Oracle
does not transfer the Java EE brand name. So whatever comes out of Eclipse
can't be named Java EE 9. You can't make this stuff up.

------
vbezhenar
What those foundations even mean for projects? Is it like free web hosting or
what? Why don't they move to github instead?

~~~
tannhaeuser
It's the gentleman's way to completely unburden maintenance for software not
commercially interesting at scale anymore without loosing face as enterprise
supplier. _Transition to_ just sounds better than _Dumping on github_ , and
upcoming vulnerabilities and other security issues won't make for good media
appearance either.

------
geodel
Java EE seems drag on Oracle's cloud future. One can see where Oracle would
like to focus, at least, through their open source efforts [1].

1\. [https://github.com/oracle](https://github.com/oracle)

~~~
horusthecat
I heard some scuttlebutt about two years ago after Oracle got rid of some Java
people that Oracle had wanted to leverage Java-as-a-Service as a cloud
product, sort of like Google Compute, but just never managed to get there...
The Sun acquisition, someone told me, "was a hardware acquisition". With
SPARC/Solaris dead, Sun staff gone and the lawsuits against Google over Java
faltering Oracle has sucked the last marrow out of the bones and is just
casting them off now.

------
rmrfrmrf
Does this mean that GlassFish will finally have a chance of not sucking?

~~~
needusername
Yes, if the Payara guys manage to take over the project, do more frequent
releases and pull off some major refactorings. I am not sure they have the
resources.

------
jerianasmith
Its' true that there's no array or map in XML, but Arrays can be serialized to
XML. I too haven't reviewd JSR, So not in position to say about
implementation.

------
nomercy400
So... Java Eclipse Edition?

------
annonwhatever
Java EE going the way of the Dodo

~~~
drama-queen
JEE is fundamentally a component container spec. The core APIs are sound.
Servlets, for example, is a little gem of coherent abstraction.

A rethink of the provider/deployment end of the equation for the world of k8
mesos etc. could resurrect it.

~~~
pvg
_Servlets, for example, is a little gem of coherent abstraction_

It's a little gem of a memento of Sun's 'write an API for everything in a
hurry and hope it sticks' insanity and greed back in the day. The very
'Servlet' interface is supposed to be some sort of generic (possibly
stateless) server-side component. All it is actually good for and used for is
http, the 'Servlet' interface itself is a completely pointless layer of
abstraction.

Servlets are the widely deployed and used standard with multiple high-quality
implementations but let's not kid ourselves that the thing itself is some kind
of pinnacle of sensible, let alone good API design.

~~~
HelloNurse
Calling the _Servlet_ interface "a completely pointless layer of abstraction"
only because in practical use nobody ever cared for anything but _HttpServlet_
is unfair. It's a reasonable, natural and correct abstraction that, at the
very least, helps distinguishing HTTP specific features from general purpose
ones.

~~~
pvg
How is it unfair? The fact that nobody uses it and that it has found no use
for the _decades_ it's been around is the very definition of 'pointless layer
of abstraction'. It was written in a period of an API land grab. A reasonable
and natural thing is to be suspicious of an abstraction that has no use or
precisely one real use.

------
puppetmaster30
I hope Java 9 Module System moves to Java EE.

------
UK-AL
Does oracle have a equivalent?

------
terminado
woah

------
wener
Feel sad, don't like things goto Eclipse. Eclipse makes me feel less techs,
maybe the bad impression from eclipse, these bad impression last for at least
five years, most of time someone get into the trouble is caused by eclipse,
feel more worse.

~~~
QuercusMax
Are you confusing Eclipse-the-IDE with Eclipse-the-Foundation? The Eclipse
Foundation is much like the Apache Foundation - the piece of software it was
originally named for doesn't have much to do with lots of the projects hosted
/ owned by the foundation.

