1. When a declaration is disallowed due to a conflicting declaration in an
    enclosing scope, in subsequent processing after the diagnostic, should the
    declaration be considered to take effect?
  
    See regression test test/tools/javac/NestedInnerClassNames.java.

    Error reported?
        1.2.2 -- yes
        1.3 -- no

2. Consider the following:

class Foo {
class Bar {
static final x;
...
x = 1;
}
}

    A static final variable is allowed in an inner class only when
    it is initialized by a constant expression. Both compilers
    correctly diagnose this. Do we then consider the declaration
    to be an ill-formed blank final declaration? Or do we consider
    it to be an attempt to define a manifest constant in which the
    required initializing expression has been omitted? GJC takes
    the latter position, and reports an error at the assignment.
    This is slightly misleading, because no value has previously
    been assigned -- we have simply assumed such an assignment as
    part of the error recovery.

    See regression test test/tools/javac/InnerNamedConstant_2.java.
    Error reported?
        1.2.2 -- no
        1.3 -- yes

3. "empty package" vs. "unnamed package" terminology in the error message.
    The 1.3 compiler uses "empty package" when perhaps "unnamed package" would
    be more appropriate.

    See regression test test/tools/javac/NestedInnerClassNames.java.

4. The following error would be clearer if it were diagnosed as two
    separate errors, one for each argument:

    Cryptique.java:16: testFunction(java.lang.Object[],java.lang.Object[]) in Cryptique cannot be applied to (Array,Array)
            testFunction (test, numbers) ;
            ^
    The old compiler gives a somewhat appropriate message, but fails to note
    that both arguments are in error:

    Cryptique.java:16: Incompatible type for method. Can't convert int[] to java.lang.Object[].
            testFunction (test, numbers) ;
                                ^
    See bug 4278250.

5. In the case of an instance initializer, checked exceptions must be declared
    in the throws clauses of the *constructors*. Should we mention this?

    B.java:5: unreported exception java.lang.Exception; must be caught or declared
    to be thrown
            { throw new Exception(); }

    See bug 4052099.

6. Unresolved method errors are not reported in the most informative way.
    For example:

    foo(int,java.lang.String) in test cannot be applied to (int)
        foo(3);
        ^
    In the case that a method of the name exists, but the parameter
    signatures do not match, it would be helpful to list one more more
    candidates:

    test.java:6: Unresolved method
      symbol: foo(int)
      nearest: foo(int,java.lang.String)
      foo(3);
      ^
    See also 4278250.

7. Bad error message for long array index. It would be more helpful to
    inform the user that the index type must be int (or smaller).

$ jdk13; javac lex00001.java
lex00001.java:9: possible loss of precision
found : long
required: int
long[] ia = new long[5L];
                       ^
lex00001.java:10: possible loss of precision
found : long
required: int
ia[5L] = 5L;
^

    There is also a possible bug in the example above -- I believe that
    a cast is required, and the above program contains a type error.
    See 1263909.

8. Modifiers on local classes should be cleanly diagnosed. Instead,
    we try to parse an expression and fail.

    See 4015400.

9. Assignments to final paramters are badly diagnosed:

class xxx {
void f(final int x) {
x = 1;
}
}

xxx.java:3: variable x might already have been assigned to
x = 1;
             ^
1 error

    Should say:
xxx.java:3: Can't assign a value to a final parameter: x

    See 4277335.

10. When a superclass constructor has a non-empty throws clause,
    subclasses must define an explicit constructor with an
    appropriate throws clause, as a default constructor has
    no throws clause. (This is stated in JLS 2e 8.8.7, ruling
    out the other alternative of copying the superclass
    constructor's throws clause.

    Currently, the compiler generates a default constructor
    with an empty throws clause, and then generates an error
    message. Unfortunately, the offending call, the implicit
    call to the superclass constructor, does not appear in the
    program text, so the message is confusing.

    See 4071337.

11. The compiler should diagnose package declarations that do
    not agree with the sourcefile path. See 4032273 for an example
    where the compiler does not.

12. In the event of a duplicate declaration error, what declaration
    should be considered to take effect? The compiler appears to use
    a dummy declaration. Should probably be public. See 4032273 for
    evidence that it is not.

13. If an anonymous class is instantiated using the unqualified form
    of the 'new' construct, an implicit reference to 'this' (the current
    instance) is generated. It is thus an error to perform such an
    instantiation in a static context, where no current instance is
    available. The error message issued in this case is confusing, because
    users are often confused enough by anonymous classes themselves that
    they are not aware of the implicit reference. See 4160104.

14. In some cases, an error message may be emitted which attempts to
    display the name of an anonymous class, yielding a garbled message:

    AnonBug.java:7: methodC3(int) in cannot be applied to ()
                   methodC3(); // ERROR
                   ^

    The class containing methodC3(int) is an anonymous class.
    See 4060696 for the code example.

15. When a return statement is required in a method, but not
    provided, the diagnostic points to the opening brace, which
    may not be on the same line as the method name. The pointer
    should either point to the method name, or the message should
    contain the name of the method (as done by the old compiler).

16. In the following type of error message:

    Test.java:7: method() in Test cannot implement method() in Interface;
attempting to assign weaker access privileges; was public
    public class Test
         ^

    it would be helpful if the compiler reported the line number of the
    declaration of the method instead of the line number of the class.
    See 4413454