There is no arguing the fact that TheServerSide.com has historically been a strong advocate for the work of Rod Johnson and the Spring framework. The J2EE platform had its shortcoming, and Spring quickly became the most prominent and pervasive framework for easily building enterprise-ready applications, while at the same time, helping developers avoid many of the pitfalls of the old enterprise Java platform.

But J2EE represents the past, and Java EE 6 represents the future. Java EE 6 promises us the ability to go beyond frameworks. Frameworks like Spring are really just a bridge between the mistakes of the J2EE past and the success of the Java EE 6 future. Frameworks are out, and extensions to the Java EE 6 platform are in. Now is the time to start looking past Spring, and looking forward to Seam and Weld and CDI technologies.

And to start shifting into a world of extensions, and moving away from frameworks, the first step is porting your Spring applications to a Java EE 6 environment. To do so, a great place to start is by checking out this article from ocpsoft.com about doing a Spring to Java EE migration.

Spring to Java EE – A Migration Experience

JEE itself is a framework.

I tend to think of Java EE as the platform. And we built frameworks because the platform was weak.

Now the platform is strong, and what we are seeing is less need for a framework, and instead, the accomodation of extensions.

Perhaps a semantic argument/discussion, but I like the terminology. I see Java EE  and J2EE and Java ME and such as being more than just a framework.

But was there any "Age of Frameworks"? Except a few products...

The basic problem is that the new 'software world' of Java  has  been misusing words and jargons all along with very general and very special meanings for the same word!  Framework, Platform, Container, Application Server...the list is endless. The problem started when Java did the huge mistake of calling the Java RunTime System as  JVM - Java Virtual Machine.  Virtual Machine was  a terminology already  known in the 'old' world - Functional Equivalent of a Real Machine. Typically IBM had the well known VM/370 which had its own CPU, memory,  disks, tapes, readers and printers - all virtual!  VM indeed masked the real hardware and software behind. On the other hand, now, JVM was neither virtual nor a machine!

Other jargons were to follow soon... JVM was simply not enough for running real applications....Playing with applets in the beginning, Javaworld was a little slow to realize that commercially one needed some sort of Application Server (which runs under the base Operating System) .. Websphere and Weblogic and others followed...

Again we heard Java was not just a language but a platform.  When EJBs did not solve all the problems with persistence and transaction management, came the new Framewroks trying to reposition  the direction.  Even before they are in full use, now we hear that their age is over!

Old-timers like me had problems in understanding all these jargons. Every shortcoming in Java gave rise to some new frameworks or technology implementations (= products).  It  was as if, we were looking at  some sort of 'shortcoming-driven' technology and products! 

Spring complained about all the EJB related xmls and configurations, but used its own configuration xml files initially before  switching over to annotations only recently.

Marketing interests of some new products always played a role in the spread of these technologies... For me, I considered all of them  as  INCOMPLETE products failing to address a minimum but complete subset of  features which could be used to make an average application for an average customer.  Competing products claimed supports and plug-ins  for each other to fill the holes.

It is disastrous to see that even after 15 years, we still haven't come to an acceptable miminum model for a web application. We still don't have a standard way of accessing databases from Java.  Irrespective of platforms and frameworks, the the basic idea of COMMERCIAL dataprocessing is to store and retrieve data in some way. Databases are needed to store any data.  Database access came as an after-thought to Javaworld and now trying tio rectify that mistake by inventing ORM and related products. There is also talk about NOSQL databases.

All these need not be this complicated at all! Complexity should be hidden within the tool - but instead, we see tools complicating the whole process of application development even further!

Dear Gopi,

I appreciate your compelling writing and I am especially found of that "...as if, we were looking at  some sort of 'shortcoming-driven' technology and products!"

But I think that there is a missing ingredient in your theory and that is "Open Source". Open source in my view is what makes us try to come up with something better than the latest "shortcomed technology and products" and eventually creste new "shortcomed technology and products".

Open source stuff is 99% coded using java.

Open source brings excellence to code, in my opinion, and the tools that we use today, mey all be "shortcomed technology and products", but they are eons ahead of the tools we had 20 years ago. I am thinking of eclipse IDE, but there are meny others. And they are free!!!

At this point I am completely evangelised into the spring framework stack. Nobody is going to make move away from it in the near future.... But then again, I might change my mind if the "shortcomed holy-grail" arrives next!

 

Cheers.

Carlos

The lines can be blurry. Is Java SE a framework? Is Swing a framework? Is PHP a framework? Is the Servlet API a framework? In my opinion, historically a framework was more akin to a skeleton app. Something that you could actually run and had some default stuff like a main window with a menu bar with an about dialog. Nowadays the term framework seems pretty much interchangeable with library, api and platform. I think the title of this opinion article should have been that for Java the of external frameworks is over. Java used to be a more foundational platform, really requiring external frameworks to get stuff done. With Java EE 6 this is no longer the case. You still use third party extensions and component libraries, but complete external frameworks are not required anymore.

The fundamental problem here is that its in JEE and will probably require a container to run making Junit testing difficult and putting container dependecies in jars that should not need it. When is DI going to be a core part of afava

 

Ah, see, that's where Arquillian from JBoss comes in:

Now it *is* just as simple as writing a JUnit test :)

http://jboss.org/arquillian

And for JPA-

http://community.jboss.org/en/arquillian/blog/2010/10/04/the-perfect-recipe-for-testing-jpa-2-revisited

Just a little more config :)

 

Lincoln...Great article! Nice to see you posting on TSS.

Lincoln...Great article! Nice to see you posting on TSS.

 

Lincoln is a very good writer. I always enjoy reading his articles.

Part of the problem of old world J2EE was that there weren't a lot of gifted people writing very good articles about the technology. With Java EE this has improved massively with people such as Reza Rahman, Adam Bien and Lincoln Baxter.

 

Hi Lincoln,

Thanks for the nice article. I must say that in comparison to Spring, CDI, from the outset, does appear to be more complicated. I have tried to list my doubts here. I would be greatful if you could clarify.

Thanks - Vinay

