blizzard of deprecation warnings related to JEP 411

[Rick Hillegas]

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