summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/classpath/ZipAndJarFileLookupFactory.scala
Commit message (Collapse)AuthorAgeFilesLines
* Remove abstraction layer in classpath implementationLukas Rytz2016-05-021-22/+23
|
* Enable flat classpath by defaultLukas Rytz2016-03-221-7/+1
| | | | | | | Implements VirtualDirectoryFlatClassPath, which is required for the presentation compiler created for the repl's tab-completion. Various minor cleanups in the flat classpath implementation.
* Fix some typos (a-c)Janek Bogucki2015-06-181-1/+1
|
* Turn off flat classpath by default, mark one of its classes as sealedmpociecha2014-12-051-1/+1
| | | | | | | | | | | This commit addresses code review comments. The flat classpath is no longer the default classpath representation. It was the default one just for the test purposes. For now it's not desirable to make it permanently the default representation. ZipAndJarFileLookupFactory is marked as sealed - it should help to limit the ways of creating flat classpath instances for zips and jars.
* Create possibility to skip flat classpath cachingmpociecha2014-12-051-4/+9
| | | | | | There's added -YdisableFlatCpCaching option to ScalaSettings which allows user to disable caching of flat representation of classpath elements.
* Add flat classpath implementation using ManifestResourcesmpociecha2014-11-301-4/+97
| | | | | | | | | | | | | | | | | | | | | | | | | There's added the flat classpath type using ManifestResources, closely related to the support for JSR-223 (Scripting for the Java Platform). It uses classes listed in the manifest file placed in the JAR. It's related to jar files so it's created using ZipAndJarFlatClassPathFactory and is cached. In general currently it's not possible to use it in Scala out of the box (without using additional tools such as jarlister) as this support is postponed. The old classpath has been properly prepared in the PR created by @rjolly https://github.com/scala/scala/pull/2238 so the new one also got this feature. ManifestResources is a ZipArchive without a real underlying file placed on a disk and in addition implementing some methods declared in AbstractFile as unsupported operations. Therefore the implementation has to use the iterator. I wanted to have the similar behaviour as in the case of directories and zip/jar files - be able to get a directory entry for a package without iterating all entries. This is achieved by iterating all entries only once and caching packages. This flat classpath type was the last needed one.
* Add flat classpath implementation for zip and jar filesmpociecha2014-11-301-0/+82
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.