Reza Rahman

Thanks and agree!

Well done. My thoughts on some of this from a while ago: https://dzone.com/articles/spring-java-ee-and-the-lilliputian-wars. Hope it helps some get a new perspective.

As the absolute graph shows Scala, etc growth has basically flatlined for years. At the current very modest trajectory that's the way it will stay for the forseeable future. That means it's foolish to bet your career on Scala unless you want to stay in a tiny niche forever or worse.

As to language incedes, take a look at Java's continual rise here as noted by many other such articles post Java 8: http://www.codingmakesyouhappy.com/2016/01/java-popularity-rises-to-top-awarded.html. Scala on the other hand was once predicted to be a serious contender to Java but now languished for a while at a very modest number 25-35 along with the likes of Prolog, Haskell and Erlang with no real improvement in sight any time soon. Here is a good writeup on the dramatic fall of Scala's fortunes.

Some obvious math to keep in mind that probably most people readily realize: earning a dollar more for someone that just makes a dollar is "100% growth". A dollar more for someone that already makes 100 dollars is 1% growth...

Beyond one-off opinion, I think the survey on the referenced website will make what is needed pretty clear. My understanding is that there are already 500+ votes that basically confirm the initial approach. I certaily agree with it.

In my view the vast majority of finer grained microservices start with simple REST. Servlet, JAX-RS and CDI is a good solid basis for that. Indeed personally I think too fine grained microservices is something to be avoided anyway in favor of sensible coarse grained subsystems that align with business contexts. Thin, fast deploying war files are ideal for such an approach. Such deployment units rarely exceed the 10 MB mark and in modern Java EE runtimes deploy in mere seconds.

That's precisely what is being done.

The profile is a very minimal set that makes sense for the vast majority of microservices - namely what is needed for a very simple REST endpoint. The majority of the work is about having a very consistent way of adding well understood standard APIs (mostly Java EE APIs) and additional features such as metrics and a fat jar deployment model. It's also a way for multiple vendors to collaborate on a single plaform instead of having proprietary islands that have nothing in common.

By the way, the Spring Boot engineering team is also contributing to this project. This isn't about the artificial Spring vs Java EE holy wars.

Good bye indeed. Last I checked I am not posting on Scala articles trying to trash another technology and tout my own favorite so I am not really sure who is argumentative. If you want to see the lackluster state of Scala adoption here is a telling graph referenced for your convenience.

I think the adoption data for Play says it all. The reality is that it doesn't offer enough for any signifcant adoption vis-a-vis far more predominant Java/EE web frameworks. The same for Scala and Akka. They are obscure niche technologies that have seen little adoption after years of heavy marketing. There's little objective indication that will change any time soon.

I think the data speaks for itself as to Scala adoption.

I hate to tell you this, but for most people interested in job security, Scala is definitely not the way to go, Java is. You'll see numerous industry articles saying the same thing. Take a look here just as one casual example. You won't see a single analyst saying the same thing for Scala, because it just isn't reality.

As to recruiter calls, if you talk to Java developers, you'll find that pretty much anyone with a few years of Java experience is flooded with them. It's so much so that we now bar recruiters from our Java User Group.

Do you realize Scala adoption has long stagnated? It actually is falling consistently while Java is rising in the language indeces post Java SE 8...

As to Play, it's just another MVC framework, of which we already have plently in Java generally as well as Java EE. In this DZone survey, it shows very minor adoption for Play. It's situation is the same or worse in many other web framwork surveys...

As to Lagoom, what honestly makes you think it will have any traction in an already overcrowded Java microframework space dominated by the likes of Spring Boot, DropWizard, Payara Micro, WildFly Swarm, etc, etc? Isn't it more likely it'll have at best marginal adoption like Scala, Akka and Play did for years?

Thanks very much for your comments. Always good to hear voices of reason. Please do consider signing the petition and encouraging others to do the same if Java EE has provided you value.

You are entitled to your opinions of course, but you should take a look at the DZone adoption survey data I posted earlier. What that shows is that most Spring developers in fact likely consider themselves Java EE developers as well. It is no accident that the only Java EE technologies Spring does not really support well is EJB 3 and CDI. As a casual example, JPA, JAX-RS, JSP, JAX-WS, WebSocket, Bean Validation, JMS and JSF are all predomintant technologies in their respective spaces. Even Spring Batch is now Java Batch compatible.

Food for thought before making too many broad generalizations.

Aside from the fact what you are suggesting means abandoning Java, the .NET ecosystem offers even worse lock-in than any Java/JVM based solution.

The point to understand about Java and Java EE is that it is by far not just about Oracle. Indeed, everyone else in the JCP process (including Red Hat and IBM) is deeply concerned about what Oracle is doing. Everyone should read the recent JCP executive committee meeting minutes here and then sign our online public petition to Oracle executives. The petition has already gathered close to 700 signatures in just a few days. Quick momentum on the petition will help resolve this issue sooner rather than later so all Java developers should be pitching in now...

I have tried both Akka and Spring Boot. I don't see them as viable replacements to Java EE at all.

Firstly Spring and Spring Boot continue to depend upon Java EE APIs heavily. Secondly, the downside with Spring remains feature bloat, comparative configuration complexity and vendor-specific APIs. By comparison things like Payara Micro, WildFly Swarm etc offer simplicity and vendor neutrality if you want far jars (as I mentioned earlier I don't in the first place for sound logical reasons). Here is a good comparison talk.

As to Akka, it is totally focused on a completely different problem domain than Java EE and is even more complex than Spring Boot. With Akka, you are 100% down an async path of no return your application may or may not actually need. By comparsion, Java EE offers a simpler synchronous model by default and allows you to make things reactive/asynchronous as you go at each APIs level. Here is a talk on the reactive features in Java EE.

It is a dangerous line of thinking that we won't be much worse off in the industry without standard vendor neutral APIs vendors agree on. The end result will be vendor-lock in silos with no alternative to remain neutral.

It's OK to agree to disagree and avoid bickering.

In each of these cases, there is actually technical merit at play as well. It is true dominant technologies are not always the ones with technical merit. On the other hand, when something is in a small niche for prolonged periods of time, it's really a good indicator it probably lacks technical or market merit. It's of course a fine art how small of a niche is too small. For me it's the first, second or third front runner on a consistent basis for about five to seven years or so. Certainly for my clients I would have a hard time recommending a solution outside of the reasonable mainstream.

What I see in your post is a lot of personal opinion not backed with many objective facts.

Let's indeed start with JSF. Here is an analysis of actual reliable data on the topic: https://blogs.oracle.com/theaquarium/entry/survey_confirms_jsf_remains_leading. What it shows is that JSF and MVC are perpetual favourites for many years. Both are now options in Java EE 8.

Java EE has nothing to do with application servers per se. If you want a fat jar, you can use Java EE and WildFly Swarm, KumuluzEE, Payara Micro, etc. In my view though, fast deploying thin war files are still the no nonsense way to go. Here is a great recent blog entry by Sebastian Daschner on the topic.

As to your favored obscure DI framework, please show adoption data and I'll begin to take you more seriously. The reality is that Spring and CDI dominate the DI space today and in the foreseeable future. Both are more similar than different today.

The fact about Java EE some of us in the enterprise enjoy is that it standardizes proven, stable, easy-to-use mainstream APIs, not experimental unproven stuff on the fringes. Here is some recent actual reliable Java EE adoption data you might want to take a look at to understand the total footprint of Java EE: https://blogs.oracle.com/theaquarium/entry/developers_affirm_strong_support_for. This data is the precise reason why what Oracle is doing needs to be stopped sooner rather than later

Care to detail what these supposedly better solutions are and why you think they are better? I've been developing Java since the nineties. Have seen lots of stuff that claims to be better and few that actually is in any meaningful way.

You seem like a pretty sensible enough guy so I'll respond and try to avoid a needless flame. As was pointed out on this now rather unreadable thread already, most of the work is actually now already done. NIO based data access is really the last practical bit of work left to be done (and it is a big one no doubt).

It's also an open debate whether async and NIO developement is really right for the blue collar enterprise developer. The focus on simplicity, blue collar development and buzz-word avoidance means by and large the Java community still keeps things like reactive programming at arms length. Personally I think that's a pretty wise move for a very pervasive technology with a sizable install base and large ecosystem dependent upon it.

Peace.

Async/NIO data access is in fact a real deficiency in Java. Sadly it is not on the Java SE roadmap until Java SE 9 or later. Which means it will take even longer for Java EE APIs like JPA and JTA to adapt to it.

Just what I thought - basically you don't have the first clue what you are talking about besides trolling on behalf of your beloved Scala (probably the only thing you really know anything about). Of course you can't offer anything specific other than vague flames when it comes right down to it.

I'll go ahead with my first instict now and not further feed the troll...

Happy flaming.

Let's keep it substantive and not devolve further into poinetless flames, shall we?

We are currenty actively working on Java EE 8. What specifically would you like to see further simplified and why?

Concrete code examples clearly demonstrating a Java EE use case simplification is invaluable.

Thanks in advance for your help.

With all due respect, I beg to differ.

It's not just a lines of code issue. I've seen numerous developers struggle to get to the right Spring configuration both in development and maintenance because there is so much to understand even to get started.

By comparison, JTA configuration is simply never necessary. It's hard to argue how that's not simpler.

I really had to think long and hard whether to further clutter this already pretty unreadable comment thread. I decided I'll state my mind anyway.

I have seen dozens of Spring applications in my long career. I did not see a single application yet that could not have used JTA instead with absolutely zero out of the box configuration.

Similarly I have seen dozens of Java EE applications that have no feature needs beyond what is already available in JTA. If I did I would have asked for those features in the JTA EG myself.

What do I think this honestly means? The myriad Spring configuraton features are probably not that useful beyond very rare cases and just adds unneeded configuration burden for most applications.

Peace.

Here is just one benchmark: https://github.com/struberg/jtabench. There are others such as from Adam Bien.

Only JTA comes with full guarantees of standardization and reliability across many use cases without much of a downside. Anything else simply does not offer that. The isolation feature you cite is a good example. The reason JTA does not offer it is because it cannot be used reliably in all use cases unless set at the data source level. Setting isolation at the data source level is supported by most application servers when needed.

Let's beg to differ that mlliseconds matter for most applications where the total transaction usually takes in the order of seconds or more.

I must beg to differ. Many folks in the Java EE community have benchmarked this repeatedly and the difference is in the order of milliseconds - a tiny fraction of the overall time to exeute any practical query. For the vast majority of applications, this is a non-issue.

The reality is that you can use JDBC transactions if you want to. Doesn't mean you should. Declarative JTA is far more easy to use, less verbose and reliable. That's Henks well made point above.

Firstly I just want to say thanks again for your continued exemplary contribution to the community. Where would we be without folks like you? I apologize for not supporting you here better. In my defence, it was Easter.

Secondly I hope you don't take anything on this thread personally. There are people involved here that are in no position to question your tempermant or anyone else's themselves...

Lastly I wanted to tell you that nothing we are doing is intended to be against the JCP. It is something every one of us continue to value as should all Java developers.

This is a very keen observation and I wish I could disagree. While I and others folks in the group are most concerned about Java EE, the reality is that we have good reasons to distrust Oracle generally with Java. What's happening with Java EE is just the most visible symptom of a much broader problem...

Sticking to facts and not childish hot air, take a good look here: https://blogs.oracle.com/theaquarium/entry/developers_affirm_strong_support_for. The reality is that Java EE and it's APIs are used more frequently than Spring and always will be.

Many folks like me have been using Java EE for years and would chose it over Spring any season of the year :-).

Anyone can see for themselves what Java EE today is about through the many folks that are publicly sharing their real world adoption stories these days - many right here on DZone. As a casual example, take a look at this one and see what they have to say about Spring: https://dzone.com/articles/java-ee-7-in-production-at-gam-electronics.

No one said you need to agree. If you want to live in your Scala bubble keep going, your loss.

I don't even want to point out the irony in a Scala fanboy arguing on current adoption of any technology as indicative of it's actual merit. Check out the well grounded adoption data for Java vs. Scala lately. Then again, you probably live in your won virtual reality bubble on those facts as well...

This is indeed accurate and something Peter covers in his talks.

I think this is quickly devolving to a pointless flame war with very limited value add. It's been clear for years both Java and Java EE are way past the point of FUD. Your bluster does nothing to convince me and I doubt it does anyone else either. It's no surprise Scala/Akka adoption never impresses in any broad factual survey anywhere.

I have kept a close eye on Scala and Akka for years. Have been convinced for all those years nether will ever see any broad adoption because of overkill complexity.

You are entitled to your opinions of course but since you mentioned being informed, maybe you should check out some of the work Java EE advocates put out demonstrating on live stage why modern Java EE and Java are about simplicity above all else.

I have a talk about simple and pragmatic reactive programming in Java EE, maybe it'll be an eye opener for you? That being said if you are a Scala/Akka fanboy I suspect it won't be mind-bending enough for you?

Modern Java is about annotations, lambda, CompletableFuture and so much more. Worth being informed instead of antiquated references to "J2EE" and FUD.

Take a look at the work by Peter Pilgrim. He shows you how and why you should consider Java EE with Scala too. That being said, not a fan of Scala or Akka at all personally. Way too complex for the normal blue collar developer. Simplicity rules in modern Java EE and Java.

Thanks for your faith in us. Please stand by for a call to action from all of us. You don't have to be a bystander. You can help make Java EE what it should have been years ago.

Beyond all your bluster, take an honest look at some recent surveys and Adam Bien's Java EE adoption stories to begin to understand just how many people are in fact using Java EE and suceeding with it. Even the most strident Sping fanboy should admit (but I'm sure won't) most Spring users in fact also consider themselves Java EE users. Our goal is to protect the best interests of all these developers, not to egage in pointless tribal turf wars.

Thanks for writing on GlassFish. Care to chat about the GlassFish community some time? Please email me? Reza dot Rahman at Oracle dot com.

Just a few quick facts for completeness (for the unaware), a desire a get a bit more clarity and nothing more:

* Can you clarify why you needed to write your own data source or transaction manager? I've successfully used Arquillian for many years now in multiple large projects and have never had to do anything of the sort.

* Can you clarify what you mean by dependencies on the Java EE side? The only one you should really need is the Java EE interface jar?

* Arquillian and Spring Testing have different trade-offs - neither necessary categorically better or worse. Interestingly enough I discussed placing the entire class-path automatically into the test with the Arquillian team from the start since I came from a Spring Testing background. Their rationale for not going that route is that it gets away from proper testing isolation and leads to slower test deployment times. The downsides as you mention is the fact that you need to explicitly list out the components under test. What I've personally found over time is that this is fine as long as you are writing tests along with components. It's harder if you are putting in tests much later or trying to test someone else's code. From an Arquillian perspective, most Java EE developers these days seem to find Spring Testing comparatively feature poor. It's not hard to see why even by briefly looking at the Arquillian docs: https://docs.jboss.org/author/display/ARQ/Reference+Guide.

I think Siva is exactly correct. We are at a point now where the differences between Spring and Java EE are relatively minor from a functional standpoint and largely now in the realm of personal taste.

Just a few quick facts for completeness (for the unaware), a desire a get a bit more clarity and nothing more:

* Can you clarify why you needed to write your own data source or transaction manager? I've successfully used Arquillian for many years now in multiple large projects and have never had to do anything of the sort.

* Can you clarify what you mean by dependencies on the Java EE side? The only one you should really need is the Java EE interface jar?

* Arquillian and Spring Testing have different trade-offs - neither necessary categorically better or worse. Interestingly enough I discussed placing the entire class-path automatically into the test with the Arquillian team from the start since I came from a Spring Testing background. Their rationale for not going that route is that it gets away from proper testing isolation and leads to slower test deployment times. The downsides as you mention is the fact that you need to explicitly list out the components under test. What I've personally found over time is that this is fine as long as you are writing tests along with components. It's harder if you are putting in tests much later or trying to test someone else's code. From an Arquillian perspective, most Java EE developers these days seem to find Spring Testing comparatively feature poor. It's not hard to see why even by briefly looking at the Arquillian docs: https://docs.jboss.org/author/display/ARQ/Reference+Guide.

I think Siva is exactly correct. We are at a point now where the differences between Spring and Java EE are relatively minor from a functional standpoint and largely now in the realm of personal taste.

Just a few quick facts for completeness (for the unaware), a desire a get a bit more clarity and nothing more:

* Can you clarify why you needed to write your own data source or transaction manager? I've successfully used Arquillian for many years now in multiple large projects and have never had to do anything of the sort.

* Can you clarify what you mean by dependencies on the Java EE side? The only one you should really need is the Java EE interface jar?

* Arquillian and Spring Testing have different trade-offs - neither necessary categorically better or worse. Interestingly enough I discussed placing the entire class-path automatically into the test with the Arquillian team from the start since I came from a Spring Testing background. Their rationale for not going that route is that it gets away from proper testing isolation and leads to slower test deployment times. The downsides as you mention is the fact that you need to explicitly list out the components under test. What I've personally found over time is that this is fine as long as you are writing tests along with components. It's harder if you are putting in tests much later or trying to test someone else's code. From an Arquillian perspective, most Java EE developers these days seem to find Spring Testing comparatively feature poor. It's not hard to see why even by briefly looking at the Arquillian docs: https://docs.jboss.org/author/display/ARQ/Reference+Guide.

