Java SE and Scala Standard Library - Cases where one is preferred
We all know that it is possible to use Java libraries from Scala and vice versa. But even looking at the Java SE surface and the Scala standard library, we can see that there are many parts in them that solve identical, or at least similar problems. Collections, concurrency and IO are trivial examples. I'm not an expert on either of the two, but I suspect that in general Java SE is wider in size and Scala SL contains more conceptually advanced features (like actors). The question is, do we have access to both libraries and are able to use both languages, is there some guidance when we should choose Java SE features over Scala SL?
source to share
Scala Libraries fit into two general categories:
- The original Scala libraries. They are completely (or almost entirely) written in Scala. Generally people will write libraries from scratch for good reasons. Perhaps Java does not have such a library, or perhaps whoever wrote Scala thinks that the Java equivalent has serious limitations.
Collections are one such example.
- Scala Wrappers over Java libraries. In these cases, Scala uses the adapter pattern (or one of the other similar patterns) to provide a Scala-friendly API. These APIs are more fluent, integrate well with important Scala classes (such as collections and
Option
), and often use powerful Scala features such as traits to reduce boilerplate.
These libraries rarely offer more functionality than Java, but they significantly reduce boilerplate and make code more imdiomatic. However, they are often only a subset of the overall functionality Java provides. Depending on the library, it may or may not be possible, or it may be easy to extend it by accessing the Java base classes.
Scala Swing is a great example.
In a particular case scala.io
, it is not so much a library as a rough wrapper to handle simple common scripting tasks using Scala's idiomatic API. This is adequate for this - and certainly much nicer in my eyes than java.io
- but not for any serious I / O. There's a real I / O library for Scala out there that is currently under evaluation for adoption.
Another example I like if scala.sys.process
. It covers Java Process
and ProcessBuilder
provides almost all the functionality and adds some. Also, you can use most of Java internals if needed (the only exception is Process
, which is actually not very useful).
My advice is to use the Scala libraries if they exist and suit your needs, extend them if they are mostly adequate, but ignore the Java libraries. After all, a high degree of Java compatibility is a key feature of Scala.
source to share
In general, when writing in Scala, I would always advise using the Scala Java libraries. My advice for specific areas:
- Collections - Scala is much better and I always prefer them over Java equivalents. Scala, however, does not have a mutable TreeMap, so if you need such a structure, you will have to fall back to Java.
- Concurrency - Scala's concurrency features are Java portals and are more advanced. I have always chosen them.
- IO - I think this is one area where Scala is already in what it supports. I've usually used Scala
Source
, but there might be more unusual situations where you need to fall back to Java IO (or perhaps use a third party library). - Swing - Last time I looked, Scala's swing handling was not complete, so if you do a lot of Swing related stuff, you might decide to use Java swing components everywhere for consistency.
source to share