If you look at the implementation of that method and its usage
its clear that it should have been named `findClassFile` from the
beginning because that's what it does: find a class file and
not a source file.

Introduced ClassfileLookup interface which allows us to remove
dependency on particular classpath implementation for class file
lookups.

Since .NET backend got removed this method is a no-op.

We need to use full name of the package if we use flat classpath.

It was removed temporarily to make sure that flatClasspath is being
used. The better way is to have implementation for both and guard
them with runtime assertion.

Also, switched to using flat classpath by default.

So it's not recomputed on every access.

It's not being used yet because we have to hook into PathResolver
and construct those objects for each classpath element.

Also, this is just to get us started with the whole idea of replacing
classpath implementation. I expect we'll get specialized versions
for JarFlatClasspath and DirectoryFlatClasspath that are optimized
for the fact that we are dealing with a jar file or a directory.

Extracted methods responsible for classpath element creation into
separate trait that can be implemented to create either recursive
(old classpath) or flat (new classpath) elements.

We don't need path-dependent entries. Actually, we want to aggregate
entries from several classpath elements.

By overriding a method and setting its type to Nothing we make it
impossible to override.

Implement various lookup methods in ZipArchive. Most of the logic
was already there so I just had to put things together.

One noticeable change is that directory entry is put under
s"{dirName}/" name instead of just dirName. That's required by
lookup methods and it was probably an omission.

So they get good-looking toString representation.

Bugs are:

  * filter out directories which are not valid package names
  * filter out files which are not valid class files
  * entries shouldn't be inner classes of AbstractFileFlatClasspath
    class because that messes up their equality (due to path-dependence)
  * not every classpath element contains given package hence
    getDirectory returns an Option[AbstractFile]

Implement AggragetFlatClasspath which aggregates a sequence
of other FlatClasspaths.

It's vastly inefficient but that's ok for now.

Before, we used WrappingFlatClasspath which would simply wrap an old
implementation of a classpath and expose it through FlatClasspath
interface.

In order to do that, we had to implement an alternative
PathResolver which resolves classpath elements to FlatClasspath
implementations.

Also, we traverse underlaying zip file only once and keep the
index (entries) in memory.

This way we can have jars (instead of class dirs) on a classpath
for SymbolTable tests.

This way we can compare the old and the new classpath implementation
without distorting the results by relying on caching in Java's
ZipFileIndex.

It turned out that going through Path is expensive because
it creates a new java.io.File and makes filesystem calls.

Moved that implementation so it's not needed in any object.

Add FlatClasspath implementation that delegates (a little bit poorly)
to javac's ZipFileIndex. That implementation of zip file index is
really fast due two reasons:

  * inherently it's written for performance, it populates the index
    in single, focused pass
  * it caches the index per jar file, so the next time we ask for
    the same jar we don't need to rescan it

It's a very poor method of measuring performance but it gives
some rough idea.

…hing, rename Classpaths and Classfiles

By the way code related to hacks has been commented out to test whether it's really and still needed.

…ds like "scala foo.MyMain"

Added some mock, temporary things like source path

- scalap can work also using flat classpath
- Added simple apps to examine classpath implementations
- Reorganised entries

It works partially. In general there are problems with jar files (for example underlying file of jar loaded as ManifestResources is null so we gen NullPointerExceptions). Many tests in partest fail because of these problems. There are still some test things and a lot of TODOs.

…y containing both

There are still problems with zip/jar abstract files without real underlying file (it has to be implemented).
Also manual test commited lately still doesn't work for flat classpath due to problems with BooleanUtils.java from jar with sources of apache commons (symbol not found), although packages and entries processed by symbol loader are exactly the same as in the case of old classpath implementation.

There was really stupid bug - we always was deleting last 6 chars from file name instead of real extension

Also set caching as a default behaviour.