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.
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 <josh.el...@gmail.com> 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<josh.el...@gmail.com> 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<ctubb...@apache.org>
> 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<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.
> >>>
> >
>
