Re: JavaFX Launch Failure on Ubuntu from JNI

[Michael Hall]

> On Jan 20, 2022, at 9:23 AM, Steve Hannah  wrote:
> 
> My reason for a launcher is that I'm building an alternative to jpackage that 
> uses npm for deployment/versioning/updates and allows you to build native 
> bundles for all platforms (Mac/Linux/Windows) on any platform.  I.e. You 
> don't need to be building on a Windows box to create a native windows exe.  
> You don't need to worry about Mac codesigning and notarization, etc...  It 
> just takes care of all that for you on whatever system you're developing on.
> 
> I already had it working well but it currently launches JVM in a separate 
> process which wasn't optimal - so I'm working on improving it to be able to 
> run in the same process as the launcher.  This (I think) was the last 
> obstacle.
> 
> Best regards
> 
> Steve

I’m not sure jpackage handles the notarization. I had done it for a jpackage 
application and posted something on how to do it on my site. My builds are 
currently throwing some sort of error on that I haven’t looked at yet. The code 
signing and packaging I think all invoke native OS/X commands. Not trivial but 
that could also probably be done on your own. It appeared tricky with an 
already signed embedded jdk. It took jpackage a few releases to get it right.

> 
> On Thu, Jan 20, 2022 at 7:13 AM Michael Hall  <mailto:mik3h...@gmail.com>> wrote:
> 
> 
> > On Jan 20, 2022, at 9:08 AM, Steve Hannah  > <mailto:st...@weblite.ca>> wrote:
> > 
> > I just wanted to post an update on this in case it helps some future dev
> > who gets stuck on the same issue.
> > 
> 
> You probably have good reasons for having your own launcher but you might 
> want to consider if jpackage could be an alternative and let that handle 
> these cross-platform application details. 
> 
> 
> 

Re: JavaFX Launch Failure on Ubuntu from JNI

[Michael Hall]

> On Jan 20, 2022, at 9:08 AM, Steve Hannah  wrote:
> 
> I just wanted to post an update on this in case it helps some future dev
> who gets stuck on the same issue.
> 

You probably have good reasons for having your own launcher but you might want 
to consider if jpackage could be an alternative and let that handle these 
cross-platform application details. 

Re: JavaFX Launch Failure on Ubuntu from JNI

[Michael Hall]

> On Jan 19, 2022, at 2:13 PM, Matthias Bläsing  
> wrote:
> 
> Unsupported != does not work!

But it might mean less tested. So you might have to worry about things like it 
works here but does it work on Linux? It works with version x but does it work 
with y?

> At this point in time Apache NetBeans loads JavaFX from classpath and
> it works.

Probably means it’s pretty thoroughly tested though.

> FWIW,  in a draft of my earlier reply, I had written a comment pointing out 
> that JavaFX is only supported with modules. I didn't include it, because I 
> think it very unlikely that that's related to the problem.
> 
> I think a simple reproducer will be most helpful in tracking this down.
> 
> — Kevin

It probably isn’t the cause but since the OP indicated he was looking for 
suggestions, and not necessarily a bug fix at this point, I thought it might be 
worth a mention. If he wasn’t aware of this he might want to consider it on 
future updates.

Re: JavaFX Launch Failure on Ubuntu from JNI

[Michael Hall]

> On Jan 19, 2022, at 11:40 AM, Steve Hannah  wrote:
> 
> com.sun.javafx.application.PlatformImpl startup
> Exception in thread "Thread-5" java.lang.IllegalStateException: This
> operation is permitted on the event thread only; currentThread =
> Thread-5

Searching on…
com.sun.javafx.application.PlatformImpl startup Exception in 
java.lang.IllegalStateException: This operation is permitted on the event 
thread only;

Gets some hits. Somewhat interestingly given…

> They are included in the classpath.  I'm not using modules.

This one 
https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna
 

Says…

The Warning

JavaFX only supports being loaded as named modules. In other words, JavaFX only 
supports being loaded from the module-path, not the class-path.

With…

> java.lang.IllegalStateException: Not on FX application thread;
> currentThread = Thread-31
>at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)

Searching only on 
checkFxUserThread 
gets a number of similar sounding issues. Mostly they seem to suggest timing 
issues or taking various steps to ensure you are on the correct thread. 

e.g.
https://stackoverflow.com/questions/29449297/java-lang-illegalstateexception-not-on-fx-application-thread-currentthread-t
 

https://github.com/sarxos/webcam-capture/issues/469 

Re: Button label text garbled - OS/X Catalina

[Michael Hall]

