Re-examine ClassLoader.getPackage(s) methods

[Mandy Chung]

On Sep 29, 2015, at 2:02 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> > I now make @apiNote in CL::getPackage to @deprecated.
> 
> Hi Mandy, Alan,
> 
> Doesn't this leads to deprecate the method
> static Package.getPackage(String name) too - as this is
> based on CL.getPackage(String)?
> 

Good catch.  It should for the same reason as described in ClassLoader::getPackage.

Mandy

> best regards,
> 
> -- daniel
> 
> 
> 
> On 28/09/15 21:36, Mandy Chung wrote:
>> 
>> 
>> On 09/27/2015 01:29 AM, Alan Bateman wrote:
>>> 
>>> 
>>> On 26/09/2015 19:28, Mandy Chung wrote:
>>>>> On Sep 26, 2015, at 7:33 AM, Alan Bateman <Alan.Bateman at oracle.com>
>>>>> wrote:
>>>>> This looks good. I think I would lean more to deprecating getPackage
>>>>> as just too fragile and leads to difficult to diagnose bugs.
>>>> Are you also suggesting to deprecate ClassLoader::getPackages as well?
>>> The ordering of the elements in the array returned by CL::getPackages
>>> is not specified so I think that is okay. However
>>> CL#getPackage(String) is a significant hazard as the @apiNote explains
>>> so I think it could be a candidate to deprecate.
>> 
>> Thanks for clarifying this as I think no need to deprecate CL::getPackags.
>> 
>> Custom class loader implementation may likely call CL::getPackage before
>> calling definePackage to avoid IAE.  There isn't any issue filed
>> reporting the returned Package contains unexpected properties.   On the
>> other hand, now each class loader defines Package objects locally
>> without walking the class loader hierarchy, I agree that deprecating
>> CL::getPackage is the right thing.
>> 
>> I now make @apiNote in CL::getPackage to @deprecated.
>> 
>>      * @deprecated
>>      * If multiple class loaders delegate to each other and define classes
>>      * with the same package name, and one such loader relies on the
>> lookup
>>      * behavior of {@code getPackage} to return a {@code Package} from
>>      * a parent loader, then the properties exposed by the {@code Package}
>>      * may not be as expected in the rest of the program.
>>      * For example, the {@code Package} will only expose annotations
>> from the
>>      * {@code package-info.class} file defined by the parent loader,
>> even if
>>      * annotations exist in a {@code package-info.class} file defined by
>>      * a child loader.  Instead, use the {@link
>> ClassLoader#getDefinedPackage}
>>      * method which only returns a {@code Package} for the specified
>> class loader.
>>      *
>> 
>> Mandy
>