Bumping this.
Given we see the occassional build breaks with Java 8, we should reconsider
this and do it for 2.2 or 2.3. By the time 2.2 is released, it will almost
be an year since this thread started.
On Sun, Jul 24, 2016 at 12:59 AM, Mark Hamstra
wrote:
> Sure, signalling well ahead of time
BTW I created a JIRA ticket for tracking:
https://issues.apache.org/jira/browse/SPARK-19493
We of course shouldn't do anything until we achieve consensus.
On Tue, Feb 7, 2017 at 3:47 PM, Reynold Xin wrote:
> Bumping this.
>
> Given we see the occassional build breaks with Java 8, we should
> r
On 23 Jul 2016, at 23:59, Mark Hamstra
mailto:m...@clearstorydata.com>> wrote:
Sure, signalling well ahead of time is good, as is getting better performance
from Java 8; but do either of those interests really require dropping Java 7
support sooner rather than later?
Now, to retroactively cop
BTW - "signalling ahead of time" is called deprecating, not dropping
support...
(personally I only use JDK 8 / Scala 2.11 so I'm for it)
Ofir Manor
Co-Founder & CTO | Equalum
Mobile: +972-54-7801286 | Email: ofir.ma...@equalum.io
On Sun, Jul 24, 2016 at 1:50 AM, Koert Kuipers wrote:
> i care
I had favored this for 2.0 even, so favor it sooner than later.
The general shape of the argument is:
- supporting Java 7 is starting to pinch a little because of extra
builds and the inevitable gap between what the PR builder (7) tests
and what the later Java 8 tests runs show
- requiring Java 8
Hi, All.
What about providing a official benchmark result between `Apache Spark on
JDK7` and `Apache Spark on JDK8`?
I think that is enough for this issue since we cannot drive users.
We had better let users choose one of JDK7/JDK8 for their own benefits.
Bests,
Dongjoon.
On Sat, Jul 23, 2016
They don't require dropping it sooner rather than later. But signalling in
some way that java 8 is (strongly) recommend would be good.
On Jul 23, 2016 6:59 PM, "Mark Hamstra" wrote:
> Sure, signalling well ahead of time is good, as is getting better
> performance from Java 8; but do either of th
Sure, signalling well ahead of time is good, as is getting better
performance from Java 8; but do either of those interests really require
dropping Java 7 support sooner rather than later?
Now, to retroactively copy edit myself, when I previously wrote "after all
or nearly all relevant clusters ar
i care about signalling it in advance mostly. and given the performance
differences we do have some interest in pushing towards java 8
On Jul 23, 2016 6:10 PM, "Mark Hamstra" wrote:
Why the push to remove Java 7 support as soon as possible (which is how I
read your "cluster admins plan to migrat
Why the push to remove Java 7 support as soon as possible (which is how I
read your "cluster admins plan to migrate by date X, so Spark should end
Java 7 support then, too")? First, I don't think we should be removing
Java 7 support until some time after all or nearly all relevant clusters
are act
dropping java 7 support was considered for spark 2.0.x but we decided
against it.
ideally dropping support for a java version should be communicated far in
advance to facilitate the transition.
is this the right time to make that decision and start communicating it
(mailing list, jira, etc.)? per
11 matches
Mail list logo