[john-waterwood]

You're mixing up things.

JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/

You're quoting an individual bug that has been open for some time. Did you also looked at the many bugs that were fixed after a few hours after being reported? Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?

Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want). That's the time between 2 spec releases. It's about the same time as between major supported JBoss releases, so between EAP 5, 6 and 7. There's 3 to 4 years between major Spring releases (Spring 2 2006, Spring 3 2009, Spring 4 2013).

And Java SE doesn't release a major new version montly, let alone yearly either. A spec should move fast enough to stay relevant, but slow enough to provide the stability needed so lots of other technology can build on it.

[needusername]

> JBoss releases updates to its implementation rather frequently. If you look at their release dates it's almost every other month. See ftp://ftp.redhat.com/redhat/jbeap/

http://jbossas.jboss.org/downloads

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

> Do you dare to state that Spring has no bugs or that none of their bugs is open for more than a day, week, month?

In about 50% of the times I have reported bugs or submitted pull requests against Spring they were closed within 6 hours. Spring releases about a month apart. The other 50% lay dormant for years. Still way better than any contribution I tried to make so far to Java EE. 0% success in about 6 tries.

> Java EE has a spec cycle of about 2 to 3 years (there was an article about this recently, Google it if you want).

https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edit...

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

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