From f643a7b9ee4b98a3b7742019371da0671a38836c Mon Sep 17 00:00:00 2001 From: harrah Date: Thu, 4 Apr 2013 11:30:41 -0700 Subject: [PATCH] Updated Scala modularization and classpaths (markdown) --- Scala-modularization-and-classpaths.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Scala-modularization-and-classpaths.md b/Scala-modularization-and-classpaths.md index a08a397..1dff140 100644 --- a/Scala-modularization-and-classpaths.md +++ b/Scala-modularization-and-classpaths.md @@ -5,7 +5,7 @@ Scala modularization makes it necessary to deal with some existing issues that m ## Java boot classpath 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 example, #702). +This is not the right thing to do because it makes available classes not on the user's classpath. 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.