Better tools for adjusting to strong encapsulation

[Alan Snyder]

If I understand JEP 264 correctly, it should be possible to direct platform generated error messages to locations other than the standard error stream (System.err).

Is that correct?

If so, would it not make sense for the default to be the (platform dependent) console log rather than System.err, which is used by applications for their own error messages?

I would guess that any platform being used for development would have a console log facility.

Providing access to the console log could be useful for applications as well. On macOS, output written to System.err currently is discarded, which means that any app that wants to log must provide its own facility.










> On Mar 21, 2017, at 10:56 AM, Simon Nash <simon at cjnash.com> wrote:
> 
> These new messages are a big problem for an application that interacts with
> the user via the console.  I understand that the messages may be useful to
> application developers who need to "identify which libraries and frameworks
> on your class path require illegal access in order to work".  For other
> situations where the reason for the access is known to the application
> developer and there is no way to avoid it, please consider giving the
> application developer the option to suppress the messages or redirect them
> to somewhere other than System.err.
> 
> Simon
> 


Roel Spilker wrote:

> That said, I consider the output of my programs (the exit code, the output
> stream, and the error stream) to be part of my public API. I consider extra
> output, that is added to those streams outside my control, a breaking
> change. Depending on my program flow and data in my program, these messages
> appear in the middle of my output.
> 
> This is especially a problem because the users of my program cannot do
> anything themselves to get rid of it. In my opinion, they should not be
> bothered by messages intended for the developer.