accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Fri, 06 May 2016 16:11:07 GMT
+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
View raw message