SpringSource's strategy

It has been interesting to follow the recent communications made by Rod Johnson as you can transparently read SpringSource's strategy. I wanted to blog about it during the last vacations but never fully finished the entry (they were vacations after all). Some elements are outdated now (including SpringSource acquiring covalent) but here it goes just refreshed with links.

Rod Johnson has been quite aggressive against JBoss AS in the last few weeks. It did not really bother me per se but the move is interesting. While it is well known that some JBoss folks and some Interface21 folks has been having tensions in the past, it came to a surprise that Rod joins the arena. Since Rod does not attack people for emotional reasons contrary to other folks, let's try a guess what's going on.

Interface21 (now SpringSource) received VC funding last year. Don't be naive, VC do transform a company, they are seeking for quick returns on their investment. Interface21 was mainly a consulting oriented company (in term of business) around the Spring portfolio. While this is a very steady and nobel business, it cannot provide the ROI VC people want to get: SpringSource's strategy had to be adjusted, the most obvious, safe and well defined solution is to follow the JBoss Inc model: go for the support money.

Well, to sell support, you need runtime. Unfortunately for SpringSource, Spring as a framework is not appealing enough for customers to jump into the support model. I think SpringSource did some interesting partnership / support deals with the folks at IBM, BEA and possibly Oracle (something JBoss never really did well because of the direct competition), but the only reasonable way to scale up the business is to have and support your own runtime. By the way, you can see the partnership going on in Rod's blogs, his tone is very sympathetic to IBM, BEA and Sun (I will come back to Sun later on). Generally speaking, the broader your platform is, the more likely you will be able to sell support. So SpringSource needs a platform to "sell and support".

Writing your own proprietary set of platform API is not so much in the air (to unquote Steve Jobs). That's why SpringSource joined the JCP and started to bless Sun and the Java EE 6 efforts, especially the profile effort. They need a mini-EE they can reach implementation-wise. If I were SpringSource, I would then try and get the smallest web-ish profile as possible out of the Java EE expert group, implement it and then raise the Java EE compliant flag to sell supports.

Side note on profiles. While everybody agrees Java EE needs some profile, I am sure nobody agrees on what to put in which profile: every application has different needs. What people really need is an ability to deploy and buy infrastructure components a la carte (whether it be one vendor or several) with the warranty of well defined API / SPI so that the whole platform keep a coherent vision freeing the customer from any integration work (component integration or programmatic model integration). Nothing a rigid profiling set can do. But that is a hard job.

Back to the main story. Even with the smallest possible Java EE profile, SpringSource is lacking some important pieces, the first one being the servlet container. And here comes the reason why Rod has been trying to not so subtly sent the message that JBoss AS is crap (I summarize here) and Tomcat is great. The only obvious choice for SpringSource is Tomcat. They need to enter the platform/runtime by the low end and gain market share (as in support market share). I would not be surprised if SpringSource announce a fully supported platform effort based on Tomcat and Spring at it's core. Of course, they need to hire some of the key contributors of Tomcat to gain some credibility. Let's imagine this done, the first competition they think they will face is JBoss AS, so seeing Rod poopooing on JBoss AS and EJB 3 is not a surprise. The first competition they will face though is people that do not want support for Tomcat: JBoss has been offering Tomcat support for a long time but not surprisingly monetizing Tomcat never succeeded. Most applications deployed on Tomcat do not want need (of course exceptions apply). Maybe Tomcat + Spring will be the silver bullet but I seriously doubt it for a bunch of reasons. The second biggest competition will probably be their own ecosystem. When you start to compete with them, your partners tend to be pissed, that's life. Ask Larry about that.

By the way, Rod does not seem to know that JBoss uses an enhanced version of Tomcat as a web container named JBoss Web. Remy (Tomcat) and Mladen (Apache httpd) sat down and wrote a native integration between Tomcat and APR to make this server the best of both Tomcat and Apache httpd. Maybe he wants to check it out and fork it :) Oh, one more thing, anybody that has been charged by an elephant tend to smile at the cat vs elephant analogy.

