On Sep 29, 2015, at 2:02 AM, Daniel Fuchs <[email protected]> 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 <[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 >
