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

[Robert Field]

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:


	final
	abstract
	static
variable
	ignore - with or without message
or allow
	error (JShell or compiler)
	ignore - with or without message
method
	ignore - no message
or allow
	error (JShell)
or ...
	ignore - with or without message
class
	allow
	allow
	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...


Thoughts please!

-Robert