Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

[Josh Elser]

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.el...@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<ctubb...@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<accum...@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<ctubb...@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<wsla...@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.el...@gmail.com>

wrote:
Sean Busbey wrote:
On Mon, May 2, 2016 at 8:55 AM, Josh Elser<josh.el...@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<ke...@deenlo.com>
wrote:
   On Mon, May 2, 2016 at 1:54 AM, Sean Busbey<
bus...@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.