Linker

Currently -

• the input to the compiler is the source code and the compile classpath ( jars and directories containing .class files)
• the output is the compiled classes (.class files)

The Linker tries to change that. Internally the compiler gets most or the information from a scala signature stored in each top level scala .class, and saves this for all of the generated files. For java files it just parses the .class file and build the symbols for that

The problems with the current approach is that the scanning of the .class files is time consuming and generates ton of data e.g. the compiler has to

• locate the .class
• decompress it if in a compressed jar
• read the internal data on the class file ( constant table, methods inner classes, code etc)
• if is is a scala file ** use a special Picked annotation to unpack the symbols
• else ** generate the symbols from the class data

if we had a better format then we could eliminate the .class file and just use the special format, so we generate a map of the classes to the picked data for the whole jar

that helps with the parsing

this pickled informtion is also produced before the .class file, in the Pickling phase, which open up an oppertinity to allow a dependent project to start compiling with this symbol dat prior to the .class files being there Clearly you can run an app without the code but you can link it.

This project has a few interlocking components

Symbol loading

changes to the symbol loader to use this new format

this is in progress

Linker phase

additional phase to write this new format

done, awaiting test

offline JAR processing

allows a previously compiled jar (scala or java compiled) to provide this additonal information in the jar as a pre processing step before compilation

in progress - close to test