Compiler Bug?? (javac 1.6.0_0-internal)

[Marc van Dongen]

Dear all,


I've recently started programming in Java and I'm having a problem
with the following class, which is not supposed to be particularly
meaningful as I've made it minimal to highlight the problem:

============================== START ================================
import java.util.Iterator;

public final class Error<T>
{
public final class Error<T>
{
private final T t;
public Error( final T t ) { this.t = t; }
private class ErrorIterator<T> implements Iterator<T>
{
public ErrorIterator( ) { }
public boolean hasNext( ) { return true; }
public T next( ) { return t; }
public void remove( ) { }
}
}
=============================== END =================================

When I try to compile this example I get the following error:

============================== START ================================
Error.java:11: incompatible types
found : T
required: T
public T next( ) { return t; }
=============================== END =================================

I'm using javac 1.6.0_0-internal.

Is this a known error? If so, is there a bug-fix I could download
somewhere?

Thanks in advance for your help.

Regards,


Marc van Dongen

 

[Marc van Dongen]

public final class Error<T>
{
public final class Error<T>
{

Sorry, the first (or the last) of these four lines should be deleted.

Regards,


Marc van Dongen

 

[Andreas Leitgeb]

import java.util.Iterator;
public final class Error<T>
{
private final T t;
public Error( final T t ) { this.t = t; }
private class ErrorIterator<T> implements Iterator<T>

The problem is, that this "T" is a different one from that above.

If you write it such:
private class ErrorIterator implements Iterator<T>
it will use the outer class' "T", which is what you probably
want to achieve.

Given that one cannot re-use a name for a local variable in a
nested block when the surrounding block already has a such-named
local variable, ... given that it seems indeed odd, that one
can confusingly (and likely unintendedly) re-use names of type
parameters in nested scopes. To that degree I'd agree that it
is a shortcoming in the JLS.

PS: At the moment I'm writing this, I see no other followup yet,
but I suspect sooner or later there will be a big subthread about
that copy+paste-error that duplicated the class header.

 

[Marc van Dongen]

The problem is, that this "T" is a different one from that above.

Thanks! I see what I've done wrong. Much appreciated.

Regards,


Marc van Dongen

 

[Roedy Green]

When I try to compile this example I get the following error:

============================== START ================================
Error.java:11: incompatible types
found : T
required: T
public T next( ) { return t; }

you will get more responses if you embed the error message in the
listing to show which line it is complaining about.
--
Roedy Green Canadian Mind Products
http://mindprod.com
PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
However, he refuses to consider the costs of not implementing Kyoto which the
famous economist Nicholas Stern estimated at 5 to 20% of GDP

 

[Joshua Cranmer]

Error.java:11: incompatible types
found : T
required: T
public T next( ) { return t; }

Almost as good as the runtime ClassCastException: "Class util.Option
cannot be cast to class util.Option" (before you blow your brains out
trying to figure out how that fails, it's because I failed to apply
enough magic to my ClassLoader).

The error stems from "you have two objects with the same name." The
class Error defines a type T (which we'll call Te) and the Class
ErrorIterator defines a Type T (which we'll call Ti).

Your declaration of ErrorIterator is therefore:


public final class Error<Te> {
private final Te t;
private class ErrorIterator<Ti> implements Iterator<Ti> {
public Ti next() { return t; }
}
}

Now, obviously Te != Ti, nor is one a subclass of the other, so this is
where the error comes in.

This is one example where generics error messages can be impenetrable,
since what generally matters more is not the name of the type, but where
the type was declared. And here, the error message doesn't bother to
explain where they're coming from. Much better would be:
found : T (from Error<T>)
required: T (from Error.ErrorIterator<T>)

In general, if you have a problem with generics, it's probably more
likely that you're misusing generics than the compiler isn't doing it
right. The only counterexample I readily know is that Enum.class is a
Class<Enum>, not a Class<Enum<?>>. Which has actually hurt me in practice.

 

[Marc van Dongen]

Marc van Dongen wrote:

[explanation]

Thanks. I understand that what I tried to program is an obvious error.
A more informative error message than [found T. required T] would have
helped me catch it before asking this newsgroup.

Thanks again.

Regards,


Marc van Dongen

 

[Mike Schilling]

Marc van Dongen wrote:

[explanation]

Thanks. I understand that what I tried to program is an obvious
error.

Obvious once pointed out, mysterious beforehand. It's a classic "I
need another pair of eyes" problem.

 

[Andrew Thompson]

...
Almost as good as the runtime ClassCastException: "Class util.Option
cannot be cast to class util.Option" (before you blow your brains out
trying to figure out how that fails, it's because I failed to apply
enough magic to my ClassLoader).

Huhh.. I am getting similar errors when
I load a page in Appleteer that attempts
applet<->communication*. It uses an
URLClassLoader, and has me puzzled.

Any tips for solving it?

* <http://pscode.org/appleteer/applet.html?href=http:/
%2Fwww.rgagnon.com%2Fexamples
%2Fjava-0022.html&log.length=50&log.level=config>
Note you need to activate the '>' button
before the applet start() method is called.
"Applet2_0022 cannot be cast to Applet2_0022"

 

[Daniel Pitts]

Huhh.. I am getting similar errors when
I load a page in Appleteer that attempts
applet<->communication*. It uses an
URLClassLoader, and has me puzzled.

Any tips for solving it?

* <http://pscode.org/appleteer/applet.html?href=http:/
%2Fwww.rgagnon.com%2Fexamples
%2Fjava-0022.html&log.length=50&log.level=config>
Note you need to activate the '>' button
before the applet start() method is called.
"Applet2_0022 cannot be cast to Applet2_0022"

The problem is that a type key is really "class-loader+class", not just
"class". If two class loaders load the same class file, the objects
created by either instance of that class are not the same type.

So, you either need to make sure that shared classes are loaded by a
shared class loader, or that objects do not pass the classloader boundary.

 

[Andreas Leitgeb]

The problem is that a type key is really "class-loader+class", not just
"class". If two class loaders load the same class file, the objects
created by either instance of that class are not the same type.

So, you either need to make sure that shared classes are loaded by a
shared class loader,

Right so far.

or that objects do not pass the classloader boundary.

.... unless accessed only through references of super-class (or implemented
interface) type loaded by a common parent-classloader.

PS: Happy seasonal greetings to everyone here.

 

[Andrew Thompson]

....
The problem is that a type key is really "class-loader+class", not just
"class".  If two class loaders load the same class file, the objects
created by either instance of that class are not the same type.

I had thought both applets were being loaded
by the same classloader, but will check the
details more carefully in the new year.

Thanks.

 

[Andrew Thompson]

I had thought both applets were being loaded
by the same classloader, ...

Duhh! Of course they are not.

Each AppletLoaderContainer had its own
URLClassLoader based on the applet element
for that applet.

The fix will be tricky though, both in design
and in the fact that a single URLClassLoader
for all applets might lead to confusion when
attempting to locate same name resources in
different Jar files.