Superclasses for inline classes

[Brian Goetz]

I've been thinking about this, and gone around in circles a few times.  
The properties laid out here are understandable and easily checkable at 
both compile and run time.  (I might add "no synchronization", or at 
least "no synchronized methods".)

I agree that having some sort of class-level modifier gives this concept 
too much importance.  And normally, I would take the position that a 
property like this would have to appear in the declaration somewhere, to 
capture the fact that conformance to these properties is not merely 
accidental and subject to change tomorrow.  But, lately I've been 
questioning this.

Reasons to have some sort of indicator of "I am an initialization-free 
class":

  - Allows author to capture design intent
  - Allows compiler to type-check conformance to requirements, based on 
design intent
  - Propagates design intent into documentation, where subclasses can 
see that this is safe to extend

But it occurs to me that all of these are within the bounds of what 
_annotations_ are allowed to do; we did the same with 
`@FunctionalInterface` that, while not required, turns on additional 
compile-time type checking and documentation.

I am currently thinking that we can adopt Dan's rules at the language 
level, and have an annotation @InitializationFree, which: (a) declares 
intent to conform to the contract of initialization-freedom, (b) 
unleashes compile-time type checking for same, and (c) causes a blurb to 
be emitted into the Javadoc along the lines of "This is an 
initialization-free class" -- but that the language specification works 
entirely in terms of structural properties.  We can say that "inline 
classes may extend initialization-free inline classes", and be done.


Regardless of compile-time type checking, we will likely want to do the 
analysis and write the result into the classfile (e.g., an 
InitializationFree class attribute), which can be seen as a 
necessary-but-not-sufficient signal for the VM to allow the class to be 
used as a super for an inline class.  When we go to load a class with 
this attribute, we can verify that it actually conforms:

  - Fields: no fields
  - Constructors/initializers: no ctor/initializer
  - Class declaration: it is abstract, and its super is i-free
  - Synchronization: No methods have ACC_SYCHRONIZED

When we go to load an inline class, we check the i-free bit on the 
superclass.

None of these checks seem all that burdensome to the VM.

It does mean that dusty abstract classes need to be recompiled before 
they can be bases for inline classes, which, on balance, seems OK.

> Language model
>
> An inline class may extend another class, as long as the superclass has the following properties:
> - It has no instance fields
> - It has no constructors
> - It has no instance initializers
> - It is abstract* or Object
> - It extends another class with these properties
>
> Subtype polymorphism works the same for superclasses as it does for superinterfaces.
>
> (*Remi points out that we could drop the 'abstract' restriction, 
> meaning there may be identity instances of the superclass. Given the 
> restriction on fields, though, I'm struggling to envision a use case; 
> the consensus is that 'new Object()' is probably something we want to 
> *stop*  supporting.)
>
> Call a class that satisfies these constraints an "initialization-free class" (bikeshedding on this term is welcome!). Like an interface, its value set may include references to both inline class instances and identity class instances.
>
> We*do *not*  want the initialization-free property to be expressed as a class modifier—this feature is too obscure to deserve that much prominence, encouraging every class author to consider one more degree of freedom; and we don't want every class to have to manually opt in.
>
> But we*do*  need the initialization-free property to be part of the public information about the class. For example, the javadoc should say something like "this is an initialization-free class". Otherwise, it's impossible to tell the difference between, e.g., a class with no fields and a class with private fields.
>
> In the past, a Java class declaration that lacks a constructor always got a default constructor. In this model, however, an initialization-free class has no constructor at all. A 'super()' call directed at such a class is a no-op.