1) In Spring in addition to Scope, we also have the notion of Singleton and Prototype. Beans are defined to be deployed in one of two modes: singleton or non-singleton. (The latter is also called a prototype). When a bean is a singleton, only one shared instance of the bean will be managed. Having singletons, helps avoid creating service objects for every Request.

a) Is there a parallel in CDI for Singletons, or, is the Application Scope a means to achieve the same objective as Singleton?

b) Are there any difficulties in CDI to get a reference to a singleton bean, something equivalent of :

MyBean bean = ApplicationContext.getBean(“mySingletonBean”);

(as one frequently needs reference to Singleton services from different parts of code, without having to pass the reference as parameter)

c) Are Bean names (named references as in Spring) supported in CDI?

 

2) In the example:

@ApplicationScoped
public class AuthorizationBean
{
@Inject
private UserCredentialsBean credentials;
}

You mentioned: "CDI will actually find the correct @SessionScoped UserCredentialsBean, and use that when performing operations on the parent bean, automatically making sure that the right objects are used. Sweet!"

How would it work? There is a single application scoped AuthorizationBean. Multiple clients can access it from multiple methods. Aftet an inject of UserCredentialsBeanB is done by thread B (HTTP Request), a thread A may  be able to access UserCredentialsBeanB (from the application scoped AuthorizationBean) instead of UserCredentialsBeanA. Can you please help me understand how this works.

3) Is it possible to have Servlet based (i.e non EJB) beans (Request Scope) in which a EntityManager is injected and managed automatically. An example of this would be nice.

4) You mentioned:

"EJB 3.1 today is miles apart from what it once was, can be used standalone in WARs, and requires just one annotation to configure"

It would be nice to have details on this.

5) For my Swing based GUI applications, is it possible to use CDI (using its core libraries in a non J2EE container environment).

 

@Vina Son

1) a) Yes. In a WAR @ApplicationScoped == @Singleton, but there is also a @Singleton scope that can be used (mostly beneficial in Java SE environments.) And @Dependent == @Prototype (take a look at my table.)

http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e1921

 

b) You can also get beans by name in CDI, but it is discouraged. No trouble though.

c) Haven't looked at that yet. Not sure.

2) CDI uses dynamic-proxies to wrap "place-holder instances of beans" when the bean is accessed, CDI will go out and find the current instance of the bean and use that instead. Therefore, the current instance is always the one that is used in execution.

3) Yes, but it's a good deal of work - this is where Seam Persistence comes in. Just like Spring (you could argue) it extends Java EE and takes care of the dirty work for you. It's still unreleased: http://seamframework.org/Seam3/PersistenceModule

4) I describe this thoroughly in my article.

5) Yes, in fact I am using this on my main project at JBoss: http://seamframework.org/Documentation/SeamForge
http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e5571

I hope this is informative :)

Frameworks are out, and extensions to the Java EE 6 platform are in. Now is the time to start looking past Spring, and looking forward to Seam and Weld and CDI technologies.

<!-- @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } -->

I think that there will always be politics. Today we’re almost 10 months after JavaEE 6 release. Are there any widely-used CDI extensions? And I’m not talking about Seam 3 alpha releases. I don’t personally know Seam, but I respect it and treat it like an alternative to Spring products. Both products have been created to make Java Enterprise (not JavaEE in particular) programming easier. They both address security, flows and other aspects not directly covered in JavaEE.

 

But let’s leave Seam now – until Gavin King reveals what his working on :)

 

So admit it – whenever there’s „Spring vs. JavaEE 6” debate there’s really „Spring vs. soon-to-be-popular Weld extensions” debate. Spring wins because it’s ubiquitous now, it’s became such dependency as „java.util” or „java.io” - just another friendly import statement.

 

Enterprise value stability and predictability. As Jurgen Holler said – the haven’t changed basic principles in Spring Framework since pre 1.0 release. I don’t think we can say this about JavaEE.

 

Of course – JavaEE 6 is good – is better than ever before. CDI is clean, but it has to pass one more test not included in any TCK – the test of time. The test hasn’t even started yet – there’s only Glassfish v3 (the RI) and TMAX JEUS (the what?) - http://java.sun.com/javaee/overview/compatibility.jsp.

 

So for Enterprise it doesn’t matter whether you can click out „Guess the number” game or „Order – line items” use case. It doesn’t matter whether the deployment time of WAR without any non-JavaEE6 dependencies deploys in 2 or 1 second. What really matters is whether to product will satisfy business requirements.

I must admit: forget the old glorius Spring Framework!

I think the most important J2EE feature is deployment: you can deploy in a modular way:

you can split your application (.war) in more than one modules (.jar) and deploy separately, then deploy your .war that link all together and your web app is complete!

All modules speak together with the ejb's local transport protocol (not remote!!!), very easy and fast!

..Fast for two reasons: 1. you can debug and redeploy single modules ; 2. the internal ejb communication is local function call, very fast.

On the Spring side, instead, you can also split your application in more than one module (at design and compile time), but, at the very end, you have to deploy only one big .war into tomcat webapps/ directory; that is not acceptable in a common multi-programmers environment.

Of course , with Spring Remote you can split your single .war in more than one .war and make each .war communicate with one of the numerous spring remote protocols (rmi, corba, hessian, SOAP), but, IMHO, this is not the best solution.

Bye.

 

Java is a platform, J2EE is a framework. Saying the age of frameworks is over is like saying the age of the developer has passed.

Java EE has promised great things, none of which have come to bear much fruit. Be it breaking down the application for dev teams or the container scalability, Hibernate and Spring have done far more in terms of progress than Java EE.

There are many enterprise apps built on java without EE, and many built without java at all. So why would anyone go through the pains of XML hell, IDE management, container testing nightmares, and heavyweight EE application servers for these features?

The cost of building apps under Java EE isn't justified. I wouldn't spend my money on it, but then again, it's not my money. :)

I quite agree.

To me, a 'framework' means that you don't have to write the basics of an enterprise application from scratch, and provides useful services and ways of accessing resources. Spring is a framework, and so is JEE, and all this talk of 'extensions' and CDI don't alter the fact. If I write components, configure them using XML or annotations, and then something creates and runs them for me, I feel I'm using a framework.

