Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hm, Such advise might not be fruitful for average user. Why? 1. ClassValue instances are typically assigned to static final fields of application classes. Which means that they will be strongly reachable as long as the ClassLoader of such static field's declaring class is strongly reachable.

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi, I would like to still propose this note for 9, we ain’t gonna resolve the underlying issue in 9. It’s currently an api note but it’s more appropriate as an implementation note (e.g. Ephemerons might help). We could amend the note with Peter’s suggestion as follows: @implNote Care should

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

resend after I did accidentally send it to Paul directly instead of the list On 10.11.2016 21:24, Paul Sandoz wrote: Hi Jochen, Can you confirm if my analysis of Groovy using ClassValue was correct: https://bugs.openjdk.java.net/browse/JDK-8136353 AFAICT in this case the issue was not with Cla

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Jochen, Can you confirm if my analysis of Groovy using ClassValue was correct: https://bugs.openjdk.java.net/browse/JDK-8136353 AFAICT in this case the issue was not with ClassValue itself but the storing of computed values in a global se

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

On 09.11.2016 19:18, Doug Lea wrote: [...] And: Similar cases can indeed occur with ThreadLocal, but users seem to mostly avoid them, sometimes after painful experience. ThreadLocal is already a bad choice once you subclass it. bye Jochen

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

On 09.11.2016 17:47, Paul Sandoz wrote: Hi Peter, Good point about if such support was added it would break the API and also (with Remi) about Ephemerons. You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Remi, On 11/09/2016 06:29 PM, Remi Forax wrote: - Mail original - De: "Paul Sandoz" Cc: "Core-Libs-Dev" Envoyé: Mercredi 9 Novembre 2016 17:47:34 Objet: Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue Hi Peter, Good

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

;Paul Sandoz" , "Core-Libs-Dev" Envoyé: Mercredi 9 Novembre 2016 09:13:54 Objet: Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue Hi Paul, On 11/09/2016 12:27 AM, Paul Sandoz wrote: Hi, Please review the addition of an api note to Cl

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

- Mail original - > De: "Paul Sandoz" > Cc: "Core-Libs-Dev" > Envoyé: Mercredi 9 Novembre 2016 17:47:34 > Objet: Re: 8169425: Values computed by a ClassValue should not strongly > reference the ClassValue > Hi Peter, > > Good point ab

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Peter, Good point about if such support was added it would break the API and also (with Remi) about Ephemerons. You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more detail than I would prefer for what i thin

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Paul, What do you think of introducing a static factory method in ClassValue in addition to your @implNotes. The method would go like this (similar to ThreadLocal.withInitial()): public abstract class ClassValue { /** * Creates a {@code ClassValue} instance which uses given {@cod

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Or, better yet, using value factory Function instead of Supplier: public class WeakFactoryClassValue extends ClassValue { private final WeakReference, ? extends T>> factoryRef; public WeakFactoryClassValue(Function, ? extends T> factory) { factoryRef = new WeakReference<>(fa

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Paul, On 11/09/2016 09:13 AM, Peter Levart wrote: It is not always the case that when ClassValue instance is strongly reachable from the associated computed value, unloading of classes and class loaders is prevented. Take the following example (assume that the code is loaded by a special

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

y too common. see https://bugs.openjdk.java.net/browse/JDK-6389107 and BTW JavasScript WeakMap uses ephemerons. Rémi - Mail original - > De: "Peter Levart" > À: "Paul Sandoz" , "Core-Libs-Dev" > > Envoyé: Mercredi 9 Novembre 2016 09:13:54 > O

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi Paul, On 11/09/2016 12:27 AM, Paul Sandoz wrote: Hi, Please review the addition of an api note to ClassValue.computeValue. There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being

8169425: Values computed by a ClassValue should not strongly reference the ClassValue

Hi, Please review the addition of an api note to ClassValue.computeValue. There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC’ed, but it turned out the problem was with Groovy's