Philly's search

I will be at the Philadelphia's Emerging Technologies for the Enterprise conference speaking about Hibernate Search on March 27th (Thursday).
The conference has some interesting talks around the new wave of development frameworks (Seam, Rails and so on). There is even a Battle of the frameworks! a Rountable Debate which sounds very promising. I will definitely try to sneak into it ;)
Come by and say hi. If people are interested we could have a chat about the future of Hibernate Search as we are shaping it as we speak (or you can show up on the hibernate dev list if you don't like Philly ;) ).

Hibernate Annotations and EntityManager fix-athlon

Hibernate Annotations 3.3.1.CR1 and Hibernate EntityManager 3.3.2.CR1 are available for download here. I have done a fix-athlon in the last few days to ready them for JBoss AS 5.
There is a ton of bug fixes especially in the Java Persistence scanning area and in edge mapping supports.
Some minor new features have been added as well (transparent integration with the latest Hibernate Search collection events, @Any, @NaturalId).

Check the changelogs here and here.

Unless huge bugs are discovered, these versions will be embedded in the next JBoss AS 5 release.

Go try them.

Lucene users (2.3): migrate to Lucene 2.3.1

In some specific cases, Lucene 2.3.0 can corrupt your index. It happens in very specific cases:

• you use autoCommit=false on IndexWriter
  
• or multiple threads are adding documents where some have term-vector enabled fields and some don't

These particular situations do not occur in the regular use of Hibernate Search, but upgrading to Lucene 2.3.1 works fine, so go upgrade, you won't be bitten later. Native Lucene users should upgrade as well.

Here is the official Lucene team announcement

Lucene Java 2.3.1 available

This release contains fixes for serious bugs in 2.3.0 that could cause index corruptions in autoCommit=false mode or in cases where multiple threads are adding documents where some have term-vector enabled fields and some don't. The autoCommit option was added to IndexWriter with release 2.2.0. If not explicitly set to false, the IndexWriter runs in autoCommit=true mode.

See CHANGES.txt for a detailed listing of changes.

2.3.1 does not contain any new features, API or file format changes, which makes it fully compatible to 2.3.0.

We would like to encourage everyone who is currently using Lucene Java 2.3.0 to upgrade to 2.3.1 to prevent possible index corruptions!

Lucene is available at apache.org.

Hibernate Search in Action book

I am very please to announce that a book on Hibernate Search is on its way. John Griffin and I are co-authoring Hibernate Search in Action from Manning.

The goal of this book is to give a good practical understanding of Hibernate Search and guide people through the steps of adding full text search capability into their Hibernate based application. The book also covers the necessary Lucene knowledge you need to use Hibernate Search on a daily basis.

An early version of the book is already available through the MEAP program. Five chapters are already out there. If you are interested, give it a try, we welcome your feedback!

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.