Enterprise Dev with GWT, Java EE, and Errai

Leave a comment

Here’s an interesting testimonial on using GWT, Java EE, and Errai to build an application.

“When I stumbled upon Errai, I was re-introduced to JEE.  We had previously explored a variety of backend frameworks, including Spring and most recently Guice.  I was instantly amazed and attracted to the simplicity and elegance of JEE – in particular the CDI API.  Once I had my JBoss AS 7 environment set up, I was incredibly pleased with how neatly everything just seemed to “work” – REST, Persistence/Transactions, CDI, and how little configuration was required.  It almost didn’t seem possible.”

A few years ago, I wrote a blog about how Java EE made a huge comeback over Spring as a development platform.  159 comments later I still get people ranting for or against me on that thread.  What was interesting about this particular testimonial is that the developer investigated both Spring and Guice.

“We had previously explored a variety of backend frameworks, including Spring and most recently Guice.”

I still stand by my 2+ year old blog that Java EE made a huge comeback as a web development platform.


Java EE wins over Spring


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.


Improved HornetQ Spring Integration


I’ve been doing some work on HornetQ SVN trunk to improve the embeddable HornetQ experience (you’ll see these improvements in the next HornetQ release).  You can disagree with me, but I thought that embedding HornetQ was a bit verbose, especially for JMS, so first of all, I wrote two wrapper classes to make this easier.  While these classes will be in the next release along with a full docbook explanation, here’s what configuring JMS looks like now:

import org.hornetq.jms.server.embedded.EmbeddedJMS;

EmbeddedJMS jms = new EmbeddedJMS();

This class will look for hornetq-configuration.xml, hornetq-jms.xml, and hornetq-users.xml within your classpath.  It also has the option of manually creating configuration objects via pojo instantiation if you desire (or if you want to wire it with Spring for instance).

Simple Spring Integration

Another thing I did was to provide some simple Spring integration with the HornetQ JMS implementation.  I wrote a simple class that extends EmbeddedJMS that will register any configured queues, topics, and ConnectionFactorys direction within the Spring application context so that other beans can reference them.  Here’s an example of bootstrapping HornetQ JMS and referencing a queue within a Spring message listener container.

<beans xmlns="http://www.springframework.org/schema/beans"

   <bean id="EmbeddedJms" 
                init-method="start" destroy-method="stop"/>

   <bean id="listener"

   <bean id="listenerContainer"
      <property name="connectionFactory" ref="ConnectionFactory"/>
      <property name="destination" ref="/queue/exampleQueue"/>
      <property name="messageListener" ref="listener"/>


Again, this assumes you have configured HornetQ properly within HornetQ specific configuration files.  You can also manually declare HornetQ config objects within Spring and inject them into the EmbeddedJMS bean instance too if you don’t want to use HornetQ config files.

Right now, the code does not also register HornetQ objects within JNDI.  Do you think I should add this capability?  Anyways, I hope you’ll find this HornetQ + Spring integration useful in the next HornetQ release.

OSGi doesn’t need to be in your face


Awhile back on TSS, I complained about OSGi possibly bleeding too much into applications.  That OSGi did not belong within application code.  This IBM article is a prime example of my point.  Here we have standard Spring code and XML.  Nowhere in there do you have OSGi APIs.  Yet, you get OSGi classloading and lifecycle.  I bet, that if you can’t already right now, Spring will eventually be able to register IoC references as direct dependencies within an OSGi kernel.  There’s really no reason or advantage to have OSGi APIs bleed into application code.

Another example is JBoss 5.  While not running on top of an OSGi kernel (instead its running on JBoss’s own special kernel) it can manage dependency and lifecycle for a variety of different component models like:  Spring, JBoss MC, EJBs, JCA adapters, Queues, Topics, Servlets, etc.  This can work because JBoss’s kernel provides a deployment abstraction and framework to publish and manage inter-component dependencies.  The end goal here is that all these different component models can take advantage of all this dependency management without writing to specific APIs and to stay within the confines of their own component model’s specification.  The metadata is there.  The dependency information is there.  There’s no reason to write to a specific deployment API to leverage these types of services.

