Support for JDK8 parallelStream()?


#1

Hello,

I played a bit with Kotlin’s collection iterators, which are really nice. Seems like JDK8 streams work as well (configured my Kotlin project to use JDK8):

val list = listOf(1, 34)
list.map {  } // compiles
list.stream().map {  } // compiles

Now I tried this which doesn’t compile:

val list = listOf(1, 34)
list.parallelStream().forEach{ } // does not compile as parallelStream cannot be called


Well, not too big of a drama. I’m just wondering whether there are plans to support this. I think Kolin’s collection iterators are better designed than the ones in JDK8 (well, Kotlin does not have the problem of having to be backwards compatible like Java). But it is nice, that you can stick to both approaches in Kotlin (JDK8-style of calling .stream() and direct way as with the Kotlin iterators). Question is now whether calling parallelStream() will be supported somewhen. That would be nice.

Regards, Oliver


#2

Just to add my 2 cents ...

I suspect this question pretty much equates to:   ‘what is the minimum JDK that Kotlin is targetting for version 1.0?’

If I’m right there and also correct in thinking that the min target JDK is still 7 … than perhaps that is why parallelStream() is not there.   Now to go out on some seriously thin ice here … why have Kotlin 7.0 (which is 1.0 targetting JDK7) and in parallel release a Kotlin 8.0 (which is a branch with added JDK8 API support).  I guess it is fast coming up to Xmas so I thought I’d throw that out there.

Cheers, Rob.


#3

Yes, I guess the release of JDK8 didn't come for the Kotlim dev team at a suitable time. I don't care whether parallelStream() is supported sooner or later. It was just something that struck me...


#4

Actually, in your first sample are not JDK 8 streams, but Kotlin analogs from standard library. That code will compile against JDK 6, as well.

In the nearest future, we will improve experience using JDK 8. In issue tracker, we have special meta-issue for it KT-4778. For same cases it would be JDK 8-specific part of standard library, for some cases special mode in compiler. Feel free to report specific Java 8-related issues in our issue tracker, so we won’t miss anything.

Minimum version of JDK needed for Kotlin will be still JDK 6 for pretty long time, because one of our goals is to compile for Android.


#5

I run IDEA on JDK 8 always and have used:

IntStream.range(1, n).parallel().

very successfully in Kotlin.


#6

Currently, Kotlin standard library has own implementations of streams (kotlin.Stream), which are similar to JDK 8 streams (java.util.stream.Stream), but have some differences in API and implementation. This is confusing and is likely to change soon.

Kotlin streams does not have any parallel execution semantics. IntStream.range() returns stream from Java, so it can be used for parallel execution.


#7

In my naive world Kotlin SDK would be based on JDK8 and 'backporting / gap filling' to run on JDK6. I'm currently not that fussed on the Javascript side so I do have that JVM bias.

As a philosophical question (and I realise we have to be pragmatic) in my ideal world when we are on the JVM don’t have 2 large overlapping SDK’s (2 collections sdk, 2 streams sdk) but are instead ‘extending’ and ‘removing warts’ from JDK.

So for example in my ideal world ‘Kotlin’ streams is based on JDK8 and just ‘extends/removes warts’ as necessary with a light touch … and then on JDK6 Kotlin ‘backfills’.  So as programmers on the JVM we don’t ultimately end up with 2 large SDK’s to deal with and translate between (which as I see it is what other languages are trying to push - their own rather large SDK to replace JDK).

This ‘Philosophy’ of ‘extending’ and ‘removing warts’ from JDK is for me is Kotlin’s number 1 ‘feature’.

I understand the JDK is far from perfect but I do really like the Kotlin approach wrt Collections (extend JDK and not replace and largely doing this at compile time) and that is a HUGE win from my perspective - brilliant.  I don’t have anything like enough knowledge on JDK streams or what other API’s in JDK8 are similarly interesting but in my world view there must be a decent amount of ‘pain threshold’ to overcome to justify a similar but totally different API.

Q: Is a separate streams API justified?  Why not extend JDK8 streams and backfill?

Those are my thoughts on it anyway.  

Cheers, Rob.


#8

I believe they started with development of Kotlin way before JDK8 and then were caught on the wrong foot when JDK8 was released. Now they need to find a common approach to streamline their collection iterators initially designed for Kotlin with those in JDK8. I also like the approach in Kotlin not to create a world on its own like Scala and Ceylon do.