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). 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.

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

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.

Well, actually Java EE is only a "spec", with no code. There's a reference implementation, though. Sometimes this RI is popular, sometimes it isn't.

Following your example: JPA (the spec) is implemented, among others, by Hibernate. And EclipseLink is the reference implementation for JPA.