ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: having datatypes load classes
Date Thu, 10 Apr 2003 08:50:29 GMT
> We already have LoaderUtil in the util subpackage.  Might fit there.
> 

I started on PathUtil for the moment, all is static so could be 
injected easily, seems to me however the current LoaderUtil more 
has somewhat of a jdk-version match-up function?

> 
>>  - public ClassLoader getClassLoaderForPath(Path);
>>  - public ClassLoader getUniqueClassLoaderForPath(Path)
> 

getting into it (taking the reverseLoader inspiration from 
Definer) the signatures are becoming:

- public static ClassLoader
    //letting myself go wild in overloading:	
      getClassLoaderForPath(Project p, Reference ref);
      getClassLoaderForPath(Project p, Reference ref,
                                boolean reverseLoader);
      getClassLoaderForPath(Path path, String pathId);

      getUniqueClassLoaderForPath(Path path);


    //the useful ones being:
      getClassLoaderForPath(Path path, String pathId,
                                boolean reverseLoader);
      getUniqueClassLoaderForPath(Path path,
                                boolean reverseLoader);


> 
> We'll probably need both to address all needs, yes.  Please note that
> CVS HEAD is going to drop Java 1.1 compatibility, so some changes in
> the whole classloader area are to be expected.
> 

could you elaborate,
and maybe be explicit on how this can affect my doing ATM?
I just encountered enough reason to ditch my 1.5.x and go for CVS 
HEAD to add this to, so I am interested...

> Farming out the common actions to instantiate a user defined class loaded
> from a user defined path will also provide additional benefits here,
> a single entry point that could ensure we check the context
> classloader first and that avoids Class.forName completely.
> 
> Something like
> 
> public Object newInstance(String classname, ClassLoader userDefinedLoader)
> 

makes sense, and just wrapping the classic instantiation/loading 
extensions into the BuildException then

only bad thing is it breaks my PathUtil naming somewhat :-)

> with the semantics hinted at above.
> 
> Stefan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message