Future Of Enterprise Java ...Is Clear (Java EE with/without Spring and Vice Versa) : Adam Bien's Weblog

It's me again ;-)

That's also the reason why SpringSource/VMWare built the Spring tcServer. Otherwise they had to certify Spring on every Java EE application server.

Posted by Simon Martinelli on March 22, 2010 at 12:58 PM CET #

I think java ee facilitates many things they are complicated with spring : web service and jms for example

Posted by ucef on March 22, 2010 at 01:18 PM CET #

Adam,
to explain the maintenance policy: Usually Open Source projects only care about the current version. We additionally offer to buy support for older version - so you can stick to the old version *and* get support. This is I think an advantage of Open Source that is backed up by a company.
Obviously you don't need to sign a support contract if you don't want to and you also always get the most up to date sources.

Also I am not sure which Java EE 6 server you are talking about. There is Glassfish certified and TMAX JEUS. It will take quite a while (read: years) until Java EE 6 compliant versions of WebSphere, WebLogic, JBoss etc are in production and can be used for real application. Spring 3 just needs Java 1.5 and J2EE 1.4 so can readily be used in almost all environments.

I am also not sure how a deployment of a Spring application in a Java EE 6 server should be a problem. Can you explain?

Eberhard Wolff
Principal Technologist
SpringSource - A division of VMware

Posted by Eberhard Wolff on March 22, 2010 at 03:44 PM CET #

Hi

Here's an example of a "serious project" I've been working on for about six years.

It started with Spring 1.0.x as a DI container (then IOC :), now it uses Spring 3.0.0.RELEASE <b>without any modification to it's XML configuration files</b>. Of course new controllers/services/etc. use annotation configuration.

So I really don't see a problem with free access to only current version - I'm not very interested (not only as a programmer, but also as a this project's decision maker) in e.g. Spring 2.5.7 version.

And Eberhard is right - I don't have neither time nor patience to wait for WebSphere 8. Actually our client uses WebSphere 6 (JavaEE 1.4 compliant). I can use Spring 3 - I can't (and really don't want to) use JavaEE 6.

And this "milliseconds" - I agree - I've even checked it personally. But I should have tested these milliseconds in my real project which at the startup loads few megabytes of data from different DBs - I wonder what benefits will Glassfiish give me in terms of reloading application? For production - it really doesn't matter. For development - I have JRebel :)

regards
Grzegorz Grzybek

Posted by Grzegorz Grzybek on March 22, 2010 at 04:06 PM CET #

@Eberhard,

Deploying Spring into an Application Server isn't a problem at all from the technical point of view.
It is as you stated: to get patches and support for older Spring versions you will have to sign a contract. Another option would be to migrate Spring to newer versions and get patches as a new version appears. The release strategy of a "serious" project just cannot depend on the Spring release cycle- so you will have to sign the contract (what is good). BUT: you will also have to do the same with your application server vendor.
Regarding Java EE 6: Glassfish, JBoss, openEJB are on the horizon and Resin / Caucho is interesting as well.

It is, however, not an Java EE 6 issue - we have the same problem with Java EE 5 already. ...and Java EE 5 is already supported by ~14 servers (http://www.adam-bien.com/roller/abien/entry/the_list_of_certified_java).

The essence of this post is: to get patches for older Spring releases you will have to sign a contract.

You will need a contract also for an appserver, so you will have to make a decision (this is also true for Java EE 5) whether to sign both or migrate entirely to Spring or Java EE.

thanks for your comment!,

adam (independent freelancer :-))

Posted by Adam Bien on March 22, 2010 at 04:24 PM CET #

@Eberhard

1. It's not a problem to deploy Spring in a Java EE 6 server, but it's not tested by anyone and no one gives a guarantee that it works. That's more or less a "management thing".

2. It's not necessary to use Spring when you have a Java EE 6 server. Sure if you need specific Spring features then it make sense but otherwise...
Don't get me wrong. Spring is a cool framework and it did a great job in bringing Java EE to where it is now. But in most cases Java EE 6 is good enough.

Posted by Simon Martinelli on March 22, 2010 at 04:26 PM CET #

@Grzegorz,

this post has nothing to do with technology, and more with contracts :-). It is actually your client's decision - whether he would like to pay for both, migrate to either direction or go live without any contract.

But: your client should know what the current support situation is - then decide.

