Comments on: Contributing to OpenJDK, no thanks http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/ Roman Kennke's ramblings Wed, 07 Jan 2009 08:24:01 +0000 http://wordpress.org/?v=2.5 By: Richard Bair http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-51550 Richard Bair Mon, 23 Jul 2007 18:52:20 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-51550 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 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

]]> By: nim-nim http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-51252 nim-nim Tue, 17 Jul 2007 09:06:58 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-51252 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. 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.

]]> By: fred http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50979 fred Mon, 16 Jul 2007 20:29:01 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50979 @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 :-( @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 :-(

]]> By: reasilva http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50855 reasilva Mon, 16 Jul 2007 09:01:12 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50855 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. 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.

]]> By: Gili http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50694 Gili Fri, 13 Jul 2007 19:41:03 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50694 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 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

]]> By: Evert Tigchelaar jr http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50690 Evert Tigchelaar jr Fri, 13 Jul 2007 18:14:52 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50690 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. 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.

]]> By: Dave Gilbert http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50684 Dave Gilbert Fri, 13 Jul 2007 17:16:07 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50684 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! 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!

]]> By: Lillian http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50679 Lillian Fri, 13 Jul 2007 15:27:52 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50679 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 :) 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 :)

]]> By: Charles Oliver Nutter http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50672 Charles Oliver Nutter Fri, 13 Jul 2007 09:22:01 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50672 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. 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.

]]> By: Andrew John Hughes http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50643 Andrew John Hughes Fri, 13 Jul 2007 00:22:40 +0000 http://kennke.org/blog/2007/07/12/contributing-to-openjdk-no-thanks/#comment-50643 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. 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.

]]>