The past 1-2 years since the release of Java EE 6, you’ve seen a lot of articles like this latest on TSS that talk about the niceities of Java EE 6’s component model over Spring and how Spring is now legacy. Yup legacy. Who would have thought it? (other than me of course 😉 ) I remember internal JBoss emails 4-5 years ago arguing whether we should give up on promoting Java EE as a component model (aka on EJB) and just concede to Spring. Now, 4-5 years later, Java EE 6 has answered the challenge and is a viable, rich, integration technology. So what happened?
Spring always depended on Java EE
Spring was and has always been a wrapper over core middleware infrastructure: ORM, Transactions, Messaging, HTTP. It always depended core Java EE specs like JPA, JTA, JMS, and Servlet. So, since you couldn’t deploy a Spring app without at least one of these core technologies/specifications, Java EE stayed in users minds. There was always the opportunity that Java EE could get its act together in component model development. While Rod Johnson always tried to position Spring as a Java EE alternative and JBoss killer, the Spring “platform” was never a true alternative to Java EE and JBoss, and in fact, couldn’t really exist without it. IMO, this was a huge missed opportunity for the Spring folks.
Being the anti-Romney doesn’t work in the long run
J2EE was a machine with a huge massive install base. A machine with a massive amount of money invested into it. Java EE was its own market. While Rod positioned himself over and over as the alternative to Java EE did he really think that this massive machine wouldn’t respond to the challenge? While there are a lot of radical technology enthusiasts out there, the core Java constituency is pretty much moderate. They are slow to adopt and tend to wait to see who is going to win the war over a long time. Spring could not replace Java EE because technology wise, they were dependent on it. All Java EE had to do was improve its component API message to the people, outspend Spring, and win over it in the long run.
Annotations were a game changer
The first thing that happened to shake Spring was the introduction of annotations in Java 5. Annotations were a game changer. Annotations were the opportunity to introduce mini-DSLs and pluggable keywords into Java. Java EE 5 grabbed this opportunity with a huge facelift and refactoring of EJB and the introduction of JPA. Basically, this was a standardization of Hibernate and its integration into EJB. Complex EJB 2.x XML was replaced by few new Java keywords (well, annotations). Simplicity ruled the day. Middleware started to look more and more like a language feature rather than something hacked together via XML. When annotations came out, I remember the Spring folks writing multiple blogs and forum posts about how evil they were. IMO, they were just terrified of this new technology as it made much of Spring 2.x obsolete, and, well, much of Spring more complicated than Java EE 5.
CDI closed API hole
Thank you Gavin and the Seam folks. CDI and Java EE 5 pretty much closed the technology gap. Not only did they fill the integration holes that Spring exposed, they innovated far beyond what Spring had and created something new. Beyond core IoC and DI, CDI’s event model was truly innovative and cool.
App Servers got their act together
Application server started to get their act together with regards to boot time. It started with Glassfish and ended with JBoss 7. Both of which can boot in a matter of seconds. The whole Spring complaint that you needed Spring to mock out and test your code because app-servers started so slow was moot.
Arquillian made a mock of mocks
The final game changer was Arquillian. One huge advantage Spring had was a unit testing story. They gave you the ability to mock out core services like transactions and allow you to test application code outside of the application server. This is huge for continuation integration and automated builds as well. Combined with the fast boot times of JBoss 7 and Glassfish, you no longer have to hope your mocks will work when you actually run it in its real environment. Arquillian allows you to run your unit tests in a real environment with real transactions, etc. Personally I always despised mocks because they didn’t test in the environment you were going to run in. I thought they were pointless and to this day, I refuse to use this testing pattern.
Anyways, in retrospect, I’m glad Rod and company were able to cash out with the VMWare acquisition before Java EE was able to regain its dominance. SpringSource pushed Java EE to innovate and for that I’m very grateful. For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.
Bill the Plumber 
Mar 13, 2012 @ 14:27:40
Spring has moved on. Javaee will have to catch SpringData and mongo and the cloud. You’re claiming that the last one left at the party wins. In truth, he just gets to clean up the mess when everyone moves on!
Mar 13, 2012 @ 14:43:03
Your comment doesn’t change the fact that Java EE has a monopoly in the Java world over a few of the core, fundamental technologies that are required to build a very large set of applications. Anyways, data grids, no-sql, and cloud are complements to the core Java EE platform, not replacements.
In fact, I hope and pray Java EE 7 and beyond focus more on refactoring themselves to fit better in these environments than creating new specifications in these areas. We all know from experience what a mess that can be. But thats a different blog post!
Mar 13, 2012 @ 19:00:23
But that is irrelevant to the point. Spring is a programming model and cross platform runtime. It never competed with JavaEE in the lower levels and always used it. In Spring you have a programming model for the new and the old. Javaee’s model doesn’t cover the new.
Sep 24, 2012 @ 05:43:56
Gentlemen, I believe that you’re focusing on the wrong questions. I have nothing against one framework or the other becoming dominant in one space or another, but it is quite another thing to hope for another framework’s departure from the market. Clearly, we can see how JavaEE benefited greatly from the challenges presented by Spring, Hibernate and Seam, as well as others. This model of cross-pollination has been immensely valuable to the Java community over the last decade.
Diversity of valid options is the key, here. I believe that Spring has managed to carve out a number of niches in the Java ecosystem that allow it to continue to contribute options and ideas. It is true that JavaEE has come a long way, and personally speaking, I believe that the JPA/EJB/JSF technology stack covers a lot of ground very well. I’m still trying to figure out where CDI fits into all this; right now, I’d just like to see its features integrated into EJB (especially its approach to dependency injection, and extending the conversation scope).
Mar 13, 2012 @ 16:08:29
You are confusing integration testing and unit testing. Arquillian is for integration testing. Unit tests by definition only exercise the individual object under test and verify interactions with other interfaces. By running tests in any “real environment,” you are no longer unit testing but integration testing. Mock frameworks allow you to verify interactions with other interfaces (ie Mockito) and are not replaceable by running against real transaction in real environment.
Mar 14, 2012 @ 04:34:43
Have fun writing and maintaining your mocks. Its becoming more and more of a pedantic exercise.
Mar 14, 2012 @ 13:43:58
In that case, nothing is stopping you from “Unit testing” Java EE, either 🙂
Mar 13, 2012 @ 17:09:44
> Java EE has a monopoly in the Java world
While I certainly agree that CDI has shaken Spring more than they like, I don’t feel the sentence above is right. That would be like saying “HTTP has a monopoly in the WWW”.
The real point is that there is exactly one Spring framework but a lots of different (but spec compliant!) EE servers and you can even plumb together your own one by just taking tomcat/jetty/Deft and stuff in a few jars. In fact EE is not a monopoly, but au contraire it opens the way to freely choose your vendor again!
Mar 13, 2012 @ 17:14:30
Yes, Spring is dead. Or dying. Or something like that. And it just wraps Java EE tech because Java EE has always addressed key issues app devs are facing today:
Mongo
Hadoop
Reddis
HBase
GemFire
AMQP
ESB patterns
Real security
Mobile
Social integration
Web flows
Batch processing
Whatever, dude. Keep fiddlin’ with specs, JSRs, and stuff like Ceylon (can’t even write that word without snickering). Spring will just keep on giving people what Java EE can’t.
Do you really think this massive machine won’t respond to challenges?
http://www.indeed.com/jobtrends?q=spring%2C+java+ee
Mar 14, 2012 @ 04:32:10
For the problems it tries to solve, Java EE is winning against Spring.
Mar 14, 2012 @ 12:20:03
So you decided to narrow the scope of the problems enterprises face today. . . But they are still there. Who is going to solve them?
Mar 14, 2012 @ 13:23:16
@Oleg, you make it sound like Spring is the only company solving problems. It kinda sickens me that you’re so brainwashed.
Mar 14, 2012 @ 14:32:15
That is not what I said, but it seems as that is what you read. I’ll leave it up to you but with small clarification. . . All i was saying is that the scope of requirements for modern enterprise application is far beyond what JEE has to offer and therefore Spring moved on to keep up. You guys seem to still want to fight yesterday’s battles.
Mar 14, 2012 @ 20:09:50
Thanks for clarification Oleg, but I’m not sure I agree with your assessment of the industry. Java EE is still a solution for a large set of problems. My guess is that Spring is trying to push into these markets because they are losing the traditional market battle. Just like BEA/WLS started pushing into “Liquid Data” when JBoss was eating up their margins. I’m just glad Red Hat has stuck with Java EE as now we’re in a position of strength in both traditional markets and some of the new ones (No-SQL, Data Grid, PaaS, etc.).
Mar 14, 2012 @ 14:16:57
Hmm…
http://www.indeed.com/jobtrends?q=spring%2C+java+ee%2C+summer&l=
Hmm, and now…
http://www.indeed.com/jobtrends?q=spring%2C+java+ee%2C+summer%2C+spring+framework&l=
Seems you forgot to substract students looking for spring break job.
Mar 14, 2012 @ 14:37:42
And yet one more interesting:
http://www.indeed.com/jobtrends?q=j2ee%2C+java+ee%2C+spring+framework&l=
Nov 14, 2012 @ 06:50:03
Quote from above: http://www.indeed.com/jobtrends?q=spring%2C+java+ee
😦 This is not helpful. Supposedly these are the job demand facts – but you give little accuracy and meaning. Firstly, 75% of the jobs with spring in the title say “Spring 2013”, “Spring Hill”, “Sandy Spring” or “Spring Accounts Intern” and the like and do not mention java and have nothing to do with IT. Compare “spring”, “spring java” and “spring -java” – give 100%, 25% and 75% splits respectively. Secondly, “java ee” doesn’t get remotely close to hitting JEE jobs on offer – (java AND ee) OR “jee” OR “J2ee” OR “java ee” OR “enterprise java” OR “java enterprise” is closer.
Try this:
http://www.indeed.com/jobtrends?q=spring+-java%2C++%28java+AND+ee%29+OR+%22jee%22+OR+%22J2ee%22+OR+%22java+ee%22+OR+%22enterprise+java%22+OR+%22java+enterprise%22%2C+%22Spring+Data%22&l=
Also Jobs with “Spring Data” requires an advanced search:
http://www.indeed.com/jobs?as_and=&as_phr=%22Spring+Data%22&as_any=&as_not=&as_ttl=&as_cmp=&jt=all&st=&salary=&radius=25&l=&fromage=any&limit=10&sort=&psf=advsrch
Returns 31 jobs. Total.
So ratio of jobs, Spring : Java EE = 1 : 2.2 (today) compared to 1 : 2.3 (6-7 years ago) – i.e. more or less constant over the period before JEE6 impact.
The OP’s point stands – the large change in JEE6 to simplicity, power and plain-old “outdoing spring” will change this. If you have an app server then you can just use JEE6 without needing to install the non-standard Spring branch of java. Most developers who try JEE6 will love it because it’s simple, streamlined, powerful, needs little in the way of tooling, but has great tools available regardless. Most won’t want to use Spring anymore.
JEE6 usage will surge going forward – and the power and flexibility of being able to combine selected polyglot JVM languages like Scala, Groovy, JRuby, Jython and Clojure to match specific business and technical needs will really help this. Also JEE will (eventually) provide some standardised support for the cloud in JEE8 – in the meantime, non-standard support will arise in proprietary toolkits and app server features. ‘Tis the cycle of innovation & then standardisation. Spring Data will gain some traction in the interim, for interfacing with Hadoop & MongoDB but less face it – this will never be the same as the original “Spring core” uptake, because it’s way too specialised.
Feb 23, 2013 @ 05:32:36
> Mongo
> Hadoop
> Reddis
> HBase
> GemFire
> AMQP
> ESB patterns
> Real security
> Mobile
> Social integration
> Web flows
> Batch processing
> Whatever, dude. Keep fiddlin’ with specs, JSRs, and stuff like Ceylon (can’t > even write that word without snickering). Spring will just keep on giving
> people what Java EE can’t.
Not sure what your point here is?? If Spring can deliver anything… then by definition the standards can deliver likewise. In the case of JEE6, the standards have actually leap-frogged and given an even more powerful and streamlined solution. Sure they were way too slow in getting there, but they eventually got there – a big lesson learnt in the evolution of Java that shouldn’t be repeated.
It’s good that Spring has wrapper glue to expose a homogenous API to leverage No-SQL DBs. But not as good as a standard homogenous API. Back in the day would you use JDBC (standard) or an equivalent proprietary DB wrapper from some company that railed against standardisation? JPA extension is being undertaken to do this – e.g. see EclipseLink’s current implementation with involvement of key players behind JPA 2. i.e. more standardisation required.
ESB patterns… supported by many decent ESBs and integration tools out there and many architecture & design modeling tools, including open source tools. Just as App Design patterns are supported by many decent UML/Archimate/SysML/Enterprise Architecture tool.
Real security… supported by many decent IAM tools, including open source tools such as Shiro and OpenAM, and also within many app servers. Obviously more standardisation would be good!!
Mobile… JSF is killer here supporting simple and direct HTML5/Javascript/AJAX via Facelets pages with great templating and drag n drop IDE HTML/JSF components, for responsive rich web design, Also supports more specific adaptive mobile design (secondary mobile websites) using JQuery Mobile/ through implementations such as JSF Mobile / primfaces mobile / richfaces mobile / icemobile.
Social integration… more standardisation required here, although OAuth and REST are a basic start.
Web flows… JSF 2 is killer here.
Batch processing… JSR 352 batch processing standard intended to be included in JEE7. Also JSR 356 concurrency utilities for JEE (scheduled, concurrent, asynchronous, operations for EJB and Servlets).
Bottom line – proprietary functionality is fantastic as long as it’s innovating, doing something new, simplified and valuable. However it should be replaced by simple, rich, standardised functionality as soon as the standards bodies can catch up for maximum portability, developer familiarity & productivity, and for the sake of the competitive technology ecosystem. There is a place for Spring functionality on the ever-moving bleeding edge, but not when it overlaps with standards and common functionality.
Mar 13, 2012 @ 18:06:28
Thank you Gavin and the folks at Seam for innovating, i.e. borrowing, things like Spring Social and renaming it to Seam Social (git clone https://github.com/seam/social and grep for “@author Craig Walls”). I’m sure that Seam is now front and center the leader of the technology pack, we can look forward to more innovative things to come.
Mar 14, 2012 @ 04:44:20
And Spring is the birth of all new ideas…please…they borrow as much as anybody.
Mar 14, 2012 @ 12:24:39
Bill, the reference was made to a very specific fact in the specific framework while yet again you’ve provided a very general response. Can you please be more concrete?
Mar 15, 2012 @ 13:24:17
DISCLAIMER: I’m Seam Social Spec Leader (the guy you even don’t mention in your Troll)
Yes most of the binding code of Seam Social is borrowed from Spring social. This code is not related to Spring it is related to Twittter, LinkedIn, Facebook & co. It’s plumbing code to map Json request to and from Social Network providers.
I would have been pleased to work with Spring Social team to share this code and find a way to collaborate with them instead of copying and pasting most of it. But they never answered my mails and tweets.
I thank them to save me time on this fastidious (but no brain) part but I’m also sorry to see that those people are snobbish enough to even talk to me to say “no”.
So you know how to use Git and Grep to troll on others work. Good for you. But if you’d had learnt Java and CDI as well, you could have seen that the core framework’s code of Seam Social has nothing to do with Spring social and is far lighter and polymorphic to do the same.
To conclude I hope that most people in Spring community will do the same as Spring Data team by providing CDI compatibility in their framework : https://github.com/SpringSource/spring-data-jpa/blob/master/src/main/java/org/springframework/data/jpa/repository/cdi
That’s clever and that’s my idea of a community.
Mar 13, 2012 @ 19:34:54
I don’t really see how JEE wins over Spring. Looking at the history of the JEE/Spring “fight” it seems obvious to me that – as you said at the end of your post – each was powering up the other’s progress. Spring was taking the good parts of JEE stack and providing replacement for the broken parts (like EJB 2.x – or even EJB 3.0 which, while letting us do the job in almost POJO way, provided only a poor man’s IoC container). It’s much better than developing a completely separate stack and duplicating nice things like Servlet API. And I don’t see a reason why Spring would now die. I think they have user base big enough to live for long and are smart enough to build new things that people now will use (like Spring Social or Spring Data).
And of course it’s totally not true that you couldn’t have a Spring app without any dependencies on JEE. Not every app needs to expose a web frontend and send messages via JMS. So Spring can live without JEE – and probably if JEE didn’t have some good parts it would provide an alternative, complete stack on it’s own. Or maybe develop a totally different solution?
As for annotations based configuration being a killer feature – yeah, I loved it when I first see it. But now I’m kind of afraid of them, having seen how getting rid of XML configuration enables people to inject everything everywhere. What I saw made me sure that annotations are powerful but dangerous – they let you make a big mess easily. Now I’d rather prefer some explicit configuration using some XML (yeah, I might be considered an alien) – or even better: code! – than having to guess what get’s injected where and why. Convention over configuration is a nice thing, but explicit will always beat implicit for me. And then XML based-config enables me to keep the core of my system independent of any API, be it JEE or Spring (I want no @Resource, @EntityManager or @Autowired there).
As for testing: first – tests using Arquillian, Spring context or a database are no unit tests. Second – no matter how fast you make your server (or Spring – that’s the same effect in a larger scale) start up and run you won’t beat the performance of pure unit tests. But forget unit tests – let’s talk about integration/functional/whatever-not-unit tests. If I have a system made of several components, each made by a different team in a different place in the world (that’s how my current project looks like), I don’t want my tests to depend on whether the guys 1000km from me did introduce some bug in their implementation. I want my own, safe and predictible mock (or rather fake) that implements the API of that system. I will test the full system, with all real components, at another level.
And for testing as close to real env as possible – yeah, you should do that. But they are trade-offs you have to make. Like keeping the tests fast. For this reason we’re using in-memory databases for running our tests before check-in, instead of full-blown Oracle server. For this reason I’m mostly doing development on good, old Tomcat6, not JBoss 5 (yeah, that’s old and damn slow but our first customer insists on using it as they’ve got some JEE apps running on it – hey, are they afraid to migrate JEE5-compliant apps to another JEE5-compliant server? 😉 ). As a developer I don’t want to spend much time waiting for a build to finish. I want it finish quickly. All the environment-dependent corner cases can be checked on a separate build on CI server.
Ah, that’s a long comment. But I really don’t like this whole Spring/JEE fight and I’m a bit alergic to victory claims of either side as long as both stand on their feet. That’s a bit early (yeah, I know you’re involved on one side so I take it as a marketing action). As for me, I’ve used both. Currently I’m using Spring but I like to think I’m not biased toward any side 😉
Anyway, thanks for the post – even if I don’t agree I now want to sit down and try out what it feels like creating a JEE 6 app.
Cheers!
Marcin
Mar 14, 2012 @ 04:42:08
I just don’t agree with your statement that XML keeps the core of your system independent of any API. Unless you’re not using any piece of framework at all, your code is going to be dependent on the behavior of your framework. With an annotation, you can look at code and know the behavior being applied as the framework becomes basically part of the Java language. This is primary the reason I ditched AOP. Hiding behavior is bad.
Mar 13, 2012 @ 19:59:36
Great assessment of what Java EE6 is doing now. I love J2EE 6’s simplified core functionality that was once Spring’s forte and I do agree that EE6 has Spring beat on that front. However, I agree with Andy though that Spring’s focus has shifted quite a bit. There are far more concerned with their vFabric cloud-based platform for virtualization of applications making use of their lightweight Tomcat container, GemFire and RabbitMQ. Being able to fire off new instances of a container in seconds based on demand is becoming the central focus of large-scale enterprise applications. I do not know if EE6 can compete on that playing field yet with Spring.
Mar 14, 2012 @ 04:30:09
JavaEE is orthogonal to the issues you’re talking about. Besides, Spring is far from the only game in town. In fact, they are incomplete in the technology stack.
Mar 13, 2012 @ 20:06:07
“Personally I always despised mocks because they didn’t test in the environment you were going to run in. I thought they were pointless and to this day, I refuse to use this testing pattern.”
IMO when you don’t use mocks, you are headed towards testing the whole system at once. This is what leads to the hell of 10 hour test suites. You do need to test the whole system, but that should happen only after your unit tests pass via integration tests.
Unit tests shouldn’t be reliant on databases, external services, or other products. These should be mocked.
Mar 14, 2012 @ 04:27:24
Have fun with that…
Mar 14, 2012 @ 14:12:52
“Have fun with that”
Incredibly professional response to someone’s detailed clarification of unit vs. integration testing.
Regarding mocks, yes, LOTS of people are having fun with finally being able to isolate units and accomplish fast, effective unit testing. It’s better than the system wide testing I had to deal with at the beginning of my career. Things like mockito really make testing fun and pleasant. Besmirching other people’s usage of such powerful tools seems a bit juvenile.
Regarding Java EE, well, have fun with that.
Mar 14, 2012 @ 20:12:04
@Lee
Go read Stan Sylvert’s comment. It pretty much sums up my experience and feelings about mocks. Mocks are niche now that we can efficiently test with the real thing in most scenarios.
Jun 15, 2012 @ 18:18:14
Dude, what’s with the mock hate… @Mockito (and a host of other similar tools) = win. Fast, easy to mock, Unit tests…
Jun 15, 2012 @ 18:30:13
read my follow up blog on mocks. Don’t care if @Mockito is easy, its still artificial testing.
Mar 14, 2012 @ 11:36:08
When you DO use mocks you are testing in an environment that is biased toward a passing test. An artificial environment will always make invalid assumptions about the behavior and stability of that environment.
What you end up with is a (hard to maintain) mock library that allows your tests to pass and gives you a warm feeling that you’ve done a great job. But you are fooling yourself.
The ONLY reason to use mocks is when test execution in the real environment is unacceptably slow. This used to be the case quite often. But with frameworks like Arquillian and super-fast startup times for app servers this is no longer a frequent concern.
I’ll end with an even more radical assertion. The difference between integration testing and unit testing is purely semantic. Even the smallest, most focused unit test pulls in a lot of the environment (JVM, OS, etc). In-container testing just pulls in more of the target environment and allows you to find more errors sooner.
Test in the real environment and get results that are truly valid. Stop kidding yourself with mocks.
Mar 14, 2012 @ 14:16:25
“In-container testing just pulls in more of the target environment and allows you to find more errors sooner.”
Except when in-container test suites start to approach 2 hours, and then nobody runs the test suite anymore. Don’t tell me you’ve never heard of this before?
Having things like faster container startups is great for CI servers so that integration tests get run with some frequency, but it doesn’t replace the need for smaller, faster unit and smoke tests for the developers to know their last change didn’t break the whole system.
Mar 14, 2012 @ 14:56:19
“Don’t tell me you’ve never heard of this before?”
Did you even read my post? I acknowledged that this used to be the case, but the days of the 2 hour in-container smoke test are over.
Since mocks no longer provide much of a speed advantage their use is outweighed by the fact that they give you a phony environment, maintenance headaches, and false confidence.
But you do touch on a truth about testing that a lot of people miss. The purpose of testing is to uncover errors. And you will uncover more errors in a real environment than you would in a mock environment.
May 21, 2012 @ 12:35:51
Those people that think there is an absolute difference between integration and unit tests are IDIOTS. I’m almost sorry to be insulting about this but I’m not… the amount of time and money I see wasted on mocking at the lowest levels is frankly outrageous. Such as introducing an interface hierarchy instead of using concrete classes just so that there can be an equivalent mock implementation version.
Not to mention the fact that the code is that much more brittle because of these code level mocking dependencies that have been introduced: if you change the implementation then step back and see all the additional work you have to do to either refactor or even rewrite the tests!!! Weighting your tests to the actual business requirements allows you not only to self document the code in a meaningful way, but also you could completely change the underlying language if you wanted to as an example.
I’m not saying these techniques aren’t valid, but start off with a simulation based testing environment that uses *genuine* launch scripts, *genuine* database code etc and actually, you know, tests the business requirements. Then if one of the tests is unacceptably slow or hard to reproduce (e.g. exceptional behaviour), then by all means go in at the lower levels. To do the other way round is just premature busy work.
May 21, 2012 @ 14:35:07
Thats the thing…I want people to think and question. Irritates me to no end when people just blindly follow…
Jul 19, 2012 @ 12:11:24
For those who think that integration test are are holy grail
http://www.infoq.com/presentations/integration-tests-scam/
Jul 20, 2012 @ 17:50:42
Piotr,
I watched about 15 minutes of that video. Under his definition of a scam, his ideas are a scam. About 8 minutes in he reveals that his entire argument is based on the assumption that integration tests are slow. That is no longer true.
Mar 13, 2012 @ 20:34:51
Bill maybe you are paid big to write this kind of slanted nonsense. In essence you want me to shell out a tonne of money for licenses for these useless servers. Your view is slanted to suit Oracle and other big players behind JEE. If one is doing a webapp of industrial strength, I would ask them to use spring and good old tomcat. Challenge you to tell me what is not possible with such a setup(so that I will run and get a $$$$ JEE server)
Mar 14, 2012 @ 04:26:37
Maybe you haven’t heard of this pretty cool Java EE app server called JBoss? How about Glassfish? You don’t have to pay big bucks anymore for full Java EE. Spring is really no different than Red Hat in what it asks its users to pay for. Good luck with rolling your own app server with Spring + Whatever 🙂
Mar 14, 2012 @ 15:27:59
@billburke:Here is a trend for your info Bill:
http://developers-blog.org/blog/de/2010/02/24/Trend-between-Spring-and-EJB-job-requirements. Means people don’t want to look at old good wine(spring) in a new bad bottle. Now why would people do that Bill? You are trying to resuscitate something that is dead(iow, JEE).
Also wait for Oracle to buy JBoss..they tried once before, but the next time they will be successful and then that “free” you mention will be gone.
Mar 14, 2012 @ 20:22:10
@ameelin how is this any different than Spring? Which was bought by a closed-source company VMWare. Spring is controlled by ONE COMPANY. It is not an independent open source organization like Apache. At least with Java EE there are multiple OPEN SOURCE implementations. How long before VMWare decides its $500 million investment needs to be recouped and they start charging for Spring in a big way? Don’t think it can happen? Think again…VMWare is in the same poor position BEA/WLS was against JBoss with Red Hat’s VM/Cloud tech eating away at VMWare’s margins. There is a much higher chance of them scrambling for revenue sources than Red hat ever being acquired by Oracle.
Mar 13, 2012 @ 21:46:44
i agree with Andy,and for me all what JavaEE is trying to do is catching its big late and reproduce every pattern Spring had already thought about .Beside don’t forget that the JEE we are talking is new and havn’t been verified in the context of big and risky project ,Spring did that a long time ago .
Mar 13, 2012 @ 22:01:59
just LOL. Author is so funny guy…
Mar 13, 2012 @ 22:02:01
Spring 3.1 could run on a JSE 1.5 J2EE 1.4 appserver of 5 years old.
Most big companies still run on those environments. Upgrading appservers is often seen as too risky, forcing developers to keep old, slow programming methodologies.
The need for centralized updating of containers vs ’embedded’ container deployment in Spring applications is the killer feature of Spring.
So JEE should:
* not force organizations to do ‘big bang upgrades’ of containers that run often tens or hunderd of applications
* allow applications to ’embed’ their own container if they desire to do so.
If JEE fixes that they might win and make Spring Core history. Until than I am happily using it ;).
Dec 03, 2013 @ 06:54:35
“Spring 3.1 could run on a JSE 1.5 J2EE 1.4 appserver of 5 years old.
Most big companies still run on those environments”
Where is your data to back that up? I’ve worked for many big companies, and most of them tend to be on the latest stable version or the one prior. In my experience, there was a shift in big companies over the last decade to be on the latest version, including patches, mostly because of security concerns. Maybe you have memories from 10 years ago and since then you’ve been stuck on Tomcat and Spring?
Dec 03, 2013 @ 15:56:49
Us Java EE guys *ARE* getting old…I often worry that I’m 10 years out of date, that is, until I go see what the script kiddies are doing.
Mar 14, 2012 @ 00:12:42
There are some best selling core Spring 3 books, such as Spring Recipes 2nd Edition. There is another core Spring 3 book in the pipeline, Pro Spring 3.1.
I haven’t seen an in-depth JavaEE6 component book yet. Is this an indication of the popularity of Spring 3 vs JavaEE6 component model in the Enterprise?
Mar 14, 2012 @ 05:01:53
Click the “Publishing” link on my blog. Follow the link to the EJB 3.1 Book written by Andy Rubinger. The book has been out for more than a year. Thats just one example.
Mar 14, 2012 @ 21:22:18
@billburke: Andy’s EJB book is like an old scary album one hid in their attic…Why do we still have to use the EJBHome, EJBLocal garbage?? Iow, you need 3 objects to prop up a service. Yeah…and Andy says it is “for backward compatibility”. Get this…People who got burned with EJB 2.x have all adopted Spring and never coming back…so who needs backward compatibility? 🙂
Also Spring is a take-what-you-want-and-use framework unlike EJB which is an take-all-or-nothing framework . Plus easy real-world testing(mock…really useless for real world as discussed here). Also someone pointed out spring could be used to make the tiniest(like a desktop java app) to an industrial strength webapp. The abstractions it provides to hook other frameworks in(like for example quartz, jms) is unparalleled in the Java world.
Mar 14, 2012 @ 23:08:41
That book is crap:
Bill, you have written very good books about EJB2 and JAX-RS in the past. Why don’t you write a book about CDI and EJB3.1 (in the context of CDI) yourself, with a chapter about how they can be used with JSF at the end of the book?
Are you afraid a book about JavaEE6 component model will not sell 🙂
Mar 15, 2012 @ 04:01:38
Writing a book sucks. You might see a JAX-RS revision, but, other than that, you won’t see another book from me until I do a new project which isn’t in the foreseeable future.
Mar 15, 2012 @ 19:50:21
I’m not entirely sure what a “Java EE 6 component book” should exactly describe, but there are quite a number of books about the different APIs of Java EE 6:
Core JavaServer Faces
JSF 2.0 Cookbook
JavaServer Faces 2.0, The Complete Reference
EJB 3.1 Cookbook
Enterprise JavaBeans 3.1
Beginning Java EE 6 with GlassFish 3
Java EE 6 with GlassFish 3 Application Server
Java EE 6 Development With NetBeans 7
Real World Java EE Patterns Rethinking Best Practices
Real World Java EE Night Hacks Dissecting the Business Tier
Mar 16, 2012 @ 01:34:57
Non of these have serious coverage of CDI. Many of them are actually on JAVA EE5.
Mar 17, 2012 @ 11:26:09
@George Jiang
For starters, nothing in the prior discussion specifically mentioned that CDI should be covered. Although there’s no book that exclusively deals with CDI yet, the first book on the list already covers CDI in the context of JSF 2. Cay Horstmann has been a strong supporter of using CDI instead of JSF native managed beans from day one.
“Java EE 6 with GlassFish 3 Application Server”, “Java EE 6 Development With NetBeans 7” , “Real World Java EE Patterns Rethinking Best Practices” and
“Real World Java EE Night Hacks Dissecting the Business Tier” all have CDI coverage.
This is blatantly false. The books are about JSF 2, EJB 3.1 and Java EE 6 in general. The first two are APIs in Java EE 6, the latter is obviously about Java EE 6.
Mar 14, 2012 @ 03:12:46
‘Victory’ being declared for J2EE by someone working for Redhat seems… underwhelming. Besides, isn’t there room in the world for competing integration pieces so we can pick and choose the best bits?
Mar 14, 2012 @ 13:29:51
@Dave, as I said in the blog, I’ve seen more and more articles written by non-JBoss people, presentations at conferences given by non-JBoss people, and talked to a bunch of others stating the same thing. There’s less and less reason to use Spring to solve traditional problems.
Plus, if you’ve heard Rod Johnson speak he is always adamant that Spring has replaced Java EE. Its good to see that his rhetoric is utter BS!
Mar 14, 2012 @ 03:34:17
we still need a simple MVC framework for those who do not like JSF. We still have to go and download one which is really annoying. To bad JAX-RS 2.0 dropped MVC support.
Mar 14, 2012 @ 13:25:34
Sorry, even Spring MVC sucks as much balls as JSF does.
Mar 15, 2012 @ 06:13:15
Yes, Web MVC is re-gaining momentum. ASP.NET MVC is over-taking ASP.NET Web Form in popularity.
Java EE definitely should include a standard Web MVC framework similar to JAX-RS. Still not too late for EE7?
Mar 15, 2012 @ 19:56:19
I personally think JSF 2 is pretty good and a major improvement over JSF 1.
REST support, possibly via JAX-RS would be great though. JSF 2 made large steps to make GET requests a first class citizen and view actions further consolidate this. Would true REST support be that difficult to support?
Mar 15, 2012 @ 23:55:16
What is needed on the Java EE platform is a better Struts2 or a better Spring MVC which is integrated with CDI. The JSF GET support does not help much here.
Mar 14, 2012 @ 06:18:51
Hi
Today it is 2 years, 3 months and 5 days since the release of the latest and greatest JavaEE 6. And believe me – there are places where you still have to deal with WebSphere 6. And guess what I’ve done in such place – I’ve deployed a WAR which contains Hibernate 4, Spring 3.1 and Thymeleaf for the view, reducing the 10K$ worth server into HTTP-to-HttpServletRequest engine with JNDIName-to-DataSource mapper. And it works like a charm.
I still hear the arguments “see how great Glassfish and JBoss are – they start in under 2 seconds”. I know JBoss well (since 3.0.x version) and I know it’s good and bad parts. JBoss 7 is (finally) a total rewrite and it’s great (really!). But can it replace WebSphere 6 in places where it was bought? I don’t think so.
@Bill, you wrote “For the problems it tries to solve, Java EE is winning against Spring.”. What do you mean? Does this implies the statement “For the problems it doesn’t try to solve, Java EE is loser”? I deduct that Java EE is loser in the fields of security (an important aspect of enterprise systems – at least for some people), batch processing, MVC, testablity (Arquillian is RedHat product – I haven’t heard of Arquillian JSR)…
@Bill: “Good luck with rolling your own app server with Spring + Whatever” – do you in JavaEE think that rolling ones own application server is *always* the first activity developers do with Spring? That’s ridiculous. When one doesn’t need XA Transactions (I’ve needed them once – and I haven’t used App Server at all) you just put a WAR into Tomcat/Jetty/JBoss/whatever and it works.
regards
Grzegorz Grzybek
Mar 15, 2012 @ 21:18:26
Grzegorz, as I’ve argued many times before, you’re having a social problem there.
Your client or boss doesn’t want you to upgrade, for whatever reason and behind their backs you’re using Spring to sneak updates into production anyway.
Now maybe you’re right, and your client or boss should not claim practical ownership over something they do not understand. However, the root problem should be recognized for what it is: a social problem, not a technical problem.
I’m not really sure if Java EE should address this and I’m not sure whether a tagline like “Java EE 7, now capable of betraying your boss” really flies. But as this is basically the ONLY argument where each and every Java EE vs Spring battle always boils down to, maybe Java EE should indeed specify a “full AS embedded mode”.
In this mode an implementation like GlassFish could then be tucked away in a war, which perhaps contains another war that is the real application. This effectively reduces whatever platform it’s being deployed on to a mere bootstrapper.
With all the embedded and modularity stuff that has been going on in both Java EE and Java SE, this might not even be that impossible.
But again, realize that the root problem is social and political and you’re trying to solve it with a technical “solution”.
Mar 16, 2012 @ 06:10:19
I’m a technical person and it seems better to deploy WAR with all I need *to* WebSphere 6 than unzip JBoss 7/Tomcat 7 *next to* WebSphere* (maybe deploying there some redirecting rules). Period. WebSphere 6 is there and I (and even my company) won’t change it.
The above makes me treat *all* application servers as some kind of infrastructure – app server is closer to OS than to my application. By sticking to this image, I must put whatever I want into WAR, not into app server (I *have* experience with JBoss and with version 7 configuring jboss-modules is *really* clean and beautiful!).
Still the above makes me think that JavaEE proponents (or rather Spring opponents, because for me JavaEE is *not* an application server, but a bunch of APIs – good or bad) present JavaEE as some kind of cure for developers problems – and I agree that the original idea of JavaEE is just this – give you the APIs and some kind of vendor neutrality – that’s one of the main points in such discussions. But reality is different – APIs and TCKs (by the way – can you or someone give me access to JAX-WS TCK? No. Just as I expected) *can’t* cover implementation differences. So I’m not telling I’m using just JPA – I’m using Hibernate, because there *are always* some quirks.
JavaEE proponents talk about vendor neutrality and Spring’s vendor lock-in. Do you really believe it too? My experience (10+) is different – with JavaEE you’re more locked in with app server (the more expensive server, the more you’re locked in) than with Spring. Why so? With Spring I have access to github and subversion – to all tags and branches (there was one incident in the past, but who’d remember). With JavaEE do you *really* know what you’re using? Just check WebSphere 7.0.0.21’s “\plugins\org.apache.axis2.jar\META-INF\maven\org.apache.axis2\axis2-jaxws\pom.xml” file – you’ll be surprised.
I’d really like to treat app server like part of my system – and it is possible with Jetty/Tomcat, even JBoss. It’s not possible with WebSphere, when someone other pays the licence fees.
So I’m aware I have social problem, but I don’t think I’m the only one.
regards
Grzegorz Grzybek
Mar 17, 2012 @ 11:52:29
@Grzegorz Grzybek
That’s still a flawed model.
The thing is you can’t upgrade your Java SE version nor Servlet version this way. You’ll be stuck on J2SE 1.3 and Servlet 2.3 (or whatever archaic version your company digs) forever.
In a much saner process, the development team builds the application using the technology they have decided works best. Being hired for their expertise in this area they are the primary party to indeed make this decision.
The application is then iteratively deployed into production. If the “JDK part” of the application changes, this is deployed. If the “AS part” of the application changes, this is deployed. And finally, if the “business part” of the application changes, this is deployed.
That way, you deploy a very slim war say every week, a JDK every few months (minor JDK update), an AS every 6 months and a major JDK update every few years.
For operations, they are all “deployments”. There is no concept of an “installed AS owned by operations”. Important in this model is also that an AS runs one application and one application only. With the advent of virtual servers this is relatively easy to realize and an order of magnitude easier to support.
(Spring being owned by VMWare should acknowledge this model more than anyone else)
I’m not really sure I follow this line of reasoning. If I develop a Java EE application for a specific client, then yes, we know EXACTLY what we are using. All the source code of JSF, EJB, CDI is just as available in a source repository with all tags and all branches open to see for everyone. What on earth makes you think this is something only Spring has?
Why do you think Spring is more open source than JBoss AS, GlassFish, TomEE, Geronimo, etc? For all of those ALL source code without ANY exception is readily, easily and freely available.
Additionally, with Java EE there’s often not only a public JIRA where you can create issues and submit patches for implementation issues, but there’s also a public JIRA for the design process.
Mar 17, 2012 @ 18:49:43
@henk53
You’re right – Spring has some minimum requirements and WebSphere 6 uses Servlets 2.4 and Java 5.
If the customer runs JBoss 4/5/6, I’d suggest replacing it with JBoss 7. With WebSphere 6 it’s not that easy – why change it to WebSphere 7 (and pay) when “everything works”?
There’s one flaw in your process – I’ve been through part 1 (JDK changes) and it was great – finally I could use generic. I’ve been throug part 2 (AS part) and it was pain because first the application was too dependant on WebSphere 5 (you know – MDBs, EJBs, other) and when the WebSphere 6 was bought we’ve worked for several hundred man-hours to make it run on WebSphere 6 – partly because we could now use JSP 2.0 and partly because there were many deployment and dependency problems.
Part 3 is obvious – we have to deploy when there are new requirements. But why change something when app server is being replaced?
My biggest problems with JEE (I’ve started with version 1.3) is that every version brings new APIs/techinques and sometimes deprecates old. Often the changes in APIs are so big that it is really new API (see EJB 2.0 and 3.0).
In enterprise programming, changing programming model for the sake of change is pure waste of money. It doesn’t bring any business value! If suddenly someone would replace WebSphere 6 with WebSphere 8 it would not be a reason to change our architecture to use CDI.
I’m not against JavaEE – I’m against connecting your app’s lifecycle with the lifecycle of JavaEE. JavaEE has many great APIs (e.g. bean validation) and I can use the implementation of choice just after there will be proper tag on github.
JavaEE 6 is almost 2,5 years old. During that time many things have changed. I can use Hibernate 4.1 now without waiting for JavaEE (which of course once again will make Java Enterprise Developers’ life simplier and which again will make Spring-* obsolete). Why wait for JSR352 (batch) when there are existing solutions right now? Why wait for JSR353 (JSON) when there are many implementations right now? What “JavaEE advocates” will be writing after JavaEE7 release – that Codehaus’ Jackson is proprietary solution – don’t use it? That Spring Batch leads to vendor lock in?
I have a feeling that every new JavaEE revision has less impls per APIs then before. Does renaming packages from “com.ibm.batch” to “javax.batch” is a solution to vendor lock-in?
Spring is just as open source as JBoss. It’s more open source than WebSphere.
So – can you give me an URL for JAX-WS TCK?
regards
Grzegorz Grzzzybek
Mar 20, 2012 @ 10:17:18
@grgrzybek
First of all, let me be straight about the fact that I would never advocate using WebSphere or any other piece of closed source software.
It’s not that I’m against paying for software, but to do my job correctly I need the source to be available. (I guess I’m the most nagging guy who always bugs JBoss to make *all* their source more easily attachable via JBoss Tools)
Support contracts are fine, as long as they are independent of the actual version you use. We have for instance a support contract for Postgres with a company (2nd quadrant) who help us no matter what version we’re on.
With such pre-conditions, as a lead developer I can basically upgrade our technology at will. Of course this practically only happens after careful consideration and exhaustive testing, but there are no political barriers.
Back to your question; why change it? Well, because the newer version offers better performance, fixes old bugs or shortcomings and offers an overal better programming model. Why upgrade from Spring 2 to Spring 3?
From the sound of it, it looks like you’re in a very conservative company. FYI, it doesn’t have to be that way. Far from all companies are extremely conservative. We used Java 5 in production approximately half a year after it came out and never had a single problem with it. We’ve now just started to use Java 7 in production and it again works great (and no, we’re not building small trivial apps, far from it).
Mar 20, 2012 @ 10:36:36
@grgrzybek
Much to my dismay, TCKs in general are not publicly available. I can give you the URL for the CDI TCK though, which is downloadable from http://seamframework.org/Weld/WeldDistributionDownloads and even has a public JIRA at https://issues.jboss.org/browse/CDITCK
In that case there are thus 3 levels of openness:
Freely available specification/design documents, public spec JIRA
Opensource and free TCK implementation, public JIRA
Opensource and free product implementation, public implementation JIRA
By definition, every part of Java EE has the first level of openness now. The third level of openness is also fully covered. The second level should be addressed though, and better today than tomorrow. I suspect quite a number of bugs in Hibernate’s JPA API are due to missing or perhaps broken TCK tests. I desperately would like to verify these and contribute better ones if possible.
But compare this to Spring, which only has the third level covered. Even with private TCKs for the majority of specs, Java EE is still doing better.
Mar 20, 2012 @ 11:46:30
@henk53
First – thanks for serious and kind answers 🙂
It’s not that I’m against paying for software, but to do my job correctly I need the source to be available. …
That’s like me. I *always* (when I can) recommend FOSS. Even in my WebSphere 6, I’ve _almost_ convinced the other side to replace WAS6+DB28 with Tomcat 7 and PostgreSQL, but unfortunately they’ve found somewhere old licences. But the seed has been planted.
Generally I agree – that’s true with FOSS. But I really haven’t notices any performance gains with WAS6 over WAS5 (and with WAS7 too) when the main bottleneck is DB access. And also, as I’ve said, switching from WAS6 to WAS7 for the sake of the switch is useless (and expensive).
That was only example from 2007 🙂 I’m also using JDK7 in one of my projects.
EJB 2.x to 3.x switch was all or nothing – or I’ve missed something. If company spent about 3 years writing business logic in Session and Entity Beans and all these XML descriptors, it isn’t a matter of days to replace all of these artifacts with 3.x compliant ones.
I, on the other side, have heard (and I’ve been through) about tons of problems with JavaEE implementations. Our application, which was first deployed in 2003 used Spring 1.0.x and with one change (changing “class” to “(class)” in one *.properties file) it runs Spring 3.1 now. See some Jourgen Hoeller’s presentations on InfoQ, where he’s describing Spring’s evolutions – it hasn’t changed in major principles since beginning (beans, bean factories, bean definitions).
I know, I know. Spring’s in the meantime exlores new areas of “big data” (hadoop) and includes plenty of useful libraries/techniques which aren’t covered by JavaEE (security, integration). Tell me – is there something similar to Spring Security (or Apache Shiro) in JavaEE? Is there something similar to Spring-Integration (JBI / JSR-208 is propably dead now)?
I know CDI’s TCK. I just wanted other specs TCKS. I really can’t understand why Oracle is hiding these things. And about CDI? It’s just a model of DI + event publish/subscribe framework and interceptors/decorators. Comparable to Spring’s DI and Guice. It’s not a religion.
regards
Grzegorz Grzybek
Mar 14, 2012 @ 06:34:02
Reblogged this on Only Software matters and commented:
I have read many articles comparing Spring with Java EE. This one is really taking the discussion in a different level. I really love also the mentioning of JBoss and Arquillian as pros on selecting JavaEE !!
Mar 14, 2012 @ 08:28:58
In my opinion, spring was legacy before JEE reached whatever point it’s reached now. Spring removed much of the boiler plate, and made hard to work with frameworks easy to work with. This inspired people to develop new frameworks, libraries and languages, making spring obsolete. I find myself using guice, because I don’t need all the abstractions spring provides anymore, I just need DI. And more recently, I’ve been developing in Scala in play framework. JEE6 has finally caught up to an already obsolete framework. That’s not something to be proud of.
Mar 14, 2012 @ 09:37:15
Is it April 1st already ?
Usual unsubstantiated Billy Berk drivel
Mar 14, 2012 @ 09:38:47
Good joke…keep posting jokes like this….
Mar 14, 2012 @ 11:27:14
I’m glad you republished this, because The Onion doesn’t have it anymore.
http://www.theonion.com/articles/java-ee-wins-over-spring,41034/
Mar 14, 2012 @ 13:24:06
Touche Simon. Best come back trash talk yet! 🙂 I love it!
Mar 14, 2012 @ 15:47:03
And now we see the real motivation behind the original post.
http://en.wikipedia.org/wiki/Sensationalism
Thanks for an entertaining morning, Bill, but not much else
Mar 14, 2012 @ 13:47:26
There is no “Winner” here. Spring and Java EE have and always will work together nicely. They both run great on the fantastic App Servers that we have today, and will continue to work fantastically together in the future. Let’s just hope that everyone continues to develop software the open-source way, collaborate where prudent to avoid key fragmentations.
Mar 14, 2012 @ 15:01:23
I’ve used all versions of Spring and JEE over the past ten years, and after re-evaluating current technologies at an agency we’ve abandoned Spring for all new projects in favor of guice/restlet/JQuery for smaller websites, Play!Framework for smaller web apps, and JEE6 for larger conversation-style ‘enterprise’ webapps.
True, JEE6 doesn’t solve all your problems. No Framework will ever will. But when combined with Seam and the upcoming CDI extensions from Apache, it’s a ‘lightweight’ alternative to a majority of problems seen in the enterprise world.
For us, Spring failed as a platform for the following reasons:
– Not modular. You can’t write an extension to Spring container in a clean, concise, and portable way.
– No first class support for Conversation model
– Spring Batch, Security, Integration still rely heavily on Xml configs that only serve Spring’s poor abstraction concepts that don’t solve your problem. For instance write 5 simple batch programs. You’ll end up with 20 Spring classes and 250 lines of xml config and you’ve not yet written a single line of business code!
– I still need to worry about 40+ jars; that means maven and ivy need to be configured and their dependencies managed etc
– For simple websites Spring’s DI is an overkill.
– Developer must learn 8-9 sub-frameworks within Spring in order to successfully write a full blown “enterprise” app.
– Need to rely heavily on IDE rather than compiler since Spring gluecodes your beans and other frameworks with loosely typed Strings. DI itself breaks during refactoring if not properly done.
– AOP is hard to grasp and thus never translated into code (apart from basic logging and auditing)
– No support for Event Delegation model or Publisher Subscriber pattern. Back in the day Swing was hugely popular for that reason and Spring never figured out how
to replicate it into Web
– No first class support for writing your own Type System with annotations (poor man’s DSL) to communicate with other beans. For instance I’d like a programming model to write a @CurrentMembers and inject it into beans that “need current members” without having the knowledge of where to get it.
JEE6 along with its portable extensions (Seam, Apache) solve ALL the above and much more with 1/4th the code and no additional jars and configuration. Instead of AOP, Interceptors and Decorators are simple to understand concepts. The concept of CDI itself is so powerful its hard to go back to an anaemic one-way DI supported by frameworks like Spring.
IMHO Spring is not a programming paradigm — it’s a wrapper with extension points to several other frameworks. So in essence you end up learning all the other new frameworks anyway rather than learning one.
My complaints with JEE6 is that it doesn’t offer a worthy alternative to JSF as a clean CDI extension (at present only Wicket extension by Seam exists), and lack of several extension market makes the adoption rate slow.
The complaints that it doesn’t provide Social or NoData or Batch is valid but that’s not JEE6’s problem. JEE6 is a core programming model on top of which modules exist. Once the adoption rates increase (JEE6 is still new so please give it due credit), you’re likely to see extensions for every possible solution. And hopefully, Redhat might come with a hosted JBoss 7 server :).
Mar 14, 2012 @ 21:34:14
but but but… what about the important things in life ? like.. whats your opinion on astro-turf?
Mar 15, 2012 @ 04:03:06
Lol…This is funny cuz Mark L was just stating internally “Just wait til the astro-turf comments start rolling…”
Mar 14, 2012 @ 22:13:06
Much of the problem is that the Java EE 6, with its “EE” brought up the old fear/annoyance from old J2EE, entity beans, deployment descriptor, and so on, causing people to not even want to give a chance to Java EE 6.
I quite agree with Marcin Deryło, at the very least I think people should give Java EE 6 a try. It’s a good stack of specifications, and with in-memory container test or arquillian, it creates a good experience developing EE applications.
I am not a Spring expert, but developing in Spring is not exactly a “pleasant” experience. On the other hand have tried Java EE 6 and it’s actually quite enjoyable.
So, do give Java EE 6 a try. Have met quite a lot of people who are not open to even give it a try. Again, it’s much to do with the old “EE” fear.
Mar 15, 2012 @ 06:20:39
Regarding the EJB 3.1 Book:
Perhaps I made a conceptual mistake in covering some of the more archaic cruft still present in the EJB specification; it’s a complaint I often hear. I’d also debated adding in CDI and other newer techs to this edition, but together with the publisher had concluded that this approach would be too out-of-scope for a revision to an existing text.
To that end, I agree that a general guide to the testable development of Java EE is a gap in the publishing landscape, and am proud that together with two very relevant names in the field I’ll soon be announcing a new project to address exactly those concerns.
We’ll be focusing on use cases. End-to-end development. No focus on any particular technology or specification, but only on how to get them to work together to build useful applications. This will be born from the lessons learned while developing the Arquillian Platform and its community, and as such will have heavy roots in proving each example with real code. The authoring process will be very open-source in nature, and a major publisher will be handling distribution through the expected channels (print, eBook, etc).
And we’re very, very excited to be taking this on. More details forthcoming; watch my Twitter and blog for details when we may share details.
S,
ALR
Mar 15, 2012 @ 20:33:12
@andrewLeeRubinger Your good intentions might be a bit too late, imho.
JEE will always be a follower of Spring with usage/adoption of JEE falling off in coming years. I know a bunch of developers and not know a single one who uses JEE(all working in diff companies). JEE is a hard sell to people in the know, not just because of the EJB2 fiasco but also because of the awareness of what Spring can bring to the table -easy to use yet powerful framework.
Mar 16, 2012 @ 07:59:01
I feel bad for the people you know.
I too had a developer friend who is starting a new project. He mentioned that he will be using Spring for that. I was surprised and ask why the hell he is going Spring.
We had a very long conversation regarding Java ee 6 and in the end he realized that he must have been like living in the cave for years for not knowing the latest java ee. He is enjoying his developer life now.
But I don’t blame him for not being updated since average developers like him and me don’t spend much time on reading tech news now a days.
Mar 16, 2012 @ 10:01:08
@ameelin: Thanks for the note.
Your observations are actually inconsistent with mine, if I use JavaOne, Devoxx, and a few other conferences to gauge the pulse of the more forwardly-focused community. We’ve seen a significant drop in Spring-related material and a renewed interest in Java EE (from a component model perspective) over the past, say 18+ months.
I don’t discredit Spring’s ease-of-use. In fact, the folks over at SS/VMW shined a light on a real verbosity problem in the EE platform. And as a standards-based community, it’s not surprising that the plates took longer to shift in EE towards a model that was more developer-friendly.
But they did, and given CDI especially there’s little question now about the power and expressiveness of this typesafe injection model.
The point I find most relevant in promoting Java EE however, is the ability to test in the real runtime. Spring Test is *not* the real runtime. With Arquillian we’ve done away with mocks and have allowed users to see how their components run in the context of the real application server. Mocks, by definition, do not test integration because they rely upon the user or a mock framework (ie. Mockito) to wire up the dependencies.
I do find it interesting that your experience is still Spring-centric, but from your arguments it looks like this is a decision based on history rather than a technical evaluation of the current state of affairs in EE.
And by the way, it’s NEVER too late for a “better” solution to edge out the status quo. Spring, unshackled by a standards body, could well come up with the Next New Thing and leapfrog EE again. And the cycle could repeat again.
S,
ALR
Mar 17, 2012 @ 12:54:32
Andrew, I think overal the book is still quite good and I ordered copies for my entire team when it came out 😉
The only really archaic thing in the book that really feels out of place is in chapter 21: JAX-RPC. This is a completely deprecated part of EJB that will be eligible for actual pruning. Starting the chapter with discussing this technology is perhaps not the best approach.
Another thing that could be done better is putting more emphasis on the fact that JPA and EJB are now separate specifications. Since the book is obviously a revision on the EJB 3 text (which was itself a revision on the EJB 2 text), the structure and text still reflects that JPA and before that EJB Entity Beans were once part of EJB.
For instance, in chapter two “Component Types”, Entity Beans are the second main type mentioned, with a sub-division into Server-side Component Types. But this seems to be not entirely correct, or at least not really aligned with the “spirit of the EJB specification”.
As such chapters 10 to 14 could perhaps better be moved to a completely separate part, simply called “JPA” and moved to come after the part dealing with “Container Services”. Chapter 9 could then be moved to this “Container Services” part, with an increased focus of describing how EJB has special support for integrating with JPA. Since the JPA integration support and transactions are so related, it could be an improvement to start the Transactions chapter right after a “Persistence Integration” chapter.
It might also be an idea to have a chapter about remoting in general, and then cover binary remoting (
@Remote), JAX-WS and briefly JAX-RS with a summary contrasting those 3 approaches.Although I personally found the JNDI chapter (16) useful, some of my teammates complained it was a little hard to get through and not that relevant to them. As such, this might be better moved to the end of the Container Services part, to deemphasize it a little. Because it deals with injection, it should also at least mention that CDI exists (I understand this is a difficult topic to deal with more in depth).
So, my ideal order would be:
Part III Container Services 9. Persistence Integration 10. Transactions 11. Security 12. Interceptors 13. Timer Service 14. Remoting Binary JAX-WS JAX-RS 15. JNDI, the ENC and Injection Part IV JPA 16. Mapping Persistent Objects 17. Entity Relationships 18. Entity Inheritance 19. Queries, the criteria API, and JPA QL 20. Entity Callbacks and Listeners Appendix A1. Web Services StandardsHope this is helpful.
Mar 21, 2012 @ 07:24:54
This is some very helpful feedback (I’ve saved it away), and I’d like to thank you for it. In fact, I agree with most of the positions you’ve got as well (so far as the role of JPA and JAX-RPC). Again, with the timing of the 6th edition we had to get out a text to describe the lastest revision of the specification.
I think what developers really need now is a centralized end-to-end guide on how to plug in various EE techs to work together. So this new book I’m doing is really important to me (and the other 2 authors), and you’ll also note that the new JBoss.org site is taking steps along these lines as well.
In short, we’re really making efforts to put ourselves in the users’ shoes, and stop explaining Java EE from a per-specification perspective. Folks need to build working apps, and we feel the best way to illustrate that is by using case studies and functioning examples.
S,
ALR
Tab Sweep – Java EE wins, Prime Faces JSF, NetBeans, Jelastic for GlassFish, BeanValidation, Ewok and more… « oracle fusion identity
Mar 17, 2012 @ 07:04:40
Mar 17, 2012 @ 22:14:08
I think JBoss is dying, not Spring.
Mar 20, 2012 @ 09:15:24
While I think the article has a bunch of valid points, so do some of the commenters. In the end, in some ways I hope to then and now finally have some more pragmatism in all this dispute as the neverending “Spring vs. Java EE” flamewar started to get boring ages ago already.
In many points, to me it seems all a discussion again and again regurgitating old “facts” and fictions rather than focussing on providing good solutions to business challenges. And while the rest of the world is talking RubyOnRails, node.js and all that other shiny stuff, in server-sided Java we’re still fighting whether Java EE is “heavyweight and bloated” (even completely leaving out things like EJB lite or interface-less EJBs packaged in .war contexts) or whether Spring is “lightweight” (again, completely leaving out that, in example including a decent set of Spring .jars to a project using maven ends up with half the internet being downloaded and added to the application, making the Spring app a fat chunk of bytes almost appearing like an application with an embedded application server even in situations in which it would be easy to re-use logic and features already available in the application container this app is supposed to run on).
Bottom line, to me: I want freedom of choice here in order to choose an appropriate technology. This should include both Java EE and Spring wherever appropriate, and in 2012 and knowing it’s all Java, I just _expect_ things to play along nicely with each other. I want both to make use of the benefits of a JSR-like approach (most notably the option to have a somewhat “standardized” API provided by different vendors, in example by being able to choose an arbitrary application container – JBoss 7, Glassfish, … – rather than being forced to use a special one) or the ability to replace implementations without too much pain (as we replaced Metro with Apache CXF in one of our applications recently because the rest of the runtime already made use of it) rather than being tied to a framework provided by “Spring Source a division of VMWare” and knowing this framework will hard to be refactored out of my stack (once it’s there) in situations in which it might not be used (and be that because of a customer application server providing strict policies about which dependencies are allowed to be installed).
Mar 20, 2012 @ 10:05:47
Reblogged this on lava kafle kathmandu nepal.
Java EE versus Spring: retomando a discussão | blog.caelum.com.br
Mar 27, 2012 @ 17:55:12
May 01, 2012 @ 14:14:30
JEE has become too bloated. Need to manage dependency and complexity.
But since this is vendor driven product, it is difficult to do that.
May 01, 2012 @ 15:13:32
Bah, Spring is just as bloated as Java EE, if not more. BTW, was doing some integration testing yesterday with AS7, a full Java EE 6 container. Booted up in 1.75 seconds. Wow thats bloated!
Jun 22, 2012 @ 22:50:30
Hi Bill,
Could you imagine what would be state of Enterprise Java Development on 2012 without the contributions of Companies like SpringSource and JBoss (Hibernate).
Image Java EE6 with no CDI or JPA?. Probably would be an EJB 2.1.? on steroids!. Really-really an scary proposition. Don’t you think?
Be careful not bashing to hard your sources of innovation.
Question for you: Is JEE 6 leveraging AOP?. I really don’t know it. It brings a lot of programming productivity. Indeed.
Java EE6 better than Spring? No yet*. I don’t think so.
Thank you
jD @ http://pragmatikroo.blogspot.com/?view=timeslide
Certainly has improved a lot. Basically assimilating the good stuff innovated from others. Nothing wrong with that.
Jun 22, 2012 @ 23:07:11
True, but the difference between Hibernate and Spring is that Hibernate joined the EE community and Spring didn’t. Standards are for standardizing and consolidating successful technologies. Java EE has done a decent job of that. Spring generally refuses to play ball. Their choice, but there are consequences to those choices.
Jun 22, 2012 @ 23:59:42
Thank for accepting the fact: “The current healthy state of the Java Enterprise Ecosystem won’t be as it is without SpringSource as a driven innovation force.”
I believe SpringSource has participated in the JCP… Right?
I truly believe that you really need “the perspective” from others for getting better. This is what happens to JEE 6. Finally.
On the Hibernate story… It really took too long, before it became the deJure Java Enterprise persistence model. At that time there was to much pain with “standardized” JDOs and other failed “standardized” ORMs. You have to admit that too.
I like standards… but there are a lot of lessons out there on the Java Enterprise Chronicles for the ones humble to understand sources are serving the same market and if you disrupt the market -in the wrong way- will be consequences as well. *
Thank you
jD @ http://pragmatikroo.blogspot.com/?view=timeslide
I think MS is already salivating on that too.
Jul 05, 2012 @ 04:59:32
Bill, you said:
“Standards are for standardizing and consolidating successful technologies”.
Now tell me: Why JSF was created as a JSR directly? I mean, why not start as an open source project and IF it is well adopted then it will became standard.
Hibernate becoming JPA was ok because Hibernate was already there and being used by lots of people.
Now the Seam framework as not as widely used as Spring and still it made trough JCP.
I will say the same for CDI and so on.
In my opinion the JCP is broken. How can a company create something new and defining it as standard right away? I do not understand that. Why not leaving the community to decide.
I tell you why. Because JCP is in the control of big companies, the ones that will get a lot of money doing this. This is so wrong. That’s the worst part of Java. They say standards are good, but they decide the standard without the community.
Jul 05, 2012 @ 05:01:47
Bill, you said:
\”Standards are for standardizing and consolidating successful technologies\”.
Now tell me: Why JSF was created as a JSR directly? I mean, why not start as an open source project and IF it is well adopted then it will became standard.
Hibernate becoming JPA was ok because Hibernate was already there and being used by lots of people.
Now the Seam framework as not as widely used as Spring and still it made trough JCP.
I will say the same for CDI and so on.
In my opinion the JCP is broken. How can a company create something new and defining it as standard right away? I do not understand that. Why not leaving the community to decide.
I tell you why. Because JCP is in the control of big companies, the ones that will get a lot of money doing this. This is so wrong. That\’s the worst part of Java. They say standards are good, but they decide the standard without the community.
Jul 20, 2012 @ 15:21:08
Spring guys could have participated in the CDI effort, instead all we got was a competing spec that was basically @Inject and no innovations so that Spring could maintain its edge.
You have a point about big companies dominating the JCP. This is one of the reasons why I think the IETF is such a great organization.
Jul 20, 2012 @ 17:19:18
Couple points on JCP…
Not with the intention of criticizing it, but more for reviewing the cost/benefit of JCP.
I think its purpose and intentions of JCP might be good but the results. I am not sure.
I think you cannot “regulate” innovation and pick who are winners or losers in the market place. I don’t think “Father” Gosling needed JCP for creating Java in first place. (unintentionally rhymed)
I don’t think these guys from jQuery are needing a ‘JCP’ for making their mark on the client-side web development. BIG. There are many other examples of innovation without committees.
Spring went rouge and tried IoC and DI and proved everybody that was the way to go for Enterprise Java.
What is sad to me is the JCP turns brilliant-brilliant technical minds, great computing people in kind of bureaucrats. I have great respect for bureaucrats. They provide a invaluable service to the community.
The thing is that the role is out of place in this case.
Thank you
Jun 27, 2012 @ 14:42:00
Time to face the facts Spring gurus. You are on a dead end street. Maintaining the crap you created so far will cost $$$$$$$$$$$$.
Jul 04, 2012 @ 16:35:41
One cannot change the implementation approach just because one technology is offering the advantage than the other in the newer version. The One cannot change the implementation approach just because one technology is offering the advantage than the other in the newer version. The other factors, that influence choice of Spring or JEE is the skill (Spring/JEE) that the team of developers has who can bring the business value at the earliest, and ofcourse many more …
JEE 6 is in advantageous position for new enterprise app development, for the older implementations, Spring offers more flexibility. Its like, if I am building a new home, I would go for some thing more advantageous, If I am renovating the existing house, I would look for cost effective way of working out. One more thing, I would like to add is, even if Spring offers all the building blocks to build enterprise app, I would choose app server, as I dont want to plumb the enterprise concerns, just focus on solving business problem in hand.
One thing is for sure, more and more features (because they are intangible) will only confuse the developer, as it becomes imparative for the developer to understand all the capability the framework offers before implementing. Keep it simple.other factors, that influence choice of Spring or JEE is the skill (Spring/JEE) that the team of developers has who can bring the business value at the earliest, and ofcourse many more …
JEE 6 is in advantageous position for new enterprise app development, for the older implementations, Spring offers more flexibility. Its like, if I am building a new home, I would go for some thing more advantageous, If I am renovating, I would look for cost effective way of working out. One more thing, I would like to add is, even if Spring offers all the building blocks to build enterprise app, I would choose app server, as I dont want to plumb the enterprise concerns, just focus on solving business problem in hand.
10 razões para migrar sua aplicação para JSF 2 | blog.caelum.com.br
Sep 19, 2012 @ 14:46:23
Oct 06, 2012 @ 18:05:44
As much as I am interested in trying out the latest and greatest Java EE one thing that puts me off is the fact that doing so would be stifling innovation by utilising a bunch of refined plagiarized works!
This is a big problem, Hibernate, Spring et. al. came to fruition because Java EE didn’t have enough features and some of the features sucked balls. All Java EE seems to have done is sat back, let others innovate and then take the best / most popular parts and refine them into their own. Whilst this means that potentially in those areas Java EE may be better and, importantly, standardised the problem is with anything emerging. History tells us that Java EE means the next “standard” to solve a future issue will be a botched job and better open source alternatives will be available to non Java EE apps. Another release or two later of Java EE and a revised version of your initial botch may arrive with a declaration of “Spring is dead because we do it just as well too”.
My question is why should people invest their money (time is money, money is money) in Java EE when they innovate so poorly and today only stand up because they stole everyone elses good ideas?
Oct 16, 2012 @ 15:02:29
Marcus, Java EE is a standards body. They mostly standardize existing technologies the idea being you’re not locked into one impleentation. While Java EE does innovate to some degree (CDI is a great example), it does and should take most of their ideas from existing working applications.
Nov 16, 2012 @ 21:12:10
I understand that standards are for standardising and its a good point, but you standardised way back when with J2EE and due to it being poor others came along to make life easier. After their innovation and due to realising others have done it better J2EE is completely rewritten, refactored and rebranded and hey, it’s a lot like Spring.
Can’t deny that it seems on the one hand the Java EE folk have wanted (and would probably like) to be seen as innovators but were shown some of their innovations were severely wanting and on the other hand want to say they are standardisers of others innovations and take a huge swipe at them once the standardisation process has taken place by declaring them “dead”. These are some of the very people who have been most influential / plagiarised in causing Java EE to be where it is today.
The issue that cannot be ignored is that over the years people and organisations faced problems and screamed to have solutions, the Java commitee didn’t listen to anyone and hence all the fragmentation with open source projects filling the void. Now for example you’ve stated that you won’t help people into the cloud or NoSQL but instead will let others solve the problems people are having and will later “standardise”. So innovators will arrive, people and organisations will do things their way, Java EE will hoover up what’s good and then tell everyone to do things your way proclaiming the death of the innovators.
Kinda sucks.
Nov 16, 2012 @ 21:24:00
marcus, IMO, Java EE shouldn’t be a place to innovate, but a place to standardize. The Spring guys wanted no part in most of the standardization efforts in Java EE other than the superficial @Inject spec. At least when I was on the Java EE 5 JSR and the first few weeks of Java EE 6 before somebody took over Red Hat rep, Spring guys were obstructionists and not much interested in standardizing any of their IP. But that’s their prerogative to not embrace anything that is going on in Java EE.
Oct 08, 2012 @ 15:38:57
> SpringSource pushed Java EE to innovate and for that I’m very grateful. For Java EE, it was either evolve or die. They evolved, now its time for Spring to die.
compare:
Samsung pushed Nokia to innovate and for that I’m very grateful. For Nokia, it was either evolve or die. They evolved, now its time for Samsung to die.
great logic 😀
Java EE must offer something really great to return back. What could java EE offer ? none. like Spring. It is why Spring evolves. I do not see innovations in java EE.
Oct 11, 2012 @ 17:45:58
Where does Typesafe, Scala and Playframework fit into this? It appears the end of the Servlet container is coming. That kind of gets rid of JEE and Spring.
Oct 22, 2012 @ 06:43:27
I walked in here wanting this article to win so I’m not coming from a Spring fanboy stance. But 2 1/2 stars and you “disagree” with 90% of comments; I’ll let the idea of objectivity speak for itself. After seeing a related post title about WebSockets going out the door also…all I’m picking up is a fear of change. These tools power our ability to drive software evolution, and they aren’t competitors. JVM adopts many languages; Spring + Hibernate even adopts .NET into the Java yard. They are basically slightly different guys on the same team. It’s great to be an enthusiast but this is bordering ‘fan faring’, the way we want to see our ‘side’ win bragging rights for us. I actually have your book and will give it the benefit of the doubt and try to see what it says, but considering the source, I’ll be wary of any contentious advice.
Seriously, it’s like comparing a regular onion to a vidalia onion here. J2EE and Spring…it’s like watching ice melt. If Spring is bad then so is J2EE because it’s based on it. Yeah, I don’t love VMware, but Spring was a blessing in the last decade when J2EE and JSF was basically an EJB 2.x disaster (think 7 years of Windows Vista). Without Spring, there would’ve been nothing to convince us that POJOs are good and simple. It may be glossy and mainstream but it got us through long enough for J2EE to get its act together and stop being so complex.
But even with that said, I won’t rest my head on Spring or any other entity who sits at the top and eventually loses sight of how it got there. That’s what J2EE did, and Spring cut in. Now Spring is on the throne, and will probably be replaced unless it undergoes deep internal revolution.
Criticism helps advancement but they have to be specific to trigger actions. This is hobby-level ranting and lazy journalism at best. Your Romney quip paints a clear picture of the type of debates you like to take on: circular and meaningless. You seem to be enamored with JBoss, and Gavin King seems to like Spring’s philosophy, so basically you’re not speaking for very many people. We’re all pretty cool with each other in the Java galaxy–whose war are you fighting?
Oct 22, 2012 @ 06:48:46
I walked in here wanting this article to win so I’m not coming from a Spring fanboy stance. But 2 1/2 stars and you “disagree” with 90% of comments; I’ll let the idea of objectivity speak for itself. After seeing a related post title about WebSockets going out the door also…all I’m picking up is a fear of change. These tools power our ability to drive software evolution, and they aren’t competitors. JVM adopts many languages; Spring + Hibernate even adopts .NET into the Java yard. They are basically slightly different guys on the same team. It’s great to be an enthusiast but this is bordering ‘fan faring’, the way we want to see our ‘side’ win bragging rights for us. I actually have your book and will give it the benefit of the doubt and try to see what it says, but considering the source, I’ll be wary of any contentious advice.
Seriously, it’s like comparing a regular onion to a vidalia onion here. J2EE and Spring…it’s like watching ice melt. If Spring is bad then so is J2EE because it’s based on it. Yeah, I don’t love VMware, but Spring was a blessing in the last decade when J2EE and JSF was basically an EJB 2.x disaster (think 7 years of Windows Vista). Without Spring, there would’ve been nothing to convince us that POJOs are good and simple. It may be glossy and mainstream but it got us through long enough for J2EE to get its act together and stop being so complex.
But even with that said, I won’t rest my head on Spring or any other entity who sits at the top and eventually loses sight of how it got there. That’s what J2EE did, and Spring cut in. Now Spring is on the throne, and will probably be replaced unless it undergoes deep internal revolution.
Criticism helps advancement but they have to be specific to trigger actions. This is hobby-level ranting and lazy journalism at best. Your Romney quip paints a clear picture of the type of debates you like to take on: circular and meaningless. You seem to be enamored with JBoss, and Gavin King seems to like Spring’s philosophy, so basically you’re not speaking for very many people. We’re all pretty cool with each other in the Java galaxy–whose war are you fighting?
Also, like one guy said up there, that EJB book wasn’t very good and the type of writings here correlate with that feeling. Barely credible blog, sigh. I feel bad but you kind of asked to be flamed but displaying such hardheaded views and refusing to deeply consider anyones’ words. It’s like the Fox News of Java up in here.
Oct 22, 2012 @ 13:32:48
Never said WebSockets was going out the door, just worried we’re headed for yet another era of everybody implementing their own pet protocols, which would be a really bad thing for the industry.
Also, I started this blog with a reference to a TSS article talking about how good Java EE 6 is. This is what we hear a lot on the JBoss side of things. That Java EE 6 has gotten a lot of things right and Spring looks old and rickety in many situations. This is contrary to what we heard 5 years ago. Maybe you should read my blog again, because its more about what allowed Java EE 6 to catch up and surpass and what advantages the JCP has over frameworks like Spring.
As for the Romney comments, well, I wrote this blog way back when the Republican primaries were happening and all the Pub candidates were trying to run a campaign where they painted themselves as the non-Romney candidate. My point being that, if you listened to Rod’s speeches over the years he always talked about how Spring was the simple alternative to Java EE, but when Java EE got its act together component wise, his argument was mute. BTW, I’m actually a staunch Democrat.
Nov 10, 2012 @ 07:03:09
I too dont agree with this. Spring just make your job easy to implement and maintain a java EE application. Well EJB is just a copy of spring provided features with just replacing xml configurations by annotations.
Nov 13, 2012 @ 05:03:00
I can’t help but laugh at this holy war going on here. JPA this and JEE that and JCP that and JSF. I’ll give Spring credit for actually having a good name
I’m going to guess that a large part of this audience are not startup developers or cutting edge technology companies because you would know that both JEE and Spring are both dying…. Why?
Because they suck at scaling and concurrency. Almost all of JEE and Spring abuse ThreadLocals use mutable objects and offer very little for truly scaling. Most of the Servlet Container, JPA, JDBC, JSF, etc… etc.. rely on synchronous mutable logic. I especially loathe Hibernate and JSF.
One thing I do like about Spring over JEE (CDI) or Guice is the AspectJ support. The other thing is that Spring MVC is sadly the only MVC player left that matters. You really can’t use JAX-RS for traditional MVC. I have tried many times and it was exceedingly painful… please don’t talk about Seam.
I’m willing to wager someone is going to make another Spring of the future. The Play 2.0 framework might be it or maybe it will be something built in Xtend leveraging Xtext for code generation but I can bet sure as hell it ain’t going to be anything Oracle or JBoss makes especially if it has the stigmata title of “enterprise”. It will probably be TypeSafe, Twitter or LinkedIn.
Regardless of whether its Scala, Java 8, or Xtend the future is functional, immutable and reactive programming with NIO built from the ground up (I’ll give JBoss credit for creating Netty and JEE for Grizzly).
Nov 13, 2012 @ 16:54:44
You are completely wrong that Java EE is unscalable. If it wasn’t we wouldn’t have a business. The fact that you state that “Servlet, JPA, JDBC, JSF) rely on synchronicity implies ignorance as its simply not true. ThreadLocals have nothing to do with scaling either and solely exist to pass contextual metadata down a Java call stack. FYI, I loathe JSF too, but I loathe pretty much every other Java web framework that creates a tight coupling between client and server. But JSF isn’t Java EE. Its a small piece of it. JMS, JTA, JPA, JAX-RS, Servlet are all decent solid fundamental APIs that have been proven the test of time.
JAX-RS wasn’t written to build MVC frameworks on. It was written to write Restful services. Also, I could give a f*k that spring is the last MVC player. MVC is a dead outdated pattern.
Nov 13, 2012 @ 18:45:27
JDBC, JPA, Servlet containers are one thread per connection. The fact you don’t know that shows “ignorance”. And Threadlocals are a problem in something like Akka or Netty and its very easy to leave an entity session open or god knows whatever else on the thread and it cost memory.
Let me rant a little more since you work for JBoss.. do you have any idea how much f$%#$ time that company has wasted of mine? JBoss 6 takes 60 seconds to boot up. So you screwed me over repeatedly and now your telling me “oh that spring thing you used sucks and you shouldn’t use it anymore”.
You can’t say MVC is dead and offer no other solution. Its not MVC people want anyway its stateless handling of requests. JAX-RS does this but if you want to add a little security or view handling… your screwed and will have to use some custom extensions… because in the real world people write apps not libraries.
Let me give you something you can relate to: this rant on JBoss and JEE now doesn’t suck is like Rex Ryan and the Jet’s (a couple years ago) saying the Patriots dynasty is over.
Nov 13, 2012 @ 19:30:42
JDBC (and thus JPA and Hibernate) require one-thread per connection, but I don’t see what that has to do with Spring vs. Java EE, as, Spring pretty much depends on Hibernate, JPA, and/or JDBC for their database support.
While Servlets don’t support NIO, they *DO NOT* require one thread per connection. But, in any case, 99% of web apps do not need async IO or NIO. Still, JMS implementations like HornetQ *DO* use async IO quite well to scale.
I just don’t see what ThreadLocals have anything to do with your argument. They are needed in async IO apps as well for the same types of reasons: to pass contextual data down the call stack.
You’re right, JAX-RS is not a view technology. Nor should it be. Nor does it need to be. And whether JAX-RS can do “a little security” is completely dependent on where it is deployed as this is mostly a web-container configuration issue and nothing to do with the JAX-RS API.
As for your problems with JBoss 6, well, it took us a few years, but AS7 boots up faster than Glassfish now and there are plans to make it better.
yeah, good Jets/Rex analogy. Rod Johnson continually stating that the Java EE dynasty is over made him look like a fool in the end.
Nov 13, 2012 @ 21:40:11
Bill I didn’t say I was entirely for Spring and the JDBC threadlocal issue is more about how JEE is flawed and not how Spring is better.
Spring is only good because it didn’t F#$% you like EJB and JBoss < 7 have in the past. Is Spring the best today? … probably not… but its very mature, works and I know it very very very well. I even know the code base of which there is only one implementation very very very well.
While I agree that 99% of *traditional* *enterprise* web apps apps don't need extensive async such is not the case with rising SaaS companies particularly if you are using Websockets or any real time updates. And this isn't fringe case.. this is better user experience (go look at things like Trello).
The reality is traditional "Enterprise" software is slowly dying. In place of it we are seeing more and more SaaS / cloud based software. The leaders of SaaS and cloud from what I can tell are just not using JBoss or even JEE. They are using Jetty (Yammer), Netty (LinkedIn Twitter), Tomcat (Saleforce)… and many more. They are writing straight up SQL or using some NoSQL option.
I will have to checkout HornetQ though (right now I'm using RabbitMQ and I like it).
Nov 15, 2012 @ 21:02:14
@agentgt
* ThreadLocals are not a design flaw. Spring also uses ThreadLocals
* A large part of Spring still depends on Servlet, JMS, JTA, and JPA. If you’re writing a spring app, you’re probably still using a piece of Java EE
* Servlet spec needs a Web Socket API. Java EE 6 should have had one.
* I’m still not convinced that WebSockets isn’t a must for push apps. There’s very few apps out there that need the kind of data rates that WS provides. The idea of rolling your own protocol seems very dirty to me, but this is another discussion and nothing really to do with Java EE vs. Spring.
Nov 15, 2012 @ 21:23:30
Bill, if it does make you feel better you are slowly convincing me. I also think you have a done a great job with RestEasy.
My concern with JEE (and even Spring) is that in large part it is becoming irrelevant to some one like me who develops web applications particularly in the startup community. I constantly have to defend the many of the Java stacks (Spring or JEE) against something like Typesafe particular since many of the traditional Juggernauts of Java have moved on: Doug Lea, Kohsuke, and Rod.
I’m also still concerned with Threadlocal problem not so much for established Java programmers but for the future Java developers particularly since Java 8 lambda support is around the corner.
I live in the Metrowest area so maybe we can grab a coffee some time.
Nov 15, 2012 @ 21:46:52
I live in the greater Boston area. FYI this blog was not to convince you to use Java EE over Spring, but to state the reasons why I thought there is a resurgence in Java EE.
Nov 15, 2012 @ 21:52:37
I live in Waltham which is not far from Brookline (sorry for the stalking). Always looking for fellow Java dudes (pun intented if you remember that mascot) to talk to 🙂 .
Hope JBoss does well.
Thanks
Nov 14, 2012 @ 05:21:01
Wow – this thread lives since march!
Bill – even if JavaEE didn’t won, it surely will win soon – JavaEE will have such killer features as Json and Batch processing – thank you Oracle for all of these!
But seriously – moving cloud features and multitenancy (the only fresh air in this Ivory Tower) to JavaEE.next is not a good sign…
regards
Grzegorz Grzybek
Nov 14, 2012 @ 09:25:07
Grzegory, if you would have looked at the details of the proposed cloud and multi-tenancy support in EE7 then I bet you would be happy as well that they got dropped again 🙂
Really that would have been a huge backstab to JavaEE.
In Oracles PaaS documents they drafted one big fat EE server for a PaaS provider and each ‘tenant’ would be an EAR inside this fat server. Just crazy imo!
Also ‘tenant’ was defined as the one who deploys the EAR into the EE server. Their tenant had nothing to do with the business decision about who defines the branding and functionality changes of a project. Purely useless.
LieGrue,
strub
Nov 14, 2012 @ 09:30:25
Wow – so they really like to create monsters… Maybe they’ll drop Json, JMS2 an batch also – there won’t be ANY migration issues then 🙂
Nov 15, 2012 @ 21:08:47
Myself and others at Jboss suggested to Mark Little that we vote no on any cloud APIs introduced into Java EE. IMO, the space is too young and evolving way too fast. Consolidation and standardization just doesn’t make sense right now, as IMO, Java EE should be a standardization of existing technology rather than a place to test new ideas.
Feb 23, 2013 @ 05:36:54
That crazy idea is called “multi-tennanting”. It’s one of the core ideas behind the cloud. Elasticity and sheer capacity of the hardware makes it possible.
Dec 10, 2012 @ 16:43:43
There’s absolutely nothing in the article demonstrating why Java EE ‘wins’ other than claiming it is a standard. Completely devoid of content.
Java EE vs Spring | Business World TI
Jan 04, 2013 @ 01:53:46
Jan 07, 2013 @ 19:35:50
I support u – Spring is simply one abstraction of java ee, a wrapper. If u understand java ee and have software engineering skills, u can abstract it how YOU want to.
Spring is ok but support for it is largely BANDWAGON, or people who don’t understand java ee very well, like the “SOAP is terrible” people (SOAP is a little bloated but fine and more advanced than e.g. simple REST calls).
Just wanted to back u since a lot of criticism. Having offended everyone apart from the clever people who quietly get on with their job and understand it, I will now disappear. Mwa ha ha ha haaa!!! (evil genius laugh)
p.s. “the cloud” sucks too, marketing rubbish
Jan 20, 2013 @ 01:42:12
About Java EE: Many of it’s standard are great, but I find the stack too rigid.
JPA is great, JSF is great, but, what if I prefer Spring MVC or struts instead of JSF? As a container Spring is much more flexible than Java EE, and also much more stable (backwards compatibility)
On the other hand, only some of the JavaEE “standars” can be considered as true standars, while other are inmature technology which do not keep backwards technology when new revisions are written. I prefer the freedom to choose which of those standards to use. I prefer to choose the vendor and version for each individual specification. That’s way I prefer spring to Java EE server fixed stack.
Jan 21, 2013 @ 17:14:04
Java EE is required to maintain backward compatibility. Until Java EE 7 there has never been an API removed.
Feb 23, 2013 @ 04:39:32
Spring is dead B-X … long live JEE!
Apr 01, 2013 @ 22:38:23
I don’t think Spring is dead because
1. There is a lot of code using it.
2. There are a lot of developers that blindly sticks to it even if now JEE 6 is easier to develop, is the standard and is FAR easier to deploy.
3. There are a lot of developers that take frameworks and languages as they were religions.
I’m a big fan of JEE 6 but now I’m learning Spring because several of potential customers asked it even for new applications. I tried to convince them to go for JEE 6 but normally is a tech savvy person who don’t want to learn something new or is a misguided non technical user or CIO.
Regards.
May 28, 2013 @ 10:09:27
The source quality and documentation of the spring framework components is unmatched. Looking at many sources on JBoss components (Resteasy is an example for an insufficient javadoc) i see potential to “Jürgenize” the code 😉
Aug 14, 2013 @ 22:12:33
Even if resteasy could be a mess is, as Jersey, implementation of the standard.
I don’t care how they implemented the specs as long as behaves as expected.
Regards.
May 28, 2013 @ 10:12:29
WTH is “Jürgenized”, have a look at: http://www.olivergierke.de/2013/03/juergenized/ 😛
Jun 13, 2013 @ 03:51:03
The big difference between spring and java ee (my opinion)
spring rocks with
1. mvc framework
2 spring integration
3 spring batch
4 cloud solutions(need to release in spring 4)
5 cqrs axon framework (spring 4-)
spring has driven java development with more innovation
java ee 7 improvements
1 batch processing( this makes me want to use java ee 7!!!)
2 java api rest improvements(jaxb, jpa-needs improvements)
3 annotations
4 web sockets!!!
Badly Improvements in java EE
JAVA NEEDS to push this
CQRS-CQRS-CQRS(command based framework)
personally I would like java 8 provide greater action-state
frameworks!!
and yes oracle atg e commerce beats anything spring brings to the table
so yes I would like to see an action framework that would fit
into concurrency or e-commerce, or financial applications
Finally java ee is becoming closer to spring (spring-has always
been the leader)
however it will never be a leader until more innovation
and open source encouragement needs to happen
Congratulations on java 7EE on glassfish 4
I am still a fan of spring however I really like
some annotations in java ee better(message driven beans)
batch processing in java ee is a step in the
right direction
I really wish that java ee would push esb
fuse esb rocks!!!
Jun 13, 2013 @ 03:56:00
I would love to see java push osgi modules!!
Jul 27, 2013 @ 13:31:59
This is an old post at this point, and I’ll keep my preference out of it….but to me the message of this post reads “Java EE has benefited by being pushed by competition but now that it’s evolved the competition is over” with the implication that that evolution will somehow continue or no longer be necessary. Both frameworks have introduced direct and indirect benefits to each other and the entire Java ecosystem, but now one of them should apparently crawl off into the woods because there is no perceived immediate advantage (which is particularly hypocritical since historically the roles have been reversed).
Aug 14, 2013 @ 21:39:11
Spring is dead? Good luck finding a job without Spring on your resume. billburke you sound like the biggest tool ever. People RIPPED your stupid article apart, all you’ve been able to do reply “good luck with that” when somebody brings up a point you don’t have an answer too (which given the premise of your article there are LOTS of). Go back to writing your stupid little books that nobody buys and the rest of us will continue writing awesome Java apps powered by Spring.
Aug 14, 2013 @ 22:05:51
Derpy derp derp. Derp derp derpy derp derp..pew pew derp derp derp…
Aug 14, 2013 @ 22:17:32
You don’t have any argument other than send Bill to F**k him self?
Wow!
Spring is just a freaking framework not a religion!
Sep 04, 2013 @ 18:20:24
JEE guys are still fighting old battles and are living examples of the ancient adage “Those who do not understand the past are bound to replicate the same mistakes again”
Spring people have at least understood that the field has changed, they’ve already moved on.
Sure your JEE6 or JEE7 kicks Spring Framework ass, no doubt about that, you copied them well 😉
But even a talented copier is just in the end… a copier.
Picasso used to say “Mediocre people copy, geniuses steal!”
The Cloud or whatever they call it it’s here to stay and is bringing a new mindset in Enterprise Software Development.
Talented kids don’t dream about working at IBM or Oracle or RedHat anymore: they are all about Google and Facebook and Tweeter etc… and all about what they have to offer.
And yes, they are going to steal the fire from you one more time if you don’t pay attention 😉
Bill, I know you’re a really smart guy but do you really believe what you say or are you just acting as a corporate spin doctor trying to fool the minions one last time again ?
Join the revolution before it crushes you!
Sep 04, 2013 @ 19:18:21
CDI doesn’t really look like Spring. If you’ve actually read the spec, you’d see it innovates beyond it. “The Cloud” has been at Red Hat for awhile. Go check out Openshift. We also have a pretty popular Rules Engine and Big Data solution. As it is, you still will always need core middleware services to write your apps.
Also, I’m pretty happy with both our talent and the talent we hire. Given we’ve been doing distributed OSS development since inception, we can pretty much hire the best and brightest anywhere in the world and do. There’s not many companies that have the culture and know how to handle such a distributed workforce. Not only that, Red Hat isn’t like the typical Silicon Valley employee that tends to change jobs on a whim during a hot market. I’ve been working with many of the same talented individuals as I have 5 even 10 years ago. I’m know there are a lot of talented engineers that have no desire to live and work in Silicon Valley.
It amazes me that people still feel the need to comment on a 2 year old blog. A blog that was written on a whim after seeing that people liked Java EE 6. The Spring crowd is just so damn touchy…Rod really did a number on you guys…
Sep 25, 2013 @ 10:19:12
I have the utter respect for the skills of people at Red Hat but that’s not the problem here.
No doubt Red Hat can hire enough talents (Microsoft did the same!) but in the end they are just minions to the corporate business decisions.
I read the CDI specs (even better I worked with it! though I have been forced to do :)) and if becoming a bloated behemoth is better then sure it is better than Spring.
When you guys just quit adding features than almost nobody uses? It just amazes me that there seems to be no end to that, developers are relentless!
Same also applies to Spring somewhat but I guess one have to keep the developers in both companies happy…
Whatever, the days of the big servers and containers are numbered, a new paradigm shift is ongoing where smaller and simpler ones (I just insist on simpler) will take over: “strength by number”
I am also a big fan of Bauhaus in the sense of — simpler and leaner — programming interfaces.
Technologists believe that they can solve any problem by providing the adequate hardware and software so let’s say I am more a behaviorist and what I have found working with many “standard developers” is that often lean is beautiful.
Sep 25, 2013 @ 13:51:14
@Eric
Your perspective is warped on multiple levels. First, Red Hat just doesn’t work the way you describe. Our products are derived from upstream community projects. So features/innovation come from the community. It ends up engineers have tremendous amount of input/control into the final product.
While we are under the thumb to varying degrees to the Java EE specs, most of these specs have reps from not only corporations, but open source projects.
As far as “simple” goes, things always seem to start of that way with the latest fad in middleware development, but always end up “bloated”, well, because, this shit is complicated and once you get past the simple low-hanging fruit use cases there’s a lot of things that need special love and care. That’s just reality.
I agree that the days of big containers are gone. The thing is, they’ve been long-gone for years and years and most of us adapted long ago by providing containers that are both modular and load on demand for fast boot speed and deployment. Get your facts straight instead of just throwing out random uninformed statements like you’ve done.
Sep 04, 2013 @ 20:23:39
I don’t care if JEE 5/6/7 is a “copy” (which is not, just learned from Spring and Seam for naming a few), what I care is that I would expect to take my application to any JEE specs complaint and run it without the JAR hell.
Regards,
Sep 05, 2013 @ 07:22:51
Yes the jar hell is a good aspect, we are to much depend on frameworks, so we are bounded. We have to keep it simple. So we are free 🙂
Feb 20, 2014 @ 19:39:15
Most of what you are saying here is not true. Spring was not built on Java EE and does not depend on it. How am I running my Spring apps on Tomcat if that were the case?
Java EE has copied a lot of Spring, but Spring still has more. With how long the JCP and JSR processes take, I’ll stick with Spring!
Please get your facts straight before you start spewing such non-sense.
Feb 20, 2014 @ 19:52:58
Servlets is a Java EE specification…Thus, you are using Java EE.
Feb 20, 2014 @ 20:00:06
Spring Data, Spring Integration, Spring Batch, Spring Security, … Do I need to keep going?
Feb 20, 2014 @ 20:21:20
The original point that I made 2+ years ago is that Spring has never been completely disconnected from the Java EE universe. For your particular example, it still depends on Servlets, which is a Java EE spec. Many more Spring apps also use JPA, which is a Java EE specification. Others use JMS, JAX-RS, or JTA. Also EE specifications. What this does is keeps the door open for Java EE to consolidate and improve on, and introduce new specifications that innovate past the Spring equivalent, i.e. CDI. Its your prerogative to scoff at my statements, but I stand by them. Even 2+ years after I’ve made them.
Feb 20, 2014 @ 20:34:41
Of course it hasn’t been disconnected from Java EE. Spring was created to enhance Java EE because of the EJB 1.x and 2.x debacle that started some 10+ years ago. I’ve been a Java EE developer for quite some time. I can’t see reinventing the wheel when Spring provides extreme productivity gains right out of the gate.
“Imitation is the highest form of flattery.”
Feb 20, 2014 @ 21:07:52
Yes, and those Spring enhancements to Java EE done 10+ years ago are now obsolete. Which was another point I was making in the OP. And who cares who is imitating or flattering who? This isn’t about who gets credit for being the smartest. Its about which techologies are being used. Java EE *should* be about imitation. A specification is about consolidating existing projects, protocols, apis, and best practices to get the industry on the same page.
Feb 20, 2014 @ 21:20:20
Ok. Your ‘obsolete’ comment is what actually got me to reply to your post. I really never get into these debates. I am confident that with the tools readily available from Spring, I can be much more productive than you with plain old Java EE out of the box.
Humor me please. What about Spring is obsolete?
Jun 06, 2014 @ 15:11:06
Bill, I fully agree with that.
We should all code to standards, specifications, which means multiple people or companies agreed on something. That’s Java EE. If you can’t find a needed feature, just use it from another framework. But in 2014, with Java EE 7 / Java SE 8, the best tools are indeed the standard, Java EE ones. The gap that Spring once filled looks like a bunch of typeless boilerplate code, nowadays. It simply isn’t required anymore in a lot of use cases. When used, it justs couples your code to proprietary Spring stuff, with its only implementation. I’m glad it’s been unnecessary, for years now.
Enterprise Dev with GWT, Java EE, and Errai | Bill the Plumber
Mar 13, 2014 @ 13:34:59
Mar 28, 2014 @ 20:52:16
Better Spring or Java EE than .NET. If .NET wins we all loose.
Mar 30, 2014 @ 19:39:56
Hi all. As for me I will vote for Java SE EE in standard complectation. Now I cannot understand for really what in Java need Spring Hibernate or EJB too. Their are not in C++. The best way is to do things more quick and easy. Also anybody could say what really need to know now and in the future. Thank you.
Apr 13, 2014 @ 16:10:48
I’m not too impressed with the apparent ignorance in the field of software engineering… How is it that in this field… ripe with such brilliant, educated and intelligent people, we so easily lose focus and get into pissing contests and holy wars …
Resources … Materials… Tools … That’s It…
Take away your perceived intellect… your education… your experience… your knowledge and expertise and measure these comparisons for what they really are …
Opinions…
Now Let’s Go Build Something …
Apr 14, 2014 @ 13:37:42
I agree, I don’t understand why people get so worked up about a blog I wrote almost 3 years ago.
Jul 25, 2014 @ 16:14:37
Neither do I! I haven’t bothered to read the majority of the childish comments and insignificant arguments on this post. Here is my take:
I have been in a new job for a few months now where I am running a web-based enterprise application that is built using Spring.
My old job was where I was running a web-based enterprise application using JavaEE, with EJB 3.1.
My experience on the JavaEE vs Spring issue is:
1. I have not seen spring doing anything that cannot be achieved by the JavaEE framework.
2. The spring framework seems more amateur and prone to deployment difficulties.
3. The solutions in my current app that have been implemented by previous developers using Spring are a lot more complicated than the equivalent solution would have been had they stuck to JavaEE.
4. The developers I work with appear to be somewhat brainwashed with respect to the use of Spring. They:
– use it to solve problems where simple Java code will do the job.
– think about how the problem can be adapted to be solved by the Spring framework rather than thinking about how the spring framework can be adapted to the problem. The latter train of thought would in many cases lead to the conclusion that the Spring framework is not suitable for the problem.
If I were given an entirely greenfield enterprise web app to develop, I would not use ANY elements of the spring framework.
Apr 07, 2015 @ 11:34:35
“It always depended core Java EE specs like JPA, JTA, JMS, and Servlet. So, since you couldn’t deploy a Spring app without at least one of these core technologies/specifications, Java EE stayed in users minds”
False! You don’t need any of them if you don’t want, why JPA or JTA if i don’t use DB? why servlet in a standalone env?
“Spring could not replace Java EE because technology wise, they were dependent on it”
As each framework, or you use j2ee implementation of JCE directly for RSA algorithm? In my job, you’re fired right now for that.
“Java EE 5 grabbed this opportunity with a huge facelift and refactoring of EJB and the introduction of JPA. Basically, this was a standardization of Hibernate and its integration into EJB”
WTF are you saying!? JPA is the standard spec, and hibernate just one implementation of this.
“When annotations came out, I remember the Spring folks writing multiple blogs and forum posts about how evil they were”
Exactly as you’re doing now, just subjetive stuff.
“App Servers got their act together”
Please try cdi in websphere.
“The whole Spring complaint that you needed Spring to mock out and test your code because app-servers started so slow was moot.”
This is true, if you have an app with a lot of beans and injection, it gets slow. I mean, a really huge app, like 10M lines of code. In fact, it’s better to think about XML, wich isn’t as bad as it seems, just organization needed.
Just the last thing, Spring guys are part of the j2ee cdi standard. How awful if they are the loosers.
Apr 07, 2015 @ 13:00:16
FYI, this blog post is 3+ years old now, and I find it funny that Spring-tards *STILL* get angry over it. I was actually there and involved. I was on the EJB3.0/JPA JSR with Gavin King. JPA was basically the standardization of Hibernate and Toplink. Gavin King and Mike Keith (from Oracle) were basically the authors and drivers of JPA. We hired the lead TCK developer from Sun, she actually said that Hibernate and JBoss’s EJB 3.0 implementation were used to test and implement the initial TCK because no other implementation was ready.
As far as CDI goes, the Spring guys basically were non-participants and fought everything, even tried to start their own competing standard. I was there. I saw the politics…Were you? Or did you just drink the Rod Johnson cool-aid and blindly believe his line of bull? I saw, in person, a lot of Rod Johnson talks over the years….well…really it was the same talk over and over again. A talk that was years out of date by the time Rod made his millions and retired. Good for him, he worked crazy hard, all of us Java guys did, and we were all rewarded one one way or another for our contributions to the community.
BTW, IBM has showed over and over the past 10+ years that they cannot get their act together. Honestly, Websphere is almost solely responsible for any negativity around Java EE. Rod and Spring guys pretty much owe their fortunes to the crappiness of Websphere as they were the only ones that cared enough to make that shit platform usable. To this day, I’m still amazed how us handful of JBoss guys could out-manuever and out-code and out-perform the army of IBM Websphere developers. Just shows you how fucked up IBM was/is. Sucks that you could never use JBoss/Wildfly, Glassfish, or even TomEE as these are the app servers that “got their act together”. Really, not my problem. We did our best to help improve the specifications. If IBM can’t execute, that’s their problem.
Apr 07, 2015 @ 13:09:51
3 years later….
hahahahaha!
Why do you only mention Websphere?
We used to develop for that app server and you are totally right: making run things that even older Tomcat can run in Websphere was a daunting task.
But what about all other JEE servers?
JBoss? Glassfish? TomEE? Or the best IMHO): Weblogic?
Have you deployed to them?
What I often see is Spring apps deployed to Tomcat and the bootstrap of those apps are very very VERY slow.
As I stated before Spring was a good thing, specially in the era when JEE containers were sluggish and expensive which is not the case today. Have you see how quickly GF or JBoss deploys and/or starts a JEE application?