This is what I had hoped OSGi would become.  A standard kernel where classloading, deployment, and dependency management would be provided as low level services so that existing and new component models would have a standard way to mix and match themselves and to deploy themselves.  In theory, such a kernel would allow JBoss’s Transaction Manager to run within a Web Logic server.  JBoss’s EJB container to run within Websphere.  Sun’s WS-* implementation to run within JBoss.

Maybe my concern is not real.  Maybe most OSGi evangelists are not positioning OSGi as an application API.  Let’s hope they aren’t.

Spring Source: The drug dealer approach to OSS


Rod and Spring Source continue to make some questionable decisions on the licensing and distribution of the Spring Framework.  I’m wondering if Rod is getting some serious pressure to deliver on the more than $25 Million in VC money he’s gotten over the past 2 years, he’s plain getting bad advice, or just had an SMD moment with the OSS freeloaders out there that refuse to buy subscriptions for technology that isn’t much more than an EJB container and Struts.

I told you so!

The latest botched attempt to monetize Spring was the announcment that they would not be releasing community versions 3 months after a major release and further point releases could only be gotten from a subscription.  The Spring community was pretty pissed off as noted by this 200 post TSS Thread.

A year ago I warned you VC initiated things like this might happen to Spring when I demanded to Standardize Spring in EE 6.  Open source alone doesn’t isolate you from vendor-lockin.  Its standards + open source combined that give you true freedom.  Its why we standardized Hibernate under JPA and why we’re standardizing Seam under the Web Beans specification.

A Bad Move

The funny thing is, this money grab by Rod and company didn’t need to happen.  The move left me scratching my head in wonderment at the stupidity of SS management.  This move was stupid for two reasons:

  1. Spring Source pissed off their community for no good reason.  Developers can still get access to the latest and greatest Spring source code, but they have to build it themselves.  (And also hope the current branch is stable, but that really shouldn’t be a problem with using SVN and timestamp checkouts).  What I bet will happen is some people who haven’t tried EJB3 will try it now.  Others will simply look for an alternative like Google’s Guice framework or even JBoss Seam.  Others, with more initiative might even fork Spring.  Hey, its ASL, it could even live at Apache.org!  Actually?  No, this isn’t a very big deal.  JBoss supposedly pissed off the open source “mainstream” years and years ago (2003) and this didn’t hurt our growth rate, or hinder our dominance.  Still, bad PR is bad PR.
  2. More importantly, Spring Source screwed up their ecosystem.  How?  Many Java open source projects rely on Spring to bootstrap themselves, or for integration purposes.  For example, the Grails projects uses Spring extensively.  This move by Spring Source has screwed projects like Grails that have depended on Spring to work.  The problem is that 90% of Spring (at least the 90% of what people use Spring for) is the integration it does with other third-party products and projects.  What happens to Spring if the third-party projects in their ecosystem stop using Spring to integrate?  Rod just endangered the very thing that makes Spring compelling!

A Better Way

What boggles my mind here is that this could have been done very differently.  WE DO NOT DO THIS AT JBOSS!!! WE CONTINUALLY RELEASE COMMUNITY VERSIONS OF OUR SOFTWARE. And yet, we have are are still growing like crazy.  What makes people buy subscriptions is value-add.

The biggest value add is that large organizations want to know that you are going to support versions of your software for years.  Let’s say 3-5 years after its released.  Spring Source, could have left their announcement at “We will support Spring versions for 3 years” and it would have been a huge win for them.  I know it helped our sales when we announced a similar support policy years ago.

Another value-add is what we built with the JBoss Operations Network.  JON not only gives you management and monitoring, but also helps with pushing patches and critical security updates to users as quickly as possible.  You make distribution a service that people want to pay for.

A third value-add is to give away proprietary add-ons with the subscription.  For us, what we did was license or acquire proprietary technology.  We licensed the underlying technology of JON, which we later open sourced.  We acquired technology from Excedel to help productize our Eclipse tool offering.

