Peter Johnson wrote:
Are there plans to do the full Java EE 6 certification for EAP 6?
EAP 6 is planned to be based on AS 7 http://community.jboss.org/message/578489#578489. So I'm sure that it will be certified for Java EE6 full profile.
John Waterwood wrote:
What does the spec mean if the most important open source implementation (jboss) isn't spec compliant? Will the spec be for the big closed source vendors again?
I'm assuming that you have read the referenced blog and other replies in this thread. And it's not about JBoss vs closed source vendors.
The primary reason why AS 6.0 Final couldn't make the full profile certification was because of lack of resources. Given the timelines for releases of AS6 and also the parallel development of AS7, it was decided that we would put our efforts in making 6.0 Final web profile certified and release it to the community. The full profile certification hasn't been ruled out as Dimitris mentioned.
Nicklas Karlsson wrote:
OK, it's understandable if AS 6 is only a "in-between"-version. Of course, if AS 7 final drags out to 2012 it's unfortunate.
I agree with that. If AS 6 is simply a kind of early release and AS 6.1 or AS 7 will be the real 'final' in terms of official Java EE compliance, then this would be understandable.
Today I did some casual asking around among some friends and co-workers, and it appeared that almost all of them where under the impression that JBoss AS 6 final would be certified for Java EE 6. This is of course but a small sample in a particular group, but it may be indicative never the less.
Please, don't read too much in the web-profile vs full-profile issue, because primarily it is a resourcing issue. Personally I'm in favor of going for the full profile for the reasons mentioned in this thread and JBoss AS 6.0 is not far from that goal. We are going to take a closer look and see what can be done, although now the focus has to move on AS7.
I also agree it would be nice if we somehow had a full-but-legacy profile because in some cases, like AS7, where you want to drop all the excess baggage it's kind of hard to bring back the legacy stuff just to get the certification stamp.
Some technologies (e.g. JAX-RS, JAX-WS, etc.) do have their individual TCKs and AFAIK we do pass those standalone TCKs, if that is any comfort.
In any case, keep your comments coming. They are extremely valuable to help us understand what our users/community/customers really need.
Nicklas Karlsson wrote:
(bordering to thread-highjacking but it's sort of related)
Will the individial components/modules be pretty much the same in AS 6 and AS 7 and the focus in AS 7 is mostly management, performance, startup times, memory footprint and classloading?
Components will be mostly the same, it's the configuration/management model that is significantly different and the integration part.
This will become more evident with the first AS7 Beta due in a couple of months, or so.
Maybe a different thread would be appropriate for that, so that our architects can jump in and explain...
Nicklas Karlsson wrote:
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.
If only it were that easy. I can shed some light on what the certification process is really like. It is indeed very labor-intensive. Read this long post if you want the full scoop.
Step 1: Integrate the container with the TCK
If a container has never run against the TCK, give yourself three to four weeks to figure out how to integrate the TCK with the container. In this case the container is JBoss AS6. Build whatever "test harness" is needed to make it work. Then standardize the test harness so others in the organization can use it. Document it and be ready for lots of questions.
I don't really know if three to four weeks is accurate because I never did that part. I'm just guessing. But I'm very familiar with the rest. Also, that part is not very relevant to this discussion because we already did most of it to certify for the Web Profile. So full EE6 compliance wouldn't require that much extra work in just figuring out how to make TCK run. But I tell you all this to point out that the full JEE6 TCK is a HUGE COMPLICATED BEAST.
Step 2: Divide and conquer
So, now that you've figured out how to make it run, it's time to divide up the work. There are thousands and thousands of tests. I don't remember the exact number, but we've probably had 20 people at a given time, each assigned to a group of tests based on their area of expertise. These are mostly the component leads. We may not be each working on TCK full time, but it's a big part of the job and we may delegate even further to other members of the team.
Also, someone is coordinating all this. Someone is keeping a spreadsheet of who is assigned to what tests and how much is passing on TCK runs in Hudson. Of course, someone else is maintaining these Hudson runs. Others are tracking the failed tests and coordinating their resolution.
Each developer needs to set up the TCK to run locally. If you've never done this before, give yourself a couple of days to get it running. If you HAVE done it before, give yourself a full day to get it running on a major new version of AS. TCK is a HUGE COMPLICATED BEAST. It can take a couple of hours just to download everything you need to run it. Actually getting it to run locally is quite painful.
Step 3: Get your component to pass 100%
Now it's all set up and you can finally test your code. It's likely that almost nothing will pass the first time. But most tests are failing for the same reasons. So give yourself a day or two to figure that out and you'll end up with about 80% passing. After a couple of days you figure out that many of the remaining 20% are failing for some other reason. That gets you to maybe 90% passing.
Now comes the hard part. It's not that easy to find why a particular test is failing because you didn't write the test and it's probably not well documented. So you have to read the test code and figure out what it is trying to test. Sometimes you can see that it's testing a particular part of the spec and sometimes it's not that clear. You might even need to go back to Sun and ask questions about it.
Once you figure out what the test is trying to test, you have to figure out why it is failing. You hope and pray it is just a bug in your code and not a bug in the TCK itself. If it's a bug in the TCK it might take a long time to get someone to fix the TCK and give you a corrected version.
But there is a third reason that a test might be failing. If it's not a bug in your code and not a bug in the TCK then the test might fail because the spec wasn't clear enough. In other words, you coded according to the spec but the person who wrote the test interpreted the spec in a different way. If you end up having to defend your implementation of the spec then that could go on for a very, very, very long time.
So that's the process. Hopefully now you've got the picture. But if not, think about it this way. Assume that the last 10% of failures is maybe 100 tests in your assigned area. Imagine if someone suddenly presented you with 100 bug reports. All of them aren't real bugs, but how long would it take to resolve them all?
In summary, I'd like to say that I concur with Dimitris in that I'd love to see us finish the certification on AS6. But in the long run AS7 is more important so we have to allocate our resources wisely. I'd also love it if there was some way we could get community help on TCK. I don't think that's feasible from a legal standpoint but maybe someone should look into it.
henk de boer wrote:
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.
What you just described is the future "full profile". The legacy technologies where "pruned" in EE6, which means they will no longer be a required part of the platform in EE7.
AS6 includes support for compliant implementations of JMS, JAX-RS, and JAX-WS.
We do understand your point-of-view. I guess the community fears the "it's all fixed in the next version"-syndrome where all your brightest minds jump on AS 7 (the why-didn't-we-do-like-this-the-first-time release) when AS 6 barely has hit the streets. Yes, all developers know it's more fun to toy around with new ideas that no-one assumes works yet ;-)
While the components are probably pretty much the same, I think AS7 will still be interesting (classloading changes, modularization, startup time, admin interfaces etc).
When it comes to TCK:s, I have only seen the JSR-299 TCK integration and that was quite resonable, I guess not all TCKs are created equal (OK, there is order of magniture in size difference between those, also).
But back on the topic of certificatio, If JBoss/RedHat had certified AS 6 and SpringSource came along and said "Hey, we have this EE 6 server, everything works but we haven't had the time to cert it", they would be smashed to the ground ;-)