Generated JNLP and HTML files - mysterious values

[Scott Kovatch]

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