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 http://www.screencast.com/users/Terracotta
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 ehcache.org.
Thanks to Ludovic Orban (Belgian) and Alex Snaps (German/Belgian) for appraising me of this.
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.
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:
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 gregluck.com.
Stefan Asemota created a Lava Foundation facebook page here.
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.
After hunting around I had to change it to:
<div id="_mcePaste"> <id>jboss.releases</id></div>
<div id="_mcePaste"> <name>JBoss Releases</name></div>
<div id="_mcePaste"> <url>https://repository.jboss.org/nexus/content/repositories/releases/</url></div>
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:
To debug in IntelliJ you right click on a .html file and select Debug.
Make sure Firefox is closed and any previous debug session is closed.
Getting it to Work
We had a bit of pain getting this working.
Mac OS X Version
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.
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
This is a known issue in Firefox. See https://bugzilla.mozilla.org/show_bug.cgi?id=513747
The workaround is to change the Browser config to use firefox-bin rather than firefox. See below.
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.
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
- Ehcache remains under the Apache 2 license
- New feature development is accelerated with the addition of a team of engineers working full-time on Ehcache
- 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!
- 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.
- Ehcache gets new hosting at ehcache.org with
state-of-the-art forums, source control and bug reporting. The changes will happen slowly and carefully.
- File release at sourceforge.net is retained
- Maven deployment to oss.sonatype.org and Maven Central is retained.
- 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.
- 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
- Ehcache APIs will replace Terracotta distributed cache APIs as a single caching interface / standard for Terracotta distributed caching
- a single-node version of Terracotta ala Ehcache will be available for the first time
- Full freedom to run on the latest version of Ehcache at all times, knowing it will work with Terracotta
- Single vendor support structure for caching interfaces / libraries as well as their scalability / reliability runtime.
- 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.
I just published an article on The Role of Caching in Large Scale Architecture on DZone.