Community
Participate
Working Groups
BETA_JAVA8 top of branch. (1) The following program does not elicit an error message at the moment, when compiled as a 1.7- project. It should be rejected with a message that reads "Default methods are available only at source level 1.8 or above" // ----- interface I { public void foo() default { System.out.println("Place holder"); } } // ----- (2) The following program while compiled as a 1.7- project triggers three error messages: // --- class X { X x = () -> 10; } // ---- - Syntax error on token ")", invalid TypeElidedFormalParameter - Syntax error, insert "ElidedSemicolonAndRightBrace" to complete LambdaBody - Syntax error, insert ")" to complete Expression. It should emit a single error message saying "Lambda expressions are available only at source level 1.8 or above" (3) The following program should be rejected at 1.7-, but is not at the moment: // --- class X { X x = System::exit; } // ---- (4) The following program generates the message "Syntax error on token COLON_COLON, delete this token", it should instead complain that "Reference expressions are available only at source level 1.8 or above" (2) & (4) are a bit tricky in that, at source levels 1.7-, for performance reasons we don't look ahead in the token stream to disambiguate between the different uses of the tokens '(' and '<'. That means that we don't build a parse subtree for these constructs at 1.7- levels. So the parser will see a badly mangled program and that could result in a slew of errors as in case (2) above. One strategy is to recognize the operators '::' and '->' which are returned as tokens at any source level and issue the "available at source level 1.8+" messages upon encountering these tokens. In order to make sure that this message is not drowned in a flurry of others, we may want to experiment with tossing out all other problem markers if any of these tokens are seen and complained against.
bug 383714 has been raised for the correctness issues i.e for (1) and (3) from comment#0, while the current bug is retained only for the quality of diagnostics: i.e (2) and (4) from comment#0. (In reply to comment #0) > (4) The following program generates the message "Syntax error on token > COLON_COLON, delete this token", it should instead complain that > "Reference expressions are available only at source level 1.8 or above" Here is the program that was supposed to follow: interface I { void foo(int p); } public class X<T> { I i = X<String>::foo; public static void foo(int p) { } }
(In reply to comment #0) > One strategy is to recognize the operators '::' and '->' which are > returned as tokens at any source level and issue the "available at > source level 1.8+" messages upon encountering these tokens. In order > to make sure that this message is not drowned in a flurry of others, > we may want to experiment with tossing out all other problem markers > if any of these tokens are seen and complained against. IIRC this is also the strategy we followed for java 7 constructs like diamond.
(In reply to comment #2) > (In reply to comment #0) > > One strategy is to recognize the operators '::' and '->' which are > > returned as tokens at any source level and issue the "available at > > source level 1.8+" messages upon encountering these tokens. In order > > to make sure that this message is not drowned in a flurry of others, > > we may want to experiment with tossing out all other problem markers > > if any of these tokens are seen and complained against. > > IIRC this is also the strategy we followed for java 7 constructs like diamond. I can't exactly see this for diamond (which isn't a single token). Did you perhaps mean handling of number syntax where we see things like this in Scanner.scanNumber()? if (this.sourceLevel < ClassFileConstants.JDK1_7) { throw new InvalidInputException(BINARY_LITERAL_NOT_BELOW_17); }
(In reply to comment #3) > Did you perhaps mean handling of number syntax where we see things like this > in Scanner.scanNumber()? > > if (this.sourceLevel < ClassFileConstants.JDK1_7) { > throw new InvalidInputException(BINARY_LITERAL_NOT_BELOW_17); > } Likely. Except that in this case, the remaining syntax errors from the same file are not discarded. Is there consensus on the value of discarding the other syntax errors ? Or should we just stick to issuing a NotBelow18 message and let the user pick that and apply a quick fix ?
(In reply to comment #4) > Or should we just stick to issuing a NotBelow18 message and let the user > pick that and apply a quick fix ? This is better, since sometimes I want to let errors in a far away line remain while i focus on the immediate work i'm doing in the editor.
(In reply to comment #5) > (In reply to comment #4) > > Or should we just stick to issuing a NotBelow18 message and let the user > > pick that and apply a quick fix ? > This is better, since sometimes I want to let errors in a far away line remain > while i focus on the immediate work i'm doing in the editor. That is even when closer to home we have a flurry of messages of dubious value ? e.g case (2) in comment#0 ? Basically program structure is FUBAR when a lambda is not recognized as a lambda. Also note that early experiments are pointing to near zero degradation in running the scanner in a always-look-ahead mode - much to my surprise.
It all depends on the recovery and the scope in which errors are discarded. If the compiler can still recover top-level types and body declarations, then I wouldn't want it to hide problems in other methods just because I wrote '->' in one place. But if a method body has a syntax error and it looks like a 1.8 construct, then I'm OK with dropping other errors in that method. Multi-page monster methods are not something we should consider specially. If you can confirm the near zero degradation in always-look-ahead mode, then that would be the best. IMO, the BETA_JAVA8 compiler should optimize performance for 1.8 code. I would accept a slight regression for older versions if this improves error reporting.
(In reply to comment #7) > It all depends on the recovery and the scope in which errors are discarded. If > the compiler can still recover top-level types and body declarations, then I > wouldn't want it to hide problems in other methods just because I wrote '->' in > one place. > > But if a method body has a syntax error and it looks like a 1.8 construct, then > I'm OK with dropping other errors in that method. Multi-page monster methods > are not something we should consider specially. Good points. BTW, I am not aware if there is a way to arrange so that problems of certain types bubble up to the top of the view automatically - is this possible ?
> ...a way to arrange so that problems of certain types bubble up to the top... Not directly. The Problems view has two mechanisms to arrange problems, see the view menu: - "Group By > Java Problem Type" shows Fatal Errors on top, so it does boost all syntax errors. - "Sort By > Description" first sorts by severity, then by description. However, errors initially only show up in the editor and only appear in the Problems view after a save/rebuild operation.
This is fixed automatically by the new look ahead policy implemented via the fix for bug 383378. Test released via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=4e141be8003d1ef09b5a958dd38e851de76be5f5
