The usual suspects

In what way is Jurgen's statement FUD? He said his opinion and what he knew at the time (unless you imply that he was lying).

Why is it legitimate to support the web profile, or any other standard, but not to oppose them if an alternative is presented? In this specific case, why would I care about conforming to a profile if I don't need all of its components? Is it THAT difficult to define my own dependencies, which I would probably need to do anyway?

Besides, if you ever try to use Hibernate on the old Oracle Application Server you would see how messy things can get when you rely on the application server for dependencies, just one example.

Of course there are pros and cons to both ways, but the standards will never fit everyone, and there is nothing wrong in saying it.

My hope is that the Web Profile displaces most uses of a standalone Servlet container so that we no longer have this huge portability problem when migrating from a Servlet container (in development, for instance) to a Java EE container (in production). The Web Profile should really be the go-to solution for rapid development.

Gabriel if you are such an apologist that you go out of your way to defend this kind of obvious FUD, it's not worth the effort of arguing with you. I'll let my post speak for itself. And the rest of your comment makes no sense at all. Nice try.

I agree with Gabriel. Gavin, with all my respect, you're just spreading your own FUD. I thought that website was about technical content but it looks like it is all about politics.

OK, so let me get this straight. If I was to say, in an interview with a journalist, or whatever:

I don't know of anyone who uses Spring in the financial industry.

Then this would be an acceptable thing to say? It may be a literally true statement about my own state of ignorance. But I think we can all recognize that it is also FUD. It's classic FUD. So what is the difference between my statement, and Jürgen's? I know the Spring folks always seem to get a free ride on this stuff, but I'm not going to give them a free ride. Sorry. With just a tiny little bit of research, Jürgen could have found out that there are vendors planning a web-profile-only EE6 implementation. But he wasn't actually interested in knowing the truth.

I thought that website was about technical content but it looks like it is all about politics.

If the ratio of politics to technical content is not to your liking, please stop reading. Seriously, I'm not interesting in wasting my time arguing with Spring zealots about their double standards. And I'm happy that we have plenty of excellent technical content up on this blog.

@Gabriel, @Michael,

I have to agree with Gavin. I mean really, who are you trying to kid here?

If Jurgen was joe six-pack web developer, perhaps one could honestly believe that he thinks that no vendor would target the web profile. But for cripes sake, Jurgen is a founding member of the Spring Framework. He knows the EE landscape, and to pretend otherwise really is FUD.

The point is not so much the injection of the possible FUD by Holler (which perhaps it is - and yes, FUD sucks and it's getting very old in the Java community), but understanding why Holler thinks implementing this profile is not very attractive. Is it not attractive to the Spring strategy or is it not attractive to the average JEE corporate developer?

I would really be interested in seeing an open and civil debate between the Spring and EE6 camps. Now wouldn't that be enlightening and potentially destructive/disturbing?

The web profile seems like a good idea and a consolation to the fact that JEE is heavyweight and we're now offering a lightweight stack, whatever that may entail/mean.

I think that the following comment from the infoq article is interesting:

As you know, you can trim down the JBoss AS configuration to the set of services that you actually need; this has always been possible with JBoss.

So it's almost like with EE6 the EG is saying hey, the average JEE dev is not smart enough to do this so let's do it for them. Which IMO is not necessarily a bad thing...

So what is/are the technical disadvantage(s), if any, of using the full profile vs. the web profile for a JEE web app?

It would be ridiculously sweet if something like Google AppEngine but for the Web Profile EE 6 appeared. Anyone have a spare server farm or two?

I am a GWT developer, why I should include JSP, EL, JSF and JSTL in my container?

Pepe Negrande wrote on Dec 10, 2009 03:29:
I am a GWT developer, why I should include JSP, EL, JSF and JSTL in my container?

First, three questions for you:

1. What on earth does this question have to do with my post? Are you trying to cover for Jurgen by changing the subject?
2. All servlet engines (including Tomcat, Jetty, etc) already include JSP, EL and JSTL. The fact that you don't seem to be even aware of this tells me a lot about exactly how much they're getting in your way (i.e. not at all).
3. The JSF jars amount to < 2.5 meg. Tomcat alone is already more 10 meg. I'm sure you're using several other libraries including GWT. How exactly are these two JSF jars getting in your way and making it harder to do your work? Precisely what problem are they causing?

And now, my answer to your question:

Having a standard base set of services there in the server adds a lot of value for infrastructure/framework developers. If I, as a developer of generic infrastructure, can rely upon the existence of a certain base set of services, I can target those services, instead of having to pull in a bunch of extra dependencies to do basic stuff, or build ridiculous abstractions of abstractions of basic services like transaction management, etc.

For example, I could create a generic user/role management UI, using JSF, that any Java EE Web Profile application could take advantage of, just by dropping in my war. I wouldn't need to embed the JSF jars or other services I use in my war, so my war could be a lot more lightweight.

We're trying to build an ecosystem here. I'm certain that this ecosystem will be inconvenient for vendors who make money off of the lack of a non-fractured ecosystem for enterprise Java, but that doesn't make it not worth doing.

Drew wrote on Dec 10, 2009 01:10:
It would be ridiculously sweet if something like Google AppEngine but for the Web Profile EE 6 appeared. Anyone have a spare server farm or two?

Totally. I think it's very likely that something like this will emerge.

Arbi Sookazian wrote on Dec 10, 2009 01:10:
...understanding why Holler thinks implementing this profile is not very attractive. Is it not attractive to the Spring strategy or is it not attractive to the average JEE corporate developer?

Yes, it would be interesting to hear Jurgen actually provide a nonfudish explanation of this lack of attractiveness. From what I've seen in the community, the Web Profile seems to be attractive to quite a lot of real web developers. My guess is it's not attractive to Jurgen because it potentially competes with Spring's proprietary platform offerings. But I'm a horrible cynic, and perhaps that's unfair.

Gavin King wrote on Dec 10, 2009 04:14:
My guess is it's not attractive to Jurgen because it potentially competes with Spring's proprietary platform offerings.

That was my first guess too. The Web Profile attacks Spring's user base.

But right now there seems to be a lot of truth in his words. Besides Glassfish (which is obliged to) and Resin there is not much support of the Web profile on the horizon. Even JBoss AS 6 doesn't provide a web profile (or did I miss something!?).

Since I've been tagged as a Spring zealot it is my sacred duty to say that the Web Profile poses no threat to Spring Framework, and the two are not that comparable. Spring is shipped as a collection of JARs and its philosophy is that everyone should take only what they need for their application, as opposed to the Java EE profiles which are based on the assumption that a few standardized collections of dependencies should fit everyone.

If a Spring users wants to use JSF - no problem, it integrates with Spring MVC. If they want JPA - Spring can manage the transactions and entity manager. Where is the competition here? It's all about freedom of features choice versus freedom of vendor choice.

Why would I throw away my Spring-based infrastructure that works like charm and was based on feedback from the community and business users in favor of a standard that was created by competing vendors, each with its own business plans and different view of the Java world that contains the minimum common features that are agreed by all (and I base it on an excerpt from the Seam manual you wrote, Gavin).

Daniel wrote on Dec 10, 2009 08:22:
Besides Glassfish (which is obliged to) and Resin there is not much support of the Web profile on the horizon. Even JBoss AS 6 doesn't provide a web profile (or did I miss something!?).

We already have a Web Platform that is similar to the EE 6 web profile. We will definitely be providing an EE 6 web profile. In fact, we will probably deliver an EE 6 web profile first, before the full profile.

And I will be very surprised if IBM and Oracle do not also provide web profile implementations.

Gavin King wrote on Dec 10, 2009 11:25:
We already have a Web Platform that is similar to the EE 6 web profile. We will definitely be providing an EE 6 web profile. In fact, we will probably deliver an EE 6 web profile first, before the full profile. And I will be very surprised if IBM and Oracle do not also provide web profile implementations.

I wasn't aware of the Web Platform. I was jnust wondering if JBoss will not ride the Web Profile train since nothing was stated about it in the release notes of AS6.

Gabriel wrote on Dec 10, 2009 11:05:
If a Spring users wants to use JSF - no problem, it integrates with Spring MVC. If they want JPA - Spring can manage the transactions and entity manager. Where is the competition here? It's all about freedom of features choice versus freedom of vendor choice.

An where exactly do you see the big difference between Spring and the Web Profile? If you don't want to use JSF you don't have to use it. If you don't want to use EclipseLink in Glassfish, use Hibernate or OpenJPA or whatever. If you want to use Spring, use Spring in the Web Profile.

the Web Profile poses no threat to Spring Framework, and the two are not that comparable. Spring is shipped as a collection of JARs and its philosophy is that everyone should take only what they need for their application, as opposed to the Java EE profiles which are based on the assumption that a few standardized collections of dependencies should fit everyone.

Actually, the Web Profile competes directly with SpringSource offerings like tc Server and dm Server. You may have missed the memo, but SpringSource is now an application server vendor. Unfortunately, their application server does not provide all industry standard APIs. Hopefully, they will decide to implement the Web Profile, and then this will be a non-issue. They've been remarkably silent recently about their plans in this area.

If a Spring users wants to use JSF - no problem, it integrates with Spring MVC. If they want JPA - Spring can manage the transactions and entity manager. Where is the competition here?

If I have a Java EE Web Profile implementation, I don't need Spring for those things.

It's all about freedom of features choice versus freedom of vendor choice .... Why would I throw away my Spring-based infrastructure that works like charm and was based on feedback from the community and business users in favor of a standard that was created by competing vendors, each with its own business plans and different view of the Java world that contains the minimum common features that are agreed by all

Because the technology in EE 6 is better, cleaner, more powerful, and more uptodate than the 5-years-without-a-proper-redesign proprietary vendor lock-in stuff you're using today. I dare you to actually try it with an open mind.

I keep being amazed by how courageous you are Gavin. In that area we're getting close to religious opinions you know. I wouldn't mixup too much the FUD and the Spring zealots although I admit the mormon-esque way of thinking of most of its advocates is often getting on my nerves too.

Personally I gave up arguing but it's always good to debunk received ideas publicly. Especially when you think the architects and PM's of tomorrow's applications will Google EE6 or CDI in order to make their mind about them.

Maybe I don't post on dzone, maybe I don't participate to jugs, but my experience in the EE area just drives me to fully support you and your team. CDI and EE6 are what the Java world needed. A kick in the ass and a leapfrog. Keep up the good work.

SpringSource is now an application server vendor. Unfortunately, their application server does not provide all industry standard APIs.

To my understanding SpringSource's application servers don't compete with with standard J2EE/JEE application servers. They just integrate Tomcat with additional tools to ease the management of the deployed Spring-based applications, and were a response to the large amount of users that deployed Spring applications on the standard Tomcat and needed better management tools.

If I have a Java EE Web Profile implementation, I don't need Spring for those things.

I totally agree. Use whatever fits your project and you feel comfortable with. There is no best choice here.

EE 6 is better, cleaner, more powerful, and more uptodate than the 5-years-without-a-proper-redesign proprietary vendor lock-in stuff you're using today

Now THAT'S FUD! Spring was invented as an alternative to the horrible EJB 2.1, and since then it evolved much more quickly than the standards. To name a few features that were added during these five years: annotation based configuration, programmatic configuration, autowiring by name/type/constructor, annotation and XML based AOP, annotated POJO controllers, RESTful mapping, bean creation/initialization/descruction customization, resource abstraction and the list goes on, and I'm not even talking about products outside of the Spring Framework itself (such as Spring WebFlow and Spring Security).

In fact, Spring introduced and/or implemented many (if not all) of the concepts that were added to JEE 6, for example Spring beans introduced exactly the same idea EJB 3.1 is based on. All the JCP did is take this idea and standardize the API.

On the other hand, if I were to stick to standards, I would have to wait for YEARS for new JEE versions to emerge, when new Spring minor versions come out every few weeks or months, and major versions still come out more often than JEE versions.

I dare you to actually try it with an open mind

I think every developer should do some hard thinking and a lot of experimentation with as much options as possible before starting a new project. I'm in no way saying Spring is better or worse than JEE, but that everyone should use what fits their projects. Of course if we are talking about an existing application, a new technology should be REALLY good in order to justify rewriting the application. The good thing in both Spring and JEE 6 components is that they encourage using POJOs in your code, which make it easier to migrate the business code to another infrastructure (unlike EJB 2.1, and again - only if there is a very good reason to).

To my understanding SpringSource's application servers don't compete with with standard J2EE/JEE application servers.

Then you should stop arguing with me, because clearly you don't understand anything at all about the application server market.

They just integrate Tomcat with additional tools to ease the management of the deployed Spring-based applications, and were a response to the large amount of users that deployed Spring applications on the standard Tomcat and needed better management tools.

You sound like you're quoting a SpringSource press release. You really do just swallow anything these guys tell you, don't you. Not very skeptical, huh?

EE 6 is better, cleaner, more powerful, and more uptodate than the 5-years-without-a-proper-redesign proprietary vendor lock-in stuff you're using today

Now THAT'S FUD!

No, it's a totally reasonable opinion. It's an opinion I can support with technical argument. Your double standard as to what constitutes FUD is breathtaking. FUD doesn't mean things you disagree with.

And I repeat my challenge to you: I double dare you to try EE 6!

If you do try it, and don't like it, great. I would be very interested in hearing what you think it's lacking. But if you don't try it, well, I guess you can wear your useful idiot badge with pride.

I think every developer should do some hard thinking and a lot of experimentation with as much options as possible before starting a new project...

... and before posting their opinions of the options in blog comment threads.

So do it. Get informed. Learn your options. Figure out what's really up with this CDI stuff. Of course, if Rod and Jurgen don't like it, it must be Bad, right? But, maybe, just maybe, there's a tiny chance that this is something you should take the time to form your own opinion about by actually learning the technology? Instead of just swallowing everything SpringSource tells you? Naaaawww....

Spring was invented as an alternative to the horrible EJB 2.1...

LOL, why is it that Spring zealots always try to bring EJB 2 into every discussion, as if it were still a relevant technology? I thought we were discussing the EE 6 Web Profile? What does EJB 2 have to do with the web profile?

EJB 2 was released eight years ago! It's ancient history. The folks who post here - the folks who worked on specifications like JPA, CDI, EJB3, bean validation - weren't even involved in the JCP back then! Most of us were so-called corporate developers at the time.

EJB 3.0 was released more than three years ago. If the best reason you can come up with for using Spring in 2010 is that it's better than EJB 2, then I rest my case.

...and since then it evolved much more quickly than the standards.

This is definitely not true. Not even close to true. But you'll never know until you actually try building an application using the standards.

Man, this is like WWE here. I am not so sure who the heel is though ;)

