accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <md...@mdrob.com>
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Tue, 03 May 2016 20:18:41 GMT
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