> On Nov 12, 2016, at 3:04 AM, fo...@univ-mlv.fr wrote: > > 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. >
That’s a good point. > 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. > I am doing a scan on the corpus I have (an old snapshot of maven artifacts outdated but hope to represent a good set of samples). So far, I only found one ClassLoader subclass defining isParallelCapable method [1]. I haven’t found any use of isRegisteredAsParallelCapable method. Mandy [1] org.eclipse.osgi:org.eclipse.osgi:3.7.1 (and other versions) > 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