Posted by Adam Bien on March 22, 2010 at 04:28 PM CET #

@Grzegorz,

some real life deployment performance stats: http://www.adam-bien.com/roller/abien/entry/how_fast_is_the_build

thanks!,

adam

Posted by Adam Bien on March 22, 2010 at 04:34 PM CET #

It is also a question of innovation and the speed of it. JEE, (although is a much better framework comparing to where it started years ago when it was almost un-usable in serious projects), is not really innovating, but rather playing a "catch-up" game to align itself with popular features of modern frameworks (e.g., Hibernate, Spring etc.). But those frameworks are already ahead with new features that I (the developer) can currently benefit from (therefore my project), while same features are not even discussed (currently) in the scope of current release of JEE.
I think the real question is not about Spring vs JEE, but about the state of JCP and how irrelevant this process has been for a while. Hopefully it will be fixed, but until then I'll pledge my allegiance to the innovators, simply because they helped me to still love my job (I hated it when I had to live in J2EE world) ;)

Posted by Oleg Zhurakousky on March 22, 2010 at 04:49 PM CET #

Sorry, but I disagree strongly. you don't need to go full stack Spring anywhere.

We do Spring + Hibernate in plain Jetty and are 100% happy. No need to go either full Java EE6 or some customized Spring server.

And with all this hoopla about Java EE6 let's not forget Oracle's recent comments how Glassfish is going to be the "departmental" server and Weblogic "the real thing". I can't say I don't have much faith in Oracle maintaining Sun's level of commitment to open source projects...

If there was an independent implementation of Java EE6 that could run in Jetty, we would be glad to give it a try, no problem. It's good to have such level of integration.

But until, we trust the platform that has already delivered for us over and over again: Spring.

P.S. And we already use a lot of Java EE pieces: JPA annotations for Hibernate entities, JAX-RS, JAX-WS (on top of Apache CXF), etc.

It's not necessarily an all-or-nothing choice between the two.

Posted by Jacek on March 22, 2010 at 04:51 PM CET #

@Jacek,

"It's not necessarily an all-or-nothing choice between the two."

It is not necessary but it makes your life easier. As I wrote -> this post is not about technology, and a ll about contracts :-).

If you don't have any plans to get commercial support - you can safely ignore this post :-).

thanks for your comment!,

adam

Posted by Adam Bien on March 22, 2010 at 04:59 PM CET #

I am seeing customers that adopted Spring tc Server during development to drop it and roll back to plain old Tomcat once it goes anywhere near production because of Ops basically deciding that the (dev) ease of use features are not ease of use in their managed environment and that the application management capabilities of Spring tc needed actual application performance management (one customer had to give 2GB of heap to the Spring Management Server process).

Any customer with experienced operations people will see very little real value in the Spring offering over Tomcat and custom scripts to integrate into their managed environment.

Posted by William Louth on March 22, 2010 at 05:00 PM CET #

Well, I guess the choice will be clear in this case if one compares the support costs of :

Java EE6 on top of Weblogic (the "real" JavaEE 6 server, which you will be pushed towards on every support call)

vs

Spring in their own custom server.

I don't know what these costs are, if you have some samples of both prices that would be great.

Knowing Oracle's support costs though....

P.S. We have some experience with Oracle in the past with Weblogic J2EE: on every support call they would complain if we were running in standard JRE and pushed us towards JRockit all the time.

In the end we just bought a JRockit license, otherwise the support contract was useless. Not exactly the type of lock-in or strong-arm techniques I'd like to see.

Posted by JACEK on March 22, 2010 at 05:06 PM CET #

@Jacek,

exactly the choice has to be made between both (or Glassfish, WAS etc.). Thats the point.

I had other "interesting" experiences with WLS support - but not with the JVM choice. We always ran on Sun's VM, although JRockit offered a better scalability.

At the end - its a business decision - as it should be.

thanks!,

adam

Posted by Adam Bien on March 22, 2010 at 05:30 PM CET #

@Jacek,

my experiences with application servers and their support: http://www.adam-bien.com/roller/abien/entry/the_end_of_commercial_java

thanks!,

adam

Posted by Adam Bien on March 22, 2010 at 05:32 PM CET #

Flowing the logic of the post, I can't use anything that isn't under the Java EE 6 umbrella, for a "serious" application

