Generated JNLP and HTML files - mysterious values

[Daniel Zwolenski]

Thanks Scott, that cleared things up a lot.

Some additional comments/musings:

>From the code (1.7.0_09) it looks like the fallback URL for windows is
hardcoded in regardless of what JRE version you provide. i.e. if I specify
1.7 from what I can see it won't stop the url from being added to the JNLP
(PackagerLib.generateJnlp). Sounds like the URL would be harmless/ignored
in this case though.

The tool still looks to default to jrePlatform = "1.6+" and fxPlatform =
"2.2+" even in the 1.7.0_09 version of the code. Might be better if it used
the JRE version being built with or was hard coded to the latest,
especially since 1.6 is a little special with the embedded JRE. I reckon it
would be good to default people to not use 1.6 and they can explicitly
change it if they want to use the older code.

Doesn't JRE/plugin auto-updating mean that webstart and applet applications
always have to run with the very latest Java release (for security
reasons)? If so what's the purpose/impact of the versioning attributes in
the JNLP file. I thought it wasn't actually possible to pin an app to a
specific JRE version via the web-plugin deployment options?

'embedJnlp' defaults to true. The docco you linked to is not totally clear
but to me it implies embedding would be "off" unless I set the
embedjnlp attribute
of the ANT task. Docco could be clearer or embedding could be off by
default (very minor).

What happens if that JNLP I sent is used on a 64bit windows machine running
Java 1.6. The URL looks to be 32bit specific so would it download a 32bit
version of JFX into a 64bit JVM? I'm wondering if this could potentially be
linked to problems I've had before getting JNLP working with 64bit windows
machines. I'm not fussed for me personally (that project is cactus, and
anything else would be Java 7 minimum from here on in if I ever get the
chance again) but just thought I'd mention it in case it's something you
want to look at.



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

>
> On Nov 16, 2012, at 1:20 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
>
> >> 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?
>
> Ah, good point. Windows is the only platform that has ever had a
> standalone installer for JavaFX, and until 7u6, the only platform that
> supported DeployToolkit as well.
>
> On Mac and Linux JavaFX has always been included with the JRE, so there's
> no standalone installer to download. You either have it or you don't.
>
> > 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?
>
> If you have FX already and it matches the version spec it should use the
> version you have. So, in the example you attached, if you don't have FX 2.2
> or better Web Start will attempt to download the standalone JavaFX
> installer from the URL in the href. The main reason this was included, I
> think, is that you have 'j2se version="1.6+"', which never had JavaFX
> bundled with the JRE.
>
> I would expect that if you specified a product version of 1.7.0_09, or a
> platform version of 1.8+, this line wouldn't be included because those
> versions have FX 2.2+ already. I'm not 100% sure, though; I don't have the
> code handy.
>
> > 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?
>
> If you leave it out and there's no FX available the app won't run. The
> user will see an alert.
>
> > 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.
>
> I believe that was the idea behind javafxpackager. It should be the
> reference standard for JNLP, with the intent that you shouldn't ever need
> to hand-edit JNLP or the HTML that went around it.
>
> > <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?
>
> Take a look at section 5.9.2.
>
> http://docs.oracle.com/javafx/2/deployment/packaging.htm#BABCJCHH
>
> The main reason is performance. It saves a network connection so you don't
> have to re-fetch the JNLP file.
>
> -- Scott K.
>
> ------------------------
> Scott Kovatch
> Oracle
> Pleasanton, CA
>
>
>