nested generic HashMap problem

[Chris Riesbeck]

I've looked at the Java generics tutorial, Langer's FAQ, and similar
online pages, but I'm still don't see what, if anything, I can do to
make the last line (marked with the comment) compile, other than do a
typecast and suppress the unchecked warning. Am I asking the impossible
or missing the obvious?

import java.util.HashMap;

public class Demo<T> {
private Class<T> base;
private Cache cache;

Demo(Class<T> b, Cache c) { base = b; cache = c; }

Class<T> getBaseClass() { return base; }
T get(long id) { return cache.get(this, id); }
}

class Cache {
private HashMap<Class<?>, HashMap<Long, ?>> maps
= new HashMap<Class<?>, HashMap<Long, ?>>();

public <T> T get(Demo<T> demo, long id) {
return getMap(demo).get(id);
}

public <T> void add(Demo<T> demo) {
maps.put(demo.getBaseClass(), new HashMap<Long, T>());
}

private <T> HashMap<Long, T> getMap(Demo<T> demo) {
return maps.get(demo.getBaseClass()); // incompatible types
}
}

 

[Lew]

I've looked at the Java generics tutorial, Langer's FAQ, and similar
online pages, but I'm still don't see what, if anything, I can do to
make the last line (marked with the comment) compile, other than do a
typecast and suppress the unchecked warning. Am I asking the impossible
or missing the obvious?

import java.util.HashMap;

public class Demo<T> {
private Class<T> base;
private Cache cache;

Demo(Class<T> b, Cache c) { base = b; cache = c; }

Class<T> getBaseClass() { return base; }
T get(long id) { return cache.get(this, id); }
}

class Cache {
private HashMap<Class<?>, HashMap<Long, ?>> maps
= new HashMap<Class<?>, HashMap<Long, ?>>();

public <T> T get(Demo<T> demo, long id) {
return getMap(demo).get(id);
}

public <T> void add(Demo<T> demo) {
maps.put(demo.getBaseClass(), new HashMap<Long, T>());
}

private <T> HashMap<Long, T> getMap(Demo<T> demo) {
return maps.get(demo.getBaseClass()); // incompatible types
}
}

No way while you have the wildcards there. Suppressing unchecked warnings
will only expose you to ClassCastException.

Did you also read the free chapter on generics from Josh Bloch's /Effective
Java/ available at java.sun.com?

You only suppress unchecked warnings when you have documentable proof that you
cannot get a ClassCastException, and that documentation needs to be in the
program comments.

As defined, your 'Cache#maps' variable cannot even guarantee that the base
type of the 'Class' key matches the type of the value map's value.

Furthermore, you define all that in terms of concrete classes instead of
interfaces. Oops.

You might have better luck putting an upper bound (e.g., 'Foo') on the type of
'T' and have

public class Cache <Foo>
{
private Map <Class <? extends Foo>, Map <Long, Foo>> maps;
}

or perhaps

public class Cache <Foo>
{
private Map <Class <? extends Foo>, Map <Long, ? extends Foo>> maps;
}

but as long as you're holding disparate types in your so-called "cache" I
don't think you can avoid the risk of ClassCastException.

I could be wrong. Type analysis is tricky.

Whenever I find tricky generics questions like these, I find it pays to really
think very hard about what to assert about the types. Once I figure that out
the generics are a simple reflection of that analysis.

 

[Chris Riesbeck]

No way while you have the wildcards there. Suppressing unchecked
warnings will only expose you to ClassCastException.

Did you also read the free chapter on generics from Josh Bloch's
/Effective Java/ available at java.sun.com?

Part of the above was meant to follow as best I could his pattern for
type-safe heterogeneous containers.

As defined, your 'Cache#maps' variable cannot even guarantee that the
base type of the 'Class' key matches the type of the value map's value.
>
Furthermore, you define all that in terms of concrete classes instead of
interfaces. Oops.

I agree. This was the shortest compilable example I could come up with
that still had the interactions I needed to support.

You might have better luck putting an upper bound (e.g., 'Foo') on the
type of 'T'
>
> [...snip...]

Whenever I find tricky generics questions like these, I find it pays to
really think very hard about what to assert about the types. Once I
figure that out the generics are a simple reflection of that analysis.

T can be anything. What I can assert is that if the key is Demo<T> then
the nested map value is Map<T, Long>, where T = the return type of
Demo<T> getBaseClass(). I can't figure out if there's a way to write
that relationship in the type declaration.

I really appreciate the quick response, Lew. Thanks

 

[markspace]

I've looked at the Java generics tutorial, Langer's FAQ, and similar
online pages, but I'm still don't see what, if anything, I can do to
make the last line (marked with the comment) compile, other than do a
typecast and suppress the unchecked warning. Am I asking the impossible
or missing the obvious?

Possibly. I've run into this before, that you basically can't use ? at
all for retrieving values of a type other than object, so you're going
to get a warning there no matter what you do.

