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 <accum...@shawn-walker.net> 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 <ctubb...@apache.org> 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 <wsla...@gmail.com> 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 <josh.el...@gmail.com> > wrote: > > > > > > > Sean Busbey wrote: > > > > > > > >> On Mon, May 2, 2016 at 8:55 AM, Josh Elser<josh.el...@gmail.com> > > > 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<ke...@deenlo.com> > > wrote: > > > >> > > > >>> > On Mon, May 2, 2016 at 1:54 AM, Sean Busbey<bus...@cloudera.com > > > > > >>> 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. > > > > > > > > > >
