Rupert,
You've hit an interesting fringe case here.
Rupert Smith wrote:
> Could someone explaing to me why this interface compiles:
>
> interface StructFactory
> {
> Struct create(short type);
> QueueDeclare create(Class<QueueDeclare> klass);
> ExchangeDeclare create(Class<ExchangeDeclare> klass);
> SessionOpen create(Class<SessionOpen> klass);
> }
>
> I would have thought that the type erasure, and ignoring return
> types when overloading, would have resulted in the compiler
> thinking that the three create(Class) methods were all of
> indistinguishable type.
By JLS 8.4.2, the three create methods are not override-equivalent
because none has a signature that 'erases into' the signature of
another.
Hence, since the methods are not override-equivalent, by JLS 8.4.9,
the methods are overloaded.
> Certainly the compiler rejects it if I change some of the type
> arguments to Class<> to be the same [...]
Yes, and it would also complain if you'd change the parameter type
of one of them into plain 'Class'. Because then the others would
erase to this method and you'd have override-equivalence between
methods in the same class, which is a compile-time error (8.4.2).
> or if I change any of the return types to be the same.
Well, this was the shocker for me! We've just established that
we're dealing with overloaded methods. Return type is irrelevant
for an overloaded method (see 8.4.9). So why can't they be
identical in this case?
Others have stumbled into this. See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182950
That bug report was rejected, and the explanation hinges on the
awfully subtle difference between the erasure of a *method* (which
includes return type) and the erasure of a *method signature*
(which does not include return type).
The unsatisfactory thing about the explanation is that the JLS
nowhere defines 'erasure of a method', as opposed to 'erasure of
of a method signature' (which is defined in 4.5).
I think they're just making up these quirks for the sake of it :-)
Anyway. Back into my lurking corner.
Cheers,
Marco
