Hi Mandy, getName() is used for debugging so if it's the wrong name which is picked, is not a big deal, the stacktrace will be just a little weird, that's why i think it's fine to make getName non static and non final, because accidental overriding is not harmful.
Accidental overriding of isParallelCapable is harmful. In term of design the main issue with a static method is the discoverability issue, if a user hit ctrl + space, a static method will not be among the proposed methods. so i'm fine with a final isRegisteredAsParallelCapable if you think that users should be aware that this method exist. regards, Rémi ----- Mail original ----- > De: "Mandy Chung" <mandy.ch...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "David M. Lloyd" <david.ll...@redhat.com>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Samedi 12 Novembre 2016 00:10:13 > Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and > conflicting method may get VerifyError > While this could be made as a static method, there are cases that an instance > method would be preferred and same compatibility would arise. For example, > ClassLoader::getName is non-final instance method as it stands and I’d be > reluctant to make it a static method taking a ClassLoader instance. > > It would be nice to support @PromoteToFinalMethod to allow a new method be > non-final when it’s added and promote to a final method in a future release > allowing existing code to transition. > > My preference is to go with ClassLoader::isRegisteredAsParallelCapable final > instance method and the chance of the name clash may be low (Brent did some > search from grepcode and at least not finding that name yet. Of course this > is > not bullet-proof). > > Mandy > >> On Nov 11, 2016, at 9:13 AM, Remi Forax <fo...@univ-mlv.fr> wrote: >> >> Hi David, >> you can not override a static method :) >> but there is still a corner case, you can have a conflict when you have a >> method >> reference over an instance method and you introduce a static method that have >> the same functional signature. >> >> Given that i prefer to have a compile time error than a strange behavior at >> runtime (if there is an accidental overriding), >> I vote for the static method too. >> >> cheers, >> Rémi >> >> ----- Mail original ----- >>> De: "David M. Lloyd" <david.ll...@redhat.com> >>> À: core-libs-dev@openjdk.java.net >>> Envoyé: Vendredi 11 Novembre 2016 16:03:44 >>> Objet: Re: RFR 8169435 : ClassLoader.isParallelCapable is final and >>> conflicting >>> method may get VerifyError >> >>> On 11/11/2016 05:07 AM, Alan Bateman wrote: >>>> >>>> >>>> On 11/11/2016 10:46, Vladimir Ivanov wrote: >>>>> Alan, >>>>> >>>>> I've looked through the current thread and also review thread [1] for >>>>> original change (8165793), but haven't found any discussion why making >>>>> it static (instead of instance final) is undesirable. >>>>> >>>>> Can you shed some light on it? Is it mainly usability concern >>>>> (loader.isParallelCapable() vs ClassLoader.isParallelCapable(loader))? >>>> I assume you mean to address this to Brent rather than me, but yes, an >>>> instance method would be nicer (if we can get away with it). >>> >>> I think the question was "why not?". A static method can never >>> conflict, and doesn't have a usability impact. A final method can >>> always conflict, and a non-final method is always potentially >>> problematic for the multiple reasons already stated on this thread. >>> >>> By score, static wins. So, why not? >>> -- > >> - DML
