A Java EE Startup: Filtering information with zeef.com

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.

>Please

Please? You're stating that JMS is not even at Java SE 1.4, then I give you simple prove that it's at Java SE 7, and your response is "please"?

>Did you ever actually use JMS in production?

Yes, rather intensively.

>If so did you use MDBs?

Yes

>If so did you use whatever happened to be the default JMS implementation of the server or did you use a stand alone message broker?

The default implementation, with a JMS bridge. This is a rather powerful setup. The application posts and listens to what are local queues using the default provider. The bridge then transports these to the remote destination.

>how did you associate the RAR with the MDB and what did activation specs look like

Since I didn't use a standalone provider, I didn't go that route. But I DO know that you've changed specs here and are barking against the wrong tree. A RAR is JCA and MDB is EJB, we were talking about JMS here.

While I don't have much experience with JCA, I also do know that things have been simplified a while ago. Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs...

Or read some of David Blevins posts about this topic.

JCA and particular the activation config annotation is rather ugly, I'll agree to that. It's a direct translation of the old XML version and there's room for simplification here. Hey, if you have some ideas why not file a JIRA issue?

>As I said, I take it you never actually tried to do that yourself. I did it for the issues listed above and more and absolutely nothing happened.

Do you have a link to the issues you filed? I'm rather curious now.

When I look at the JIRAs of the Java EE specs I see a lot of issues that were filed by community users and were indeed implemented.

JSF is most well known here. Take a look at: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC

Check what has been implemented in JSF 2 and check that with the issues that were filed. This one makes that rather easy: http://jdevelopment.nl/jsf-22 Now see who filed a lot of those issues. See?

If we look at JMS and I grab this issue, then it's a community member and the issue got included in Java EE: https://java.net/jira/browse/JMS_SPEC-63

Now just grab whatever other spec, say JPA, and look at another feature that was introduced a while back: https://java.net/jira/browse/JPA_SPEC-26

What do you know, AGAIN a community member. You can go on and on. MANY issues that actually ended up in Java EE were proposed by community members.

> It doesn't help that you can't create pull requests for Java EE

Oh? So what is this: https://github.com/spericas/ozark/pulls?q=is%3Apr+is%3Aclose...

And not every implementation is on Github, but many RI implementations take the equivalent of pull requests; patches attached to issues. Boils down to the exact same thing.

Yes, I too would like that every implementation and specifically the RI ones were all on Github, but there are many great other open source projects that aren't on Github either and this doesn't make them any less open source or free. In fact, I just called my old friend RMS (we go way back) and according to him there's nothing in OSI that requires projects to be on Github.

> Since I didn't use a standalone provider, I didn't go that route. But I DO know that you've changed specs here and are barking against the wrong tree. A RAR is JCA and MDB is EJB, we were talking about JMS here.

Yes, and the only way of listening to a queue without polling or blocking in Java EE that JMS supports in through an MDB. The way you plug a custom JMS provider into Java EE is through a RAR. The way you connect the RAR to the MDB is undefined because "expert group" can't be bothered.

> Take a look at this article: http://robertpanzer.github.io/blog/2014/inboundra-nointfmdbs....

A very good explanation of what's wrong with JMS. The class to be notified and the configuration is the same file. If this was a host you would have the hostname and port of the message broker in the listener class file.

> Hey, if you have some ideas why not file a JIRA issue?

I personally spoke to the spec lead at JavaOne and he couldn't be bothered.

> Do you have a link to the issues you filed? I'm rather curious now.

Did you or did you not personally file a single issue?

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

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