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

[Andrew John Hughes]

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.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8