RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

[Mandy Chung]

> On Nov 12, 2016, at 3:04 AM, forax at 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.chung at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "David M. Lloyd" <david.lloyd at redhat.com>, "core-libs-dev" <core-libs-dev at 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 <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