The fourth and final, is of course indemnification.  Where we protect you legally from lawsuits.

The Drug Dealer Approach

Instead of modeling themselves like other open source businesses, Rod had to take the drug dealer approach to professional open source.  Give open source users a free taste of pure open source smack, get them hooked, then charge them big bucks when they need a fix for their Spring addiction.  What’s sad, it just didn’t have to be this way.

SpringSource goes for 15M more


Seems Rod isn’t immune to the typical startup hunger for cash. They raised another $15 million today. To put things into perspective, Jboss raised $10 million in 2004. When we got acquired in 2006 we had only burned through 5-6 million and that was after the Arjuna acquisition, building a new 2 floor office, and adding 150 people to the payroll. I’ve been at startups that burned through 10 million in 6 months then went out of business. I hope this is good news rather than bad news for the SS. Even though I do trash them every once in awhile, every professional open source success is good for the industry and inches the industry closer to an open source model.

EJB maintains its dominance


EJB was created almost 10 years ago to solve the component needs of application developers. Since then thousands of successful applications have been written and deployed using this technology. Although I don’t do much with EJB nowadays as I have other responsibilities at JBoss, I still wonder how it is doing in the industry. Recently, I became privy to various bits of knowledge that EJB is still going strong and maintaining its dominance in Java application development. Consider this job trends graph from indeed.com:

EJB job graph

Over 3 years EJB jobs have remained pretty much constant. This is very encouraging news considering recent Rod Johnson propaganda. EJB really did not have an alternative in the Java space until 2004/2005 when Spring started to be known and popular. It is very interesting to see that although EJB has had a serious competitor, it has maintained its dominance in Java application development over the years. You could even extrapolate from these numbers that EJB is an upper bound on the number of Java component jobs out there and that Spring has only recently matched this. This is proven by the fact that the Spring and Java graph trends are the same since they converged 6 months ago.

This trend pretty much correlates with download numbers I posted on our EJB implementation awhile back on TSS in June 2007.

I can give you a few from two perspectives:

downloads on sf.net for JBoss and Hibernate projects related to EJB3 and JPA:

* Downloads of a standalone distribution of the JBoss EJB3 project since 10/2004: 183199

* JEMS installer which bundles EJB 3.0 (not same as JBoss Appserver download): 201923

* JBoss 4.2 which bundles EJB 3.0: ~65000

* JBoss 5 betas which bundles EJB 3.0: ~80000

* Hibernate’s JPA implementation: 135269

* Hibernate Annotations (which is JPA based): 202561

So, total downloads solely related to JPA: ~337K
Total downloads solely related to EJB3: ~550K
Total EJB3 + JPA related downlaods: ~ 887K

Compare that to Spring 2.x downloads: ~600K
Spring 1.x downloads: 946K
Hibernate 3.x downloads: 1445K
Hibernate 2.x downloads: 495K

Now that’s just JBoss. You also have Glassfish, Open JPA, Oracle, and now Geronimo communities not included in these numbers.

Also, my EJB 3.0 book has been out a year and has sold ~12K copies +/- a thousand (haven’t gotten check yet from last quarter).

So, all and all I think there is pretty compelling evidence that EJB3 and JPA has momentum.

Its hard to continue any analysis on JBoss specific download numbers as we basically encourage our user base to download JBoss 4.2.x or 5 as it is bundled with our EJB3 implementation.

There’s some other encouraging numbers as well. In 2005 I was offered by O’Reilly to take over Richard Monson-Haefel’s EJB series.  “EJB 3.0, 5th Edition” was published in May, 2006. Even after being out for almost a year and half, sales are still going strong. Just last quarter we sold 1700 copies, very good for a technical book. When I went to Krakow in October, I also found that my book had been translated into Polish. I believe its also been published in Chinese. All indicators of broad adoption by the technology.

So, as you can see, even after almost 10 years, EJB is still going strong and maintaining its dominance. With the emergence of Seam and Web Beans being incorporated into EE 6, I predict this trend to continue.

Older Entries

%d bloggers like this: