Generated JNLP and HTML files - mysterious values

[Daniel Zwolenski]

Thanks Scott, I'm still a bit unclear though.

On Sat, Nov 17, 2012 at 3:58 AM, Scott Kovatch <scott.kovatch at oracle.com>wrote:

>
> On Nov 16, 2012, at 2:15 AM, Daniel Zwolenski <zonski at gmail.com> wrote:
>
> > When the standard JFX packaging tool generates a JNLP file it includes:
> >
> >    <jfx:javafx-runtime version="2.2+" href="
> >
> http://javadl.sun.com/webapps/download/GetFile/javafx-latest/windows-i586/javafx2.jnlp
> > "/>
> >
> > I don't understand why there is a windows specific URL in the JNLP file -
> > isn't a JNLP file OS independent?
>
> Not necessarily. You can put platform-specific resources in a JNLP based
> on the OS or architecture for things like native libraries that only apply
> to a given platform.
>
> In this case, that URL is there to install the Windows implementation of
> JavaFX if it isn't available. It's only very recently that JavaFX is being
> included with the JRE. Each platform has its own implementation of Glass,
> so we have to install the right one.
>

Sorry, I should have phrased the question differently: why is there a
Windows specific URL here and not also a Linux, Mac, etc alternatives with
an OS qualifier on them (as would normally be done with the third party
native libraries in a jnlp). I'd expect either none or all, currently I see
*only* windows (32bit).

I'm assuming that the generated JNLP file is to launch the app on any OS,
but this URL has me suspicious it is generating one biased to Windows just
because I am building on Windows? Or is it just that Windows is special and
the other OSs don't need this explicit declaration?

I've attached the actual JNLP file that was generated by calling the ANT
"fx:deploy" task with minimal settings. Will this file launch my app
equally happily on Windows, Linux and Mac?

This was built using jdk1.7.0_09_win_64bit. What happens if this explicit
url to the JFX runtime is in the JNLP but the user has Java7 installed with
FX already co-bundled - will it use the one already on the OS or try and
download the referenced one? What happens if I leave the jfx version in but
leave the URL off and the user doesn't have JFX installed, or has 1.6, etc?


Is the attached JNLP the current perfect JNLP file for an app? If not it
would be great if there was a reference example for a best-practices JNLP
file.



>
> > Also, the generated HTML file to launch the JNLP has this:
> >
> >        dtjava.launch(            {
> >                url : 'hello-javafx-maven-example-1.0-SNAPSHOT.jnlp',
> >                jnlp_content :
> > 'PD94bWwgdmVyc2lvbj0iMS4wIi...whole-lot-more-base64-style-data ....
> >
> > What's the 'jnlp_content' thing for? From the code it looks like a base64
> > encoding of the JNLP file.
>
> Yes, that's basically what it is. This allows us to pass in the JNLP
> directly to Web Start without the overhead of another HTTP request. This is
> a feature of DeployToolkit, and it's documented in the main deployment
> guide. See section 7.3.2 and 7.3.3.
>
> <http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm>
>


I had read that docco but the only thing it says is: "(optional) Content of
the JNLP file in BASE64 encoding."

What is the purpose/benefit of providing this content, how is it used and
what benefit does it provide over not including it. The "url" parameter is
not optional so I assume we can't choose to fully embed the content and not
provide an actual JNLP file. Why and when would anyone want to include this
blob of base64 data in their file? If it's included, is the URL parameter
ignored?

The JFX ant task seems to think it is a good idea to include it, as it
includes it by default - what's the motivation behind doing this?

Cheers for your help,
Dan