Right, _other than caching_, we are not getting much from Guava that we couldn't get from Commons libraries or Java 8 itself.
Before delving any further into caching, are there other examples of things that we are getting from Guava besides caching? I'm just trying to determine whether we even have the option of excluding it from a baseline, modulo another solution for caching. --- A. Soroka The University of Virginia Library > On Apr 6, 2017, at 11:45 AM, Andy Seaborne <[email protected]> wrote: > > I was responding to "or Java 8 itself" > > On 06/04/17 16:38, A. Soroka wrote: >> No, I didn't mean LinkedHashMap. That's why I said "But other than that, " >> about caching. I'm saying that caching is the one thing that I can think of >> that is really truly substantive that we are getting from Guava. >> >> There is a Commons caching component: >> >> https://commons.apache.org/proper/commons-jcs// >> >> But I know nothing (yet) about it. It looks like it is targeted a bit >> differently. >> >> --- >> A. Soroka >> The University of Virginia Library >> >>> On Apr 6, 2017, at 11:34 AM, Andy Seaborne <[email protected]> wrote: >>> >>> Java8 caching - which I take to mean LinkedHashMap was what TDB used to use >>> and changed away from. It really isn't sophisticated enough. >>> >>> I'm not going to rework it all again. Any change has to be better, not >>> just equivalent, let alone needing a bunch of machinery around it. >>> >>> Andy >>> >>> On 06/04/17 16:19, A. Soroka wrote: >>>> Lost this thread for a while, but found it again! >>>> >>>> For comparison with Andy's lists below, the Jena Karaf feature calls out: >>>> >>>> com.github.andrewoma.dexx/collection >>>> com.github.jsonld-java/jsonld-java >>>> com.fasterxml.jackson.core/jackson-core >>>> com.fasterxml.jackson.core/jackson-databind >>>> com.fasterxml.jackson.core/jackson-annotations >>>> org.apache.httpcomponents/httpcore-osgi >>>> org.apache.httpcomponents/httpclient-osgi >>>> org.apache.commons/commons-csv >>>> org.apache.commons/commons-lang3 >>>> commons-io/commons-io >>>> org.apache.thrift/libthrift >>>> >>>> Which isn't too surprising. That seems like a pretty reasonable baseline >>>> for our core functionality. Obviously, Fuseki needs to add some stuff to >>>> that, as does the CLI gear. >>>> >>>> The caching question is a big one-- that's clearly pretty important >>>> functionality. But other than that, my (very loose and barely informed) >>>> sense is that we aren't using much from Guava that we couldn't get from >>>> Commons libraries or Java 8 itself. >>>> >>>> --- >>>> A. Soroka >>>> The University of Virginia Library >>>> >>>>> On Apr 2, 2017, at 11:05 AM, Andy Seaborne <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> On 02/04/17 15:08, A. Soroka wrote: >>>>>>> I’m not sure that it is necessarily safe to stop shading Guava. It is a >>>>>>> widely used library with poor compatibility between versions and our >>>>>>> users may experience Version conflicts in other environments. >>>>>> >>>>>> I've not got a good notion right now of how heavy our dependency is on >>>>>> Guava (although I know I have increased it myself by using it various >>>>>> places!) >>>>>> >>>>>> Does it seem (for the long term) worth investigating the possibilities >>>>>> of moving off Guava entirely? >>>>> >>>>> Is it more nuanced than that? I have been using Guava's caching whenever >>>>> I need a cache. There are other possibilities. (Commons JCS, >>>>> commons-collections4#map.LRUMap >>>>> >>>>> Can we agree on what we consider the base dependencies (commons-lang3, >>>>> commons-io, commons-codec etc)? >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>> Mentions in POMs for commons-* >>>>> >>>>> == jena-parent >>>>> commons-cli >>>>> commons-codec >>>>> commons-collections4 >>>>> commons-csv >>>>> commons-fileupload >>>>> commons-io >>>>> commons-lang3 >>>>> >>>>> == jena-fuseki1 >>>>> commons-io >>>>> commons-logging >>>>> commons-fileupload >>>>> >>>>> == jena-core >>>>> commons-cli >>>>> >>>>> == jena-permissions >>>>> commons-collections4 >>>>> commons-lang3 >>>>> >>>>> == jena-text >>>>> commons-codec >>>>> >>>>> == jena-fuseki-core >>>>> commons-logging >>>>> commons-fileupload >>>>> commons-io >>>>> >>>>> == jena-arq >>>>> commons-csv >>>>> commons-lang3 >>>>> >>>>> == jena-base >>>>> commons-csv >>>>> commons-lang3 >>>>> >>>>> == jena-osgi/pom.xml >>>>> commons-codec >>>>> commons-csv >>>>> commons-lang3 >>>>> >>>>> >>>>> **** Excluded: >>>>> commons-logging >>>>> >>>>> >>>>>> >>>>>> --- >>>>>> A. Soroka >>>>>> The University of Virginia Library >>>>>> >>>>>>> On Mar 31, 2017, at 9:34 AM, Rob Vesse <[email protected]> wrote: >>>>>>> >>>>>>> Yes that would be a good idea >>>>>>> >>>>>>> You should just be able to change a single property and see if it Will >>>>>>> compile. See the instructions on the website: >>>>>>> >>>>>>> http://jena.apache.org/documentation/hadoop/artifacts.html >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>> On 31/03/2017 13:57, "A. Soroka" <[email protected]> wrote: >>>>>>> >>>>>>> So for next steps, should someone (aka me) try to build against a 3.X >>>>>>> Hadoop to see where the jolts are? Does that make sense as a way to >>>>>>> gather more info? I would just go ahead and do it, but lacking (as I >>>>>>> do) any Hadoop dev experience, I want to make sure that it's a good >>>>>>> idea before investing time. >>>>>>> >>>>>>> --- >>>>>>> A. Soroka >>>>>>> The University of Virginia Library >>>>>>> >>>>>>>> On Mar 31, 2017, at 5:11 AM, Rob Vesse <[email protected]> wrote: >>>>>>>> >>>>>>>> My impression is that 3.0 is still a long way off a generally >>>>>>>> available release since they are still in Alpha at the moment. >>>>>>>> >>>>>>>> I would expect that 2.x would remain the primary distribution for a >>>>>>>> while yet. >>>>>>>> >>>>>>>> I don’t know how much, If at all, map/reduce has changed so it may >>>>>>>> already be possible to build Elephas against 3.X without any changes >>>>>>>> but then again it might not. >>>>>>>> >>>>>>>> I’m not sure that it is necessarily safe to stop shading Guava. It is >>>>>>>> a widely used library with poor compatibility between versions and our >>>>>>>> users may experience Version conflicts in other environments. >>>>>>>> >>>>>>>> Rob >>>>>>>> >>>>>>>> On 29/03/2017 00:18, "Bruno P. Kinoshita" <[email protected]> wrote: >>>>>>>> >>>>>>>>> I would think we could go with a minor version for this, no? Or is >>>>>>>> Elephas such a big part of our offering that we need to make a major >>>>>>>> release to move with Hadoop...? >>>>>>>> >>>>>>>> >>>>>>>> I would think the same. Unless we have other important features to be >>>>>>>> released, maybe something that breaks backward compatibility, etc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: A. Soroka <[email protected]> >>>>>>>> To: [email protected] >>>>>>>> Sent: Wednesday, 29 March 2017 3:20 AM >>>>>>>> Subject: Re: [jira] [Updated] (HADOOP-10101) Update guava dependency >>>>>>>> to the latest version >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> * Jena would have to move in step with Hadoop and drop support for >>>>>>>>> older versions. >>>>>>>> >>>>>>>> Maybe we can see what Hadoop itself ends up doing for this problem... >>>>>>>> they are targeting their own major release 3 for this. I would think >>>>>>>> we could go with a minor version for this, no? Or is Elephas such a >>>>>>>> big part of our offering that we need to make a major release to move >>>>>>>> with Hadoop...? >>>>>>>> >>>>>>>> --- >>>>>>>> A. Soroka >>>>>>>> The University of Virginia Library >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 25, 2017, at 7:15 AM, Andy Seaborne <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Step 1: upgrade jena-shaded-guava to v21.0 >>>>>>>>> >>>>>>>>> and see if it works. >>>>>>>>> >>>>>>>>> >>>>>>>>> There are at least two considerations: >>>>>>>>> >>>>>>>>> * Jena would have to move in step with Hadoop >>>>>>>>> and drop support for older versions. >>>>>>>>> * Our downstream users may have guava version choices. >>>>>>>>> >>>>>>>>> and we have to wait until a Hadoop release to remove it. >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> On 25/03/17 01:22, A. Soroka wrote: >>>>>>>>>> Looks like Hadoop has successfully updated their Guava dependency-- >>>>>>>>>> this might provide us the opportunity to stop shading Guava. (yay!) >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> A. Soroka >>>>>>>>>> The University of Virginia Library >>>>>>>>>> >>>>>>>>>>> Begin forwarded message: >>>>>>>>>>> >>>>>>>>>>> From: "Tsuyoshi Ozawa (JIRA)" <[email protected]> >>>>>>>>>>> Subject: [jira] [Updated] (HADOOP-10101) Update guava dependency to >>>>>>>>>>> the latest version >>>>>>>>>>> Date: March 24, 2017 at 9:18:42 PM EDT >>>>>>>>>>> To: [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [ >>>>>>>>>>> https://issues.apache.org/jira/browse/HADOOP-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>>>>>>>>>> ] >>>>>>>>>>> >>>>>>>>>>> Tsuyoshi Ozawa updated HADOOP-10101: >>>>>>>>>>> ------------------------------------ >>>>>>>>>>> Resolution: Fixed >>>>>>>>>>> Fix Version/s: 3.0.0-alpha3 >>>>>>>>>>> Status: Resolved (was: Patch Available) >>>>>>>>>>> >>>>>>>>>>> Committed this to trunk. Thanks Nicholas and Steve for your review, >>>>>>>>>>> and thanks people who joined this issue for your comments. >>>>>>>>>>> >>>>>>>>>>>> Update guava dependency to the latest version >>>>>>>>>>>> --------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> Key: HADOOP-10101 >>>>>>>>>>>> URL: https://issues.apache.org/jira/browse/HADOOP-10101 >>>>>>>>>>>> Project: Hadoop Common >>>>>>>>>>>> Issue Type: Improvement >>>>>>>>>>>> Affects Versions: 3.0.0-alpha2 >>>>>>>>>>>> Reporter: Rakesh R >>>>>>>>>>>> Assignee: Tsuyoshi Ozawa >>>>>>>>>>>> Labels: BB2015-05-TBR >>>>>>>>>>>> Fix For: 3.0.0-alpha3 >>>>>>>>>>>> >>>>>>>>>>>> Attachments: HADOOP-10101-002.patch, HADOOP-10101-004.patch, >>>>>>>>>>>> HADOOP-10101-005.patch, HADOOP-10101-006.patch, >>>>>>>>>>>> HADOOP-10101-007.patch, HADOOP-10101-008.patch, >>>>>>>>>>>> HADOOP-10101-009.patch, HADOOP-10101-009.patch, >>>>>>>>>>>> HADOOP-10101-010.patch, HADOOP-10101-010.patch, >>>>>>>>>>>> HADOOP-10101-011.patch, HADOOP-10101.012.patch, >>>>>>>>>>>> HADOOP-10101.013.patch, HADOOP-10101.014.patch, >>>>>>>>>>>> HADOOP-10101.015.patch, HADOOP-10101.016.patch, >>>>>>>>>>>> HADOOP-10101.017.patch, HADOOP-10101.018.patch, >>>>>>>>>>>> HADOOP-10101.patch, HADOOP-10101.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The existing guava version is 11.0.2 which is quite old. This >>>>>>>>>>>> issue tries to update the version to as latest version as possible. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> This message was sent by Atlassian JIRA >>>>>>>>>>> (v6.3.15#6346) >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>
