JDK-6930076 : "null" can incorrectly appear in error message compiler.err.error.reading.file
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-02-25
  • Updated: 2011-10-07
  • Resolved: 2011-10-07
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 7 Other
7 b86Fixed OpenJDK6Fixed
Description
The following message has been seen in a test that was timing out

error: error reading /net/jano2.sfbay/export2/tl/ws-depot/7/repo.latest-pit/langtools/test/tools/javac/nio/compileTest/HelloPathWorld.java; null

Note the "null" at the end.  This is an error.

[The test is test/tools/javac/nio/compileTest/CompileTest.java]
Comments
EVALUATION The structure of the error message is indicative of this entry in the resource file: compiler.err.error.reading.file=\ error reading {0}; {1} Searching for the compiler sources for "error.reading.file" reveals 5 instances. In all cases, the usage is within catch (IOException e) { ... } In 4/5 cases, the second arg is e.getLocalizedMessage(). In the last case, the second arg is simply e. Since e cannot be null, we must have a case where e.getLocalizedMessage() is null. The default impl of getLocalizedMessage() returns getMessage(). As a result, in all cases, it is suggested that e.getLocalizedMessage() is used if not null, and e is used if e.getLocalizedMessage() is null.
26-02-2010