I think Siva is exactly correct. We are at a point now where the differences between Spring and Java EE are relatively minor from a functional standpoint and largely now in the realm of personal taste.

Just a few quick facts for completeness (for the unaware) and nothing more:

* By quick start if you mean help with automated project/build setup in the Java EE world you may use Forge. If you mean the fat jars, there are multiple solutions like WildFly Swarm, Payara Micro and KumuluzEE (that you can use with Forge).

* The DeltaSpike Query module is a direct counterpart of Spring Data in the Java EE realm. There are other options like NetBeans DAO generators as well.

* It is true JRebel is not free, but most Java EE application servers in fact do come with hot deployment these days. I personally find JRebel unnecessary. It's true hot deployment tends to break after about fifty deploys or so but then it's just a matter of doing a fresh deploy which takes just seconds in most modern Java EE servers and skinny Java EE wars with much fewer dependencies.

* It has long been possible to use action-oriented frameworks like VRaptor that support CDI with Java EE. That being said we are adding an action oriented framework as an option in Java EE 8 because enough folks wanted it. Here is a write-up on it including some trace-offs: https://blogs.oracle.com/theaquarium/entry/why_another_mvc_framework_in.

Just a few quick facts for completeness (for the unaware) and nothing more:

* By quick start if you mean help with automated project/build setup in the Java EE world you may use Forge. If you mean the fat jars, there are multiple solutions like WildFly Swarm, Payara Micro and KumuluzEE (that you can use with Forge).

* The DeltaSpike Query module is a direct counterpart of Spring Data in the Java EE realm. There are other options like NetBeans DAO generators as well.

* It is true JRebel is not free, but most Java EE application servers in fact do come with hot deployment these days. I personally find JRebel unnecessary. It's true hot deployment tends to break after about fifty deploys or so but then it's just a matter of doing a fresh deploy which takes just seconds in most modern Java EE servers and skinny Java EE wars with much fewer dependencies.

* It has long been possible to use action-oriented frameworks like VRaptor that support CDI with Java EE. That being said we are adding an action oriented framework as an option in Java EE 8 because enough folks wanted it. Here is a write-up on it including some trace-offs: https://blogs.oracle.com/theaquarium/entry/why_another_mvc_framework_in.

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

Comments on the stuff I could clearly make out (let me know if I missed anything):

* One more thing to understand about Java EE is that we are the opposite of Spring and .NET when it comes to adding features. We try very hard to understand what the likely common case is, make that case as easy as possible and avoid anything that looks like it might be feature bloat. In the end what we get is simplicity and minimalism in every aspect of the core Java EE development experience. This isn't an accident. It's what our (growing) core community clearly values. What this means is that for requirements that are outside the common case, we rely on extensions to Java EE such as DeltaSpike. To the uninitiated, think of it as KISS - keeping simple things very simple while still keeping the more exotic possible. Another important upshot of this is that the core of your application always remains largely vendor neutral while still meeting most if not all requirements.

* I actually know Boot quite well and frankly Swarm not so well by comparison :-). Firstly, the reason Swarm does not do implementation pluggability is the same reason Java EE overall avoids it. It adds a lot of risk in terms of being able to support a stable, well understood runtime. Adding just one layer of pluggability significantly degrades what you can guarantee to your mission critical users. Because Swarm is just Java EE in the end, you can in fact create a fat jar or a war from your basic (let's say Maven) project structure by just swapping out Swarm for (let's say) WildFly. Your last comments basically along the lines of Swarm usability is legitimate and I am sure the Swarm team could use the feedback. Much like Boot it is still very much a active development project. Also, you may want to check out Payara Micro or KumuluzEE. I believe TomEE too is working on a far jar solution (not sure how far along they are). That's the thing with the Java EE ecosystem to try to appreciate - you always have choices for your largely exact same application if you are unhappy in any way with your current provider.

* Your comment about time is well understood. Frankly I think this is the main reason why Spring is still dominant and will remain that way for some time. They are lucky in that recent history in our industry has allowed them to build up a large mind share. My task is to gradually chip away at that mind share :-).

With regards to extensibility, configuration and integration with third party components, the Java EE answer as of EE 6 has been CDI and it's ecosystem (and that it quite a deliberate direction). A good place to start exploring is the ever evolving/expanding CDI ecosystem page: https://blogs.oracle.com/theaquarium/entry/a_directory_for_cdi_plugins - specifically project DeltaSpike and of course my own blog entries. If you are to truly understand the Java EE ecosystem what you'll quickly realize is that it is not as much of a centralized one-stop-shop as the Spring or the .NET world is. There are likely solutions to most realistic problems, but you will no doubt need to do some Googling around and reading :-). Again though that CDI ecosystem page is a good start.

With regards to Camel's support for CDI and Java EE other than Markus' great talk another good place to start is his blog: http://blog.eisele.net/2014/08/bootstrapping-apache-camel-in-java-ee7.html. Camel now being very close to the JBoss ecosystem there's little doubt CDI and Java EE is a first class priority for them :-).

Not entirely sure what you mean with regards to Swarm vs. Boot but I am sure you can tell them what you think is missing. The project is in active development and certainly highly receptive to any input. I suspect they too may direct you to the broader CDI ecosystem.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Please note the update to this article available here: https://blogs.oracle.com/reza/entry/the_ghosts_of_java_ee. The significant change is that IBM announced the release of WebSphere Liberty full Java EE 7 production support by the end of this month.

Mark,

Some hopefully completely respectful comments regarding what I can make out as to specific points in your note:

* I think Bert, et al have made it amply clear all they can reasonably hope to achieve is provide a rough migration guideline and everyone must then chart their own specific course. I believe such content has clear value and demand even though it can never be "perfect".

* WildFly Swarm, Payara Micro and other current and upcoming Java EE centric solutions occupy the same problem domain as Spring Boot. It feels as though I should also point out that most application servers like GlassFish and WebLogic have long provided very robust command-line support.

* Camel indeed provides Java EE integration. Markus Eisele does a nice talk covering the topic you might want to check out?

* I have to admit we don't have much to do with the .NET runtime besides providing interoperability via REST, SOAP etc. For some reason the Microsoft folks don't want to work with us and properly support Java on their runtime :-).

Cheers,

Reza

Mark,

Some hopefully completely respectful comments regarding what I can make out as to specific points in your note:

* I think Bert, et al have made it amply clear all they can reasonably hope to achieve is provide a rough migration guideline and everyone must then chart their own specific course. I believe such content has clear value and demand even though it can never be "perfect".

* WildFly Swarm, Payara Micro and other current and upcoming Java EE centric solutions occupy the same problem domain as Spring Boot. It feels as though I should also point out that most application servers like GlassFish and WebLogic have long provided very robust command-line support.

* Camel indeed provides Java EE integration. Markus Eisele does a nice talk covering the topic you might want to check out?

* I have to admit we don't have much to do with the .NET runtime besides providing interoperability via REST, SOAP etc. For some reason the Microsoft folks don't want to work with us and properly support Java on their runtime :-).

Cheers,

Reza

Mark,

Some hopefully completely respectful comments regarding what I can make out as to specific points in your note:

* I think Bert, et al have made it amply clear all they can reasonably hope to achieve is provide a rough migration guideline and everyone must then chart their own specific course. I believe such content has clear value and demand even though it can never be "perfect".

* WildFly Swarm, Payara Micro and other current and upcoming Java EE centric solutions occupy the same problem domain as Spring Boot. It feels as though I should also point out that most application servers like GlassFish and WebLogic have long provided very robust command-line support.

* Camel indeed provides Java EE integration. Markus Eisele does a nice talk covering the topic you might want to check out?

* I have to admit we don't have much to do with the .NET runtime besides providing interoperability via REST, SOAP etc. For some reason the Microsoft folks don't want to work with us and properly support Java on their runtime :-).

Cheers,

Reza

Mark,

Some hopefully completely respectful comments regarding what I can make out as to specific points in your note:

* I think Bert, et al have made it amply clear all they can reasonably hope to achieve is provide a rough migration guideline and everyone must then chart their own specific course. I believe such content has clear value and demand even though it can never be "perfect".

* WildFly Swarm, Payara Micro and other current and upcoming Java EE centric solutions occupy the same problem domain as Spring Boot. It feels as though I should also point out that most application servers like GlassFish and WebLogic have long provided very robust command-line support.

* Camel indeed provides Java EE integration. Markus Eisele does a nice talk covering the topic you might want to check out?

* I have to admit we don't have much to do with the .NET runtime besides providing interoperability via REST, SOAP etc. For some reason the Microsoft folks don't want to work with us and properly support Java on their runtime :-).

Cheers,

Reza

Of course the issue of using services inside entities is not black and white as I already suggested - there can be legitimate cases where it's needed but I think these are rare personally.

As to reconciling the JPA/CDI life-cycle synchronization issue, it's unfortunately not as simple as saying let CDI manage the life-cycle. That works if the JPA life-cycle matches the CDI life-cycle fairly closely, but not if it doesn't. The only solution that has reasonable credence is making a specialized life cycle common to both CDI and JPA - not a very easy proposition at runtime. It becomes a near impossible problem in the case of entities instantiated using the new operator and then managed by the entity manager as is the case today.

Of course the issue of using services inside entities is not black and white as I already suggested - there can be legitimate cases where it's needed but I think these are rare personally.

As to reconciling the JPA/CDI life-cycle synchronization issue, it's unfortunately not as simple as saying let CDI manage the life-cycle. That works if the JPA life-cycle matches the CDI life-cycle fairly closely, but not if it doesn't. The only solution that has reasonable credence is making a specialized life cycle common to both CDI and JPA - not a very easy proposition at runtime. It becomes a near impossible problem in the case of entities instantiated using the new operator and then managed by the entity manager as is the case today.

Of course the issue of using services inside entities is not black and white as I already suggested - there can be legitimate cases where it's needed but I think these are rare personally.

As to reconciling the JPA/CDI life-cycle synchronization issue, it's unfortunately not as simple as saying let CDI manage the life-cycle. That works if the JPA life-cycle matches the CDI life-cycle fairly closely, but not if it doesn't. The only solution that has reasonable credence is making a specialized life cycle common to both CDI and JPA - not a very easy proposition at runtime. It becomes a near impossible problem in the case of entities instantiated using the new operator and then managed by the entity manager as is the case today.

Of course the issue of using services inside entities is not black and white as I already suggested - there can be legitimate cases where it's needed but I think these are rare personally.

As to reconciling the JPA/CDI life-cycle synchronization issue, it's unfortunately not as simple as saying let CDI manage the life-cycle. That works if the JPA life-cycle matches the CDI life-cycle fairly closely, but not if it doesn't. The only solution that has reasonable credence is making a specialized life cycle common to both CDI and JPA - not a very easy proposition at runtime. It becomes a near impossible problem in the case of entities instantiated using the new operator and then managed by the entity manager as is the case today.

As just noted above, firstly I think accessing a domain service from an entity is somewhat an anti-pattern as well. For a good write-up, you should look here.

Note that I suggested the entity listener injection is a handy workaround, not a perfect solution. It would work if you can express the relevant bits of domain logic as a cross cutting concern that can be tied to the persistence life-cycle events. If that does not work, you can use lookup (aka service locator) or by-pass normal runtime dependency injection in favor of something like AspectJ weaving that works around the difficult problems of synchronizing the persistence manager and dependency injection runtime life-cycles.

In your specific example, you can also pass and store a reference of the domain service to the entity in @PostLoad, but it wouldn't work with entities simply instantiated via the new operator as opposed to retrieved from a query.

As just noted above, firstly I think accessing a domain service from an entity is somewhat an anti-pattern as well. For a good write-up, you should look here.

Note that I suggested the entity listener injection is a handy workaround, not a perfect solution. It would work if you can express the relevant bits of domain logic as a cross cutting concern that can be tied to the persistence life-cycle events. If that does not work, you can use lookup (aka service locator) or by-pass normal runtime dependency injection in favor of something like AspectJ weaving that works around the difficult problems of synchronizing the persistence manager and dependency injection runtime life-cycles.

In your specific example, you can also pass and store a reference of the domain service to the entity in @PostLoad, but it wouldn't work with entities simply instantiated via the new operator as opposed to retrieved from a query.

As just noted above, firstly I think accessing a domain service from an entity is somewhat an anti-pattern as well. For a good write-up, you should look here.

Note that I suggested the entity listener injection is a handy workaround, not a perfect solution. It would work if you can express the relevant bits of domain logic as a cross cutting concern that can be tied to the persistence life-cycle events. If that does not work, you can use lookup (aka service locator) or by-pass normal runtime dependency injection in favor of something like AspectJ weaving that works around the difficult problems of synchronizing the persistence manager and dependency injection runtime life-cycles.

In your specific example, you can also pass and store a reference of the domain service to the entity in @PostLoad, but it wouldn't work with entities simply instantiated via the new operator as opposed to retrieved from a query.

As just noted above, firstly I think accessing a domain service from an entity is somewhat an anti-pattern as well. For a good write-up, you should look here.

Note that I suggested the entity listener injection is a handy workaround, not a perfect solution. It would work if you can express the relevant bits of domain logic as a cross cutting concern that can be tied to the persistence life-cycle events. If that does not work, you can use lookup (aka service locator) or by-pass normal runtime dependency injection in favor of something like AspectJ weaving that works around the difficult problems of synchronizing the persistence manager and dependency injection runtime life-cycles.

In your specific example, you can also pass and store a reference of the domain service to the entity in @PostLoad, but it wouldn't work with entities simply instantiated via the new operator as opposed to retrieved from a query.

Sigh. I really should know better than to respond to inflammatory, poorly written posts on an all but dead thread that doesn't have that many views. That being said some of this appears to be recurring themes that we should perhaps clearly address in separate posts for the Java EE community instead of leaving unanswered and further festering. So perhaps a hearty thanks is in order after all for the additional impetus.

To that end, some thoughts/questions to consider below:

* Interestingly enough, I actually have mapped JPA to legacy databases that do not conform to reasonable domain models and hence are not the core target problem set for ORM. The JPA feature that comes in very handy in this case is native queries. The big advantage of JPA in this case is that it can actually support both the hand-written SQL and ORM generated SQL models in the very same persistence unit. This gives users a great opportunity to gradually re-factor legacy databases to a sane domain model while still using the same domain model.

* You can in fact change fetch strategies at runtime using fetch joins, not to mention entity graphs in JPA 2.1.

* I'm not sure how to put a finer point to this but there's little question JPA and ORM is a practical and long proven approach to data access for a large variety of applications. It's not terribly rational to believe otherwise at this point given exactly how pervasive ORM has been from mission critical TopLink applications that have been around since the nineties, the widespread adoption of Hibernate for more than a decade now to the standardization of JPA. The most easily visible demonstration of this fact is the many sessions on successful JPA usage presented at conferences like JavaOne and Devoxx. For example, in JavaOne 2014 we had JPA sessions from Overstock.com (a more mission critical system than most of us have the good fortune to work on) as well as from credible real world Java experts like Patrycja Wegrzynowicz.

* Can you to be specific as to what EclipseLink bugs you encountered? Have they been filed properly? Since EclipseLink/TopLink is part of our mission critical WebLogic stack, we make sure to fix bugs promptly as issue patches to customers if required. If a user requires further guidance on EclipseLink or JPA we typically provide that too - often for free!

* It's a fallacy that standards must guarantee 100% portability - no known standard does that. What standards do is make it much easier to switch between vendors and implementations. JPA most certainly does that. The most visible demonstration of this fact is that all JPA implementations must pass the exact same set of tests in the Java EE TCK, not to mention benchmarks this one that run the same application against multiple JPA implementations.

* Can you be specific as to what JPA portability issues you have come across? Have they been filed against the JPA spec? Portability is a very important goal and we make sure to address any significant gaps that we know about.

* One large benefit of an open standard is that real world developers beyond vendor do indeed contribute to it (as I did for many years before joining Oracle). Standards are actually far better in this regard than alternatives.

P.S.: If you insist on a hand-written SQL centric free open source tool (sounds like mostly due to your existing SQL skill set more than anything else), MyBatis is certainly a logical choice. I've blogged about it recently here.

Sigh. I really should know better than to respond to inflammatory, poorly written posts on an all but dead thread that doesn't have that many views. That being said some of this appears to be recurring themes that we should perhaps clearly address in separate posts for the Java EE community instead of leaving unanswered and further festering. So perhaps a hearty thanks is in order after all for the additional impetus.

To that end, some thoughts/questions to consider below:

* Interestingly enough, I actually have mapped JPA to legacy databases that do not conform to reasonable domain models and hence are not the core target problem set for ORM. The JPA feature that comes in very handy in this case is native queries. The big advantage of JPA in this case is that it can actually support both the hand-written SQL and ORM generated SQL models in the very same persistence unit. This gives users a great opportunity to gradually re-factor legacy databases to a sane domain model while still using the same domain model.

* You can in fact change fetch strategies at runtime using fetch joins, not to mention entity graphs in JPA 2.1.

* I'm not sure how to put a finer point to this but there's little question JPA and ORM is a practical and long proven approach to data access for a large variety of applications. It's not terribly rational to believe otherwise at this point given exactly how pervasive ORM has been from mission critical TopLink applications that have been around since the nineties, the widespread adoption of Hibernate for more than a decade now to the standardization of JPA. The most easily visible demonstration of this fact is the many sessions on successful JPA usage presented at conferences like JavaOne and Devoxx. For example, in JavaOne 2014 we had JPA sessions from Overstock.com (a more mission critical system than most of us have the good fortune to work on) as well as from credible real world Java experts like Patrycja Wegrzynowicz.

