ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peter.rei...@corvil.com>
Subject Re: New Launcher and JPackage RPMs
Date Mon, 19 Jan 2004 13:23:47 GMT
First, I should say that classloader issues makes my head hurt.!

Jose Alberto Fernandez wrote:

>>From: Peter Reilly [mailto:peter.reilly@corvil.com] 
>>
>>
>>No, the optimization is that if the <typedef/> does not define a 
>>classpath, a cached classloader is used. This
>>cached classloader gets set once (the first call).
>>
>>Jose's more general caching solution souds more promising.
>>
>>    
>>
>
>Peter, I could not work on this during the weekend, but will try to post
>it
>tonight. Some additional questions I have (for improvements):
>
>1) It seems that we want a static cache, instead of per project.
>I can do this, but I am a little concern with IDEs keeping classes
>longer than we want. An alternative is to pass the parent cache
>to <antcall/> subproject (or a clone of it). Just like we do with
>some other system-like properties. Suggestions.
>  
>
This (use of static) is the main reason that I was worried about my patch
to antclassloader2.

The cache could be copied by ComponentHelper#initSubProject() as
this method gets called for each subproject.

>
>2) Looking at the code for createClassLoader(Path), as I mentioned
>before,
>we never seemto pass getCoreLoader() as the parent of the classloaders
>being created, if we were, we would be reusing the parent all the time
>and maybe gaining some savings. Is this kind of a very scarry change to
>do?
>Some of the complaints about the bootclassloader being used, may be
>fixed by
>doing such a change.
>  
>
I think that the code for getCoreLoader() and the new 1.6 classloader 
code were
two separate code paths that did not complete for 1.6.

>3) Since we do not need to support JDK1.1 anymore, can we get rid of the
>1.1 specific reflexion magic in createClassLoader() and use an
>AntClassLoader2 directly? Opinions?
>  
>
This makes sense.

Peter

>I think I can incorporate some of your input in this regard quite
>easily.
>So let me know what you think is best.
>
>Jose Alberto
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>  
>


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


Mime
View raw message