JDK-4061452 : (reflect) Should provide API for reflection of packages
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 1.1,1.2.0,1.3.0
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • OS: generic,windows_95
  • CPU: generic,x86
  • Submitted: 1997-06-25
  • Updated: 2013-05-15
Related Reports
Blocks :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
There is a notable omission in the current reflection API: packages.
There should be a class java.lang.reflect.Package with methods to
access a named package, and to iterate over the contents of a package.

This would be particularly useful inside JCK, where we are trying to verify the
contents of the standard Java packages, making sure that misguided licencees
do not try and add extra classes into the Java hierarchy.

===========================================================================
Another request from ###@###.###:

Is there any way to get a list of classes in a package?
If not, what is the point of the Package class?

A natural new package method would be:

Class[] Package.getClasses()

which would return a list of all the classes registered
in the Package.  

brian.klock@eng 1998-05-08
==========================================================================

Comments
EVALUATION Too late for 1.2, so making this a P5. anand.palaniswamy@Eng 1998-06-17 I agree the existing java.lang.Package class is rather lame. It would make sense to add a getClasses method to a Package, returning all classes currently loaded within the package. Related API changes might be a getSubPackages method, a getpackage() method in Class etc. However, this will not work the miracles that some of the requestors expect. In particular, we can only find classes that are loaded; we cannot plausibly search the universe (or even the disk, if there is a disk) for classes within the package. So I doubt if it addresses JCK needs. We should consider adding this functionality; but its utility is limited, so this must be balanced against the added bloat and run time cost. gilad.bracha@eng 2000-03-09
09-03-2000