Arbi Sookazian wrote on Feb 08, 2010 07:51:


from the Weld ref doc:

CDI is the first technology, and certainly the first specification in the Java
EE platform, that achieves this level of loose coupling in a typesafe way.

So I'm wondering how many Java dev shops are taking the type safety and loose coupling manifesto very seriously as I would hope they should be?

Who knows... loose coupling and typesafety are not that important for other JSRs... for example JSF (and JSP) navigation, is not typesafe at all. Is typesafety good for all things? (the Wicket guys, the Tapestry guys, the WebObjects guys (and me) have known it is good for navigation, but the JSF guys seem to believe different, why is that?)

In order to push Java EE 6 platform into my company, it needs to pass architect team's approval.  And they are saying that we need to prove the new technology is providing something we currently don't have in our technology stack and something that will benefit the company, its revenue, customers, software products, etc.  Bottom line: how will Java EE 6 have a positive effect on productivity, revenue, customer experience, risk, etc?

Very good question, would love to know someone with an objective answer... (but I also believe that to be almost impossible)

So I'm wondering if any technology stacks (namely Spring 3) have achieved type safety and loose coupling in the way that CDI has?  I know that the Spring API has heavy usage of annotations now and most Spring projects post-2.5 are more annotation-driven using Java 5/6 than before.

Also... is loose coupling even at all possible in Java without JavaRebel support? Because without it, updating specific modules has a big impact on the rest of the application (an impact that does not exist in PHP, Javascript, Ruby and even in JSP-without-MVC or Groovy land)

I'm just wondering how seriously the industry and dev shops are taking the type-safe and loosely coupled concepts?  Yes, it's great to have reusable, refactorable, maintainable and tool-friendly code/components.

Maintainable? just try to fix a bug in a JSF component , and uploading your fix in to your production environment against doing the same with a bug in a UI widget implemented in JavaScript (in YUI, ExtJS, jQuery, take your pick). What is easier? (Hint: not JSF)

I agree.  Who else does and how many shops are actually taking action on Java EE 6 platform this year?  How many shops are planning on having EE6 deployments in say 2 years?

We do have one team whose architect is already using Glassfish v3, but EE6 projects are marked in the experimental phase since most teams are not comfortable with being the guinea pigs (which I totally understand). 

Mmm, and which one of the features that Glassfish has (and Tomcat does not have) are really required to finish those projects?

Also, from a learning curve perspective, it will always be harder in the near term to find qualified candidates for projects using EE6 APIs vs. Spring 2.x or even Spring 3.  I suppose if you can find a Seam dev, then EE 6 will be easier to learn (main learning curve being CDI I imagine) but there aren't too many experienced Seam devs out there...

Also.. is Seam knowledge really applicable for CDI? I mean, the general IoC principles of course are, but that is also true if you come from Spring, or Guice, or... is the learning curve really much better if you go from Seam in to Weld than if you go from Spring in to Weld?

I would say the learning curve from Seam to Weld will be among the lowest in frameworks considering the background of JSR-299 and the fact that most concepts in Seam have an equivalence (or a thought-out migration path) in Weld.

Arbi Sookazian wrote on Feb 08, 2010 20:18:


I'd have to agree with Nicklas on that one.  But there are not too many experienced Seam devs in the world.  I feel advanced somehow all of a sudden as of Dec 2009. :)

Really? exactly what is so common between Seam and Weld (and so different between Spring and Weld) that makes the learning curve for Weld significantly harder for people that know Spring but do not know Seam?. Concrete examples only, please.

As long as I don't have to learn/use AOP, that's one thing I agree with GKing on, overkill and over-complex.

Yes, but if you already know  Spring, and are already comfortable with AOP... does that mean you will feel that Weld interceptors are hard? IMO no... what could make people not switch to Weld is that they may feel that AOP is more powerful (note that I am not saying it is, I am saying that might be the perception of some people).

But I would have liked to see Maven 3 with CDI/Weld or other frmwks/libs using Weld...

Well, Maven is not an standard (no JSR for it, or something remotely like it that I know about), and its (ugly) XML based configuration files are not type safe at all...

