[JENKINS-68080] DurableTaskStep.HandlerImpl.printStreamDelegate requires --add-opens

[jglick]

Fixes tests skipped in #209.

workflow-durable-task-step-plugin/src/main/java/org/jenkinsci/plugins/workflow/steps/durable_task/DurableTaskStep.java

Lines 697 to 702 in bb7ad07

	printStreamDelegate = FilterOutputStream.class.getDeclaredField("out");
	} catch (NoSuchFieldException x) {
	// Defined in Java Platform and protected, so should not happen.
	throw new ExceptionInInitializerError(x);
	}
	printStreamDelegate.setAccessible(true);

is the problem

hudson.remoting.ProxyException: java.lang.reflect.InaccessibleObjectException: Unable to make field protected java.io.OutputStream java.io.FilterOutputStream.out accessible: module java.base does not "opens java.io" to unnamed module @… [master]
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) [master]
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) [master]
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178) [master]
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:172) [master]
	at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$HandlerImpl.<clinit>(DurableTaskStep.java:702) [master]

--add-opens java.base/java.io=ALL-UNNAMED is passed to the controller, but not the agent by JenkinsRule.createComputerLauncher. Normally the error is swallowed because https://github.com/jenkinsci/durable-task-plugin/blob/0d250a6142908f591bda91d8658ab1b102611ce3/src/main/java/org/jenkinsci/plugins/durabletask/FileMonitoringTask.java#L548 runs this asynch and Remoting apparently discards errors from asynch tasks without logging them? (act actually works just as well, and exposes the error.)

[basil]

I have been considering whether to add any Add-Opens directives to Remoting's MANIFEST.MF. After some discussion in jenkinsci/docker-agent#207 (comment) @timja and I concluded they may have been needed in the past (perhaps for older versions of XStream?) but do not seem to be needed in the present, so in jenkinsci/docker-inbound-agent#263 I removed them from our Docker images and did not add anything to Remoting's MANIFEST.MF. This would be the first case I am aware of where Add-Opens is required on the agent side. (On the controller, of course, we know it is needed for XStream.) If this is the only such case, and it is only needed for better error handling, then I suppose it is better to keep Remoting's MANIFEST.MF free of any Add-Opens entries. If, on the other hand, we find additional use cases, then it might be worth adding Add-Opens to Remoting's MANIFEST.MF.

[jglick]

Ideally we would not need to use reflection to get the wrapped OutputStream, but the TaskListener interface is built around PrintStream. A bunch of code could be made simpler and more robust (and this fixed) if TaskListener exposed an optional ability to return the underlying OutputStream; I have just not gotten around to it. I agree that adding the JVM flag to agents is probably overkill just to support better error handling in a still-experimental mode.