ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Neward" <tnew...@javageeks.com>
Subject RE: [PROPOSAL] No need for CLASSPATH in ANT1
Date Sun, 11 Nov 2001 23:38:08 GMT
If you want to be *really* technical about it, the example

> URLClassLoader classLoader = new URLClassLoader( myURLs );
> 
> where they would need to do something like
> 
> URLClassLoader classLoader = new URLClassLoader( myURLs, 
>             this.getClass().getClassLoader() );
> 

really highlights a bug in the Java Class Libraries, and isn't an Ant-specific problem whatsoever--the
default "parent" argument is always the System ClassLoader (the sun.misc.AppClassLoader),
when it should be the ClassLoader of the class that's executing the current call (getCallerClassLoader()).

Jose, if you're particularly bothered by this bug, I'd suggest you take it up with Sun--THAT's
what would fix the problem.

Ted Neward
{.NET||Java} Course Author & Instructor
DevelopMentor (http://www.develop.com)
http://www.javageeks.com/tneward/index.html

> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Tuesday, November 06, 2001 5:49 PM
> To: Ant Developers List
> Subject: Re: [PROPOSAL] No need for CLASSPATH in ANT1
> 
> 
> On Wed, 7 Nov 2001 09:34, Jose Alberto Fernandez wrote:
> > From: "Glenn McAllister" <glenn@somanetworks.com>
> >
> > > Jose Alberto Fernandez wrote:
> > > > From: "Peter Donald" <donaldp@apache.org>
> > > >
> > > > > The problem was that it is not backwards compatible and 
> several tasks
> > > > > make the assumption that the system classloader contains the ant
> > > > > classes. Hence we can't really implement it in Ant1.
> > > >
> > > > No offence, but isn't is possible to modify the offending tasks?
> > > >  What was insurmountable about it?
> > >
> > > Of course its possible for us to change our tasks.  But what 
> about custom
> > > tasks? We've made a reasonable commitment to break as little 
> as possible
> > > before Ant 2. If we change something as potentially 
> fundamental as that,
> > > we could break a lot of people.
> >
> > What kind of tasks are we talking about. Can someone explain?
> > As far as I know, there is nothing in ANT1's API that can be 
> thought to be
> > guaranteeing that classes must be loaded from the CLASSPATH.
> 
> Most tasks that need to create their own ClassLoaders will do 
> something like
> 
> URLClassLoader classLoader = new URLClassLoader( myURLs );
> 
> where they would need to do something like
> 
> URLClassLoader classLoader = new URLClassLoader( myURLs, 
>             this.getClass().getClassLoader() );
> 
> if they wanted the ant runtime classes to be included in 
> classLoader (which 
> many do need). It would not be a good idea to break all tasks that create 
> their own classloaders (many of which do)..
> 
> > That is make quite clear by the public entrypoint
> > org.apache.tools.ant.Main.start() which it is there so that things like
> > GUIs can provide their own ClassLoader when invoking ANT1. Given that it
> > has been there since from at least 3 releases I would argue 
> that any task
> > making CLASSPATH assumptions contins bugs and needs to be fixed.
> 
> has nothing to do with the entry point.
> 
> -- 
> Cheers,
> 
> Pete
> 
> "Artists can color the sky red because they know it's blue.  
> Those of us who
>  aren't artists must color things the way they really are or people might 
>  think we're stupid." -- Jules Feiffer 
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message