Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4278961

# error reporting and recovery issues in the new compiler



    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.2, 1.1.3, 1.2.0, 1.3.0
    • Fix Version/s: None
    • Component/s: tools
    • Labels:
    • Subcomponent:
    • CPU:
      generic, x86, sparc
    • OS:
      generic, solaris_2.5.1, windows_nt


      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)
          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

          test.java:6: Unresolved method
            symbol: foo(int)
            nearest: foo(int,java.lang.String)
          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


          Issue Links



              gafter Neal Gafter
              iris Iris Clark
              0 Vote for this issue
              0 Start watching this issue