* Can you to be specific as to what EclipseLink bugs you encountered? Have they been filed properly? Since EclipseLink/TopLink is part of our mission critical WebLogic stack, we make sure to fix bugs promptly as issue patches to customers if required. If a user requires further guidance on EclipseLink or JPA we typically provide that too - often for free!

* It's a fallacy that standards must guarantee 100% portability - no known standard does that. What standards do is make it much easier to switch between vendors and implementations. JPA most certainly does that. The most visible demonstration of this fact is that all JPA implementations must pass the exact same set of tests in the Java EE TCK, not to mention benchmarks this one that run the same application against multiple JPA implementations.

* Can you be specific as to what JPA portability issues you have come across? Have they been filed against the JPA spec? Portability is a very important goal and we make sure to address any significant gaps that we know about.

* One large benefit of an open standard is that real world developers beyond vendor do indeed contribute to it (as I did for many years before joining Oracle). Standards are actually far better in this regard than alternatives.

P.S.: If you insist on a hand-written SQL centric free open source tool (sounds like mostly due to your existing SQL skill set more than anything else), MyBatis is certainly a logical choice. I've blogged about it recently here.

Sigh. I really should know better than to respond to inflammatory, poorly written posts on an all but dead thread that doesn't have that many views. That being said some of this appears to be recurring themes that we should perhaps clearly address in separate posts for the Java EE community instead of leaving unanswered and further festering. So perhaps a hearty thanks is in order after all for the additional impetus.

To that end, some thoughts/questions to consider below:

* Interestingly enough, I actually have mapped JPA to legacy databases that do not conform to reasonable domain models and hence are not the core target problem set for ORM. The JPA feature that comes in very handy in this case is native queries. The big advantage of JPA in this case is that it can actually support both the hand-written SQL and ORM generated SQL models in the very same persistence unit. This gives users a great opportunity to gradually re-factor legacy databases to a sane domain model while still using the same domain model.

* You can in fact change fetch strategies at runtime using fetch joins, not to mention entity graphs in JPA 2.1.

* I'm not sure how to put a finer point to this but there's little question JPA and ORM is a practical and long proven approach to data access for a large variety of applications. It's not terribly rational to believe otherwise at this point given exactly how pervasive ORM has been from mission critical TopLink applications that have been around since the nineties, the widespread adoption of Hibernate for more than a decade now to the standardization of JPA. The most easily visible demonstration of this fact is the many sessions on successful JPA usage presented at conferences like JavaOne and Devoxx. For example, in JavaOne 2014 we had JPA sessions from Overstock.com (a more mission critical system than most of us have the good fortune to work on) as well as from credible real world Java experts like Patrycja Wegrzynowicz.

* Can you to be specific as to what EclipseLink bugs you encountered? Have they been filed properly? Since EclipseLink/TopLink is part of our mission critical WebLogic stack, we make sure to fix bugs promptly as issue patches to customers if required. If a user requires further guidance on EclipseLink or JPA we typically provide that too - often for free!

* It's a fallacy that standards must guarantee 100% portability - no known standard does that. What standards do is make it much easier to switch between vendors and implementations. JPA most certainly does that. The most visible demonstration of this fact is that all JPA implementations must pass the exact same set of tests in the Java EE TCK, not to mention benchmarks this one that run the same application against multiple JPA implementations.

* Can you be specific as to what JPA portability issues you have come across? Have they been filed against the JPA spec? Portability is a very important goal and we make sure to address any significant gaps that we know about.

* One large benefit of an open standard is that real world developers beyond vendor do indeed contribute to it (as I did for many years before joining Oracle). Standards are actually far better in this regard than alternatives.

P.S.: If you insist on a hand-written SQL centric free open source tool (sounds like mostly due to your existing SQL skill set more than anything else), MyBatis is certainly a logical choice. I've blogged about it recently here.

I am not sure how to put a fine point on this but this looks to me like a series of ideologically driven nits that aren't that particularly practical. Perhaps the best approach to responding to this sort of stuff effectively is to actually write up detailed responses to each point in myth-busters format. I'll try to see if the JSF community can produce that in the near future.

Cool - hopefully that's impetus for the other folks to add similar support.

Cool - hopefully that's impetus for the other folks to add similar support.

Totally understood and appreciated. Clearly there are ways of discussing highly subjective technical material that are less confrontational/professional/personal than others.

Totally understood and appreciated. Clearly there are ways of discussing highly subjective technical material that are less confrontational/professional/personal than others.

Ugh. Feels like I should try to cool down, de-personalize and de-escalate this discussion a bit...

From a JCP, Java, Java EE standpoint it's never a goal to try to squash innovation outside the standard or suggest that using the standard is always the only way to go. In fact it may make perfect sense for many good reasons to use JOOQ with (or without) Java EE and not opt for JPA. This decision frankly is up to the end user (like Yannick) and it's probably best not to be too heavy handed in pushing ones' own view on end users (standard or otherwise). Now, I am not sure if JOOQ can even be used with CDI/Java EE, but there are certainly similar solutions that can be: http://mybatis.github.io/cdi/. It is a valid point that innovation outside the standard is essential for the health of the overall ecosystem for the reasons mentioned in the article (e.g. EJB 2 Entity Beans vs. JDO vs. TopLink vs. Hibernate).

There are unfortunately a few points that I think are worth mentioning here though (that I hope is not worth dragging on/quibbling about):

* Open Source software can certainly be forked and closed source software can be cloned. The reality though is that these are relatively weak forms of avoiding vendor/implementation lock-in from the standpoint of the average user. These risks are without much doubt significantly lower with an open standard that has multiple good, readily available implementations as is the case with JPA.

* There are in fact many folks that use EclipseLink that have nothing to do with TopLink. Folks migrate from Hibernate to EclipseLink and vise-versa all for good reasons. That is the customer choice that open standards like JPA enable.

* It's really quite wrong to imply that the JCP is somehow dominated by Oracle interests or Oracle customer interests. There are clear, open, transparent checks and balances to ensure that all valid viewpoints are given equal weight in the JCP. In fact, the best way to ensure transparency is through greater grassroots level independent developer involvement - which we strive our best to promote and facilitate.

* It's important to remember that JPA does indeed allow users to be quite SQL centric via Native Queries and Stored Procedures if that it what is desired for a given use case or application.

Ugh. Feels like I should try to cool down, de-personalize and de-escalate this discussion a bit...

From a JCP, Java, Java EE standpoint it's never a goal to try to squash innovation outside the standard or suggest that using the standard is always the only way to go. In fact it may make perfect sense for many good reasons to use JOOQ with (or without) Java EE and not opt for JPA. This decision frankly is up to the end user (like Yannick) and it's probably best not to be too heavy handed in pushing ones' own view on end users (standard or otherwise). Now, I am not sure if JOOQ can even be used with CDI/Java EE, but there are certainly similar solutions that can be: http://mybatis.github.io/cdi/. It is a valid point that innovation outside the standard is essential for the health of the overall ecosystem for the reasons mentioned in the article (e.g. EJB 2 Entity Beans vs. JDO vs. TopLink vs. Hibernate).

There are unfortunately a few points that I think are worth mentioning here though (that I hope is not worth dragging on/quibbling about):

* Open Source software can certainly be forked and closed source software can be cloned. The reality though is that these are relatively weak forms of avoiding vendor/implementation lock-in from the standpoint of the average user. These risks are without much doubt significantly lower with an open standard that has multiple good, readily available implementations as is the case with JPA.

* There are in fact many folks that use EclipseLink that have nothing to do with TopLink. Folks migrate from Hibernate to EclipseLink and vise-versa all for good reasons. That is the customer choice that open standards like JPA enable.

* It's really quite wrong to imply that the JCP is somehow dominated by Oracle interests or Oracle customer interests. There are clear, open, transparent checks and balances to ensure that all valid viewpoints are given equal weight in the JCP. In fact, the best way to ensure transparency is through greater grassroots level independent developer involvement - which we strive our best to promote and facilitate.

* It's important to remember that JPA does indeed allow users to be quite SQL centric via Native Queries and Stored Procedures if that it what is desired for a given use case or application.

Ugh. Feels like I should try to cool down, de-personalize and de-escalate this discussion a bit...

From a JCP, Java, Java EE standpoint it's never a goal to try to squash innovation outside the standard or suggest that using the standard is always the only way to go. In fact it may make perfect sense for many good reasons to use JOOQ with (or without) Java EE and not opt for JPA. This decision frankly is up to the end user (like Yannick) and it's probably best not to be too heavy handed in pushing ones' own view on end users (standard or otherwise). Now, I am not sure if JOOQ can even be used with CDI/Java EE, but there are certainly similar solutions that can be: http://mybatis.github.io/cdi/. It is a valid point that innovation outside the standard is essential for the health of the overall ecosystem for the reasons mentioned in the article (e.g. EJB 2 Entity Beans vs. JDO vs. TopLink vs. Hibernate).

There are unfortunately a few points that I think are worth mentioning here though (that I hope is not worth dragging on/quibbling about):

* Open Source software can certainly be forked and closed source software can be cloned. The reality though is that these are relatively weak forms of avoiding vendor/implementation lock-in from the standpoint of the average user. These risks are without much doubt significantly lower with an open standard that has multiple good, readily available implementations as is the case with JPA.

* There are in fact many folks that use EclipseLink that have nothing to do with TopLink. Folks migrate from Hibernate to EclipseLink and vise-versa all for good reasons. That is the customer choice that open standards like JPA enable.

* It's really quite wrong to imply that the JCP is somehow dominated by Oracle interests or Oracle customer interests. There are clear, open, transparent checks and balances to ensure that all valid viewpoints are given equal weight in the JCP. In fact, the best way to ensure transparency is through greater grassroots level independent developer involvement - which we strive our best to promote and facilitate.

* It's important to remember that JPA does indeed allow users to be quite SQL centric via Native Queries and Stored Procedures if that it what is desired for a given use case or application.

With all due respect the fact is that with every release of Java EE, there have been numerous ideas that have been adopted into competing solutions, let alone outright APIs altogether. Java EE 7 is already no exception. While the core goal of Java EE is standardizing well understood cases and staying away from hype-ware, innovation happens anyway as an organic, natural process inherent in any engineering endeavor.

Truth be told, other than some NIH fueled chest beating, this line of thinking doesn't really matter that much to the average user anyway. What matters is whether business needs are met in a productive fashion. I think it's hard to objectively argue that Java EE and it's ecosystem does not do that especially as of Java EE 6.

With all due respect the fact is that with every release of Java EE, there have been numerous ideas that have been adopted into competing solutions, let alone outright APIs altogether. Java EE 7 is already no exception. While the core goal of Java EE is standardizing well understood cases and staying away from hype-ware, innovation happens anyway as an organic, natural process inherent in any engineering endeavor.

Truth be told, other than some NIH fueled chest beating, this line of thinking doesn't really matter that much to the average user anyway. What matters is whether business needs are met in a productive fashion. I think it's hard to objectively argue that Java EE and it's ecosystem does not do that especially as of Java EE 6.

Both are my accounts - one older than the other. And I totally agree with you. There's a bit of material out there on CDI/Spring integration/migration but not nearly enough for folks that want/need the material.

Both are my accounts - one older than the other. And I totally agree with you. There's a bit of material out there on CDI/Spring integration/migration but not nearly enough for folks that want/need the material.

Firstly, you can in fact use different versions of Java EE APIs in the same application because of the backwards compatibility guarantees in Java EE. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by simply specifying the version number. In reality, there is no real reason to have this degree of customization and thus it is rarely ever done in Java EE applications, which is why you probably don't know about it. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications without much testing against the new runtime.

Whether or not you use one or more applications on a server, using a pre-configured runtime will always save time/effort, be better supported and be safer instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some die-hard parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus mostly on their own application code. If you claim needing to customize your runtime is such a big deal, can you really objectively explain why it's not a big deal to the users of these widely used runtimes besides Spring?

I believe Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code on a pre-loaded runtime. That's a perfectly valid and indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this observation is that closely integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that a framework like Spring simply can't do.

The reason we will never make Servlet == Java EE is that one of the primary goals of Java EE is to promote a well-understood, common, compatible runtime that everyone can depend on and applications should be able to be easily ported between vendors with minimum configuration effort. In reality, this is hardly a problem if you look at fully compliant application servers like GlassFish, WildFly, TomEE, WebSphere Liberty or the latest versions of WebLogic that basically have the same developer experience as plain servlet containers.

Lastly, the objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable/reliable fork. To make matters worse for users, historically forks are never compatible unless backed by a strong standard. By comparison switching between readily available fully standards backed, compatible implementations is far more practical for most people.

Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

Anyway it sounds like you need to read up a bit on LSB: the compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

Firstly, you can in fact use different versions of Java EE APIs in the same application because of the backwards compatibility guarantees in Java EE. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by simply specifying the version number. In reality, there is no real reason to have this degree of customization and thus it is rarely ever done in Java EE applications, which is why you probably don't know about it. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications without much testing against the new runtime.

Whether or not you use one or more applications on a server, using a pre-configured runtime will always save time/effort, be better supported and be safer instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some die-hard parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus mostly on their own application code. If you claim needing to customize your runtime is such a big deal, can you really objectively explain why it's not a big deal to the users of these widely used runtimes besides Spring?

I believe Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code on a pre-loaded runtime. That's a perfectly valid and indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this observation is that closely integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that a framework like Spring simply can't do.

The reason we will never make Servlet == Java EE is that one of the primary goals of Java EE is to promote a well-understood, common, compatible runtime that everyone can depend on and applications should be able to be easily ported between vendors with minimum configuration effort. In reality, this is hardly a problem if you look at fully compliant application servers like GlassFish, WildFly, TomEE, WebSphere Liberty or the latest versions of WebLogic that basically have the same developer experience as plain servlet containers.

Lastly, the objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable/reliable fork. To make matters worse for users, historically forks are never compatible unless backed by a strong standard. By comparison switching between readily available fully standards backed, compatible implementations is far more practical for most people.

Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

Anyway it sounds like you need to read up a bit on LSB: the compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

Firstly, you can in fact use different versions of Java EE APIs in the same application because of the backwards compatibility guarantees in Java EE. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by simply specifying the version number. In reality, there is no real reason to have this degree of customization and thus it is rarely ever done in Java EE applications, which is why you probably don't know about it. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications without much testing against the new runtime.

Whether or not you use one or more applications on a server, using a pre-configured runtime will always save time/effort, be better supported and be safer instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some die-hard parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus mostly on their own application code. If you claim needing to customize your runtime is such a big deal, can you really objectively explain why it's not a big deal to the users of these widely used runtimes besides Spring?

I believe Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code on a pre-loaded runtime. That's a perfectly valid and indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this observation is that closely integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that a framework like Spring simply can't do.

The reason we will never make Servlet == Java EE is that one of the primary goals of Java EE is to promote a well-understood, common, compatible runtime that everyone can depend on and applications should be able to be easily ported between vendors with minimum configuration effort. In reality, this is hardly a problem if you look at fully compliant application servers like GlassFish, WildFly, TomEE, WebSphere Liberty or the latest versions of WebLogic that basically have the same developer experience as plain servlet containers.

Lastly, the objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable/reliable fork. To make matters worse for users, historically forks are never compatible unless backed by a strong standard. By comparison switching between readily available fully standards backed, compatible implementations is far more practical for most people.

Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

Anyway it sounds like you need to read up a bit on LSB: the compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

Firstly, you can in fact use different versions of Java EE APIs in the same application because of the backwards compatibility guarantees in Java EE. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by simply specifying the version number. In reality, there is no real reason to have this degree of customization and thus it is rarely ever done in Java EE applications, which is why you probably don't know about it. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications without much testing against the new runtime.

Whether or not you use one or more applications on a server, using a pre-configured runtime will always save time/effort, be better supported and be safer instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some die-hard parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus mostly on their own application code. If you claim needing to customize your runtime is such a big deal, can you really objectively explain why it's not a big deal to the users of these widely used runtimes besides Spring?

I believe Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code on a pre-loaded runtime. That's a perfectly valid and indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this observation is that closely integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that a framework like Spring simply can't do.

The reason we will never make Servlet == Java EE is that one of the primary goals of Java EE is to promote a well-understood, common, compatible runtime that everyone can depend on and applications should be able to be easily ported between vendors with minimum configuration effort. In reality, this is hardly a problem if you look at fully compliant application servers like GlassFish, WildFly, TomEE, WebSphere Liberty or the latest versions of WebLogic that basically have the same developer experience as plain servlet containers.

Lastly, the objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable/reliable fork. To make matters worse for users, historically forks are never compatible unless backed by a strong standard. By comparison switching between readily available fully standards backed, compatible implementations is far more practical for most people.

Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

Anyway it sounds like you need to read up a bit on LSB: the compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

Firstly, you can in fact use different versions of Java EE APIs in the same application because of the backwards compatibility guarantees in Java EE. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by simply specifying the version number. In reality, there is no real reason to have this degree of customization and thus it is rarely ever done in Java EE applications, which is why you probably don't know about it. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications without much testing against the new runtime.

