Idea: App mode for the compiler

Currently, the compiler implements a lot of useful linting options which help to maintain the quality of the code.

Identifying unused values, methods, implicits, etc; is one of the most useful ones (IMHO).
However, right now, it has the restriction that public things are always considered used even if they are never called in the whole codebase.
Of course, this makes all the sense for libraries because those are probably intended to be called by downstream users. But for applications, those are probably legacy pieces of code that should have been deleted before.

Thus I got the idea that maybe it would be good if the compiler could be configured in a way such that it understands it is compiling an app and not an application, and as such things like the linters (and maybe optimizers and other things) could behave differently.

I understand that this is probably very complex, so I am opening this just to put the point in the table and see if other users have similar (or opposite) feelings towards this idea and hopefully pick the interest of a contributor.
Another point that increments the complexity of this would be multi-module projects and the interaction between source code and test code; e.g. Should not warn in something that is only called in another module, but should warn if it is only called on tests.


The compiler must be able to perform separate compilation, even in an application, because of incremental compilation. Therefore, even in an application, from the compiler’s point of view, every file is and must be considered as its own little library. When it is invoked with a set of files, it might not be the full set of files in the project.

Therefore, the compiler cannot do this job, even if you configure it as such. This job could be performed by an external static analysis tool.


Yeah, this makes sense. I was about to say that even that the compiler was able to signal unused things in a package level, but it actually doesn’t (I probably was confused with a class inside an object or something).

For the unused things yes. But, as I said, the idea of a whole app mode was that this could be useful for other things, as an optimizer.
Nevertheless, I understand that this is not a job for the compiler alone.

Still, I believe it would be great if such linter / tool / optimizer would be part of the standard toolchain; however, I know some people would prefer otherwise.

Anyways, maybe this post could motivate someone to write such tool.

btw, I guess it is possible to use the existing bytecode-level optimizer.

(I tried to do this on source level with Java, near 10 years ago, the performance difference was also near 15-20 % depends on tasks)

UPD: and sbt-proguard already exists:

1 Like