I’m doing a bit of a cleanup in the backend and stumbled over a few features that can possibly go away. There’s no deeper reason than spring cleaning, so anything that’s actually being used will stay.
Please let me know if you feel that any of these features should stay.
Compile to jar
-d out.jar, the backend generates a jar file instead of separate classfiles. The jar has a simple manifest that sets
Main-Class. The main class can be specified using
-Xmain-class pkg.Main. Without a given
-Xmain-class, if the compiler finds a single valid main method, its containing class will be used.
From what I hear, writing directly to jar can speed up compile times, especially on (certain versions of?) Windows where the file system is slow dealing with many small files. The feature was added 6 years ago. There’s an sbt plugin.
Issues when using that features are:
- it doesn’t work with incremental compilation. The sbt plugin always re-compiles all sources. It might be technically possible to improve that aspect by patching an existing jar file.
- the resulting jar only contains the simple manifest generated by the Scala compiler and no other metadata. In a standard workflow with sbt, a jar often contains more files (resources, more metadata).
-Ydump-classes /path makes the compiler generate classfiles also in
/path, in addition to the output directory. This is potentially useful when compiling to memory instead of the file system (when the compiler is invoked programmatically). Added in https://github.com/scala/scala/commit/7eb45e79b8.
-Ygen-asmp /path makes the compiler emit the bytecode as text files in asm’s format (similar to javap). This can be easily achieved by invoking asm separately, I personally use an
asm shell script. For comparing classfiles or jars I can recommend the recent jardiff tool by Jason.