[john-waterwood]

>EAP 6.4: 8 months EAP 6.3: 8 months EAP 6.2: 7 months

That's skipping a lot of updates. EAP 6.2.2: 1 month EAP 6.2.3: 2 months EAP 6.2.4 1 month EAP EAP 6.3.0: 1.5 months Etc

>The other 50% lay dormant for years

So this exactly the same as with a Java EE implementation or any other open source project for that matter. Many get fixed in hours, others weeks or months and some years or simply never. Spring is not inherently better here as their track record proves. That your personal reports were of no success maybe says more about yourself than of any Java EE implementation. I got many bugs fixed and have seen others reporting bugs that have been fixed in no time.

>Java EE 8: at least 3 years Java EE 7: 4 years Java EE 6: 3 years Java EE 5: 3 years

I was more referring to this one: http://arjan-tijms.omnifaces.org/2014/10/java-ee-process-cyc...

The actual time spend on the spec is less (see table). Whatever number you look at, it's not that different from the major Spring releases, and Spring is a product even, not a spec.

[needusername]

> Whatever number you look at, it's not that different from the major Spring releases, and Spring is a product even, not a spec.

Spring releases are every month. When there is a bug in a Java EE spec (like the WebSocket/CDI integration or the CDI annotation scanning in EE 7) you have to wait for the next major spec version to fix it. The spec has to be "perfect" for 3 to 4 years because there is no way to fix it.

[henk53]

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