luke
/
sbt
mirror of https://github.com/sbt/sbt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Scala modularization and classpaths (markdown)

eugene yokota 2019-04-18 11:22:30 -04:00
parent 03be20907b
commit fa83a93981
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Scala-modularization-and-classpaths.md

@ -6,11 +6,11 @@ Scala modularization makes it necessary to deal with some existing issues that m
The term "boot classpath" comes from Java's Bootstrap Classes, which are the classes that implement the Java Platform. By default, bootstrap classes are in the `rt.jar` and several other jar files in the `jre/lib` directory according to [How Classes are Found](https://docs.oracle.com/javase/8/docs/technotes/tools/findingclasses.html).
For the Java boot classpath, the `scala` launcher justs puts everything in `lib/` on it.
This is not the right thing to do because it makes available classes not on the user's classpath.
For the Java boot classpath, the `scala` script justs puts everything in `lib/` on it.
This is not the right thing to do because it makes classes not on the user's classpath available.
It also forces a particular version of the config, JLine, and JAnsi libraries.
(Currently Scala's JLine is in a custom namespace, but I believe a goal is to use the standard JLine.)
I think it is closer to the right thing to do for the `scalac` launcher, because no user code runs and configures a particular classpath.
I think it is closer to the right thing to do for the `scalac` script, because no user code runs and configures a particular classpath.
(This is not strictly true with macros anymore, but I expect macros are discouraged from using JLine.)
I assume the original reason for putting anything on the boot classpath is to avoid some jvm overhead somewhere, perhaps class file verification.