ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scot P. Floess" <flo...@mindspring.com>
Subject Re: AW: a problem compiling a Java 5 project with generics
Date Wed, 18 Oct 2006 17:59:11 GMT

> 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.
Honestly, I think you are in the gray area with inner classes...  Mostly 
because it "appears" syntactically your code has access to everything in 
the enclosing class...  However, at the class level when javac does its 
job, it changes things.  For instance, you will note when you compile a 
class who contains an inner class the class name for the inner class 
becomes <outerclass name>$<inner class name>.  So when inner classes 
became a part of the language in 1.1, the VM didn't have to change.
> 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?
Personally, my opinion is that it is an issue in javac the application.  
I was able to compile if I didn't include the bin dir as part of 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.
No doubt :)  However, generics go far beyond collections - and are very 
useful in other scenarios.
>
>> 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.
Yea I hear ya :)  And, what you describe makes sense...  Still, one can 
refactor such that this functionality exists outside the class.
>
>
> Thanks,
> Chavdar
>

-- 
Scot P. Floess
27 Lake Royale
Louisburg, NC  27549

252-478-8087 (Home)
919-754-4592 (Work)

Chief Architect JPlate  http://sourceforge.net/projects/jplate
Chief Architect JavaPIM http://sourceforge.net/projects/javapim


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


Mime
View raw message