On 1/18/17, 2:14 AM, Alan Bateman wrote:
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 again, Alan.
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.
I don't know why the original author coded it that way. It's a very old
piece of code from the last millennium, something that just worked and
therefore wasn't touched for almost two decades.
Cheers,
-Rick
-Alan
