How to find Ehcache and Terracotta Webinars and Presentations

After many requests we have extracted our talks out of the mess that is Webex and have started posting them to ScreenCast. From there you can easily watch them without any sign in rubbish or embed them. See

Introducing the Elephant Curve

While having a few drinks with some French-speaking colleagues at  Le Meridien hotel in San Francisco during JavaOne 2010 I realised that French speakers have a cool name for a load phenomenon of online systems

It is difficult to tune an online system for the average daily traffic volume because it varies a lot during the day. Specifically in my experience it is common to see demand rise in the morning to a midday peak then lull somewhat in the afternoon to be followed by a lower mid-evening peak. Things then quiten down. Now my experience is in travel systems. The explanation we had was that though some of the usage was business related, a lot was leisure. And users would tend to search and book travel at lunchtime and then after dinner.

It turns out that French speaking people have come across the same phenomenon but were clever enough to give it a name: The Elephant Curve. The reference is to Le Petit Prince, a best-selling children’s story from  1943 which has been published in 190 languages. In the book a boa constrictor swallows an elephant. The silhouette of the boa then becomes an elephant curve. Though I did not read the book at school it seems that many people have.

Here is the elephant curve illustration from the book

So I plan on calling the E-commerce daily double spike the elephant curve from now on like the Francophones do. I am going to add this as a slide in my talks and to my Caching Theory chapter on

Thanks to Ludovic Orban (Belgian) and Alex Snaps (German/Belgian) for appraising me of this.

Is it time to fork Java?

This year’s JavaOne was a dismal affair. Crammed into the Hilton hotel and Parc 55, the feeling was that Oracle had ruined the conference. And the dual conference idea also caused Java people problems: those that tried to attend the key note at Moscone with JavaOne passes were turned away – instead needing to go to the Hilton ballroom to see it televised.

Last year, Larry shocked many with a goof ball suggestion to port OpenOffice to JavaFX. This year attendees were shocked to hear of the cancellation of JavaFX. Those giving and attending sessions on the topic felt it was futile. I was never convinced that JavaFX would be able to get the sort of dominance required to make it work as a browser platform. But what of Java 7, something I am interested in? The beer talk I heard at the Thirsty Bear, was that the JCP has stalemated for the past year on Java 7 over Oracle wanting to add a “restricted field of use condition” to it restricting the OpenJDK to desktop and server, not mobile. One possibility is for Oracle to abandon the JCP and just release it. The other rumour floating around is that future free versions of the JDK will be reference implementations, with higher quality or more fully featured versions only available under commercial license.

All of this suggests to me that Java as we have known it is over. Should we wait for Java to lose momentum and popularity to other languages? Or should we as a community step up and go in a new direction. I prefer the latter. Following is a sketch of how this could be done.

What to call the fork

Java is famous for coffee but also for volcanoes. So let’s call the new fork Lava.

Lava Foundation

We don’t want one company to take over the fork. What would be best is if  a foundation, like the Linux Foundation, Mozilla Foundation, or Eclipse Foundation be formed. This group would be funded by corporations with deep enough pockets to make it work such as Google, IBM, HP and RedHat.

It would be a non-profit foundation.

