Re-examine ClassLoader.getPackage(s) methods

[Mandy Chung]

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