On Tue, May 3, 2016 at 4:54 PM, Christopher <[email protected]> wrote:
> I think I'd prefer leaving 1.8 as it stands, with the expectation to have a > release line of 1.8 which only requires Java 7. > +1 I can not see any reason to switch to JDK8 before releasing 1.8... assuming thats going to happen soonish > > We can create a 2.0 branch, which bumps the Java version, and can accept > changes which require Java 8 or API-breaking changes (as per semver) for > the next major release line after 1.8. > > That would put us on a solid roadmap for 2.0 without disrupting 1.8 > development, which is probably already nearing release readiness. > > On Tue, May 3, 2016 at 4:33 PM Josh Elser <[email protected]> wrote: > > > Gotcha. Thanks for clarifying, Mike -- I'm inclined to agree with you. I > > can't think of a reason why we would upgrade to Java8 and not make use > > of it in some way (publicly or privately). > > > > That being said, I don't think I see consensus. How about we regroup in > > the form of a vote? (normal semver rules are an invariant -- no changes > > to our public API compatibility rules are implied by the below) > > > > * Call the current 1.8.0-SNAPSHOT (master) "2.0.0-SNAPSHOT" and move to > > jdk8 > > * Branch 1.8, make master 2.0.0-SNAPSHOT. 1.8 stays jdk7, 2.0 goes jdk8 > > > > Please chime in if I missed another option or am calling discussion too > > soon. It just seems like we might have veered off-track and I don't want > > this to fall to the wayside (again) without decision. > > > > Mike Drob wrote: > > > 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. > > >>> > > > > > >
