JDK-7036255 : javac crashes when a specific system option is set
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6u25
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2011-04-13
  • Updated: 2011-05-02
  • Resolved: 2011-04-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u25 b06Fixed
Related Reports
Relates :  
JDK-6625520 - javac handles missing entries on classpath badly
Relates :  
JDK-6999460 - Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux
Description
When compiling using the useJavaUtilZip=true system option (that disables caching of the zip file indices in memory), the 6u25 javac crashes:
$ ./jdk1.6.0_25/bin/javac -J-DuseJavaUtilZip=true Test.java
error: error reading /tmp/jdk1.6.0_25/jre/lib/sunrsasign.jar; error in opening zip file
1 error

The javac version is:
$ ./jdk1.6.0_25/bin/javac -fullversion
javac full version "1.6.0_25-b05"

NetBeans is using this system option to prevent leaking memory through the zip file index cache: when a project is built inside NetBeans, the javac is run in the same VM to speed-up the building of small projects.
Comments
EVALUATION This problem exists on Linux and Solaris. On Windows new ZipFile(...) does throw a FileNotFoundException.
14-04-2011
SUGGESTED FIX The fix is the same as shown in 6625520: } catch (IOException ex) { >>>>>>>>>>> if (zipFileName.exists()) log.error("error.reading.file", zipFileName, ex.getLocalizedMessage()); archive = new MissingArchive(zipFileName); }
13-04-2011
EVALUATION As Jon pointed out in the comment, the problem is the openArchive method in DefaultFileManager.java. It does this: try { : if (!useZipFileIndex) { zdir = new ZipFile(zipFileName); } : } catch (FileNotFoundException ex) { archive = new MissingArchive(zipFileName); } catch (IOException ex) { log.error("error.reading.file", zipFileName, ex.getLocalizedMessage()); archive = new MissingArchive(zipFileName); } The problem is that new ZipFile(...) doesn't throw a FileNotFoundException if the file does not exist, instead, it throws a java.util.zip.ZipException, so that the log.error is executed.
13-04-2011