Integrate JNA 5.14

[arjantijms]

Changes: java-native-access/jna@5.13.0...5.14.0

[arjantijms]

I'm inclined to merge this even with the failures. The second has different failures from the first run, with the exception of

[ClientTestNG.testTransactionScopedJMSContextInjection](https://ci.eclipse.org/glassfish/job/glassfish_build-and-test-using-jenkinsfile/job/PR-24778/2/testReport/junit/ql_gf_full_profile_all/test-jms-injection-ClientTestNG/ant_tests___ql_gf_full_profile_all___testTransactionScopedJMSContextInjection_3/)

But that test always fails randomly, so I tend to ignore it. (I think we should not have that test enabled at all in the current state of things)

@dmatej @avpinchuk what do you think?

If over several test runs, all tests together pass at least in one run, shall we just then merge it instead of endlessly consuming resources and repeating the run again and again?

Shall we disable tests that fail randomly, or move them to a new "unstable" test module, where we can just setup a build for only that test module, and set that on auto repeat until it succeeds (with a maximum of say 20 retries?)

[dmatej]

I'm inclined to merge this even with the failures. The second has different failures from the first run, with the exception of

[ClientTestNG.testTransactionScopedJMSContextInjection](https://ci.eclipse.org/glassfish/job/glassfish_build-and-test-using-jenkinsfile/job/PR-24778/2/testReport/junit/ql_gf_full_profile_all/test-jms-injection-ClientTestNG/ant_tests___ql_gf_full_profile_all___testTransactionScopedJMSContextInjection_3/)

But that test always fails randomly, so I tend to ignore it. (I think we should not have that test enabled at all in the current state of things)

@dmatej @avpinchuk what do you think?

If over several test runs, all tests together pass at least in one run, shall we just then merge it instead of endlessly consuming resources and repeating the run again and again?

Shall we disable tests that fail randomly, or move them to a new "unstable" test module, where we can just setup a build for only that test module, and set that on auto repeat until it succeeds (with a maximum of say 20 retries?)

I have already fixed it locally, but I have a new bug inside, so be patient with me few days ;-)

[avpinchuk]

If over several test runs, all tests together pass at least in one run, shall we just then merge it instead of endlessly consuming resources and repeating the run again and again?

I agree.

Shall we disable tests that fail randomly, or move them to a new "unstable" test module, where we can just setup a build for only that test module, and set that on auto repeat until it succeeds (with a maximum of say 20 retries?)

I like second option. In the first case , we may simply forget to enable them again ))

[dmatej]

We should simply fix them asap, third option. They detected bugs.

[arjantijms]

We should simply fix them asap, third option. They detected bugs.

I agree with first part, but not with latter necessarily. It can just be bad tests as well.

Whatever we do, running the build over and over again until finally everything is green at the same time doesn't add anything and wastes resources.

If in build 1 test A succeeds and B fails, then in build 2 A fails and B succeeds, then that is not really different from that in build 10 finally A and B succeed in the same build.

[dmatej]

I agree with first part, but not with latter necessarily. It can just be bad tests as well.

Right now I am sure they are not bad tests, they really reproduce a race condition. Btw the implementation is from 1997 and before :-D