Tomcat + Spring will still be a weak platform, SpringSource will have to beef it up with some additional components:
- a persistence framework (and no Spring is not a persistence framework :) )
- a transaction manager
- a messaging system
- maybe some webservices thingy stuffs

and a few more components. They probably will also have to announce a developer tooling strategy around that.
I will only comment on the persistence piece of their platform as I know the field quite well. They can technically chose between Hibernate, OpenJPA, and Toplink. Hibernate would be the smartest move for them and the most aligned with their customer base but this probably will be a tough call for Rod. The two alternative strategie are Toplink (aka EclipseLink) and OpenJPA. If I were them, I guess I would go for OpenJPA as a second choice but they will have to invest R&D in the pieces that differenciate OpenJPA from Kodo.

Rod, please be more open with your strategy. I always liked Marc Fleury's own way to tell everyone what strategy he was following and what will be the next moves. To everyone, including the competition :)

Good luck anyway, I am eager to have competition in this field as I think JBoss AS, Seam, Web Beans and the technologies around them (JPA, EJB 3, JSF and so on) are more appealing to the next leap forward.

Usual disclamer, this represents my own thoughts not necessarily my current, past, future, potential employer, etc etc.

Paris JUG

For the fellows based in Paris or nearby, a new Java User Group has been formed. I expect lots of good content from this user group thanks to some cross-pollination with the OSSGTP group and the industry knowledge of the two founders.
The first meeting is planned for February 12th, check out the announcement here.

Candid 10,000 feet thoughts about Android

Android is the new mobile platform developed by Google. They released the SDK yesterday. Basically a Linux kernel, a mobile optimized virtual machine running Java, and a set of API to play with the phone.

First of all, the usual disclaimer. I am not a mobile developer, I am not much of a UI developer, but I am a Java developer and mobile consumer. Anyway, I'll give you some of my thoughts.

Android is yet another platform. We already had Symbian, Palm OS, Windows Mobile, Java ME, Mac OS X, you name it. So yet another platform to support when writing a mobile app, year!

Sounds pretty bad for Sun and Java ME. I don't know the specific deal that Sun did with Google for embedding the Java technology into Android but I hope it's a good one for Sun because Java ME will suffer from the Android platform:

• it's "Java" enough for people to think twice before writing a Java ME app
• it's not Java ME, it's not Java SE, it's a subset of Java SE, so practically a different platform to target
• it's not a Java VM, so no need to pay any IP-related royalties to Sun
  
• it's not the Sun's Java ME virtual machine, so no need to pay Sun some license fee

Last grief. From the live demo you can watch on Youtube (especially minute 3:32), they have a long way to go before having a UI as responsive as the iPhone at least in the screen touch area. Plus they probably don't have multi touch events yet ;p

That being said, it seems to be a smart move from Google in three ways:

• it's a free platform for any mobile constructor (quite appealing)
  
• the notion of intent allows the user to replace one application with another in a very sleek way (sort of the loose coupling dream made true), making Android potentially an open platform even for the user
  
• they leverage all the Java developer base
  

Plus you can define your UI declaratively (XML), that's a smart move too.

So Android is a very open platform, but don't forget one thing: it's so open that your phone carrier can lock it down as much as it wants :)

As an iPhone user, I'm relieved a bit, my investment is worthwhile.

Welcome to G2One

Yesterday was the official public birth of G2One, a new company dedicated to Groovy and Grails training, consulting and support. I am happy to see Guillaume (Groovy lead) and Graeme (Grails lead) jumping into the Professional OpenSource bandwagon. Good luck to you guys, it is as stressful as exciting :)

Speaking of it, I will be speaking Wednesday 17th to the Grails eXchange.

One talk about Hibernate in general and what is cooking up for the next releases and another one about Hibernate Search (hopefully I will get my demo ported on Grails :) )

