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