I went and read the TFA, and it basically seems to be saying "In Spring you do X, but in JEE 6 you do Y", and there's a pretty clear connection between the two.

Arquillian is *not* as trivial as JUnit + Spring. The front page of the site alone makes that clear. I should *NEVER* manage containers to execute a test. The whole Spring vs. JEE garbage makes me glad to become a .NET developer. I am embarrased to even admit it, but it's gotten old, guys. Just use the dang tools and stop debating. If you're not delivering business value, we just plain don't want you around anymore.

Couldn't have said that better myself! Congrats! :)

I got this in my email, and thought it was an article from "The Onion" not TheServerSide.

While Java EE 6 is headed in the right direction, Spring 3 is superior in my opinion. That's right, it's my opinion, just like Java EE 6 making Spring unnecessary is your opinion; not fact.

At the end of the day, each framework has its place and people who find it to be the right tool for them to Get Things Done.

I'm all for Java EE trying to "make things right", and sure, post about why Java EE is an attractive solution. But forget about fell swoop statements such as "The Age of Frameworks is Over". That's not the right approach, and you are not gaining any respect with this kind of illusion.

I've read your posts over time and please know that I have nothing but respect for you. In other words, no disrespect intended. But you can't write a title like this and not expect any reaction, right?

Cheers,

Freddy

I have used Spring for years without any problems. In my view, Java EE is catching up to Spring in many ways. While it is catching up, Spring is moving forward more and more. Spring works in Jboss, Websphere, Weblogic, Tomcat, Jetty without problems. i stopped using any Java EE specific technology in favor of Spring many years ago and I have never looked back. Development is easier, testing and deployment easier and faster and customers are much happier with Spring. With such influence over Java EE, now we need the Spring guys to influence Java SE and put out their own JVM that is modular and with a more active development cycle.

With such influence over Java EE, now we need the Spring guys to influence Java SE and put out their own JVM that is modular and with a more active development cycle.

I agree in 100%! Now, when no one knows what JCP will become under Oracle's leadership, VMWare+Springsource (+ReadHat/JBoss too) should create better and pragmatic vision of Java (Standard+Enterprise). Putting more and more APIs under javax.* without checking how it will help programmers and customers in practice is not a part of this vision.

There is much going on beyond what JCP committee decide to put into JavaEE.next. There's Terracota, VMWare, Apache (with many interesting projects related to OpenSocial, "NoSQL", cloud computing), JRebel. Of course from theorethical point of view it's nice to work on JavaEE specifications and RIs, but there's one good description of such activity - Big Upfront Design. JavaEE is just too slow and too late (both JavaEE 5 and 6) to be serious from practical point of view. I (personally) can't afford to wait for stable JBoss and RIs and prefer using what's best now. And Spring gives me all this once a month, not once a 2 years...

I have used Spring for years without any problems. In my view, Java EE is catching up to Spring in many ways.

I have quite a different experience. I have used Java EE for years (ever since Java EE 5 came out) without any problems. In my personal view, Java EE has far surpassed Spring, which always felt as a patched together thing instead of a coherent whole. Spring seems to be resting too much on their laurels, and keep thinking they invented DI and therefor will be the leading platform forever. 

Now it's Spring who's limbing behind. The entire smart defaults approach and simple annotation based approach was started by Java EE. Now Spring is following that and moves away from XML too, but Java EE is already one step ahead again with type safe injection. I also love the rich ecosphere of UI component libraries that exist for Java EE. Don't see that for Spring really...

While it is catching up, Spring is moving forward more and more. Spring works in Jboss, Websphere, Weblogic, Tomcat, Jetty without problems.

And Java EE apps work with JBoss AS, Glassfish, Geronimo, Websphere, Weblogic etc. Better yet, the Java EE implementations work on the Sun/Oracle JVN, the Jrockit JVM, the IBM JVM, the Apple JVM, etc.

Really, what is your point?

As Adam Bien pointed out some time ago, your argument "Spring works on JBoss" is actually a little silly. You would most likely be by-passing a lot of stuff, since you want to include everything in your war. JBoss would be very little more than a relatively dumb Servlet container in that case, which would be a total waste of any service contracts you might have in place.

If you want to use Spring, you might just as well use a dedicated Spring application server, which makes a lot more sense. Then you'll more clearly see that there really is only one Spring implementation vs many implementations for Java EE.

 

i stopped using any Java EE specific technology in favor of Spring many years ago and I have never looked back. Development is easier, testing and deployment easier and faster and customers are much happier with Spring.

If that is the case for you, I'm happy for you and by all means please keep using Spring. My own experience is exactly the other way around. We completely stopped using Spring in favor of Java EE (JBoss in our case) and we never really looked back. Our development is really much easier and since we deploy tiny EAR files our building and shipping of code is much faster. Our customers are much happier with us now we're fully using Java EE than they were ever with us when we were still a mixed Spring shop.

With such influence over Java EE, now we need the Spring guys to influence Java SE and put out their own JVM that is modular and with a more active development cycle.

Here I agree with you. Next to their own application server (Tc Server), let them make their own JVM and then thereafter let them use their own JVM language. That way it will be completely clear that Spring is an alternative platform just like .NET is an alternative platform.

It would still be nice to compare Java EE and Spring then (and .NET I think) and they will probably continue to influence each other, but Spring fans can stop their campaign that it is somehow 'natural' that you should be using Spring if you're into enterprise Java. Spring would with simply be their own complete platform and Java would simply be Java :P

I feel the same.

Can't wait to find out  which direction open source technologies like spring is going to java and .net technology.

Hi Cameron,  this post doesn't really seem like a news post but rather an editorial/opinion piece.  It seems to cross journalistic boundaries to portray your opinion here as a fact vs. identifying it as an opinion piece.

Back when I was reporting on all things Spring and Rod Johnson here at TSS, we never said it was better than J2EE, we only reported on what was going on in the community and the community said it was. :)

Floyd

Back when I was reporting on all things Spring and Rod Johnson here at TSS, we never said it was better than J2EE, we only reported on what was going on in the community and the community said it was. :)

