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

Tue Mar 24 04:39:43 PDT 2015

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.

On 23 March 2015 at 20:29, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> How many places is keySet called? Can we just change the underlying
> collection to be one that preserves order?
>
> On Tue, Mar 24, 2015 at 3:50 AM, Matthew Jones <matthew at longsight.com>
> wrote:
>>
>> As of the latest version, all of the tests pass and the source builds.
>>
>> I haven't tested it with Sakai though, to do that you'd have to
>> - Download and build this reflectutils with Java 8
>> - Update master
>>   - Change the reflectutils.version in master to 0.9.20-SNAPSHOT
>>   - Change the sakai.jdk.version to 1.8
>> -  Do a full build/deploy of the entire Sakai code base
>> - Test out the places where it was used, running on Java 8.
>>
>> It seems like it's almost entirely used in Sakai entities providers so
>> that seems like it wouldn't make any issues very obvious.
>>
>> I believe there might be some test failures and anything calling keySet is
>> going to have to be changed to use legacyKeySet. In Java 8 the return value
>> of keySet was changed and the keySet in reflectutils is designed to preserve
>> insertion order. The keySet returned calling in in Java 8 (verses previously
>> in java 7) will return the keys in a random order and *possibly* cause
>> runtime (or hopefully test) errors.
>>
>> The only solution for this was to
>> 1) Leave keySet as is, returning incorrect results (this was PR #1)
>> 2) Implement keySet and have it return null (and also log that it was used
>> so it can be switched). This would work and be more obvious it's broken, but
>> would break Java 7 compatibility for the jar.
>> 3) Fix keySet to return correct values. This seemed like it would take
>> some work, especially if we wanted to support Java 7 and 8 by having both
>> versions correctly compile in a profile. The resulting jar though would be
>> specific to each version. This is how many libraries lately have to release.
>>
>> 2 & 3 are ugly but I feel like we might have to go down that road to
>> identify all of the usages.
>>
>> On Mon, Mar 23, 2015 at 12:35 PM, Kirschner, Beth <bkirschn at umich.edu>
>> wrote:
>>>
>>> Has anyone else been able to test this? We'd like to try and update to
>>> Java 8 this summer, and while we could tag a forked copy of reflectutils, it
>>> would be nice if we could just use a released 0.9.20 version.
>>>
>>> Thanks,
>>> - Beth
>>>
>>> On Mar 11, 2015, at 11:40 AM, "Kirschner, Beth" <bkirschn at umich.edu>
>>> wrote:
>>>
>>> > FYI  - Aaron merged this request several days ago, so we're onto step
>>> > #3 -- it would be great if someone else on this list could test out the
>>> > reflectutils change on Java 8 to verify it works. It worked for me when I
>>> > tested a week or two ago.
>>> >
>>> > Thanks,
>>> > - Beth
>>> >
>>> > On Mar 6, 2015, at 10:17 AM, "Kirschner, Beth" <bkirschn at umich.edu>
>>> > wrote:
>>> >
>>> >> Pull request created -- Aaron, can you take a look?
>>> >>
>>> >> - Beth
>>> >>
>>> >> On Mar 4, 2015, at 4:02 PM, Matthew Jones <matthew at longsight.com>
>>> >> wrote:
>>> >>
>>> >>> This is moved over to github as mentioned on the ticket.
>>> >>> (https://github.com/azeckoski/reflectutils) There is still some work to do.
>>> >>> Ideally the people mentioned below would do it but I can do it if you'd
>>> >>> rather.
>>> >>>
>>> >>> 1) Beth - Move the patch over as a pull request against this
>>> >>> repository
>>> >>> 2) Aaron - Merge the pull request after Beth submits it
>>> >>> 3) Anyone on this list - Build and test out new snapshot version with
>>> >>> JDK8 in a tool that uses reflect utils. I don't think it was able to
>>> >>> compiled with JDK8 and I feel like signup was causing problems running in
>>> >>> JDK8.
>>> >>> 4) Aaron - Release reflectutils 0.9.20 after verified
>>> >>> 5) Matt - Update Sakai master to reference this new version
>>> >>>
>>> >>> As far as the release step #4, I'd also be happy to do that and
>>> >>> change it over to sonatype if given access to this repository in github.
>>> >>> That would make more sense than forking it and releasing this fork.
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>> On Thu, Feb 26, 2015 at 5:07 PM, Kirschner, Beth <bkirschn at umich.edu>
>>> >>> wrote:
>>> >>> I haven't seen any activity on this thread in a few weeks (though I'm
>>> >>> catching up from a vacation and might have missed it) -- has there been any
>>> >>> decision? I think moving forward with Steve's proposal makes the most
>>> >>> practical sense.
>>> >>>
>>> >>> Thoughts?
>>> >>> - Beth
>>> >>>
>>> >>> On Feb 12, 2015, at 5:13 PM, Steve Swinsburg
>>> >>> <steve.swinsburg at gmail.com> wrote:
>>> >>>
>>> >>>> What about a sakai-libs repo under sakai org, much like contrib but
>>> >>>> a place where we hold libraries we use for stuff that isn't core, isn't
>>> >>>> contrib and isn't really Sakai. Like forks of other projects, sakai wicket,
>>> >>>> rsf, etc.
>>> >>>>
>>> >>>> On 13 Feb 2015 08:42, "AZ" <azeckoski at gmail.com> wrote:
>>> >>>> Let's petition github to give me more space for free. That is the
>>> >>>> best option for sure (for me).
>>> >>>>
>>> >>>> --
>>> >>>> Aaron Zeckoski - Lead Architect for Elsevier Education
>>> >>>>
>>> >>>> On Feb 12, 2015, at 16:26, Charles Severance <csev at umich.edu> wrote:
>>> >>>>
>>> >>>>>
>>> >>>>> On Feb 12, 2015, at 3:20 PM, Matthew Jones <matthew at longsight.com>
>>> >>>>> wrote:
>>> >>>>>
>>> >>>>>> Yeah, I agree that we can't just assume that these projects are
>>> >>>>>> only used by Sakai. They don't have any explicit dependencies on Sakai, so
>>> >>>>>> while I'd be okay with them living in a sakaiproject space as a separate
>>> >>>>>> project, not in the sakaiproject/sakai unless they were specific to Sakai.
>>> >>>>>> Something that *should* be in sakaiproject/sakai that isn't would be
>>> >>>>>> something like SakaiRSF (https://github.com/rsf/SakaiRSF) since that's an
>>> >>>>>> RSF piece that has no use outside of Sakai, but RSF in general would stay
>>> >>>>>> separate.
>>> >>>>>
>>> >>>>>
>>> >>>>>>> On Thu, Feb 12, 2015 at 12:06 PM, Kirschner, Beth
>>> >>>>>>> <bkirschn at umich.edu> wrote:
>>> >>>>>>> I believe I have Sakai building & running with Java 8 -- the only
>>> >>>>>>> outstanding issue is reflectutils. I've attached a patch to Aaron's google
>>> >>>>>>> svn repo, and also sent him an email to his gmail address, but haven't heard
>>> >>>>>>> anything back. I wonder if we should move this dependency into github?
>>> >>>>>>>
>>> >>>>>>> Thoughts?
>>> >>>>>>> - Beth
>>> >>>>>
>>> >>>>> Matt -
>>> >>>>>
>>> >>>>> I was answering a *very specific question*.   If Aaron has stopped
>>> >>>>> maintaining reflectutils - and so to get our patch in, we are forced to fork
>>> >>>>> it to perhaps bkirschn/reflectutils, then we might just as well fork it
>>> >>>>> right into Sakai and forget about the original repo.  While other projects
>>> >>>>> "might" use it - if the repo is not going to be maintained - it is dead.  We
>>> >>>>> do not need to worry about the effect on those "other adopters" - we need to
>>> >>>>> worry about our use of the code and the simple fact that we depend heavily
>>> >>>>> on this code and are likely the single largest user of the code and that
>>> >>>>> probably all the other users of the code are some legacy thing deep inside
>>> >>>>> Unicon that will never be updated.
>>> >>>>>
>>> >>>>> If the patch gets applied and a release gets made - then the repo
>>> >>>>> is not dead and I withdraw my suggestion.  My suggestion only triggers when
>>> >>>>> the original repo is dead.
>>> >>>>>
>>> >>>>> A middle ground might be to for it to sakai/reflectutils.  But that
>>> >>>>> would be silly too - as it would mean that we would need to release our
>>> >>>>> little reflectutils and then release Sakai based on that release.   Just
>>> >>>>> simplify it all - fork it and put it in our repo and tag/branch our version
>>> >>>>> with our own tagging scheme.
>>> >>>>>
>>> >>>>> We depend heavily on these bits of code and it is *highly unlikely*
>>> >>>>> that we could switch to anything else without breaking upwards compatibility
>>> >>>>> with who knows how many bits that have now hard coded to the exact
>>> >>>>> conventions of /direct and entitybroker.
>>> >>>>>
>>> >>>>> When you are the only real customer for something that you depend
>>> >>>>> heavily on - there is little value in maintaining the sham of
>>> >>>>> "independence".
>>> >>>>>
>>> >>>>> I understand that I won't win this argument - I just bring it back
>>> >>>>> from time to time in hopes of removing dependencies on code that is
>>> >>>>> effectively dead-end.
>>> >>>>>
>>> >>>>> /Chuck
>>> >>>>>
>>> >>>>> P.S. Rhetorical question: What happens if Aaron deletes his repo
>>> >>>>> because he ran out of space on github?
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> sakai-core-team mailing list
>>> >>>>> sakai-core-team at collab.sakaiproject.org
>>> >>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> sakai-core-team mailing list
>>> >>>> sakai-core-team at collab.sakaiproject.org
>>> >>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> sakai-core-team mailing list
>>> >>>> sakai-core-team at collab.sakaiproject.org
>>> >>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>> >>>
>>> >>> _______________________________________________
>>> >>> sakai-core-team mailing list
>>> >>> sakai-core-team at collab.sakaiproject.org
>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>> >>>
>>> >>
>>> >
>>>
>>
>
>
> _______________________________________________
> 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