Building JDK 6.0 on Windows

; Date: Fri Sep 16 2005

Tags: Java

One of the things we've been doing is opening up the processes around Java, and distributing buildable source that's updated as we develop the 6.0 release. We really want feedback from the public as to whether we're going in the right direction, if you see any quality issues in your applications, whether we've broken anything, etc.

We are, of course, continuing to do the testing the Quality Team has been doing all along. But we know that we can do only so much, and that the real test is where the rubber hits the road, so to speak. In other words, where the JDK is run against your applications.

While we provide prebuilt binaries, you may also want to build your own. The licenses allow you to do so, and under certain limitations to redistribute modified JDK's. For example you might want to try submitting bug fixes, in which case you need to build a JDK to implement and your fixes.

With that, let me point you to this blog entry: ( Building the JDK 6.0 on Windows XP

This is a fairly comprehensive description on how to set up to build the JDK on Windows XP. There's a few simple requirements, such as having Visual Studio and such. It's all explained in the posting.

Source: (


Humor me as I think about this:

Windows developers who own Visual Studio do Windows development in C#, C++, or Visual Basic. That's why they or their boss shelled out $600 or do Windows development. These Windows developers who own VS aren't interested in Java development or compiling the Java platform on Windows. The vast majority of Java developers who work on Windows OS do not own Visual Studio nor will they purchase it just to compile Java. Any one interested in Java development on the Windows platform probably doesn't have or can't purchase the tools to participate in building the product. And the final conclusion...Sun doesn't get too many bug fixes from the Windows crowd.

Surely, I'm not the only person with these ideas? And I've brought this topic up before: Building Java SE 6 on Windows. Potential contributors on the Windows side can't contribute because they are locked out of the party. It's the tools. You cannot expect them to buy the tools just to compile the VM...and if they already have the tools, they're too busy doing Windows development to bother with Java. I would love to see the actual numbers on this. Just how many bug fixes from the Windows crowd has Sun collected? Provide a Windows build environment that doesn't have Visual Studio, preferably a GCC solution, and all those Java developers who work in a Windows environment will contribute. Otherwise, I just can't imagine any reason to expect big numbers of contributions.

Posted by: joconner on September 16, 2005 at 11:52 PM

I recall a thread on the Mustang forum where people were explicitely discouraged from redistributing Mustang builds along with their software for the usual reasons: it's not an official, compatible Java(TM) release.

cheers, dalibor topic

Posted by: robilad on September 17, 2005 at 06:46 AM

joconner, It seems your assertion is that Java programmers are poor, acting on their own, and therefore can't afford Visual Studio. I don't think that's true. Among the 5 million odd Java developers some are in major corporations and surely develop in multiple languages.

I do agree that it adds an additional requirement that someone who's gonna work on Java have Visual Studio. I'm not involved with the team that determines how Java is built, however, so I can't talk about why they're requiring one compiler or another.

robilad, There are various licenses for Java. For example for 1.5 we have the SCSL which allowed various freedoms, but apparently wasn't clear enough (something about many long pages of lawyerese). For 1.6, in addition to the commercial licenses we have the JRL meant for researcers who want to contribute. There's another license which I can't find right now which allows you to redistribute within an organization a modified JDK.

If you haven't noticed, we take compatibility very seriously. In some redistribution modes (e.g. bundling Java with a commercial application) we're requiring that you pass the JCK. This is meant to protect the public, giving them the comfort that if they see something claiming to be Java, that it includes at the least all the things that are Java. Graham Hamilton discusses it more in his blog.

Unfortunately I can't find a page that gives an overview of all the licenses. It would be nice to have a single page summarizing all of them. I'll bring that up with some folks and see what can happen.

Posted by: robogeek on September 18, 2005 at 12:02 PM

Sun is working on some changes to the build process so that it will be possible to easily build Java sources in the JDK without requiring any native compiler. Of course this will only work if you are only interested in making changes to Java source files, and not to native files or native interfaces. But I think most Mustang contributions we have seen so far have been on the Java side only, so I think this will significantly lower the bar for folks that want to experiment with JDK development. The relevant bug report is 6288957. Watch this blog for future developments.

Thanks, Chris.

Posted by: campbell on September 18, 2005 at 01:35 PM

David, thanks for your reply. Let me help you, since I know a lot about Sun's licensing models for Java: the license you mean is called JIUL.

If you have read through Ray Gans' blog on the internal redistribution license, you have probably noticed the quote:

" I hope you never have to use the JIUL, but if the need ever arises, you'll be glad it's there."

You'll notice that Sun does not want you to license the code under the JIUL, and spread potentially incompatible versions internally, unless you really have a bad, bad need to do so. Which should be never, as far as hope carries ;)

If you've read through Graham's interviews on JRL and Peabody and what not, you may have noticed that he thinks that the SCSL is a perfect license, which can easily be understood by an army of lawyers. What if you don't have a handy army of lawyers? Too bad, buy some. ;)

As for taking the compatibility very seriously, I wouldn't expect less. Even I take compatiblity very seriously, and I am writing my own runtime from scratch in my spare time, and don't have multi-million dollar customers to cater to. If I can spend a few hours on it, I am sure a mutli-billion dollar corporation can do it, too. ;)

Unfortunately, Sun is a few steps behind, say, GNU Classpath, that lets everyone evaluate the compatibility of that platform easily using the free software Mauve testsuite, while noone knows how compatible Sun's own releases for Linux on the not officially certified platforms like Gentoo, or Debian are, for example, and noone can legally find out and publish the results.

But then, I guess noone should really care about verifying compatibility claims of some proprietary piece of software, right? ;)

cheers, dalibor topic

Posted by: robilad on September 20, 2005 at 10:33 PM

robilad, thank you for clearing up where you're coming from ...

This article: How to Contribute Code to Mustang is more what I was looking for, as it gives an overview of all the licenses.

There is a specific meaning to "compatibility" which the Mauve test suite does not measure. The JCK is the official measure of compatibility to the java specification. Mauve is not the JCK.

I haven't made a deep study of Graham's statements as you apparently have. I do hear him speak about the licenses from time to time (his office is around the corner from mine) and my take of his thinking is that we tried SCSL and the public rubbed our noses in the fact that it was an overly lawyerly license. I don't know if he prefers the SCSL himself, but does his personal opinion really matter so much as the action Sun has taken overall? Simpler and easier to understand licenses is a good thing, and expanding flexibility of using Java source is a good thing.

The owner of a piece of software gets to determine the license under which it's published. Different licenses serve different ends. That's the way it is. Posted by: robogeek on September 21, 2005 at 02:46 PM

About the Author(s)

David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.