Maybe not you personally, but I remember a lot of Spring fanatics always trying to get an image across as if Java EE was long died and buried and 'faking' surprise with every little tidbit of Java EE news: "Huh? EJB was declared dead long time, how is this still relevant?" and "Java EE is bad since it's an application server! And Java EE is bad since it's a container", and so on and so forth.

It could well be that these were all lone developers acting on their own, but I can't escape the thought there was more than a little 'guidance' from the Spring camp here. Okay, maybe I'm paranoid, but I always felt the talks of especially Rod pushed developers into thinking such kinds of thoughts. Some developers even seemed genuinely surprised that Java EE and EJB even still existed. After listening to some talks of Rod it was not totally surprising where those thoughts came from, since he always seemed to talk about Java EE (J2EE) as that technology from 2002/2003.

Maybe not you personally, but I remember a lot of Spring fanatics ...

The point is (as Floyd already pointed out), there is a difference between an editorial comment saying something as fact, and letting the "community" express what it thinks (whether that community is full of Spring zealots, JBoss zealots, or whatever). Far better to give the readershipp something intelligent and based in reality to read and provoke their opinions ... i.e the difference between impose views on people, and let people express their views. Or viewed another way, the difference between "this is the software that you should use" rather than "there are these alternatives and you can decide which you like best".

Maybe this is the way of things at TSS now ...

Hi Cameron,  this post doesn't really seem like a news post but rather an editorial/opinion piece.  It seems to cross journalistic boundaries to portray your opinion here as a fact vs. identifying it as an opinion piece.

Back when I was reporting on all things Spring and Rod Johnson here at TSS, we never said it was better than J2EE, we only reported on what was going on in the community and the community said it was. :)

Floyd

Lol, Floyd.  You can't be serious... Weren't you around for JBoss: a modern day plague? back in 2003?  In your day, driving traffic was much more important than crossing journalistic boundaries, and, many times, at jboss's expense.

IMO, theserverside needs to get back to its roots and publish *MORE* opinion, flaim baiting, front page articles.  That's what made it fun.  Being the Java Tabloid rather than a wannabe infoq.com will make it infinitely more enjoyable to read.

Hi Cameron,  this post doesn't really seem like a news post but rather an editorial/opinion piece.  It seems to cross journalistic boundaries to portray your opinion here as a fact vs. identifying it as an opinion piece.

Back when I was reporting on all things Spring and Rod Johnson here at TSS, we never said it was better than J2EE, we only reported on what was going on in the community and the community said it was. :)

Floyd

Lol, Floyd.  You can't be serious... Weren't you around for JBoss: a modern day plague? back in 2003?  In your day, driving traffic was much more important than crossing journalistic boundaries, and, many times, at jboss's expense.

IMO, theserverside needs to get back to its roots and publish MORE opinion, flaim baiting, front page articles.  That's what made it fun.  Being the Java Tabloid rather than a wannabe infoq.com will make it infinitely more enjoyable to read.

 

Bill Burke and his breast milk is right.  This place is like a tree falling in Siberia without flamebaiting articles.

Speaking of Bill Burke's breast milk, can TSS hire Hani to do some guest flame spots?

 

Great post Lincoln. I had loved your piece of work, Pretty faces on JSF.

No need.

Yes, JEE 6 is better than J2EE 4. Glassfish 3 is better than glassfish 2.

No need to change the framework for the shake of changing the framework. Fortunately springframework is bigger than DI.  If you are into cloud computing and osgi you will know what i mean.  No need to use EJB if you dont' want to. Stop beliving EJB will make your application more performant.

Open source frameworks are the driving force behind JEE standard. You can always bet on these and new framework to  create new  technology. If you can use JPA api use it, but if you need to use hibernate api go ahead and use it.

Well said.

People need to realise that JEE is owned by Oracle and the Java standard API wont buy you much.
Another powefull feature of Spring most fail to mention is its support for Proxies and AOP.

As for JEE dependency injection, it is a limited implementation (it almost feels like a kids toy).
Can anyone comment on http://www.tsolak.com/?p=59 and prove me wrong and show that JEE or any annotation based DI is actually a worthwhile feature?  

 

People need to realise that JEE is owned by Oracle and the Java standard API wont buy you much.

 

I usually try to stay out of the flame wars.. they are quite a laugh..    But I have to ask.   So Oracle owns JEE..   And Spring is owned by?    yes a single company..   what's the difference?  They both are in it to make money.    neither of them are a charity..   

 

Same for me. Personally I try to avoid using or lokcing myself with anything produced by Oracle (except databases).
I have seen too many times Oracle helping companies getting rid of their cash and producing nothing. 
Again its my opinion, anyone else is free to try them.

<blockquote>I hate JSF. It's very very slow and buggy (I only used SEAM 2.0.2 + IceFaces). I would prefer wicket, gwt and ZK. Therefore, CDI does not offer much value to me.</blockquote>

CDI was designed to integrate with other web frameworks. AFAIK, there is *already* CDI support available for Wicket and GWT (as part of the Seam3 project), and ZK (implemented by the ZK folks).


<blockquote>Legacy Project: I can migrate any existing applications int spring step by step easily. SEAM/CDI? no way  It's all or nothing.</blockquote>

Why? I don't understand this comment at all.

<blockquote>As for JEE dependency injection, it is a limited implementation (it almost feels like a kids toy).
Can anyone comment on http://www.tsolak.com/?p=59 and prove me wrong and show that JEE or any annotation based DI is actually a worthwhile feature? </blockquote>

The reason your post is "wrong" is that you missed a feature of CDI: @Alternative and @Alternative stereotypes, which allow enablement/disablement of a component in the beans.xml deployment descriptor. I understand that if you didn't notice this feature, then CDI would indeed look like a "toy".

http://docs.jboss.org/weld/reference/1.1.0.Beta1/en-US/html/beanscdi.html#d0e711
http://docs.jboss.org/weld/reference/1.1.0.Beta1/en-US/html/injection.html#alternatives
http://docs.jboss.org/weld/reference/1.1.0.Beta1/en-US/html/specialization.html#alternativestereotypes

Gavin, I have already commented on @Alternative feature you metnioned, showing some of the issues with it.

