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

Daniel Zwolenski zonski at gmail.com
Wed Oct 24 15:02:53 PDT 2012


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


More information about the openjfx-dev mailing list