Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6865375

(cl) Request ClassLoader.getResourcePairs(String) => Enumeration<(ClassLoader,URL)>



    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 5.0
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:


      There are various situations where calling ClassLoader.getResources is unsatisfactory. The problem is that the returned "flattened" enumeration gives no hint which ancestor loader was the defining loader for a given element: unlike a Class which has a getClassLoader() method, a URL tells you nothing more than how to open it.

      A particularly nasty consequence is when you try to load a class given by name in a resource. Several difficult problems can arise:

      1. The initial loader might not be able to load this class even though an ancestor can, for whatever reason (e.g. cross-module API visibility rules).

      2. In a multiply-parented loader, there might be several ancestors which can all load a class of the same name, and which independently mention that class in a resource. Trying to load the class through the initial loader could produce an error or an arbitrary and incorrect result, such as one ancestor being used twice while another defining ancestor is not used at all.

      3. An supertype to which the instantiated class is expected to be assignable might be defined differently in some ancestor. This can usually be worked around by doing an explicit checkcast on the implementation class.

      Suggest a method which would return a list of pairs of class loader and resource.

      Some examples of where this would be useful:


      gets a list of URLs from an unknown class loader hierarchy but has no way of knowing what loader produced a given element. Since each such resource is associated with some Java classes that need to be loaded, it is necessary to just guess that the class can be loaded via an initiating class loader.


      has a similar problem. In fact java.util.ServiceLoader suffers from this problem, as corrected in the supplied patch.

      Bug #6723276 gives a different example. See comment #1 under Suggested Fix.


      also alludes to problems with getResource* returning URL rather than some richer type. It is not clear from that message what the suggested API would be.


          Issue Links



              Unassigned Unassigned
              jglick Jesse Glick (Inactive)
              0 Vote for this issue
              1 Start watching this issue