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.
On 6/15/21 8:56 AM, Alan Bateman wrote:
On 15/06/2021 15:10, Rick Hillegas wrote:
:
When I tried to build Derby with the Rampdown Phase One build of open
JDK 17 (17-ea+26-2439), I saw many warnings related to the
deprecation of Security Manager classes and methods, undoubtedly the
consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby,
like Tomcat, embraced the Security Manager early on. Permissions
checks were rototilled across the whole code base and our
distributions ship with several template policy files, which we
encourage users to customize for their environments. The "Configuring
Java Security" section of our Security Guide explains how to do this
(https://db.apache.org/derby/docs/10.15/security/index.html).
My build only reported the first 100 warnings. It is likely that
there are many more.
Yes, JEP 411 deprecates a number of APIs for future removal. There
probably isn't much to do right now except to be aware that the APIs
are earmarked for removal in some future release. I've no doubt there
will be another JEP when that time comes. I assume you know about
@SuppressWarnings("removal"), which you can use to suppress the
warnings for now. The JDK usages of these APIs are using
SuppressWarnings as the JDK is compiled with -Xlint set to made
warnings fatal.
-Alan
