On 12/21/2012 8:58 AM, David DeHaven wrote:
Later I figured out that too. In that case, I think loadJavaFxLauncher() is
called twice. LM_CLASS may be used for a JAR file with a Main-Class pointing
to a FX application entry point which is confusing. So the fxlauncher only
needs to know the main class but not any other information in the JAR manifest?
I think you're confused as to what's happening..
I need more coffee this morning :-)
In the absence of JavaFX-Application-Class, canLaunchFXAppJar simply returns
false. It does not load the FX launcher on failure or it would be doing so for
non-FX jars which would cause testExtraneousJars to fail. getMainClassFromJar
then returns the class name defined by Main-Class. At that point it's processed
no differently than any non-FX application jar, the main class is loaded and
calls canLaunchFXAppClass where the doesExtendFXApplication check passes and
*then* it loads the FX launcher and uses LM_CLASS to launch the application,
not LM_JAR.
Essentially, launching an FX app via "java -jar fxapp.jar" is the same as "java -cp
fxapp.jar SomeFXAppClass" if there is no JavaFX-Application-Class attribute.
This explains what caused the confusion - I didn't expect that "java
-jar fxapp.jar" will be passed to fxlauncher with the same launch mode
as "java -cp fxapp.jar SomeFXAppClass" (i.e. LM_CLASS). I think the
semantics there was not obvious why it is not LM_JAR mode but
JAVAFX_LAUNCH_MODE_xxx has a different semantics than LM_JAR and
LM_CLASS that are defined in java.c and also LauncherHelper. Is there
any reason why "java -cp fxapp.jar" can't be passed to fxlauncher with
LM_JAR mode? That'll be consistent how launch mode is used in java.c
and the non-FX app. I'll leave it for you and Kumar/Kevin to decide if
this is important to address.
As for naming of those methods… how about canLaunchAsFXAppClass and canLaunchAsFXAppJar
(just added "As" in the middle). That should no longer imply it's an FX app
class or jar but still convey what it's doing.
That helps.
Thanks
Mandy