No Seam 2, Seam 3, RichFaces, IBatis, Hibernate (native), Wicket, common-*, google collections, log4j, slf4j, etc, etc

As they don't support older versions, as there development progresses. They would all be "uncertified, un-indemnified"

Posted by Darryl Smith on March 22, 2010 at 06:17 PM CET #

Hi Adam,

I'll tell you what the future of Enterprise Java is. It's in the cloud. So whoever keeps innovating toward that end, whether it's Spring, or JEE Spec/vendors they will keep winning. The next step in this evolution is a Eucalyptus style architecture for the JEE and or Spring platforms that seamlessly integrated internal private, and public cloud applications into one single cooperating entity. If Spring delivers on that first then they'll win, period.

Posted by Mike Azzi on March 22, 2010 at 06:21 PM CET #

@Mike

Ok and if cloud is the future of Enterprise Java, Adam is much more right with his post.

Because if it is a PaaS (platform as a service) like Google App Engine then you have to relay on the framework of the cloud.

An then I hope it will it's Java EE in the cloud ;-)

Posted by Simon Martinelli on March 22, 2010 at 07:13 PM CET #

I basically think that the No. 1 argument for Spring from an architects perspective is: stability.

Stability in terms of "compatibility".

I started my first Java EE project in 1999 with EJB 1.0 and I think it was WebSphere 3.0 then. It turned out that EJB 1.0 was not as easy as many "evangelists" told us at the conferences. With EJB 1.1 everything was better - and we had to rework the whole code, as EJB 1.1. was very different from 1.0.

Turned out that EJB 1.1 had some flaws and with EJB 2.0 everything was better and we where all very happy to have books like "EJB Design Patterns" that showed us how to develop around the EJB model. Oh yes, I forgot to say that we had to reimplement most of the application as EJB 2.0 was totally different from EJB 1.1.

At the TheServerSide Symposium 2003 in Boston I met Rod Johnson who presented his book and did a talk about the Springframework. From that point I was a "Spring-Fan" - easy programming model (that was basically copied by Java EE 6 - what is ok and good) and no more work for upgrading. I am using Spring 2.x for some years now and had never problems with missing updates etc.

Basically I don't trust this Java EE platform anymore - I am tired of telling my customers that we need budget for migrating from EJB X to EJB X+1 - with Spring I can focus on the real stuff.

Hey - and if you look at JSF I see similarities. JSF 1.x was never really usable without Facelets - now Facelets are JSF 2 and this means for JSF 1.x users: Migration!

Sorry, but Java EE has nice APIs (Servlet, JSP - hm...maybe that's it...) but most of the APIs are application-server-vendor-driven. And actually they have reinvented the wheel so often that they also are not able to migrate their stuff as quick as they want :-) Let's see when WebSphere and WebLogic will fully support J EE 6.

When you do a "Coding Twitter with Java EE 6 in 60 minutes" presentation - it is fun watching and very entertaining but comparable to a TV cooking show - looks nice but has nothing to do with prof. cooking ;-)

Posted by Mirko Novakovic on March 22, 2010 at 07:22 PM CET #

Frankly, this rant seems desperate :->. This is pure FUD.

(I've worked for biggest financial enterprises in Europe, no.1 in Banking and Insurance. Both use a *lots* of Spring for virtually everything, and abandon EJB if they can. None of them has signed up agreement with SpringSource, as well as RedHat (Hibernate and other stuff), (apache?) lot of stuff, (eclipse?) lots of stuff etc.)

Posted by Artur Karazniewicz on March 22, 2010 at 10:00 PM CET #

@Artur,

o.k. this is your experience. In "my" projects management, operations and project leaders only accepted supported servers and platforms.

Its only risk management - nothing else. You don't have to sign anything.

Why you consider this post to be a rant or FUD?

Posted by Adam Bien on March 22, 2010 at 11:12 PM CET #

@Darryl,

you are right - Seam etc. have the same issues. Now it is solved with CDI -but e.g. I would start with JBoss + Seam, before I evaluate Glassfish + Seam. The same is true with JBoss + Hibernate, Glassfish + EclipseLink etc.
I would expect the JBoss guys to support Seam with the appserver - but I cannot expect that from the Glassfish support... Patches etc. are also an issue. Recently we had a threading problem with too old HttpClient library...

Posted by Adam Bien on March 22, 2010 at 11:15 PM CET #

@Mirko,

"When you do a "Coding Twitter with Java EE 6 in 60 minutes"

Well it is funnier to explain Java EE 6 with living code, than with slides - isn't it? :-)

Btw. this weekend we hacked a small application (REST / Json, JSF2, EJB 3.1, JPA, Interceptors etc.) with 25 students in 3h.

The only thing I can say is: Java EE 6 works good in real world :-)

