IdentityObject & abstract superclasses

[Dan Heidinga]

(Sorry for breaking the threading - with the email change I can't respond
directly to the original email)

> API features
>
> (Optionally) The method Class.Interfaces(), and similar reflection API
points, filters out IdentityObject when it is not explicitly named in the
class file.

Like Peter, I'm also concerned about filtering the IdentityObject interface
from the reflection api.  I understand there
are a lot of tests with assumptions on the number of interfaces returned by
these APIs and maybe even some
applications with runtime behaviour changes (?) due to this.

While it seems clever to filter it now - and it helps said tests & apps -
is that really the model we want in the future?
In 5 years is this going to be seen as the smart decision or another of the
"yesterday's solutions are today's problems"
variety?

I think treating the injected interface as consistently as possible with
non-injected ones provides the cleanest model
to build in the future.  It'll bring some hopefully short term pain but
save us from having to explain to every user
why this interface is special and only sometimes (injected vs declared)
returned by the API points.

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20200909/14555eb7/attachment.htm>