> On Jun 30, 2021, at 6:44 PM, Michael Hall  wrote:
> 
> I was looking at some JavaFX introductions. HelloWorld type things. In this 
> case literally…
> https://docs.oracle.com/javafx/2/get_started/hello_world.htm
> 
> The button labels show garbled text. Googling shows a number of similar 
> examples. 
> I found one issue indicating something very similar showing as resolved.
> https://bugs.openjdk.java.net/browse/JDK-8234916
> 
> If you try to setFont you get about the same messages like…
> 
> java -cp . --module-path ~/Documents/javafx-sdk-11.0-2.2/lib --add-modules 
> javafx.base,javafx.controls helloworld.HelloWorld

Double checked and saw there was a later release download. sdk-16 works.

Button label text garbled - OS/X Catalina

[Michael Hall]

I was looking at some JavaFX introductions. HelloWorld type things. In this 
case literally…
https://docs.oracle.com/javafx/2/get_started/hello_world.htm

The button labels show garbled text. Googling shows a number of similar 
examples. 
I found one issue indicating something very similar showing as resolved.
https://bugs.openjdk.java.net/browse/JDK-8234916

If you try to setFont you get about the same messages like…

java -cp . --module-path ~/Documents/javafx-sdk-11.0-2.2/lib --add-modules 
javafx.base,javafx.controls helloworld.HelloWorld
2021-06-30 17:52:22.790 java[4142:207281] CoreText note: Client requested name 
".SFNS-Regular", it will get Times-Roman rather than the intended font. All 
system UI font access should be through proper APIs such as 
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2021-06-30 17:52:22.790 java[4142:207281] CoreText note: Set a breakpoint on 
CTFontLogSystemFontNameRequest to debug.
2021-06-30 17:52:22.792 java[4142:207281] CoreText note: Client requested name 
".SFNS-Regular", it will get Times-Roman rather than the intended font. All 
system UI font access should be through proper APIs such as 
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2021-06-30 17:52:22.896 java[4142:207311] CoreText note: Client requested name 
".SFNS-Regular", it will get Times-Roman rather than the intended font. All 
system UI font access should be through proper APIs such as 
CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
Hello World!

Should I open an issue on this someplace or is it still open somewhere? 
Or is there something I should do different to avoid it? 

Re: Can't load fxml on Macos

[Michael Hall]

> On Oct 20, 2020, at 8:56 AM, Davide Perini  
> wrote:
> 
> GUIManager.class.getResource

Not finding it? Not sure why that would be different OS X though.
Recently moved a (non-jfx) project to Eclipse and had to change 
class.getResourceAsStream to ClassLoader.getResourceAsStream. Because couldn’t 
figure out how to bundle the resource with the packaged class in Eclipse. Are 
the jars the same? If you jar -tvf is the resource where you expect to find it?

Re: How to set app name in macOS, gradle?

[Michael Hall]

> On Sep 17, 2020, at 3:00 PM, Michael Paus  wrote:
> 
> NSMenuFX will fix, e.g., the "About" issue and will allow consistent 
> internationalization
> of these predefined menu items.
> 

I saw the above were supposed to support some localization. It wasn’t a current 
concern for me. It’s sort of an obscure probably old Apple property but 
-Dapple.awt.application.name also works. Except I just noticed maybe not in 
Activity Monitor, still LoaderLaunchStub.

Re: How to set app name in macOS, gradle?

[Michael Hall]

> On Sep 17, 2020, at 12:20 PM, Michael Paus  wrote:
> 
> You can achieve this when you bundle your application with jpackage.

With jpackage including these…
-Dapple.laf.useScreenMenuBar=true
-Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe

My application name showed correctly on the top menu bar and in the dock.
Whether it was from these or just jpackage

--name -n 
  Name of the application and/or package

I don’t know. What wasn’t showing correctly was the application names within 
the application menu. Like “About LoaderLaunchStub”
These looked like they were parsed from the main class name. 

app.mainclass=us.hall.hp.common.LoaderLaunchStub

After seeing this thread I found this…

-Dapple.awt.application.name=HalfPipe

Which seems to correct that. 

NSMenuFX may give you additional functionality you want but with just the above 
for jpackage should get you correct looking application names about everywhere.

Re: EventHandler not working in 11.0.2

[Michael Hall]

> On Mar 27, 2019, at 1:29 PM, Andrew Munn  wrote:
> 
> How do I listen for mouse events in 11.0.2? IntelliJ's code completion 
> suggests this:
> 
> textField.addEventHandler(MouseEvent.MOUSE_ENTERED, (EventHandler) t -> {
> // do something
> });
> 
> but it fails to compile with error: cannot find symbol T
> 
> Thanks

Isn’t that just generic notation saying it takes an event handler where you 
indicate the specific type.

e.g. this https://docs.oracle.com/javafx/2/events/handlers.htm 
 includes

node.addEventHandler(DragEvent.DRAG_ENTERED, 
new EventHandler() {
public void handle(DragEvent) { ... };
});

showing that this handler is for DragEvent’s, specifically the DRAG_ENTERED 
event in this case. 
So you need to pass your own handler as that parameter. 

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

[Michael Hall]

> On Dec 3, 2017, at 11:12 PM, victor.droz...@oracle.com wrote:
> 
>> 
>> 
>> 
> writeEntry() is supposed to be used for the operations where we need to 
> create a directory and then do Files.copy(). I see no reason to avoid using 
> it here. Linux bundler is also implemented this way.
> 

This wasn’t clear just from the patch. But if it is consistent with how other 
code works it makes sense.

Thanks.

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

[Michael Hall]

> On Dec 2, 2017, at 9:11 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> 
> wrote:
> 
> 
> 
> Michael Hall wrote:
>> 
>> 
>>> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth <kevin.rushfo...@oracle.com 
>>> <mailto:kevin.rushfo...@oracle.com>> wrote:
>>> 
>>> 
>>> 
>>> Michael Hall wrote:
>>>> 
>>>> 
>>>>> On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com 
>>>>> <mailto:victor.droz...@oracle.com> wrote:
>>>>> 
>>>>> Kevin,
>>>>> 
>>>>> Please review the changes about copying classpath entries on Mac and 
>>>>> Windows.
>>>>> 
>>>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8179033>
>>>>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Evdrozdov/JDK-8179033/webrev.00/>
>>>> 
>>>> Sorry, to comment on this when it is not my place. 
>>>> But I had looked at this sometime ago and it made no sense.
>>>> For the Mac you have…
>>>> 
>>>> -Files.copy(new File(srcdir, fname).toPath(), new 
>>>> File(javaDirectory.toFile(), fname).toPath());
>>>> +writeEntry(new FileInputStream(new File(srcdir, fname)),
>>>> +   new File(javaDirectory.toFile(), 
>>>> fname).toPath());
>>>> 
>>>> What is the difference here? You are just changing the method of writing 
>>>> the file. Otherwise locations are identical.
>>>> Assuming the first way isn’t working, why would the second way do better?
>>>> 
>>> 
>>> writeEntry creates the directory before copying (and also opens the file 
>>> using an InputStream, but its the former that is the main part of the fix).
>>> 
>> I had just noticed that was different and wondered if it was the fix. 
>> Which is fine.
>> Although maybe creating the directory and then do the Files.copy might be 
>> clearer rather than someone later trying to figure out what makes the 
>> writeEntry call necessary.
>> 
> 
> Perhaps Victor can comment about this. Since many of the other copy 
> operations also use writeEntry, it seems fine to me.

If it is normally used to ensure the directory is there this would probably be 
something people more familiar with the code would know.

Thanks.

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

[Michael Hall]

> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> 
> wrote:
> 
> 
> 
> Michael Hall wrote:
>> 
>> 
>>> On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com 
>>> <mailto:victor.droz...@oracle.com> wrote:
>>> 
>>> Kevin,
>>> 
>>> Please review the changes about copying classpath entries on Mac and 
>>> Windows.
>>> 
>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 
>>> <https://bugs.openjdk.java.net/browse/JDK-8179033>
>>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Evdrozdov/JDK-8179033/webrev.00/>
>> 
>> Sorry, to comment on this when it is not my place. 
>> But I had looked at this sometime ago and it made no sense.
>> For the Mac you have…
>> 
>> -Files.copy(new File(srcdir, fname).toPath(), new 
>> File(javaDirectory.toFile(), fname).toPath());
>> +writeEntry(new FileInputStream(new File(srcdir, fname)),
>> +   new File(javaDirectory.toFile(), 
>> fname).toPath());
>> 
>> What is the difference here? You are just changing the method of writing the 
>> file. Otherwise locations are identical.
>> Assuming the first way isn’t working, why would the second way do better?
>> 
> 
> writeEntry creates the directory before copying (and also opens the file 
> using an InputStream, but its the former that is the main part of the fix).
> 
I had just noticed that was different and wondered if it was the fix. 
Which is fine.
Although maybe creating the directory and then do the Files.copy might be 
clearer rather than someone later trying to figure out what makes the 
writeEntry call necessary.

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

