Java Runtime now incorrectly reports `Cannot read field "stderr" because "consoleOutput" is null`

[TimothyJones]

Describe the bug

In the java version of jsii 1.109.0, the runner now reports:

Unexpected error in background thread "software.amazon.jsii.JsiiRuntime.ErrorStreamSink": java.lang.NullPointerException: Cannot read field "stderr" because "consoleOutput" is null

on every run.

The way the jsii Java runner works is that there's a thread that reads standard error for json objects. It reads each line, tries to parse them to json, and if it fails with an exception, it will print the line instead.

There's a small mistake in the runtime, where the buffer is flushed on EOF, even if it is empty. This would have failed the json parsing, and printed a newline to standard error (probably no one noticed this - I certainly didn't).

Unfortunately, Jackson-Databind 2.18.3 contains a change, where json nodes that aren't present will now return null instead of throwing an exception as they did previously. This changes the behaviour for empty string.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

No errors to be printed on a successful run

Current Behavior

The following error is printed to standard out

Unexpected error in background thread "software.amazon.jsii.JsiiRuntime.ErrorStreamSink": java.lang.NullPointerException: Cannot read field "stderr" because "consoleOutput" is null

Reproduction Steps

Run any java code that calls jsii with v1.109.0

Possible Solution

The fix is twofold:

1. Don't flush an empty buffer on EOF (ie, this line)
2. Handle a null return from objectMapper.treeToValue here

Additional Information/Context

Happy to produce a PR if you like

SDK version used

1.109.0

Environment details (OS name and version, etc.)

openjdk 23.0.1, node v22.9.0, MacOS 14.4.1

[TimothyJones]

Pull request #4802 raised to address this

[iliapolo]

@TimothyJones I can confirm I see this output. My question is - does it crash your process or affect functionality in some way? this needs to be addressed regardless, i'm just trying to asses impact here.

[iliapolo]

Noting for ourselves.

This is also prints in our unit test executions, for example:

This doesn't actually fail the tests though, so it went unnoticed. I am still unclear on the actual impact of this though, right now it seems like this just causes the error stream thread to silently crash, which will cause error outputs coming from the node process to not be printed to console.

Note that this only happens starting from 2.18.3 of jackson-databind, which was released March 1st, after we increased the allowed version range for jackson-databind.

[TimothyJones]

does it crash your process or affect functionality in some way?

No, the only real effect is it's a red herring when debugging unrelated issues.

Note that this only happens starting from 2.18.3 of jackson-databind

That's right. Before that version, I think jsii would have been incorrectly emitting a blank line to standard error, but that's the kind of thing that people are unlikely to notice.

[TimothyJones]

right now it seems like this just causes the error stream thread to silently crash, which will cause error outputs coming from the node process to not be printed to console.

To be clear, it only does this when closing down the stream - so yes, the thread crashes, but only during the last operation (printing out a buffer that has nothing in it). That's why there's no impact.