[sakai-core-team] [Building Sakai] Java 8

[Kirschner, Beth]

I had the same thoughts about ConcurrentOrderedMap  - I could test and submit a PR that removes this class if Aaron is amenable.

- Beth

On Mar 24, 2015, at 8:04 AM, Matthew Buckett <matthew.buckett at it.ox.ac.uk> wrote:

> On 24 March 2015 at 11:39, Matthew Buckett <matthew.buckett at it.ox.ac.uk> wrote:
>> I couldn't see any references to ConcurrentOrderedMap in the current
>> Sakai codebase. The bug with EntityBroker tests failing should be
>> fixed by:
>> 
>> https://github.com/azeckoski/reflectutils/commit/4b33c37e8e29f3a260817d9218a5d32e145377aa
>> 
>> which was a problem with the assumption that the superclass would call
>> put() when putAll() was called.
>> 
>> I'd just drop ConcurrentOrderedMap from reflectutils so that people
>> don't start using it in the future.
> 
> Looking a little ConcurrentOrderedMap has a few issues:
> - It loses the performance characteristics of ConcurrentHashMap as it
> has an internal Vector which limits it's concurrency.
> - #putIfAbsent(K, V) isn't thread safe. It calls containsKey and then
> put, but doesn't do it atomically so it's not deterministic.
> - #remove(key, value) isn't thread safe. It removes the entry from the
> ConcurrentHashMap and then removes it from the internal Vector without
> any locking (another thread could be adding in between this).
> 
> So I'd be even more incline to remove it as it's not really a good
> implementation of the API and seems like it was just created for
> completeness.
> 
> -- 
>  Matthew Buckett, VLE Developer, IT Services, University of Oxford
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team