Andreas Schaefer's Blog

Community: JDK Archives

OpenJDK: Here I come

Ditching the Keynote session at JavaOne I am sitting in the Alumni room and trying to get my head around the OpenJDK. Having a MacBook Pro I cannot download the JDK and build it on my Mac natively and so I needed to fire up my VMware installation of OpenSuSE and use Linux to build it on top of the Mac. So I went to the OpenJDK website, downloaded the source and the binary plugins and extracted them. Then I went ahead and tried to setup the environment as requested by j2se/make/jdk_generic_profile.sh script file like ALT_BOOTDIR, ALT_CLOSED_JDK_IMPORT_PATH, LANG and emptied JAVA_HOME. There I realized that I do not have Java 6 installed so I downloaded and installed it. Finally I was ready to fire up the build:

cd control/make
gmake sanity

and sure enough it failed right away complaining missing Alsa headers. After going through some hops I finally could install Alsa, Cups and Motif headers. For Motif I had to revert to lesstif-devel which I have to force to install because of the dependencies of lesstif. Nevertheless I got that going and after setting ALT_MOTIF_DIR to the directory (/usr/X11R6 on my box) containing the includes I was ready to go, at least I thought so. Unfortunately the sanity checks are looking for this file include/Xm/AccColorT.h which is not in lesstif but when I just created that file with vi the make system happily start to build, yeeha.

As a side note I wanted to fool the build by just creating the AccColorT.h file because I saw that on some mailing list that the JDK build does not need Motif but that is wrong, at least as of now. Some generated classes (I found a class called sizer.c) uses it in its imports.

Finally, after nearly an hour the built went through and a short java -version confirmed that I have built JDK 1.7.

Cool - Andy

OpenJDK: Who is / will be in Charge?

JDK Community: Update

After quite some screaming and kicking (see my previous blog) my fix for bug ##6212146 made it into Mustang build #78. For a change I do not want to bitch about anything but congratulate Sun for all the progress they made in the Peabody endeavor. Any community project in a big company is difficult especially when so much is at stack as in Java and lawyers tend to be the problem as well as the solution and so it is amazing that the community project went as far as it did. Of course, there is a lot that can be improved and I will try to contribute to that as much as I can but I think that Sun is on the right path and I see the light at the end of the tunnel where Java becomes an open-source project.

Nearly ten years ago I had an job interview in my hometown in Switzerland and the manager  asked me what I would like to do as a software engineer if the sky would be the limit. According to his reaction he was not used to hear that a little developer would like to write software that is distributed worldwide. Since I moved to the US this dream became more and more reality and now some code will be distributed along with JDK 1.6. Now, the only thing left to do is world domination, right Pinky.

Bad Andy - Better Pizza

JDK Community: Dream or Reality

Yesterday Ray Gan blogged about the JDK Community listing some of the facts about the Peabody project. If you never heard about that project then you are not alone and I only now about it because Joshua Marinacci gave a presentation about it at the LA-JUG last year. But even without knowing about the Peabody project is became a JDK contributor last year in November and started to code a fix for bug #6212146 which I has sent to Sun for a review by the end of November. I got an initial confirmation that the bug fix was received but that was all I heard from Sun for a long time. Then January 2006 Ray blogged about the state of JDK Community and I responded complaining about that I got no feedback from Sun about my patch. A little bit later I finally got an email from Michael McMahon (1/31) that they started to look into the patch. I also spoke with Matt Ingenthron from Sun about it and he tried to find out what is going on and to bring some more transparency into the JDB Community. Needless to say that I did not get any feedback since then

As a good citizen I took the time yesterday to fill out the survey and to pour in some of my thoughts and complaints. Now I take the opportunity of this blog to share my thoughts on the JDK Community to a broader audience. As an active open-source developer I know both sides of the aisle, the one that runs a project and the one that provides patches. But in order to keep a community alive and active the project team must react to input from the community and give feedback without being pushed all the time. Especially in this case where Sun is a huge company and Java is a big project getting a community project up an running is difficult. Nevertheless as a contributor I think I have the right that Sun not only receives the work from the contributors but also gives something in return and the very basic would be feedback on the progress of a patch. Unfortunately a regular contributor cannot get the CTS in order to make sure that one's but fixes does not break Java and so I cannot test it thoroughly. This means a contributor has to wait until Sun provides feedback to improve the patch. As a contributor I do not want that my patch is swallowed by a black hole and one day it makes it into the JDK or not.

I suggested a few improvements and most prominently I would love to have a contract person within Sun with whom I can work on the patch to make it into the JDK. He/she does not have to be the developer that test or improve the patch but he/she must be able to answer questions and to provide feedback. I do not need contests, awards or public recognition but I would love to have my name as author in the Java code when the patch makes it into the JDK. In addition I would love to have forum(s) for contributors where they can discuss items with the Sun's Java developers and also a way to track which contributor is working on which bug so that I can avoid working on a bug that someone else is already working on. Maybe it would be a good idea to invite some contributors into an expert group to improve the JDK Community process.

Currently I am not working on any patches for the JDK because I want to ensure that my time spent on this is spent worthwhile and so I want to see if it makes it into the JDK or not and in case it fails I want to know why. That said I still hope that Sun can improve the JDK Community because I would love to work on the JDK in the future. So far I am disappointed about the process and also think that this is why there are not as many contributions as one would expect (see the JDK Community List).

-Andy

Sun let's you Scratch the Itch in the JDK 1.6

After complaining about shortcomings in the Java JDK for some time I took the opportunity to actually try to fix one of the problems is encountered and send a patch to Sun. Looking back I have to give kudos to Sun how relatively easy it is to become a contributor and that they really want to keep the developers in the loop not like in the "good old" days where submitting a bug report meant that I just disappeared in a black hole and if you were lucky it reappeared later.

What I would like to see is that there would be a way to access particular classes from the web rather than downloading 65M archive especially when I also need to download a 85M archive containing the binaries. Normally I only need a few classes to work with in order to fix a problem.

So far I am only interested in fixing problems within the Java classes of the JDK and so I do not need to rebuild the entire JDK. In order to run a program with my patches I just prepend the build directory of my patches to the boot classpath like it did to run the JUnit tests within my Ant build script:

<junit printsummary="yes" fork="yes" forkmode="once"
       haltonfailure="no" showoutput="true" 
       failureproperty="test.failures">
       
    <formatter type="xml" usefile="true"/>

    <classpath>
        <path refid="build.test.path"/>
    </classpath>
                        
    <jvmarg value="-Xbootclasspath/p:${my.boot.class.path}"/>
    <jvmarg value="-Xms128m"/>
    <jvmarg value="-Xmx512m"/>			
    <jvmarg value="-Xnoclassgc"/>			
    
    <batchtest todir="${test.report.dir}" >
        <fileset dir="${test.src.dir}" includes="**/*" excludes=""/>
    </batchtest>
</junit>

This is enables me to run the tests without my patch (just by running JDK 1.6 on its won) so make sure that it keeps failing.

Strange how things are changing over time. Back when I was contributing to JBoss there were tensions with Sun about licensing and now I am contributing to the JDK and I have tensions with JBoss about licensing and trademarks.

Have fun - Andy

This work is licensed under a Creative Commons License.