Fwd: resource location problem in JDK 9 from build 148 onward

[Rick Hillegas]

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
>