As I'm sure you've all seen, Java EE 6 has gone final. You can now download the Final Release of the Contexts and Dependency Injection, Bean Validation, Java Persistence API 2 and Java Servlet 3 specifications from jcp.org, and read the linked javadoc for the entire platform. It's also a good chance to check out the Java API for RESTful Web Services specification, which now includes CDI integration, if you havn't already.
Sun have also published a three-part overview of the new platform and the Java EE 6 tutorial and sample applications.
It's just fantastic to finally see the fruits of all that work :-)
Created: 12. Dec 2009, 00:10 CET (Gavin King)
Last Modified: 12. Dec 2009, 00:11 CET (Gavin King)
Very informative post indeed!
I skimmed thru the three-part overview and thought about the fact that there is seemingly only one profile available in this final release. It would have been more interesting if there were more. But more importantly, apparently if a team has a profile (e.g. telephony profile or mortgage processing profile, etc.) it must be submitted to the JSR EG team for review, etc. Is it possible to create our own profile independently or must it be standardized (sounds like it must be standardized so others teams can use it which is not a bad idea ultimately)? You can compare this process to writing portable extensions for CDI, but PEs do not require new JSRs and review, correct?
This is interesting:
Has anybody in the JCP done comparative analysis similar to what this graph depicts as far as the total number of pages in all the specs per release of each version of the platform?
Number of spec pages is not a proxy for complexity. You can add pages without adding any new features of new complexity, just by better nailing down the definition of some feature, by adding examples, or by adding more verbose explanations.
What do you estimate the JSF 2 would be sized at after a rewrite (in the spirit of the 299 spec, keeping the information)? It is not for the faint of heart...
The EE tutorial was impressive, you don't write that in a week...
Yes, the documentation is very good.
I was reading the Spring3 docs (trying to size it up against EE6 web profile):
So they're basically picking and choosing the JSRs in EE6 (apparently limited to Bean Validation, JSF 2.0, and JPA 2.0) but not CDI? I'm assuming because they already have their own proprietary DI mechanism with setter and constructor static injection as well as conversation scope support in Spring Web Flow...
Note that Spring3 is well ahead of Seam3 in terms of final release date. They're already on 3.0.0.RC2...
Is the inspiration for EJB 3.1's @Asynchronous annotation from Seam?
1) how is EJB 3.1's unit testing facility with JUnit or testNG, for example? Do you still need something like JBoss embedded container?
2) how is EJB 3.1's redeployment capability in terms of hot incremental deployment via a special classloader like Seam or JRebel or otherwise?
I know that as of EJB3, we have been referring to EJB's as POJOs, but they're not exactly equivalent if you consider the two points above, correct?
Also, in EE6 we have the option of packaging our EJBs directly in a WAR along with other POJO classes and deployment descriptors, etc. What is the advantage of using simply a WAR rather than a WAR in an EAR? Yes, it's cleaner/simpler, but any other advantages?
You don't need any kind of container to unit test EJBs since version 3.0. Do you understand what the term means?
For integration testing, you will need some kind of container. Just like you do for Spring beans, Hibernate/JPA entities, CDI managed beans, or any other kind of container-managed object.
Incremental hot deployment has absolutely nothing to do with the EJB spec, as I've explained to you before. This all depends upon limitations of the Java Virtual Machine, and of the container implementation.
I don't use the term much, because it's become more or less meaningless through overuse, and as a result of changes in technology (e.g. annotations). So I'll answer your question with a question: considering the two points above, how are EJBs in any way different to Spring beans, Hibernate/JPA entities or CDI managed beans? They're not different at all, right? They are all container managed objects, with certain programming restrictions, and annotations. They all have a natural programming model. They can all be easily instantiated using new and unit tested. So if Spring and Hibernate beans are according to your personal definition, then so are EJBs, right?
And what precisely do Spring 3 and Seam 3 have to do with one another? I mean, apart from sharing the same version number? Is Oracle 10 database of Windows 7 OS?
@Asynchronous methods are one of the features I proposed to Sun when they were first scoping out EJB 3.1. So, yes, I suppose so. But not that Seam is definitely not the first framework to have asynchronous methods.
How close can we get to 100% hot incremental deployment with an exploded EAR/WAR? I wish EJB 3.0 was hot incrementally deployable (I know JRebel guys are working on this for the next release!)
Where are applicable archetypes?