Whether or not you use one or more applications on a server, using a pre-configured runtime will always save time/effort, be better supported and be safer instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some die-hard parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus mostly on their own application code. If you claim needing to customize your runtime is such a big deal, can you really objectively explain why it's not a big deal to the users of these widely used runtimes besides Spring?

I believe Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code on a pre-loaded runtime. That's a perfectly valid and indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this observation is that closely integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that a framework like Spring simply can't do.

The reason we will never make Servlet == Java EE is that one of the primary goals of Java EE is to promote a well-understood, common, compatible runtime that everyone can depend on and applications should be able to be easily ported between vendors with minimum configuration effort. In reality, this is hardly a problem if you look at fully compliant application servers like GlassFish, WildFly, TomEE, WebSphere Liberty or the latest versions of WebLogic that basically have the same developer experience as plain servlet containers.

Lastly, the objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable/reliable fork. To make matters worse for users, historically forks are never compatible unless backed by a strong standard. By comparison switching between readily available fully standards backed, compatible implementations is far more practical for most people.

Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

Anyway it sounds like you need to read up a bit on LSB: the compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

Firstly, you can in fact use different versions of Java EE APIs in the same application because of the backwards compatibility guarantees in Java EE. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by simply specifying the version number. In reality, there is no real reason to have this degree of customization and thus it is rarely ever done in Java EE applications, which is why you probably don't know about it. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications without much testing against the new runtime.

Whether or not you use one or more applications on a server, using a pre-configured runtime will always save time/effort, be better supported and be safer instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some die-hard parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus mostly on their own application code. If you claim needing to customize your runtime is such a big deal, can you really objectively explain why it's not a big deal to the users of these widely used runtimes besides Spring?

I believe Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code on a pre-loaded runtime. That's a perfectly valid and indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this observation is that closely integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that a framework like Spring simply can't do.

The reason we will never make Servlet == Java EE is that one of the primary goals of Java EE is to promote a well-understood, common, compatible runtime that everyone can depend on and applications should be able to be easily ported between vendors with minimum configuration effort. In reality, this is hardly a problem if you look at fully compliant application servers like GlassFish, WildFly, TomEE, WebSphere Liberty or the latest versions of WebLogic that basically have the same developer experience as plain servlet containers.

Lastly, the objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable/reliable fork. To make matters worse for users, historically forks are never compatible unless backed by a strong standard. By comparison switching between readily available fully standards backed, compatible implementations is far more practical for most people.

Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

Anyway it sounds like you need to read up a bit on LSB: the compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

Firstly, you can in fact use different versions of Java EE APIs in the same application because of the backwards compatibility guarantees in Java EE. For example, you can use CDI 1.0 or JPA 2.0 in a Java EE 7 application by simply specifying the version number. In reality, there is no real reason to have this degree of customization and thus it is rarely ever done in Java EE applications, which is why you probably don't know about it. As I mentioned, WebLogic goes as far letting you explicitly set an implementation version for running older applications without much testing against the new runtime.

Whether or not you use one or more applications on a server, using a pre-configured runtime will always save time/effort, be better supported and be safer instead of trying to build and configure your own runtime. Again, it's like using a pre-configured Linux distribution versus trying to build your own. That being said, your viewpoint does not surprise me much. Spending time building and configuring runtimes seems to be a peculiar obsession with some die-hard parts of the Spring community while users of integrated platforms like Java EE, .NET, Rails and Play! seem to largely take their runtime configuration for granted and focus mostly on their own application code. If you claim needing to customize your runtime is such a big deal, can you really objectively explain why it's not a big deal to the users of these widely used runtimes besides Spring?

I believe Arun's point was that it will always bloat/complicate/slow-down deployments to try to load your runtime with your application as opposed to loading just your application code on a pre-loaded runtime. That's a perfectly valid and indisputable technical point. It's a key observation made by someone that recently ported the Spring Pet Clinic to Java EE: http://thomas-woehlke.blogspot.com/2014/02/java-ee-7-petclinic.html. The other indisputable reason for this observation is that closely integrated runtimes can heavily optimize application loading using techniques like sharing class path scanning metadata that a framework like Spring simply can't do.

The reason we will never make Servlet == Java EE is that one of the primary goals of Java EE is to promote a well-understood, common, compatible runtime that everyone can depend on and applications should be able to be easily ported between vendors with minimum configuration effort. In reality, this is hardly a problem if you look at fully compliant application servers like GlassFish, WildFly, TomEE, WebSphere Liberty or the latest versions of WebLogic that basically have the same developer experience as plain servlet containers.

Lastly, the objective reality is that Open Source alone is a very weak guarantee against vendor and implementation lock-in. The problem is that to escape from a vendor/implementation you must either maintain third-party code yourself or rely on someone else to maintain a sustainable/reliable fork. To make matters worse for users, historically forks are never compatible unless backed by a strong standard. By comparison switching between readily available fully standards backed, compatible implementations is far more practical for most people.

Your Linux kernel example is actually great. The reality is that Linux/UNIX distributions are not relatively portable just because they are open source, they are compatible because of standards like POSIX and Linux Standard Base (LSB) - so even there standards are protecting your interests, in your case apparently without your knowledge! Even then frankly Linux distributions are very hard to port between because LSB is still very immature (thankfully POSIX is not). In reality Java/EE, SQL, TCP/IP, HTTP, etc comes to the rescue in not locking server applications too tightly to potentially incompatible OS runtimes.

Anyway it sounds like you need to read up a bit on LSB: the compatibility/lock-in risks in Linux are actually well understood, widely acknowledged and very likely fixed more effectively in the near future: http://en.wikibooks.org/wiki/FOSS_Open_Standards/The_Linux_Standard_Base.

I think beyond being off-topic and redundant, this has now also devolved to petty bickering. Be it SQL, HTML, Java, Java EE, Spring or .NET, no mainstream technology, standard or product has any precedent of not taking backwards compatibility very seriously. This is not an accident: hundreds of thousands if not millions of real paying customers not just prefer it, but demand it as a hard requirement. Java and Java EE will be the last not to take backwards compatibility very seriously and most certainly not the first. A few random pseudo anonymous comments on internet forums has no hope of changing that unless the hard evidence is overwhelming.

I think beyond being off-topic and redundant, this has now also devolved to petty bickering. Be it SQL, HTML, Java, Java EE, Spring or .NET, no mainstream technology, standard or product has any precedent of not taking backwards compatibility very seriously. This is not an accident: hundreds of thousands if not millions of real paying customers not just prefer it, but demand it as a hard requirement. Java and Java EE will be the last not to take backwards compatibility very seriously and most certainly not the first. A few random pseudo anonymous comments on internet forums has no hope of changing that unless the hard evidence is overwhelming.

The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment. It may be that you have a very unique and unfortunate operational situation. In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

Not that it matters that much, but both of the cases I referenced above are actually driven by application owners with long term investments, not to mention the numerous other case studies at JavaOne over the years. BTW, most consultants do actually maintain long term relationships with their clients - my average is actually about five years :-). Otherwise, you really don't last long as a consultant :-). Again, Adam is an awesome example.

The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment. It may be that you have a very unique and unfortunate operational situation. In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

Not that it matters that much, but both of the cases I referenced above are actually driven by application owners with long term investments, not to mention the numerous other case studies at JavaOne over the years. BTW, most consultants do actually maintain long term relationships with their clients - my average is actually about five years :-). Otherwise, you really don't last long as a consultant :-). Again, Adam is an awesome example.

The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment. It may be that you have a very unique and unfortunate operational situation. In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

Not that it matters that much, but both of the cases I referenced above are actually driven by application owners with long term investments, not to mention the numerous other case studies at JavaOne over the years. BTW, most consultants do actually maintain long term relationships with their clients - my average is actually about five years :-). Otherwise, you really don't last long as a consultant :-). Again, Adam is an awesome example.

The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment. It may be that you have a very unique and unfortunate operational situation. In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

Not that it matters that much, but both of the cases I referenced above are actually driven by application owners with long term investments, not to mention the numerous other case studies at JavaOne over the years. BTW, most consultants do actually maintain long term relationships with their clients - my average is actually about five years :-). Otherwise, you really don't last long as a consultant :-). Again, Adam is an awesome example.

The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment. It may be that you have a very unique and unfortunate operational situation. In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

Not that it matters that much, but both of the cases I referenced above are actually driven by application owners with long term investments, not to mention the numerous other case studies at JavaOne over the years. BTW, most consultants do actually maintain long term relationships with their clients - my average is actually about five years :-). Otherwise, you really don't last long as a consultant :-). Again, Adam is an awesome example.

The reality in our vast customer base and my own decades long real world experience is that most customers have multiple versions of application servers often from multiple vendors in their environment. It may be that you have a very unique and unfortunate operational situation. In fact, most customers these days are moving into the runtime-per app model instead of the one runtime for all applications model, for great reasons.

Not that it matters that much, but both of the cases I referenced above are actually driven by application owners with long term investments, not to mention the numerous other case studies at JavaOne over the years. BTW, most consultants do actually maintain long term relationships with their clients - my average is actually about five years :-). Otherwise, you really don't last long as a consultant :-). Again, Adam is an awesome example.

Java EE does indeed allow this. Most application server vendors do in fact routinely update components (again just like Linux distributions), just look at the GlassFish update center facility or the WebLogic patch utility. It's also the case that applications rarely change their core dependencies in the short term instead of focusing on implementing business needs as you suggest. After all, any such change usually requires extensive testing of mission critical applications, whatever technology you are using.

Java EE does indeed allow this. Most application server vendors do in fact routinely update components (again just like Linux distributions), just look at the GlassFish update center facility or the WebLogic patch utility. It's also the case that applications rarely change their core dependencies in the short term instead of focusing on implementing business needs as you suggest. After all, any such change usually requires extensive testing of mission critical applications, whatever technology you are using.

Java EE does indeed allow this. Most application server vendors do in fact routinely update components (again just like Linux distributions), just look at the GlassFish update center facility or the WebLogic patch utility. It's also the case that applications rarely change their core dependencies in the short term instead of focusing on implementing business needs as you suggest. After all, any such change usually requires extensive testing of mission critical applications, whatever technology you are using.

Java EE does indeed allow this. Most application server vendors do in fact routinely update components (again just like Linux distributions), just look at the GlassFish update center facility or the WebLogic patch utility. It's also the case that applications rarely change their core dependencies in the short term instead of focusing on implementing business needs as you suggest. After all, any such change usually requires extensive testing of mission critical applications, whatever technology you are using.

Java EE does indeed allow this. Most application server vendors do in fact routinely update components (again just like Linux distributions), just look at the GlassFish update center facility or the WebLogic patch utility. It's also the case that applications rarely change their core dependencies in the short term instead of focusing on implementing business needs as you suggest. After all, any such change usually requires extensive testing of mission critical applications, whatever technology you are using.

It is good the author is fairly clear about the fact that this analysis is something they decided upon as the correct one for their particular team after some debate instead of positioning it as the right decision for everyone. The reality is that such considerations are very much alive, will remain so in the foreseebale future and not everyone will make the same decisions. For example, here are some recent opinions that go in the opposite direction:

• It’s not Spring anymore is the summer of JEE7, ready riding the wave?: http://nmpallas.wordpress.com/2014/03/16/its-not-spring-anymore-is-the-summer-of-jee7-ready-for-riding-the- wave/
• Migrating a JSF-Based Web Application from Spring 3 to Java EE 7 and CDI: https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=3389

In fact, despite not wanting to do so, I had to update my own analysis (that BTW covers the opinions expressed in this analysis as valid choices) on request from customers: http://www.slideshare.net/reza_rahman/java- ee-and-spring-sidebyside-34320697.

A few comments on some specifics of the analysis for perhaps better balance:

• The reality is that there are many happy users of EJB 3 and it is an excellent solution on it's own right. Just take a look at Adam Bien's hugely popular blog (http://www.adam-bien.com/roller/abien/) and some of the comments on them.
• You have many choices for security in Java EE. For example, many of our customers choose WebLogic security for Java EE applications as they find it extensive, powerful and easy to use. That being said, you can also use Apache Shiro or PicketLink if embedded security is desired in Java EE applications.
• The advantages of using the batch runtime that comes with Java EE 7 is that it minimizes configuration/setup, the jobs are managed by the container (e.g. through a properly managed thread pool) and you can manage/monitor the jobs through the container (e.g. the admin console).
• GlassFish is here to stay. In fact, companies outside of Oracle have now stepped up to contribute and support GlassFish. Read a recent fairly balanced opinion on this: http://blog.c2b2.co.uk/2014/06/a-strong-glassfish.html. The Java EE application server market itself is as vibrant as ever. Take a look at the landscape: http://www.slideshare.net/reza_rahman/javaeenext-java-ee-7-8-and-beyond/38. In fact, the Sevlet container choices are very limiting by comparison.
• Simply using and upgrading a pre-integrated runtime is far easier than getting into the business of fine grained dependency management and custom system maintenance. What many of our customers choose to do is simply use a newer runtime for new applications and leave older applications alone or gradually migrate them using WebLogic backwards compatibily features. This is especially easy to do using the cloud. One way of looking at this is bulding and maintaining your own Linux distribution vs. just going with a pre-configured one.

BTW, there are plenty of real world projects using Java EE already - come to JavaOne and hear from just some of those numerous folks yourself, they've been there for years now. If you can't make it, here are just a few success stories: https://blogs.oracle.com/stories/.

BTW, in the interest of full disclosure, I think it's best to mention that you own the company behind the technology you referred to?

Reza Rahman | WebLogic, GlassFish and Java EE Evangelist

All views voiced are my own, not necessarily Oracle's.

No one is saying using NoSQL APIs directly is not a valid option. I've covered these concerns in this talk: http://www.slideshare.net/reza_rahman/using-nosql-with-jpa-eclipselink-and-java-ee.

However, JPA clearly works quite elegantly for a large class of applications - it can work for NoSQL too, which is what these emerging initiatives are all about. JPA has certainly worked well for me personally and many other Java EE adopters quite well for many years now for example.

If you have specific technical concerns around JPA, it is will be good to know what they are so that they can be addressed.

Reza Rahman | WebLogic, GlassFish and Java EE Evangelist

All views voiced are my own, not necessarily Oracle's.

King's Canyon pictures posted here: https://plus.google.com/photos/105337742626157521641/albums/5930208918927703649.

Album posted here: https://plus.google.com/photos/105337742626157521641/albums/5914767591999808593/5914767590213441506?banner=pwa&pid=5914767590213441506&oid=105337742626157521641

Album here: https://plus.google.com/photos/105337742626157521641/albums/5914767591999808593/5914767590213441506?banner=pwa&pid=5914767590213441506&oid=105337742626157521641

Just for clarity here, my DevNexus talk/slide deck covers DataNucleus...

Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.

Just for clarity here, my DevNexus talk/slide deck covers DataNucleus...

Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.

Just for clarity here, my DevNexus talk/slide deck covers DataNucleus...

Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.

The separate API jars are also available via GlassFish. Please check the Maven coordinates referenced in the previous post as well as the existing Java EE 6 jars already published in Maven central repositories.

Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.

The separate API jars are also available via GlassFish. Please check the Maven coordinates referenced in the previous post as well as the existing Java EE 6 jars already published in Maven central repositories.

Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.

The separate API jars are also available via GlassFish. Please check the Maven coordinates referenced in the previous post as well as the existing Java EE 6 jars already published in Maven central repositories.

Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.

There are no plans to update JAXB or JAX-WS that I know of. However, that does not necessarily mean the schema could not be updated if people want it. It's best to let your preference be known directly via the Java EE EG user alias (open to all): http://java.net/projects/javaee-spec/lists/users/. The same is true of the request to add the additional links :-).

All spec project dependencies are put into Maven via the GlassFish project. Here are the early Maven coordinates that are already available: https://blogs.oracle.com/theaquarium/entry/java_ee_7_maven_repository. Beyond that, what's the point of adding just the schemas into Maven? What's the use case? Are there any existing projects that do this? It's certainly not hard to do if there's actually a compelling need.

Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.

The lead for Oracle Security Martin Smith and Doland Smith from the OpenJDK team had a conference call with worlwide JUG leaders. The recordings of the meeting is available here: http://java.net/projects/jugs/downloads/download/Jan24_JUGLeaderCall.mp3. This was a frank two-way discussion with Java community leaders about Java security, bundled software installers, openness, communication and the technical/journalistic quality of recent press coverage in some venues. As Donald and Martin indicate on the call, we can expect this to be the tip of the iceberg of what will be done on the Java Security and communication fronts.

All views voiced are my own, not necessarily Oracle's.

For concerns with bugs and performance, it is very useful to enter JIRA issues on the Mojarra project. Ed and his team are usually on top of Mojarra code quality.

Personally, I have developed fairly significant applications with both Mojarra and MyFaces and can't say there were any siginifacant issues with bugs or performance, so it would be good to know what the particulars in your case where (I'm sure Ed would want to know as well).

All views voiced are my own, not necessarily Oracle's.

For concerns with bugs and performance, it is very useful to enter JIRA issues on the Mojarra project. Ed and his team are usually on top of Mojarra code quality.

Personally, I have developed fairly significant applications with both Mojarra and MyFaces and can't say there were any siginifacant issues with bugs or performance, so it would be good to know what the particulars in your case where (I'm sure Ed would want to know as well).