The one thing i never understand about springsource is, why they joined an EG if they never say anything? I see it here, here, here or here. If they disagree at some standard, they can explain to public. Make it better. I think it is better and I hope finally java have an universal, plugable, and great component framework that people can take advantage from it.

OOT: Im just nothing and newbie user for this area, but, I think JCP should change their vote mechanism, so people can see about the opinion from one of EG about some specs. If they are an expert, at least just give some technical review about the specs no matter they agree or disagree. It is confusing to reading something like:

xxx voted Yes with no comment.

So what??? Can you say some expert opinion to the community? JCP is all about community right? Or, should I think that my self is not part of their community?

Sakuraba wrote on Dec 10, 2009 17:07:
Man, this is like WWE here. I am not so sure who the heel is though ;)

Oh, I am definitely the Bad Guy. Grrrrrrrr.

As GKing knows full well, I don't always support his opinions, but I'm adamantly supporting him this time.

1) EJB 1.x and 2.x is basically irrelevant now for new application development. Has been since EE5/EJB3 unless we're considering legacy component support (i.e. backwards compatibility). So, for example, in these types of talks, RJohnson needs to start coming up with some better arguments than go read my J2EE without EJB book and the problems introduced into the EJB spec from CORBA and the problems inherent in EJB CMP entity beans, etc. How many new projects are actually using EJB CMP entity beans?! That book is a very good read but it's not as relevant as it was when it was published circa 2004. Although I do find his over-complexity of EE argument somewhat interesting and true. What about the over-complexity of AOP vs. interceptors? It seems to me that open-source vendors may actually want to produce/release over-complex software and technologies so that they can make more money with their training and consulting services, no? The same argument applies to SpringSource and the Spring frmwk.

