JDK-4834690 : javac generates fewer class files than it could on errors
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2003-03-19
  • Updated: 2022-03-02
  • Resolved: 2022-03-02
Related Reports
Relates :  
JDK-6420151 - need to improve byfile compile policy to eliminate footprint issues
Description
Name: gm110360			Date: 03/19/2003


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


FULL OS VERSION :
Linux release.eventmonitor.com 2.4.18-3smp #1 SMP Thu Apr 18 06:59:55 EDT 2002 i686 unknown


A DESCRIPTION OF THE PROBLEM :
javac only generates class files until it finds the first incorrect .java file.  After this, it does not generate any .class files, even for correct .java files.

This means that if I compile 1000 .java files and only one file has an error, I might get 999 class files or 0 class files or anywhere in between.  If the one bad file is the third parsed, I will get 998 class files.  But javac will do the work to parse and verify 999 correct java files.  It just won't do me the favor of saving that work, so I have to do it again the next time.  And the next, until I get all errors out.

This slows down my compile/edit/debug cycle, and wastes computer time as well.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
compile three class files, one of which has an error.  If that file is processed first, no class files will be produced.  If it is processed second, one class file (for the first class) will be produced.  If it is processed third, two class files will be produced.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Following my "Steps to Reproduce", two class files will be produced, no matter what order the classes are processed in.
(see "Steps to Reproduce")

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 182663) 
======================================================================
Comments
EVALUATION Once the compiler encounters an error, it populates its symbol table with error entries to suppress cascaded diagnostics. Consequently, it cannot tell which of the subsequently compiled modules depend or do not depend on erroneous sources. Trying to track this would slow down the compiler. ###@###.### 2003-03-19 I'm reopening this one. When semantic errors occur in the bodies of methods only, there is no reason to suppress any classes other than the containing class. ###@###.### 2004-01-06 With the internal rewrite of JavaCompiler.compile, it would be reasonable to change selected tests for (errorCount() > 0) to (errorCount() > prevErrorCount) for some appropriate definite of prevErrorCount. Then, assuming we get past Attr OK (which is the core of Neal's initial concern above), we should be able to be more tolerant of downstream errors, if we so choose to do. ###@###.### 2005-06-28 18:36:36 GMT
28-06-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
17-07-2004
PUBLIC COMMENTS ...
17-07-2004