Imported From: https://issues.scala-lang.org/browse/SI-8717?orig=1
Reporter: Samuel Halliday (fommil)

@adriaanm said:
I agree it would be good to provide more fine-grained control (without sacrificing performance; I also don't think Java logging would be a good fit, though). I'm open to a refactoring that introduces overridable methods for different logging levels. Would you be interested to contribute this?

Samuel Halliday (fommil) said:
I am not keen on creating yet another logging library. JUL is part of J2SE and I'd be perfectly happy to send you a PR that simply replaces the current println usages in Global with the equivalent JUL debug/fine statements. For downstream users (like me, in ENSIME) we can trivially redirect JUL log messages to SLF4J and manage it there (e.g. with logback).

However, if you don't want to use JUL then at least removing the @inline and allowing these methods to be overridden should be good enough.

BTW I think there is some bug in the way the @inline methods are being interpreted. Even when my debug/verbose boolean vals are false (and I can check this), I still see some debug/verbose statements coming through on the terminal. It is just really really weird.

@dragos said:
I agree this is a pain, and a Java logging framework is the simplest way forward. For example, Code is using stdio as a transport protocol for its language server and any unwanted output is going to break it down completely.

@adriaanm, can you elaborate why Java logging isn't an option?

If we go for overridable methods we still need to make them "not inline", which may or may not hurt performance. I don't know what the current optimizer can do, but at some point in the past, @inline log saved about 8% in code size and a couple of percentages in speed. It may not be an issue in 2.12 and Java 8 lambdas, but I think any fix should be backported to 2.11 too.

Scala IDE is dead and the old ENSIME is too, so I'm guessing there's probably no longer downstream appetite for this?