All views voiced are my own, not necessarily Oracle's.

For concerns with bugs and performance, it is very useful to enter JIRA issues on the Mojarra project. Ed and his team are usually on top of Mojarra code quality.

Personally, I have developed fairly significant applications with both Mojarra and MyFaces and can't say there were any siginifacant issues with bugs or performance, so it would be good to know what the particulars in your case where (I'm sure Ed would want to know as well).

All views voiced are my own, not necessarily Oracle's.

As the results from the survey indicate, I think the reaction in the Java community itself is quite sober, since most Java developers worth their salt know Java has had an excellent security track record for years, compared to say Windows or ActiveX (something I think responsible technologists should point out, as members of the tech press have). Programming language/industry politics aside, here is a pretty good technical analysis of the actual issue: http://timboudreau.com/blog/read/The_Java_Security_Exploit_in_(Mostly)_Plain_English.

As the results from the survey indicate, I think the reaction in the Java community itself is quite sober, since most Java developers worth their salt know Java has had an excellent security track record for years, compared to say Windows or ActiveX (something I think responsible technologists should point out, as members of the tech press have). Programming language/industry politics aside, here is a pretty good technical analysis of the actual issue: http://timboudreau.com/blog/read/The_Java_Security_Exploit_in_(Mostly)_Plain_English.

As the results from the survey indicate, I think the reaction in the Java community itself is quite sober, since most Java developers worth their salt know Java has had an excellent security track record for years, compared to say Windows or ActiveX (something I think responsible technologists should point out, as members of the tech press have). Programming language/industry politics aside, here is a pretty good technical analysis of the actual issue: http://timboudreau.com/blog/read/The_Java_Security_Exploit_in_(Mostly)_Plain_English.

Not sure if you already know this or not, but PrimeFaces makes it a lot easier to work with JQuery, backbone.js and JSF (that's what I did for my most recent JSF project). The new pass-through components in JSF 2.2 should make things easier too. It is however a very fair point that action oriented framework are more JavaScript/HTML5 friendly for the simple fact that they do not manipulate the HTTP request/response cycle as much (and thus offer less of an abstraction but more verbosity/low-level code).

All views voiced are my own, not necessarily Oracle's.

Thanks for the kind words on Java EE 7.

You can of course use frameworks like Struts 2 with CDI on the Java EE stack (as well as Wicket, etc). There is some consideration of adding an action-oriented web framework to Java EE that would be more JavaScript/HTML 5 friendly. It was named JAX-RS MVC and was initially proposed for Java EE 7 but later widthdrawn largely due to time contraints. If there is a compelling need, it could be re-introduced for Java EE 8. In the meanwhile, JSF seems to be doing quite well on it's own right. If there are specific feedback items on JSF, helpful comments are most welcome on the JSF 2.2 spec. I have used JSF extensively myself and certainly prefer it over alternatives (and I have used both Struts and Spring MVC).

We don't actually see much value in Spring Data/JPA (seems like a redundant abstraction over an already pretty streamlined API). However, if others really see value it is easy to create a similar CDI based solution under DeltaSpike. The Java EE answer to DI is of course CDI. As to security, developers have a choice to use their application server's security framework over Java Security/JAAS/JASPIC (such as Resin Security) or a portable CDI based solution like Seam Security.

Hope that helps.

All views voiced are my own, not necessarily Oracle's.

I don't think there is anything wrong with Spring adopting Java EE or Java SE technologies (or have that be the major theme of a given release). Despite the silly, unproductive flame wars, there has always been two way adoption of ideas between Spring and Java EE. In fact SpringSource was a contributor to various Java EE 7 JSRs, most notably Java Batch.

At the end of the day, greater competetion/coexistance is good for the Java community, as long as things are on a fair, healthy basis.

We certainly wish Spring and SpringSource all the best now and in the future...

All views voiced are my own, not necessarily Oracle's.

Thanks for the final verdict of including GlassFish in the winner's list :-).

All views voiced are my own, not necessarily Oracle's.

This could indeed be something valuable for the community if in fact it is fair, unbiased and transparent at all stages.

There's no better way to achieve better transparency than getting people with differing opinions to counter-balance each others viewpoints constructivly and come to a consensus. Given Matt's self-confessed bias againts JSF and component based frameworks in general (http://raibledesigns.com/rd/entry/why_the_bias_against_jsf) one way to achieve better transparency in this effort is adding a recognized expert from the component based framework camp. Either Kito Mann (http://www.linkedin.com/in/kitomann) or David Geary (http://www.nofluffjuststuff.com/conference/speaker/david_geary) come to mind.

This could indeed be something valuable for the community if in fact it is fair, unbiased and transparent at all stages.

There's no better way to achieve better transparency than getting people with differing opinions to counter-balance each others viewpoints constructivly and come to a consensus. Given Matt's self-confessed bias againts JSF and component based frameworks in general (http://raibledesigns.com/rd/entry/why_the_bias_against_jsf) one way to achieve better transparency in this effort is adding a recognized expert from the component based framework camp. Either Kito Mann (http://www.linkedin.com/in/kitomann) or David Geary (http://www.nofluffjuststuff.com/conference/speaker/david_geary) come to mind.

Take a look here: http://weblogs.java.net/blog/fabriziogiudici/archive/2011/08/02/worried-about-java-7-go-hudson-or-jeskins. One of the bugs was filed as low-priority and hence presumably worth the risk since it happens very infrequently. The other two were discovered just a few days before the release. All are assigned high priority now and are getting fixed. The only real question here is whether the most sound judgement call was made under the circumstances.

I do hope the OpenJDK team realizes things have gone too far for them not to present their side of the story themselves soon...

Take a look here: http://weblogs.java.net/blog/fabriziogiudici/archive/2011/08/02/worried-about-java-7-go-hudson-or-jeskins. One of the bugs was filed as low-priority and hence presumably worth the risk since it happens very infrequently. The other two were discovered just a few days before the release. All are assigned high priority now and are getting fixed. The only real question here is whether the most sound judgement call was made under the circumstances.

I do hope the OpenJDK team realizes things have gone too far for them not to present their side of the story themselves soon...

Take a look here: http://weblogs.java.net/blog/fabriziogiudici/archive/2011/08/02/worried-about-java-7-go-hudson-or-jeskins. One of the bugs was filed as low-priority and hence presumably worth the risk since it happens very infrequently. The other two were discovered just a few days before the release. All are assigned high priority now and are getting fixed. The only real question here is whether the most sound judgement call was made under the circumstances.

I do hope the OpenJDK team realizes things have gone too far for them not to present their side of the story themselves soon...

Take a look here: http://weblogs.java.net/blog/fabriziogiudici/archive/2011/08/02/worried-about-java-7-go-hudson-or-jeskins. One of the bugs was filed as low-priority and hence presumably worth the risk since it happens very infrequently. The other two were discovered just a few days before the release. All are assigned high priority now and are getting fixed. The only real question here is whether the most sound judgement call was made under the circumstances.

I do hope the OpenJDK team realizes things have gone too far for them not to present their side of the story themselves soon...

I think the work you are doing is great.

It's similar to something I really wanted to do a long time ago -- implement EJB 3.1 and CDI on top of Spring. Unfortunately, I haven't had time to revisit that with all the things I need to do already. Similarly, it would be easy to write a CDI compatibility layer on top of Google Guice...

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

Henk,

Thanks for your support of Java EE! Interestingly, there is a JavaOne 2011 talk on thisd very topic titled "Best Practices for Migrating Spring Applications to Java EE 6" by Paul Bakker and Bert Ertman from Luminis Technologies. Shold be an interestig talk I am looking forward to hearing.

With Java EE 6, one of the things we are thinking of doing is creating a list of early adoption stories, perhaps in video format hosted on java.net with people talking about why they adopted Java EE and what their experinces with them had been.The Seam team had a similar list of Java EE 5 that was pretty cool: http://seamframework.org/Community/SeamInProduction.

Here are my thoughts on the conclusions drawn in this article:

* I can achieve everything in Java EE 6 using Spring , but not the other way round.

- This is not entirely true, but is mostly true from a purely functional perspective. Even that being said, Java EE and Java EE friendly projects like Seam require less configuration and are more vendor neutral the way I see it. Ever since Seam 2, any Spring projects I have done simply feels less elegant, which is the main driving I have always advocated Java EE. Also, Java cannot and should not standardize every single kitchen sink feature. Features that are not required by 80% of applications should remain in the realm of vendor-specific extensions like Seam 3 and CODI. As far as I can see, Java EE 6 covers the 80% use-case very well.

* I can get Java EE 6 (or 7.x or 8.x ) features in a container that’s doesn’t uses Java EE 6 (or 7.x or 8.x ..) using Spring.

- I don't see this as much of an issue. Firstly, I think the best way to get Java EE 6 features is simply to upgdrade to Java EE 6 :-). Secondly, even if you somehow can't upgrade, you can still use a vast majority of Java EE ecosystem features using pluggable solutions like OpenWebBeans (CDI), OpenEJB (EJB 3.x), Weld (CDI), Seam 3, JSF, JPA 2, Bean Validation, etc - even in Java SE :-).

* I don’t think having a vendor specific extension in Java EE 6 can categorize to all vendor requirements, given that getting anything as part of standard usually takes a very long time. The choice needs to be provided, whether I use pure Hibernate APIs or JPA using a standard way.

- I don't follow this at all - maybe a language issue (not sure if you are a native speaker)? Pluggable extensions like Seam 3 can provide any feature on top of any CDI implementation cleanly. The non-standard features of a product like Hibenate similarly builds cleanly on top of JPA.

* J2EE 5.x and now 6.x Spec is good start, but will take a while for J2EE 6.X (and future versions) to be adopted and catch up with Spring.

- I think Java EE has already more than caught up to Spring :-). The way I see it, it is Spring that has been doing a majority of the "catching up" with Java EE and Seam since around Spring 2.5 :-).

* J2EE future versions should be streamlined further to Java (POJO) with enterprise services, along with a test driven methodology.

- I'm not sure what this means at all. EJB 3.0 and CDI are already 100% POJO and annotations. Embedded containers have been standardized in Java EE to provide excellent TDD support. For Java EE testing support, look at my presentation titled "Testing Java EE 6 Applications: Tools and Techniques" here: http://www.caucho.com/documentation/.

* Finally it’s up to your requirements and what applications you are building.

- Agreed. No one is suggesting that everyone should adopt Java EE 6 as is, just as it is a perfectly fine choice not to use Spring at all :-).

