Conor, I'm not sure I understand (bear with me as I'm quite new with CL :-)). My understanding is that there is a hierarchy in CL : there is a parent and there are children CL. When a children CL is asked to load a class, it looks first if it can find it. If it cannot it delegates the load to its parent classloader. Up until the system classloader.
This seems a sensible strategy and I don't see how you could end up with 2 different instances of the same class ? (unless you don't use this strategy everywhere ?). Thanks -Vincent > -----Original Message----- > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > Sent: 28 February 2002 10:43 > To: Ant Developers List > Subject: Re: Taskdef Classloader change (was RE: Custom Ant tasks and > classpath issue) > > Vincent Massol wrote: > > > Ah ok. Thanks Stefan for the clarification. Is that the way we want Ant > > to operate ? Don't you think it would be better if the "reverseloader" > > mode was the default one. It would be backward compatible in all cases > > except for persons like who were counting on their classpath was being > > picked before the system classpath. > > > > I do agree, it is not nice to have my jar in both places. It wasn't > > actually meant that way. I had just dropped my cactus-ant.jar in > > anthome/lib a long time ago for some quick test I did ... and had > > forgotten about it ... until 3 months later I had to change one task ... > > > > I think it is safer to load the user classpath before the system > > classpath, making the user classloader a child of the system > > classloader. > > > > What do you think ? > > > Vincent, > > This is nice in theory but dangerous in practice. If you don't delegate > to the parent loader it is possible to end up loading two different > instances of the same class. Sometimes that is OK but sometimes, when > there is an indirect relationship between the two classes, the JVM will > complain and throw a LinkageError. the circumstances under which this > happens are complicated and are enforced by a set of "loader > constraints". It is part of the mechanism implemented in Java to ensure > type safety. > > Conor > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
