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 currently needs.

Pro: minimize source code volume. Con: more complicated maintenance - if Peter makes a change, we would need to check whether it involves the subset.

3. Include the whole library source.

Pro: simpler maintenance - if Peter makes a change, we just copy in the change. Con: Distributing source code that is not used by River.

Any other options we should consider? Other pros or cons I have not thought of? Opinions?

On 8/12/2015 5:34 AM, Peter wrote:
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).

The code itself is scalable, it has a single JVM thread that performs
garbage collection of references, api calling threads don't perform this
task.  The references themselves are often created and destroyed without
being shared among other threads, a large number never leave CPU cache
and safe publication is used to avoid synchronization.  Overhead is low
and its public API is compact.

For the most part use of soft references is advised against, however
there is a case for a cache that degrades gracefully under load in the
form of a Map where keys are timed and values softly reachable (or vice
versa), to avoid extreme cases where a JVM is running out of memory, the
jvm gc can clear entries that aren't strongly reachable (even though
timed keys haven't expired) at its descretion potentially avoiding or at
least delaying an OOME.  Timed references will prune infrequently used
cache values, even though they're still strongly reachable.

Unlike other cache libraries, custard apple only implements reference
capabilities, allowing the user to wrap this over their preferred
collection, such as ConcurrentHashMap, ConcurrentSkipListMap,
NonBlockingHashMap etc, it reduces code duplication and allows the user
to benefit from new performance improvements in popular collections.

Regards,

Peter.

On 12/08/2015 8:57 PM, Patricia Shanahan wrote:
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
wan't you can always copy only the code in use into
org.apache.river.impl
...


Reply via email to