If I follow your logic correctly, I think you can add a type parameter
to Cache, and that will allow you to use T instead of ? as a type
parameter for the hash map. Take a gander at the following and see if
it matches what you want to do:

package test;

import java.util.HashMap;

public class Demo<T> {
private Class<T> base;
private Cache<T> cache;

Demo(Class<T> b, Cache c) { base = b; cache = c; }

Class<T> getBaseClass() { return base; }
T get(long id) { return cache.get(this, id); }
}

class Cache<T> {
private HashMap<Class<T>, HashMap<Long, T>> maps
= new HashMap<Class<T>, HashMap<Long, T>>();

public T get(Demo<T> demo, long id) {
return getMap(demo).get(id);
}

public void add(Demo<T> demo) {
maps.put(demo.getBaseClass(), new HashMap<Long, T>());
}

private HashMap<Long, T> getMap(Demo<T> demo) {
return maps.get(demo.getBaseClass());
}
}

 

[Daniel Pitts]

I've looked at the Java generics tutorial, Langer's FAQ, and similar
online pages, but I'm still don't see what, if anything, I can do to
make the last line (marked with the comment) compile, other than do a
typecast and suppress the unchecked warning. Am I asking the impossible
or missing the obvious?

import java.util.HashMap;

public class Demo<T> {
private Class<T> base;
private Cache cache;

Demo(Class<T> b, Cache c) { base = b; cache = c; }

Class<T> getBaseClass() { return base; }
T get(long id) { return cache.get(this, id); }
}

class Cache {
private HashMap<Class<?>, HashMap<Long, ?>> maps
= new HashMap<Class<?>, HashMap<Long, ?>>();

public <T> T get(Demo<T> demo, long id) {
return getMap(demo).get(id);
}

public <T> void add(Demo<T> demo) {
maps.put(demo.getBaseClass(), new HashMap<Long, T>());
}

private <T> HashMap<Long, T> getMap(Demo<T> demo) {
return maps.get(demo.getBaseClass()); // incompatible types
}
}

Perhaps you should move the Map<Long, T> from Cache directly into Demo?

public class Demo<T> {
private Class<T> base;
private Map<Long, T> cache;

Demo(Class<T> b, Map<Long, T> c) { base = b; cache = c; }

Class<T> getBaseClass() { return base; }
T get(long id) { return cache.get(id); }
}

As a side note, I would make base and cache final.

 

[Chris Riesbeck]

Perhaps you should move the Map<Long, T> from Cache directly into Demo?

Which is actually where it started long ago, in the full set of classes,
before Factory came along. And probably the best way to go after all.

public class Demo<T> {
private Class<T> base;
private Map<Long, T> cache;

Demo(Class<T> b, Map<Long, T> c) { base = b; cache = c; }

Class<T> getBaseClass() { return base; }
T get(long id) { return cache.get(id); }
}

As a side note, I would make base and cache final.

I agree. It's a habit I still haven't gotten into, even though I const
like crazy in C++.

Thanks

 

[Chris Riesbeck]

Possibly. I've run into this before, that you basically can't use ? at
all for retrieving values of a type other than object, so you're going
to get a warning there no matter what you do.

If I follow your logic correctly, I think you can add a type parameter
to Cache, and that will allow you to use T instead of ? as a type
parameter for the hash map. Take a gander at the following and see if
it matches what you want to do:

package test;

import java.util.HashMap;

