[External] : Re: EG meeting, 2021-11-17

[Dan Smith]

> On Nov 22, 2021, at 2:07 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
>> On Mon, Nov 22, 2021 at 6:27 AM Dan Heidinga <heidinga at redhat.com> wrote:
>> 
>> I'll echo Brian's comment that I'd like to understand Kevin's use
>> cases better to see if there's something we're missing in the design /
>> a major use case that isn't being addressed that will cause useer
>> confusion / pain.
>> 
> Sorry if I threw another wrench here!
> 
> What I'm raising is only the wish that users can reasonably default to B2-over-B1 unless their use case requires something on our list of "only B1 does this". And that list can be however long it needs to be, just hopefully no longer. That's probably how we were looking at it already.

Here's the current list, FYI (derived from JEP 401):

	• Implicitly final class, cannot be extended.
	• All instance fields are implicitly final, so must be assigned exactly once by constructors or initializers, and cannot be assigned outside of a constructor or initializer.
	• The class does not implement—directly or indirectly—IdentityObject. This implies that the superclass is either Object or a stateless abstract class.
	• No constructor makes a super constructor call. Instance creation will occur without executing any superclass initialization code.
	• No instance methods are declared synchronized.
	• (Possibly) The class does not implement Cloneable or declare a clone()method.
	• (Possibly) The class does not declare a finalize() method.
	• (Possibly) The constructor does not make use of this except to set the fields in the constructor body, or perhaps after all fields are definitely assigned.

And elaborating on IdentityObject & stateless abstract classes:

An abstract class can be declared to implement either IdentityObject or ValueObject; or, if it declares a field, an instance initializer, a non-empty constructor, or a synchronized method, it implicitly implements IdentityObject (perhaps with a warning). Otherwise, the abstract class extends neither interface and can be extended by both kinds of concrete classes.

(Such a "both kinds" abstract class has its ACC_PRIM_SUPER—name to be changed—flag set in the class file, along with an <init> method for identity classes.)