Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Rob Thornton on Nov 20, 2006
Rick Hightower has posted a few graphs from Indeed's Job Trends comparing Spring against EJB3 and various ORM tools against each other. The graphs show that Spring is steadily gaining while EJB3 (and EJB overall) is not. Similarly, Hibernate continues to dominate the ORM field in job postings.
Using Indeed's Job Trends, which allows you to compare job postings between different keywords, he analyzed EJB3 vs Spring. As can be seen in the graph below, EJB is steadily slipping while Spring is continues to grow.
If the current trends continue, in the next six months Spring will overtake EJB.
After looking at containers, he looked at ORM solutions and, as shown here, Hibernate is far and away the most popular tool.
Lastly he compared Spring to JBoss to see how that battle was doing. The trend shows that while Spring and JBoss are both gaining, Spring is increasing much faster and has nearly caught JBoss.
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Regaining control of the data centre
Innovation in Your Data Centre
The 5 Mandates of Software Development Teams - Presto Manifesto
Rick forgot to post the JSF numbers. Webwork's rate of growth annihilates JSF, which is barely able to outpace the growth of Struts at this point.
Give EJB3 some time. Once more Java EE 5 app servers are out, i assume it will balance with, or later surpass Spring. i know that Spring can coexist with EJB3, but in practice not sure if people will follow that road. Of course, people who do not use app servers will treasure Spring, it makes a lot of things easier. But especially when it is used with an app server, it just feels like an extra and unnecessary abstraction layer.
According to Rick's figures JSF jobs have doubled in 6 months. Webwork's rate of growth may be higher, but it is from a very much smaller base, so remains (according to those figures) a small fraction of JSF's market share - hardly annihilation. The interesting thing about JSF is not just the overall growth rate, but the fact that the growth rate itself is getting faster - it is start of a classic technology adoption curve. This is also backed up by the increasing number of products offering component libraries for JSF.
Corby,
In your dreams! JSF job-demmand growth is outpacing the growth curve of Ruby on Rails (but its close curve wise). WebWork is not even close in its growth curve or it current rate.
Where do you get your figures?
Check out:
www.jroller.com/page/RickHigh?entry=demand_for_...
Silly rabbit, Web development is for JSF.
JSF growth is higher than WebWork. JSF job demmand doubled in the last 5 months. No other alternative to Struts was even close. The immediate future of Java web development looks very JSF centric. Struts has increased, but its chart looks very similar to COBOL. With that said, the only reason Struts is not in rapid decline, methinks, is because of WebWork. I like WebWork. It is like my 5th choice: JSF, Tapestry, Spring MVC, WebWork/Struts2, ....
JBoss EJB3 support is out. No?
Oracle's EJB3 support is out.
Glassfish is out.
It is just not going to happen. Why take a step backwards with EJB3? It is easier to add the annotation style support to Spring than to completely take a step backwards with EJB3.
EJB3 is a lot better than EJB2, but compared to Spring it is not so great. EJB3 is Spring and Hibernate's retarded cousin.
Read my further opinions on this topic at:
opensource.sys-con.com/read/216307.htm
EJB 3.0 is much better than EJB 2.x. If you compare EJB3 to an older version of EJB, EJB3 is a boon; however, if you compare EJB3 to Spring and Hibernate, it stinks.
The related OR (Object Relation) Persistent API does not have a criteria API specified; any persistent API that does not define a criteria API is not finished.
The AOP support in EJB3 is broken. EJB3 has a method interceptor, but no pointcuts. In addition, the method interceptors are declared and imported with class-level annotations. This effectively tightly couples the class to the method interceptors that decorate it (Can you smell the bad odor?).
Rod Johnson mentioned thess same problems about EJB3 Method Interceptors at a recent Java enterprise conference (in his talk "Are We There Yet") and went on to mention many limitations on the @Resource style of DI, the absence of FactoryBeans, post processors, Constructor Injection, lists/maps, and a lot of the features Spring developers know and love are just missing. The EJB3 JSR members did not look at any of the prior art in this space and created their own limited version of what was already available.
I've heard some call EJB3 a dumbed-down version of what is available by using Spring and Hibernate. "EJB3 is Spring and Hibernate's stupid cousin" is frequently echoed.
After three years of deliberation, the JCPs delivered EJB3, which is inferior to de facto standards. Many parts of EJB3 are a big step backward from Spring, and, to many, EJB3 is broken. As Bruce Tate says about EJB3: "Don't make me eat the elephant again."
It's not just the persistent API and the AOP support that's broken in EJB3, it's also the random use of annotations, another misguided effort. The idea of annotations is good. The implementation of the annotations ruins some of the principles of the POJO model; namely, it ties your Java classes through a compile-time dependency to the standard API you're using and to any value-add annotations the vendor supports. Now why would vendors like this approach? Hmmm...I wonder. (Hint: Follow the money!)
In that question lies the real problem with the JCP. The JCP is heavily influenced by vendors that have "business need(s) or corporate agenda(s)." Parts of the enterprise Java community is innovative, parts stink, but there are many parts.
Strangely enough, RoR, which is currently being championed by Bruce Tate among others, is a safe haven for Java developers who are sick of vendor-driven APIs. In short, vendor-centric JSRs, Struts, and EJB have driven many a developer, who just wanted to get things done, to RoR.
... (read the rest at syscon)....
Like I mentioned in my blog:
javajmc.blogspot.com/2006/11/struts-cobol-jsf-d...
I dont think the indeed.com results show what you think they do. In fact, I dont think they really mean anything for or against the growth of JSF. For example, search for all java jsf jobs that do NOT also contain Struts..and your results are cut in half. Filter our jsf listings that also contain jsp, and you get next to nothing (though still more than WebWork).
So, how do you know which toolkit the job is really looking for? Without making a bunch of assumptions, i dont think you know. I just dont think these "job listing" posts claiming framework X is growing more than Y are very useful. I think most (not all, but most) of the job listings are just listing a bunch of java technologies to increase the chances the job turns up in a search.
Corby,
In your dreams!
Where do you get your figures?
Silly rabbit, Web development is for JSF.
Here's where I got my figures:
www.indeed.com/jobtrends?q=jsf
www.indeed.com/jobtrends?q=webwork
I didn't see your other entry about jsf trends, so I was wrong when I said you forgot about jsf. It is very interesting that we got such radically different results when you added the term 'java' to your search terms.
I'm sure we could make arguments about whether adding the term java makes the search results more or less accurate, but in the end the differences probably just underscore how shaky this type of 'analysis' is.
What's most important is what's happening in the field. You are clearly seeing a lot of enthusiasm and adoption for JSF in the trenches, whereas I am seeing a bit of experimentation, usually followed by frustration.
we will see. we use Spring extensively and mostly happy about it. i am a supporter of spring, but i have my complains too. No matter what you say, standards has always an advantage over the non-standard populer. they are safer to play with, easier to learn and you can find resources easier. Spring has some things not really cool to me. Some stuff Developers are not really ready (AOP), or needed (Spring template for hibernate). Spring tries to please everybody, and that is why some of the mechanisms it uses is overly abstract, or mediocre (Spring MVC). it is easy to bloat your application with spring configurations (unlike EJB3-JSF) and believe it or not it makes you tied to spring in some ways (like you will soon feel a need for the library you use to be "spring compatible"). it just feels absurd to use Spring fully , if you have a modern Java EE 5 app server (like GlassFish). it has out of box web services, ORM, transactions support, clustering after all. some problems here and there, but it is good enough to. And by the emerge of new EJB-JSF based systems (Like Seam), or MVC's (like Stripes) i feel that Spring will be mostly used only for it's dependency injection mechanism later.
I added Java to exclued JSF as in Joint Strike Fighter (the other JSF). At one point about 1.5 years ago there were a lot of ads from companies looking for people who worked with or could who work on the Joint Strike Fighter.
Hmmmm.....
"So..now i'm looking through the results...and well over half mention jsp, or some other java web framework, along with JSF. These results are in NO WAY JSF only, or even JSF primary job listings. It looks like JSF is just listed along with one or more other java MVC frameworks, as the hiring companies are throwing most popular java frameworks in the job listing."
Do you mean to say that people are using JSF with JSP? Shock! Since JSP is the only templating framework supported by the core standard stack, this is not so shocking. People having experience with Struts to work on a JSF project is also not so shocking as Struts has been around a lot longer.
I made no assumptions about the data. I just presented it in its raw form. In the raw form, JSF is leading job-demmand wise to all the other preteneders to the Struts throne. Plain. Simple. Numbers. No editing needed. Cheers.
Based on your logic: There are 102 WebWork jobs on indeed, if you subtract the WebWork jobs that mention Struts, there is 21 jobs.
There is 192 Spring MVC jobs, if you substract jobs that also mention Struts than there is 55 Spring MVC jobs.
Of course I would not bother substracting JSP from either result, since both can use JSP.
And since we are talking about folks migrating from Struts to other platforms, the likely hood that Struts will also be mentioned is fairly high. I don't see how you can exclude jobs that mention Struts.
Job demmand for JSF has doubled in 5 months (with and w/o supporting legacy Struts apps).
RE: "No matter what you say, standards has always an advantage over the non-standard populer. they are safer to play with, easier to learn and you can find resources easier."
Yes I am sure this is why JDO did so much better than Hibernate b/c we are all so worried about standards. Oh wait, Hibernate crushed JDO adoption. Working technology counts more than standards. De facto standards (Struts, Spring, Hibernate) seem to do really well in the marketplace.
That said: I agree with you to a large extent about EJB3, JSF and Seam. I think the Spring project has missed the ball when it comes to the type of support that Seam provides. Spring Annotations (not done by the core Spring team) seems to get it. I think the Spring project has spent too much energy on Spring WebFlow and AspectJ while both are important and interesting not as much as what Spring Annotations and Seam provide. If I switch to the EJB3 stack, it will be because of Seam and its ilk.
Lastly he compared Spring to JBoss to see how that battle was doing. The trend shows that while Spring and JBoss are both gaining, Spring is increasing much faster and has nearly caught JBoss.
Isn't this comparing apples and oranges? What am I missing? When did Spring start battling with Jboss?
Not really. AFAIK, from the beginning Spring promotes usage of simple servlet containers against App servers (they dont mention about it after the whole BEA deal, but you can read pages of stuff in Rod's J2EE without EJB book.). So, basically, Spring sort of gives you the luxury of doing stuff you normally can do with App servers. However, after Java EE 5, most of the criticism over EJB is not valid. Thus, in a way it is fair to compare it against modern Java EE 5 app servers (in a sense one does not really need the other, but do the same job). Also, i believe the cutting edge on Java EE 5 is not JBoss, it is Glassfish..
RE: What am I missing? When did Spring start battling with Jboss?
A lot. Most of what EJB 3 has been available with Spring for years. There is a lot of overlap. The JBoss microcontainer is a direct answer to Spring. Project pitchfork is a direct answer to JBoss. Declaritive transaction managment... Spring has it and it can work with Tomcat... Method interceptors... Spring has it and it is an order of magnitude better than EJB3. You don't need JBoss for many applications. EJB 3 provides a dumbed down version of what already exists in Spring. While Spring continues to move forward, EJB 3 is stuck in time until the major vendors add support for it. (Major vendors != JBoss and Glassfish.)
I've got nothing against JBoss. I like it well enough. It is a quiver for my bow when the situation arises.
There has been a lot of tension between the Spring camp and JBoss camp (just google it). (I don't represent either camp. I am an independent 3rd party.) I actually like both camps well enough. It would be better if they got along. (Maybe they already do...)
Choice is good and maybe one day the JBoss microcontainer will be a valid choice against Spring, but it seems unlikely at this point.
RE: However, after Java EE 5, most of the criticism over EJB is not valid.
I agree, most of the EJB2 critisism is not valid. Now of course there is the critisism of EJB 3. No pointcuts. Reliance of vendor specific annotations. Reliance on annotation period. It is much more brittle than what Spring provides.
Glassfish does not have enough market share to matter much. EJB3 will not be a valid alternative until JBoss (just added), BEA (when?) and IBM (when ?) have support for it.
Spring now works with all major app servers, and it is better than what EJB3 provides so.... why?
I've been more and more disappointed with Hibernate lately. They seem to be more interested in adding "cool new features" than in fixing bugs.
"Advanced" features (like Map-based associations and ordered List associations) have serious bugs that prevent them from working correctly (see HHH-2038 and this forum post for example).
I'm currently evaluating JDO and JPA to replace Hibernate, because I've lost confidence in it. At least in theory, I could change the JDO or JPA implementation to work around this kind of bugs.
I don't doubt that you can find an issue with Hibernate. (Although I have worked with Map based associations and ordered list associations and have not had any issues per se, but perhaps I don't use them like you.)
Hmmmm..... It is good to have choices. I generally pick Hibernate. It has always worked for me. Good luck.
"Oh wait, Hibernate crushed JDO adoption."
I agree with you about most things, but I think this is too simple. I think earlier versions of JDO crushed their own adoption by not having adequate ORM support. JDO 2.0 is a very different animal. It lacks things you really like (such as the critera API), but is way above JPA in terms of capabilities (not hard, I know). I suspect it has a chance of reasonable adoption (though won't challenge Hibernate's dominance) as it seems to be far more suited to areas that Hibernate seems not that interested in - high volume transactions, non-relational persistence (which seems to be growing).
RE: I agree with you about most things,
Then you must have a really high IQ. ;o)
RE: I think earlier versions of JDO crushed their own adoption by not having adequate ORM support.
Hmmmm... Hibernate dominance had something to do with it... I am sure.
So will JDO have a major rebirth with 2.0? (Doubtful....)
Let me know if it does.
I hope my criticism of JDO leaves me some room to be critical of JPA as well which is a very underspecified specification mostly to appease the JxEE vendors with out having a scary developer-centric features.
See:
www.jroller.com/page/RickHigh?entry=jpa_misfeat...
(JRoller seems to be down at the moment....)
Here is the whole post:
Let me write about another JPA misfeature: the JPA Transaction API. In Hibernate (and Spring for that matter) there is one Transaction API that works with global transactions (JTA) and local transactions (JDBC datasource, i.e., the JDBC connection API). However, with JPA the Transaction API, which looks almost identical to Hibernate's Transaction API, only supports local transactions. If you want to use global transactions, you have to use the JTA transaction API directly. Two APIs to work with.
Here is another reason to use Spring. Spring has not sold its soul to the JCP. The funny part about this is that the original Hibernate book (Hibernate in Action) declares the insight into its single API to manage both types of Transaction, while the latest copy of the book declares how this was a misfeature. Yes... a misfeature that greatly simplifies testing by providing a single API.... Yikes! Talk about being sold down the river for a few pieces of silver. (BTW both books are wonderful and I would not recommend using Hibernate w/o reading them, but still)
There are some parts I like about JPA. Its transaction API and its lack of a Criteria API are not winning me over.
I know EJB 3 and JPA have parted their ways but they came from the same roots so I will continue to lump them together.
Disclaimer: I have not affiliation with the Spring project.
Note: I think that JPA is a good idea and I like the idea of having a standard API for Java persistence. Expectation: The book says something like this: "We tried to warn those boneheads to use a single API for both types of transactions but they were so worried about losing market-share by losing their tie on developers through a restrictive API that they would not let us do the right thing." Instead, the book insults our IQ. Of course it would be better to have a single API. Of course Hibernate does it the right way and JPA is broken. You can dissent and still be on a JSR can't you? The reason given in the book for this change in course was weak. (BTW: Darn good book anyway... buy two... give one to a friend.... it is a great Hibernate resource...)
I checked Amazon. The second book (Java Persistence with Hibernate) is not available yet. Where did you get it?
If you use JPA in a JEE server, you should use JPA in conjunction with EJB3 session bean. Then the EJB3 container will decide whether it will be a local transaction or global transaction.
If you use JPA outside a JEE server, well, it should be a local transaction anyway. I was once bashed for merely suggesting global transaction outside a JEE server (on the serverside).
You can buy the PDF from Manning. I bought the PDF and printed it out. I sleep with it under my pillow hoping that some of the 600+ pages absorb into my brain.
I think it cost me $50.00 to print it out and bind it myself. (Or there abouts...)
It is a really great book.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
24 comments
Watch Thread Reply