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 20:07:45 GMT
I intend to remove mock, and other deprecated stuffs (aggregators!) in 2.0.
But, that's exactly my point. Removing or changing these things required a
bump in 2.0, so discussions about whether or not we'd need to bump to 2.0
with the jdk8 switch were moot (unless we were willing to disable
modernizer, of course).

To Josh's question, unfortunately, modernizer has a fail/no-fail mode, but
it doesn't allow custom exceptions like findbugs. It's more like checkstyle
in that way. It's either on or off.

On Fri, May 6, 2016 at 12:11 PM Josh Elser <josh.elser@gmail.com> wrote:

> +1 to that, too
>
> Dave Marion wrote:
> > It's 2.0, remove mock and deprecate it in 1.8 if it's not already.
> > On May 6, 2016 10:25 AM, "Josh Elser"<josh.elser@gmail.com>  wrote:
> >
> > We can't disable modernizer just for mock? Or really, any code which we
> > intentionally don't want to modernize?
> > On May 5, 2016 11:43 PM, "Christopher"<ctubbsii@apache.org>  wrote:
> >
> >> Another interesting point... didn't realize until actually doing it:
> >> bumping to JDK8 *requires* a bump in the major version, because
> modernizer
> >> will block on some incompatible API changes in Mock, which is already
> >> deprecated. (Unless we're okay with disabling modernizer... which I
> guess
> >> is an acceptable solution... but it makes me unhappy :) )
> >>
> >> On Thu, May 5, 2016 at 11:39 PM Josh Elser<josh.elser@gmail.com>
> wrote:
> >>
> >>> Thanks boss. I figured you'd have my back :)
> >>> On May 5, 2016 9:43 PM, "Christopher"<ctubbsii@apache.org>  wrote:
> >>>
> >>>> 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