luke/sbt
1
0
Fork 0
mirror of https://github.com/sbt/sbt.git synced 2026-08-22 06:07:24 +02:00
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
Download Patch File Download Diff File Expand all files Collapse all files
Scala-modularization-and-classpaths.md
+3 -3
@@ -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). 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. 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 available classes not on the user's classpath. 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. 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.) (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.) (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. I assume the original reason for putting anything on the boot classpath is to avoid some jvm overhead somewhere, perhaps class file verification.