Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5011101

(main) Premature generation of class file fools javac dependency checker later

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Won't Fix
    • Icon: P4 P4
    • None
    • 6
    • tools
    • x86
    • linux

      Name: jl125535 Date: 03/10/2004


      FULL PRODUCT VERSION :
      java version "1.4.1"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
      Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

      java version "1.5.0-beta2"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b41)
      Java HotSpot(TM) Client VM (build 1.5.0-beta2-b41, mixed mode)

      A DESCRIPTION OF THE PROBLEM :
      Given these files:

      BadFile.java (will not compile):

       public class BadFile {
           static TestFile test;

           static public void main(String args[]) {
               throw new java.io.IOException();
           }
       }

      TestFile.java:

       public class TestFile extends BadFile {
          static OtherClass other;
          static OtherPublic other2;
       }

       class OtherClass extends BadFile { }

      OtherPublic.java:

       public class OtherPublic { }

      The command "javac TestFile.java OtherPublic.java BadFile.java" will generate TestFile.class and nothing else. This means that TestFile.class is now newer than TestFile.java, so if the error is removed from BadFile.java and only BadFile is recompiled ("javac BadFile.java"), OtherClass.class will not be generated, even though it is required and would be generated if TestFile.class had not been generated. Furthermore, OtherPublic.class is also not generated in this situation, even though it, too, is required by TestFile and would normally be generated.

      This causes a similar problem with ant, which has no idea that there are missing non-public classes, although ant will recompile any file whose public class has not been generated, so it does not lack OtherPublic.class

      Note that this does not happen if the error is an import not found or a syntax error.

      STEPS TO REPRODUCE BEHAVIOR :
      1. javac TestFile.java OtherPublic.java BadFile.java
      2. Correct the mistake in BadFile.java
      3. javac BadFile.java

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      TestFile.class should not be generated by step 1.

      A public class file should only be generated if it would lead to the correct behaviour of the javac dependency checking mechanism: all of the classes which it depends on have been generated, and all of the classes in the same source file have been generated.

      ACTUAL -
      TestFile.class is generated by step 1.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      CUSTOMER SUBMITTED WORKAROUND :
      If all .class files are removed or all source files are listed on the javac command line, the next build will be correct (but slow).

      If make is used with a sufficiently clever tool to determine the dependencies (e.g., gcj), it is possible to get conservative builds which are correct.
      (Incident Review ID: 185671)
      ======================================================================
      ###@###.### 10/26/04 06:06 GMT

            jjg Jonathan Gibbons
            jleesunw Jon Lee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: