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
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
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
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
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
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
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'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
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
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
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