Posted by Adam Bien on March 22, 2010 at 11:18 PM CET #

@Mike,

not every enterprise project is suitable for a cloud - at least not from management's perspective right now. But: eucalyptus rocks :-).

Spring is already in the clouds (looks actually really interesting, but you can distribute with VMWare whatever Java-App you want).
You can also start whatever you want on EC 2...

Yes - clouds are also interesting: http://java.sun.com/developer/technicalArticles/Interviews/community/bien_qa_2009.html

thanks!,

adam

Posted by Adam Bien on March 22, 2010 at 11:23 PM CET #

@Eberhard
" It will take quite a while (read: years) until Java EE 6 compliant versions of WebSphere, WebLogic, JBoss etc are in production and can be used for real application. Spring 3 just needs Java 1.5 and J2EE 1.4 so can readily be used in almost all environments."

I think JBoss AS 6, which is fully Java EE 6 compliant, is scheduled to be released later this fall.

From then on, you can find this in production. So it will most likely be months, not years we're talking about.

If you solely mean that enterprises will not dare use brand new technology, then of course the same holds for Spring 3.x and it will thus be years before we will find Spring 3.x in production according to that reasoning.

Posted by Robert Tuinman on March 23, 2010 at 01:59 AM CET #

@Adam

You might be right with this "only spring or only JavaEE" choice in terms of support contracts. But it makes me sad as a technologist - that the management thinks that there's some kind of battle between Spring and JEE. For me Spring is just a tool to makes JEE development much easier! Spring helps me with servlets, JSP, JPA, JSF, JTA, JCA, JAXB, JMX etc. I'm not Spring programmer - I'm a JEE programmer which realizes benefits Spring offers!

But the whole "support agreement idea" for management - I think these are only cover-the-management-a$$ type of contracts. When it comes to real problems, the phone calls to (highly paid) support ends with "have you installed latest fixpacks"?.

From my point of view, as @Mirko said, some APIs are just vendor/product driven. From my experience, the app server should provide good, clean and fast HTTP layer (servlets-api implementation) and other specs (implementations) I would like to "carry" with me in my WEB-INF/lib. I don't want my container to provide particular, hard-to-replace JPA implementation, I just manage my own, known version of Hibernate among my jars. And I won't let anyone from my team to replace this hibernate.jar with any other JPA implementation - not because I'm using hibernate-specific classes, but because I WANT to know I'm using hibernate and I know where its JIRA is located (which is not a case with some unknown JPA provider). If only I could carry my own JSP implementation...

So in terms of support contracts, I'm sure there are many (at least a few) companies which will offer support for Tomcat or Jetty which are great at what they're supposed to do - at handling HTTP traffic and routing requests to my servlets/controllers.

I wish I lived in times where offering Tomcat/Jetty server will be highly demanded and common practice. But I'm afraid that now it's almost impossible. Many software contracts include profits from reselling licenses to "big" servers. It's very common to sell IBM Process Server (+WebSphere +MQ +Message Broker) just to deploy "a process" consisting in "a flow" which reads data from RDBMS and sends it to some external WebService... Sad, but true.

@Mirko

Very well said! That's the case I had. As I said - one of our projects uses Spring from 1.0.x. Now it uses Spring 3.0.0 IN PRODUCTION with absolutely no issues. We use WebSphere, but only because IBM wanted use to use it. My decision was to get rid of MDBs (and replace it with Spring JMS support) and container-managed security (replaced with Spring Security). When we've migrated from WebSphere 5, to 6 we've had had only issues with JavaEE (MDBs and JSPs) - not with Spring!.

regards
Grzegorz Grzybek

Posted by Grzegorz Grzybek on March 23, 2010 at 09:04 AM CET #

@Grzegorz,

in your case it would be better to migrate entirely to Spring TServer.
Why to pay Java EE support, when plain Spring would be enough.
It just crazy to overlay existing J2EE functionality with Spring.

Why you need WebSphere then? I guess you are using about 5% of the existing WebSphere functionality :-).

