blizzard of deprecation warnings related to JEP 411

Alan Bateman Alan.Bateman at oracle.com
Thu Jun 17 11:56:35 UTC 2021


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



More information about the security-dev mailing list