I would say "pure" Java EE is good enough for the vast majority of use cases (that's certainly been my experience even with Java EE 5 projects). Where it is not, you should be looking to extensions and plugins to each Java EE API. CDI plugins play a particularly important role since one of CDI's primary goals was to significantly expand Java EE extensibility. Folks like Dan Allen made that clear long ago: http://java.dzone.com/articles/cdi-extensions-you-can-build.

I look forward to the rest of your posts. I think as a long-time Spring user, you have a bit of a Spring bend, but I do think you are making a real effort to be objective and that's what you need to do in your role for the long and short term best interests of your orgnization and the developers that work there. Besides, people like me are here to keep you honest :-).

If you want to deliberately disregard CDI plugins, your article should clearly mention that as well as a rationale for what your reasoning behind leaving it out is.

I would say "pure" Java EE is good enough for the vast majority of use cases (that's certainly been my experience even with Java EE 5 projects). Where it is not, you should be looking to extensions and plugins to each Java EE API. CDI plugins play a particularly important role since one of CDI's primary goals was to significantly expand Java EE extensibility. Folks like Dan Allen made that clear long ago: http://java.dzone.com/articles/cdi-extensions-you-can-build.

I look forward to the rest of your posts. I think as a long-time Spring user, you have a bit of a Spring bend, but I do think you are making a real effort to be objective and that's what you need to do in your role for the long and short term best interests of your orgnization and the developers that work there. Besides, people like me are here to keep you honest :-).

If you want to deliberately disregard CDI plugins, your article should clearly mention that as well as a rationale for what your reasoning behind leaving it out is.

I think this kind of statement lacks serious perspective.

Let alone the community around the JCP that includes people like Antonio, Adam and Werner each open source Java EE implementation like GlassFish, JBoss, Seam and Resin have their own vibrant communities. For example, here is the list of people involved in the Java EE 7 JSR: http://java.net/projects/javaee-spec/members. Note that non-vendors far outweight vendors and there is no limit to who can join the java.net project.

A lot of time is spent making sure all Java EE APIs integrate with each other. The few gaps that are left are usually promptly filled vendor extensions or plugins. Besides adding features where needed, the major goal of portable extension projects like Seam/CODI is to provide integration with standard/non-standard APIs from various vendors as smoothly possible. Take a look at the current and proposed list of Seam/CODI modules to see why.

As to upgrades, both every JCP expert group and vendor is downright religious about backwards compatibility and upgrade paths. In fact, I think Java EE is too overly concerned with backwards compatibility (perhaps with the sole exception of the Seam project that I see as being far more progressive). For example, products like WebSphere to this day support things like CORBA, EJB 1, EJB 2 and JAX-RPC just so old code can continue to run!

I think this kind of statement lacks serious perspective.

Let alone the community around the JCP that includes people like Antonio, Adam and Werner each open source Java EE implementation like GlassFish, JBoss, Seam and Resin have their own vibrant communities. For example, here is the list of people involved in the Java EE 7 JSR: http://java.net/projects/javaee-spec/members. Note that non-vendors far outweight vendors and there is no limit to who can join the java.net project.

A lot of time is spent making sure all Java EE APIs integrate with each other. The few gaps that are left are usually promptly filled vendor extensions or plugins. Besides adding features where needed, the major goal of portable extension projects like Seam/CODI is to provide integration with standard/non-standard APIs from various vendors as smoothly possible. Take a look at the current and proposed list of Seam/CODI modules to see why.

As to upgrades, both every JCP expert group and vendor is downright religious about backwards compatibility and upgrade paths. In fact, I think Java EE is too overly concerned with backwards compatibility (perhaps with the sole exception of the Seam project that I see as being far more progressive). For example, products like WebSphere to this day support things like CORBA, EJB 1, EJB 2 and JAX-RPC just so old code can continue to run!

I think this kind of statement lacks serious perspective.

Let alone the community around the JCP that includes people like Antonio, Adam and Werner each open source Java EE implementation like GlassFish, JBoss, Seam and Resin have their own vibrant communities. For example, here is the list of people involved in the Java EE 7 JSR: http://java.net/projects/javaee-spec/members. Note that non-vendors far outweight vendors and there is no limit to who can join the java.net project.

A lot of time is spent making sure all Java EE APIs integrate with each other. The few gaps that are left are usually promptly filled vendor extensions or plugins. Besides adding features where needed, the major goal of portable extension projects like Seam/CODI is to provide integration with standard/non-standard APIs from various vendors as smoothly possible. Take a look at the current and proposed list of Seam/CODI modules to see why.

As to upgrades, both every JCP expert group and vendor is downright religious about backwards compatibility and upgrade paths. In fact, I think Java EE is too overly concerned with backwards compatibility (perhaps with the sole exception of the Seam project that I see as being far more progressive). For example, products like WebSphere to this day support things like CORBA, EJB 1, EJB 2 and JAX-RPC just so old code can continue to run!

Hmm - I'm not entirely sure of the point of your post. I guess it's cool that someone from SpringSource itself joins the fray. No one so far is talking about comparing anything other than basic DI features but you.

The point is that projects like Seam Solder, Seam XML Config and CODI enhance even basic DI features via CDI plugins, so they are entirely relevant while talking about CDI DI features. Maybe they are not relevant only because it deprives Spring of a spuriuos claim to "de-facto superiority" :-).

What I find very interesting about your comments on my analysis is that it was reviewed by none other than - you. You had no valid objections to it then and I doubt you do now (in fact, your only concrete suggestion was to use the "p" namespace that I've never seen anyone use in a real Spring project). You can quibble about configuration flavors all you want, but the reality is that anything Spring mandates more configuration.

I'll grant you that it is dated, which is why I fully intend to update and expand on it in article series form as soon as possible. I'll look forward to seeing what you guys have to say on those...

jar scanning *is* quite trivial. It's a matter of one loop and if statements over class definitions you find in a candidate jar. It's performance on most typical systems are in the sub-second range. Spring incurs basically the same cost, just iterating through packages in multiple jars instead of all class definitions in a jar. That's hardly worth the additional configuration burden.

jar scanning *is* quite trivial. It's a matter of one loop and if statements over class definitions you find in a candidate jar. It's performance on most typical systems are in the sub-second range. Spring incurs basically the same cost, just iterating through packages in multiple jars instead of all class definitions in a jar. That's hardly worth the additional configuration burden.

You are missing the point and that's what's making your analysis deeply flawed.

The relationship between Seam 2 and Seam 3 to Java EE is fundamentally different. Seam 2 was a framework like Spring that sat on top of Java EE. Seam 3 (and other CDI portable extension projects like CODI) on the other hand is just a set of ad-hoc CDI plugins. Talking about CDI without it's available plugins is about as meaningless as talking about JSF without it's available plugins. The way I see it, talking about EJB 2 without useful extensions like XDoclet is just as meaningless.

As I have tried to explain to you repeatedly in the past, there is no such thing as "pure Java EE". The job of any good Java EE API is to define the core and foster an extensions/plugins ecoystem that developers can leverage, not act as a walled garden. I think the walled garden is more the Spring mindset in that something that doesn't come from the "mothership" is not considered "pure".

You are missing the point and that's what's making your analysis deeply flawed.

The relationship between Seam 2 and Seam 3 to Java EE is fundamentally different. Seam 2 was a framework like Spring that sat on top of Java EE. Seam 3 (and other CDI portable extension projects like CODI) on the other hand is just a set of ad-hoc CDI plugins. Talking about CDI without it's available plugins is about as meaningless as talking about JSF without it's available plugins. The way I see it, talking about EJB 2 without useful extensions like XDoclet is just as meaningless.

As I have tried to explain to you repeatedly in the past, there is no such thing as "pure Java EE". The job of any good Java EE API is to define the core and foster an extensions/plugins ecoystem that developers can leverage, not act as a walled garden. I think the walled garden is more the Spring mindset in that something that doesn't come from the "mothership" is not considered "pure".

You are missing the point and that's what's making your analysis deeply flawed.

The relationship between Seam 2 and Seam 3 to Java EE is fundamentally different. Seam 2 was a framework like Spring that sat on top of Java EE. Seam 3 (and other CDI portable extension projects like CODI) on the other hand is just a set of ad-hoc CDI plugins. Talking about CDI without it's available plugins is about as meaningless as talking about JSF without it's available plugins. The way I see it, talking about EJB 2 without useful extensions like XDoclet is just as meaningless.

As I have tried to explain to you repeatedly in the past, there is no such thing as "pure Java EE". The job of any good Java EE API is to define the core and foster an extensions/plugins ecoystem that developers can leverage, not act as a walled garden. I think the walled garden is more the Spring mindset in that something that doesn't come from the "mothership" is not considered "pure".

You are missing the point and that's what's making your analysis deeply flawed.

The relationship between Seam 2 and Seam 3 to Java EE is fundamentally different. Seam 2 was a framework like Spring that sat on top of Java EE. Seam 3 (and other CDI portable extension projects like CODI) on the other hand is just a set of ad-hoc CDI plugins. Talking about CDI without it's available plugins is about as meaningless as talking about JSF without it's available plugins. The way I see it, talking about EJB 2 without useful extensions like XDoclet is just as meaningless.

As I have tried to explain to you repeatedly in the past, there is no such thing as "pure Java EE". The job of any good Java EE API is to define the core and foster an extensions/plugins ecoystem that developers can leverage, not act as a walled garden. I think the walled garden is more the Spring mindset in that something that doesn't come from the "mothership" is not considered "pure".

You are missing the point and that's what's making your analysis deeply flawed.

The relationship between Seam 2 and Seam 3 to Java EE is fundamentally different. Seam 2 was a framework like Spring that sat on top of Java EE. Seam 3 (and other CDI portable extension projects like CODI) on the other hand is just a set of ad-hoc CDI plugins. Talking about CDI without it's available plugins is about as meaningless as talking about JSF without it's available plugins. The way I see it, talking about EJB 2 without useful extensions like XDoclet is just as meaningless.

As I have tried to explain to you repeatedly in the past, there is no such thing as "pure Java EE". The job of any good Java EE API is to define the core and foster an extensions/plugins ecoystem that developers can leverage, not act as a walled garden. I think the walled garden is more the Spring mindset in that something that doesn't come from the "mothership" is not considered "pure".

This is actually an implementation detail. All beans need not be loaded on startup and can be loaded lazily as they are needed. All Java objects in a module are also not loaded, just the ones that are legitimate CDI beans. All that is done is jar scanning which is trivial and done for all Java EE components and not just CDI in Java EE 5/Java E 6.

This point actually vividly demonstrates the fundamental philosophical differences between Spring and CDI/Java EE in general that this comparison only vaguely alludes to. In CDI, bean processing via annotaions just works out of the box. In Spring, enabling it requires explicit configuration. My comparsion showed the differences between Spring and Java EE configuration for very common cases: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. Lincoln makes the same point here: http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/ as does CDISouce.

This is actually an implementation detail. All beans need not be loaded on startup and can be loaded lazily as they are needed. All Java objects in a module are also not loaded, just the ones that are legitimate CDI beans. All that is done is jar scanning which is trivial and done for all Java EE components and not just CDI in Java EE 5/Java E 6.

This point actually vividly demonstrates the fundamental philosophical differences between Spring and CDI/Java EE in general that this comparison only vaguely alludes to. In CDI, bean processing via annotaions just works out of the box. In Spring, enabling it requires explicit configuration. My comparsion showed the differences between Spring and Java EE configuration for very common cases: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. Lincoln makes the same point here: http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/ as does CDISouce.

Thanks for mentioning this. I agree talking about CDI without portable extensions is somewhat myopic. In the least case, the article should have made mention of their availability.

The explicit reason CDI supports an extensive portable extensions SPI is to support a rich plugin ecosystem consisting of projects like Seam 3, Apache CODI, Arquillian, Forge, CDISource and so many others. This way, CDI can remain a very small, simple core that focuses on getting the 80% use-case right while allowing for exensions where really needed (but still in a very portable, standards-compliant manner).

I talked about the CDI ecosystem at TSSJS 2011 for those interested: http://www.caucho.com/articles/CDI_Landscape.pdf.

Forking sounds good in theory, but the reality is that forking any open source project is like being handed down a very large legacy application with no one to help you navigate it - which is a big reason why most forks never wind up being a success. There is not even a comparison for the average development effort as to the comparative practicality of forking vis-a-vis simply switching implementations. It's also the case that open source and open standards are not a dichotomy -- they are meant to go together. In fact, the most major Java EE implementations are all open source -- like Resin.

The JCP is not perfect, but in many ways it is better than existing standards bodies. It is an excellent mechanism for developers (like Antonio), the community (like the London Java Community) and vendors (like Caucho, JBoss and Sun/Oracle) to collaborate together to standardize solid innovations in a sensible time-line. To see for yourself or even better, join in right now -- look here. The reality is that JCP expert groups highly prize any positive contributions from independents, so it is well worth your effort.

As you correctly pointed out, point-cuts are quite complex and really not worth their salt for a vast majority of enterprise use-cases where you would want some declarative hint of where a cross-cutting concern is being applied anyway (e.g. @Logged, @Cached, @Monitored, @Transactional, @Secure, etc). This is precisely why Java EE/CDI interceptors avoided points-cuts altogether and went the much more intuitive annotation binding approach and avoided the traditional complexity associated with AOP.

That being said, folks that still need a full-blown AOP system can easily use AspectJ with CDI/Java EE.

Lastly, I wrote a CDI tutorial long ago that covered both interceptors and decorators: http://www.theserverside.com/news/2240016831/Part-3-of-dependency-injection-in-Java-EE-6.

Henk,

The real reason it has been historically difficult to standardize resource configuration is that they differ from vendor to vendor so much. That's why the standardized data source configuration in Java EE 6 is so sparse. Things are even worse for JMS. That being said, I hear your pain and we (I and Antonio) can see if at least some basic JMS configuration can be standardized in Java EE 7.

For now, I would say simply continue to provide deployers XML fragments of resource configuration. Most application servers like GlassFish, JBoss and Resin support that. In fact, in case of Resin you can package database configuration with the application.

Thanks for the input and keep it coming. Also, I encourage you to join the Java EE 7 JSR user open aliases (you do not have to be a JCP member in order to do so).

Cheers,

Reza

Henk,

The real reason it has been historically difficult to standardize resource configuration is that they differ from vendor to vendor so much. That's why the standardized data source configuration in Java EE 6 is so sparse. Things are even worse for JMS. That being said, I hear your pain and we (I and Antonio) can see if at least some basic JMS configuration can be standardized in Java EE 7.

For now, I would say simply continue to provide deployers XML fragments of resource configuration. Most application servers like GlassFish, JBoss and Resin support that. In fact, in case of Resin you can package database configuration with the application.

Thanks for the input and keep it coming. Also, I encourage you to join the Java EE 7 JSR user open aliases (you do not have to be a JCP member in order to do so).

Cheers,

Reza

Henk,

The real reason it has been historically difficult to standardize resource configuration is that they differ from vendor to vendor so much. That's why the standardized data source configuration in Java EE 6 is so sparse. Things are even worse for JMS. That being said, I hear your pain and we (I and Antonio) can see if at least some basic JMS configuration can be standardized in Java EE 7.

For now, I would say simply continue to provide deployers XML fragments of resource configuration. Most application servers like GlassFish, JBoss and Resin support that. In fact, in case of Resin you can package database configuration with the application.

Thanks for the input and keep it coming. Also, I encourage you to join the Java EE 7 JSR user open aliases (you do not have to be a JCP member in order to do so).

Cheers,

Reza

I think you should look at real world implementations instead of simply thinking in a void of how this should be. There is more to any of this than unfortunately readily meets the eye. I mentioned some of those concerns already -- implementation (both simplicity and flexibility)/class-loading/deployment/code-generation/byte-code manipulation/proxying/performance/overall container architecture/innovation and so on.

However, as I promised, I'll bring up the issue for you anyway.

I think you should look at real world implementations instead of simply thinking in a void of how this should be. There is more to any of this than unfortunately readily meets the eye. I mentioned some of those concerns already -- implementation (both simplicity and flexibility)/class-loading/deployment/code-generation/byte-code manipulation/proxying/performance/overall container architecture/innovation and so on.

However, as I promised, I'll bring up the issue for you anyway.

I think you should look at real world implementations instead of simply thinking in a void of how this should be. There is more to any of this than unfortunately readily meets the eye. I mentioned some of those concerns already -- implementation (both simplicity and flexibility)/class-loading/deployment/code-generation/byte-code manipulation/proxying/performance/overall container architecture/innovation and so on.

However, as I promised, I'll bring up the issue for you anyway.

Spring AOP and CDI interceptors are good enough for the vast majority of real world use cases and both AOP system are clear that they require interception only on injected proxy calls. For the remaining cases, it is possible to use AspectJ with CDI, Java EE or pretty much anything else.

Now, I believe I've said everything that needs to be said on this. I don't have the time or patience to explain to you why the imaginary code you have above makes little sense in a real-world proxy-based container. You'll have to find that out on your own by looking at Weld, OpenWebBeans, CanDI or Spring AOP. The way I see it, I have paid this more attention than most people would.

If you really feel that strongly about it, feel free to bring it to the attention of the CDI 1.1 EG that is just currently underway: http://www.jcp.org/en/jsr/proposalDetails?id=346. The JCP page references a JIRA instance for CDI/Weld that you can also use.

Hope it helps.

Spring AOP and CDI interceptors are good enough for the vast majority of real world use cases and both AOP system are clear that they require interception only on injected proxy calls. For the remaining cases, it is possible to use AspectJ with CDI, Java EE or pretty much anything else.

Now, I believe I've said everything that needs to be said on this. I don't have the time or patience to explain to you why the imaginary code you have above makes little sense in a real-world proxy-based container. You'll have to find that out on your own by looking at Weld, OpenWebBeans, CanDI or Spring AOP. The way I see it, I have paid this more attention than most people would.

If you really feel that strongly about it, feel free to bring it to the attention of the CDI 1.1 EG that is just currently underway: http://www.jcp.org/en/jsr/proposalDetails?id=346. The JCP page references a JIRA instance for CDI/Weld that you can also use.

Hope it helps.

The trivial fix would be:

class InterceptedBean{ @MethodReturnOne <-- interceptor, always returns 1 Integer x(){ return 2L; }

 @MethodReturnOne <-- interceptor, always returns 1 Integer y(){ return x(); } }

The big benefit to using proxying vis-a-vis AspectJ style byte-code injection is class-loader simplicity/performance. CDI interceptors are also way easier than arcane AspectJ point-cut syntax.

The trivial fix would be:

class InterceptedBean{ @MethodReturnOne <-- interceptor, always returns 1 Integer x(){ return 2L; }

 @MethodReturnOne <-- interceptor, always returns 1 Integer y(){ return x(); } }

The big benefit to using proxying vis-a-vis AspectJ style byte-code injection is class-loader simplicity/performance. CDI interceptors are also way easier than arcane AspectJ point-cut syntax.

As to integrating CDI with Spring, we are working on it as discussed on the TSS flame-fest. More details here: http://rick-hightower.blogspot.com/2011/04/cdi-and-spring-living-in-harmony.html. There is also a Seam 3 module for it: http://seamframework.org/Documentation/Seam3Modules#H-SpringIntegrationLedByMariusBogoevici.

As to SpringSource doing the CDI integration piece/supporting CDI, I think a snowball has a better chance in hell :-).

You indeed can use @Named as a qualifier.

The trade-off is sacrificing Java-based type-safety and readability as mentioned. The way I see it personally, in most real-life projects, you will only really need a handful of qualifers, so I don't see more type-safe qualifiers as a big issue, but an overall improvement over traditional name based injection point qualification (in fact I suspect it is an evolutionary quirk arising fom the heavy XML dependence of early DI frameworks).

You indeed can use @Named as a qualifier.

The trade-off is sacrificing Java-based type-safety and readability as mentioned. The way I see it personally, in most real-life projects, you will only really need a handful of qualifers, so I don't see more type-safe qualifiers as a big issue, but an overall improvement over traditional name based injection point qualification (in fact I suspect it is an evolutionary quirk arising fom the heavy XML dependence of early DI frameworks).

You indeed can use @Named as a qualifier.

The trade-off is sacrificing Java-based type-safety and readability as mentioned. The way I see it personally, in most real-life projects, you will only really need a handful of qualifers, so I don't see more type-safe qualifiers as a big issue, but an overall improvement over traditional name based injection point qualification (in fact I suspect it is an evolutionary quirk arising fom the heavy XML dependence of early DI frameworks).

You indeed can use @Named as a qualifier.

The trade-off is sacrificing Java-based type-safety and readability as mentioned. The way I see it personally, in most real-life projects, you will only really need a handful of qualifers, so I don't see more type-safe qualifiers as a big issue, but an overall improvement over traditional name based injection point qualification (in fact I suspect it is an evolutionary quirk arising fom the heavy XML dependence of early DI frameworks).

You indeed can use @Named as a qualifier.

The trade-off is sacrificing Java-based type-safety and readability as mentioned. The way I see it personally, in most real-life projects, you will only really need a handful of qualifers, so I don't see more type-safe qualifiers as a big issue, but an overall improvement over traditional name based injection point qualification (in fact I suspect it is an evolutionary quirk arising fom the heavy XML dependence of early DI frameworks).

You indeed can use @Named as a qualifier.

The trade-off is sacrificing Java-based type-safety and readability as mentioned. The way I see it personally, in most real-life projects, you will only really need a handful of qualifers, so I don't see more type-safe qualifiers as a big issue, but an overall improvement over traditional name based injection point qualification (in fact I suspect it is an evolutionary quirk arising fom the heavy XML dependence of early DI frameworks).

Steve,

It sounds as though you haven't looked around the Java EE 6 ecosystem too much (understandable if you have been doing solely Spring develoment for a period of time).

* Seam has had an excellent security module that works with Java EE since Java EE 5. With Seam 3, the security module will work with any CDI compliant container.

* You could do out-of-container testing with embedded containers like OpenEJB since Java EE 5. With Java EE 6, that has been improved even more with making embedded containers mandatory for all containers (including WLS) and well as excellent application-server agnostic testing tools such as JBoss Arquillian.

* Spring Roo has an equivalent in Seam tooling such as seamgen that works with Java EE and is being imoroved even further with Seam 3/Java EE 6. As you noted though, it is also the case that Spring Roo has a relatively narrow use case as such.

* It is true that WLS is closed-souce but of course there are great open source Java EE implementations out there.

* As you mentioned, a majority of Java EE APIs are now pluggable and most people using open source Java EE application servers do upgrade quite frequently without problems.

Hope it helps,

Reza

Adam,

I know how you feel - I've been asked this question numerous times myself and even finally attempted to provide an answer with code examples: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. Personally, I think people should be taking these as input and drawing their own conclusions.

And of course I experience the same thing you see here - that you must be the devil incarnate if you suggest that Spring is anything but manna from heaven when it is crystal clear that it has it's own unique set of trade-offs as most technologies do.

Do yourself a favor and ignore the blatant flames for what they are and simply address the technical points (as you are)...and keep up the good work :-).

Cheers,

Reza

Rob,

I have to say this is an excellent and rather accurate take on Java EE 6. Going forward, we do hope to maintain focus on the basic concept of components, declarative services, ease-of-use, near-zero-configuration and modularity as well as expanding the API set where needed (such as perhaps a higher level security API as compared to JAAS).

Cheers,

Reza

Rob,

Understood and I agree. These are some of the issues I am trying to deal with myself via best practices for using Java EE 6. Indeed, I would say it is not a cardinal sin to not use CDI at all in favor of the more vanilla Java EE 6 APIs (JPA 2, JSF 2, EJB 3.1) or simply focus on using the CDI sub-set defined by JSR 330...

Cheers,

Reza

Rob,

Thanks for the CDI coverage. It wasn't entirely clear to me if you had an alternative DI model in mind other than CDI, Spring or Guice? If you do, what is it? Examples would be great but even a relatively abstract idea is fine.

I look forward to hearing specific areas of suggested improvement as you dig deeper into CDI (we are now just gearing up for Java EE 7 ourselves). I'm no "general" but I'm certainly not too engaged in the "last war" as to not keep my eyes and ears open to valid, constructive suggestions from intelligent people that know what they are talking about...

