blizzard of deprecation warnings related to JEP 411

[Rick Hillegas]

On 6/17/21 4:56 AM, Alan Bateman wrote:
> 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?

I stopped investigating the problem after I found that I could work 
around it by giving javadoc more memory. All I can report is the following:

1) The extra annotations caused the JDK 11 javadoc tool to run out of 
memory.

2) The extra annotations did NOT cause the JDK 17 javadoc tool to run 
out of memory.

>
> 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?
The Derby network server installs a security manager if the DBA doesn't. 
With some effort, users can override this behavior. This behavior dates 
back to 2007 and was introduced by Derby release 10.3.1.4. At that time, 
developers from IBM and Sun Microsystems (the major players in the Derby 
community) agreed that the client-server configuration should be "secure 
by default."
> 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? 

Canon-based testing is an old black-box testing pattern in which you do 
the following:

1) Run a test script through a Read-Evaluate-Print-Loop tool.

2) Collect the console output (stdout + stderr).

3) Compare the actual output to a file of expected output (the canon).

> There were a small number of these in the JDK test suite too, but not 
> many.
>
> -Alan