The javah changes from 6572945 are failing during the fastdebug build (product build seems to work OK):
Once you have run a fastdebug build as far as jdk/make/java/nio, running javah on one particular class is enough to see the java.lang.NullPointerException:
cd /w/hg/Agones/jdk/make/java/nio
/opt/java/jdk1.6.0/bin/java -showversion -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javah.jar:/w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javadoc.jar:/w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javac.jar" -jar /w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javah.jar -bootclasspath /w/hg/Agones/build/solaris-i586-fastdebug/classes -d /w/hg/Agones/build/solaris-i586-fastdebug/tmp/java/java.nio/nio/CClassHeaders/ \
sun.nio.fs.SolarisWatchService
java version "1.6.0_01-ea"
Java(TM) SE Runtime Environment (build 1.6.0_01-ea-b03)
Java HotSpot(TM) Client VM (build 1.6.0_01-ea-b03, mixed mode)
An exception has occurred in the compiler (1.7.0-tbell_2009_10_05.23.59.01_bootstrap). 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:1014)
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:745)
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:745)
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:805)
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)
###@###.### wrote:
> An even more trivial workaround to this entire problem is (just) to change the jdk build to use javah
> from the boot JDK instead of from langtools. That way we don't have to change langtools at all.
>
> Look in jdk/make/common/shared/Defs.gmk, lines 145-171
>
>> # Langtools
>> ifdef LANGTOOLS_DIST
>> JAVAC_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javac.jar
>> JAVAH_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javah.jar
>> JAVADOC_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javadoc.jar
>> DOCLETS_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/doclets.jar
>> JAVAC_CMD = $(BOOT_JAVA_CMD) \
>> "-Xbootclasspath/p:$(JAVAC_JAR)" \
>> -jar $(JAVAC_JAR) $(JAVACFLAGS)
>> JAVAH_CMD = $(BOOT_JAVA_CMD) \
>> "-Xbootclasspath/p:$(JAVAH_JAR)$(CLASSPATH_SEPARATOR)$(JAVADOC_JAR)$(CLASSPATH_SEPARATOR)$(JAVAC_JAR)" \
>> -jar $(JAVAH_JAR) $(JAVAHFLAGS)
>> JAVADOC_CMD = $(BOOT_JAVA_CMD) \
>> "-Xbootclasspath/p:$(JAVADOC_JAR)$(CLASSPATH_SEPARATOR)$(JAVAC_JAR)$(CLASSPATH_SEPARATOR)$(DOCLETS_JAR)" \
>> -jar $(JAVADOC_JAR)
>> else
>> # 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%)
>> endif
>
> I think all you need to do is to change the definition of JAVAH_CMD when LANGTOOLS_DIST is set to the same as it would be if
> LANGTOOLS_DIST is not sure.
>
> Alternative, you could do something like adding in an override definition for JAVAH_CMD after this block of code. That way it is
> easier to comment bit as a temporary workaround.
>
>
> -- Jon
Once you have run a fastdebug build as far as jdk/make/java/nio, running javah on one particular class is enough to see the java.lang.NullPointerException:
cd /w/hg/Agones/jdk/make/java/nio
/opt/java/jdk1.6.0/bin/java -showversion -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javah.jar:/w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javadoc.jar:/w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javac.jar" -jar /w/hg/Agones/build/solaris-i586-fastdebug/langtools/dist/bootstrap/lib/javah.jar -bootclasspath /w/hg/Agones/build/solaris-i586-fastdebug/classes -d /w/hg/Agones/build/solaris-i586-fastdebug/tmp/java/java.nio/nio/CClassHeaders/ \
sun.nio.fs.SolarisWatchService
java version "1.6.0_01-ea"
Java(TM) SE Runtime Environment (build 1.6.0_01-ea-b03)
Java HotSpot(TM) Client VM (build 1.6.0_01-ea-b03, mixed mode)
An exception has occurred in the compiler (1.7.0-tbell_2009_10_05.23.59.01_bootstrap). 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:1014)
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:745)
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:745)
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:805)
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)
###@###.### wrote:
> An even more trivial workaround to this entire problem is (just) to change the jdk build to use javah
> from the boot JDK instead of from langtools. That way we don't have to change langtools at all.
>
> Look in jdk/make/common/shared/Defs.gmk, lines 145-171
>
>> # Langtools
>> ifdef LANGTOOLS_DIST
>> JAVAC_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javac.jar
>> JAVAH_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javah.jar
>> JAVADOC_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/javadoc.jar
>> DOCLETS_JAR = $(LANGTOOLS_DIST)/bootstrap/lib/doclets.jar
>> JAVAC_CMD = $(BOOT_JAVA_CMD) \
>> "-Xbootclasspath/p:$(JAVAC_JAR)" \
>> -jar $(JAVAC_JAR) $(JAVACFLAGS)
>> JAVAH_CMD = $(BOOT_JAVA_CMD) \
>> "-Xbootclasspath/p:$(JAVAH_JAR)$(CLASSPATH_SEPARATOR)$(JAVADOC_JAR)$(CLASSPATH_SEPARATOR)$(JAVAC_JAR)" \
>> -jar $(JAVAH_JAR) $(JAVAHFLAGS)
>> JAVADOC_CMD = $(BOOT_JAVA_CMD) \
>> "-Xbootclasspath/p:$(JAVADOC_JAR)$(CLASSPATH_SEPARATOR)$(JAVAC_JAR)$(CLASSPATH_SEPARATOR)$(DOCLETS_JAR)" \
>> -jar $(JAVADOC_JAR)
>> else
>> # 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%)
>> endif
>
> I think all you need to do is to change the definition of JAVAH_CMD when LANGTOOLS_DIST is set to the same as it would be if
> LANGTOOLS_DIST is not sure.
>
> Alternative, you could do something like adding in an override definition for JAVAH_CMD after this block of code. That way it is
> easier to comment bit as a temporary workaround.
>
>
> -- Jon
- relates to
-
JDK-6892021 Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR
-
- Closed
-
-
JDK-6572945 javah should be written as an annotation processor, not a doclet
-
- Closed
-
-
JDK-6889255 javac MethodSymbol throws NPE if ClassReader does not read parameter names correctly
-
- Closed
-