eXist-db does not run correctly on JDKs 12, 13, 14 and 15

[dizzzz]

During running unit tests, at least one test fails, only with Java13:

[WARNING] Tests run: 156, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 3.288 s - in xquery.arrays.ArrayTests
1466[WARNING] Tests run: 458, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 34.446 s - in xquery.xquery3.XQuery3Tests
1467[INFO] Tests run: 58, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 33.929 s - in xquery.optimizer.OptimizerTests
1468[INFO] 
1469[INFO] Results:
1470[INFO] 
1471[ERROR] Errors: 
1472[ERROR]   VariableByteStreamTest.copyTo:82 » ArrayIndexOutOfBounds Index 3106157 out of ...
1473[INFO] 
1474[ERROR] Tests run: 4673, Failures: 0, Errors: 1, Skipped: 102
1475[INFO] 

[adamretter]

Just to let you know @dizzzz I am digging into this. It's a tricksy one...

[dizzzz]

@adamretter the issue is not visible in all PRs....

[adamretter]

@dizzzz Indeed. The issue I am tracing appears to be non-deterministic on JDK 13 :-/ I am still not sure I believe it!

[reinhapa]

@adamretter do we have something like code coverage in the build? We got something similar in our build when using jacoco...

[adamretter]

@reinhapa No, there is no code coverage in that build or any other form of bytecode instrumentation that I am aware of.

I do have a branch where I introduce JaCoCo, but that is separate... and that has other problems... https://github.com/eXist-db/exist/pull/3341

[adamretter]

I finally managed to isolate the issue to an independent stripped down test case - https://github.com/adamretter/vbe-test

Still it's a mystery right now that I trying to understand, but much less code to look through now at least.

[reinhapa]

@adamretter I wil try to take a look into this

[adamretter]

Looks like a JIT issue with HotSpot JDKs. Versions 12, 13, 14, and 15 are affected - https://github.com/adamretter/vbe-test#testing-results

eXist-db's Variable Byte Encoding implementation would need to be replaced to fix this at the eXist-db end.

[adamretter]

Thanks to @reinhapa for helping us report the JDK issue - https://bugs.openjdk.java.net/browse/JDK-8253191

[dizzzz]

see https://github.com/eXist-db/exist/pull/3545

[joewiz]

During the community call @wolfgangmm said he wanted to have a look at this

[joewiz]

During today's Community Call @wolfgangmm said he is looking at this

[dizzzz]

I'd vote to update the PR to ignore java 12-13-14-15 and pull this in as-is.

[StephanMa]

Dear Team,

it seems that this issue was recently fixed (2020) for Java 15.0.2. Unfortunately eXist is not able to run with Java15 because of "Error Code: 13". Is this still intended?

[adamretter]

@StephanMa Can you tell us which platform, which JDK, and what you are running to get Error Code: 13 please?

[StephanMa]

Mac M1 macOS Big Sur 11.4 JDK 15.0.2 trying to start eXist via ./startup.sh

Building via maven works fine... but I cannot run it due error 13

[joewiz]

@StephanMa Which JDK distribution?

[adamretter]

@StephanMa Any chance of a screenshot showing the error 13?

[StephanMa]

Will attach all the needed infos today

[StephanMa]

@adamretter Please see attached file

[adamretter]

@StephanMa Ah ha! Thanks that explains it.

So eXist-db only checks the major Java version, see https://github.com/eXist-db/exist/pull/3545/files#diff-7c6977667d2de8c09c5d46280134525d516cff8a0a43552b042cea303dfe8819R30

If this is fixed in Java 15.0.2, then we should update the check to permit that version.

In the mean time, your options are JDK 8 - 11.

[adamretter]

@StephanMa I have a fix for you here - https://github.com/eXist-db/exist/pull/3960

[StephanMa]

Thank you… will give it a try

[dizzzz]

I am sure we actually implemented this way on purpose; for most end-users the 3rd digit it just to complex to understand; it is much more clear just to block java 12,13,14 and 15 ; from a communication perspective imo this is better. Java15 is EOL and should not be used anyway.

[line-o]

I agree with @dizzzz the communications overhead we might get with this change does not justify the gain to support a patch of a Java version that is no longer supported anyway. @StephanMa do you really need this?

[duncdrum]

@adamretter @dizzzz i think this one can be closed

[adamretter]

@duncdrum But the issue is not fixed!