Cheers,

Reza

Fabrizio,

Thanks for the kind words and I wholeheartedly agree with you. I am tired of individuals and companies in the Java realm thinking they can enlist Java developers as "foot soldiers" at will whenever it suits their purposes - be it Oracle or Google. The big boys already have their big guns - they don't need any help from little guys like us...

As to conference attendance, I think the key is to "buy" whatever product/service provides the best quality at the greatest value instead of making professional choices on the basis of personal political beliefs. This is basically the same as the "buy American" nonsense that never works because it ignores fundamental economic factors in favor of intangible political ones that have little to do with metrics of the actual "but/not buy" decision...

For example, although I value standardization personally, I don't always simply choose standards-backed products for a project unless they really have technical merit as well...

Cheers,

Reza

Adam,

Great job as usual. I do indeed agree that the case for Spring/Java EE integration is much weaker with Java EE 6 than it has been with Java EE 5 and J2EE 1.4. Plotting a chart forward, with Java EE 7 I think we will see two very distinct camps evolving that have very little in terms of common ground.

Cheers,

Reza

It's really great to see the GlassFish roap-map so quickly. Personally, I was not expecting this for a few months. Hopefully this clears up some of the FUD/uncertainty. The content certainly looks great to me.

Cheers,

Reza

Bruno,

The trouble is, of course, that I don't really see IoC as a cure-all either :-). I'm not sure if an IoC based solution is even needed here but is yet another overkill/distraction item to solve the modularity/classloading problem that can have other, perhaps more elegant solutions (Maven is a good example that Adam and others pointed out)...

Ideally, what I'd like to see is "peaceful" aligment of Jigsaw, OSGi and Java EE. So something like Java SE->Jigsaw->OSGi->Java EE. The theory here, of course, is that the realigment would do the evolution OSGi/Jigsaw/Java EE needs to be truly compelling as a modular system...just food for thought...

Cheers,

Reza

Bruno,

The trouble is, of course, that I don't really see IoC as a cure-all either :-). I'm not sure if an IoC based solution is even needed here but is yet another overkill/distraction item to solve the modularity/classloading problem that can have other, perhaps more elegant solutions (Maven is a good example that Adam and others pointed out)...

Ideally, what I'd like to see is "peaceful" aligment of Jigsaw, OSGi and Java EE. So something like Java SE->Jigsaw->OSGi->Java EE. The theory here, of course, is that the realigment would do the evolution OSGi/Jigsaw/Java EE needs to be truly compelling as a modular system...just food for thought...

Cheers,

Reza

Bruno,

The trouble is, of course, that I don't really see IoC as a cure-all either :-). I'm not sure if an IoC based solution is even needed here but is yet another overkill/distraction item to solve the modularity/classloading problem that can have other, perhaps more elegant solutions (Maven is a good example that Adam and others pointed out)...

Ideally, what I'd like to see is "peaceful" aligment of Jigsaw, OSGi and Java EE. So something like Java SE->Jigsaw->OSGi->Java EE. The theory here, of course, is that the realigment would do the evolution OSGi/Jigsaw/Java EE needs to be truly compelling as a modular system...just food for thought...

Cheers,

Reza

Bruno,

The trouble is, of course, that I don't really see IoC as a cure-all either :-). I'm not sure if an IoC based solution is even needed here but is yet another overkill/distraction item to solve the modularity/classloading problem that can have other, perhaps more elegant solutions (Maven is a good example that Adam and others pointed out)...

Ideally, what I'd like to see is "peaceful" aligment of Jigsaw, OSGi and Java EE. So something like Java SE->Jigsaw->OSGi->Java EE. The theory here, of course, is that the realigment would do the evolution OSGi/Jigsaw/Java EE needs to be truly compelling as a modular system...just food for thought...

Cheers,

Reza

Neil,

Hmm...I hope your analysis focuses more on the kind questions about OSGi that people are asking about here and elsewhere rather than your opinion on how the JDK code is organized. Granted Sun-bashing as a "populist" tactic worked for some companies in the past, but I really don't think it is a real substitute for actual solid technical merit for any solution. For one thing, if the JDK is indeed a "mess" and Jigsaw solves the problem there, it stands to reason that Jigsaw would be much more effective for enterprise applications that are presumably much less messy :-).

Cheers,

Reza

Neil,

I look forward to your post. I hope you will consider posting it on it's own right on DZone or elsewhere instead of merely as a link. You are correct in that there is no inherent mismatch between Java EE (a pretty high level developement API on a platform) and a modularity systems be it JAR/EAR/WAR/Jigsaw/OSGi that deals with more-or-less orthogonal concerns. I guess that the point I was trying to get across is that in Java EE and Java SE, it is more critical than ever to keep usability and developer productivity in mind. As you know that has been the focus in Java EE 5 and Java EE 6. I can assure you there is no tribalism going on from my perspective, just a focus on keeping things simple where they can be. You are also correct in that I think most application servers will support both the OSGi and "Jigsaw+" (if it comes to that via broader vendor consensus) development models going forward so that it is the best solution that "wins" in the end.

I do hope you will make an attempt to keep your analysis technical but digestible from a "layman's" perspective and keep my/Adam's comments (and similar others that might be more pervasive than you think and are quite natural questions) in mind in your write-up.

Best regards,

Reza

Neil,

I look forward to your post. I hope you will consider posting it on it's own right on DZone or elsewhere instead of merely as a link. You are correct in that there is no inherent mismatch between Java EE (a pretty high level developement API on a platform) and a modularity systems be it JAR/EAR/WAR/Jigsaw/OSGi that deals with more-or-less orthogonal concerns. I guess that the point I was trying to get across is that in Java EE and Java SE, it is more critical than ever to keep usability and developer productivity in mind. As you know that has been the focus in Java EE 5 and Java EE 6. I can assure you there is no tribalism going on from my perspective, just a focus on keeping things simple where they can be. You are also correct in that I think most application servers will support both the OSGi and "Jigsaw+" (if it comes to that via broader vendor consensus) development models going forward so that it is the best solution that "wins" in the end.

I do hope you will make an attempt to keep your analysis technical but digestible from a "layman's" perspective and keep my/Adam's comments (and similar others that might be more pervasive than you think and are quite natural questions) in mind in your write-up.

Best regards,

Reza

Neil,

I look forward to your post. I hope you will consider posting it on it's own right on DZone or elsewhere instead of merely as a link. You are correct in that there is no inherent mismatch between Java EE (a pretty high level developement API on a platform) and a modularity systems be it JAR/EAR/WAR/Jigsaw/OSGi that deals with more-or-less orthogonal concerns. I guess that the point I was trying to get across is that in Java EE and Java SE, it is more critical than ever to keep usability and developer productivity in mind. As you know that has been the focus in Java EE 5 and Java EE 6. I can assure you there is no tribalism going on from my perspective, just a focus on keeping things simple where they can be. You are also correct in that I think most application servers will support both the OSGi and "Jigsaw+" (if it comes to that via broader vendor consensus) development models going forward so that it is the best solution that "wins" in the end.

I do hope you will make an attempt to keep your analysis technical but digestible from a "layman's" perspective and keep my/Adam's comments (and similar others that might be more pervasive than you think and are quite natural questions) in mind in your write-up.

Best regards,

Reza

Neil,

I look forward to your post. I hope you will consider posting it on it's own right on DZone or elsewhere instead of merely as a link. You are correct in that there is no inherent mismatch between Java EE (a pretty high level developement API on a platform) and a modularity systems be it JAR/EAR/WAR/Jigsaw/OSGi that deals with more-or-less orthogonal concerns. I guess that the point I was trying to get across is that in Java EE and Java SE, it is more critical than ever to keep usability and developer productivity in mind. As you know that has been the focus in Java EE 5 and Java EE 6. I can assure you there is no tribalism going on from my perspective, just a focus on keeping things simple where they can be. You are also correct in that I think most application servers will support both the OSGi and "Jigsaw+" (if it comes to that via broader vendor consensus) development models going forward so that it is the best solution that "wins" in the end.

I do hope you will make an attempt to keep your analysis technical but digestible from a "layman's" perspective and keep my/Adam's comments (and similar others that might be more pervasive than you think and are quite natural questions) in mind in your write-up.

Best regards,

Reza

Neil,

I look forward to your post. I hope you will consider posting it on it's own right on DZone or elsewhere instead of merely as a link. You are correct in that there is no inherent mismatch between Java EE (a pretty high level developement API on a platform) and a modularity systems be it JAR/EAR/WAR/Jigsaw/OSGi that deals with more-or-less orthogonal concerns. I guess that the point I was trying to get across is that in Java EE and Java SE, it is more critical than ever to keep usability and developer productivity in mind. As you know that has been the focus in Java EE 5 and Java EE 6. I can assure you there is no tribalism going on from my perspective, just a focus on keeping things simple where they can be. You are also correct in that I think most application servers will support both the OSGi and "Jigsaw+" (if it comes to that via broader vendor consensus) development models going forward so that it is the best solution that "wins" in the end.

I do hope you will make an attempt to keep your analysis technical but digestible from a "layman's" perspective and keep my/Adam's comments (and similar others that might be more pervasive than you think and are quite natural questions) in mind in your write-up.

Best regards,

Reza

Neil,

I look forward to your post. I hope you will consider posting it on it's own right on DZone or elsewhere instead of merely as a link. You are correct in that there is no inherent mismatch between Java EE (a pretty high level developement API on a platform) and a modularity systems be it JAR/EAR/WAR/Jigsaw/OSGi that deals with more-or-less orthogonal concerns. I guess that the point I was trying to get across is that in Java EE and Java SE, it is more critical than ever to keep usability and developer productivity in mind. As you know that has been the focus in Java EE 5 and Java EE 6. I can assure you there is no tribalism going on from my perspective, just a focus on keeping things simple where they can be. You are also correct in that I think most application servers will support both the OSGi and "Jigsaw+" (if it comes to that via broader vendor consensus) development models going forward so that it is the best solution that "wins" in the end.

I do hope you will make an attempt to keep your analysis technical but digestible from a "layman's" perspective and keep my/Adam's comments (and similar others that might be more pervasive than you think and are quite natural questions) in mind in your write-up.

Best regards,

Reza

Neil,

I look forward to your post. I hope you will consider posting it on it's own right on DZone or elsewhere instead of merely as a link. You are correct in that there is no inherent mismatch between Java EE (a pretty high level developement API on a platform) and a modularity systems be it JAR/EAR/WAR/Jigsaw/OSGi that deals with more-or-less orthogonal concerns. I guess that the point I was trying to get across is that in Java EE and Java SE, it is more critical than ever to keep usability and developer productivity in mind. As you know that has been the focus in Java EE 5 and Java EE 6. I can assure you there is no tribalism going on from my perspective, just a focus on keeping things simple where they can be. You are also correct in that I think most application servers will support both the OSGi and "Jigsaw+" (if it comes to that via broader vendor consensus) development models going forward so that it is the best solution that "wins" in the end.

I do hope you will make an attempt to keep your analysis technical but digestible from a "layman's" perspective and keep my/Adam's comments (and similar others that might be more pervasive than you think and are quite natural questions) in mind in your write-up.

Best regards,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Neil,

It is always good to see folks in a particular community accepting non-positive feedback seriously and professionally. From a personal standpoint, I did explore OSGi with an open mind. To my dismay, what I found is a very complex, low-level specification that needs a lot of evolution/abstraction to be adapted to be digestible to most enterprise Java environments. It also seems quite overkill for most realistic enterprise needs. Jigsaw in comparison feels much more "clean room", Java-centric, compact and easy to understand. These qualities do make it very compelling for me personally. Without devolving into a flame war, could you give me some simple, layman points that I am missing? Alternatively, please do feel free to simply point me to a resource I can take a look at.

Thanks in advance,

Reza

Adam,

It is good to see the post - brazen and to-the-point as usual. I think it is about time people started asking these questions vis-a-vis OSGi. I too have seen a lot of people waste a lot of time on OSGi before figuring out the pitfalls. Personally, I am very happy to see Java modularity not going the OSGi route and staying very Java centric. I had been very fearful we will see an entirely avoidable marketing-driven replay of EJB 1.x/EJB 2.x if Java SE and Java EE went the OSGi route and basically handed a big blow to the hard-earned advances in Java EE 5, Java EE 6 and the Java EE 7 effort that is now underway...

Cheers,

Reza

Ryan,

I understand what you are saying, but like anything else in life, I don't think it is sound to make too many generalizations.

Yes, we all know that EJB 2.x was a bad idea. However, as I mentioned, there are many examples where innovation through the standard is effective (and in some cases unavoidable). It all depends on who is doing the innovating and why they are doing it. From a personal standpoint, I would certainly not be shy of bringing up good ideas in an expert group or opening up a JSR if there is true technical merit. One value of the standardization process that I have seen is that weak ideas and edge case features often don't make the final cut. It's also important to note that developers do have input into the standardization process, just as they have into an open source product for example. The most visible means of such input are the many independents that work inside the JCP (myself included).

Cheers,

Reza

P.S.: As much as there are many problems with EJB 2.x/EJB 1.x/CORBA that persisted way too long, the fact is that it did bring many ideas to the mainstream that influence us even today - for example the idea of declarative services provided transparently by a run-time. The same I think applies to the early versions of JSF too (BTW, I do think that JSF 1.x+Facelets+RichFaces and JSF 2 are excellent solutions).

Ryan,

I understand what you are saying, but like anything else in life, I don't think it is sound to make too many generalizations.

Yes, we all know that EJB 2.x was a bad idea. However, as I mentioned, there are many examples where innovation through the standard is effective (and in some cases unavoidable). It all depends on who is doing the innovating and why they are doing it. From a personal standpoint, I would certainly not be shy of bringing up good ideas in an expert group or opening up a JSR if there is true technical merit. One value of the standardization process that I have seen is that weak ideas and edge case features often don't make the final cut. It's also important to note that developers do have input into the standardization process, just as they have into an open source product for example. The most visible means of such input are the many independents that work inside the JCP (myself included).

Cheers,

Reza

P.S.: As much as there are many problems with EJB 2.x/EJB 1.x/CORBA that persisted way too long, the fact is that it did bring many ideas to the mainstream that influence us even today - for example the idea of declarative services provided transparently by a run-time. The same I think applies to the early versions of JSF too (BTW, I do think that JSF 1.x+Facelets+RichFaces and JSF 2 are excellent solutions).

Ryan,

I understand what you are saying, but like anything else in life, I don't think it is sound to make too many generalizations.

Yes, we all know that EJB 2.x was a bad idea. However, as I mentioned, there are many examples where innovation through the standard is effective (and in some cases unavoidable). It all depends on who is doing the innovating and why they are doing it. From a personal standpoint, I would certainly not be shy of bringing up good ideas in an expert group or opening up a JSR if there is true technical merit. One value of the standardization process that I have seen is that weak ideas and edge case features often don't make the final cut. It's also important to note that developers do have input into the standardization process, just as they have into an open source product for example. The most visible means of such input are the many independents that work inside the JCP (myself included).

Cheers,

Reza

P.S.: As much as there are many problems with EJB 2.x/EJB 1.x/CORBA that persisted way too long, the fact is that it did bring many ideas to the mainstream that influence us even today - for example the idea of declarative services provided transparently by a run-time. The same I think applies to the early versions of JSF too (BTW, I do think that JSF 1.x+Facelets+RichFaces and JSF 2 are excellent solutions).

Ryan,

Thanks for pointing out the flip-side of this often used fallacy. "Standardization vs. open-source" is indeed a totally false dichotomy (curiuosly similar to the arguments made by some of the non-open source commercial vendors). At any given time, any standards compliant implementation (open source or not) will have features that go beyond the standard (the best of which go into a future revision of the standard by gaining acceptance through collaboration in a standards body). RESTEasy and Seam 3 are good examples of that, as is our CanDI, EJB 3.1 Lite or JAAS/security implementation in Resin. This on it's own, I don't think is good enough reason for being too tightly tied to any single product (unless the gap is particularly wide like Spring 2.0 and EJB 2.x). It is a good reason to keep an eye out on various implementations and choose the best one available at any given time for a given project. This is especially true of highly pluggable products like JSF, JPA, JAX-RS and JAX-WS.

I disagree with the opinion that standards just consolidate and don't innovate on their own right. When vendors come together, they innovate in the process of standardizing as well. Good examples of this are the annotation paradigm in EJB 3/Java EE 5, a lot of the CDI (JSR 299) features as well as curiously enough, JAX-RS itself. I doubt this is Bill Burke's opinion since we has one of the folks that are responsible for EJB 3.0/Java EE 5.

Cheers,

Reza

Can you kindly expand on the API remark? Have you taken a look at the EJB 3.1 timer API? How is the recompile/redeploy requirement any different than Quartz, for example? As I see it, EJB 3.1 timers fulfill 80-90% of application use-cases.

Cheers,

Reza

Can you kindly expand on the API remark? Have you taken a look at the EJB 3.1 timer API? How is the recompile/redeploy requirement any different than Quartz, for example? As I see it, EJB 3.1 timers fulfill 80-90% of application use-cases.

Cheers,

Reza

Mitchell,

