Discussions

News: Does JBoss AS needs to be Java EE 6 certified?

  1. After JBoss AS 6 was released without much fanfare during the Christmas holidays, it became clear that this was the first major offering of a JBoss AS release that wasn't certified for the full Java EE specification. Instead, JBoss took advantage of the smaller Web Profile; a subset of the full Java EE spec that is new for Java EE 6.

    Initially the community remained quiet about this, but recently people have started to speak up. The discussion on JBoss' own forum has started to heat up (see  JBoss AS 6 full Java EE certification) and a few words were spent on this in the comments of The ServerSide's latest coverage of JBoss AS 6: http://www.theserverside.com/discussions/thread.tss?thread_id=61593#342621

    At the moment it's not really clear yet what the actual user base wants. Is compliance with the full Java EE 6 specification important for you, or is the Web Profile 'good enough'?

    Let your voice heard by participating in this small survey: http://www.surveymonkey.com/s/ZM3MTXX

     

    Threaded Messages (30)

  2. I personally think it would be important for JBoss AS to be spec compliant.

    It's a double edged sword; users of JBoss AS know their code will more likely also run on other implementations (and vice versa!) and for the Java EE specification it's important that one of the most popular implementations of it actually complies to it.

     

     

  3. I don't think it matters.[ Go to top ]

    Certification was barely important for JBoss back in the day; most Java EE developers don't bother deploying on more than one container. Compatibility is less important than function; if JBoss works, it works, end of story. Certification has been devalued for a long, long time now.
  4. I don't think it matters.[ Go to top ]

    Certification has been devalued for a long, long time now.

    By extension, does that mean the Java EE specification itself has been devalued as well?

  5. I don't think it matters.[ Go to top ]

    No.

    The thing is, what Java EE does is very important, and Java EE does it. The specifics of the way that an app server does those things with Java EE is less important.

    The question isn't "Can I do this with the specs?" but "can I do this with my app server?" The specs only matter for people who are writing frameworks - and servlet compliance here is a lot more important than any other spec. So if I wanted to write an app server, well, I'd aim for 100% compliance with the servlet spec, and ignore certification for the rest of it. 

    Nobody writes frameworks for EJBs, unless you consider Seam one.

  6. I don't think it matters.[ Go to top ]

    Nobody writes frameworks for EJBs, unless you consider Seam one.

    But the spec for instance defines portable global JNDI names.

    If JBoss AS wouldn't implement that (and how would I know, test everything myself?), then how can I be sure that this global JNDI name works on JBoss AS?

    How can I let my students read an "EJB book" if maybe 20% of that doesn't apply to JBoss AS, since JBoss explicitly or by accident choose not to implement that 20%?

     

  7. I don't think it matters.[ Go to top ]

    If you're deploying only on JBoss, the portable JNDI names don't matter. Same for the EJB stuff; you'll trend to what works, not what's specified, and JBoss itself has to do (and does) the same thing. If "what works" and "what's specified" are the same, all the better.

    To be clear, I'm for standards; I just don't see certification to be the most important thing ever.

  8. I don't think it matters.[ Go to top ]

    If you're deploying only on JBoss, the portable JNDI names don't matter. Same for the EJB stuff; you'll trend to what works

    I agree with that, but even if you only ever deploy on JBoss AS it can be a bloody pain to find out what works and what doesn't. People read blogs, articles, and some even read books.

    Those explain certain things, like how to setup a datasource in application.xml. But would you believe it, JBoss AS 6 doesn't really support defining datasources there. If it was spec compliant, it probably would.

    This adds to the frustration of developers using JBoss AS.

    In the extreme, you can no longer look for books on Java, but you have to look for books on JBoss Java. Every time you read a single article about EJB or JMS you have to wonder, is this "general" EJB, or is this about JBoss EJB?

    Now luckily JBoss did certify for the Web Profile, so Servlet, JSF, JPA, JTA and CDI among others are safe. But what's the next step? No certification at all? You just seemed to propose to only certify Servlet.

    If that were to happen, programmers would have to wonder, am I reading about general JSF or about JBoss JSF? Am I reading about general JPA or JBoss JPA.

    It gets worse...

    If Glassfish and Resin decided to do the same thing, the reader would have to wonder if she is reading about general JSF (whatever that still means then), Glassfish JSF, JBoss JSF, Resin JSF? Where does this end? Every current Java EE implementation being a totally different platform just like say RoR and .NET are totally different platforms? (yes, I exaggerate a little here, but the undertone is serious)

     

     

  9. it does matter[ Go to top ]

    Well, if it's not spec compliant, you won't really know if it works. Specs define 'working' precisely.

  10. it does matter[ Go to top ]

    Well, if it's not spec compliant, you won't really know if it works. Specs define 'working' precisely.

    Well a spec may "define" something, but doesn't mean it defines that something very well. Certification simply says that the tests that are present in the (top-secret) TCK are passed. It doesn't mean that there are adequate tests in that (top-secret) TCK to check that it matches the spec on all aspects. And, since the TCK is top-secret, you, the user, wouldn't know if it has a test for option X of the spec. Consequently, how important certification is, given the ridiculous constraints placed on it by the JCP (NDA just to request the TCK, pray that Oracle can be bothered to process your application for it, etc etc) is extremely dubious

  11. it does matter[ Go to top ]

    As far as I have seen personally, the Java EE TCK is actually quite thorough.

    As to the TCK not being "pure" open source I think there are upsides and downsides to that. The primary concern Sun had and Oracle has was the possibility of creating spurious clones of the official TCK that a specification lead/EG is supposed to be ultimately responsible for.

    That being said, I never understood the reasoning behind not granting Apache Harmony a full Java SE TCK. After all, a full, unrestricted Java EE TCK is granted to Apache Geronimo (and a commercial product like WebSphere CE is even based on Geronimo). I was hoping Oracle would fix this oddity. I am guessing they can't make that kind of change at the moment because of the Oracle/Google lawsuite?

    Cheers,

    Reza

  12. Certification IS a factor[ Go to top ]

    Joe, certification is definitely a factor - maybe not an overriding one, but something to consider.  As a buyer, avoiding vendor lock-in is one the many things I would look at when deciding on a tool.  If all other factors are equal between JBoss and another certified app server, then I would choose the certified product over JBoss (again, assuming all other things are equal)

  13. This is actually a very good question. We at Resin for example are simply opting for the Web Profile certification although we do include message driven beans, scheduling, remoting, JMS and asynchronous processing in the implementation. My guess is that JBoss will get the full platform certification anyway because it does matter to some of the larger companies that probably use commercial offerings today. The CORBA and EJB 2.x backwards compatibility pieces are a pain though...

    Cheers,

    Reza

  14. The CORBA and EJB 2.x backwards compatibility pieces are a pain though...

    They certainly seem to be.

    Would you think that JBoss maybe only 'boycots' the Java EE 6 Full profile and will certify for it again once those two items are pruned in Java EE 7?

  15. Augustientje,

    Personally, I find that intermixing technical and more "political" issues always backfires somehow :-).

    I definitely think the CORBA and EJB 2 pieces could be safely deprecated in Java EE 7 but that is ultimately up to the Java EE and EJB EGs. Other than those two pieces, there are other parts of the full spec like JAX-RPC, JAXR, the Java EE Management Specification (JSR 77) and the Java EE Deployment Specification (JSR 88) that are a little cumbersome for implementors. It's even somewhat questionable if JAX-WS is a common enough use case at this point (we do get requests for JAX-RS and JAX-WS ourselves though).

    I think it's always going to be a balancing act whether or not to create a full platform implementation with the introduction of Profiles. Relaxing the backwards compatibility gaurantees that Sun/IBM was/is always big on certainly could help trim things down out of the full platform in either case.

    Cheers,

    Reza

  16. Is JBoss AS not JEE certified somewhat related to Oracle making TCK closed source?

  17. <blockquote>Is JBoss AS not JEE certified somewhat related to Oracle making TCK closed source?</blcokquote>

    Well no.  They haven't and it isn't for one thing.  The TCK for Java SE does include a field of use restriction - nothing to do with Oracle though.  It was there in the Sun days to.  And it doesn't have any impact on Java EE.

     

    According to Pete Muir

    "The goal for AS 6 was to pass the Web Profile TCK as quickly as possible so we could promote some of the new and exciting technologies (like CDI) with a full JBoss run-time as soon as possible. Because AS 6 was built on the AS 5 code-base (which is a full EE 5 implementation), AS 6 does include additional JSRs as well.

    People shouldn't read too much into this - we're not turning our back on EE, we're simply trying to move as fast as we can because we see a lot of excitement around Java EE 6 - getting a JBoss Web Profile server out is an important milestone and you'll see us building on that for full EE 6 certification as part of the community roadmap for AS 7 and then a fully supported Red Hat product later this year."

  18. Forgot the link for the quote.  It is

    http://www.infoq.com/news/2011/02/muir_seam3

  19. Jboss AS have a nice reputation, and, with this, we spec nice patterns and accoplation to default implementations to promove interoperability. Without this, we´ll have an fork of this work, doing things out of this nice nice patterns, promoting a hell in suport, packaging, and so on. It would be better?
  20. Our community releases are focused on quicker turn around time so that the community can take advantage of certified features they care about.  For us this means a certified Web Profile and, additionally, certified JSR implementations for JTA, JAX-RS, JAX-WS, and JMS.  Legacy specifications like CMP and JAX-RPC have little usage today and are already schedule to be removed in EE7.

    That being said, AS6 still has features like CMP and JAX-RPC available, they are just in preview mode as they have not been certified.  Or they can just use an earlier EE 5 certified version JBoss AS.  We also plan on providing a fully certified Java EE 6 stack with our product release (EAP6).

  21. From a technical perspective, maybe/maybe not. From a business perspective, YES.

    I think this may be a very big blunder and could really damage JBoss. Other companies are going to jump all over this as an opportunity to further their own selves where the current clientele base uses JBoss and use it to discredit JBoss where you may be looking to gain inroads. My 2 cents.

  22. Most people think JEE is just a stack of APIs, but it's not. It's a specification, the base for vendors to build their implementations.

    And the way a product proves its commitment to the specification is by a certification process. I think that if we forget this we're missing what JEE is all about.

  23. Most people think JEE is just a stack of APIs, but it's not. It's a specification, the base for vendors to build their implementations.

    And the way a product proves its commitment to the specification is by a certification process. I think that if we forget this we're missing what JEE is all about.

    I fully agree. You can't compare JEE against various API's without taking that into account. Some people also tend to not understand that writing a spec takes more time than writing a random project.

  24. Full EE6 compliance is coming[ Go to top ]

    I've seen that Bill has already replied to this directly and Pete by proxy through his InfoQ interview. However, I just want to make sure that everyone is aware: we will be releasing a fully EE6 compliant/certified application server instance in the future. It is our plan to do this as quickly as possible given other commitments and community requirements, but I won't be drawn on an exact date. I believe that EE6 is very important to the industry and specifically to JBoss, so walking away from it is not an option. The reason we went with the Web Profile first is because you pretty much have to pass through that configuration on your way to EE6 compliance.

  25. Full EE6 compliance is coming[ Go to top ]

    I've seen that Bill has already replied to this directly and Pete by proxy through his InfoQ interview. However, I just want to make sure that everyone is aware: we will be releasing a fully EE6 compliant/certified application server instance in the future. It is our plan to do this as quickly as possible given other commitments and community requirements, but I won't be drawn on an exact date. I believe that EE6 is very important to the industry and specifically to JBoss, so walking away from it is not an option. The reason we went with the Web Profile first is because you pretty much have to pass through that configuration on your way to EE6 compliance.

    But EE6 compliance is comming for version 6.0 of JBoss Application Server or for version 7.0 of JBoss Application Server??

     

  26. From my perspective it is important to have a product that implements and complies to the spec. Whether this product has the certification from the "official" authority is of less importance to my mind.

  27. From my perspective it is important to have a product that implements and complies to the spec. Whether this product has the certification from the "official" authority is of less importance to my mind.

    But if the "official" authority doesn't say a product complies with the spec, who does? The vendors themselves?

  28. But if the "official" authority doesn't say a product complies with the spec, who does? The vendors themselves?

    How do you think it works with certification for any normal JSR? The vendor runs the TCK and informs the "official" authority that they pass, and that authority register it in a database; nothing more. All the mor reason for a TCK to be public under a suitable license so that anybody could validate claims, and/or contribute to such a TCK to make it more complete

  29. Actually, that is not correct at all. It is ultimately the responsibility of the specification lead and EG to ensure that an implementation that claims to have passed the TCK actually does. That's precisey why getting certified is vastly different from simply "passing the TCK".

    Unlike a random piece of software, the integrity/correctness of a TCK is critically important. That's precisely why even in a hypothetical world where TCKs are open sourced, they should have some pretty strong copy protections (certainly stronger than GPL) such that there is only one "true copy" verified and maintained by the folks responsible for the corresponding specification.

    BTW, vendors are encouraged today to report any issues they see with any given TCK to the spec lead/EG. In fact, that is what a JSR maintenance release is all about.

    Cheers,

    Reza

  30. TCK[ Go to top ]

    Actually, that is not correct at all. It is ultimately the responsibility of the specification lead and EG to ensure that an implementation that claims to have passed the TCK actually does. That's precisey why getting certified is vastly different from simply "passing the TCK".

    We're talking of two different things here. You're talking theory and I'm talking practice. As far as the vendor sees if (and I am one actually, for other JSRs) they receive a TCK (well, they do when Oracle can be bothered sending them one, which isn't too often). They run aforementioned TCK against their software. They pass it. They report that back to "high command". High command enter it into a database/spreadsheet with the exact version that is claimed to pass, and the URL where it is available from. That is it for the vendor, they can then claim compliance. Whether high command do anything further is invisible to the vendor. Yes, I've been through the process, and that is how it was. Maybe it has been different for other JSRs but then my comment was "my experience", and that doesn't make it "not correct at all" (if it happened for me, most likely its happened for others).

  31. it should be---[ Go to top ]

    I think jboss should not start its own track as following standards was/is a major reason for sucess of java platform. everyone from developers to stakeholders feel comfortable that their projects are easily portable. if i cant port my already existing apps to jboss or apps developed on jboss to other application servers, i might think to exclude jboss out of my list.