Modularization of Scala 2.13 standard library

Watchers of the scala/scala PR queue may already have seen at https://github.com/scala/scala/pull/5677 that we are looking to further modularize the Scala standard library in Scala 2.13, splitting various packages off into new modules: scala.concurrent, scala.util, scala.io, and others. See the PR for details.

at https://github.com/scala/scala/pull/5677#issuecomment-287238228 @nafg asked “Why is scala.sys being deprecated? I think it makes scripting with scala a lot nicer.”

That’s a great question. By the time I had finished writing a proper answer, it had gotten somewhat long and general, so I decided to put it here instead.

Note that certain methods in scala.sys are being deprecated, not the whole thing.

scala.sys is a mixed bag of varying quality, often not very high. I guess that’s the reason for Adriaan’s “not recommended for use” remark in the PR. I would probably choose a more moderate wording, something like “of varying quality; use cautiously”.

But anyway, scala.sys is being split out into a separate repo and separate jar, not annihilated. It will be community-maintained (like scala-parser-combinators and scala-xml). Perhaps the community will improve it to the point where it won’t have a clouded reputation anymore.

If you disagree about the deprecation of sys.env in particular, I’d suggest we not hash that out on the PR, which is mainly about accomplishing the modularization. I’d suggest you take that up, perhaps by submitting a PR undeprecating the method, with the maintainers of the module once it’s been split off.

Perhaps one of those maintainers will be you! (You Naftoli, or you, anyone reading this.)

As for the convenience of scripting — yes, we’re aware that it’s more likely that script authors will need to depend on additional JARs in their scripts. It’s a tradeoff, for sure. It will incrementally increase the pressure on tooling around Scala (the REPL, the script runner, sbt, ammonite, etc) to make it easier to discover and add those dependencies.

It also incrementally increases the pressure on the Scala Platform to exist, since a module like scala.sys is a likely candidate for the platform. (I’m not sure how much it overlaps with https://github.com/pathikrit/better-files, which is also being considered for the platform. Perhaps they ought to merge.)

3 Likes

It doesn’t sound that way.

To compensate for the associated deprecations in your own code:
[…]

  • sys.props → System.getProperties().asScala (with import scala.collection.JavaConverters._)
  • sys.env → System.getenv().asScala

That sounds like it’s not treated like scala.xml, but deprecated and should be replaced with the verbose Java API.

Yes, those two specific calls have provisionally been deprecated. They are only a small part of scala.sys overall. (Much of the code is under sys.process.)

As I already mentioned, the decision to deprecate those methods, or not, will be in the hands of community maintainers once the module has been created.

If Try is moved to the scala package, will we then have scala.Success and scala.Failure? That may cause unpleasant situations for other things with those names, no?

3 Likes

Could do some baby steps first.