gpoul's Out Of Memory Blog

On Monday we announced that IBM will join the OpenJDK project. If you’re interested in why this decision was taken and what this means, you definitely want to read Bob Sutor’s blog post on this change in direction.

One major part is the decision that “IBM will be shifting its development effort from the Apache Project Harmony to OpenJDK” and that there will be changes to the JCP “to make it more democratic, transparent, and open”, although it seems to be unclear what concrete steps will be taken.

Henrik Ståhl posted a few details about Oracle’s future plans on his blog, but apart from the fact that we’ll finally see a Java SE 7 and Java SE 8 JSR, there is not too much of substance to report. We’ll see whether that gets more concrete over the coming months.

It turns out that the JDK 7 development project is delayed quite a bit and the current estimated ship date is now Mid 2012. Given this delay Mark Reinhold is currently looking for feedback on a proposed Plan B, which would only include certain parts of Coin, NIO.2, InvokeDynamic (JSR 292), and “JSR 166y” (fork/join, etc.) in JDK 7 and delay everything else until JDK 8.

The estimated ship date for this Plan B would be Mid 2011 with JDK 8 being delayed an additional 6 months with a ship date in Late 2012.

I’m not a huge fan of releasing two major JDK releases within two years when the most current release is already almost 4 years old, but it seems like that’s what Oracle is currently leaning towards.

Comments on this post are closed, please post your feedback directly on Mark’s blog.

Update 9/21: Plan B is now the plan of record.

The WebSphere Application Server V8.0 Beta is now available.

Update 7/9: Andrew posted that the download is now fixed and he also included some helpful links to get started with trying the beta.

Every wanted to script Google services? Then you’ll have a lot of fun with GoogleCL, a Google command line tool based on the GData APIs.

Poul-Henning Kamp in acmqueue:

On a modern multi-issue CPU, running at some gigahertz clock frequency, the worst-case loss is almost 10 million instructions per VM page fault. If you are running with a rotating disk, the number is more like 100 million instructions.

What good is an O(log2(n)) algorithm if those operations cause page faults and slow disk operations? For most relevant datasets an O(n) or even an O(n^2) algorithm, which avoids page faults, will run circles around it.

Besides being an interesting article, this is the first time I read about Varnish. I know lighttpd, but haven’t heard about Varnish before . Anyone ran into that before? Maybe even used it?

You learn something new every day. Looks like Lombardi uses GWT for Blueprint and the web portions (i.e. everything that’s not Eclipse-based) of Teamworks. There is a video on the GoogleDevelopers channel where Alex Moffat showcases Blueprint and describes why they chose GWT.

In addition they’ve also been demoing their solution as part of the Google I/O 2010 Sandbox this week.

btw: Lombardi is an IBM company.

Google announced the Google Chrome Web Store last week. I wonder how they came up with that idea. I’m sure in some meeting the idea made perfect sense. In the real world? Not so much.

At Google I/O one of the minor announcements was a cloud based storage offering called Google Storage for Developers.

The product is still in beta and developers can currently sign up to be placed on a waitlist. Given this has been released more than two years after Amazon S3 I would’ve expected that it would not be limited to US developers and US data centers. In comparison to Amazon S3 it is also missing CDN integration, which I think would be very interesting for many, no matter if they also use AppEngine or not.

This was announced hours after Amazon S3 continued to innovate; announcing their Amazon S3 Reduced Redundancy Storage.

Amazon this week announced a new cheaper storage option that has reduced guarantees for the durability of stored objects. Amazon calls this Reduced Redundancy Storage.

It’s 99.99% durable instead of 99.999999999% durable per storage object.

Interesting that they not only measure availability, but also durability of data. I’ve never seen that before. Not that I think the numbers are based on reality at all, but it kind of makes me nervous about how durable the storage of my bank’s data-center is ;-)

I already blogged about open source versioning some time ago and what happens when you introduce multiple dependencies into your projects. More recently Bob Sutor discussed the issue of what happens when you use highly customized open source code. But how do you get your patches back into the upstream project so you don’t need to port all your customizations forward into new versions as they’re released, which can cause huge costs each time you have to integrate?

The decision seems to be easy. You needed a legal review to use open source in your commercial project anyway, so you get another approval to contribute your changes back. But what happens when the patch is not accepted or acceptance is dragged out for months? Open source projects usually don’t line up with your project schedule.

You’ll have to perform change integration anyways until the patch has been accepted upstream, but what will you do when the change is not accepted and you need to rework your patch for it to be accepted? Who’s going to pay for the costs associated with these changes? Who’s going to make sure that these changes are integrated into the software you developed based on the open source project and regression tested to make sure it performs as well as the old code?

I have a few ideas to address this type of situation, but their applicability varies depending on the project and what kind of open source project you might be using:

• The faithful approach: Don’t change the open source code and report issues to the bug tracker of the project and hope they’ll be fixed in a few days, months, or years.
• The painful approach: Plan for these continuous integrations and code rework and make them part of your schedule. It’s not easy to know how much cost will be associated with this and it’s probably not trivial to argue about them with a PM who wants to keep costs predictable, but that’s what “usually” happens when you change code that is owned and maintained by someone else.
• The commercial approach: Purchase a support contract for the open source code from someone who has project members with commit access on staff and have them fix the problem and integrate it upstream.
• The strategic approach: Have someone on staff who is a project member with commit access.

Did I miss any good ideas? Please feel free to share how you solve this problem in your organization!