Collection proxy(Map) bug with Long values as keys

[ratang2000]

I'm using TreeCacheAOP (JBOSSCache version 1.2.4SP1) for which im storing a map in the cache.
When i retrieve the map and do a get() or a containsKey() it returns a null or a false value respectively for the given key.
This happens only when i have a Long object stored as a key in my HashMap. When I use a string it works perfectly.
And also,when we do similar operations on regular java Maps they work.Its an issue with the Proxy map that is returned by the getObject();
My key looks like 8225676592564383 .
So I insert my values like map.put(new Long("8225676592564383"),"prateek");
Below is a code sample of what Im doing:

public class AOPTest extends HttpServlet {
 protected void doGet(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse)
 throws ServletException, IOException {
 TreeCacheAop cache = (TreeCacheAop) getServletContext().getAttribute("treecache");
 Map nonCacheMap = (Map) getServletContext().getAttribute("noncachemap");
 try {
 Map guidMap = (Map) cache.getObject("/aop/guidmap");
 Map guidMap2 = (Map) cache.getObject("/aop/guidmap2");
 System.out.println(guidMap.containsKey("8225676592564383"));//This works-Its a string key
 System.out.println(guidMap2.containsKey("8225676592564383"));//this returns false.Its a long.

 } catch (CacheException e) {
 e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
 }
 }

 public void init() throws ServletException {
 TreeCacheAop cache = null;
 try {
 cache = new TreeCacheAop();

 PropertyConfigurator config = new PropertyConfigurator();
 config.configure(cache, "META-INF/jbosscache-config.xml");
 cache.start();
 Map guidMap = new HashMap();
 Map guidMap2 = new HashMap();
 cache.putObject("/aop/guidmap", guidMap);
 cache.putObject("/aop/guidmap2", guidMap2);

 guidMap = (Map) cache.getObject("/aop/guidmap");
 guidMap2 = (Map) cache.getObject("/aop/guidmap");

 guidMap.put("8225676592564383", "abhishek");
 guidMap2.put(new Long("8225676592564383"), "abhishek");
 getServletContext().setAttribute("treecache", cache);
 } catch (ConfigureException e) {
 e.printStackTrace();
 } catch (Exception e) {
 e.printStackTrace();
 }
 }

}

Please tell me a solution for this ..I want to use the Long key only in my map.

[ratang2000]

Hey there is a small typo in the code..The following code
System.out.println(guidMap2.containsKey("8225676592564383"));.

should read as
System.out.println(guidMap2.containsKey(new Long("8225676592564383"))).

[ratang2000]

any ideas on this one anyone?

[smarlow]

Nice find!

If you create a Jira for this, I'll fix it for the JBoss Cache 1.3 release. Assign it to me for release 1.3. This needs to be done today.

The workaround is:

System.out.println(guidMap2.containsKey(new Long("8225676592564383").toString())).

[smarlow]

Never mind, I created the Jira JBCACHE-496 for this problem.

[ratang2000]

Thanks Scott, the workaround wouldn't be a good idea in our software since the structure is used nearly everywhere.

[ratang2000]

OK got it,I can still put Long keys and while accessing it I can make them to strings and still be access the object.
This workaround is then bearable, then changing the type of the key.
Thanks Scott!!

[ratang2000]

Hey one more issue is there.
When I do the following:
Set set=map.keyset();
Iterator setIterator=set.iterator();
while(setIterator.hasNext()){
Object object= iterator.next();//object returned here is String and not Long
}

The Object returned by iterator.next() is actually a String and NOT Long.

Is this there in your fix too???

[ratang2000]

Is it possible to get a nightly build of the JBOSS Cache that has your fixes for the time being until we dont have the 1.3 release?

[ben.wang]

Since the current limitation regarding to non-primitive Jey object is in the hashcode. Instead of coverting everything into String, we need to verify this, but I think we can support the primitive type object, e.g., Long, Integer, Short, String, etc.

Scott, would you like to investigate this?

Thanks,

-Ben

[smarlow]

Currently, we convert the key objects into String (via toString()). The bug was that we didn't always do this consistently.

My fix doesn't change the way we convert key objects to String. My fix changes Map.containsKey to also convert the key to string. We already fixed Map.get to convert the key to String in 1.3.

With my fix applied, you will still get String values from the collection for the key.

[smarlow]

Jira http://jira.jboss.com/jira/browse/JBCACHE-399 requests that we change the Map implementation to not convert Key object values to String. You should vote for this Jira if this is important to you.

[ratang2000]

Ideally, the Collection proxies should exactly behave the way normal Java Collections/Maps do..
Atleast user knows what to expect out of it and
this would also prevent related issues popping up later on...

[smarlow]

We should be releasing a beta 2 build of JBossCache 1.3 soon that you can try.

[smarlow]

Ideally, the Collection proxies should exactly behave the way normal Java Collections/Maps do..
Atleast user knows what to expect out of it and
this would also prevent related issues popping up later on...

I agree. We should work towards this goal.

I see that you have voted for JBCACHE-399 which is good, it helps us to know how many people want a bug to be fixed.