RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError
Mandy Chung
mandy.chung at oracle.com
Fri Nov 11 23:10:13 UTC 2016
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 <forax at 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.lloyd at redhat.com>
>> À: core-libs-dev at 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
More information about the core-libs-dev
mailing list