Arbi Sookazian wrote on Feb 08, 2010 21:36:


The only support for conversations that Spring has is in Spring Web Flow with flows AFAIK.  So there is no direct comparison in Spring core with Weld @ConversationScoped, correct?

Correct. So to go from Spring to Weld, one needs to understand conversations (and only if one has not used the somewhat similar if more cumbersome WebFlow). Anything else? So far, it seems like it will be easy for Spring developer to switch to Weld if they want to do so (or if not easy, slightly harder to switch than for Seam developers)... And RIAs technologies (Flex, Silverlight/JavaFX) , JS widgets (ExtJs, YUI) and javascript compilers (GWT, Echo) are IMO) slowly eroding the need for conversations (except on very specify and not very common scenarios)

Also, I've recently had a lot of exposure to Maven 2 at work on the new project and you're right about the excessive XML (although a lot of Maven is designed to be convention over configuration so it's really minimized xml apparently).  But you're right, it's not type-safe and neither are Ant scripts.

Exactly, they both are not type-safe.How lame is that? :'(. But in Ant I can code in JavaScript to fix rapidly any shortcoming... with Maven... (no dynamism, no type safety... what's the use?)

There is one build tool (Gradle?) that is based on Groovy build scripts which I believe DAllen commented about a while back (to use as the build system for Seam3?)

Yes, I think eventually Gradle and Gant will substitute both Ant and Maven. It is just a matter of time and Maven IMO will die first, because it is the one that will be less able to adapt (it was never designed to be adaptable, it was designed for everybody to adapt to it)

I really think that Java EE platform and tooling needs to be easy to use (the intention of EE5) as well as easy to learn.  Isn't this the case with the .NET platform and visual studio generally speaking?

Don't even get me started here... Java EE tooling is so bad in comparison... a very good technology wrapped in so much unnecessary difficulties... I just have no words...

As usual you have interesting/good points, however, we're off topic, and the topic moderator gods are getting angry.

I agree, this is forum not for discussing Ant and Maven... but I still think Ant is better and Maven should have been implemented as a set of Ant tasks... again, sorry for digressing, lets go back on topic.

I'm wondering, for example, how hot loose coupling and type safety are in the .NET and RoR space?  I agree that they are important goals/topics but just wondering how much momentum there is behind the movement?

Well, in .NET C# is type safe, and VB.NET can be configured to be typesafe or not. With LINQ, queries to the database, XML, the filesystem, an in memory object array or anything else can be done in a typesafe way... but for the next release (4.0) the hot new feature is dynamic behavior. RoR is based on Ruby, and AFAIK Ruby is not type safe at all. And well, much of the web is built with JavaScript IMO it is the most popular if invisible language right now, and it is also not typesafe...

I guess the future is in typesafe languages like Scala, with a syntax that gives you the convenience of a scripting lenguage with the strength of a strict typesafe language.

Or hybrid languages like C#, that leave type safety as a developer choice... I think Oracle should adopt Scala, buy JavaRebel, integrate them, and use the result to compete with C#... (and gradually deprecate Java as the main language for the JVM) but I don't think they will be that smart... :'(

I don't think type safety is really the main practical advantage of, say Weld over Seam. It's just that injection by type rather than name is a lot easier to not mess up. You're more likely to misspell the name of a bean than to confuse the types you're trying to inject.

In terms of cost, if your project overall requires less lines of code and third party stuff, it's a big win. So, I would approach the question of cost by saying: If we use JEE6, we don't have to write this XML configuration file, this startup class, include these Spring libraries, etc.

And yes, Maven is not a JSR but neither is Ant, Spring, Hibernate (well, sort of with JPA I guess). I think there should be a JSR/standard for a Java build tool as well as a JSR/standard for AOP.

Agreed, and I'll add one more area into the discussion: testing. Why are there no JSR's for either of these areas that affect every developer on a daily basis?

Ant and Maven both require very copious amounts of difficult-to-read and untype-safe XML configs. A type-safe, programmatic solution in Java would be great. Reusable builds with inheritance, polymorphism, etc.

How would one declare a dependency in a type-safe manner? I'm not saying it's not possible, I'm just curious what ideas are out there...