[email protected] wrote:
Branch 1.8, leave at JDK 7 Move master to 2.0.0-SNAPSHOT and: -> Move to JDK 8 -> Remove deprecated items -> Bump versions for dependencies (*Htrace issue)Question: Could we release 1.8.0 and 2.0.0 around the same time such that 2.0.0 is equivalent to 1.8.0 except for the changes mentioned above? ----- Original Message ----- From: "Josh Elser"<[email protected]> To: [email protected] Sent: Tuesday, May 3, 2016 4:33:39 PM Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache) 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<[email protected]> 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<[email protected]> wrote: Right, these are competing and mutually exclusive goals, so we need todecide 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<[email protected]> wrote: I'm not sure that guaranteeing build-ability under Java 7 would address theissue 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<[email protected]> wrote: I don't feel strongly about this, but I was kind of thinking that we'd bumpto Java 8 dependency (opportunistically) when we were ready to developa 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<[email protected]>wrote: So my point about versioning WRT to the Java runtime is more abouthowthere are incompatibilities within the granularity of Java versionswetalkabout (I'm specifically referencing a Kerberos incompatibility within versions of Java 7), so I think that just blanket saying "We supportJava Xor Y" really isn't enough. I personally feel some kind of versionbumpisnice to say that something has changed, but until the public API startsexposing Java 8 features, it's a total cop out to say, "Here's allthese bug fixes and some new features, oh by the way upgrade your infrastructurebecause we decided to use a new Java version for an optionalfeature".The best parallel I can think of is in Scala, where there's no binarycompatibility between minor versions (ie, 2.10, 2.11,etc), so there's generally an extra qualifier on libraries marking the scalacompabilitylevel. Would we ever want to have accumulo-server-1.7-j[7|8] styledartifacts to signal some general JRE compatibility? It's a totalmess,butI 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 onlydistribute Java 8 artifacts by default? On Mon, May 2, 2016 at 2:30 PM, Josh Elser<[email protected]>wrote: Sean Busbey wrote:On Mon, May 2, 2016 at 8:55 AM, Josh Elser<[email protected]> wrote: Thanks for the input, Sean.Playing devil's advocate: we didn't have a major version bumpwhenwedropped JDK6 support (in Accumulo-1.7.0). Oracle has EOL'edjava 7back inApril 2015. Was the 6->7 upgrade different than a 7->8upgrade?On Mon, May 2, 2016 at 10:31 AM, Keith Turner<[email protected]>wrote:On Mon, May 2, 2016 at 1:54 AM, Sean Busbey<[email protected]wrote:If we drop jdk7 support, I would strongly prefer a majorversionbump.Whats the rationale for binding a bump to Accumulo 2.0 with abumpintheJDK version? The decision to drop JDK6 support happened in latemarch /earlyApril2014[1], long before any of our discussions or decisions onsemver.AFAICT it didn't get discussed again, presumably because by thetimewe got to 1.7.0 RCs it was too far in the past.Thanks for the correction, Sean. I hadn't dug around closelyenough.
