Stefane Fermigier

Posts for category: Java

Java, OSS and innovation

| Comments

“Cristiano”, from Faqs.it, has written a comment about our switch from Python to Java in his blog.

Here is my comment about his comment.

Hi Cristiano,

Thanks for your comments about our Java switch. I fully agree with you that a lot of innovations come from the OSS ecosystem, but there are some wrong facts in your remarks that I have to correct, including the following:

  • Python, for instance, did actually copy Java’s syntax (and concept) for annotation (called decorators in Python-speak), not the other way around.

  • Generics are irrelevant in dynamics languages, hence dynamic languages can’t have “out-innovated” Java on that matter.

  • The sentence “Python doesn’t fit in the enterprise-class web apps market” is in part irrelevant for us, because we are not only in the web apps market, but also in the rich client market (with Eclipse RCP).

  • Your opposition (in the last sentence) of “Java vs. OSS” is completely disconnected from the reality: Java is GPL now (or will be RSN), Java OSS communities (JBoss, Spring, Apache, Eclipse, Nuxeo…) are among the most active (if not the most active) OSS communities now. And some of these communities have a lot of money at their disposal, because these are projects for building enterprise-class OSS software (or middleware), backed by serious companies like Sun, IBM, Red Hat, or Nuxeo.

IMHO, OSS is now driving, in many ways, the development of Java, and this means that there is no need to oppose Java if you are (like I am) an OSS believer.

Seam 1.1 almost there + insightful interview on InfoQ

| Comments

As everyone should know now, Seam is an important part of our Nuxeo 5 ECM stack.

We are currently using Seam 1.0.1, but it is nice to learn that Seam 1.1 is coming along, and it’s going to be very good.

There is a very nice (like always, on InfoQ) interview of Gavin King, Seam’s creator, that explains in details where Seam is headed (rest assured that Nuxeo 5.1 will include Seam 1.1, but let’s focus on the Nuxeo 5.0 release now ;) ).

Seam 1.1 beta1 released

| Comments

Gavin King has released last week the first beta of JBoss Seam 1.1, but hasn’t made any spectacular announcement for it, besides a post in the JBoss Seam forum.

According to his release notes, the major new features of Seam 1.1 are:

  • The Seam Application Framework for data-oriented applications
  • Asynchronous methods and events
  • Integration of Ajax4JSF for partial page refresh
  • New concurrency model for Ajax-based applications
  • Efficient clustering of Seam-managed extended persistence contexts and JavaBean components
  • Support for atomic conversations
  • Enhanced configuration via components.xml
  • Exception handling via annotations or exceptions.xml
  • Page parameters for RESTful applications
  • Page fragment caching via <s:cache/>
  • “Decoration” of invalid input via <s:decorate/>
  • Themes
  • Support for the Sun JSF 1.2 reference implementation

Michael Yuan, author of the upcoming Prentice Hall Seam Book, also has some comments on the new features.

As developers of the Nuxeo 5 open source ECM platform, which relies heavily on Seam for its web presentation layer, we are both excited by this new release, and curious about other projects (open source or not) that are using the Seam framework.

What a month! (Quick reflections two weeks after our Java switch)

| Comments

We announced our switch to Java two weeks ago. There was of course a lot of preparation before the announcement (besides just coding). That included: creating the new Nuxeo.org website, writing a FAQ, preparing slides, writing announcements for various media (InfoQ, TSS,…), and anticipating some discontent in the Zope community.

Well, two week after going public with the announcement, I’m glad to say that we are completely pleased with the way things went.

We already have released one of the key components of the platform, Nuxeo Runtime and are preparing to release Nuxeo Core this week. Overall, work on the project is going on at a steady pace and we are on track to meet the next milestones of our roadmap.

Our announcement got noticed both by the main Java sites, and countless blogs (including some in languages that we don’t understand without Google Translator).

There has been a little discontent, as expected, in the Zope community, but we mostly got some nice messages of people saying they understood our choice. The most heated discussions took place after Jean-Marc’s post (and its followups) supporting our change.

And, most importantly, we got many subscriptions to the mailing list, which shows there is a real interest in the developer community.

On the business side, we’ve had many calls from system integrators.

I’m especially glad to notice that in two weeks, we got contacts from several new systems integrators, telling us that, now we are using Java, they will be very happy to work with us on new projects. Consequence: we now have a commercial contact with 8 of the 10 leaders of ECM integration in France (some of them the french subsidies of international groups), as well as interesting partnership projects with a big name (I mean BIIIIG) software vendor (more on this another day).

JSR 170 (Java Content Repository) and Zope 3 ECM

| Comments

I'm at the Z3ECM sprint in EuroPython 2005 and I've spent yesterday trying to play with the JCR (Java Content Repository aka JSR-170) trying to understand

  1. how easy it would be to how a Zope content management system into a JCR (short answer: not easy - despite of claims of interoperability, JCR is a 100% Java technology).
  2. if there are useful ideas in the JCR that could be put into the design of the repository for Z3ECM (short answer: probably, yes)

Hooking Zope into a JCR

After installing Jackrabbit (an open source implementation of the JCR made by the Apache project) and testing it with some Java examples, I've trying calling it from Python using the JPype Java<->Python bridge.

Installing Jackrabbit is not that hard, it took me about one hour though since I haven't done any Java development since 1996 and didn't have all the right tools (including Maven and a dozen of libraries like xalan, xerces, log4j, etc.) from the Apache Java project installed. Not a big deal anyway.

Unfortunately, JPype is pretty much a work in progress, that would benefit from more users and developers. There are, seemingly, limitations that prevented me from login in the JCR so this experiment didn't succeed and my knowledge of Java is much to light to keep on the experiment.

If we succeed in hooking Python/Zope into a JCR (which is, overall, just a question of Java/JNI knowledge and grunt work), I think the most important question is how the to make Zope and Java transactions systems work well together (transactions are an optional JSR-170 feature, but I don't see how a repository without transactions would be useful at all).

Ideas from the JCR specs

A JCR is a repository of nodes stored in whatever you want (flat files, SQL DB, object DB, XML DB...). Nodes are just collections of properties, so it's a very data-centric model that doesn't impose a programming model, and would work very well outside of Java. In practice, Nodes are the documents you're managing with you application. Nodes can be accessed from a path (hierarchical navigation, something Zope developers are very familiar with), or by UUID (unique identifiers). More interesting are:

  1. Querying nodes, which is based on a simplified XPath query language, or, optionally, a variant of SQL
  2. XML import/export, which would provide interoperability between repositories at list in the sense that you can import data from one repository to another (no vendor lock-in)
  3. Versionning
  4. Events

Overall, nothing very different from what we are already doing with the CPS Repository (from CPSCore), but it's interesting to try to dig a bit further in the specs and to keep then in our minds when designing the Z3ECM model for the repository, querying, and versionning.

Related standards

The WebDAV/DeltaV standard for versionning and its JCP interpretation (JSR-147) are related to these specifications.