Contributing to OpenJDK, no thanks

Late Update (January 2009): I see that this particular post is still very popular in search results and server statistics. Probably it is linked on various sites. I want to say that Sun took my criticism very serious and most things changed alot, and all other things is beeing worked on. So please read the following original post with that in mind. I’m a rather happy OpenJDK contributor now.

It is such a ridiculous pain to get a patch into OpenJDK, I get the feeling that this is not the kind of project, I would feel comfortable with. Both of the above linked patches have been rather trivial. Davids patch even came with a testcase. And still it has to go through a week-long process before it can show up in the build. This will scare off most voluntary contributors quickly I guess.

Now the thing is, I have to deal with OpenJDK as part of my job. So I will have to do some tweaks here and there. What I am going to do is, upload my patches somewhere, post a link to them so the Sun dudes can pick it up if they like, or not if they don’t. But I certainly won’t jump through their hoops only to get my code in. I will do my job, but I won’t spend my free time to implement some encumbrance or whatever. I have more important things to do, like hacking on GNU Classpath, Escher, Xebece or Hypertree. That is, if I actually find some free time besides the baby and family. πŸ˜‰

Update: I think a good chance to both serve the community and keep things stable would be to open up the repositories a little more. If non Sun contributors could work freely, for example in an external project like IcedTea, their patches could probably be fed back into Sun’s internal reviewing system in a streamlined, automatic or semi-automatic fashion. It would be even better if the community could be included into this reviewing system.

There’s a lot to be done and I’m sure a lot will be done. For now I’ll take care for my own little projects.

Advertisements

