FULL PRODUCT VERSION :
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Darwin Macintosh.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

EXTRA RELEVANT SYSTEM CONFIGURATION :
Not applicable

A DESCRIPTION OF THE PROBLEM :
appbundler was code developed during the macosx port project to create OS X application bundles.

javapackager is another currently supported way to do this.

I think appbundler is code that needs it's support status resolved.

There is a 3rd party fork of the original project at...
https://bitbucket.org/infinitekind/appbundler

This could be viewed as community support for the continuation of this code and openjdk could be discontinued.

If not, I encountered issues using javapackager on a OS X application.
There are a couple javapackager related bug reports on this...

https://bugs.openjdk.java.net/browse/JDK-8188851
One of mine. It got away from what it originally reported that turned out not to be a bug but I think still has a couple valid issues related to javapackager on OS X.
1) What about applications, probably jdk based, that require an embedded bin executable, such as the java command itself? JShell for the bug report seemed to require this. I do not think this is supported.
2) How does a javapackager application specify an --add-exports if it needs to? I could not get this to work.

https://bugs.openjdk.java.net/browse/JDK-8179033
This one concerns issues of improper handling of -srcdir. As an interested 3rd party I might comment that...
-srcfiles also does not appear to work as documented. I could only get it to take one file. A space delimited list didn't appear to work. I might also suggest on OS X a space for a file name delimiter might not be the best choice as file names with embedded spaces are allowed.

Given these issues for javapackager I attempted to take a JRE generated by that and include it as the embedded for a appbundler application.
This is where I encountered the JRELoadError. As mentioned appbundler currently supports a infinite kind fork of this code and appears to have resolved the same issue.

https://bitbucket.org/infinitekind/appbundler/issues/5/when-using-host-jre-does-not-find-one-if

with changes to the JavaAppLauncher application executable. The application successfully launched when I changed to using the JavaAppLauncher from this distribution.

I think openjdk should in some way indicate it's future intentions for support of this code.


REGRESSION. Last worked in version 8u144

ADDITIONAL REGRESSION INFORMATION:
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I believe embedding any java 9 JRE into a openjdk appbundler application should have the same problem.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The appbundler application should successfully launch with an embedded java 9 JRE.
ACTUAL -
The application shows the JRELoadError and does not launch.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
The JRELoadError appears in a dialog.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I am not sure if the openjdk source forest contains this or not. It was a side project for machos port as I remember.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I used the infinitekind fork version of the JavaAppLauncher executable. My main concern with this is if this fork is going to be able to provide needed modular jre support going forward.