It looks like folks are helping out with the immediate problems at hand. Just one side-note, in case it should ever become relevant:
As folks have pointed out about, you don’t need any extra ceremony to use Java classes – Scala is, intentionally, pretty compatible with Java. (Indeed, some of Scala’s odder nuances are precisely because the Java compatibility was Very Very Important early in Scala’s life, when it was still establishing traction.)
However, note that this is not entirely true when using Scala.js in the browser, and compiling to JavaScript. Scala.js is, by design, nicely interoperable with JavaScript, but JS doesn’t have Scala’s notion of strong types. So interoperating with JS does require some ceremony – either finding or writing a Scala “facade” (in the form of a trait) that describes in a strongly-typed way how a JS library works.
Yup, reproducible. Apologies, my code trying to reproduce the symptom was utter nonsense and didn’t do anything of that kind, and later I understood that you actually were aware of some way your code was injecting null into the game (which isn’t the case).
It seems to be as simple as this: WeakValueRef will report null when its referent has been purged, thus the WeakValueHashMap reports that there is an entry for this key (since the ref is mapped) and its value is null - which is faithfully translated as Some(null) by the conversion wrapper. So, yes, with this Map you’ll have to expect Some(null) for purged items.
Do you know whether there is some sort of reflection capability in the WeakValueHashMap nullification strategy? So I could measure how effective it is? How many such operations occur? Since the keys remaining in the table, hash.size won’t give me any meaningful information.
I mentioned before, that it would be even better if when WeakValueHashMap nullifies a value, that it also removes the key. Or at least gives me a callback so I can delete them myself. It will be far too expensive for me (in production code) to search the HUGE table looking for nullified values, although of course I could do that during the development phase.
I’ve added an issue for the WeakValueHashMap.java code in github discussing this question. On the other hand it would be excellent it I could manage to make this enhancement via a Scala specific subclass of WeakValueHashMap.
Another question, just to make sure I didn’t misunderstand the advise.
Do I or do I not need to install the code from https://github.com/hzulla/WeakValueHashMap/blob/master/WeakValueHashMap.java into the src/main/java directory of my project? The risk of course is that it won’t be subject to updates of the source changes.
Funny, I wanted to complain that the code downloaded does not contain any license information. But when I looked at the github page, someone else has already created an issue to that effect.
You generally shouldn’t need to do so – adding the library dependency should do the trick, just as it does with a Scala library.
(Unless you want to modify the WeakValueHashMap class itself to suit your needs – possible based on what you’re saying above – in which case you would need to add the code itself, yes.)
That’s a completely different implementation than the JBoss class we discussed before.
For the JBoss one, I’d go with the library dependency. This one by hzulla doesn’t come as a Maven/Ivy artifact, so if you want to use it, you’ll have to copy it to your code base.
It’s the GC that does the nullifying, through the WeakReference mechanism. The map implementations actually try to do the removal by iterating through the associated reference queue at the beginning of every method invocation. However, the documentation states that
At the same time or at some later time it will enqueue those newly-cleared weak references that are registered with reference queues.
…and I guess it’s between the nullification and the removal that you see the “explicit” null values that translate to Some(null) in the Scala wrapper.
