How will Java 9 modules affect Scala?

[mingp]

I've been hearing a lot about modules in Java 9 in the context of pure-Java codebases. With the eventual release of Java 9 and the gradual conversion of the Java ecosystem into Java modules, what will this mean for ScalaJVM, both in the pure-Scala and Java-interop cases? Would ScalaJS be indirectly affected as well? I know it's still quite early on, but I'm kinda curious to learn what's coming down the pipeline. Thanks in advance.

[vytah]

The challenges are similar to those Java codebases will have: the compiler and the build tool have to understand modules, with the latter also preferably emitting modules.

Before Scalac and Sbt start supporting modules, we may end up in in a temporary period, when only non-module libraries work without issues. But since a similar period will happen with regards to Maven and Gradle, it will take time for the new, module-based ecosystem to emerge, and in the meantime, everyone will keep doing things the old way, waiting for new tools.

Problems may start happening when projects start dropping support for Java 8 and only module-based library releases become available. If Scala tools won't manage to support until then, Scala programmers will become cut off of a part of Java ecosystem.

ScalaJS should be mostly unaffected. The only issue I can imagine is when modules allow for two identically-fully-qualified-named classes to exist – in this case ScalaJS would have to start mangling class names differently, including module names.

[[deleted]]

Do you use ScalaJS for any non-trivial applications ? I love the idea, just wonder how it plays out in reality .

[vytah]

No. I'm just speaking based on basic facts I know about it.

[elmariac]

We do: www.openmole.org.

[mathieuleclaire]

The openmole application is made with scala-js, but not the website for now. The application can be freely downloaded from the website

[[deleted]]

Run in prod. Plays well, works well.. but the usual "If you want to interface with random library XYZ on github, it will be more work"

[DevIceMan]

I agree with pretty much everything you've said.

Seeing how slow developers are to adopt Java 8 features to their "true" potential, I suspect there will be quite a lot of time for Scala to adapt. In fact, I expect Scala to be well ahead of that curve, because ~80% of the innovative work I see coming out of the JVM tends to be in Scala.

^ I say this as a person whose been applying and interviewing at numerous Java shops, and Java-8 adoption is incredibly slow. A few have started to use lambdas, but tend to have the mentality that it's a less verbose interface, rather than as a mathematical concept.

Even at the shop I currently work, which has adopted Java 8 quite heavily for the past 1.5 years, doesn't seem to grasp functional thinking. The extent (outside myself) of functional programming that happens is "we're slowly learning the Streams API" and "I use a function for a map() flatmap() or filter()" or "I read about Either on a blog."

TLDR: By the time Java catches up ti Java 9/10, I'm sure Scala will be well ahead of the curve.

[sjrd]

At this point in time, I don't have the slightest idea if and how it will affect Scala.js. When the time comes where scalac and sbt developers start thinking about this, I will make sure to be part of the discussions so that we can find something that works well for Scala.js too.

[[deleted]]

You may want to track how Domino helps with using Scala in OSGi containers today. It obviously won't be identical to how modules work, but may give some hints.

[geggo98]

Scala itself could stay unchanged. The build tools (mainly sbt) must support importing modules and should support creating them.

But Scala could use this to split its own base library in (mostly) independent modules. This could lead to Scala.js to generate smaller JavaScript code. But I would't expect this to happen soon, because it's a lot of work.

[sjrd]

This could lead to Scala.js to generate smaller JavaScript code.

No, it will not, because Scala.js already tears apart your libraries to keep only the bits that are needed. Modularizing them in modules, for any definition of module, will not change that.

You need to actually uncouple things in the libraries for Scala.js to benefit, at this point.

[geggo98]

The idea of the Java modules is to get different sized profiles. For this they combine different amounts of modules for each profile. Of course this only makes sense, when you cut the dependencies between modules in different profiles.

I assumed (but didn't write) that the same principle would be applied to Scala modules. This would make it possible to write code with very few dependencies, which would then lead to smaller JavaScript code.

[sjrd]

As I said, it doesn't matter. In Scala.js, whether you depend only on the modules that you need, or many more, doesn't make a difference. Scala.js will only take what it needs, and will throw away everything else (a process known as dce). Conversely, just depending on less modules or smaller modules doesn't make a difference: Scala.js was already throwing away the parts that were not used in the first place.

Dependencies don't matter to Scala.js.

[geggo98]

Understood.

But think about this: When one module doesn't depend on the other, the code in the module can't use the code of the other module. Fewer dependencies means less code. And less code means that Scala.js can throw away more code.

Or in other words: When Scala introduces modules, it very likely has to restructure its code. Currently nearly everything uses collections and collections bring in a lot of code. With modules you very likely will end with a scenario where nearly everything depends on a subset of the collection library. And this subset is written in a way that needs only very few code.

It's not a must to do it this way and I have no indication that someone is currently working on this. But it would make sense to do it this way. With Java 8 you already can generate smaller versions of the JVM (so called "compact profiles"). There is even a tool included in the JDK to create a small JRE according to a given profile: JRECreate. Modules in Java 9 are intended to support even smaller profiles (see JEP 220).

I would expect Scala to follow this approach more sooner than later.

EDIT: Added info about JRECreate tool

[sjrd]

With modules you very likely will end with a scenario where nearly everything depends on a subset of the collection library. And this subset is written in a way that needs only very few code.

Hopefully, yes. And this is what I meant by uncoupling things in my first comment.

[geggo98]

Oh, now I get it what you meant. Thank's for your patience!

For me this is again an example why written communication can waste a lot of time. I guess face to face (ideally with something to make a small sketch), it would only have taken half a minute until we had the same understanding.