Fix for 6888888 breaks the build

Mon Oct 26 22:46:08 UTC 2009

Andrew John Hughes wrote:
> 2009/10/26 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
>   
>> Andrew John Hughes wrote:
>>
>> 2009/10/26 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>
>>
>> 2009/10/16 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>
>>
>> Tim Bell wrote:
>>
>>
>> Andrew John Hughes wrote:
>>
>>
>> (snip!)
>>
>>
>> I think there's still an issue here that makes this patch worth
>> pushing.   The 6888888 fix didn't cause the bug, but merely made it
>> visible to a lot more people.  So 6889255 will only hide it again.
>> The build uses JAVA_TOOLS_DIR for javac, javah and javadoc:
>>
>>  # If no explicit tools, use boot tools (add VM flags in this case)
>>  JAVAC_CMD     = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \
>>                  $(JAVACFLAGS)
>>  JAVAH_CMD     = $(JAVA_TOOLS_DIR)/javah \
>>                  $(JAVAHFLAGS)
>>  JAVADOC_CMD   = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%)
>>
>>
>> but only when LANGTOOLS_DIST is not defined.  Normally, langtools is
>> built first so LANGTOOLS_DIST is defined.  What your fix for 6888888
>> did was cause the setting for JAVAH to get used in all cases and, as
>> JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR
>> this fails in many cases as the user sets ALT_BOOTDIR not
>> ALT_JDK_IMPORT_PATH.
>>
>> In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to
>> ${jdk_instances}/${importjdk} if it exists.  On Solaris,
>> ${jdk_instances} is set to /usr/jdk/instances which probably explains
>> why Sun engineers building on Solaris may not see this bug either.
>> ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros
>> tend to have standardised on /usr/lib/jvm.  It's simply "C:" on
>> Windows.  As mentioned on IRC, release engineering are setting
>> ALT_JDK_IMPORT_PATH explicitly so also would never see this bug.
>>
>> As we presumably want the tools from the bootstrap JDK, and not from
>> 'the import JDK to be used to get hotspot VM if not built', I suggest
>> we switch to BOOTDIR by default by applying this patch.
>>
>>
>>
>> Jonathan Gibbons wrote:
>>
>>
>>
>> This probably explains problems I've reported informally to Kelly a
>> while back, but never got around to formally investigating.     FWIW,
>> this fix does not interfere with the fix for 6889255 coming up, and this
>> fix seems like a good idea to me.
>>
>>
>> OK - I filed a new bug report:
>>  6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR"
>> with a pointer to this email thread.
>>
>> Kelly - do you have an opinion on this?
>>
>>
>> The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH
>> at all. And all class files would have been created by the LANGTOOLS_DIST
>> compiler (hotspot was a special case, using the ALT_BOOTDIR to compile).
>> But no class files would ever be created by the javac in ALT_BOOTDIR.
>>
>> ALT_JDK_IMPORT_PATH was supposed to only come into play when someone
>> was doing what I called a 'partial build', and it provided the missing
>> pieces, including a jdk7 flavored javac compiler.
>>
>> The other tools were less well defined in their use.
>> The jar tool in ALT_BOOTDIR is always used to build jars as I recall.
>>
>> The javah and javadoc story I'm not so sure about. I thought they would
>> have followed the same rules as javac.
>>
>> Not sure my ramblings are helping here....  :^(
>>
>> -kto
>>
>>
>>
>> Thanks-
>>
>> Tim
>>
>>
>> Did we come to a decision on this? I was reminded of it today because
>> none of the forests will build for me (except IcedTea which I've
>> patched) due to this bug.
>>
>> If we don't want to change from using ALT_JDK_IMPORT_PATH, we could at
>> least make it default to the BOOTDIR rather than a deliberately broken
>> path.  Though I still fail to see the need to point to two different
>> JDKs simultaneously...
>> --
>> 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
>>
>>
>>
>> I take it this is the error:
>>
>> # Running javah:
>> /mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah -bootclasspath
>> /mnt/builder/icedtea7/openjdk/build/linux-amd64/classes -d
>> /mnt/builder/icedtea7/openjdk/build/linux-amd64/tmp/sun/sun.security.pkcs11/j2pkcs11/CClassHeaders/
>> \
>> 		sun.security.pkcs11.wrapper.PKCS11 sun.security.pkcs11.Secmod
>> An exception has occurred in the compiler (1.7.0_0). Please file a bug
>> at the Java Developer Connection
>> (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade
>> for duplicates. Include your program and the following diagnostic in
>> your report.  Thank you.
>> java.lang.NullPointerException
>> 	at com.sun.tools.javac.code.Symbol$MethodSymbol.params(Symbol.java:1226)
>> 	at
>> com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1252)
>> 	at
>> com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1)
>> 	at
>> javax.lang.model.util.ElementScanner6.visitExecutable(ElementScanner6.java:191)
>> 	at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1260)
>> 	at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139)
>> 	at
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767)
>> 	at
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1)
>> 	at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129)
>> 	at
>> javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169)
>> 	at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874)
>> 	at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139)
>> 	at
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767)
>> 	at
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1)
>> 	at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129)
>> 	at
>> javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169)
>> 	at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874)
>> 	at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139)
>> 	at
>> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767)
>> 	at
>> com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:825)
>> 	at
>> com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1070)
>> 	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:806)
>> 	at com.sun.tools.javac.main.Main.compile(Main.java:400)
>> 	at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:139)
>> 	at com.sun.tools.javah.JavahTask.run(JavahTask.java:482)
>> 	at com.sun.tools.javah.JavahTask.run(JavahTask.java:319)
>> 	at com.sun.tools.javah.Main.main(Main.java:46)
>>
>> Should have clicked with me earlier, but I presume this also stops a
>> full bootstrap as well as the FontManager issue
>> (/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah above is the
>> just-built OpenJDK).  Looks like IcedTea won't be able to support b74.
>>  I hope RE learn from this and do a full bootstrap before promoting
>> b75, especially as that one is supposed to be the milestone.  b74
>> certainly gets the award for most broken promoted build so far.
>>
>>
>> Andrew,
>>
>> This should now be fixed.
>>
>> -- Jon
>>
>>     
>
> That's excellent news.  Do you happen to know which changeset(s) fix
> the issue?  I can then pull them into IcedTea ahead of time.
>   
Andrew,

Here's the fix:

Changeset: 2485f5641ed0
Author:    jjg
Date:      2009-10-19 13:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2485f5641ed0

6889255: javac MethodSymbol throws NPE if ClassReader does not read parameter names correctly
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+ test/tools/javac/6889255/T6889255.java

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20091026/5d162877/attachment.htm>