| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://openjdk.java.net/jeps/220 changes the layout of the
JDK to encapsulate the provided libraries with the new module
system.
This commit modifies the compiler's classpath implementation
to scan the new location of these, the `jrt://` virtual filesystem.
This might need to be adjusted once we provide a means for
users to specify the subset of modules that they want to
depend on, but for now reclaims the ground we lost.
```
⚡ (java_use 9-ea; qscala)
Welcome to Scala 2.12.0-20160908-223617-7e4ebda (Java HotSpot(TM) 64-Bit Server VM, Java 9-ea).
Type in expressions for evaluation. Or try :help.
scala> import StackWalker._, java.util.stream._, scala.collection.JavaConverters._
import StackWalker._
import java.util.stream._
import scala.collection.JavaConverters._
scala> (() => StackWalker.getInstance(java.util.EnumSet.of(Option.RETAIN_CLASS_REFERENCE)).walk[Seq[String]]((s: java.util.stream.Stream[StackFrame]) => s.iterator.asScala.take(3).map(_.toString).toList)).apply().mkString("\n")
res0: String =
.$anonfun$res0$1(<console>:21)
.<init>(<console>:21)
.<clinit>(<console>)
scala>
```
I've marked the new class, `NioFile` as `private[scala]` to justify
the forward compatibility whitelist entry.
In principle we could use NioFile more widely rather than `PlainFile`
I tried this out in https://github.com/retronym/scala/commit/b2d0a17a
which passed CI. But to be conservative, I'm not submitting that change
at this point.
|
| |
|
|
|
|
|
| |
Implements VirtualDirectoryFlatClassPath, which is required for the
presentation compiler created for the repl's tab-completion.
Various minor cleanups in the flat classpath implementation.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The part of the functionality of a ClassPathContext has been moved
to the base trait ClassPathFactory so it can be reused by the newly
created FlatClassPathFactory. This new implementation works in
similar manner as the ClassPathContext with this difference that it
just creates instances of flat classpath.
This change doesn't modify the behaviour of the compiler as the
interface and the way ClassPathContext works didn't change. Moreover
FlatClassPathFactory is currently unused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds an implementation of flat classpath which can handle
both jar and vanilla zip files. In fact there are two versions - for
a class- and a sourcepath. Both extend ZipArchiveFileLookup which
provides common logic.
They use FileZipArchive. @gkossakowski made a comparison of different
ways of handling zips and jars (e.g. using javac's ZipFileIndex). He
stated that general efficiency of FileZipArchive, taking into account
various parameters, is the best.
FileZipArchive is slightly changed. From now it allows to find the
entry for directory in all directory entries without iterating all
entries regardless of a type. Thanks to that we can simply find
a directory for a package - like in the case of DirectoryFileLookup.
There's also added possibility to cache classpath representation of
classpath elements from jar and zip files across compiler instances.
The cache is just a map AbstractFile -> FlatClassPath. It should
reduce the number of created classpath and file instances e.g. in the
case of many ScalaPresentationCompilers in Scala IDE.
To prevent the possibility to avoid a cache, caches are created as
a part of factories responsible for the creation of these types of
the flat classpath.
|
| |
|
|
|
|
|
|
|
|
|
| |
There's added the flat classpath implementation for directories using
java.util.File directly. Since we work with a real directory - not
the AbstractFile - we don't need to iterate all entries of a file to
get inner entries of some package. We can just find an adequate
directory for a package.
There are added implementations for a class- and a sourcepath. Both
extend DirectoryFileLookup which provides common logic.
|
|
|
The method asClasspathString is now deprecated. Moreover it's moved
to ClassFileLookup in the case someone was using it in some project
(an alternative classpath also will support it - just in the case).
All its usages existing in Scala sources are changed to
asClassPathString method. The only difference is the name.
Some operations on files or their names are moved from ClassPath to
the newly created FileUtils dedicated to classpath. It will be
possible to reuse them when implementing an alternative classpath
representation. Moreover such allocation-free extension methods like
the one added in this commit will improve the readability.
|
