ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <>
Subject Re: AW: a problem compiling a Java 5 project with generics
Date Wed, 18 Oct 2006 11:55:21 GMT

Steve Loughran wrote:
> Peter Reilly wrote:
>> On 10/17/06, Chavdar Botev <> wrote:
>>> Peter,
>>> I repeated the steps you described and I can confirm that with the
>>> -classpath argument the compilation fails and without it the
>>> compilation succeeds. I also tried running javac on "src/test/*.java"
>>> instead of "src/test/". In this case, the compilation
>>> succeeds with or without -classpath.
>>> I think it looks like some dependency problem.
>> I have just checked the <javac> revision history,
>> since the initial checkin (6 years, 9 months), <javac> has always added
>> the destination path to the classpath for the javac command.
>> It does not seem to be necessary? but I do not know if
>> we can remove it without something failing.
>> Perhaps we can use (yet another) attribute to javac to
>> disable this behaviour.
> It is probably needed for incremental builds in which all source files
> are not in the source tree you specify, such as when you have multiple
> <javac> tasks building into the same place.
> I think we have caused a java generics bug to surface here. If
> -classpath triggers it on the command line, it is probably a sun
> problem. Question is, how to report it, and how to work around it in ant?
We could add an attribute to the javac task in order not to incorporate
the destination to the compilation classpath. We could call it :
includeclasses or includedest. It would be true by default,
so BC would be preserved. So the workaround would be to set it to false
in build files/projects affected by this problem.

How to report it : should go to the bug parade I think if it can be
reproduced and is really a Sun bug.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message