Win a copy of Java 9 Modularity: Patterns and Practices for Developing Maintainable Applications this week in the Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Compiling problem with generics.  RSS feed

 
Michael Remijan
Author
Ranch Hand
Posts: 131
7
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is a simple simple Java class.



The jdk 1.6.0_01 compiler can not compile this class. The error I get is:


I find this a big odd. I'm guessing that behind the scenes the method parameters really are still a Collection of Objects?
 
Brian Cole
Author
Ranch Hand
Posts: 954
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Remijan:
name clash: setFoo(java.util.Collection<java.lang.Double> ) and setFoo(java.util.Collection<java.lang.Integer> ) have the same erasure

I find this a big odd. I'm guessing that behind the scenes the method parameters really are still a Collection of Objects?


That's essentially correct, in that the generic types are available
at compile time but get compiled away. They call it Type Erasure.

Interestingly, you can get this to work if you change the return type
of one of the two methods:



I find this nonintuitive, but the return type is evidently part of the
method erasure even though it is not part of the method signature.

[edit: try to get the smileys out of the quoted text]
[ September 20, 2007: Message edited by: Brian Cole ]
 
Michael Remijan
Author
Ranch Hand
Posts: 131
7
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thought so.....well that's no fun!
 
Brian Cole
Author
Ranch Hand
Posts: 954
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Remijan:
Thought so.....well that's no fun!


Certainly there are downsides to the choice to use
type erasure for java generics, but what's "no fun"
in your particular example?

If you really want those two methods to overload
you can just have one return an int like I said.

If the compiler has the source code to class Test
it should work as overloaded methods usually do.

(Frankly, I'm not sure what happens if the compiler
has access only to the compiled .class file. Hmm.)
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Brian]: I find this nonintuitive, but the return type is evidently part of the method erasure even though it is not part of the method signature.

I agree. Even if it works, the original methods didn't have a need for any return value, so including one now seems very strange. I would suggest Michael might consider two other options:

1. Change the method names themselves (so we're no longer overloading at all):


2. Write a single, more general method:

or even

(as long as we're doing something more general - if you don't do anything with the Collection other than iterate through it, then Iterable is all you need.)

[Brian]: (Frankly, I'm not sure what happens if the compiler
has access only to the compiled .class file. Hmm.)


Should work the same. The .class file contains all the generic type info that was available at compile time. That stuff will get ignored away when the class is loaded into a JVM at run time, but it's useful and necessary when compiling using other classes in .class and jar files, so the info is indeed stored in .class files.
 
Nicole Lacoste
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I was just reading through some of the posts, and came across this topic.

I find this really disturbing. It's annoying that generics can't be uses in overloads, but at least I understand type erasure and have come to live with that. But I just can't get my head around the fact that changing the return type makes it work, since this isn't the case for over loading in general, ie.

will not compile.
As you state

doesn't compile due to type erasure but it is true that

does compile, and not only that it works! Calling method with a calls the first method and calling it with a collection calls the second.

Anyone else as disturbed as me? Or is there some explaination?

Cheeers,

Nicole
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nicole Lacoste:
I find this really disturbing.


I'm not sure I'd go that far. However, this thread does seem to have exposed a very arcane feature of Java. As one of the main aims and benefits of Java is its relative simplicity and obviousness, I think that the language designers made a mistake in allowing this feature. Perhaps they thought it was a benefit to allow this as a power-user feature, but I think they'd have been better requiring it to be a compilation failure.

I think that no good Java programmer should use this feature. "KISS" applies. <TROLL>If you want to write arcane, impossible to understand, code, go get yourself a Perl interpreter.</TROLL>
[ October 02, 2007: Message edited by: Peter Chase ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!