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

Matthew Jones matthew at longsight.com
Mon Mar 23 13:49:45 PDT 2015 

I don't know how many places *this* keySet is called this is a special

reflectutils/map/ConcurrentOrderedMap.java -> keySet that overrides the
ConcurrentHashMap keySet.

It seems like you'd have to do a search and replace keySet->legacyKeySet
and then everything that doesn't break when compiled is code that needs to
change! ;)

In Java 8 the return for this changed to

ConcurrentHashMap.KeySetView<K,V> keySet()

And I can't figure out how to (easily) fix this so that this method returns
essentially what the old keySet (Set <K>) returned which is legacyKeySet.
See KeySetView cannot be directly instantiated. [1]

So someone fixing this will need to go through newKeySet but that returns a
KeySetView <K,Boolean> which was giving errors because it can't return
<K,Boolean> into <K,V>. So doesn't seem to be an option.

So it seems like you have to implement everything all the way down the
chain that is a new ConcurrentOrderedMap->KeySet and a few other things.
(That's how it was previously, KeySet in here preserves order)

Someone could probably get this working, but then you'd still have a
version that's incompatible with Java 7, and we'd have to either release 2
versions, or never release another Java 7 version. I'm guessing at this
point Java 8 requirement is going to be a blocker and a minimum requirement
for Sakai 11 so maybe that's not a big deal, but there are a few other
things necessary too before it gets there.

Anyway, if someone wants to take a stab at that and submit a PR it's in
github! [2] I didn't have any additional time and wanted to take a step
back before moving forward with it.

[1]
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.KeySetView.html
[2] https://github.com/azeckoski/reflectutils

On Mon, Mar 23, 2015 at 4:29 PM, 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
>>> >>>
>>> >>
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20150323/736a4c55/attachment-0001.html

More information about the sakai-core-team mailing list