Security fixes are back; other fixes can go in. Time for build 18?

[Jonathan Gibbons]

Andrew John Hughes wrote:
> 2009/12/8 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
>   
>> Andrew John Hughes wrote:
>>
>> 2009/12/8 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
>>
>>
>> Jonathan Gibbons wrote:
>>
>> Joseph D. Darcy wrote:
>>
>> [snip]
>>
>> I'm open to OpenJDK 6 langtools  being made Werror clean as judged by JDK 7,
>> but backporting the fixes may be nontrivial.  (The Werror checking in JDK
>> 7's javac is more stringent than that in OpenJDK 6.)
>>
>> -Joe
>>
>> Joe,
>>
>> I will look at this -- but I think the correct solution is simply to fix
>> warnings and not try backporting anything.
>>
>> -- Jon
>>
>>
>> I looked at this. It is easy enough to fix the warnings that come from using
>> an OpenJDK 7 compiler, but it is somewhat more problematic to have the build
>> work at all.
>>
>> Here's what happens when you try to run ant with boot.java set to a recent
>> OpenJDK 7:
>> -- it compiles the bootstrap compiler OK
>> -- the build then tries to run the bootstrap compiler on the boot JDK
>>    -- the bootstrap compiler finds version 51 class files on its
>> bootclasspath, but it only accepts up to version 50 class files, so it
>> starts reporting warnings
>>    -- eventually it runs over the warnings limit regarding class file
>> versions and aborts
>>
>> So now we are talking about hacking the build a bunch more with fixing up
>> bootclasspath, or we are talking about using a version of OpenJDK 7 that has
>> been built for v50 class files. Either way, we've gone over the effort
>> budget for what ought to be a simple fix.
>>
>> In my opinion, the correct solution is for those folk trying to use an
>> OpenJDK7 compiler to disable the use of those warnings that are new in JDK7:
>>
>> $ hg diff
>> diff -r a9008b46db24 make/build.properties
>> --- a/make/build.properties    Sun Oct 11 12:02:03 2009 +0200
>> +++ b/make/build.properties    Tue Dec 08 14:21:27 2009 -0800
>> @@ -68,7 +68,7 @@
>>  # set the following to -version to verify the versions of javac being used
>>  javac.version.opt =
>>  # in time, there should be no exceptions to -Xlint:all
>> -javac.lint.opts =
>> -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial -Werror
>> +javac.lint.opts =
>> -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial,-rawtypes
>> -Werror
>>
>>  # options for the <javadoc> task for javac
>>  javadoc.jls3.url=http://java.sun.com/docs/books/jls/
>>
>>
>>
>> From what you say, it's not going to work even with that fix because
>> the OpenJDK6 compiler will baulk at the OpenJDK7 class files on the
>> bootclasspath.  The only way I can see around that is to point it at
>> the source code in the JDK instead.
>>
>>
>> Oh you so do not want to do that!  See my blog entry
>> http://blogs.sun.com/jjg/entry/building_javac_for_jdk7 for some of the
>> problems you get into when you start to compile against JDK sources!
>>
>> -- Jon
>>
>>
>>
>>
>> -- Jon
>>
>>
>>
>>
>>
>>     
>
> Oh believe me, I meant that as a showstopper rather than a suggestion!
>
> I have read your blog on this, and we also have plenty of experience
> with bootstrapping from IcedTea.  The IcedTea build has to do exactly
> this before it can even launch the OpenJDK build process.  The reason
> is twofold:
>
> 1.  There are some methods and classes still missing from gcj which we
> use to bootstrap
> 2.  There are com.sun.* and sun.* intrinsic dependencies in the OpenJDK code.
>
> Long term, I'd like both of those to go away, by additional work on
> gcj and fixes to OpenJDK.  The current process relies on compiling a
> specific subset of OpenJDK to fill the holes and on pre-generated
> versions of the files you mention.  It's fragile and breaks every so
> often as new build drops appear.  But it's necessary because there is
> no OpenJDK before 6 to bootstrap with.
>   


Having done this once, can you now use earlier builds of OpenJDK 6 to 
build newer builds?
Can you now not define OpenJDK 6 to be the preferred platform for 
building newer versions of OpenJDK 6?

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20091208/875d8711/attachment-0001.html