On 18/01/2017 01:21, Rick Hillegas wrote:
Thanks, David and Alan. The suggested workaround works for me. I will
mouse your response into the commentary on
https://issues.apache.org/jira/browse/DERBY-6856, where I have been
collecting all of the issues I've encountered when building and
testing Apache Derby with JDK 9.
I strongly recommend a GA release note about this topic if the
backward-incompatibility won't be ameliorated.
The "Risks and Assumptions" section in JEP 261 will be refreshed soon so
that it has an up to date list of the compatibility issues that relate
to the changes that we are doing here. They will eventually show up in
release notes and migration documentation.
Thanks for the link to the Derby issue tracking your migration efforts.
From a quick read then the only other issue that seems to be relevant
to what we are doing here is the test that was hacking into a field of
java.security.Permission.
As regards the test using Object.class to locate
"/org/apache/derbyTesting/functionTests/suites/derbyall.properties" then
it's an odd way to locate a resource and not clear why it didn't use
ClassLoader.getSystemResourceAsStream originally. Anyway, as I said,
we'll need to see if using types in modules to locate a resource on the
class path make sense or not.
-Alan
