+1 On Jun 15, 2017, at 3:35 PM, Claes Redestad <claes.redes...@oracle.com> wrote:
> 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
