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

Steve Swinsburg steve.swinsburg at gmail.com
Mon Mar 23 13:29:09 PDT 2015 

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
>> >>>
>> >>
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20150324/61e0b106/attachment.html

More information about the sakai-core-team mailing list