-
Bug
-
Resolution: Unresolved
-
Minor
-
Jenkins 2.263.4
RH7 Linux, no container (slaves and master)
remoting 4.5
openJDK jdk-11.0.9.1+1 on slaves and master
(openJDK jdk8u275-b01 for crosscheck on one slave)
On start of a slave using openJDK jdk-11.0.9.1+1 on slaves and master I get in the log:
--------------
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 4.5
This is a Unix agent
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by jenkins.slaves.StandardOutputSwapper$ChannelSwapper to constructor java.io.FileDescriptor(int)
WARNING: Please consider reporting this to the maintainers of jenkins.slaves.StandardOutputSwapper$ChannelSwapper
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Evacuated stdout
[StartupTrigger] - Scanning jobs for node ullteb106
--------------
The bold warning makes me a little bit nervous....
All these warnings are not present, if I use openJDK jdk8u275-b01 instead. (Everything else unchanged)
There is a similar report referring to Windows and (Sun) JDK9: https://issues.jenkins.io/browse/JENKINS-46631
And on JDK11, but referring to "after installing the selenium plugin" https://issues.jenkins.io/browse/JENKINS-64831
(We DON'T have this plugin installed)
I'm running Jenkins with JDK11, because in my understanding the switch is pending; I'm using openJDK because Sun/Oracle would need a license in my understanding.
- duplicates
-
JENKINS-46631 Illegal reflective access by RemoteClassLoader to ClassLoader#getClassLoadingLock
-
- Closed
-
- relates to
-
JENKINS-64831 illegal reflective access in remoting
-
- Closed
-
The code in question could be reworked to call jnr-posix's JavaLibCHelper.toFileDescriptor, but that also prints a reflective access warning as described in jnr/jnr-posix#110. The comments to that issue describe one possible workaround (using JNI), but really the root of the problem is that this use case just isn't supported by the Java Platform. StandardOutputSwapper itself only seems to exist as Kohsuke's solution to a stream integrity problem encountered years ago. It might be worth reconsidering that use case and possibly redesigning the subsystem so that this problem (and therefore the use case for doing file descriptor manipulation from Java) is avoided.