diff options
author | mpociecha <michal.pociecha@gmail.com> | 2014-11-29 16:26:16 +0100 |
---|---|---|
committer | mpociecha <michal.pociecha@gmail.com> | 2014-11-30 22:31:30 +0100 |
commit | 1545d2aead61e8c85f554d00b58d5a6536d5d5d8 (patch) | |
tree | c722f441317786eb4ee3ea8d5bbe49a41b18fd47 /test/support/java-tests.txt | |
parent | 6b498c30038d92c5dd8970656258894e30566104 (diff) | |
download | scala-1545d2aead61e8c85f554d00b58d5a6536d5d5d8.tar.gz scala-1545d2aead61e8c85f554d00b58d5a6536d5d5d8.tar.bz2 scala-1545d2aead61e8c85f554d00b58d5a6536d5d5d8.zip |
Define interface for flat classpath and add package loader using it
This commit introduces the base trait for flat classpath - an
alternative classpath representation. In accordance with the idea
and the experimental implementation of @gkossakowski, this
representation will try to make the best use of the specificity of
a given file type instead of using AbstractFile everywhere. It's
possible as .NET backend is no longer supported and we can focus on
Java-specific types of files.
FlatClassPath extends ClassFileLookup which provides the common
interface used also by existing ClassPath.
The new implementation is called flat because it's possible to query
the whole classpath using just single instance.
In the case of the old (recursive) representation there's the
structure of nested classpath objects, where each such an object can
return only entries from one level of hierarchy but it returns also
another classpath objects for nested levels included in it.
That's why there's added dedicated PackageLoaderUsingFlatClassPath in
SymbolLoaders - approaches are different so also the way of loading
packages has to be different. The new package loader is currently
unused.
There's added also PackageNameUtils which will provide common methods
used by classpath implementations for various file types.
Diffstat (limited to 'test/support/java-tests.txt')
0 files changed, 0 insertions, 0 deletions