Bug 35436 - AntClassLoader returns false loader in getParent()
Summary: AntClassLoader returns false loader in getParent()
Status: RESOLVED FIXED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.7.0
Hardware: All All
: P2 normal (vote)
Target Milestone: 1.8.0
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks: 46759
  Show dependency tree
 
Reported: 2005-06-20 21:59 UTC by Rainer Noack
Modified: 2009-07-22 02:51 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Noack 2005-06-20 21:59:42 UTC
Calling getParent() on oata.AntClassLoader doesn't return the - expected - 
actual parent classloader but allways the SystemClassLoader.

The Reason is simple:
Parent-Property is immutuable in java.lang.ClassLoader and getParent() is 
final.
AntClassLoader has a local, mutuable parent property that can be set via 
setParent(ClassLoader).

However, there should be a way to get AntClassLoader's real parent loader.

I see two solutions:
1. Remove the local property and it's setter-method. Allow setting of the
   parent only in the constructors. Use ClassLoader's parent property.
   Advantages: IMHO, the cleanest solution.
   Disadvantages: Many build brakes.
   Fazit: Not usable
2. Provide a "special" getter like getRealParent()
   Advantages: works with existing environments.
   Disadvantages: such a shame
   Fazit: No better way !?

Any other idea?

Regards

Rainer
Comment 1 Peter Reilly 2006-09-03 16:44:27 UTC
This will be fixed in ant 1.7.
I have added a new constructor to set the parent
classloader and made all the other constructors
deprecated.

I have not converted all uses to use the new constructor
(since some of them do strange things), however I have
modifed the setParent() to use reflection to
attempt to set the private field of the super class to 
the new parent.
Comment 2 Peter Reilly 2006-09-05 13:15:46 UTC
The change had to be reverted as it did work
for java 1.4 and lower.

In java 5, ClassLoader.getResources() is protected,
in java 1.4, it is private.
Comment 3 Matt Benson 2006-09-05 14:01:33 UTC
(In reply to comment #2)
> The change had to be reverted as it did work
> for java 1.4 and lower.
> 
> In java 5, ClassLoader.getResources() is protected,
> in java 1.4, it is private.
> 

Can Dale Anson's "object rape" technique (see ac Variable task) be used here?
Comment 4 Peter Reilly 2006-09-05 14:34:45 UTC
No, one would have to change the class itself, not
the use of the class. Well.., we could do this, but
it would mess up the JDK rt.jar file.....

Users call classloader.getResources() to get the resources.
As ClassLoader.getResources() is final in java 1.4 (but not
in java 5), AntClassLoader cannot have a getResources() method.
It has to fake the getResources by not having a parent as seen
by ClassLoader.getResources(). 
Comment 5 Peter Reilly 2006-09-05 14:36:17 UTC
Opps, hit the wrong button... reopen
Comment 6 Stefan Bodewig 2009-02-23 05:18:36 UTC

*** This bug has been marked as a duplicate of bug 46759 ***
Comment 7 Stefan Bodewig 2009-07-22 02:51:53 UTC
the getResources issue is fixed in the Java5 case now.

I don't think we would achieve much by setting ClassLoader.parent since we'd still have to deal with parentFirst and setIsolated in a way incompatible with the base implementation.

In order to close this issue I've simply added a getConfiguredParent method in svn revision 796649