> On Nov 22, 2021, at 2:07 PM, Kevin Bourrillion <kev...@google.com> wrote:
>
>> On Mon, Nov 22, 2021 at 6:27 AM Dan Heidinga <heidi...@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.)
