On 2017-06-15 18:50, Alan Bateman wrote:
On 15/06/2017 17:26, Chris Hegarty wrote:
:
Claes,
This is the first test in the core area that will now use a test
specific native library, which will need to be built ( by the build
system, which it does ), and pointed to when executing jtreg
from the command line, e.g.
jtreg ...
-nativepath:build/macosx-x86_64-normal-server-release/support/test/jdk/jtreg/native/lib
I think this may be ok, but some folk will need to get used to
adding this option to their jtreg runs. Either that, or move the
test to a separate group / target.
One thing to mention is `jtreg -k:!native ..` if you need to skip the
native tests.
Neat!
If you don't mind I'd like to move ahead with the test
configuration as-is, and then if there's a pressing need
to split the jdk_lang test group into a native and non-native
part that can be done as a follow-up. As there seems
there's a simple workaround in case a test system needs
time to adapt this doesn't seem too unreasonable, no?
I've been using the new run-test target to test this locally:
make run-test TEST=jdk/test/java/lang/String/nativeEncoding
Very convenient, and it of course emits the full command
line for reruns if something goes wrong.
---
On a different note I finally found out how to allow specifying
different runs with native tests:
@run main/othervm/native ...
By running this with -Xcheck:jni I found a couple of benign
issues (passed wrong arguments to
ReleasePrimitiveArrayCritical in both jni_util.c and the test,
and triggered a capacity warning at one place in pre-existing
code). I fixed these and added -Xcheck:jni to the default
test configuration.
Now it turns out setting -Dsun.jnu.encoding actually breaks
things in subtle ways (seems the native code reads the implicit
property, which is determined by LANG/LC_ALL before it gets
set by the provided flag). I've verified the test passes locally
for some different LANG+LC_ALL values, but can't figure out
how to express that in the test. I think we can lean on having
test systems with different default locales set, and leave it to
the future to - if possible - improve coverage.
Finally, Chris Hegarty pointed out that we could use the
@Native annotation to expose constants to JNI code (as
generated #defines), which saves us the trouble of
maintaining this assumption as a test. Since there doesn't
seem to be any drawbacks to this then I went ahead with
this approach.
New webrev:
http://cr.openjdk.java.net/~redestad/8181147/jdk.07
Thanks!
/Claes
