river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Questions about the Reference Collection dependencies. Was: Re: Release 3.0
Date Thu, 13 Aug 2015 08:49:32 GMT
Good point. That seems to eliminate my option 1.

On 8/13/2015 1:45 AM, Greg Trasuk wrote:
> If we have a dependency on a library that’s not in Maven Central,
> then using River in a Maven-based project (for example, the River
> Examples project) will effectively be impossible (it can be done but
> is a royal nuisance for downstream users).
> As such, I’d vote against any release that has a dependency on a
> library that’s not in Maven Central.
> If Peter’s not able to put custard-apple into Maven Central, then I
> think we have no choice but to accept it as contributed code and roll
> it into River.
> A third option would be to accept it as a contributed code, but treat
> it as a separate deliverable and publish it on its own into Maven
> Central.  The only caveat is that we would have to rename the
> packages to ‘org.apache.river….’, since we can only publish under the
> ‘org.apache’ and ‘net.jini’ group ids.  Peter (or anyone here) could
> maintain it under River’s aegis, and other users could still get it
> out of Maven Central.
> Cheers,
> Greg
>> On Aug 12, 2015, at 3:24 PM, Patricia Shanahan <pats@acm.org>
>> wrote:
>> 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
>>>> ...

View raw message