Difference between revisions of "DealingWithJava5CompilerIssues"

From Protege Wiki
Jump to: navigation, search
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
Because apple has not yet moved to Java 6, the Protege team has remained with the Java 5 development platform.  Since this is an old platform that is coming close to its end of life there are bugs that have been fixed in Java 6 but not in Java 5.  There are at least two of  these Java 5 compiler  bugs  that have given the Protege developers trouble.  The first of these involved an annotation in the wrong part of the java code (eclipse liked it but Sun's java compiler  did not).  The second of these was much more difficult to find and fix. For a while I was in despair and considering that we might be forced to abandon the Sun Java platform in favor of  Jikes.  (I know some of my readers think  that this would have been a good idea!)
+
Nearly three years after Java 6 was introduced, apple has still not succeeded in getting Java 6 working on the Apple 32 bit intel and powerpc platform.  Thus, in order to continue to support the 32 bit intel macs, the Protege team has been forced to do its development on Java 5.  Since this is an old platform that has past its end of life, there are bugs that have been fixed in Java 6 but not in Java 5.  There are at least two of  these Java 5 compiler  bugs  that have given the Protege developers trouble.  The first of these involved an annotation in the wrong part of the java code (eclipse liked it but Sun's java compiler  did not).  The second of these was much more difficult to find and fix. In both cases the compiler would crash without giving any useful diagnostics.  After working on the second of these problems for half a day, I was in despair and considering that we might be forced to abandon the Sun Java platform in favor of  Jikes.  (I know some of my readers think  that this would have been a good idea!)
When I was working on solving this problem, I had no idea how  to isolate the source of the problem.  In the end I got lucky and found an approach that worked.  I thought that I would report it here.  This is the second time we have had this type of problem and if it ever happens again I hope that this page can help you find a solution.
+
I had no idea how  to isolate the source of the problem.  In the end I got lucky and found an approach that worked.  I thought that I would report it here.  This is the second time we have had this type of problem and if it ever happens again I hope that this page can help you find a solution.
  
 
To see the problem, checkout [http://smi-protege/repos/protege/protege4/protege-standalone/branches/protege4_1_port] at revision 14332 and run<pre>
 
To see the problem, checkout [http://smi-protege/repos/protege/protege4/protege-standalone/branches/protege4_1_port] at revision 14332 and run<pre>
 
     ant clean equinox
 
     ant clean equinox
 
</pre>
 
</pre>
If you do this with a Java 6 compiler there will be no problem.
+
If you do this with a Java 6 compiler there will be no problem (Sun fixes their bugs!).
 
If you do this with apple's Java 5 compiler you will see the error
 
If you do this with apple's Java 5 compiler you will see the error
 
<pre>
 
<pre>
Line 14: Line 14:
 
     [javac] at com.sun.tools.javac.comp.Lower.access(Lower.java:1048)
 
     [javac] at com.sun.tools.javac.comp.Lower.access(Lower.java:1048)
 
</pre>
 
</pre>
If you do this on one of the Java 5 sun compiler's you will see an AssertionError with a different stack:
+
If you do this on one of the Java 5 sun compilers (which are near their end of life) you will see an AssertionError
 +
with a different stack:
 
<pre>
 
<pre>
 
     [javac] An exception has occurred in the compiler (1.5.0_17). 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.
 
     [javac] An exception has occurred in the compiler (1.5.0_17). 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.
Line 53: Line 54:
 
[tredmond@Andromeda owleditor]$  
 
[tredmond@Andromeda owleditor]$  
 
</pre>
 
</pre>
This is a lot of code to work through and even when I was down to one class it took a bit of work to finish.  So working through this would be possible but pretty hard.  I tried using the -v option to the ant process but as it turned out this pointed me  to the wrong problem.  Ant -v pointed me to the RDFXMLRenderingViewComponent class which was not the cause of the problem. What I didn't yet know was that I needed to run the java compiler directly with the -verbose option.
+
This is a lot of code to work through and even when I was down to one class it took a bit of work to finish.   
 +
But actually based on my experience now having found a workaround for the compiler bug, it would have been possible to go through these one by one until I found out which class and then which lines were causing the problem.
 +
So working through this would be possible but pretty hard.  I tried using the -v option to the ant process but as it turned out this pointed me  to the wrong problem.  Ant -v pointed me to the RDFXMLRenderingViewComponent class which was not the cause of the problem. What I didn't yet know was that I needed to run the java compiler with the -verbose option.
  
 
So I was playing with running the java compiler directly from the command  line and at some point I tried the lucky sequence  of commands in the plugins/org.protege.editor.owl/src directory:
 
So I was playing with running the java compiler directly from the command  line and at some point I tried the lucky sequence  of commands in the plugins/org.protege.editor.owl/src directory:
Line 65: Line 68:
 
   javac -verbose -d ../build/classes -classpath ${CP}  `find org -name "*.java"`
 
   javac -verbose -d ../build/classes -classpath ${CP}  `find org -name "*.java"`
 
</pre>
 
</pre>
You would have to do a bit of work to get the above to work but if you really need to I know you could set it up.  The placement  of the Protege directory is a bit hard to explain and you would probably do this  slightly differently.
+
You would have to do a bit of work to get the above to work but if you really need to I know you could set it up.  The placement  of the Protege directory is a bit hard to explain and you would probably do this  slightly differently.
It is much harder to do that running ant with the -v option but it pointed me to the correct file.  With the -verbose option I could see what the compiler was doing right before it  died:
+
 
 +
Actually - embarrassingly enough - it turns out that there is a perfectly easy way to do this in ant.  Add the verbose option to the javac task as follows:
 +
<pre>
 +
    <javac srcdir = "${src}"
 +
            destdir = "${classes}"
 +
            debug="on"
 +
            verbose="on"
 +
            includeAntRuntime="false">
 +
      <classpath refid = "project.classpath"/>  
 +
    </javac>
 +
</pre>
 +
Hmm... that would have been a lot easier.
 +
With the -verbose option I could see what the compiler was doing right before it  died:
 
<pre>
 
<pre>
 
...
 
...
Line 78: Line 93:
 
at com.sun.tools.javac.comp.Lower.access(Lower.java:1019)
 
at com.sun.tools.javac.comp.Lower.access(Lower.java:1019)
 
</pre>
 
</pre>
This pointed me to the OWLAnnotationPropertyHierarchyViewComponent class.  I had no idea at this point whether the problem was really with the RDFXMLRenderingViewComponent  class or the OWLAnnotationPropertyHierarchyViewComponent class.  I knew I was on the right track when I emptied  the OWLAnnotationPropertyHierarchyViewComponent class, added the minimal  amount of code to get it to compile in the ide and then ran the ant script.  The ant script was now able to compile the code!  I was close!  Then I did  a binary search of changes through this  class to narrow  the problem.  Even when I was down to the five lines of code that was causing the problem it took me a while before I figured out the fix.
+
This pointed me to the OWLAnnotationPropertyHierarchyViewComponent class.  I had no idea at this point whether the problem was really with the RDFXMLRenderingViewComponent  class or the OWLAnnotationPropertyHierarchyViewComponent class.  I knew I was on the right track when I emptied  the OWLAnnotationPropertyHierarchyViewComponent class, added the minimal  amount of code to get it to compile in the ide and then ran the ant script.  The ant script was now able to compile the code!  I was close!  Then I did  a binary search of changes through this  class to narrow  the problem.  Even when I was down to the five lines of code that was causing the problem it took me a while before I figured out the fix.  Of course the fix involved replacing some perfectly valid java code with a slightly rewritten version that did the exact same thing.
  
 
Hopefully knowing the sequence of steps will help you!
 
Hopefully knowing the sequence of steps will help you!

Latest revision as of 21:23, May 1, 2010

Nearly three years after Java 6 was introduced, apple has still not succeeded in getting Java 6 working on the Apple 32 bit intel and powerpc platform. Thus, in order to continue to support the 32 bit intel macs, the Protege team has been forced to do its development on Java 5. Since this is an old platform that has past its end of life, there are bugs that have been fixed in Java 6 but not in Java 5. There are at least two of these Java 5 compiler bugs that have given the Protege developers trouble. The first of these involved an annotation in the wrong part of the java code (eclipse liked it but Sun's java compiler did not). The second of these was much more difficult to find and fix. In both cases the compiler would crash without giving any useful diagnostics. After working on the second of these problems for half a day, I was in despair and considering that we might be forced to abandon the Sun Java platform in favor of Jikes. (I know some of my readers think that this would have been a good idea!) I had no idea how to isolate the source of the problem. In the end I got lucky and found an approach that worked. I thought that I would report it here. This is the second time we have had this type of problem and if it ever happens again I hope that this page can help you find a solution.

To see the problem, checkout [1] at revision 14332 and run
    ant clean equinox

If you do this with a Java 6 compiler there will be no problem (Sun fixes their bugs!). If you do this with apple's Java 5 compiler you will see the error

    [javac] An exception has occurred in the compiler (1.5.0_16). 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.
    [javac] java.lang.NullPointerException
    [javac] 	at com.sun.tools.javac.tree.TreeMaker.Ident(TreeMaker.java:413)
    [javac] 	at com.sun.tools.javac.comp.Lower.access(Lower.java:956)
    [javac] 	at com.sun.tools.javac.comp.Lower.access(Lower.java:1048)

If you do this on one of the Java 5 sun compilers (which are near their end of life) you will see an AssertionError with a different stack:

    [javac] An exception has occurred in the compiler (1.5.0_17). 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.
    [javac] java.lang.AssertionError
    [javac] 	at com.sun.tools.javac.comp.Lower.access(Lower.java:955)
    [javac] 	at com.sun.tools.javac.comp.Lower.access(Lower.java:1048)
    [javac] 	at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java:1379)
    [javac] 	at com.sun.tools.javac.comp.Lower.access(Lower.java:1019)

It is not at all clear at this point how to pinpoint the problem. It was not hard to determine which svn revisions were involved. A binary search quickly revealed that the problem occurred between revisions 14299 and 14300. However several files changed in that period:

[tredmond@Andromeda owleditor]$ svn diff --summarize -r 14299:14300
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/OWLWorkspace.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/entity/CustomOWLEntityFactory.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/entity/OWLEntityFactory.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/IndividualsByInferredTypeHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/cls/InferredOWLClassHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/OWLObjectHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/AbstractOWLPropertyHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/OWLOntologyHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/OWLObjectPropertyHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/OWLDataPropertyHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/OWLAnnotationPropertyHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/IndividualsByTypeHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/AbstractSuperClassHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/AbstractOWLObjectHierarchyProvider.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/model/hierarchy/AssertedClassHierarchyProvider2.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/ui/OWLEntitySelectorPanel.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/ui/tree/OWLObjectTree.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/ui/tree/OWLModelManagerTree.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/ui/renderer/OWLIconProviderImpl.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/ui/view/annotationproperty/OWLAnnotationPropertyHierarchyViewComponent.java
M       plugins/org.protege.editor.owl/src/org/protege/editor/owl/ui/frame/OWLAnnotationFrameSection.java
A       plugins/org.protege.editor.owl/icons/property.annotation.addsib.png
A       plugins/org.protege.editor.owl/icons/property.annotation.addsub.png
M       plugins/org.semanticweb.owl.owlapi/lib/owlapi-bin.jar
[tredmond@Andromeda owleditor]$ 

This is a lot of code to work through and even when I was down to one class it took a bit of work to finish. But actually based on my experience now having found a workaround for the compiler bug, it would have been possible to go through these one by one until I found out which class and then which lines were causing the problem. So working through this would be possible but pretty hard. I tried using the -v option to the ant process but as it turned out this pointed me to the wrong problem. Ant -v pointed me to the RDFXMLRenderingViewComponent class which was not the cause of the problem. What I didn't yet know was that I needed to run the java compiler with the -verbose option.

So I was playing with running the java compiler directly from the command line and at some point I tried the lucky sequence of commands in the plugins/org.protege.editor.owl/src directory:

  CP=../../Protege/bundles/org.protege.common.jar
  CP=${CP}:../../Protege/bundles/org.protege.editor.core.application.jar
  CP=${CP}:../../Protege/plugins/org.semanticweb.owl.owlapi.jar
  CP=${CP}:../build/lib/log4j.jar
  CP=${CP}:../../Protege/org.eclipse.osgi.jar 
  CP=${CP}:../../Protege/bundles/org.eclipse.equinox.registry.jar
  javac -verbose -d ../build/classes -classpath ${CP}  `find org -name "*.java"`

You would have to do a bit of work to get the above to work but if you really need to I know you could set it up. The placement of the Protege directory is a bit hard to explain and you would probably do this slightly differently.

Actually - embarrassingly enough - it turns out that there is a perfectly easy way to do this in ant. Add the verbose option to the javac task as follows:

     <javac srcdir = "${src}"
            destdir = "${classes}" 
            debug="on"
            verbose="on"
            includeAntRuntime="false">
       <classpath refid = "project.classpath"/>  
     </javac>

Hmm... that would have been a lot easier. With the -verbose option I could see what the compiler was doing right before it died:

...
[wrote ../build/classes/org/protege/editor/owl/ui/view/annotationproperty/AbstractOWLAnnotationPropertyViewComponent.class]
[checking org.protege.editor.owl.ui.view.annotationproperty.OWLAnnotationPropertyHierarchyViewComponent]
An exception has occurred in the compiler (1.5.0_16). 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.AssertionError
	at com.sun.tools.javac.comp.Lower.access(Lower.java:955)
	at com.sun.tools.javac.comp.Lower.access(Lower.java:1048)
	at com.sun.tools.javac.comp.Lower.makeOwnerThis(Lower.java:1379)
	at com.sun.tools.javac.comp.Lower.access(Lower.java:1019)

This pointed me to the OWLAnnotationPropertyHierarchyViewComponent class. I had no idea at this point whether the problem was really with the RDFXMLRenderingViewComponent class or the OWLAnnotationPropertyHierarchyViewComponent class. I knew I was on the right track when I emptied the OWLAnnotationPropertyHierarchyViewComponent class, added the minimal amount of code to get it to compile in the ide and then ran the ant script. The ant script was now able to compile the code! I was close! Then I did a binary search of changes through this class to narrow the problem. Even when I was down to the five lines of code that was causing the problem it took me a while before I figured out the fix. Of course the fix involved replacing some perfectly valid java code with a slightly rewritten version that did the exact same thing.

Hopefully knowing the sequence of steps will help you!