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.

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.

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...

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.

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).

Carol,

Great job and thanks for posting this.

Cheers,

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

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