Reading that JBoss AS 6 was only certified for the Java EE 6 web profile got me worried a little. Among others this web profile does not support the following:

Message driven beans

Asynchronous processing

Scheduling

REST (JAX-RS) end-points

JMS

JavaMail

JNDI

RMI

These are however all technologies we heavily depend on. I understand it's a pain to support EJB2 and CORBA and I know very few projects that use them AND are willing to upgrade to Java EE 6 (typically those projects running on EJB2 tend to keep running on J2EE 1.4 servers IMHO).

I'm not sure a lot of the above is legacy or deprecated. I know it's (still) supported in JBoss AS 6, but it does worry me a little. Especially asynchronous processing in EJB (@Asynchronous) is a brand new feature in Java EE, so if the certification for the web profile was chosen to leave out the legacy stuff, then maybe something doesn't quite add up?

Note that the technologies that you listed above are functional in AS6.0 Final.

I know, I just felt slightly worried that not certifying them might be the first step to eventually not support them at all. That's a highly speculative thought of course, and knowing how much efforts JBoss spents on its worldclass JMS implementation for instance this maybe isn't likely. But still...

It's just that the full profile certification process formalities haven't been carried out on those.

Are there any plans related to this? E.g. do you plan on having a fully certified Java EE 6 implementation eventually? (JBoss AS 6.1, or JBoss AS 7)

Was there any part of JBoss AS 6 that didn't pass the certification test, or didn't you bother to take the test at all?

To begin with, JBoss AS 6.0 is a Java EE 6 Web Profile implementation. Does this mean AS 6.0 implements only the Web Profile? Not really. JBoss AS 6.0 bundles almost all the technologies required by the full Java EE 6 spec, including the legacy stuff, like EJB2 and RMI/IIOP, however, we chose to certify only for the Web Profile at this stage due to resource constraints. (This is also a very good way to gather input and see how many people actually do care about EE6 full profile compliance, just scream in the forums!).

Are there plans to do the full Java EE 6 certification for EAP 6? It would seem that businesses purchasing licenses and support would be more inclined to want a full Java EE 6 certified solution (even though for most purposes this ends up being more of an item on a laundry list that an actual statement of business need).

Are there plans to do the full Java EE 6 certification for EAP 6? It would seem that businesses purchasing licenses and support would be more inclined to want a full Java EE 6 certified solution (even though for most purposes this ends up being more of an item on a laundry list that an actual statement of business need).

I'm not sure. Doesn't your statement call the entire idea of Java EE being a specification into question? If no one except Glassfish certifies for the full Java EE specification, then what is its practical use really?

The reason that I would like to see such a certification is that I want to be reasonably sure my code which includes e.g. JMS also runs when I move it to another Java EE implementation. I've personally been through 2 migrations of a huge single code base from one J2EE and Java EE implementation to the other, and the fact that there was such a thing as a standard made this both times a relatively painless process.

If all vendors are going to just side-step the Java EE spec from now on, I'll see some bleak times ahead.

Okay, you're complying to the Java EE web profile now, but following the same line of reasoning you might say with the next JBoss AS release that a Web Profile certification is also just an item on a laundry list instead of an actual business need. Java EE will then end, and we'll have a JBoss platform, and a Glassfish platform, and so on. It's a slippery road.

Maybe you are just opposed to 'legacy' stuff though and see the Web Profile as modern and the full profile as old?

I don't think it's that clear cut. The Web Profile is now basically the simple and most popular stuff, while the full profile contains more advanced stuff in addition to legacy. Maybe Java EE needs a new profile called "legacy-free"? This could exclude EJB2, Corba, JSR 77, JSR 88, while definitely keeping some of the more advanced but surely not legacy things like JMS, message driven beans and certainly jax-rs, which is absolutely not legacy but instead a very exciting and modern API and platform.

I don't think it's that clear cut. The Web Profile is now basically the simple and most popular stuff, while the full profile contains more advanced stuff in addition to legacy. Maybe Java EE needs a new profile called "legacy-free"? This could exclude EJB2, Corba, JSR 77, JSR 88, while definitely keeping some of the more advanced but surely not legacy things like JMS, message driven beans and certainly jax-rs, which is absolutely not legacy but instead a very exciting and modern API and platform.

You are describing the functionality of JBoss Application Server 6 here. We have JMS, MDB and jax-rs. Its just not a set which can be certified as such.