16 Responses to Contributing to OpenJDK, no thanks

  1. Kelly O'Hair says:

    Please bear with us here. I’ve been actively working on converting our sources to Mercurial and once done the plan includes making the Mercurial repositories externally available, and from there we want to streamline the process of contributions to the appropriate integration level. I know this is taking longer than it probably should, and I know that the contribution process is difficult right now. But it will improve, really.

    -kto

  2. Babies first.

    The patch turnaround is something that we’ll need to fix for OpenJDK, or developers won’t keep coming back.

    I guess it can be fixed in part by having the mercurial repository available soonish, so that one can track the patch through the working spaces, and in part by using something like icedtea (but for hot, experimental patches instead) to integrate the pending patches.

    But for a real fix, we’d need discussions on the lists, and see what’s blocking the queue.

  3. I’ve had similar feelings for a while now. I’m really hoping that as a proper repository appears and things start to work out, they’ll go away. I know we Classpath folks need to be patient but it’s difficult when OpenJDK has effectively put what we’ve been working on for years in limbo.

    We can’t go and fix holes in OpenJDK in any kind of fulfilling manner because you get the feeling someone behind the scenes is already working on it and the result will suddenly appear in some code drop, rendering you work obsolete. If even minor fixes like the ones Roman mentions here take forever, how can we work on something large like graphics or sound support?

    The motivation for working on Classpath instead is largely gone because the features that we miss are already implemented in OpenJDK code now under the same licence. It also feels a like we’re then going against the whole OpenJDK ethos.

    OpenJDK is a great step forward, but it’s also brought about the most indecisive and scary time in my Classpath hacking history and I guess that’s the case for many others too.

  4. A week doesn’t sound bad at all…on JRuby we have patches regularly sit for a couple weeks before getting in, largely because of the manpower needed to verify them. But of course if a patch is accompanied by a test case, no further effort should generally be required of the submitter. If that’s not the case in OpenJDK, it should certainly be changed. But if the problem is simply a lack of a place to post testcase + bug report + patch for the OpenJDK folks to get back to, then perhaps submitters just need to be more patient.

    Getting the Hg repo up soon would be a huge help to the whole process.

  5. Lillian says:

    I completely agree with you and it is disheartening. All Classpath-ers know what it feels like to have work rendered obsolete after the OpenJDK drop. While we are all extremely happy to have the JDK open, we don’t want to go through implementing something that may be done and waiting in a queue behind the scenes. I think this process goes against what Open Source is. I definitely hope (and believe) they will change this process- that is where blogging/complaining/bitching gets us. It works, and people do hear us.

    Keep up the good work though, having you stop doing what you are doing would only hurt Open Source Java a lot more πŸ™‚

  6. Dave Gilbert says:

    These are teething troubles, I’m sure, which is why I submitted a very simple patch for my first attempt at contributing to OpenJDK. Hopefully, we could get a contributors build set up with automated regression testing as the first stepping stone for patches…that would allow for quicker feedback, which I think is critical for OpenJDK to attract external-to-Sun contributors. Meanwhile, I can easily spend more time on something else – JFreeChart is always a nice time sink for me!

  7. Man, do you have nothing else to do that complaining all day long?

    Its good that Sun takes some to check the contributing before added it, the JDK is a very inportent application.

    I don’t want and need the open JDK, especialy because its gpl licenced.

    The only thing that hurst Java is the linux community. I can’t stand those people just complaining all day long and make stupid jokes. Get a real life.

  8. Gili says:

    I agree that developers should be able to work directly against a repository and commit their changes like they would to any other open-source project. I like the idea of working against an independent repository with Sun Engineers handling regular merges between the two repositories.

    These difficulties are just normal growing pains. Look around the industry, how many companies are open-sourcing their crown jewels and how smoothly does this transition happen?

    I think we should keep on sending Sun constructive criticism and help them understand what they can do to ease the process. With enough community support I’m sure we can come to an arrangement that makes everyone happy.

    Just my 2 cents,
    Gili

  9. reasilva says:

    Thanks God SUN people are not including into SDK any patch that they get from a random hacker. I would be terrified if they did that.

    And please understand. That making SDK open source was not an ideological choice or technical one – SUN cannot care less about contribution to the SDK code. This was simply a marketing action – OS is hot right now, let’s do some open source. SUN realized that open sourcing Java on GPL does not have ANY practical consequences. That’s why IBM with their Apache Harmony was so furious. IBM was trying to overtake Java, but they failed.

    This is the same with Ruby. SUN is totally uninterested in Ruby from the technical point of view. But is is hot topic right now, so MARKETING department spends some money on developmnet of JRuby and NetBeans support for Ruby (which is very cool, BTW).

    Now Java is OS, SUN is doing Ruby, SUN is cool and modern for the 1/4 money they would have to spend on marketing capaign that would bring similar echo.

  10. fred says:

    @reasilva: “SUN cannot care less about contribution to the SDK code”, I think here you are completely wrong.
    Not because we live in a beautiful world of openness, but because if they don’t integrate the good patches and insert what developers expect and want, someone will have the leverage to make a successful branch of the OpenJDK (look what happen with OpenOffice on MacOS).
    Just the fact that it’s possible, is making Sun spend all this useful energy on Mercurial.
    Anyway, for the problem at hand, what we are currently missing is a completely open list of who is working on what. On most open source project today, with JIRA it’s quite straight forward: Add a comment that you are starting coding this feature or bug, attached the pacth, and start the feed back loop.
    Everyone can get the patches provided by anyone.
    IMO, before Mercurial I will really like to have the Bug Database of Sun upgraded to something a lot more open. For example, I discussed the need for voting against a patch or feature (Request Against Enhancements) in my blog.
    So, in the mean time I’m also creating my patches for the OpenJDK (abstract enum and now generics on enum) without pushing them, but will really like to get more feedback 😦

  11. nim-nim says:

    Speaking as someone who’s overseing IT projects in a big corporation I can tell you SUN’s opening of Solaris and Java is not pure marketing.

    SUN badly needs good Linux Java support (even if it means it becomes just another Linux hardware provider). Their own Linux support sucks. Solaris intel is *not* ready yet and missing third-party support. The current upheavals in the sparc line are quite frightening to projects – two new unproven sparc generations in a row is a bit much.

    Their customers have been willing to wait a few years for SUN to clean up their act but not anymore. I’ve seen lots of historical J2EE/Solaris apps being deprecated this year.

    Corporations typically use three-year contracts. Three years ago SUN hardware and software was not positionned too bad. So SUN J2EE got a good treatment.

    Since then performace of the old Sparc line has been abysmal, intel servers got very powerful and Microsoft developped an attractive .Net platform. As a result a lot of SUN customers are re-evaluating the J2EE/Solaris place in their systems. If anything the SUN opening is late and they’ll have a bumpy ride for a few years.

    SUN lost many opportunities trying to accaparate the J2EE market and pushing solutions no one wanted (SUN one, SUN grid…). At the end of the day it’s better of with a mixed J2EE market than customers dumping Java for something else. Java (even non-SUN Java) sold a lot of SUN servers.

  12. Richard Bair says:

    Hey Roman,

    Just wanted to note that the fix has (finally) been putback to the swing workspace. It should be popping out in a development build in the next couple weeks. I’m not sure what the integration schedule is of the build team.

    Thanks
    Richard

  13. Larry says:

    GPPOzB0KTb0jn

  14. Pingback: This note’s for you » Blog Archive » About an old post

  15. sandrar says:

    Hi! I was surfing and found your blog post… nice! I love your blog. πŸ™‚ Cheers! Sandra. R.

  16. Pingback: The end of Java boulevard? « Experiences in the community

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: