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 <[email protected]>
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