It would  perform the following duties:

  • A code fork of OpenJDK, based on current trunk.
  • A new standards body to replace the JCP
  • Creation and maintenance of a Lava TCK, which implementations would test against.
  • A new annual conference, or a series of conferences.
  • Write Once, Run Anywhere

    So how would we maintain this guarantee? The Lava compiler and Virtual Machine would remain backwardly compatible with Java 6. That way the vast array of existing code would work. Then depending on IP restrictions, Lava versions could add support for new language features in later versions of Java. If IP restrictions would preclude that it stays with Java 6.

    The question then becomes whether developers would write to the new Java versions or to the evolving Lava. The answer likely would depend on market traction. In favour of Oracle is that it is the real Java. However  if you need to pay license fees to Oracle for the higher quality implementations you would likely want to run in production, then that would come at a cost. If enough commercial companies supported Lava so that it was very high quality, then developers would follow. And developers would want the open source version to win.

    I am interested in what the community thinks of this idea. Ping me at gluck AT


    October 7:

    Stefan Asemota created a Lava Foundation facebook page here.

    October 14:

    Well, some interesting developments have occurred in the last week. IBM and Oracle jointly announced that IBM was switching from project Harmony to OpenJDK and would:

    work with IBM and others to enhance and improve the JCP.

    What does this last one mean? Trink Guarino clarified this for me:

    This includes improving the collaboration with other standards bodies, increasing the participation in the JCP processes and expert groups as well as improving the efficiency of the specification process.

    A close reading of the various corporate blogs and press releases shows that the approach between the two companies was made after the reaction to this blog. So, here is hoping that IBM, by negotiating in it’s own interest, will also open things up for the community.

    Finally, what about the conference? Happily I was asked to give some feedback on JavaOne, which I did in great detail. Beyond that I am going to Devoxx 2010 and will be speaking there on “The essence of Caching”. With Google there, and hopefully the European non-attenders of JavaOne this year, it should be a bumper conference and may well be the largest Java conference this year.

    Maven Rant: Backward incompatibility and Software anti-distribution

    Today I was upgrading Ehcache’s JGroups replication module to apply a patch. I needed to upgrade JGroups. Fine. I went into IntelliJ and updated my Maven repository indexes as they were a little stale, then clicked on the version number and used auto-complete to find the new versions. I found 2.7. That did not compile with the patch. I went back to the submitter. He then informed me that JBoss had changed their repo.
    I had:

    After hunting around I had to change it to:

    It would have been nice if the old name could have been mapped to the new location.

    I thought I was done. But no, in the meantime JGroups decided to become more correct and go to a package name. Now, Ehcache did this about three years ago. So the old and new are as follows:

    This whole thing was a hassle. Played out over the entire development community it turns into a lot of wasted productivity. To me each of these changes is no different to people changing interfaces in code. You have to change to rebuild. As it happens, later on I found out JGroups also did that with getLocalAddress, which is no longer castable to IPAddress. 🙁
    This is a pet hate of mine. Why create work for your users? I always strenuously try to avoid these changes.
    As to Maven I have been observing a trend where much of what you need is no longer in the central repository. It is now mainly a federated system. The central repo is therefore kind of dead.
    This is now getting to be not much better than the old days of having to go hunting for software on a multitude of websites. But now it is even worse than that. You also have to then search on those web sites for their Maven repository, which is often buried somewhere, and then their maven coordinates for the artifact you want. I think this is turning into a software anti-distribution system. And then back to the beginning of this post – having done all that you can expect to do the same each time you want to upgrade, because of a lack of regard for backward compatibility.

    Debugging Ext JS in IntelliJ 9.0.2 (Maia IU.92.273)

    I am working on Ehcache Monitor right now, which uses Ext JS. IntelliJ gives you the ability to debug both Java and JavaScript, which is really nice.

    Local Debugging

    To debug in IntelliJ you right click on a .html file and select Debug.

    Remote Debugging

    Set up a JavaScript Debug Remote configuration. See below for an example.

    Make sure Firefox is closed and any previous debug session is closed.

    Then Debug the Javascript Debug Remote config.

    Getting it to Work

    We had a bit of pain getting this working.

    Mac OS X Version


    IntelliJ Versions

    I tested 9.0, 9.0.1 but couldn’t get it to work. It is known to work with Maia IU.92.273 which will become 9.0.2. It will install a FireFox plugin called JetBrains Firefox Extension. The version should be 0.2.5. 9 and 9.1 shipped with a 0.1 version of this plugin.

    I am using Java 1.6_17.

    Firefox Bug

    Firefox gives an error mentiowith sqlite3 when using the HTML and JavaScript debugger.

    This is caused by a bug in Firefox 3.5.7 and a few versions back. This problem has been reported on SnowLeopard.

    Dyld Error Message:
    Library not loaded: /usr/lib/libsqlite3.dylib
    Referenced from: /System/Library/Frameworks/Security.framework/Versions/A/Security
    Reason: Incompatible library version: Security requires version 9.0.0 or later, but libsqlite3.dylib provides version 1.0.0

    Dyld Error Message:  Library not loaded: /usr/lib/libsqlite3.dylib  Referenced from: /System/Library/Frameworks/Security.framework/Versions/A/Security  Reason: Incompatible library version: Security requires version 9.0.0 or later, but libsqlite3.dylib provides version 1.0.0

    This is a known issue in Firefox. See

    The workaround is to change the Browser config to use firefox-bin rather than firefox. See below.

    Ehcache welcomes Grails as a first-class supported framework

    The Ehcache project is happy to welcome Grails to the fold. The new Grails 1.2RC1 uses Ehcache as the default Hibernate second level cache. We worked with the Grails community to test Ehcache with Grails to ensure a good developer experience. As part of that we have added a new Grails Chapter to the Ehcache documentation on how to configure Ehcache for Grails, including production tuning.

    We plan further enhancements to Ehcache to roll in the Terracotta Hibernate provider so that Grails users can experience the Terracotta Scale Continuum by simply making config changes in ehcache.xml.

    Note that earlier versions of Grails also ship with the Ehcache library and it very quick and easy to configure it. See the documentation.

    What is d7073c02eca990a65c2c4c911fe33b20?

    As many of you have guessed d7073c02eca990a65c2c4c911fe33b20 is an MD5 hash. It is actually a hash of a zip archive of documentation for the acquisition by Terracotta Inc. of Ehcache. Adding an MD5 hash into a contract caused the lawyers some angst. They hadn’t seen it before and were naturally reluctant to include it.

    The MD5 went through multiple revisions but the final hash is the one I blogged and tweeted. My new colleagues at Terracotta got in on the fun and also started blogging and twittering. We then watched the fun unfold on the blogosphere and twittersphere as people searched for what is obviously a unique string and looked for the patterns.

    The prize goes to Matt Raible for getting closest to the correct answer.

    What is Happening

    Terracotta Inc. is acquiring Ehcache. On one side we have a late stage startup and on the other an open source project. So what does that mean? It means the copyright notices in Ehcache source code change to Terracotta Inc, I join Terracotta, and we get on it. The status of the many contributors to Ehcache who have licensed their code to the Ehcache project remains unchanged.

    Why is it Happening?

    The timing of this is perfect for both Ehcache and Terracotta. Reflecting on it with Amit Pandey, CEO and Ari Zilka, CTO of Terracotta Inc, we realised that this would not have happened a year ago and may not have happened a year from now. Ehcache and Terracotta have been cooperating for the last two years since I agreed with them at JavaOne 2007 to do an integration. To me distributed caching was a hard problem and I have invited all comers to solve it. We now have four mechanisms: RMI, JGroups, JMS and Terracotta. The Terracotta integration provides coherence, massive scale and visibility. The integration has been so successul that fully 50% of Terracotta’s customers use Terracotta via Ehcache. This presented both an opportunity and a challenge for Terracotta. Fortunately for the Ehcache community, Terracotta have taken the opportunity to acquire Ehcache.

    What about open source

    Ehcache is a project committed to open source goals. Bottom up construction with the community driving innovation. As anyone who has submitted a bug report or patch to Ehcache knows, I seriously consider every contribution and incorporate most of them – all with a maniacal attention to detail and quality. Ehcache has always followed the benevolent dictator open source model. Commit access is closely guarded but contributions are welcome.

    What stands behind my approach to Ehcache and other open source projects I maintain is my open source philosophy: “Simply and naively, why not make the world a better place?”. It is entirely possible to do well and help others at the same time.

    News flash: Terracotta is also an open source company. The difference is they have a business model.

    I also think there is a consolidation going on in distributed caching. Ehcache has been on the winning end of that, and now with Terracotta’s help, we will jointly strive to continue that past success.

    What this means for Ehcache Users

    1. Ehcache remains under the Apache 2 license
    2. New feature development is accelerated with the addition of a team of engineers working full-time on Ehcache
    3. I am full-time on Ehcache. I have not had the time I would have liked to devote to Ehcache (I have been doing a miserly 10-15 hours per week for the past 6 years) but now I do. Look out!
    4. Ehcache extends its standards support. There are multiple emerging standards in this area and I plan to work with the community to lead further standardisation efforts. A lack of time has been my biggest obstacle in doing more on this to date.
    5. Ehcache gets new hosting at with
      state-of-the-art forums, source control and bug reporting. The changes will happen slowly and carefully.

    6. File release at is retained
    7. Maven deployment to and Maven Central is retained.
    8. Distributed caching via Terracotta is seamless. Ehcache users can have full confidence that they can start single node and scale as high as they need to with Enterprise features.
    9. Enterprise support, training and professional services for Ehcache. I have provided these for a few years now, but now we will have the full Terracotta organisation behind them with the usual SLAs.

    What this means for Terracotta Users

    1. Ehcache APIs will replace Terracotta distributed cache APIs as a single caching interface / standard for Terracotta distributed caching
    2. a single-node version of Terracotta ala Ehcache will be available for the first time
    3. Full freedom to run on the latest version of Ehcache at all times, knowing it will work with Terracotta
    4. Single vendor support structure for caching interfaces / libraries as well as their scalability / reliability runtime.
    5. the investment protection of standards


    See Terracotta’s news announcement for more detail.

    Terracotta founder and CTO Ari Zilka has a blog post on the acquisition. He explains the same material from a Terracotta viewpoint and gives insight into the product roadmap.

    At last, the important stuff

    The Terracotta – Ehcache blend is a natural one that works. What has really been occupying my attention the last week is deciding pronunciation issues. Anyone who has attended my JavaOne sessions knows that I pronounce Ehcache as “ee h kay sh“. Alternative pronunciations in use are “eh cash” (USA) and “eh kay sh” (Canada and Atlassian). Given that Ehcache is going to be around for a long while and I am the founder let me state that the official pronunciation is “ee h kay sh“. Now let’s get on with it.