2) Try out EE6, give it a chance, then start comparing/contrasting features, etc. vs. Spring frmwk. It would be a very good exercise to compare/contrast EE6 app vs. Spring 3 app. When to use which platform or tool? It depends on the needs of the app you're developing perhaps.

3) I'm guessing that most likely SpringSource and the Spring frmwk in particular has an advantage over JCP in that it can release new versions more quickly than JCP of EE (i.e. more agile) but also there is less input in their EG because there are possibly less players from the industry contributing (but I may be wrong on that). So that's good and bad at the same time.

I wish these blogs and forum posts were not focused so much on Spring vs. JEEX and essentially what can we do to dethrone Spring topics. It would be nice to compare/contrast .NET platform vs. JEE 6. If RJohnson and JHoeller read these posts they must laugh. Focus your energies on something constructive and ignore the FUD, it seems that's what they do...

299/316 iview: Nice hat. I haven't viewed this yet but I will soon...

servlets in the future will be a kind of managed bean

http://java.dzone.com/videos/gavin-king-jsr299

ok, so how bout defaulting all components/classes to SLSBs? If in EJB3.1 local interfaces are optional and these components are truly POJOs, let's default all classes to SLSBs so we can access the container services...

What about unit testing EJB3.1 classes? Is the EJB conainer still required or not? How can we unit test a SLSB DAO component that has @TransactionAttributeType annotations in it, therefore utilizing the tx support from the EJB container, without JBoss embedded container, for example?

Gavin King wrote on Dec 10, 2009 11:25:

Daniel wrote on Dec 10, 2009 08:22:
Besides Glassfish (which is obliged to) and Resin there is not much support of the Web profile on the horizon. Even JBoss AS 6 doesn't provide a web profile (or did I miss something!?).

We already have a Web Platform that is similar to the EE 6 web profile. We will definitely be providing an EE 6 web profile. In fact, we will probably deliver an EE 6 web profile first, before the full profile. And I will be very surprised if IBM and Oracle do not also provide web profile implementations.

It seems to me there should be the following editions of Java: JSE, JME, JEE, JWE. Java Web Edition. Now what is the difference b/n JWE and JEE? Why not slim down JEE and replace it with JWE and remove JEE? No longer heavyweight. This whole web profile thing is weird. Aren't all JEE apps basically web apps? They're not Swing apps, correct? There's typically a web front-end, with some kind of MVC frmwk (JSF, Struts, etc.) and security and transaction support, JDBC/ORM, possibly web services and a DBMS, no?

JBoss Enterprise Web Platform is a lighter and slimmer version of JBoss Enterprise Application Platform 5, Red Hat's solution for full Java EE enterprise applications.

http://www.jboss.com/products/platforms/webplatform/

Confusing:

JBoss Enterprise Application Platform: Everything you need to deploy, host, and persist data to Java-based web applications and services. JBoss Enterprise Web Platform: A standards-based solution for light and rich Java web applications. JBoss Enterprise Web Server: a single enterprise open source solution for large scale websites and lightweight web applications.

http://www.redhat.com/jboss/platforms/

What if you need BRMS, SOA, portals, web all for one large project or sub-projects in a master project? Then which platform(s) do you purchase?

Are these platforms new? As of when?

Trying to be like Spring/Tomcat basically (slim and flexible)...

Are you kidding me?! Spring but no Seam in a JBoss product offering??

JBoss Web Framework Kit includes popular web frameworks for quickly and easily building light and rich Java applications. By combining leading rich application frameworks, Google Web Toolkit and RichFaces, with popular Java frameworks, Spring and Apache Struts, JBoss Web Framework kit provides a single enterprise solution for popular programming styles, all under one subscription.

http://www.jboss.com/products/wfk/

What about Seam?!?!

What about this: Therefore, that future for all of our projects and platform is Seam.

http://blogs.jboss.org/blog/mlittle/2009/11/11/The_future_of_component_models.txt

Sounds like the strategy is to steal SpringSource customers and build new customer relations and trainings, support contracts...

Aren't all JEE apps basically web apps? They're not Swing apps, correct? There's typically a web front-end, with some kind of MVC frmwk (JSF, Struts, etc.) and security and transaction support, JDBC/ORM, possibly web services and a DBMS, no?

Probably true in the vast majority of apps, and these can all be migrated to the Web profile. But the full stack supports all sorts of apps that would fall under the Enterprise heading: Headless batch processing apps (via timers and JMS), legacy system integration (JCA), message bus and brokering (JMS, JAXB), etc.