[Michael Hall]

> On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com wrote:
> 
> Kevin,
> 
> Please review the changes about copying classpath entries on Mac and Windows.
> 
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033
> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 
> 

Sorry, to comment on this when it is not my place. 
But I had looked at this sometime ago and it made no sense.
For the Mac you have…

-Files.copy(new File(srcdir, fname).toPath(), new 
File(javaDirectory.toFile(), fname).toPath());
+writeEntry(new FileInputStream(new File(srcdir, fname)),
+   new File(javaDirectory.toFile(), fname).toPath());

What is the difference here? You are just changing the method of writing the 
file. Otherwise locations are identical.
Assuming the first way isn’t working, why would the second way do better?

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 30, 2017, at 6:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> — Kevin

I was sort of waiting to see what came out of the JEP. 
It had some issues on OS X the last time I tried it. I might have used it for a 
starter application that I’ve been manually updating since. 
Now I use jlink, copy in the results… That sort of thing. 
I may look at it some more as-is if it doesn’t have a significant update 
currently in the works.

Thanks.

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> 
> Hi, Mani.
> 
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you 
> proposed(there is an arg named jvmOptions but that's not mentioned in the 
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
> non-gui mode. Can you provide more details about that (like full cmd line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for 
> deploy/packager, as it's not always clear what users expect.
> 

Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311

Re: JEP 311: Java Packager API & CLI

[Michael Hall]

> On Oct 19, 2017, at 4:00 PM, Kevin Rushforth  
> wrote:
> 
> [truncating the subject line to remove my name, which isn't relevant]
> 
> The JEP discussion should happen at jdk-dev, so please go there to ask 
> questions about the JEP or to discuss it.
> 
> — Kevin

I saw that. But thought there was going to be some initial questions answered 
here. 
I will post the question to jdk-dev.

Thanks.

Re: JEP 311: Java Packager API & CLI (Kevin Rushforth)

[Michael Hall]

> On Oct 19, 2017, at 3:01 PM, victor.droz...@oracle.com wrote:
> 
> Hi, Sverre.
> 
>> The preliminary list of new arguments has arguments for DEB, but not RPM.
>> Really hope RPM is not phased out after refactoring arguments for later
>> removal after JDK10.
> RPM will not be phased out. It's just a preliminary list of arguments.
>> 
>> What is the reason for removing support for Java Web Start (JNLP) in the
>> Java Packager?
> 
> Support for Java Web Start will be available for old CLI

I don’t see --add-exports listed with the JEP arguments, my understanding is 
that for the current release of Java 9 this might sometimes be needed for 
restricted API’s?

Re: Bulk packager integration

[Michael Hall]

> On Nov 30, 2015, at 9:19 AM, Danno Ferrin <danno.fer...@oracle.com> wrote:
> 
>  do we need to add some -XaddExports?  

Yes?

java -cp . JRTLister -p  com.sun.tools.jdeps.Main
/modules/jdk.jdeps/com/sun/tools/jdeps/Main.class

javac TestJdeps.java
TestJdeps.java:1: error: package com.sun.tools.jdeps does not exist
import com.sun.tools.jdeps.Main;

Macintosh:jigsaw mjh$ javac 
-XaddExports:jdk.jdeps/com.sun.tools.jdeps=ALL-UNNAMED TestJdeps.java
Macintosh:jigsaw mjh$ 

import com.sun.tools.jdeps.Main;

public class TestJdeps {
  
  public static void main(String[] args) {
try {
  Main.main(new String[] { "-version" });
}
catch (Exception ex) { ex.printStackTrace(); }
  }
}

[fwiw http://www195.pair.com/mik3hall/JRTLister.java] 
<http://www195.pair.com/mik3hall/JRTLister.java%5D>

Michael Hall

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Michael Hall]

> On Nov 17, 2015, at 11:31 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> 
> wrote:
> 
> [taking awt-dev off of this thread]
> 
> The fix that was put into 8u72-b02 is that the packager will no longer 
> include libjfxwebkit.dylib in the packaged app. Is this not working correctly?

> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from 
> https://jdk8.java.net/download.html <https://jdk8.java.net/download.html>):
> otool -L 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
>  | grep icu
>   /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current 
> version 51.1.0)
> And it the issue is still there, Build b05 still references private API.

If I followed this correctly the OP seems to be saying that libfxwebkit.dylib 
is present in 1.8.0_72 b05? So that fix did not work correctly somehow.
Is there any chance the change, which was to remove this(?) was missed or 
disappeared between b02 and b05?

Michael Hall

Re: MenuBar in osx to set About, Preferences, Quit

[Michael Hall]

> On Sep 2, 2015, at 9:05 AM, jo...@msli.com wrote:
> 
> Please respond with only methods that do swing, awt, or eawt, as I have
> not seen this published anywhere.


Not easy to find doc these days. But fwiw…
http://www.docjar.org/docs/api/com/apple/eawt/Application.html

Michael Hall

Re: MenuBar in osx to set About, Preferences, Quit

[Michael Hall]

> On Sep 2, 2015, at 3:16 PM, Tai Hu <tai...@veroanalytics.com> wrote:
> 
> Michael,
>  I checked out eawt couple weeks ago when I search the solution for this 
> issue. It seems that there is no updates since 2010 and I played with it for 
> a little while. It seems not working with latest OS X and JavaFX 8. I cannot 
> control the Mac menu bar by using the eawt.

You mentioned having something else that worked for you?
These work fine for me. If they don’t for you and you don’t have a work around 
you would probably have to file a bug report.
 
Michael Hall

Re: MenuBar in osx to set About, Preferences, Quit

[Michael Hall]

> On Sep 2, 2015, at 9:05 AM, jo...@msli.com wrote:
> 
> What is the method for a pure javafx app to control the osx application
> menu bar (e.g. About, Preferences, Quit, etc)?
> 
> 
> Please respond with only methods that do swing, awt, or eawt, as I have
> not seen this published anywhere.
> 

I’m not quite following this. Maybe there is another eawt, but when I see that 
I think of the Apple API’s for this which are I believe are still supported. 
Is this what you mean?
These were used in the past on Apple jvm’s to provide this functionality to 
java app’s and were I think open sourced and given to the openjdk project when 
Apple turned over it’s java related. 
Is this what you mean by eawt? And are you saying this is or is not acceptable. 
That support has nothing to do with javapackager as far as I know. 
It was indicated to me at some point that support for these legacy Apple API’s 
now informally belongs to the awt group. Also that they would probably continue 
to be available in Java 9 as part of the Desktop module? If I remember right. 
 
Michael Hall

Re: Can we use JavaPackager and a get full JRE?

[Michael Hall]

 On Aug 9, 2015, at 11:14 PM, Danno Ferrin danno.fer...@oracle.com wrote:
 
 It's not easy, since this is functionality that is deliberately removed in 
 the name of security.  You could copy the .../bin/java file somewhere else 
 prior to packaging and then copy it back into place after packaging, but that 
 would be platform specific.

Wouldn’t this break code signing?

For now, OS X only, couldn’t you require your users to have the common, 
‘browser’, jre installed?

alias javajre=/Library/Internet\ 
Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java

javajre -version
java version 1.9.0-ea
Java(TM) SE Runtime Environment (build 1.9.0-ea-b70)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b70, mixed mode) 

Then you could Runtime exec that?

Michael Hall




 

Re: Can we use JavaPackager and a get full JRE?

[Michael Hall]

 For now, OS X only, couldn’t you require your users to have the common, 
 ‘browser’, jre installed?

Or, thinking about I guess you could require the jdk to be installed. Then 
normal Runtime would work, OS X I’m pretty sure and maybe cross platform.
For Java 9 I thought the jdk/jre separation sort of goes away and you either 
just get the jdk tools or can include their module? 

Michael Hall

javapackager

[Michael Hall]

It was indicated that this might be the list for questions on javapackager.

This could very well just be that some OS X customization hasn’t been done yet 
for the java 9 early access but a javapackager application gets the following 
error if I replace the default Java 8 jdk with the java 9 and change JVMRuntime 
in the Info.plist file to reflect that. 
It default sets Java 8 as the embedded runtime, I’m not familiar enough with 
javapackager to know how to override that, so I change it manually. 
Embedded Java 9 got…,

4/2/15 7:03:23.334 PM TestApp[4354]: Could not get function pointer for 
JLI_Launch.: (
0   CoreFoundation  0x7fff9466025c 
__exceptionPreprocess + 172
1   libobjc.A.dylib 0x7fff95bf8e75 
objc_exception_throw + 43
2   CoreFoundation  0x7fff9466010c 
+[NSException raise:format:] + 204
3   TestApp 0x00010e327de1 launch + 593
4   TestApp 0x00010e327366 main + 70
5   TestApp 0x00010e327314 start + 52
)

This is a fairly simple test application, it just puts up an empty JFrame, it 
did work with the Java 8 runtime embedded.

Michael Hall