JDK-8145466 : javac: No line numbers in compilation error
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u65
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-12-15
  • Updated: 2016-04-27
  • Resolved: 2015-12-22
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 8 JDK 9
8u101Fixed 9 b100Fixed
Description
On 8u65/8u66, the attached Test class shows javac displaying an error but not displaying line numbers associated with the error. 

example output : 

$/java/re/jdk/9/promoted/all/b94/binaries/solaris-sparcv9/bin/javac Test.java
error: incompatible types: possible lossy conversion from long to int
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

Would like the javac compiler to include a line number when it displays this error.
Comments
A fix that passes all tests and passes code review is available. I am exploring whether a slightly better solution can be arrived at. We will take a call early next week on what will be the final fix.
18-12-2015
Moe bad news; compiling this: class Bar { Bar(Object o) { } } class Foo { void test() { new Bar(null) { void g() { m(2L); } }; } void m(int i) { } } generates the following (wrong) message: Main.java:29: error: incompatible types: possible lossy conversion from long to int new Bar(null) { ^ Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output 1 error (note that the line in which the error is reported is wrong). Again the problem disappears when using -Xdiags:verbose)
16-12-2015
Simple test case: class Foo { void test() { new Object() { void g() { m(2L); } }; } void m(int i) { } }
16-12-2015
The rewriteDiagnostic logic should be rewritten as follows (Resolve.java: 4183) @Override public JCDiagnostic rewriteDiagnostic(JCDiagnostic.Factory diags, DiagnosticPosition preferedPos, DiagnosticSource preferredSource, DiagnosticType preferredKind, JCDiagnostic d) { JCDiagnostic cause = (JCDiagnostic)d.getArgs()[causeIndex]; DiagnosticPosition pos = d.getDiagnosticPosition(); if (pos == null) { pos = preferedPos; } return diags.create(preferredKind, preferredSource, pos, "prob.found.req", cause); } That is - if the position attached to the fragment is null (which can happen in some method lookups), the preferred position should be used instead, rather than blindly using the diagnostic pos (which, if null, leads to current problem).
16-12-2015
workaround: use the compiler flag -Xdiags:verbose. It's an issue in the error message simplification.
16-12-2015
Behavior verified in jdk9 with provided test case
16-12-2015
In JDK 9, the message comes from Check.java checkType, c. line 565 (possible.loss.of.precision) Code is locally the same in jdk8u http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/file/0caab0d65a04/src/share/classes/com/sun/tools/javac/comp/Check.java#l550 needs deeper investigation why pos is not set
16-12-2015