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
