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

[Kirschner, Beth]

It looks like this was merged (thanks Aaron!) -- what is dependent on getting Sakai to work with Java 8 is is having a version of reflectutils tagged that compiles & runs with Java 8. 

- Beth

On Mar 29, 2015, at 11:34 AM, Matthew Buckett <matthew.buckett at it.ox.ac.uk> wrote:

> I've made a pull request for removing ConcurrentOrderedMap:
> 
> https://github.com/azeckoski/reflectutils/pull/6
> 
> But I don't see that this is dependent on getting Sakai to work with Java 8.
> 
> On 24 March 2015 at 12:25, Kirschner, Beth <bkirschn at umich.edu> wrote:
>> 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
>> 
> 
> 
> 
> -- 
>  Matthew Buckett, VLE Developer, IT Services, University of Oxford