0

I have a java.util.ArrayList returned by a library. As soon as I receive the object I would like to convert it to a vavr collection.

What should I use to minimize the computations for this? I don't have a clear scenario of usage after that.

  1. The first thing that comes to mind is to use io.vavr.collection.Iterator.ofAll(x) but this will be optimum only if I will iterate.
  2. Using a io.vavr.collection.Vector or io.vavr.collection.Array will instantiate vavr collections.

What should I use? These might be called views (not wrappers). There are any guidelines on how to properly interoperate between java and vavr collections with minimal friction/computation - eventually only when is needed?


Update

The question looks similar to Lazy view of java.util.Collection in Vavr

raisercostin
  • 8,777
  • 5
  • 67
  • 76

1 Answers1

0

I would just create a vavr Array or Vector from it and forget about the cost of copying.

Are you working with huge collections or doing this in a tight loop? If not, I wouldn't worry too much about the cost of copying. If yes, you'll have to think about something to avoid the conversion, but that would depend on the actual use case. There's no solution that fits all use-cases.

You could also create a new type that wraps the ArrayList that lazily creates either a vavr Iterator, an Array or a Vector and you choose which conversion method to invoke on a use case basis, but the usefulness of such a type is limited in my opinion.

Nándor Előd Fekete
  • 6,988
  • 1
  • 22
  • 47
  • In general is a good ideea not to bother with this. Still I was trying to find out if there are some interoperability idioms/concepts/types that I don't know about. – raisercostin Mar 21 '20 at 13:07
  • I understand what you want to achieve, but I don't know of any such construct in vavr. Vavr collections are all immutable, so they cannot wrap any mutable Java collections as that would violate the guarantees these collections make to the API consumer. Also, an `Iterator` should be a short-lived object when the underlying collections is mutable like with JDK collections, as the `Iterator` should fail-fast in case the underlying collection is modified. So an iterator is not really something that you should carry along in your code. It's something that you create and consume right afterwards. – Nándor Előd Fekete Mar 21 '20 at 15:02