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 detail than I would prefer for what i think is an edge case.
I would not regard that an edge case. For a dynamic language using ClassValue to store information, it is very easy to produce a memory leak with ClassValue.
So I want in general to warn developers away from strongly referencing this ClassValue in the computed value for any associated class. If we do get strong feedback that this is a real problem we could consider adding a clever little static method like you suggest, with caveats that the computing Function might go away.
for us it is such a strong problem, that we are unable to transfer the old structure to use ClassValue without a major rewrite of large parts. Just imagine a runtime that uses ClassValue and that your application, let it be a web application, will spawn many runtimes over time. You do want the runtimes and all computed values be able to be garbage collected. But if you will need at the same time a ClassValue to not to prevent a class we computed the value for from unloading and have the computed value alive for min(lifespan class, lifespan runtime), then you get a real big problem in realizing this.
As it stands for me ClassValue is only usable as a class associated cache with values you can recreate at any moment. That is not good enough for us in the general case.
If that is an edge case I still miss a major part in the documentation... and that is what a ClassValue should be used for instead of a cryptic and incomplete description of what a ClassValue is. And then we could talk about if the intended use and the actual usability fit together
bye Jcohen