Just a minor point - Resin CanDI can actually run in Java SE as an embedded runtime with full support for all enterprise services including @TransactionAttribute, @Schedule, @Asynchronous, @Lock and @Startup. We can certainly run CanDI on GAE if there is sufficient interest in the community.

Cheers,

Reza

========================

Resin EJB 3.1 Lite Container Developer

Exper Group Member, Java EE 6 and EJB 3.1

Author, EJB 3 in Action

Adam,

BTW, maybe it would be cool to document how different application servers approach pooling?

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Henk,

Good job on thinking some of this through and looking past the usual misconceptions.

I agree the biggest difference between CDI managed beans and EJB are the defaults. Since EJB is designed for the business/service tier, the defaults that make the most sense are transactions and thread-safety. This means that you can use pretty much safely use whathever resource you want (like a JPA entity manager which is not thread-safe or even a raw TCP connection) inside an EJB without worrying about what is going to happen in a production environment.

Given that most back-end resources are usually session-based/connection-based/transactional, thread-safety concerns at the service tier are pretty much unavoidable in enterprise applications. Alternative component models that do not have built-in thread-safety semantics basically deal with this problem by creating proprietary abstractions over shared resources (like JPA entity managers, JMS and JDBC) that have to implement thread-safety behind the scenes (Spring's "entity manager proxy" extension that wraps native JPA entiy managers before injecting them is a great example of this).

Adam's analysis that pooling is sensible as long as the container implements EJB thread-safety by synchronizing on the pool (which almost all containers that I know of do) is exactly on the money too. Besides saving CPU resources needlessly constructing and destroying bean references, pooling also guarantees graceful handling under heavy (especially sudden) load and helps by minimizing garbage collection churn under moderate load.

Cheers,

Reza

Adam,

Great post as usual. I think it would be great if you wrote a similar post on JTA. I think there are a lot of misconceptions around that as well that could be cleared-up. Here is an interesting section from the spec on JTA:

=====================================================================
Many applications will consist of one or several enterprise beans that all use a single resource manager (typically a relational database management system). The EJB container can make use of resource manager local transactions as an optimization technique for enterprise beans for which distributed transactions are not needed. A resource manager local transaction does not involve control or coordination by an external transaction manager. The container’s use of local transactions as an optimization technique for enterprise beans with either container-managed transaction demarcation or bean-managed transaction demarcation is not visible to the enterprise beans. For a discussion of the use of resource manager local transactions as a container optimization strategy, refer to [ 12 ] and [ 15 ].
=====================================================================

Cheers,

Reza

========================

Resin EJB 3.1 Lite Container Developer

Expert Group Member, Java EE 6 and EJB 3.1

Author, EJB 3 in Action

Ummm...you are really being a little paranoid here. There are plenty of people who are supporters of Java EE that have nothing to do wioth Sun. You are really fooling yourself if you beleive Spring is end-all-be-all. It hasn't been past Spring 2.0...

Cheers,

Reza

Ummm...you are really being a little paranoid here. There are plenty of people who are supporters of Java EE that have nothing to do wioth Sun. You are really fooling yourself if you beleive Spring is end-all-be-all. It hasn't been past Spring 2.0...

Cheers,

Reza

Carol,

Great job and thanks for posting this.

Cheers,

Reza

Carol,

Great job and thanks for posting this.

Cheers,

Reza

Ryan,

How about an analysis piece covering the pros vs. the cons of Java EE 6 with/without Spring? I am giving a talk on a very similar topic for JBossWorld this year, feel free to check it out. Also, how about a analysis of the current state of OSGi? I think the community could benefit from an honest analysis from someone without anything to "sell" but something valuable to say. I was planning on doing something similar, but don't really have the time. You might find this interesting: http://blog.caucho.com/?tag=osgi. Also, you could write an article about contributing to the community at large as a developer via open source, standards, writing, speaking etc.

All the best,

Reza

Ryan,

How about an analysis piece covering the pros vs. the cons of Java EE 6 with/without Spring? I am giving a talk on a very similar topic for JBossWorld this year, feel free to check it out. Also, how about a analysis of the current state of OSGi? I think the community could benefit from an honest analysis from someone without anything to "sell" but something valuable to say. I was planning on doing something similar, but don't really have the time. You might find this interesting: http://blog.caucho.com/?tag=osgi. Also, you could write an article about contributing to the community at large as a developer via open source, standards, writing, speaking etc.

All the best,

Reza

Ryan,

How about an analysis piece covering the pros vs. the cons of Java EE 6 with/without Spring? I am giving a talk on a very similar topic for JBossWorld this year, feel free to check it out. Also, how about a analysis of the current state of OSGi? I think the community could benefit from an honest analysis from someone without anything to "sell" but something valuable to say. I was planning on doing something similar, but don't really have the time. You might find this interesting: http://blog.caucho.com/?tag=osgi. Also, you could write an article about contributing to the community at large as a developer via open source, standards, writing, speaking etc.

All the best,

Reza

Good job Ryan...

Cheers,

Reza

Ibrahim,

Sounds promising, do hope you keep it up. In case you haven't looked at it yet, JCDI (JSR 299) might help you with the effort: http://jcp.org/en/jsr/detail?id=299. Although JCDI is targeted for Java EE 6, the goal of the JSR is to be able to create pluggable implementations that can run on top of Java EE 5. You could actually consider simply donating your code to the Apache or JBoss JSR 299 implementation: http://incubator.apache.org/openwebbeans/ (or maybe even Resin's JSR 299 implementation :-)).

A few years back, I was really hoping Spring would do exactly this. Indeed, some of the Spring template APIs do this fairly well and can cleanly be integrated on top of Java EE 5. I think they have gotten a little too carried away from that focus into the often virulent/counter-productive anti-Java EE mind-set. Sometimes I can't help but think the unneccessary negativity has made them into what they once hated, but that's another story. I keep hoping that will change at some point, but it is obviously up to them. Personally, I've given them my support in incorporating the Rod's DI JSR (JSR 330) into Java EE 6 and have kept open arms/open mind.

Best of luck,

Reza

Ibrahim,

Sounds promising, do hope you keep it up. In case you haven't looked at it yet, JCDI (JSR 299) might help you with the effort: http://jcp.org/en/jsr/detail?id=299. Although JCDI is targeted for Java EE 6, the goal of the JSR is to be able to create pluggable implementations that can run on top of Java EE 5. You could actually consider simply donating your code to the Apache or JBoss JSR 299 implementation: http://incubator.apache.org/openwebbeans/ (or maybe even Resin's JSR 299 implementation :-)).

A few years back, I was really hoping Spring would do exactly this. Indeed, some of the Spring template APIs do this fairly well and can cleanly be integrated on top of Java EE 5. I think they have gotten a little too carried away from that focus into the often virulent/counter-productive anti-Java EE mind-set. Sometimes I can't help but think the unneccessary negativity has made them into what they once hated, but that's another story. I keep hoping that will change at some point, but it is obviously up to them. Personally, I've given them my support in incorporating the Rod's DI JSR (JSR 330) into Java EE 6 and have kept open arms/open mind.

Best of luck,

Reza

Adam,

Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.

Cheers,

Reza

Adam,

Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.

Cheers,

Reza

Adam,

Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.

Cheers,

Reza

Adam,

Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.

Cheers,

Reza

Adam,

Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.

Cheers,

Reza

Adam,

Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.

Cheers,

Reza

Adam,

Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.

Cheers,

Reza

Give OpenEJB or EasyBeans a try for unit/integration testing: http://openejb.apache.org. That's what I use for my Java EE 5 projects. The startup and shutdown has typical performance in the sub-second range. I am told the JBoss folks are working to scale down the Embeddded JBoss tool once it gets out of beta mode (which it is still currently in). I would imagine the GlassFish folks will do the same when they become Java EE 6 compliant and their Embedded tool is productionized. And there will be choices from the WLS, IBM, etc camps too since embedded containers are part of the Java EE 6 standard (and of course Resin will have a solution too :-)).

Configuration complexity is of course a more subjective topic. Most developers that work with Java EE 5 state that working with it (unit testing included) requires a lot less configuration effort and it has a much smoother learning curve. Both of these factors can be traced to the fact that Java EE is a cohesive platform focused on solutions for the 80% use case rather than providing options and features that cover edge cases...

Hope it helps,

Reza

Give OpenEJB or EasyBeans a try for unit/integration testing: http://openejb.apache.org. That's what I use for my Java EE 5 projects. The startup and shutdown has typical performance in the sub-second range. I am told the JBoss folks are working to scale down the Embeddded JBoss tool once it gets out of beta mode (which it is still currently in). I would imagine the GlassFish folks will do the same when they become Java EE 6 compliant and their Embedded tool is productionized. And there will be choices from the WLS, IBM, etc camps too since embedded containers are part of the Java EE 6 standard (and of course Resin will have a solution too :-)).

Configuration complexity is of course a more subjective topic. Most developers that work with Java EE 5 state that working with it (unit testing included) requires a lot less configuration effort and it has a much smoother learning curve. Both of these factors can be traced to the fact that Java EE is a cohesive platform focused on solutions for the 80% use case rather than providing options and features that cover edge cases...

Hope it helps,

Reza

Liam,

You are of course entitled to your opinions (as for me, I tend to stay away from predictions altogether - they tend to have a built-in quality of Hubris about them). The prediction you speak of is hardly new or original though (or speak to the content of the article for that matter). The reality is that Java EE adoption continues to rise despite all the naysaying. Indeed, I see more EJB/full stack Java EE adoption now than I have seen at any other point in my career. In the mythical "golden years" of J2EE picture some people like to portray, I hardly saw anyone deploying EJB beyond some very large corporations. These days, I see mid-sized companies and even startups giving serious thought to full stack Java EE adoption (albeit often with JBoss Seam - a good bit of which is being standardized in Java EE 6). Just some things to think about before making too swift of a generalization...

I also beg to differ on your assertion that an EJB does not meet the definition of a POJO or that frameworks are necessarily better than platforms universally. I think both of those statements are a little out of balance :-). I do agree that the OSGi story is yet to play out fully. With respect to Adam, I do think the statement on OSGi could have been phrased better (then again, who amongst us can claim to never have mis-phrased something - I most certainly have).

Cheers,

Reza

Liam,

You are of course entitled to your opinions (as for me, I tend to stay away from predictions altogether - they tend to have a built-in quality of Hubris about them). The prediction you speak of is hardly new or original though (or speak to the content of the article for that matter). The reality is that Java EE adoption continues to rise despite all the naysaying. Indeed, I see more EJB/full stack Java EE adoption now than I have seen at any other point in my career. In the mythical "golden years" of J2EE picture some people like to portray, I hardly saw anyone deploying EJB beyond some very large corporations. These days, I see mid-sized companies and even startups giving serious thought to full stack Java EE adoption (albeit often with JBoss Seam - a good bit of which is being standardized in Java EE 6). Just some things to think about before making too swift of a generalization...

I also beg to differ on your assertion that an EJB does not meet the definition of a POJO or that frameworks are necessarily better than platforms universally. I think both of those statements are a little out of balance :-). I do agree that the OSGi story is yet to play out fully. With respect to Adam, I do think the statement on OSGi could have been phrased better (then again, who amongst us can claim to never have mis-phrased something - I most certainly have).

Cheers,

Reza

Liam,

You are of course entitled to your opinions (as for me, I tend to stay away from predictions altogether - they tend to have a built-in quality of Hubris about them). The prediction you speak of is hardly new or original though (or speak to the content of the article for that matter). The reality is that Java EE adoption continues to rise despite all the naysaying. Indeed, I see more EJB/full stack Java EE adoption now than I have seen at any other point in my career. In the mythical "golden years" of J2EE picture some people like to portray, I hardly saw anyone deploying EJB beyond some very large corporations. These days, I see mid-sized companies and even startups giving serious thought to full stack Java EE adoption (albeit often with JBoss Seam - a good bit of which is being standardized in Java EE 6). Just some things to think about before making too swift of a generalization...

I also beg to differ on your assertion that an EJB does not meet the definition of a POJO or that frameworks are necessarily better than platforms universally. I think both of those statements are a little out of balance :-). I do agree that the OSGi story is yet to play out fully. With respect to Adam, I do think the statement on OSGi could have been phrased better (then again, who amongst us can claim to never have mis-phrased something - I most certainly have).

Cheers,

Reza

Adam,

Firstly, excellent article - I agree with you a 100%. A handful of bad implementations most certainly have a lot to do with the bad rap Java EE has received over the years. It's also hard to ignore the fact that the EJB 2.x (specifically 2.x Entity Beans) programming model was pretty cumbersome/heavyweight.

I do think most informed developers already know that the bloat is a thing of the past, especially with very focused Java EE 5 implementations like GlassFish/JBoss 5. Hopefully the upcoming Java EE 6 Web Profile, pruning, Java Contexts and Dependency Injection (aka WebBeans) and EJB 3.1 Lite will convince a few more developers that all that can be conceivably done to keep Java EE as simple and streamlined as possible is being done wholeheartedly.

I am currently working on Resin's EJB 3.1 Lite container and think Resin is a great example of the next generation of Java EE too. The Resin folks have always taken pride in keeping Resin as lightweight as possible, so hopefully we can all look forward to a decidedly lightweight, painless Java EE 6 Web Profile compliant application server in the form of Resin. Interestingly, the Resin folks have already looked at OSGi and bypassed it as a technology that is very promising but not all that applicable for most bread-and-butter Java EE applications. Take a look at "Why OSGi is cool, but not for most enterprise apps": http://blog.caucho.com/?p=213.

Cheers,

Reza

mlavannis,

Debu is an old school Sanatana Dharma guy, hence the cow :-).

Best regards,
Reza

Meera,

I'll definitely try to get as much community involvement as I can throughout the project. Right now, I am trying to get the project charter+requirements+high level architecture reveiwed/approved by the SpringSource folks. I am thiking of opening that document up for community review before I start work on the prototype...at this point, the project is likely going to be part of the SpringSource portfolio.

Reza

Meera,

I'll definitely try to get as much community involvement as I can throughout the project. Right now, I am trying to get the project charter+requirements+high level architecture reveiwed/approved by the SpringSource folks. I am thiking of opening that document up for community review before I start work on the prototype...at this point, the project is likely going to be part of the SpringSource portfolio.

Reza

Meera,

I'll definitely try to get as much community involvement as I can throughout the project. Right now, I am trying to get the project charter+requirements+high level architecture reveiwed/approved by the SpringSource folks. I am thiking of opening that document up for community review before I start work on the prototype...at this point, the project is likely going to be part of the SpringSource portfolio.

Reza

Meera,

I'll definitely try to get as much community involvement as I can throughout the project. Right now, I am trying to get the project charter+requirements+high level architecture reveiwed/approved by the SpringSource folks. I am thiking of opening that document up for community review before I start work on the prototype...at this point, the project is likely going to be part of the SpringSource portfolio.

Reza

Sidewinder,

Indeed the JPA 2.0 EG is trying to make custom component development a lot easier ala Facelets. I think the draft for that is coming out soon. I would encourage you to take a look at it and send in early comments.

Here is the JSR page: http://jcp.org/en/jsr/detail?id=314

Reza

Sidewinder,

Indeed the JPA 2.0 EG is trying to make custom component development a lot easier ala Facelets. I think the draft for that is coming out soon. I would encourage you to take a look at it and send in early comments.

Here is the JSR page: http://jcp.org/en/jsr/detail?id=314

Reza

Meera,

Thank you for an excellent article. As you know, these are some of the same ideas myself and Debu forwarded in the Spring and EJB 3 chapter of EJB 3 in Action. I definitely see excellent integration opportunities for EJB 3 and Spring, just as I see excellent oppotunities for WebBeans/Seam and EJB 3 integration.

Indeed, I am curently working with SpringSource on an EJB 3.1 Lite implementation for the Spring framework/platform that should make such integration even easier (essentially a follow-up to the Spring Pitchfork project intiated by BEA but not followed through).

Cheers,

Reza

Meera,

Thank you for an excellent article. As you know, these are some of the same ideas myself and Debu forwarded in the Spring and EJB 3 chapter of EJB 3 in Action. I definitely see excellent integration opportunities for EJB 3 and Spring, just as I see excellent oppotunities for WebBeans/Seam and EJB 3 integration.

Indeed, I am curently working with SpringSource on an EJB 3.1 Lite implementation for the Spring framework/platform that should make such integration even easier (essentially a follow-up to the Spring Pitchfork project intiated by BEA but not followed through).

Cheers,

Reza

Munwar:

Try posting to the Manning EJB 3 in Action forum here: http://www.manning-sandbox.com/forum.jspa?forumID=273. I or Debu will be happy to help you get started with our example code.

Cheers,

Reza

Munwar:

Try posting to the Manning EJB 3 in Action forum here: http://www.manning-sandbox.com/forum.jspa?forumID=273. I or Debu will be happy to help you get started with our example code.

Cheers,

Reza

Munwar:

Try posting to the Manning EJB 3 in Action forum here: http://www.manning-sandbox.com/forum.jspa?forumID=273. I or Debu will be happy to help you get started with our example code.

Cheers,

Reza

Munwar:

Try posting to the Manning EJB 3 in Action forum here: http://www.manning-sandbox.com/forum.jspa?forumID=273. I or Debu will be happy to help you get started with our example code.

Cheers,

Reza

Debu,

Great job as usual effectively representing our views as an authoring team :-).

Cheers,

Reza