ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: cvs commit: ant/src/testcases/org/apache/tools/ant DirectoryScannerTest.java
Date Mon, 07 Mar 2005 17:12:10 GMT
On Mon, 7 Mar 2005, Dominique Devienne <DDevienne@lgc.com> wrote:
>> From: Stefan Bodewig [mailto:bodewig@apache.org] The "package" a
>> class belongs to really is not just the package name, but the pair
>> of package name and the classloader that has loaded the class.
> 
> Only when a package is sealed, no?

No.

> Are you saying that you can't have two classes from the same package
> loaded by two different classloaders?

You can, they are just not inside of the same package when it comes to
access.  You can't access package private or protected stuff in one
class from the other.

> I was not aware of this restriction. Can you point to a specific VM
> spec?

Let me sleep over this ;-)  I know I once found a reference when I
tried to debug a failing test, but I forgot where.  Maybe if you look
into CVS when the tests.and.ant.share.classloader property has been
added and search around the Ant-dev archives of that time, you can
find the link there.

> 
>> When we run "ant test", our testcases are in a nested <classpath>.
>> This means the tests get loaded by a separate AntClassLoader that
>> is a child of the classloader that has loaded Ant itself.
> 
> Right. Up to here I'm following. But ClassLoader delegation kicks
> in, and the Ant classes the tests depend on are loaded thru the
> parent loader.  (at least that was my understanding)

Exactly.  This means they get loaded by the parent, the tests get
loaded by the child.  Two different classloaders => two different
packages as far as access control is concerned.

> Counldn't we just use the ignore Ant classes switch, for tests,
> and put the compiled Ant classes on the classpath?

Won't help because of delegation.  That's why I said the classloader
must be a non-delegating one for this to work.

> Forking + explicit classpath, as described above, is much simpler
> a model, no?

Forking is the second option apart from build.sysclasspath, true.

Stefan

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


Mime
View raw message