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

JShell: Handling of top-level final, abstract, and static modifiers

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 16
    • Component/s: tools
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b15
    • CPU:
      generic
    • OS:
      generic

      Description

      Background: we need to support sealed types, for that we must allow classes to be final. Current behavior for top-level modifiers is that "final" and "static" are ignored, with a warning; "abstract" is an error for variables and methods; and "static" is ignored with a warning.

      It is guiding principle of JShell that as much pasted Java code should work. Additionally, unnecessary warnings are a distraction. Jan has pointed out some possibilities for improvement, as we investigate how the modifier changes are handled and implemented.

      Let's step back and look at the space...

      "final", "abstract", and "static" are the interesting cases. Let's look at the options:
          
      variable
          final: ignore with or without message or allow
          abstract: error (JShell or compiler)
          static: ignore with or without message
      method
          final: ignore without message or allow
          abstract: error (JShell) or ...
          static: ignore with or without message
      class
          final: allow
          abstract: allow
          static: ignore with or without message

      Case by case:

      abstract
      -----------

      variable: abstract is not allowed on variables in Java. Currently a JShell error is generated. Seems using the compiler error would be superior.

      method: there is no way to implement/override a top-level method and the top-level is implemented static, which can't be abstract, so generating an error kinda makes sense on that level. It can't be ignored, because there is no body. But in support of pasting code and allowing code to evolve, it could have a body generated for it that, if called, aborts with a message just as methods with an undefined identifier in the body behave. This is probably out of the immediate scope of this investigation.

      class: abstract classes must be and are allowed

      final
      ------

      variable: final variables have been ignore because it prohibits modifying the value -- which when exploring code is important. This is almost certainly overkill protective padding. It interferes with pasting, including constants. Allowing final seems the best option, as a new user can see the semantics. The declaration can always be overridden without the final. Ignoring without a message is another option, but this could confuse new users and also violates Java semantics.

      method: final methods have also been ignored with a warning, and that is just silly in retrospect. They can't be overridden, so there is no way observe the semantics. They should be allowed (or ignored with no warning, as that is equivalent).

      class: final classes haven't been allowed, again overly heavy-handed attempt to allow modification. And now, we must have final classes for sealed classes.

      static
      -------

      All definitions are implemented as static. They have been ignored with warning, on the fear that user's would attempt to ascribe meaning to them. My guess is the warning (esp. in a paste case) is more pain than value. And just confusing to a new user. Or...

      -------------

      Note: the "final" portion of this has been handled under JDK-8246353

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              rfield Robert Field
              Reporter:
              rfield Robert Field
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: