Understanding -nativepath and how it is applied

David Holmes david.holmes at oracle.com
Wed Feb 19 03:38:47 UTC 2020

Hi Jon,

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 
>> java.library.path!
>> 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?
>> Thanks,
>> David
> David,
> 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 mailing list