Re-examine ClassLoader.getPackage(s) methods

Daniel Fuchs daniel.fuchs at oracle.com
Tue Sep 29 09:02:21 UTC 2015


 > 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)?

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



More information about the jigsaw-dev mailing list