public class Demo<T> {
private Class<T> base;
private Cache<T> cache;

Yes, if the Cache is in Demo, then I can do it. That was the original
design. Time to chalk this up as a blind alley.

Thanks, everyone, for the comments and problem solving.

 

[markspace]

Yes, if the Cache is in Demo, then I can do it.

Just a note, in case you missed it: I didn't put the Cache inside of
Demo, all I did was add a type parameter to Cache.

That was the original
design. Time to chalk this up as a blind alley.

I think, given what you've shown us, you either have to remove the T
type information from the return types in Cache (if you don't have a
type, how can you guarantee that two different method calls actually
correlate in their type? That's why the ? is messing you up), or you
have to parameterize Cache, as I did, so the compiler can check your work.

Also, I didn't modify any other code. Your program appears to me to be
correct, so you could add a SupperssWarnings to the return type. But it
might be better not to: There's always maintenance to consider, and
keeping that SupperssWarnings valid through many code revisions,
possibly not done by you, might not be easy or even possible.

 

[Lew]

I agree. It's a habit I still haven't gotten into, even though I const
like crazy in C++.

The semantics of Java's 'final' differ from C++'s 'const' somewhat, as with so
many things that are similar between the languages but not quite the same.

 

[Chris Riesbeck]

Just a note, in case you missed it: I didn't put the Cache inside of
Demo, all I did was add a type parameter to Cache.

I did mis-read that.

I think, given what you've shown us, you either have to remove the T
type information from the return types in Cache (if you don't have a
type, how can you guarantee that two different method calls actually
correlate in their type?

I don't follow the "don't have a type" part here. The correlation I was
trying to capture was

T get(Demo<T>, long)

Also, I didn't modify any other code. Your program appears to me to be
correct, so you could add a SupperssWarnings to the return type. But it
might be better not to: There's always maintenance to consider, and
keeping that SupperssWarnings valid through many code revisions,
possibly not done by you, might not be easy or even possible.

Yes. I try to keep all SuppressWarnings limited to those cases forced by
old libraries or corner cases in Java that have no alternative. In this
case, in the larger design, there's another approach that doesn't need
to suppress unchecked warnings, so I'll stick with that.

Thanks

 

[Lew]

I don't follow the "don't have a type" part here. The correlation I was
trying to capture was

    T get(Demo<T>, long)

using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
well-defined, just not definable in Java.

What do you mean, not definable? That's exactly how you define it,
what you wrote just there, modulo the typos.

class Registry <T>
{
private final Map <Demo <T>, Map <Long, T>> demoMaps =
new HashMap <Demo <T>, Map <Long, T>> ();

...
}

 

[markspace]

I don't follow the "don't have a type" part here. The correlation I was
trying to capture was

T get(Demo<T>, long)

using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
well-defined, just not definable in Java.

What I was referring to was the actual type used in the program. Cache
doesn't have a type (parameter) and so the hash map doesn't either.
Thus, Java says "I don't have a type to check here" when you try to
return a value.

private HashMap<Class<?>, HashMap<Long, ?>> maps
= new HashMap<Class<?>, HashMap<Long, ?>>();

The ? says to me "I have no type." YMMV.

In your design, you have a type, yes, but you need to tell the compiler.

 

[Chris Riesbeck]

What do you mean, not definable? That's exactly how you define it,
what you wrote just there, modulo the typos.

class Registry <T>
{
private final Map <Demo <T>, Map <Long, T>> demoMaps =
new HashMap <Demo <T>, Map <Long, T>> ();

...
}

That defines a Map of Maps of one type T. I.e., you can make one
Registry where an instance of Demo<Book> retrieves a Map of type <Long,
Book>, and another Registry where a key of type Demo<Author> retrieves a
Map of type <Long, Author>.

But you can't define a single Registry where a Demo<Book> retrieves a
Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>.

 

[Lew]

Don't quote sigs.

That defines a Map of Maps of one type T. I.e., you can make one
Registry where an instance of Demo<Book> retrieves a Map of type <Long,
Book>, and another Registry where a key of type Demo<Author> retrieves a
Map of type <Long, Author>.

But you can't define a single Registry where a Demo<Book> retrieves a
Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>.

That isn't what you asked for in the post to which I replied.

 

[Daniel Pitts]

The semantics of Java's 'final' differ from C++'s 'const' somewhat, as
with so many things that are similar between the languages but not quite
the same.

Yes, I miss C++ "const", actually. I hated it when I was first learning
C++, because it stopped me from doing things I thought I should be able
to do (but were actually bad to do).

 

[Daniel Pitts]

What do you mean, not definable? That's exactly how you define it,
what you wrote just there, modulo the typos.

class Registry<T>
{
private final Map<Demo<T>, Map<Long, T>> demoMaps =
new HashMap<Demo<T>, Map<Long, T>> ();

...
}

Lew, the problem is "T" is different for every key of the map.

map.put(String.class, new Map<Long, String>());
map.put(Foo.class, new Map<Long, Foo>());

There is no definition for Map<Class<...>, ...> which will fit the above
usecases.

One will need to carefully ensure the key matches the value, and cast
appropriately, or not use a java.util.Map.

 

[Daniel Pitts]

Don't quote sigs.



That isn't what you asked for in the post to which I replied.

It has been the problem that the OP has been trying to solve this entire
thread.

 

[Lew]

It has been the problem that the OP has been trying to solve this entire
thread.

In which he referred to wildcarded generics. In the post to which I
responded, he seemed to have changed tack and remarked on what on the surface
was a very specific point. While true, Daniel, your point is irrelevant.

I believe that what the OP is doing is best served by finding some upper-bound
type for the keys, at least, of the primary and secondary map layers, and
using it for T, perhaps making the secondary value simply 'Object'. What
they're trying to do is never going to be painless.

Their desire to have the structures be typeless dooms them to conflict with
the heart of generics. They will have to cast somewhere. Fortunately, they
have a class token buried in all that goop, so they can at least hide the
'catch (ClassCastException ex)' blocks down in the depths and throw only
runtime exceptions. They'll need to Javadoc the hell out of the structures so
that everyone knows that everything has to match the class token.

As I finished typing this I see your other post, Daniel, where you made many
of these points as well.

 

[Arne Vajhøj]

Yes, I miss C++ "const", actually.

+1

Arne