ClassValue rooting objects after it goes away?

[Jochen Theodorou]

Am 27.08.2015 00:54, schrieb Remi Forax:
> Hi Jochen,
> what you can try is to use this code written by Jerome Pilliet as replacement of ClassValue (using -Xbootclasspath/p)
>    https://bitbucket.org/jpilliet/libcore-292/src/tip/libdvm/src/main/java/java/lang/ClassValue.java?at=4.4.3.292
> to see if you can reproduce your bug or not with this other implementation of ClassValue (under Apache Licence).
>
> Note that i hope that this implementation works but it's clearly haven't been battletested,
> nevertheless if you can not reproduce your issue, it means that this is clearly a bug in the OpenJDK implementation.

I have not tried that yet. But Henry Tremblay came up with a more simple 
solution for the testing scenario. Our old ClassValue class was this:

public class GroovyClassValueJava7<T> extends ClassValue<T> implements 
GroovyClassValue<T> {
    private final ComputeValue<T> computeValue;
    private Map<Class<?>, T> cache = new HashMap<Class<?>, T>();

    public GroovyClassValueJava7(ComputeValue<T> computeValue){
       this.computeValue = computeValue;
    }
    @Override
    protected T computeValue(Class<?> type) {
       return computeValue.computeValue(type);
    }
}

and the suggestion was to move the caching out of ClassValue internals 
and into a simple map:

public class GroovyClassValueJava7<T> extends ClassValue<T> implements 
GroovyClassValue<T> {
    private final ComputeValue<T> computeValue;
    private Map<Class<?>, T> cache = new HashMap<Class<?>, T>();

    public GroovyClassValueJava7(ComputeValue<T> computeValue){
       this.computeValue = computeValue;
    }
    @Override
    protected T computeValue(Class<?> type) {
       return computeValue.computeValue(type);
    }

     @Override public T get(Class<?> type) {
         T t = cache.get(type);
         if(t == null) {
             t = computeValue(type);
             cache.put(type, t);
         }
         return t;
     }

     @Override public void remove(Class<?> type) {
         cache.remove(type);
     }
}

Of course this is no proper replacement, since it is far from threadsafe 
and all, but it makes the test scenario work.

anyway... doesn't this also mean a OpenJDK bug?

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/