Why isn't JavaFX on the jdk1.7.0_u10build12 class path?

[Scott Palmer]

We always install a private JRE for our apps anyway. It will be shared among apps from our company only.

But I meant the update would break my build. Running the app. should still work. I think we test to see if we can load the Node class and if that fails only then attempt to add jfxrt.jar to the classpath by assuming it is beside rt.jar (or whatever jar String.class loads from).  Since Node will be on the classpath we will skip trying to hack jfxrt.jar onto the classpath in the first place so it won't matter that it isn't where we expect it.

Though I'm generally disappointed that things will change yet again in unexpected ways if jfxrt.jar moves to a new location.

Scott

On 2012-10-24, at 6:02 PM, Daniel Zwolenski <zonski at gmail.com> wrote:

> In that case, might be worth highlighting that if you are using any of the deployment options that require the JRE to be 'installed' (i.e. all of them except native), then the JRE will automatically try to upgrade itself on your users' machines. Meaning that at any given moment your app could just stop working (e.g. due to a change affecting something like your workaround below) without you, the developer, doing anything. 
> 
> I nearly had this happen with a commercial product of mine in a previous JRE release but I noticed it (by pure chance) a couple of days before the JRE release. I did some (unpaid) late nights to make my code work on both versions of the JRE. Now every JRE release there's a chance it could (and probably will) break though, which is one reason, among many, why that client is considering a rewrite to HTML (cross browser compatibility pales in comparison to the sort of risk created by this JRE update).  
> 
> This is one of the main reasons I would recommend the native installers as the only 'safe' option. Since the JRE is bundled into your distro and never actually 'installed', you can guarantee control over it. Everything else, you are at the mercy of the elements.  
> 
> This is just another issue that has been (recurringly) discussed on here but not seen as important. Best to assume you're on your own for this sort of stuff and use extremely defensive strategies in both your code and your deployments.  
> 
> 
> On Thu, Oct 25, 2012 at 1:52 AM, Scott Palmer <swpalmer at gmail.com> wrote:
>> 
>> On 2012-10-24, at 9:56 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>> 
>> > > I can confirm that simply dragging jfxrt.jar to the ext package works like a charm.
>> >
>> > Current thinking is that putting jfxrt.jar in lib/ext is what we will do to include JavaFX on the default classpath in FX 8 (and possibly 7u12 if no issues arise with this transition).
>> >
>> > -- Kevin
>> 
>> Ah.. then that will break my Maven "hack". Since the path to jfxrt.jar will change and Maven will barf when it can't find the system dependency.  I'm glad that I haven't rolled out that hack yet.
>> 
>> Scott
>