Prev: Quartz with Spring: more jobs with different input argument
Next: call jni function dynamically without getting a JNIEnv handle as an argument.
From: Chris Riesbeck on 26 Apr 2010 20:52
Daniel Pitts wrote:
> On 4/26/2010 2:54 PM, Chris Riesbeck wrote:
>> 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 Cache {
>> private HashMap<Class<?>, HashMap<Long, ?>> maps
>> = new HashMap<Class<?>, HashMap<Long, ?>>();
>>
>>...
>>
>> 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?

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
From: Chris Riesbeck on 26 Apr 2010 20:54
markspace wrote:
> Chris Riesbeck wrote:
>> 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;

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.
From: markspace on 26 Apr 2010 21:28
Chris Riesbeck wrote:
>
> 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.
From: Lew on 27 Apr 2010 06:33
Daniel Pitts wrote:
>> As a side note, I would make base and cache final.

Chris Riesbeck wrote:
> 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.

--
Lew
From: Chris Riesbeck on 27 Apr 2010 09:31
markspace wrote:
> Chris Riesbeck wrote:
>>
>> 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.

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)

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

> 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Quartz with Spring: more jobs with different input argument
Next: call jni function dynamically without getting a JNIEnv handle as an argument.