I don't see why it needs weak references? I would just control the cache manually within the application and if I need to get rid of all references then call a clear() method.
Of course if it was inbuilt in Jooq and on by default it would be a different story. Still, weak hash maps I don't think would solve all issues. It might just prevent memory leaks, which I don't think would be a major issue unless you are using "into" for a growing number of classes... which I guess might happen in an osgi environment or webapp if you happen to be using Jooq from the shared classpath. But in that case you're asking for trouble if you wanna cache application classes in the shared classloader classpath... or something... this stuff does my head in... Lukas Eder <[email protected]> wrote: 2013/6/17 Durchholz, Joachim <[email protected]> > > [...] you could cache the results of the reflection > > (really it is the whole "parsing" algorithm, which > > uses reflection) globally for each class, so it > > re-uses the same generated "algorithm" whenever it > > sees the same class. > > Please make sure that the class objects don't get strongly > linked to from the cache. > This is surprisingly hard to get right actually. I once > tried to do something like that, and found that garbage > collection and weak references and WeakHashMaps somehow > do something subtly different than I had thought. In the > end, I punted and declared Introspector "barely sufficient > for the use case at hand". > It is indeed very hard to get right. Consider the WeakHashMap's Javadoc [1]: *Implementation note:* The value objects in a WeakHashMap are held by ordinary strong references. Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded. It is hard to ensure that a Class<?> key is not indirectly referenced by a map value. The ReflectionMapper, for instance, holds a strong reference to the class and to members of that class. Since caching reflection is easy to get wrong, if Jooq is > ever going to use that, the hard-to-get-right aspects of > this should be solved by Jooq. Could be done by > - having (or linking to) a full in-depth description > how to do it right, > - offering a reflection cache data structure that does it > right, > - make Jooq's API accept the reflection info, but manage > the cache inside Jooq (and say in the Javadoc that the > code computing that reflection info must never retain > any references to that info). I will certainly think about these things a bit more. But I'm also thankful for contributions by someone who will get it right quicker than me... Cheers Lukas [1]: http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html -- You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/mM19mjR-49g/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
