In ServiceDiscoveryManager, it's used to to cache
ServiceDiscardTimerTasks in a ConcurrentHashMap with key's that are
weakly referenced by ServiceID.
PreferredClassProvider, uses it to cache weakly referenced Classloaders
(values) in a ConcurrentHashMap using a LoaderKey that contains URI []
Hmm, I forgot about OSX, and static analysis.
FreeBSD still has some socket issues BTW.
Users with latent concurrency bugs are also likely to have these
exposed, so should test user code thoroughly.
Regards,
Peter.
On 11/08/2015 7:19 PM, Peter wrote:
On 11/08/2015 8:33 AM, Patricia
Off-topic, but I am astonished that custard apple is not in the Central
Maven repo - I wonder why?
I'd have thought in this day and age, almost any Java library of
meaningful utility would be published there?
regards,
Dawid
On 12/08/2015 11:05, Bryan Thompson wrote:
We use very similar
We use very similar collections in Blazegraph and they are quite important
(we mainly use them as a cache for index objects) I do avoid SoftReference
based collections due to the inability to have predictable behavior of the
garbage collector.
It sounds like importing the relevant classes would
Does it have a license that lets us do that?
(If you are the writer, and copy it in yourself, it would be covered by
your ICLA, just like any other code you contribute to Apache.)
On 8/12/2015 12:00 AM, Peter wrote:
...
I'm a little busy right now to consider moving custard apple. If you
It's AL2 licensed, the source is in a jar file in dep-libs, consider it
already contributed.
The library contains more code than you need, as it covers every type of
Java Collections interface, up to Java 7 (it will be updated at some
point to support Java 8 9 collections interfaces also).
Thanks, Peter.
It appears to me that we have three options for dealing with custard
apple:
1. Do not include it in the release, but include a download link in the
installation instructions.
Pro: easy for us. Con: more work for users.
2. Include a selected source subset that River