Release Candidate for Hibernate Search 3.0.0

Release Candidate for Hibernate Search 3.0.0

Hibernate Search 3.0.0.CR1 is now out. This release is mainly the last bits of new features and polishing before the final version. The next cycle will be dedicated to bug fixes (of any bug that pops up), as well as test suite and documentation improvements.

Thanks to Hardy for the new getting started section (this should ease the path for newcomers), and to John for hammering the last features we wanted in the GA version.

The next version should be the GA release unless some complex bugs are discovered.

Check the changelogs for a detailed change list.

Podcast about Hibernate Shards

Max Ross and Maulik Shah from the Hibernate Shards team at Google got interviewed by the Google Developer Podcast.
It's a nice and easy access 30 mins introduction of Hibernate Shards: how does it work, where does it come from, what are Hibernate Shards do's and don'ts, what's the secret plan to take over the world... Insightful. One of the cool stuffs they added in the latest beta is support for Hibernate Annotations.
If you want to know what shards is all about or if your DB starts to feel the heat, go get your headset.

Innovation in the Log space, yawn...

Steve and I had a discussion yesterday about loggers. I know what you're thinking: hasn't log been a solved problem for years now? Plus it's boring ;)
That's why usually, when a discussion starts on the subject, I tend to carefully not listen. But because it's Steve, and because he has some specific requirement for the next Hibernate Core version, I decided to ignore my own rule.

It turned out to be much more interesting than what I expected. Here are some news for people, like me, that stopped listening to the log crowd when the rule was use log4j and when you can't use commons-logging.

I was pleasantly surprised by slf4j. I know, it's yet another facade and the name is awful. But this project has 2 features that really caught my attention.

Parameterized log
Isn't it very annoying to have to do

if ( log.isDebugEnabled() ) {
    log.debug("My dummy " + object1 + " and expensive " + object2  + " concatenation");
}

because the object's toString() method are expensive?

slf4j solves that by using parameterized logs

log.debug("My dummy {} and expensive {} concatenation", object1, object2);

Very elegant and just as efficient as the previous form. Now because slf4j supports JDK 1.3, the API cannot use varargs, which means that for 3 or more parameters you will have to write

log.debug("My dummy {} and expensive {} concatenation {}", new Object[] { object1, object2, object 3 });

instead of the much more elegant

log.debug("My dummy {} and expensive {} concatenation {}", object1, object2, object3);

Damn slow movers! I guess most of the time you have 1 or 2 arguments so the pain should be minimal, or you could write you own facade, sigh

Static binding

Once I understood what it meant, I liked it. Basically to switch from one underlying logger to another, you will replace slf4j-mylogger1.jar by slf4j-mylogger2.jar: the slf4j engine is statically bound to an implementation.
OMG! This means I cannot change my logger implementation by hot deploying a config file! Oh, wait a minute, it's useless anyway.
The good side is that classloader hells are behind us.

The Ultimate Uber Cool solution

The ultimate solution is actually what Gavin came up with in Seam. So instead of doing

private static final Log log = LogFactory.getLog(CreateOrderAction.class);
       
public Order createOrder(User user, Product product, int quantity) {
    if ( log.isDebugEnabled() ) {
        log.debug("Creating new order for user: " + user.username() +
            " product: " + product.name()
            + " quantity: " + quantity);
    }
    return new Order(user, product, quantity);
}

you end up with

@Logger private Log log;
       
public Order createOrder(User user, Product product, int quantity) {
    log.debug("Creating new order for user: #{user.username} product: #{product.name} quantity: #0", quantity);
    return new Order(user, product, quantity);
}

Notice the parameterized logs, the log injection (yes the framework is smart enough to guess the category, doh!), and the contextual parameters injection.

But such solution is not accessible to library developers until someone decides to push that into the JDK.
OK I'm done for logs for another 5 years time :)