Showing posts with label openjdk. Show all posts
Showing posts with label openjdk. Show all posts

Saturday, 10 September 2011

The OpenJDK as the default Java on Linux

Hi All,  (this post is x-posted to the java7developer blog and the ljc blog)

Recently I've received a bunch of private correspondence from people confused/worried over the change in the default Java packaging for Linux. For many Linux distributions, the official Sun/Oracle version of Java has been packaged up as the default Java for the platform. However, due to a recent licensing change, this will no longer be the case! So, is this a positive or a negative thing for the Java and open source ecosystem? Read on for my take on it :-)


Dalibor Topic announced that With Java SE 7 and JDK 7 being released, and with OpenJDK as the official Java SE 7 reference implementation, that it was finally time to retire the non open source "Operating System Distributor License for Java" (DLJ).

What does it mean for me?

The knock on effect of this is that Linux distributions will on longer package Oracle's Java (== OpenJDK wrapped up in some proprietary bits and pieces) as the default Java. This can/will cause problems for some Java users initially as there are a smattering of bugs (especially in the Swing UI libs) still left in the OpenJDK that affect programs like PCGen. However, some Linux distributions had already taken this path some years ago, most notably Ubuntu and the last remaining bugs are being cleaned up pretty quickly.

Positive or Negative?

Overall, I think this is a positive step in the right direction for free and open Java on Linux platforms. This sentiment was welcomed by well known open source advocate Simon Phipps in a twitter post. The fact the the OpenJDK is now the reference implementation (combined with efforts to open up the issue tracker for the OpenJDK) means that means that a vast host of Java/Linux end users can now directly improve 'official Java' for all of us. 

I want the Oracle version!

Linux users who need to use the proprietary parts of the Oracle JDK 6 or Oracle JDK 7 binaries can of course as usual simply get the gratis download at under the same terms as users on other platforms. However, if it is due to a 'bug' that is discovered I strongly encourage those users to submit a bug report to the OpenJDK project, so that any issues can be fixed for all of us.

Opinions and further questions are welcome!


Thursday, 1 September 2011

JavaOne schedule

Here is my JavaOne schedule:  I can't mimic the nice colouring that Steve On Java has, but hey :-).

Please note the JCP EC meeting is open and free for all to join (Sunday 15:45) - we need the voice of the community there, so come along!

I'll actually be speaking at:

  • 30440 - Java User Groups and the JCP (Sunday 14:30)
  • 23647 - JCP and the Developer Community (Monday 11:00)
  • 23641 - Meet the Executive Committee Candidates (Monday 1900)
  • 23645 - Lightning Talks: JSRs in Progress (Wednesday 0830)
  • 25303 - The Diabolical Developer (Redux)  (Wednesday 1500)
  • 25303 - The Diabolical Developer (Redux) - repeat!  (Wednesday 1630)
  • 37780 - Java Community Keynote (Thursday 0845)

Let me know if you want to catch up!  I'll be fairly flexible about turning up to most sessions, the benefit of attending a conference like JavaOne is as much isn't catching up with friends an colleagues as much as anything else :-)

Tuesday, 19 April 2011

The Data Grid JSR Backlash and why you should support the JCP reforms

The recent backlash against Red Hat's data grid JSR proposal sparked an interest as I know the JCP is going under reform right now.

For those of you who have missed the debates, here's some background reading for you:

So, here are my thoughts on the subject!

Technical merits

On technical merit the JSR proposal certainly seems sound enough to be a solid starting point for discussion (I'm no expert mind you).

Open standards are good

It's a laudable goal to standardise this space, and Red Hat have got 
my support on that front. Just like vendor lock-in was bad for databases and app servers, it's also bad for developers and users of data grids.

This area is potentially worth Billions and so I can understand why some vendors may be reluctant to form an open std 
around it, but really, it's a good thing! I believe the vendors should be competing on performance and other factors, not basic get and put type API calls.

Where the proposal went wrong

Politically, Red Hat went about this in an unusual way, hence the backlash. Sadly, that sort of backlash can be enough to sink a JSR before it even sets sail.

I was a surprised that an organisation with so much JCP experience presented this JSR without the usual pre-collaboration that typically goes on in these cases. So I dug a little deeper to find out why Red Hat had gone about it this way.

The root cause

Without knowing all of the ins and outs, the new data grid JSR was proposed partly because of Red Hat's frustration with trying to get JSR-107 (data caching) back to an active state (it's been an inactive JSR for some time).

A std caching API (JSR-107) would be a natural base for any agreements around standardising any further data grid APIs on top of that.

Red Hat (and others?) had tried to re-vitalise the JSR-107 Expert Group to get 
the JSR re-opened, ratified and released. That would've been a great start, as it meant that there would be collaboration amongst the same vendors that are then needed for a subsequent data grid JSR.

Why did that attempt fail?

We don't really know. Unfortunately nobody on the outside can confirm what was/is going on as the JSR-107 mailing list is closed to the public!

This is the crux of the problem with the existing JCP rules, in that 'open standards' are being decided behind closed doors. Thankfully Patrick Curran is working on changing this (see! Oracle isn't always evil ;p).

So what happens next?

By raising the new JSR, Red Hat has gotten their desired result of getting JSR-107 moving again to complete the caching work. It's a 
shame that they were seemingly forced into this stance.  We'd all much rather see deliberate community collaboration, it's certainly not a model of how we want to see inactive JSRs moving again!

Red Hat's intentions are almost certainly completely honourable, but as some of the other vendor's stated, the raising of the new data grid JSR came across as a great surprise and was therefore not as welcomed as it could have been.

So, JSR-107 will go ahead, but it'll take some amount of bridge mending before data grid JSR gets off the ground.

Lets avoid this in the future and support Patrick Curran's JCP reforms!