SPP November Meeting Minutes


Dear Contributors,

With a bit of delay, here comes the SPP Meeting Minutes from November 27th, 2017:

  1. Catching up on updates since our previous meeting: Scala Platform infrastructure, policies, and roadmap for 2.13.x.
    YouTube time: 00’00’'
    Jorge gives a brief status update on the progress between the two SPP meetings.
    Notably the Better files and Scala JSON AST, both libraries had active contributions and productive discussions.
    He points out that Scala 2.13 release is scheduled for 27. April 2018 and that Scala Platform should have its release before that (ideally January / early February 2018).
    He later adds that the list of deprecated modules is not yet final but that there are talks about certain modules like scala.concurrent, scala.io, scala.sys scala.runtime, scala.util, scala.text… (more about these changes SIP meeting 2017 YouTube link minutes).
    The SPP Committee should make a decision about which of those modules should become a part of the Scala Platform.

Many questions were raised throughout the meeting about SP and SPP:
Eugene asks Jorge (YouTube time 3’15’’) to give a general overview of the SPP and explain if SPP is the one or one of many possible platforms in the future?

(In the following part I will summarise the main points and the subjects related to this question. Please note that I extracted them from various parts of the meeting and bundled them up under the “SPP general points to discuss category” (below) all points were mentioned but not decided upon and will be spoken about in the future SPP meetings.)

  • As of Scala 2.13 release in April 2018, many libraries will be deprecated, meaning Scala Team at Lightband will not keep maintaining them.
  • Scala Platform is an answer to the modularisation of the language.
  • The modules in Scala Platform should support only the last 2 versions of Scala
  • It is one of the possible platforms, it’s unique in its choice of the content but not in its existence
  • The objective is to create and collaboratively maintain a reliable, established and simple to use/learn infrastructure = Scala Platform, aside from the Core language.
  • The spirit of “the least powerful abstraction”

SPP general points to discuss and some ideas:
a) which libraries should be a part of the Platform
b) keep contributors active within the Platform
c) find a way to entice the companies to help support contributors
d) develop a migration tooling/guides: how is the process actually going to unfold
(see Rex’s argument at 12’27’’ - 16’10’’)
e) IDEA: create a “minimal validation library” that other libraries could integrate.
(mentioned by Jorge)
f) IDEA: eventually provide a “style guides” and “standards” (see Aleksandar’s argument at 26’35’’ and Jorge’s suggestion at 32’37’’)

  1. A final vote on Better Files and updates on Scala JSON AST.
    Pathikrit makes an introduction about what are and Better Files and the motivation.
    It’s targeting the common file utiles (like read, write, move directory, copy and other) for those who want to do IO in Scala, as "it is not obvious how to do those in java"
    Better Files is a wrapper around java.io.file
    In the meantime, it became it’s own Scala library, thanks to adding utiles to it.
    The work is inspired by Google’s Guava and Apache’s IOUtiles.
    More at https://github.com/pathikrit/better-files
    After taking a closer look, Eugene (YouTube time: 19’40’’) goes into technical details to which Pathikrit explains how the issues evolved, basically pointing that issues pointed out by Eugene are already addressed, one is resolved and the other is on its way.
    Rex agrees it is a good idea to have “parameters each time in the methods”.
    Others agree the Better Files are useful and needed a part of the Platform.

Conclusion: The module is accepted as a part of Scala Platform by a unanimous vote.

  1. Discussion of the proposal “Make Scala Platform API independent of Java namespaces”
    Eugene’s opens the topic with the observation that the proposal is a bit confusing, and he tries to understand what is it aiming to do (YouTube time: 37’)
    Option 1 - moving some stuff to a scala namespace (like a date)
    Option 2 - standard tooling like a compiler and sbt will only depend on scala namespace and not use the java namespace, what exact problem is it trying to solve?
    Or is this proposal philosophical/aesthetic?
    Jorge: it asks for re-implementing the JDK utilities in the Scala with a goal to directly cross compile, so that Scala supports and Java doesn’t.
    Concluding that with different runtimes there needs to be a team working on it full time.
    The communities that benefits the most are Scala JS users and Scala Native (the further would not need to re-implement IO or NIO as they do right now)
    Lars makes a point on if Scala Native and Scala JS don’t share the same code, this proposal makes no sense, Jorge adds it should be discussed another time and ask the proposal authors to join.
    Rex (YouTube time: 44’45’’) doesn’t think that the proposal addresses the difficult part of the problem - the underlying differences between the platforms. It could solve a less difficult part of the problem, but it’s not worth the effort.
    Jorge agrees with Rex and adds that it would need a more balanced proposal as it would be great having something cross-platform on the Scala Platform.
    Aleksandar (YouTube time 53’24’’) suggests, given that Committee is supposed to define the minimal API than the maintainers of those specific backend or compiler versions should be the one that tests it.
    He points out that the biggest advantage of this proposal is introducing the Scala namespace gives a certainty that it might be supported in the future.
    Bill proposes to have naming by packages showing which libraries work on which platform e.g “library x JVM only” so it is easier to keep track of which libraries work across platform and which don’t.

Conclusion: This proposal is interesting but there needs to be more discussion and clarity before moving forward.


As of Scala 2.13 release in April 2018, many libraries will be deprecated

I’d like to expand on this a little bit, as the summary wording here is potentially misleading.

Not every module we hope to split out of the 2.13 standard library will become “deprecated”. It varies from module to module, and could vary even within a module.

Some examples of the varying statuses and destinies that modules can have:

  • scala-actors: was deprecated in its entirety at the same time it became a module.
  • scala-parser-combinators. The module as a whole was not deprecated when it was split off from stdlib, but the scala.util.parsing.json part of it was deprecated.
  • sys.process. Perhaps some particular things in it will be deprecated, but I don’t expect the entire module to be considered deprecated.

Also, the fact that something is separate from the standard library doesn’t necessarily mean that the module becomes community-maintained rather than Lightbend-maintained. For example, the scala-java8-compat module is primarily Lightbend-maintained.


@SethTisue Are there more news on which modules or their parts will be eventually deprecated? In a SIP discussion we had in May, there wasn’t a definitive list of it (which is understandable, as it requires experimentation).

In the SPP meeting, I mentioned the modules that were preemptively proposed by Adriaan to be carved out:

Scala concurrent, Scala.ref, Scala.sys, Scala.compat (that is already totally deprecated), Scala.text (that has already couple of things that are deprecated), Scala.util; whereas Scala.io and Scala.sys are good candidates for replacements with better community modules.

(I would expect that list to be updated. As far as I know all of us are looking for more community feedback on this.)

For those that want more context, have a read at this scala-dev ticket and its predecessor.


You link to the same issue twice.


True, I changed it now. For reference, this is its predecessor. Thanks for the heads up.


@darja is there documentation online which enumerates all currently ongoing and/or accepted proposals for the Scala Platform?


@joshlemer Not yet, but we’ll put this up together soon.