You'd want to use CacheBuilder, which allowed us to pull away from the limitations of and not abuse the Map interface.
If you want to embed an LRU cache, which I don't think is the case, many prefer its predecessor (ConcurrentLinkedHashMap<http://concurrentlinkedhashmap.googlecode.com>) as a lighter-weight dependency to shade. We reworked<http://concurrentlinkedhashmap.googlecode.com/files/ConcurrentCachingAtGoogle.pdf>Guava's implementations based on that project. As a user, I'd prefer a plugin scheme when possible to tease apart complexities. It would be nice if jOOQ provided a good implementation or two, which might require me to add a few more dependencies to the project, to avoid repeated work. On Monday, June 17, 2013 5:04:04 AM UTC-7, Lukas Eder wrote: > > N.B: > > Guava's MapMaker might implement some more sophisticated maps for the task: > http://stackoverflow.com/a/264591/521799 > > > 2013/6/17 Lukas Eder <[email protected] <javascript:>> > >> >> >> >> 2013/6/17 Ryan How <[email protected] <javascript:>> >> >>> 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. >>> >> >> Yes, at the client side, such a solution is good enough. You know your >> own class loader. >> >> >>> >>> Of course if it was inbuilt in Jooq and on by default it would be a >>> different story. >>> >> >> Precisely. That's what Joachim and I were referring to. >> >> >>> >>> 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... >>> >> >> The point here is that jOOQ shall not hold any strong references to >> classes loaded by a ClassLoader C. Once a C is GC'ed, classes loaded by C >> in jOOQ's cache should "disappear". That's where weak references are >> useful. In fact, it probably makes sense to check if this rule isn't >> violated already today. >> >> The weak references won't be GC'ed before the ClassLoader is unloaded (to >> prevent memory leaks), as each ClassLoader contains a Vector of its loaded >> classes as strong references. to prevent memory leaks, a fixed-sized LRU >> Map would probably have to be used. >> >> this stuff does my head in... >>> >> >> Same here. In case of doubt, I won't implement any such cache in jOOQ. >> >> >>> >>> Lukas Eder <[email protected] <javascript:>> wrote: >>> >>> >>> >>> >>> >>> 2013/6/17 Durchholz, Joachim >>> <[email protected]<javascript:> >>> > >>> >>>> > [...] 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] <javascript:>. >>> >>> 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] <javascript:>. >>> 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.
