accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <wsla...@gmail.com>
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Tue, 03 May 2016 20:33:32 GMT
They'll at least get runtime errors.

On Tue, May 3, 2016 at 4:18 PM, Mike Drob <mdrob@mdrob.com> 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