Understanding -nativepath and how it is applied
david.holmes at oracle.com
Wed Feb 19 03:38:47 UTC 2020
On 19/02/2020 5:33 am, Jonathan Gibbons wrote:
> On 02/17/2020 11:21 PM, David Holmes wrote:
>> I have a test that uses native code.
>> I specify "@run main/othervm/native" for the main test class
>> I invoke jtreg with -nativepath
>> My test exec's a second VM that needs to load the native library. This
>> is done using ProcessTools.executeTestJvm.
>> When I run the test locally it works fine and if I print out
>> java.library.path it shows that the "nativepath" value has been set in
>> that property.
>> But when I run the test via our testing system it fails because the
>> native library cannot be found! The jtr file shows -Dtest.nativepath
>> being set as expected, but the exec'd VM doesn't have its value in
>> I can obviously fix this by explicitly adding -Djava.library.path=...
>> as an explicit arg to the exec'd VM, but I want to understand how this
>> works in the local case but not otherwise.
>> I'm also wondering whether this is something that should be
>> automatically handled at the ProcessTools level?
> jtreg has no control over the VMs that a test might itself exec. That is
> entirely up to the test code, and any library code (such as
> ProcessTools) that may be involved. The most that jtreg can do is
> provide the information (i.e. test.* properties) that may be required in
> order for the test to do what is required in the specific context of the
> test itself.
Okay but somehow we go from -nativepath to -Dtest.nativepath to
-Djava.library.path (or equivalent). And somehow when running jtreg
locally an exec'd VM gets the same java.library.vm as the VM exec'd by
jtreg; but when jtreg is run in other cases it doesn't. I'm trying to
understand how we can possibly see differences in behaviour here.
> -- Jon
More information about the jtreg-use