Let us know what you're missing in AS 6. Either we ditched something important or we forgot to list it in the release notes.

@Henk: I think that you read more into my parenthetical remark than what I had intended. Companies often use checklists when comparing one vendor to another. In such cases you often cannot compete if your product does not meet one of the requirements of the checklist, regardless of whether that particular checklist item meets a business need. For example, if JBoss AS is certified only for the web profile, while some other app server is certified for the full profiles, then JBoss AS is at a disadvantage even if JBoss AS will meet the business needs and even if it does implement the specs required by the business (in other words, implements the full Java EE 6 spec) but just doesn't have the "certified" stamp, and even if the business needs can be met by the web profile (ask me how many customers I have dealt with who insisted on a full Java EE stack when all they really needed as a servlet container).

My statement was not to say that certification was not important. It is important based on the points that you made. Without it there would be more chaos in the Java world than there currently is.

@Henk: I think that you read more into my parenthetical remark than what I had intended.

[...]

if JBoss AS will meet the business needs and even if it does implement the specs required by the business (in other words, implements the full Java EE 6 spec)

[...]

My statement was not to say that certification was not important. It is important based on the points that you made. Without it there would be more chaos in the Java world than there currently is.

I'm glad to hear that, and indeed exactly for that reason. The Java space is very fractured, and the Java SE and Java EE standards are one of the few truly binding factors.

If you do technically implement the full Java EE 6 spec, then why not prove this to your customers by getting the certification? I do trust JBoss enough that if they state they fully support the Java EE spec, then this is indeed true. The problem is thus not a technical one. JBoss AS does support the full Java EE stack.

Is it then a kind of political reason for not getting the official certification? You obviously aren't against the JCP or certifications, otherwise JBoss AS wouldn't have been certified for the Java EE 6 Web Profile. But again, it's also not a technical problem, since you do fully support Java EE 6.

I'm just a bit in the dark here why there isn't a full Java EE 6 certification for JBoss AS 6 then.

I'm just a bit in the dark here why there isn't a full Java EE 6 certification for JBoss AS 6 then.

Because certification takes a significant amount of time and resources (both human and equipment). And with a constrained budget that everyone seems to have nowadays, spending the time and resources (and thus $$$) on certification takes away from other pursuits (new implementation, enhancements, etc). So the question comes down to what brings the most value to customers and to the company providing the product. As Dimitris blog points out, the JBoss team is not against pursuing certification, they just want to make sure that there is a real need for it before doing so. Your vote an Arjan's vote are two votes in favor of doing that. My original question came about because I know that for my company having EAP 6 certified is important (and I know someone in the company will ask me abotu it sooner or later so I thought i would at least inquire as to the answer).

Because certification takes a significant amount of time and resources (both human and equipment).

I see. Maybe there is definitely a need then to have the certification process simplified? I can understand that building a fully compliant implementation might take a lot of time and resources. But once you have such an implementation, 'proving' that it complies to the specifications shouldn't be such a hassle, should it?

Enterprises might indeed sometimes demand certification for questionable reasons, but as an engineer an important aspect of certification and spec compliance is that I can be sure that knowledge I learned from Java EE 6 books and articles is applicable to JBoss AS 6 without restrictions, and that I can have new co-workers hired who know "Java EE 6" instead of "JBoss Java EE 6", and that Java EE 6 code we obtained from whatever source incorporates fine with our other Java EE 6 code running on JBoss AS 6.

I don't really have good memories from over a decade ago when C++ compilers all supported "C++", but all to varying degrees of compliance with the spec.

If JBoss AS 6 fully supports Java EE 6, but just not officially, then this is a relief to hear although I can't help to still feel slightly discomforted. I do wonder what other developers think about this. Since JBoss AS 6 has just recently been released, it might be that a lot of people don't fully realize yet that Java EE isn't fully officially supported this time around. Either that, or I'm one of the only nuts who cares. We'll see

I would also like to raise my hand for full EE 6 certification. Sure, it's easy for me because all it costs me is a post on a forum ;-)

But on a more serious side, it's hard to play the "no vendor lock-in" card when trying to convert managers used to propriatary technologies when you don't have any proof that you can bring to the table.

I'm unfamiliar with the certification process but I was under the naive impression that all the technologies in the stack already worked again some TCK to ensure they fulfilled the spec and all you had to do is go "Look, mama, it runs!" and flash a credit card and that would be it.