Check the link to my blog to see the comment.

- It's a huge investment for many company to upgrade their production application server. What's the ROI for upgrading the app server just for converting my app from Spring to JEE when i can achieve the result with both frameworks? - There are loads of application that doesn't run inside a container, e.g. Swing, or simple "non-webapp" java program (e.g. Main()). As a Architect, I would like my organization to use a unify programming model. JEE doesn't have an answer for me. Sorry, I don't need stateful bean in my batch program. - Conversion/Lazy Loading Exception: Spring webflow can solve this long time ago. - I hate JSF. It's very very slow and buggy (I only used SEAM 2.0.2 + IceFaces). I would prefer wicket, gwt and ZK. Therefore, CDI does not offer much value to me - JPA: the criteria API is just an nightmare compare to hibernate. For Database centric application, i prefer iBatis. For multiple data source, I prefer JDO. - What about the rest? In addition to what's JEE spec cover, I also need LDAP, batch, osgi, work flow, EAI alike integration, "web service security", drools integration ... etc. JEE can't help all these for me. I want an unify programming model, so that my boys can get started quickly - JTA: yes, i would go for ejb if i need to manage distributed txn, i can't be bother to setup things JTOM in spring. Having said that, I tried to avoid this as much as I can. I prefer to use compensation rather that distributed txn, because it's stupid to lock multiple resources at the same time. therefore, it's not relevant to me. - Legacy Project: I can migrate any existing applications int spring step by step easily. SEAM/CDI? no way !!! It's all or nothing

• It's a huge investment for many company to upgrade their production application server. What's the ROI for upgrading the app server just for converting my app from Spring to JEE when i can achieve the result with both frameworks?

• There are loads of application that doesn't run inside a container, e.g. Swing, or simple "non-webapp" java program (e.g. Main()). As a Architect, I would like my organization to use a unify programming model. JEE doesn't have an answer for me. Sorry, I don't need stateful bean in my batch program.

JEE isn't a client-side technology, yet, I believe Weld should be usable at an injection container on the client-side.  But, as Reza has said, JEE and Spring compliment each other.  I'm sure you'd find Servlets, JSP, JPA, JMS, JAX-RS, JTA, and even JCA useful in a Spring deployment.

IMO, you've fallen for Rod Johnson's Long-Con, that JEE == EJB (now CDI too) and that Spring == Java EE.  Spring has always been dependent on Java EE technologies and underlying infrastructure.

Why would you want to migrate an existing Spring app?  You wouldn't.  It's wasted hours from a technical perspective.  From a business perspective though, Spring == vendor lockin.  They charge for legacy patches and updates.

 

• Conversion/Lazy Loading Exception: Spring webflow can solve this long time ago.

Yeah, so has Seam (CDI's predecessor).

• I hate JSF. It's very very slow and buggy (I only used SEAM 2.0.2 + IceFaces). I would prefer wicket, gwt and ZK. Therefore, CDI does not offer much value to me

I know Seam team has always wanted to integrate with other web frameworks.  They do have integration with GWT.  So while Java EE may not define GWT hooks into CDI, I'm sure frameworks like Weld will.

• JPA: the criteria API is just an nightmare compare to hibernate. For Database centric application, i prefer iBatis. For multiple data source, I prefer JDO.

Where you have you been?  JDO is dead man...  If you don't like JPA's criteria API, than just use Hibernates.  What's the big deal?  Doesn't stop you from using other JPA interfaces.  Again, its the vendor-lockin thing.  I do like iBatis too though.

• What about the rest? In addition to what's JEE spec cover, I also need LDAP, batch, osgi, work flow, EAI alike integration, "web service security", drools integration ... etc. JEE can't help all these for me. I want an unify programming model, so that my boys can get started quickly

A unified programming model across all of these components is a compelling argument and a goal Gavin always had when creating Seam then bringing Seam to the JCP through CDI.  You can use JCA for EAI-like integration.  Web service security is covered by the WS-* specs.  Workflow and rules, are not part of Java EE.  But this hasn't stopped vendors from having their own unified programming model.  For us it has been Seam, the future, its CDI.  I'm sure other vendors (besides Spring) will follow suit.

 

 

• JTA: yes, i would go for ejb if i need to manage distributed txn, i can't be bother to setup things JTOM in spring. Having said that, I tried to avoid this as much as I can. I prefer to use compensation rather that distributed txn, because it's stupid to lock multiple resources at the same time. therefore, it's not relevant to me.

So, what happens if you have to manage multiple resources within your compensating transactions?  Even with an application architected for compensation and an avoidance of DTX, you're still gonna have some requirement for atomicity.

• Legacy Project: I can migrate any existing applications int spring step by step easily. SEAM/CDI? no way It's all or nothing

As I said before, no reason other than vendor lock-in to migrate your spring apps.  Just as there is no technical reason to migrate your (very) old EE apps to Spring.

Where you have you been?  JDO is dead man...  If you don't like JPA's criteria API, than just use Hibernates.

Maybe the respondent likes the developments that are present in JDO2.1, JDO2.2, and JDO3.0, and indeed what will be in JDO3.1; new definition of "dead" perhaps :-). Maybe the respondent likes other typesafe query API's like QueryDSL for example, offering a significantly improved user experience over JPA's "Criteria". Maybe just maybe you ought to let him decide for himself what technologies he likes to use rather than issue decrees. You know, choice is a good thing.

 

• It's a huge investment for many company to upgrade their production application server. What's the ROI for upgrading the app server just for converting my app from Spring to JEE when i can achieve the result with both frameworks?

I think there are no reasons to change old projects sources, even if they have some bugs.

thus, I think there are no reasons to change Spring based apps to EJB based, and viceversa.

• There are loads of application that doesn't run inside a container, e.g. Swing, or simple "non-webapp" java program (e.g. Main()). As a Architect, I would like my organization to use a unify programming model. JEE doesn't have an answer for me. Sorry, I don't need stateful bean in my batch program.

With the new J2EE6 specs you can! you can  create an  Embedded Container and use all your ejbs: Glassfish3 supports this.

• Conversion/Lazy Loading Exception: Spring webflow can solve this long time ago.

