New candidate JEP: 401: Primitive Objects (Preview)

[David Lloyd]

Are we completely sure that having every existing class suddenly implement
IdentityObject isn't going to break all kinds of reflection-based
frameworks?  I'd be very nervous about making a change like that.

Reinterpreting calls to `new Object()` seems like trouble to me as well;
it'd be downright bizarre to have `new Object().getClass() !=
Object.class`.  Making `Object` be special is just going to make the
language that much more awkward overall; I honestly can't imagine the
tradeoffs that made this seem like a good idea in comparison.

I'm surprised that adding these special cases would be preferable to having
primitive types be isolated to their own space (i.e. not extending Object)
or other options.  For example, by having an isolated root primitive class
analog to Object (with a box type extending Object directly), and requiring
any base abstract types to extend that class, the existing language
behaviors would not have to change AFAICT.  Primitive classes would be much
easier to recognize.  Primitive base classes could even have state.  What
critical use case did such a design inhibit?  Where were such decisions
documented?

Historically, I personally have failed to understand how these kinds of
language-level enhancements balance preserving consistent and simple
behavior with enabling specific use cases in certain ways; from the outside
it seems very ad-hoc (retroactively updating requirements to adhere to new
design ideas).  I wish there were some better way to have this be
communicated through the life of a project.  In the case of valhalla, it
seems that new requirements have arisen (and some old requirements have
been invalidated) over time/iterations, but unless one follows the project
discussion from the absolute beginning and keeps careful notes throughout
(and is privy to what appear to be possibly non-public design discussions),
apart from occasional big-document drops and actually building prototypes,
there really seems to be no way to understand what the total set of
requirements of the final iteration actually are, or what design
considerations went into it.  Is this something that can be improved
somehow?  It would be nice to see, for exampe, a living document with use
cases (including use cases that are later rejected) which map to goals and
requirements, that could be updated after each design decision.  Even if
many of the use cases are along the lines of "we want this user experience"
in the form of "here is some syntax we'd like users to be able to use, with
justifications", this would be really nice to maintain publicly in a simple
living document.  It would, for example, provide a nice and simple way for
news media to inform users about the project progress.  All the better if
changes for the document could be managed publicly somehow (GitHub pull
requests for example).

If nothing else, something like this might help mitigate the inevitably
repetitive user-level questions that are associated with substantial
changes.  At best, it avoids the major change "bomb drop" - which IMO
leaves the user base with the impression that they have no choice but to
accept these kinds of changes - and gives users more of a reason to look
forward to a change, with *more* of a possibility of accurate expectations.

I'm not saying *nothing* was done on this effort but the end impression for
me is that the process resulting in this design has been substantially more
obscure than, say, the process of designing pattern-matching switch
statements, which seems much more accessible to users.  For such important
changes, wouldn't it be good to have a more consistent and public process
for communication?


On Wed, Mar 17, 2021 at 4:50 PM <mark.reinhold at oracle.com> wrote:

> https://openjdk.java.net/jeps/401
>
>   Summary: Enhance the Java object model with user-declared primitive
>   objects, which are class instances that lack object identity
>   and can be stored and passed directly, without object headers or
>   indirections. This is a preview language and VM feature.
>
> - Mark
>
>

-- 
- DML • he/him