Your comment just proofs my point: in future there will be only a fullstack Spring or Java EE. Using Java EE servers and overlying them with Spring is just crazy.

thanks!,

adam

Posted by Adam Bien on March 23, 2010 at 09:24 AM CET #

@Adam

"crazy" - good word :) we have very similar thinking after all. Of course it is crazy, but usually persons dealing with contracts are not the same persons which deal with technology. My luck is that the former persons only dictated the app server and I had choice with the rest - so I chose Spring to make pure servlets+jsps easier.

Of course we're using only 5% of WebSphere :) The entire application + WebSphere starts in about 3 minutes. On my development env it starts with Tomcat in 20 seconds. But I can't go to my company's client and say "hey - the app works great on Tomcat/Jetty, there are even companies who offer support for these servers and it is very affordable". I can't because there is this "invisible (dark side of the) force on the market" :)

Grzegorz

Posted by Grzegorz Grzybek on March 23, 2010 at 09:39 AM CET #

@Robert
The list of Java EE 6 compliant servers is available at http://java.sun.com/javaee/overview/compatibility.jsp and does not include JBoss.

The difference to Spring is that to operations Spring is a part of the application. So a new version can be installed as part of an application upgrade. Installing new application servers is much more complex and probably more risky. As operations are conservative they will try to stay away from that.

Posted by Eberhard Wolff on March 23, 2010 at 09:58 AM CET #

@Eberhard

Of course the list you refer to doesn't include JBoss AS 6 yet, since its GA is planned for this fall. It will be there soon, but not now.

From an application point of view, upgrading Spring is just as easy or as difficult as upgrading JBoss AS. It's not the actual act of the upgrade that is difficult (Spring: copy a dozen downloaded jars over, JBoss AS: unarchive the downloaded archive), but to ensure all of the application code still works as expected. There is barely any difference here between Spring and Java EE (e.g. JBoss AS).

We've been over this a couple of times in the past, but I absolutely don't think installing a new AS is more complex than installing a new Spring container in your application. I also don't buy it that operations are by default conservative and thus by assumption software developers are all cowboys. In practice I've seen nearly all combinations. Very careful software architects, with young and brash people in operations, the other way around, careful software architects and careful operations and even brash software architects and brash operations.

In practice, basically anything goes. I understand that Spring has an interest in the idea that software architects are always cowboys and operations are always conservative, so the Spring 'benefit' of sneaking architectural upgrades into an application archive past operations is time and again highlighted.

As I explained in reactions on previous posts of Adam, I just don't think this is the case. Certainly it's not the case for each and every company.

Posted by Robert Tuinman on March 23, 2010 at 01:08 PM CET #

@ Grzegorz

>Spring helps me with servlets, JSP, JPA, JSF, JTA, JCA, JAXB, JMX etc.

In the past Spring has been helpful indeed with e.g. JDBC, but I'm far from convinced it provides any benefit for the JPA API. On the contrary I think something like JPATemplate is really unnecessary. Maybe you like it, and that's good for you, but most people I personally know much rather use the more elegant and clean JPA API directly.

In a Java EE environment, I'm also not sure why I would need any additional help with JTA. The API is minimal and very focussed. Better yet, because of declarative transactions, in 99% of all cases the API is completely invisible for me.

The same goes for web services. Java EE offers an excellent and clean API here. The Spring 'abstraction' API on top of if only seems to make things that were once easy more difficult.

Maybe Spring does offer some benefits with using JCA, which can feel a little archaic at times. I think JCA though is not really targeted at regular application developers, but it more intended for vendors providing some kind of integration connector for their system.

>As I said - one of our projects uses Spring from 1.0.x. Now it uses Spring 3.0.0 IN PRODUCTION with absolutely no issues.

Good for you, but what does this prove? We have a project that was deployed to JBoss AS 4.2. When JBoss AS 5 was released, we tested our app for some 6 months on it and then pushed it into production with absolutely no issues. We did the same with JBoss AS 5.1 and intend to do the same again with JBoss AS 6.

Posted by Robert Tuinman on March 23, 2010 at 01:26 PM CET #

@Robert

I don't use JPATemplate, I use pure JPA API (which by the way Spring guys recommend) JPA in Spring gives me benefit of using both JPA and JDBC at the same time (same connection, same tx).