Yes, Spring Web Flow is great, even if it is not needed in many medium/little web apps.

• I hate JSF. It's very very slow and buggy (I only used SEAM 2.0.2 + IceFaces). I would prefer wicket, gwt and ZK. Therefore, CDI does not offer much value to me

Me too! In fact I prefer Zk and Vaadin, but they are all usable inside a EJB container without strong efforts (both can used backed ejb objects)

• JPA: the criteria API is just an nightmare compare to hibernate. For Database centric application, i prefer iBatis. For multiple data source, I prefer JDO.

JPA is ok, it is enough for the 90 % of your needs, but, of course, Hibernate API is better.

JDO & iBatis are preistoric!!!

• What about the rest? In addition to what's JEE spec cover, I also need LDAP, batch, osgi, work flow, EAI alike integration, "web service security", drools integration ... etc. JEE can't help all these for me. I want an unify programming model, so that my boys can get started quickly

All these technologies can be used inside a j2ee container without efforts.

I cannot understand the problem!

Of course, Spring is great, thus surely you should have no problem to integrate all that technologies into a spring container, but this not involves that j2ee is difficult to use!

 

Cameron,

Personally, I think Java EE and Spring are both great options and I hope Spring remains an active force of innovation going forward. As I've said at JavaOne (http://blogs.sun.com/alexismp/entry/javaone_2010_java_ee_6), Java EE needs Spring to be healthy and vibrant just as Spring benefits from the innovations in Java EE...

I do agree portable CDI extensions (such as the ones in Seam 3) as well as Java EE 6, Java EE 7 are important things developers should start paying serious attention to if they are not doing that already...

Cheers,

Reza

Standards like Java EE, aren't supposed to be bleeding edge.  They are supposed to be behind the community in features and architecture.  For every 1 company that wants to take a chance on new technologies, there are 10 more conservative companies that want something mature.  When standards work, vendors and open source projects innovate first, then bring their innovations to a standards body so that the industry can consolidate.  Conservative companies eventually get innovations that have been baked in the community and because there is a standard, haven multiple choices from a vendor perspective (IMO, this choice is also important even from an open source perspective).

Standards allow an industry to "take a breather".  To draw a line in the sand to say, "This is what we agree things should look like going forward".  Good standards allow for the industry to build upon past experiences rather than re-inventing itself every 5 years.

That being said, one of the most important additions to Java EE 6 is both pluggability and independence.  CDI and Servlet have added nice SPIs to make things easier for the community to innovate on their own.  You also see a number of specs that are now allowed to be standalone: i.e. EJB and JAX-RS.  The problem with Java EE is that in the past it never provided the portable SPIs so that framework developers could add their innovations on top of Java EE.

For every 1 company that wants to take a chance on new technologies, there are 10 more conservative companies that want something mature.  [...]

Standards allow an industry to "take a breather".  To draw a line in the sand to say, "This is what we agree things should look like going forward".  Good standards allow for the industry to build upon past experiences rather than re-inventing itself every 5 years.

That being said, one of the most important additions to Java EE 6 is both pluggability and independence.  CDI and Servlet have added nice SPIs to make things easier for the community to innovate on their own.  You also see a number of specs that are now allowed to be standalone: i.e. EJB and JAX-RS.  The problem with Java EE is that in the past it never provided the portable SPIs so that framework developers could add their innovations on top of Java EE.

These are correct statements but dangerous for JavaEE 6 advocates :) What is "mature"? JavaEE 6 with its revolutionary (and good) CDI or Spring which from the architectural point of view hasn't changed since beginning? IMO "re-inventing itself" is rather an attribute of JavaEE, not of Spring (maybe with a little exception of Spring Security :).

So if we're talking about conservative decision-makers I don't think they would choose GFv3 or TMAX JEUS. I've been working for customers who've decided not to migrate from WebSphere 6 to 7 after painful experiences from 5 to 6 migration (all issues related to "standard" J2EE 1.3 - 1.4). With Spring the application I've been developing migrated from Spring 1.0.2 to Spring 3.0.4 without any problems.

JavaEE' being a standard is a little behind (being a standard) so why all the posts titled "end of frameworks"? Let's see in 2 years - JavaEE6 will finally gain momentum, there should be many CDI extensions (also these non-Seam3 extensions), JavaEE7 will be ready or in EDR or PFD state, but remember - these 2 years will also be the time when Spring/Terracota/others will evolve :)

regards

Grzegorz Grzybek

I have to say your statement on Java EE 6 gaining what you regard as momentum does not seem accurate/balanced at all.

If you are talking about WebSphere and WebLogic customers, there might be some truth to the statement (although you can use CDI centric technologies in these containers as well as many of the Java EE 6 pluggable APIs and I have done upgrade project for these containers too; upgrading from WebSphere 6 to 7 is quite a different experience from upgrading from 5 to 6 because we are talking again about J2EE and not Java EE here). We already have people using our implementation even though Resin isn't even Java EE 6 certified yet (will be in the next few months). There are similarly many GlassFish and JBoss customers adopting Java EE.

Frankly, as far as Spring, etc evolving, I wish I could say that has been true of the past few years :-). I do hope that changes going forward for Spring. The industry can always use good innovation no matter where it might come from...

Cheers,

Reza

I have to say your statement on Java EE 6 gaining what you regard as momentum does not seem accurate/balanced at all.

You're right - it's gaining momentum for some time now. I rather meant "enterprise adoption after final releases of JBoss 6, WebSphere 8, ...".

And about the innovation - Spring's DI container and its architectural concepts are stable, innovation is taking place "above" - in Spring Integration (JBI is not part of JavaEE), Spring Security (JavaEE doesn't describe security mechanisms which are required in practice - e.g. complex, multi LDAP scenarios). Look at git.springsource.org - there's a lot going on (e.g. Spring Social).

I value your opinions Reza, I'm just continuously amazed by posts saying "end of frameworks", "vanila Javav EE" and "Spring has fulfilled its role and it has to go".

regards

Bill,

I agree with you 100%. EJB 1 and 2 is what happens when standardization gets too far ahead of actual implementation. One of the value prositions of standardization is to not treat adopters as alpha and beta testers for ideas...

