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

[Matthew Jones]

Right,

We could possibly build and publish the snapshots for a short term
solution, but we'd need a new version of reflectutils released (and tagged
as part of that process) prior to the final 11 release. If it was
released/tagged it would overall be better than relying on snapshots.

On Mon, Mar 30, 2015 at 8:14 AM, Kirschner, Beth <bkirschn at umich.edu> wrote:

> 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
>
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20150330/e98d5eb7/attachment.html