Whitelist standard streams (System.out/System.err)

[bsideup]

No description provided.

[simonbasle]

small doc nitpick: it should probably be documented that installing blockhound with this integration wraps the stdout/stderr (in case somebody uses their own wrapper and expects System.out to be of a certain class, for some reason). and also that this integration is rendered moot if the stdout/stderr are set after the integration is installed.

[simonbasle]

@bsideup does it really fix the logging use case (see #120) ? I mean, if there is no console appender, but rather eg. an async-to-file appender?

[bsideup]

@simonbasle if it is async-to-file then the expectation that it won't block. If it does - it is rather a problem that the user should know about.

The change solves a very common case of something that should be whitelisted for 99.(9)% of users, because doing System.out.println() from async code is common (especially for debugging))

[simonbasle]

@bsideup ok then! my comment about javadoc still stands, but other than that 👍

[bsideup]

it should probably be documented that installing blockhound with this integration wraps the stdout/stderr (in case somebody uses their own wrapper and expects System.out to be of a certain class, for some reason).
and also that this integration is rendered moot if the stdout/stderr are set after the integration is installed.

I think both these points are kinda the expectations you get from System.out/System.setOut API.

1. You should never expect it (System.out value) to be the same (or of certain class) because it is global. Gradle, for example, overrides it too.
2. If the user decides to replace the value (either manually or my using a framework that does that), the overridden value is unknown and will either use the previous System.out value (because that's the only reference to the stdout of your process unless you use native code), or redirect it to some completely different destination where new rules apply