accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Fri, 06 May 2016 01:43:28 GMT
Already pushed. Initially forgot about modernizer, but I'm working through
it now.

On Thu, May 5, 2016 at 7:25 PM Josh Elser <josh.elser@gmail.com> wrote:

> Sounds good!
>
> I had tried to switch master to jdk8 as well, but ran into modernizer
> plugin issues. I've since been on a call, so I haven't been able to push
> that update. I'll get to it when I can, but perhaps someone has beaten
> me to it already.
>
> Christopher wrote:
> > Okay, so if we're okay treating the master branch as a 2.0 development
> > branch, then I'm going to go ahead and start focusing on some 2.0 tickets
> > that may involve refactoring which have breaking changes that I've been
> > reluctant to do before without an explicit 2.0 development branch. Of
> > course, none of this says we have to stop development on 1.x stuffs, or
> > says anything about when we'll release a 2.0, but it'd be nice to have a
> > place to start putting in stuff for an eventual 2.0.
> >
> > On Thu, May 5, 2016 at 11:07 AM Josh Elser<josh.elser@gmail.com>  wrote:
> >
> >> Ok, looks to me that we are in agreement now and don't need a vote.
> >>
> >> I will create a 1.8 branch today (updating Jenkins appropriately) so we
> >> can get master in a state that would be ready for the changes in 4177.
> >>
> >> Keith Turner wrote:
> >>> On Tue, May 3, 2016 at 4:54 PM, Christopher<ctubbsii@apache.org>
>  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<josh.elser@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.elser@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<ctubbsii@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<
> >>>> accumulo@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<ctubbsii@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<
> wslacum@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.elser@gmail.com
> >>>>>>>>>>> wrote:
> >>>>>>>>>>> Sean Busbey wrote:
> >>>>>>>>>>>>> On Mon, May 2, 2016 at 8:55 AM,
Josh Elser<
> >> josh.elser@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<keith@deenlo.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>      On Mon, May 2, 2016 at 1:54 AM,
Sean Busbey<
> >>>>>>>>>>>>>>> busbey@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message