> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>, > "amber-spec-experts" > <amber-spec-experts@openjdk.java.net>, "joe darcy" <joe.da...@oracle.com> > Envoyé: Mercredi 4 Décembre 2019 15:46:01 > Objet: Re: Clarifying record reflective support
>> I pretty sure there is an item in Effective Java saying that It's bad >> practice >> to have a method that return null instead of an empty array. > This is true, but remember where this method lives — java.lang.Class. All the > other methods return null here. methods that returns an array in java.lang.Class: getAnnotatedInterfaces(), getAnnotations(), getAnnotationsByType(), getClasses(), getConstructors(), getDeclaredAnnotations(), getDeclaredAnnotationsBytType(), getDeclaredClasses(), getDeclaredConstructors(), getDeclaredFields(), getDeclaredMethods(), getEnumConstants(), getFields(), getGenericInterfaces(), getInterfaces(), getMethods(), getNestMembers(), getSigners(), getTypeParameters(). Two of them can return null, getEnumConstants() and getSigners(). > So if we were to do the new one “right”, now the poor users are in an _even > worse_ situation — some of the methods do the wrong thing — but not all of > them, and so the user has to keep it in their head to remember which is which! 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 ? > The lesser of evils here is to follow the convention established by previous > reflection methods, especially — as Maurizio pointed out — the name of the > method screams “don’t call me if you’re not a record.” Like getEnumConstants(), this is an argument i can agree upon. But during the scanning of the methods of java.lang.Class, i've discovered that describeConstable() already returns an Optional. So i vote for returning an Optional. I'm sure there is a quote from you somewhere saying that Optional is better than null. regards, Rémi
