Clarifying record reflective support

[Brian Goetz]

Short answer: nope.

> You are already describing the current situation, we already have methods that returns null (wrong),
> but not all of them so why add a new one ?

Heh, this is a “high school debate team” sort of argument — it amounts to “there is already an inconsistency in the world, so we can do whatever we want now.”  Nope.

> 
> But during the scanning of the methods of java.lang.Class, i've discovered that describeConstable() already returns an Optional.

This is even worse!  You know full well that describeConstable is not a method of reflection, it’s a method from the constants API that happens to be implemented by Class.  So, nice try.  

> So i vote for returning an Optional. I'm sure there is a quote from you somewhere saying that Optional is better than null.

Yes, when writing new code.  The considerations for extending a class like Class, though, are completely different.  Because Class will span the entire history of Java, we don’t want to make it look like an archaeological dig of Java API design techniques through the ages!  

The right thing to do here is to ask “What would Java 1.0 do”, and do that, because Class has already set its API principles, and we don’t want to ask users to remember which methods work which way.

(We have the same problem with exceptions; arguably calling getRecordComponents when its preconditions don’t hold could also merit an exception.  But again, Class is full of situations where it returns null instead, so even though an exception is arguably better, we will respect the API design precedent set by previous iterations, for the sake of not asking users to reason about six generations of API design idioms in one class.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191204/60f31416/attachment.html>