That being said, there is obviously a need for innovation via standrization too - EJB 3, CDI, JAX-RS, etc are all good examples of stricking that balance...

Cheers,

Reza

Well played Mr McKenzie, well played.

IMHO,  J2EE6 is now a little better than Spring!

The overtaking on Spring was possible because of the wrong investment that Spring Source inc. had made on their dm-server.

The problem is all in this point: they have invested many time (and men) to work on an Application Server (dm-server) that has had no success!

Thus now, we have the following scenario:

1.On one hand, we have a robust and easy to use DJ framework (EJB) with a robust and wide used application server (GlassfishV3, Jboss...);

2.On the other hand we have a robust and easy to use DJ framework (Spring V3) without any  comfortable application server! IMHO TC server is only Tomcat + instrumentation!!it is not a real application server!

The problem (about Spring) is the lack of an appropriate (and comfortable) application server for Spring applications!

Now, the history goes on, and the Eclipse community is working hard on Virgo (the successor of dm-server), and...how will it finish?

If they will be able to delivery an optimum product, then Spring will have a new "momentum"; otherwise I think that there will be no a new overtaking on J2EE!

Bye

 

 

 

michele: "The problem (about Spring) is the lack of an appropriate (and comfortable) application server for Spring applications!" You say bug, I say feature. The fact that virtually *every* application server is appropriate and comfortable for Spring applications is one of the major reasons I like to use it. It's only when the application server vendors try to force JEE down everyone's throat and make classpath customization a pain that we begin to have any discomfort whatsoever.

You say bug, I say feature. The fact that virtually every application server is appropriate and comfortable for Spring applications is one of the major reasons I like to use it.

I hear what you're saying, but in my personal opinion it's debatable how useful that really is. With such a setup (a single war that deploys to everything), you're basically only using the application server to pipe HTTP requests to it. What's the entire point of deploying to an application server in such case?

Why not also just embed Jetty in the your app, and then you can not only deploy to every application server but also to every JVM.

You can even take this one step further and include the JVM for a series of popular platform. Then you can not only deploy to every application server and every JVM but also to every OS.

The final step would be to also include a (stripped down) OS with your 'application'. Then you can not only deploy to every application server and every JVM and every OS, but also to every computer.

Of course, I'm greatly exaggerating, but just trying to get the point across that including everything with your application sometimes might have benefits but is also a little debatable.

 

 

 

It's only when the application server vendors try to force JEE down everyone's throat and make classpath customization a pain that we begin to have any discomfort whatsoever.

It's only when the application server vendors try to force JEE down everyone's throat

Don't know about you, but I never had any threatening letters from JBoss or Apache that I had to use Java EE because otherwise... uhm... yeah, otherwise what?

How come this same Cameroon who recently has been writing articles and tutorials on Guice all of a sudden thinks the Age of frameworks is over? I smell something fishy here.

Personally, I think the whole motive behind this provoking title is to generate high responses to show to advertisers that Therserverside still has a high number of active members. Members with vulnerable eyeballs he can always torture with those popup ads. Looking at the past few weeks, it's been boring and quite here so for me I can understand this action from Cameroon.

I can imagine Cameroon is now sitting in his nice and soft sofa, with beer in his hand looking at the responses this post is generating and laughing and saying "Mission accomplished". Congratulations, man.

Jan

Jan,

You may be right.

By the way, how come you didn't somehow find a way to work into your comment that Tapestry is long dead and that nobody in their right mind should even consider using it? I'm disappointed. I love your (dis)passion about Tapestry; I feel the same way about JSF.

;-)

Jan,

You may be right.

By the way, how come you didn't somehow find a way to work into your comment that Tapestry is long dead and that nobody in their right mind should even consider using it? I'm disappointed. I love your (dis)passion about Tapestry; I feel the same way about JSF.

;-)

Freddy,

I hope with this message you're not aiming to turn this post into a Tapestry vs other frameworks. I have no time and effort to comment on a framework (Tapestry) whose founder (Mr. Ship) has given up on it and is currently on payroll at a company. Howard is currently  working on non-Java projects. His number 2 man, Jesse Kuhnert has left Tapestry for good. Tapestry is an over-engineerd piece of Framework that is good for nothing. Their mailing list is filled with a few people using Tapestry on hobby projects or are students playing. For a very long time no serious company has use Tapestry on a serious project. Tapestry is a dead horse. I won't waste my time beating a dead horse.

Jan

I am not sure when and how the J2EE team will learn from the lessons of the past. I see the current JEE framework more clutter and messier than the past. One thing that I liked though in JEE 6 is the seperation of configuration files for different tiers and the fragmented deployment model and out of the box Rest support.

But the thing that I don't understand is why we have to over enginnered some thing that is for no use for 90% of the time. Let me tell you this the only 3 things that 90% of the developers care from the JEE is Servlet, JSP and now the REST support. Touting CDI, JSF, Webbeans, EJB, Spring and their impact is just for the vendors who have vested interest in these technologies. I hope now since Java is in the hand of Oracle they will stop vendors with the iron fist who abused JEE to make it a mess for their own benefits.

 

Has JEE already become the underdog?

 

Does anybody remember why Spring became so popular and successful? Because I do.

 

Here’s the story….

In the beginning the SUN created J2EE and we looked on in awe and we knew it looked good. 

EJB1, the first child, turned out to be a wayward beast but none had come before him and he was worshipped by the managers that ruled our tribes as they saw it as an answer to their CORBA prayers.

Developers were forced into EJB1 servitude but only a few could satisfy it’s demanding needs.

Displeased, the developers gathered to raise their concerns with their managers and together they prayed to the SUN to put it right.

But the SUN didn’t listen, instead it bore upon us all the rath of EJB2 for our insolence.

The SUN then heard a new child was to be born in the Spring whom would grow to be the saviour of all developer kind but the SUN dismissed this challenge to its omnipotent being.

As the Spring child grew, more and more developers from far off lands whom spoke in many different tongues flocked to hear the sermons of the Spring child from the mount and were converted as they had become discontent with the power of the SUN over J2EE.

