They'll at least get runtime errors. On Tue, May 3, 2016 at 4:18 PM, Mike Drob <[email protected]> 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. > >>> > >> > >> >
