Enterprise Dev with GWT, Java EE, and Errai

March 13, 2014

billburke java, javaee, spring 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

March 13, 2012

billburke java, javaee, spring 169 Comments

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

September 7, 2010

billburke hornetq, java, jboss, jms, spring 6 Comments

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();
jms.start();

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"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

   <bean id="EmbeddedJms" 
                class="org.hornetq.integration.spring.SpringJmsBootstrap" 
                init-method="start" destroy-method="stop"/>

   <bean id="listener"
             class="org.hornetq.tests.integration.spring.ExampleListener"/>

   <bean id="listenerContainer"
             class="org.springframework.jms.listener.DefaultMessageListenerContainer">
      <property name="connectionFactory" ref="ConnectionFactory"/>
      <property name="destination" ref="/queue/exampleQueue"/>
      <property name="messageListener" ref="listener"/>
   </bean>

</beans>

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

April 2, 2009

billburke java, jboss, spring 8 Comments

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.

SpringSource goes for 15M more

July 9, 2008

billburke business, spring 3 Comments

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

February 13, 2008

billburke ejb3, seam, spring 22 Comments

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.

Standardize Spring in EE 6

September 3, 2007

billburke spring 23 Comments

Back in 2004 JBoss had a tough decision to make. Should we keep Hibernate proprietary and under our sole control? Or should we bring it to a standards body? You know the decision we made. I think Spring and Interface 21 are at a similar crossroads, whether they know it or not. I’d like to call on Interface 21 to bring core Spring IoC to EE 6. Here’s why its a win-win situation for everybody.

Better business for Interface 21

I personally think that the main reason I21 hasn’t thought about standardizing Spring is because they are worried it will hurt their business. We had the exact similar fear with Hibernate. What would happen if we standardized Hibernate and gave the opportunity to vendors like Oracle and BEA to enter the ORM space and threaten our growing strangle hold on ORM frameworks? The reality of the situation was that there was a shrinking, but still very large, set of users out there still using CMP. Many of these organizations were married to standards and wouldn’t go proprietary, even though Hibernate was open source. What ended up happening was that when we brought Hibernate to the EJB 3.0 and JPA specification, Hibernate was recognized immediately as a migration path to EE 5. Hibernate downloads skyrocketed along with Hibernate related business. I just know that Spring and Interface 21 would notice similar gains if they aligned with EE 6.

The Spring community will probably scoff at any suggestion that the EJB user base is still large enough to make any impact on things, but this is just not the case. Yes, Spring has a large community, but EE 5 stopped much of the bleeding and breathed new life into the EJB specification. I know this because I’ve been out there. There’s also these compelling facts about EJB 3 momentum that I posted on a TSS thread back in June.

Better for the Spring community

Let’s face it, Spring is not a kernel. It has no deployment model. It is dependent on bootstrapping itself through the WAR init process, manually, or by proprietary app server specific init classes. It has no classloader scoping, delegating it to the application server it is running in. The Spring guys know this is a weakness of theirs, which is why they are so keen to align themselves with OSGi. They desperately need a standardized kernel to build their own stack. If Spring was brought to EE 6, they would get this deployment model they so thirst for. Not only this, but it would be even easier, more consistent, and simpler to package and deploy Spring components within other application servers like what we do with the JBoss Spring Deployer. The Spring community would also get the benefit of mixing and matching Spring technology with EE component models.

Now, a bit more touchy non-technical subject is the idea that Spring is controlled by one vendor. Yes, its open source, but, IMO, JBoss history proves that a vendor can maintain tight control over its space even if there is defection and forking. Way back in the day, people also complained of the stranglehold Marc Fleury had on JBoss. The thing is, I thought our users were isolated from any real or imagined evil we might inflict on the open source Java community because we were standards base. This isn’t so with Spring. Spring is now VC funded which means its founders and investors are looking for an exit strategy and payday event. There were recent rumors of acquisition we heard as well before they announced this funding. Yes, this sounds a lot like FUD from me, but it is just the plain reality of the software business. Having Spring standardized would isolate the Spring community from the mess of any acquisition, IPO, founder exit, or going out of business fire sale. Any real or imagined mess 😉

Better for Java EE

Although EE 5 added some IoC capabilities, its still both verbose and incomplete. For instance, you cannot define graphs of pojos within XML and inject it into an EE components. This limits EE to having to solely work with primitives when doing configuration. Not very flexible. Beyond technical reasons, having Spring standardized would make EE 6 a compelling platform to migrate to just like annotations and Hibernate standardization made EE 5 exciting. Bringing the weight of the Spring community into EE would greatly strengthen and unify the Java enterprise space.

Unification

Before EE 5, you had division in the Java ORM world. You had the CMP crowd: big, but legacy. The JDO crowd: noisy, but irrelevant. And the Hibernate crowd: large, de facto, but proprietary. What JPA did was get everybody together and start showing a unified path and vision for the Java ORM space. I think Spring and EJB are in a very similar situation and we would get similar benefit of joining them.

So Rod, Bill Shannon this is good for everybody, so lets get it done.