About JTA - I might sound like quoting spring reference, but Spring's tx management is clean, declarative, testable and usable outside app server. It allows both XA and non-XA transactions with the same API - we're living in a world which cannot just abandon separate JPA/Hibernate/JDBC transaction APIs :)

WebServices - of course Java EE has great JAX-WS/JAX-RPC APIs. If one don't like template-style web services access I'm not the one to convince him/her. I just found it easy (even possible) to use legacy axis1-style webservice in Spring-Integration using Spring-WS.

JCA - OK, I went too far :)

I've also had little problems migrating from JBoss 4.2 to 5.0/5.1. But as @Eberhard said - it's usually easier to replace Spring inside WAR then to replace whole app server (which may run other applications as well).

regards
Grzegorz Grzybek

Posted by Grzegorz Grzybek on March 23, 2010 at 01:47 PM CET #

@Grzegorz

Okay, good to hear that even the Spring guys now recommend using the JPA directly.

In Java EE however one can just as well use JDBC and JPA within the same tx. Both the EM and a plain old datasource can be injected in your beans. A datasource is injected with e.g. @Resource(name="jdbc/MyDS").

Connections obtained from this datasource will participate in the currently active transaction, just as everything else thats supports transactions will (e.g. like a transactional cache).

If I just want to execute a native query however, I often find it easier to just use the EM for this as well instead of going through the JDBC API. The EM perfectly supports executing native queries.

>it's usually easier to replace Spring inside WAR then to replace whole app server (which may run other applications as well).

Okay, if your app server also runs other applications, then it's easier to replace the Spring container that's embedded in your WAR.

We however don't really do this. We run 1 application on 1 AS instance. I'm not really sure whether it's a misconception or a failure on Java's part, but I don't really think either the JVM itself or the AS is a replacement for what is the task of an OS: separating and isolating applications.

Since the AS only provides a very mild level of isolation between applications running on it, IMHO 'applications' on a single AS are more like larger modules of a single application. At the lowest level we have the methods and the classes. One level up is the package, then comes the Java EE module (web modules, ejb modules) and then, if you still need a modularization level on top of that you can use 'application modules' that execute on a single AS. These 'application modules' typically share the same local JNDI, so they can use each other's datasources directly, and they can communicate via local interfaces. Note that I'm not advocating such a setup as something a typical application needs!

Thanks to affordable and excellent virtualization products that are on the market today, it's far easier to run truly separate applications on a separate AS that runs within a separate virtual server. Especially Springsource should recognize this setup now that they're being owned by VMWare.

With such virtual servers in place, the traditional problems with upgrading the AS also disappear. The virtual server is what operations maintain and the AS running in it is just 'the application'. Operations then doesn't have to care whether it's Glassfish, JBoss AS, Tomcat, the Spring AS (TC), etc.

Posted by Robert Tuinman on March 23, 2010 at 03:31 PM CET #

@Adam: Yes, I like your presentations and the way you present Java EE by coding "live" on the stage. And I also believe that Java EE 6 would function in "real life", BUT the question is how Java EE 7 will look like and what that will mean for my investment in a new software. The history of Java EE shows that there was a lot of migration affort in the past and I am not sure why this should be different in the future, because the companies behind the standard are earning money with "migration"...

With Spring I am save and I have a similar architecture/feature set - in addition to that I don't need an expensive App Server (have never seen Glassfish in production) - I can just use Tomcat.

Taking the history of Java EE and Spring and the current App Server situation. What is your point for an architect to chose Java EE?

Posted by Mirko Novakovic on March 23, 2010 at 10:04 PM CET #

I was able to get down to sub-nanosecond response time with my server side web services as measured at the service method call. Of course I used cache and after implementing a 3-tier caching system it was around a couple of micro seconds. I am using an old AMD64 5200+ CPU with DDR2 memory.

So if you go light on frameworks you can achieve some very good results.

I wrote all about my obsession several years ago on the jboss performance forum.

http://community.jboss.org/thread/70463?start=0&tstart=2

It got viewed over 106K times.

Regards,
Tony Anecito
Founder,
MyUniPortal
http://www.myuniportal.com

Posted by Tony Anecito on March 23, 2010 at 11:52 PM CET #

@Mirko
> companies behind the standard are earning money with "migration"...

Never paid JBoss a dime for any migration. And what migration efforts are you talking about? It took us very little trouble to move our app from JBoss 4.2 to 5.0 and to 5.1.

> in addition to that I don't need an expensive App Server (have never seen Glassfish in production) - I can just use Tomcat.

Never paid JBoss a penny for any App Server. And yes, JBoss AS is used in production. A lot!

It's free and it's open source. Please don't play this old card that Java EE is only about expensive closed source software. This hasn't been true for a LONG time...

>What is your point for an architect to chose Java EE?

It's free, it's open source, it works like a charm, it feels like a coherent platform, there is lots of documentation available, there are courses available, there is support available from multiple companies and multiple vendors provide implementations... any thing else?

Posted by Robert Tuinman on March 23, 2010 at 11:56 PM CET #

@Robert

You're right with this concept of 'applications' on single app server. It's all true - usually there is only one application on an application server.

But there are two points:
First - I really would like to not use WebSphere, because I expect my app server to implement only servlets+jsps. I really would like to use Tomcat (or JBoss - it doesn't matter untill it's open source :). I really would like to tell my company's customer "If you want support, buy Tomcat/JBoss support" - but the reality is more brutal - sometimes WebSphere (or Oracle Application Server - anyone?) is [b]the key element of my company's offer[/b] - it's beyond any discussion! It must be OAS just "because".

Second - I DO use JavaEE. But I'm using Spring, because it's well knows, proven, clean and predictable (which is very important in enterprise). Spring IS NOT replacement for JavaEE (I wonder why in almost every discussion "the JavaEE guys" say that "since JavaEE there is no need for Spring because now we have CDI"). I am JavaEE programmer. Spring offers not only DI container. It has many helper classes, implements many shortcuts for common tasks (StringUtils, ReflectionUtils, StaxUtils) and Spring!=SpringFramework. The most obvious need for Spring is Spring Security - I'm sure you'll agree that "declarative security" of JavaEE is way tooooo much vendor-dependent.

I've heard that Seam has many improvements and excellent modules/components - I'm sure it has. If only I've started with Seam (portfolio) instead of Spring (portfolio), I would write comments glorifying Seam benefits, but somehow there is no "JavaEE vs. Seam" war...

regards
Grzegorz Grzybek

Posted by Grzegorz Grzybek on March 24, 2010 at 09:41 AM CET #

I think there is no Java EE vs Seam war because none of the Seam guys constantly say that Java EE is outdated, legacy, heavyweight, complex and impossible or very difficult to upgrade.

Instead, Seam contributes great ideas back to the Java EE platform. I remember that Spring was invited to do the same, but in practice nothing really came out of that.

Posted by arjan on March 24, 2010 at 06:55 PM CET #

For sake of completeness here, Resin is actually slated for Java EE 6 Web Profile certification by this fall. Here are our plans: http://blog.caucho.com/?p=384.

JCP is "slow", "irrelevant", etc is clearly just a bunch of self-serving FUD. Simply taking a close look at Spring 3, it's significant theme has been Java EE 6 API support as well as mirroring some functionality from both the EJB 3.1 and CDI specifications. If that's not a sign that that the JCP is both relevant and a source of important innovations, I am not sure what is.

It's also sad to see the anti-GlassFish FUD given that GlassFish just released it's road-map. I do agree that the animosity between the Java EE and Spring camps originates squarely in the SpringSource leadership. We all hoped to see that subside with Java EE 6, but that clearly has not happened.

Cheers.
Reza

Posted by Reza Rahman on March 26, 2010 at 11:57 PM CET #

@Reza

I saw the Glassfish roadmap few hours after posting my last comment. So I recant my comments about GF3 not being clustered :) It's great news, so let's see what future holds for GF!

Posted by Grzegorz Grzybek on March 30, 2010 at 11:09 AM CEST #

@Grzegorz,

thanks again for your extensive + constructive comments. Whatever the future will bring - clustering is not a mandatory feature: http://www.adam-bien.com/roller/abien/entry/ha_without_clustering

I'm using GF v2 without clustering in some HA projects already.

cheers!,

adam

Posted by 192.168.0.24 on March 30, 2010 at 11:56 AM CEST #

Also with JEE6 I don't believe in the often shown webshop in 15 minutes :-) JEE6 is similar to Spring but why shouldn't I take the Best? Anyway, I have to work with JEE6 and read a bit more than the intro of the spec so far

Posted by openwms on April 07, 2010 at 02:17 PM CEST #