Explore how this library can support Java collections.

[Ichoran]

People who are using Scala it interoperate heavily with Java typically need to convert back and forth between Java and Scala collections, e.g. with JavaConverters. We should write converters for a couple of collections (maybe ArrayList and HashMap?) to shake out any pain points that might exist.

[julienrf]

I think if such a thing exists it should be an independent project. But we might want to experiment the feasibility here…

[Ichoran]

Right. I wouldn't want to include it here (most likely--there is an argument to keep it here if we need package private access); I just think we should know how it goes and see if there are any obvious hurdles etc.. I don't anticipate any, but without trying a couple of conversions each way it's a little hard to know.

[szeiger]

We currently have these converters in the standard library so they will need to be updated to work with the new collections.

[julienrf]

What about providing decorators only rather than converters? (idea suggested by @jvican)

[jvican]

Hello. I think providing decorators for Java Map and Set is the way to go and would suppose a significant improvement.

As I work on the Zinc API, which has a user-facing Java API implemented by Scala, I've realised that we're doing too many inefficient conversions between Java and Scala that could be solved if we were wrapping Java collections instead of reimplementing them, which causes the VM to allocate memory and takes time. This is usually worst than just one conversion, since we have two conversions: one from Java to Scala and then another one from Scala to Java.

I am happy to help on this task.

[jvican]

By the way, just a comment on @szeiger's appreciation:

We currently have these converters in the standard library so they will need to be updated to work with the new collections.

Aside from the fact these are expensive, I just want to remark that they are not complete: for example, there's not a conversation between java.util.Set to scala.collection.immutable.Set.

[szeiger]

Where do you see the inefficient conversions? I had a quick look at some of the implementations for both directions and didn't see any copying. All collections are wrapped, and when converting back and forth the wrappers are detected and unwrapped.

[julienrf]

Note that @szeiger ported the JavaConverters to the strawman in the scala-integration branch: https://github.com/scala/collection-strawman/tree/scala-integration