Also, it would not surprise me in the least to see a Rich Client Profile in JEE7: Drop JSF and JSP from the Web profile, add JAX-RS and JAX-WS, and you're good to go. Then your Flex/GWT/Swing/Eclipse RCP apps have a common backend infrastructure.

Daniel wrote on Dec 10, 2009 08:22:

Gavin King wrote on Dec 10, 2009 04:14:
My guess is it's not attractive to Jurgen because it potentially competes with Spring's proprietary platform offerings.

That was my first guess too. The Web Profile attacks Spring's user base. But right now there seems to be a lot of truth in his words. Besides Glassfish (which is obliged to) and Resin there is not much support of the Web profile on the horizon. Even JBoss AS 6 doesn't provide a web profile (or did I miss something!?).

This has to be put into context. Spring is a product from a company. Java EE 6 (Web Profile) is a specification. Because GlassFish v3 is closely tied to the reference implementation (same underlying bits), we were first out the door. Others will follow as they weave Java EE 6 into their product road maps. Expecting many implementations on day one is not pragmatic.

John Clingan, GlassFish Group Product Manager

John Clingan wrote on Dec 11, 2009 21:33:
Spring is a product from a company. Java EE 6 (Web Profile) is a specification.

I think the main point here, and this is referring to the JEE space in general since J2EE 1.0 in the late 90's, is that the concept (with or w/o a spec) is important, the RI and other implementations are important, and the timing of the delivery is very important.

Spring Framework released circa 2004. EJB 3 released circa 2006 with EE5 (too late as the masses had started using Spring/Hibernate already). Web profile (and pruning concept) released late 2009 with EE6 (also possibly too late). And anyways, JBoss has had a pruning concept for years (minimal, full, default, custom, etc. profiles).

Bottom line: delivery is late for both EJB3 and web profile. CDI and the rest of EE6 may be absolutely fabulous (and I'm not doubting it) but the question is how will we convert the thousands of Spring projects to EE6? Can it happen? Or at least convert the enterprise Java shops to use EE6 for new projects rather than Spring 3...

If you can't beat them, join them:

http://www.jboss.com/products/wfk/

And how important is portability nowadays anyway? They keep banging on Spring b/c it's supposedly non-portable with proprietary XML, ok fine. Seam has proprietary annotations and XML as well, no? How often do we really change application servers in the corporate world? About as often as changing DB vendors?? Is portability really a big value add when you consider the probability of it even to matter??

Spring Framework released circa 2004. EJB 3 released circa 2006 with EE5 (too late as the masses had started using Spring/Hibernate already). Web profile (and pruning concept) released late 2009 with EE6 (also possibly too late). And anyways, JBoss has had a pruning concept for years (minimal, full, default, custom, etc. profiles).

So you think the JCP should be in the business of standardizing ideas that have not yet been tried out in the real world?

but the question is how will we convert the thousands of Spring projects to EE6? Can it happen?

Is that the question? Really? It's not something I've been hoping for or expecting. Isn't it enough to provider a better, and more standard, way to start out with new projects? (Or with new functionality in existing projects?)

And how important is portability nowadays anyway?

Just as important as it has ever been. Vendors come and go. Standards provide continuity.

How often do we really change application servers in the corporate world?

It happens all the time. We do lots of WebSphere->JBoss and WebLogic->JBoss migration projects.

About as often as changing DB vendors??

No, much more often, because Java EE servers are much more compliant with the standards than relational databases are with ANSI SQL, making Java EE applications much more portable. And because the EE server is not shared between multiple applications, the way a database is.

How often do we really change application servers in the corporate world? It happens all the time. We do lots of WebSphere->JBoss and WebLogic->JBoss migration projects. About as often as changing DB vendors?? No, much more often, because Java EE servers are much more compliant with the standards than relational databases are with ANSI SQL, making Java EE applications much more portable. And because the EE server is not shared between multiple applications, the way a database is.

And it's not that much about migrating. It's about writing an application and saying to a potential customer: It will run in any certified EE 6 appserver. If it doesn't, it's a bug in the AS and we'll solve it with the vendor.

And it's not that much about migrating. It's about writing an application and saying to a potential customer: 'It will run in any certified EE 6 appserver. If it doesn't, it's a bug in the AS and we'll solve it with the vendor'.

The standard also leads to feature and price competition among the vendors, to the benefit of the customer. JavaEE has been extremely successful in that account.

I'm really happy to have SpringSource and JBoss in Java culture. Well I know it is hard to hold our hands together and sing Kumbaya and I know there is no love between SpingSource and JBoss but would you please flaming each other? We are blessed to have you both, options is a good thing.

I mean stop flaming each other

I dunno. I always get a kick out of these holy wars. It's better than day-time TV anyway! :D

I actually appear to support Spring sometimes, but I really am a JEE guy and hope for the best for EE6!

The portability concern after all is sometimes important as I'm sure many projects convert from JBoss to WFOO as well... It provides assurance to the project team (like JPA, for example).

Gavin King wrote on Dec 10, 2009 13:27:
EJB 2 was released eight years ago! It's ancient history. The folks who post here - the folks who worked on specifications like JPA, CDI, EJB3, bean validation - weren't even involved in the JCP back then! Most of us were so-called corporate developers at the time.

I was a physicist 8 years ago :-)

