Just to clarify, this is an example of a change I had to do to get the code
working with Scala 2.12. With Scala 2.11 this works:
val terminate = prevPaths
.coGroup(nextPaths)
.where(0).equalTo(0) {
(prev, next, out: Collector[(Long, Long)]) => {
val prevPaths = prev.toSet
for
I think there was no conclusion so I didn't go for breaking the API in the end.
What this means for users is:
- when using Scala 2.11 nothing changes
- you can now use Scala 2.12, but you might have to add explicit types to
disambiguate calls. This disambiguation is not needed when using Scala
I was wondering about the outcome of this discussion on what it means
for our users.
In particular: Does this API break only apply to 2.12 users, or also for
people using 2.11?
On 04.10.2018 17:10, Aljoscha Krettek wrote:
Hi,
I'm currently working on https://issues.apache.org/jira/browse/FL
Yes, but I think we would pretty much have to do that. I don't think we can
stop doing 2.11 releases.
> On 8. Oct 2018, at 15:37, Chesnay Schepler wrote:
>
> The infrastructure would only be required if we opt for releasing 2.11 and
> 2.12 builds simultaneously, correct?
>
> On 08.10.2018 15:
The infrastructure would only be required if we opt for releasing 2.11
and 2.12 builds simultaneously, correct?
On 08.10.2018 15:04, Aljoscha Krettek wrote:
Breaking the API (or not breaking it but requiring explicit types when using
Scala 2.12) and the Maven infrastructure to actually build a
Breaking the API (or not breaking it but requiring explicit types when using
Scala 2.12) and the Maven infrastructure to actually build a 2.12 release.
> On 8. Oct 2018, at 13:00, Chesnay Schepler wrote:
>
> And the remaining parts would only be about breaking the API?
>
> On 08.10.2018 12:24,
And the remaining parts would only be about breaking the API?
On 08.10.2018 12:24, Aljoscha Krettek wrote:
I have an open PR that does everything we can do for preparing the code base
for Scala 2.12 without breaking the API:
https://github.com/apache/flink/pull/6784
On 8. Oct 2018, at 09:56,
I have an open PR that does everything we can do for preparing the code base
for Scala 2.12 without breaking the API:
https://github.com/apache/flink/pull/6784
> On 8. Oct 2018, at 09:56, Chesnay Schepler wrote:
>
> I'd rather not maintain 2 master branches. Beyond the maintenance overhead I'm
I'd rather not maintain 2 master branches. Beyond the maintenance
overhead I'm
wondering about the benefit, as the API break still has to happen at
some point.
@Aljoscha how much work for supporting scala 2.12 can be merged without
breaking the API?
If this is the only blocker I suggest to ma
Thanks Aljoscha for starting this discussion. The described problem brings
us indeed a bit into a pickle. Even with option 1) I think it is somewhat
API breaking because everyone who used lambdas without types needs to add
them now. Consequently, I only see two real options out of the ones you've
p
The second alternative, with the addition of methods that take functions
with Scala types, seems the most sensible. I wonder if there is a need
then to maintain the *J Java parameter methods, or whether users could just
access the functionality by converting the Scala DataStreams to Java via
.java
Hi,
I'm currently working on https://issues.apache.org/jira/browse/FLINK-7811, with
the goal of adding support for Scala 2.12. There is a bit of a hurdle and I
have to explain some context first.
With Scala 2.12, lambdas are implemented using the lambda mechanism of Java 8,
i.e. Scala lambdas
12 matches
Mail list logo