Eventually the SUN did notice that many of its followers had become discontent and that they were now repeating the sermons delivered by the Spring child from the mount…

etc etc etc

 

Anyway, you get the picture. Evolution boys and girls. Parts of J2EE were rubbish; Spring offered an alternative, JEE came along and addressed some of these J2EE problems, learning from Spring and other third party frameworks in the process, and if we are lucky this leapfrogging and innovation cycle will continue well into the future.

I for one have seen too many blows levelled at Spring recently that are, in my opinion, undeserved (my opinion, my opinion, my opinion. Free speech is great isn’t it!). Spring are a major factor in shaping what we have today in Java and have achieved this standing through great innovation that addressed our needs. Sure some of Spring is looking a bit dated, especially around the bean lookup String vs Object typing but so what, it’s still very relevant and still very usable as a framework and it will continue to be so for some time to come.

Personally, I would like to see a major shift away from JEE and towards Enterprise OSGi and Social Media integration, I just feel JEE6/7 offers me nothing more than I can already get mixing and matching a couple of well supported existing frameworks.

 Steven M

The Spring framework solves real world problems today (and yesterday)! Spring has earned the trust of enterprise developers by providing frameworks that solve "real" developer issues. The richness of Spring's portfolio goes well beyond DI. For example, I can run Spring Batch (yes a framework !!!) on a JRE without an application server and w/a DI container. Spring Integration (another framework !!!) can run with or without a application server w/the same DI container. 

In my world, enterprise java development is more than just web applications! it spans multiple engineering domains and Spring's flexibility to mix and match frameworks, private and public clouds (ie Vmforce.com) and run with or without an application server makes it an easy (and cost effective) choice for me everytime. 

-brian

 

Yes yes... Spring is dead... frameworks are dead ... LoL !!!!

Show me something like dmServer + ActiveMQ + Spring Integration + Spring batch + ibatis inside JEE

Guys... are you REALLY serious??

The world is a little bit bigger than web applications. By the way, for web applications wicket is much much better than JSF.

JEE sucks guys, just admit it.

The world is a little bit bigger than web applications. By the way, for web applications wicket is much much better than JSF.

I don't really agree. Wicket is surely a nice framework, and it has some advantages over JSF, but *much much* better is really exaggerated. There are also a lot of advantages that JSF has over Wicket. One of the non-technical advantages is that it is actually used by more than a hand full of programmers.

JEE sucks guys, just admit it.

Must... resist... troll....

.....Again wicket?!?!?!?

Oh my!

Let's use the cudgel!

JEE sucks guys, just admit it.

 

 

Must... resist... troll....

In fact doesn't sucks. JEE 6 is great and the work of Gavin King and the rest of the people on Seam and Weld is amazing.

But when I saw articles like this, articles that are just opinions but posted like universal trues, I really piss off and I write things like that.

 

Congratulation !

 

JEE6 does what Spring did 5 years ago.

 

Have we to wait another 5 years to get what does Spring by NOW ?

Congratulations!

 

Spring does what Java EE did 5 years ago.

 

Do we have to wait another 5 years to get in Spring what Java EE does NOW ?

FTFY

Document Generation

Document generation (docgen) is an automated way of generating and distributing documents. Instead of creating a document manually, the user creates a template, and specific information populates the template when the document is generated.

Java document generation

 

Document g eneration is the most thorough and efficient means of automating documents , and without it, businesses would waste critical resources.

is python is answer for all the questions / issues by the Java/J2EE

Quote << Frameworks like Spring are really just a bridge between the mistakes of the J2EE past and the success of the Java EE 6 future.>>  There is a point here which is overlooked.

That is it was the "mistakes in JEEE" which gave rise to Spring.  This is true in the JavaWorld in general. Every mistake becomes a new product! Java itself never admit the mistakes as such. Normally mistakes should be rectified. Instead, here we jump to a new product doing a  little job. 

Olden days online  transactions (as opposed to the dumb batch jobs) DID not run directly under the OS (IBM MVS as an example). They did not run even under the TSO /MVS of iBM . OLTP stuff ran under own IMS-DC or CICS or IDMSDC all of which ran under the OS (MVS). In general we call it DC - for Data Communication.  DC was the platoform or container or a super framework which supported a variety of features to facilitate ONLINE systems.

In the JavaWorld we don't have SUCH a 'dc'. JVM is not. Weblogic, Websphere, JBoss  or Tomcat should have done this job. But all of them did satisfy the role in part!  So for every damn thing you needed an extra framework - Struts, JSF, "EJB support", Spring etc.   These frameworks are all centered around new packages specially made to support each framework. Obviously they have a short life. In the case of Spring it changes its face with every release! This gives you the impression that the new setup of Container (WLS/WAS or JB)  + Spring is always incomplete. Should we also add Hibernate to make it complete? If I borrow the terminology from Cameron  "MISTAKES" or "missing stuff"!  Instead of coming up with new frameworks, the CONTAINER - WLS, WAS or JBoss - should give the basic features (APIs) to support transactionn  processing and database integrity (PERSISTENCE).

A car delievered should be complete, irrespective of any new car coming  with a lot of new features. The old car if functional will continue to be complete and fulfill your need. In the Javaworld frameworks are like an incomplete CAR! Something missing all the time.

A Spring course material once said '"alongwith Groovy or GRAILS" we will give you the features of Ruby Rails!' THis is like Toyota (eg) claiming that if you also buy/add a little  "thing" to 'our car' you will get the features of a  Mercedenz (eg)! Then why should I go for that solution?

Today's patchwork solutions with incomplete containers and frameworks have no future, no life. Of course one can rewrite all the code to the new version every 5 years!

 

Moving from Spring to Java EE 6 is great experience which i appreciate.tours in India

Javva EE6 is my favorite also and i appreciate you to move to it from any other, i hope it will be best for u. tours in India

The web services page which link is shared in the post is amaing and outstanding for me as an IT professional i got a lot from it. tours in India

I love to rad this kind of article and the materiel is very well written

The Age of Frameworks is Over works well for me

 

 

gift ideas for illustrators

It is so OVER! I agre with all the points mentioned here

stork club movie