On 17/06/2021 00:30, Rick Hillegas wrote:
Thanks for that advice, Alan. I have rototilled
@SuppressWarnings("removal") annotations across the Derby codebase and
thrown more memory at javadoc so that it won't crash on JDK 11. When I
run Derby's test suites, I see a blizzard of the following diagnostics:
WARNING: java.lang.System::setSecurityManager is deprecated and will
be removed in a future release.
Unfortunately, Derby still has more than 100 canon-based tests which
were developed before assertion-based testing became the norm. These
tests are run both with and without a security manager. In the latter
case, they now fail on JDK 17.
Is there a way to disable this diagnostic?
Even better: Could the diagnostic be removed in the next Open JDK
build? It could be re-introduced when Open JDK provides a replacement
for the deprecated functionality. Right now the diagnostic does not
seem to provide any actionable information.
I assume the OOME with javadoc isn't anything to do with this JEP or the
@SupressWarnings annotations, right?
There isn't any way to suppress the warning. This warning is sending a
clear message that that setSecurityManager will be removed in the
future. The "Illegal reflective access" warnings in JDK 9-15 set the
precedent.
For applications that do set a security manager then it is more likely
that they set it once, at startup, rather than setting it hundreds of
times in a running VM. Does Derby call setSecurityManager itself? At
least in the embedded case then I wouldn't expect it does as it will be
up to the application to do that if it wants. Clearly Derby has tests to
ensure that it can work with a SM so I assume its the tests that are
calling setSecurityManager. I'm not familar with the term "canon-based
tests" but I'm guessing that these are tests that run with and without
SM and are somehow sensitive to the stderr stream, is that right? There
were a small number of these in the JDK test suite too, but not many.
-Alan
