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

javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure.

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 11
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      Hide
      Some API clients (esp. annotation processors) may be written to expect the CompletionFailure. As this wasn't specified and depended on the context, it is likely many of them will already contain code to cope with the new situation, and it should be fairly simple to fix those that currently rely on the CompletionFailure.
      Show
      Some API clients (esp. annotation processors) may be written to expect the CompletionFailure. As this wasn't specified and depended on the context, it is likely many of them will already contain code to cope with the new situation, and it should be fairly simple to fix those that currently rely on the CompletionFailure.
    • Interface Kind:
      Java API

      Description

      Summary

      javax.lang.model API methods should no longer throw a javac-internal CompletionFailure exception.

      Problem

      When javac internally reports missing classes using a CompletionFailure exception. This is an internal javac exception, that is not part of the APIs. Sadly, this exception may sometimes be thrown out from an API method to an API client. E.g. when an API client gets a TypeMirror by calling TypeElement.getSuperclass() for some TypeElement whose superclass is missing, this may lead to several different behaviors depending on the exact circumstances:

      1. a DECLARED type, that will throw a CompletionFailure (once) at some point if used (e.g. when converted to Element and then invoking getKind() on that Element)
      2. a DECLARED type that will not throw a CompletionFailure (because it was already thrown either inside javac code or in an API client that have caught the exception)
      3. an ERROR type (if the reference to the missing class appeared in the source file)

      Handling all these cases appears to be troublesome to the API clients. Moreover, as javac's error reporting depends on these exceptions, if the API client catches the exception, javac may miss an error report, which can lead to various breakages, e.g. javac crashes.

      Solution

      The CompletionFailure is not thrown out of the API methods when API client is invoking them. TypeMirrors for representing missing classes should behave as ErrorTypes.

      Specification

      No API specification change. The behavior changes to be close to variant "3" from the list of possibilities in the Problem section. Variants "1" and "2" shall not happen. javac reports errors properly even in presence of API clients.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jlahoda Jan Lahoda
                Reporter:
                ksrini Kumar Srinivasan
                Reviewed By:
                Jonathan Gibbons
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: