Impasse: compiler/eclipse bug

[Twisted]

This code is part of an inner class for a custom collection class. The
parent class contains an instance member called "inner" of type Map<T,
Integer> and has a type parameter (T).

private class Iterator<T> implements java.util.Iterator<T> {
private java.util.Iterator<Map.Entry<T, Integer>> i;

Iterator () {
i = inner.entrySet().iterator();
}

public T next () {
Map.Entry<T, Integer> entry = i.next();

}
}

That's what I have so far and it complains about the constructor's only
line of code:

Type mismatch: cannot convert from Iterator<Map.Entry<T,Integer>> to
Iterator<Map.Entry<T,
Integer>>

In other words, cannot convert from foo to foo. Yes. The types are the
same. The iterator() call on the entrySet() return value returns a
java.util.Iterator<Map.Entry<T, Integer>>; the instance variable i is
explicitly declared as being of this same type.

Now what do I do?

 

[Twisted]

Twisted wrote:
[snip]

Eh -- removing the <T> from "public class Iterator<T>" removed.
Apparently it considered this to be a separate T from the nesting
class's own <T>, and it was the two Ts it considered to differ in the
two iterator types.

This new code compiles with no errors or warnings; soon I will have
implemented a working Bag.

private class Iterator implements java.util.Iterator<T> {
private java.util.Iterator<Map.Entry<T, Integer>> i;
private Map.Entry<T, Integer> entry;
private int qty;

Iterator () {
i = inner.entrySet().iterator();
qty = 0;
}

public T next () {
if (qty == 0) {
entry = i.next();
qty = entry.getValue().intValue();
}
--qty;
return entry.getKey();
}

public boolean hasNext () {
return (qty > 0) || i.hasNext();
}

public void remove () {
int n = entry.getValue().intValue() - 1;
if (n > 0) {
entry.setValue(new Integer(n));
}
assert qty == 0;
i.remove();
}
}

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Twisted schreef:

Twisted wrote:
[snip]

Eh -- removing the <T> from "public class Iterator<T>" removed.
Apparently it considered this to be a separate T from the nesting
class's own <T>, and it was the two Ts it considered to differ in the
two iterator types.

This new code compiles with no errors or warnings; soon I will have
implemented a working Bag.

You do know about Jakarta Commons Collections, right? It has several
Bag implementations.

H.

- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEtPI4e+7xMGD3itQRAv4SAJ9H5M728bN3044ind/qRJ3Oihvz1wCfTIXp
2TFmEeCBs6yb6vWh+GAiFH4=
=Rq1F
-----END PGP SIGNATURE-----

 

[Twisted]

You do know about Jakarta Commons Collections, right?
Nope.

It has several Bag implementations.

Fascinating.