ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chavdar Botev" <>
Subject Re: AW: a problem compiling a Java 5 project with generics
Date Wed, 18 Oct 2006 17:22:25 GMT
> Peter Reilly wrote:
> The original code may be slightly incorrect (my understanding
> of java generics is not high).

Ha-ha. I think the original code cannot be slightly incorrect. It is
either correct or incorrect. ;) It certainly possible that my
understanding of Java generics is wrong. I come from a C++ templates
background and although syntactically similar, Java generics and C++
templates seem to be very different. C++ templates are just fancy
macros. Java generics are types. Unfortunately, I think that these
syntactic similarities can often lead to misconceptions and errors.

The problem with the project I posted is the inconsistent behavior. If
my code is incorrect, that's fine, I'll have to rework it. In this
case, the compilation should always fail. If the code is correct, the
compilation should always succeed.

Anyway, I think I am going to post on the Sun Java problems to try to
locate where the problem is. Is it in my possibly incorrect
understanding of Java generics, is it in the java compiler, or is it
in Ant which puts the destination directory in the classpath?

As of the previous comments about the value in using Java generics, I
think the biggest value is not saving some typing. In fact, with the
lack of typedefs, this saving is rather dubious. I think the biggest
advantage is that they allow the Java compiler to do a lot of type
checks at compilation time. In previous versions of Java, you could
add an Apple to a collection of Oranges and you will not know this
until you try to retrieve the Apple and type-cast it to an Orange.
Anything that avoids a runtime error by doing a compile-time check is
good in my book.

> Scot P. Floess wrote:
> The problem here, I think, is that the inner class
> has access to everything defined in the outer class (this includes the
> declaration of the generic).

Ha-ha. This is what I kind of trying to use. The inner classes in my
case (and I have more than one per outer class) serve as different
views on the data in the outer class. Each view contains only the
functionality that certain other classes should care about. I don't
want to lump all the interface methods into the outer class.


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

View raw message