ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
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:
> For additional commands, e-mail:

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message