If our code ends up using java 8 bytecode in any classes required by a consumer, then I think they will get compilation (linking?) errors, regardless of java 8 types in our methods signatures.
On Tue, May 3, 2016 at 3:09 PM, Josh Elser <[email protected]> wrote: > That's a new assertion ("we can't actually use Java 8 features util > Accumulo-2"), isn't it? We could use new Java 8 features internally which > would require a minimum of Java 8 and not affect the public API. These are > related, not mutally exclusive, IMO. > > To Shawn's point: introducing Java 8 types/APIs was exactly the point -- > we got here from ACCUMULO-4177 which does exactly that. > > > Mike Drob wrote: > >> I agree with Shawn's implied statement -- why bother dropping Java 7 in >> any >> Accumulo 1.x if we can't actually make use of Java 8 features.until >> Accumulo 2.0 >> >> On Tue, May 3, 2016 at 1:29 PM, Christopher<[email protected]> wrote: >> >> Right, these are competing and mutually exclusive goals, so we need to >>> decide which is a priority and on what timeline we should transition to >>> Java 8 to support those goals. >>> >>> On Tue, May 3, 2016 at 9:16 AM Shawn Walker<[email protected]> >>> wrote: >>> >>> I'm not sure that guaranteeing build-ability under Java 7 would address >>>> >>> the >>> >>>> issue that raised this discussion: We (might) want to add a dependency >>>> which requires Java 8. Or, following Keith's comment, we might wish to >>>> introduce Java 8 types (e.g. CompletableFuture<T>) into Accumulo's >>>> >>> "public" >>> >>>> API. >>>> >>>> >>>> >>>> On Mon, May 2, 2016 at 6:42 PM, Christopher<[email protected]> >>>> wrote: >>>> >>>> I don't feel strongly about this, but I was kind of thinking that we'd >>>>> >>>> bump >>>> >>>>> to Java 8 dependency (opportunistically) when we were ready to develop >>>>> >>>> a >>> >>>> 2.0 version. But, I'm not opposed to doing it on the 1.8 branch. >>>>> >>>>> On Mon, May 2, 2016 at 2:50 PM William Slacum<[email protected]> >>>>> >>>> wrote: >>> >>>> So my point about versioning WRT to the Java runtime is more about >>>>>> >>>>> how >>> >>>> there are incompatibilities within the granularity of Java versions >>>>>> >>>>> we >>> >>>> talk >>>>> >>>>>> about (I'm specifically referencing a Kerberos incompatibility within >>>>>> versions of Java 7), so I think that just blanket saying "We support >>>>>> >>>>> Java X >>>>> >>>>>> or Y" really isn't enough. I personally feel some kind of version >>>>>> >>>>> bump >>> >>>> is >>>> >>>>> nice to say that something has changed, but until the public API >>>>>> >>>>> starts >>> >>>> exposing Java 8 features, it's a total cop out to say, "Here's all >>>>>> >>>>> these >>>> >>>>> bug fixes and some new features, oh by the way upgrade your >>>>>> >>>>> infrastructure >>>>> >>>>>> because we decided to use a new Java version for an optional >>>>>> >>>>> feature". >>> >>>> The best parallel I can think of is in Scala, where there's no binary >>>>>> compatibility between minor versions (ie, 2.10, 2.11,etc), so there's >>>>>> generally an extra qualifier on libraries marking the scala >>>>>> >>>>> compability >>> >>>> level. Would we ever want to have accumulo-server-1.7-j[7|8] styled >>>>>> artifacts to signal some general JRE compatibility? It's a total >>>>>> >>>>> mess, >>> >>>> but >>>>> >>>>>> I haven't seen a better solution. >>>>>> >>>>>> Another idea is we could potentially have some guarantee for Java 7, >>>>>> >>>>> such >>>> >>>>> as making sure we can build a distribution using Java 7, but only >>>>>> distribute Java 8 artifacts by default? >>>>>> >>>>>> On Mon, May 2, 2016 at 2:30 PM, Josh Elser<[email protected]> >>>>>> >>>>> wrote: >>>> >>>>> Sean Busbey wrote: >>>>>>> >>>>>>> On Mon, May 2, 2016 at 8:55 AM, Josh Elser<[email protected]> >>>>>>>> >>>>>>> wrote: >>>>>> >>>>>>> Thanks for the input, Sean. >>>>>>>>>> >>>>>>>>>> Playing devil's advocate: we didn't have a major version bump >>>>>>>>>> >>>>>>>>> when >>>> >>>>> we >>>>>> >>>>>>> dropped JDK6 support (in Accumulo-1.7.0). Oracle has EOL'ed >>>>>>>>>> >>>>>>>>> java 7 >>>> >>>>> back in >>>>>>>>> >>>>>>>>>> April 2015. Was the 6->7 upgrade different than a 7->8 >>>>>>>>>> >>>>>>>>> upgrade? >>> >>>> On Mon, May 2, 2016 at 10:31 AM, Keith Turner<[email protected]> >>>>>>>> >>>>>>> wrote: >>>>> >>>>>> On Mon, May 2, 2016 at 1:54 AM, Sean Busbey< >>>>>>>>>> >>>>>>>>> [email protected] >>> >>>> wrote: >>>>>>>>> >>>>>>>>>> If we drop jdk7 support, I would strongly prefer a major >>>>>>>>>>>> >>>>>>>>>>> version >>>> >>>>> bump. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Whats the rationale for binding a bump to Accumulo 2.0 with a >>>>>>>>>> >>>>>>>>> bump >>>> >>>>> in >>>>>> >>>>>>> the >>>>>>>>> >>>>>>>>>> JDK version? >>>>>>>>>> >>>>>>>>>> The decision to drop JDK6 support happened in latemarch / >>>>>>>> >>>>>>> earlyApril >>>> >>>>> 2014[1], long before any of our discussions or decisions on >>>>>>>> >>>>>>> semver. >>> >>>> AFAICT it didn't get discussed again, presumably because by the >>>>>>>> >>>>>>> time >>> >>>> we got to 1.7.0 RCs it was too far in the past. >>>>>>>> >>>>>>>> Thanks for the correction, Sean. I hadn't dug around closely >>>>>>> >>>>>> enough. >>> >> >>
