+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

Reply via email to