Pete Muir wrote on Dec 15, 2009 15:04:

Gavin King wrote on Dec 10, 2009 13:27:
EJB 2 was released eight years ago! It's ancient history. The folks who post here - the folks who worked on specifications like JPA, CDI, EJB3, bean validation - weren't even involved in the JCP back then! Most of us were so-called corporate developers at the time.

I was a physicist 8 years ago :-)

Haha. I think I was still in my first job out of university :-)

Pete Muir wrote on Dec 15, 2009 15:04:

Gavin King wrote on Dec 10, 2009 13:27:
EJB 2 was released eight years ago! It's ancient history. The folks who post here - the folks who worked on specifications like JPA, CDI, EJB3, bean validation - weren't even involved in the JCP back then! Most of us were so-called corporate developers at the time.

I was a physicist 8 years ago :-)

Windows tech support here ;-)

For some very recent news, Spring 3.0 GA is compatible with Java EE 6 final

http://blog.springsource.com/2009/12/16/spring-framework-3-0-goes-ga

Sakuraba wrote on Dec 17, 2009 11:19:
For some very recent news, Spring 3.0 GA is compatible with Java EE 6 final http://blog.springsource.com/2009/12/16/spring-framework-3-0-goes-ga

For a very narrow definition of compatible. They have JSR-330. I don't think it's quite accurate to take one specification (actually, only a few annotations) and then calling it compatible

Sakuraba wrote on Dec 17, 2009 11:19:
For some very recent news, Spring 3.0 GA is compatible with Java EE 6 final http://blog.springsource.com/2009/12/16/spring-framework-3-0-goes-ga

By which they mean you can use it in a Java EE 6 container. Their own containers do not, however, support Java EE 6. And they've not yet explained exactly why anyone with a Java EE 6 container needs to add a proprietary dependency injection framework when Java EE 6 comes with CDI built-in (except for compatibility with legacy code, of course).

I looked through the Spring 3.0 blog. SpringSource might as well just suck it up and implement all of Java EE6, or at the very least Web Profile on their server (which I thought they were planning on doing). Too bad they'll have to support CDI if they go that route :P Seems like it's more and more Spring is just becoming another Java EE implementation, they just won't admit it yet.

Jason Porter wrote on Dec 17, 2009 15:39:
I looked through the Spring 3.0 blog. SpringSource might as well just suck it up and implement all of Java EE6, or at the very least Web Profile on their server (which I thought they were planning on doing). Too bad they'll have to support CDI if they go that route :P Seems like it's more and more Spring is just becoming another Java EE implementation, they just won't admit it yet.

Yes, I think that would be the best outcome for them, for their users and for enterprise Java. It would really help reduce the fragmentation of the community and platform. I suppose there is a pride issue there - they missed the boat on proposing their own JSR for dependency injection, then decided not to get involved in 299, and then at the last minute tried to disrupt 299 by proposing 330. But I think it's now very clear that a big slice of the community really wants to see EE 6 succeed, and that the Web Profile, CDI, JAX-RS, Bean Validation and improvements to JSF, JPA and EJB have answered pretty much all the traditional criticisms of the platform, as well as giving developers a bunch of brand new ideas to explore and get excited about. So it would be a great time for the Spring folks to suck down a bit of pride and reinvent themselves. Why not just support the standard APIs and give their customers a choice?