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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
