Salil Deshpande, ex CEO of The Middleware Company (the company that originally created TheServerSide.com and TheServerSide Java Symposium), and now a venture capitalist with Bay Partners (the venture firm that among other things, invested in Weblogic, before it was acquired by BEA) attended TheServerSide Java Symposium after a long hiatus. He shares his perspective and experience – this article is partly human-interest and partly technical.
The last time I attended TheServerSide Java Symposium, it was in 2004, also at The Venetian, when I was running The Middleware Company. It was only our 2 nd year running the conference, and the first time at a big venue. I remember the excitement all of us felt as our little Java conference had grown up. We were humbled that all the trailblazers and mavens had deemed our conference worthy, and were in attendance, which resulted in a more intimate and productive environment for server-side Java topics than larger conferences such as JavaOne (but that probably goes without saying). The big news was that EJB3 was finally being unveiled (and that Sun chose to do it at our conference, not at JavaOne).
The new J2EE was back with a vengeance. BEA’s demeanor indicated that Weblogic was going to be out in front with a beta implementation of EJB3, with Websphere and others soon to follow. JBoss had recently acquired Hibernate, a major influence on EJB3. JBoss and open source were often spoken of together. We had just produced (with the help of TheServerSide community) and distributed to every attendee the “Who’s Who in Enterprise Java” deck of playing cards (Spades were for power and influence, Hearts were for community & developer love, and so on, with Ace being strongest, Deuce being lowest) in which Marc Fleury was the Joker. JBoss had one of the keynotes, and Marc and delivered it dressed up as a Joker (not a clown, but the Joker from Batman), a very gracious way of dealing with our bratty little stunt. Spring 1.0 had just been released and Rod Johnson, who had recently created the Spring framework, was only the 5 of Hearts…
Some things stay the same.
After TheServerSide web properties became part of TechTarget, I had taken a couple of years off to play with my 3- and 5-year-olds, and I had let Java conferences drift downwards on my priority list. It was déjà vu as I walked to the conference three years later and registered. Same old Venetian, same old carpets, same old smoky casinos and hallways. Same old ding-ding-ding-ding slot machine noises as you had to walk through the casino to get to the ballrooms. And it seemed like all the familiar faces instantly appeared in the first twenty minutes, down to Jody the camera guy. It was awesome.
But what a difference three years makes
But this year, there was barely any mention of Sun or BEA. Or JBoss. Or EJB. Java EE, maybe sometimes, in passing. Oracle did make a small splash by announcing that they had acquired Tangosol, which had just started getting on people’s radar in 2004.
So what was the juggernaut du jour? It was all Spring, all the time, baby.
There was a whole track dedicated to Spring. It made sense of course, but I wasn’t expecting it. And even sessions I attended that were not in the Spring track did not fail to talk about Spring. John Davies’ keynote session, on what investment banks are using as their technology stack, covered many things, but Spring was at the core of the stack. After that keynote I walked around to where the booths were. The folks in the GigaSpaces booth were demonstrating OpenSpaces, a framework that uses Spring to hide many of the complexities of the GigaSpaces product, and said that future versions of the product will require Spring.
Ross Mason, CTO of MuleSource, spoke about how Mule 2.0 open-source enterprise service bus (ESB) is influenced by and supports Spring 2.0, and was careful to explain not only how Mule fits with Spring, but how Spring was vital to Mule. From Frank Cohen’s report on the session:
“The room was full of developers interested in Mule, most of them already use Spring. Mason directed the attendees to consider that while Spring provides a good development framework, that Mule provides a very good runtime environment. In both cases Java developers are working with Plain Old Java Objects (POJOs) that become services using Spring and are deployed to a service bus using Mule. Mason told attendees Mule is ideal for situations where a POJO-created service will be under heavy load, with lots of concurrent requests, shared POJO functions between multiple applications, and using mix-and-match synchronous, asynchronous, and request/response patterns. Mule supports 30 transports, including XA and local transaction support with Spring transactions.”
“Spring 2.0 enables Mule to do namespace handlers (no need for class names, instead Mule defines properties in a schema and offers validation that properties are set correctly), new` orchestration like Java contract based messaging, and Aspect Oriented Programming (AOP) and OSGi hot deployment of services.”
For me this conference finally drive home that Spring is truly taking over. What’s funny to me is that Spring is finally solving the problems that J2EE and application server products identified, and tried to solve, but couldn’t.
It was amazing that all this time Sun had left the door to the Enterprise Java world wide open (well all right, not that amazing) and Spring had waded right in.
Although the old-timers think of Spring as mainly a Dependency Injection (DI) solution, the DI combined with two other core facilities, Spring 2.0 AOP, and portable services abstractions, plus all the community traction, really make it a true platform.
The curious thing about Spring as a platform is not just that it’s getting larger (more feature-full, more functional, more powerful) over time. All platforms do that.
The curious thing is that apparently due to its decoupled inside-out pieces-parts architecture, and some key decisions the Spring team have made recently, it actually seems to be getting simpler to use. Most platforms don’t do that – they get more complex until things come to a head, before they get simpler (if they survive).
One of those key decisions seems to have been in the area of Annotations. Last I checked, the Spring team had been opposed to Annotations, taking the purist stance that configuration and meta information should not be in your code, but factored out into configuration files (XML of course). Fast forward to 2007, and Spring 2.0 supports annotations as an alternative to putting this information in XML files (for AOP-related stuff in 2.0 and for everything in Spring 2.1). Apparently the market had spoken, and kudos to the Spring team for listening. Taking a dogmatic stance against annotations could have been one of the many potholes that platforms reliably hit.
In 2004 we were only mildly concerned that in the name of factoring infrastructure dependencies out of our code, our systems had many thousands of lines of XML, as configuration. XML had started to run the world, even in build systems such as Ant – thousands of lines of XML code in Ant, ugh. And it seemed that we had just started to copy good ideas from .NET. Annotations had just started to come on the scene, and everyone was worried about Annotation hell. It’s still early days, and there’s still a lot to worry about, but it’s looking good (it looks like we are managing to balance well) and that Annotations used judiciously have been a big part of the solution to the XML problem.
Back then I also remember the mavens in the Java community feeling mildly threatened by, or at least having mild resentment towards, .NET. I definitely recall the sentiment that Microsoft was “coming after us.” The massive J2EE vs. .NET benchmarks we did were unpopular and caused controversy, but were widely regarded as good work. As a community, we got comfortable with the fact that .NET was going to be viable and wouldn’t eat our lunch. In 2007, there seemed to be unspoken acceptance that .NET was not a threat, and possibly even a deployment alternative, with which it’s beneficial to all to interoperate and play nice. Given the pervasiveness of Spring, Spring.NET seems to be an awesome way for Java developers to write software as POJO’s, and deploy to .NET with minimal impact.
In 2004, there was an AOP track. Debates raged over DynAOP vs. AspectJ vs. AspectWerkz. Since then AspectJ and AspectWerkz have merged. Some of us thought that all developers would be writing aspects. That hasn’t happened at all, and 2007 attendees seemed to think that the most pragmatic use of aspects is via Spring AOP! It doesn’t hurt that Interface21 grabbed two AOP rock stars, Adrian Colyer, lead of AspectJ, and Ramnivas Laddad, author of AspectJ in Action.
Okay, Enough about Spring
As an aside on the two general unrelated topics of copying good ideas from .NET, and suddenly realizing that things sucked: there was general consensus among speakers and panelists that when Sun copied generics from .NET, they traded off the most important feature (type erasure) in the name of backwards compatibility. Now a Java programmer a look at a piece of supposedly well-written Java code, and legitimately have no friggin’ idea what it does.
Back then we were still debating Java Data Objects (JDO) vs. Hibernate. Turned out, it was the last year we did so. Hibernate won; and ideas from Hibernate, Toplink, and JDO went into the Java Persistence API (JPA) standard. Patrick Linskey and Neelan Choksi sold Solarmetric (a JDO and JPA vendor) to BEA, open sourced their Kodo product as OpenJPA, and Neelan joined Interface21. (Spring again! OK, I promise to stop.)
Up the tiers a little bit to the presentation layer: in 2004 Struts had been the big daddy but everyone was suddenly realizing that it sucked had limitations. Back then the competitors to Struts were little frameworks like Webwork and Tapestry, and Sun was embarking on creating the mammoth JSF. At this year’s conference Struts is back as Struts 2 (which is Webwork under the hood, strangely) and JSF is a reminder that when you mix innovation and standards bodies the results are often standards that are unusable by humans but need another layer (such as Seam) to make them usable. (I’m an old CORBA guy so I’ve seen this movie before).
In 2004 the IDE wars were between Eclipse, Netbeans, and IntelliJ. Eclipse was open, and IntelliJ IDEA was the best IDE. Fast forward to 2007, and Eclipse has a ridiculously large and overwhelmingly pervasive ecosystem and has successfully become the Emacs of the 21 st century, while IntelliJ IDEA, the little engine that could, continues to be the best IDE. Sun continues to push Netbeans, and each version gets better and better, but no one seems to care.
Back then, less than five speakers had Macs. This year almost all the speakers had Macs, and most attendees seemed to think that Mac was the Java development platform of choice.
And lastly, in 2004 there was one session on Ajax (by Dion Almaer and Ben Galbraith). Ben and Dion went on to create Ajaxian.com (the most popular site for Ajax news, technology, and events) and The Ajax Experience, a successful bi-annual conference, while having other day jobs. In 2007, there was a panel and six sessions on Ajax. Yes, it was still TheServerSide Symposium, but people care about the user experience again.
Back to our regularly scheduled programming: it’s not just a framework anymore
The Spring phenomenon though, is too big to not end the article dwelling on it again. Spring will be integrated with OSGi during the remainder of 2007, Rod Johnson said in his talk on Spring 2.0. OSGi is a dynamic module system for Java, something that should have been part of Java from the beginning. Strangely, it is currently pervasive on the client side due to Eclipse (plugins), but not well known on the server side. The Spring-OSGi integration is likely to make it into OSGi standards. And as a testament to Spring’s decoupled pieces-parts architecture, Spring itself is available as OSGi bundles.
Longer term, the Spring Framework is turning into the Spring Portfolio. There are integrations with JCA, CICS, and IMS. There’s Spring Web Services, and Spring LDAP. Message-driven POJOs will become possible with Spring. Acegi, the leading enterprise-grade Java security framework, is becoming Spring Security. There’s Spring Web Flow, which is just what it sounds like, again with POJOs. The role of Spring in SOA is being standardized with efforts such as the Service Component Architecture (SCA). A Spring IDE (implemented as plugins for Eclipse) which will support Spring development, including support for AOP, and Spring Web Flow, is in the works.
Perhaps most important is the fact that Interface21 plans to bundle this large collection of little parts that make up the Spring platform or portfolio, and make them available as a single download …or distro. Not just parts all slapped together, but tested and integrated, with the right versions, known to work with each other. I believe this will clinch it. Enterprise Java will mean Spring.
Last but not least, next generation application servers from BEA, and maybe IBM, will be built on top of Spring. Am I the only one that finds this mind-blowing?
What clearly hadn’t changed was that TheServerSide Java Symposium was still the place to get the best pulse on the industry, and an intimate setting to interact with the people making things happen. Going forward, besides watching what happens with all of the above, I am most curious to see how Rails, Ruby, and JRuby affect the Java ecosystem, and whether Groovy and Grails, which has been written off by many in favor of RoR, will make a strong comeback with the major releases coming this fall.