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
