Ok, i have this approach working now for me.
Windows and Linux worked quite "out of the box"
But i want to say this on the list (and hopefully also it is then found by google) that for OSX you really need to do one more bit because else that jre will not work.
We did get this exception when use use in our Eclipse product Runtime.exec() or ProcessBuilder.start()
java.io.IOException: error=0, posix_spawn failed
at java.lang.ProcessImpl.forkAndExec(Native Method) ~[?:?]
at java.lang.ProcessImpl.<init>(Unknown Source) ~[?:?]
at java.lang.ProcessImpl.start(Unknown Source) ~[?:?]
at java.lang.ProcessBuilder.start(Unknown Source) ~[?:?]
at java.lang.Runtime.exec(Unknown Source) ~[?:?]
at com.servoy.j2db.server.main.Zl.run(Zl.java:1) [j2db_server_2019.6.0.3500_rc.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
When testing we did see if we just got (the same) tar.gz file from adoptopenjdk and we pointed the vm to that one it did work..
So with quite a search we finally found the difference there is a "jspawnhelper" binary in the lib folder that needs to have the executable bit set...
So i added that also the the p2.inf.template:
and made sure that the tar.gz file that we generate as an "installer" of our product also sets the right executable bits on that file.
Why is it if you generate through tycho a tar.gz file that the executable bit is not set on "eclipse" binary?
And would it be possible that what we mention now i the p2.inf, for the java and jspawnhelper binaries, that that is also ending up in the product.tar.gz file? (even if you are on windows building it)
Because currently even if you use tar.gz files as an output format, then extracting that won't start it because of the missing executable flags.
"java" is for osx or linux not really needed because the vm arg does point to a .dylib or .so but on osx we do need that jspawnhelper to be executable.
johan