JFX build and deployment - squeaking wheel

Daniel Zwolenski zonski at gmail.com
Mon Nov 5 13:41:38 PST 2012

Awesome, thanks John! That is actually the best news in this space for a

>From Richard's comments (and working my way through all the JavaOne
videos), I'm working out that deployment is not a show stopper for the
current JFX main ("enterprise") clients since it sounds like they are
deploying "on site" into very controlled eco-systems and not really using
any of the JFX packaging tools to their full extent. Ok, fair enough.

Whereas I'm looking at Java being deployed to the general public, and I've
been trying to use the JFX tools to do this with all the problems listed
previously. From what I can gather no one is really deploying to the public
happily, and the reason there is so little activity/progress on it is
because the bigger fish don't need it (yet). Believe it or not, that
actually takes a lot of the frustration out of it - I can comprehend the
logic at last, which makes it a lot easier to swallow.

Maybe instead of "enterprise" apps I should use the term "consumer" apps
(not sure that's quite right either though - too far the other way)? All my
"enterprise" apps are consumer apps to some extent. At a minimum users want
to use them on their home PC when working from home, but just as common is
for people to use them in distributed offices (branch/retail outlets for
example) or in uncontrolled environments (schools across australia) or on
disparate laptop or tablet devices (safety inspectors, insurance brokers,
etc, going out to customer sites, etc). I just don't have the luxury to
dictate the platform nor can I push releases or Java updates out to these
guys magically. Since the end users may be low tech and have to do the
setups themselves, I also need the simplest, quickest of installs to get
them going.

I guess for a cargo unloading system, there is not a lot of working from
home or a big need for iPad support (although I'd if they had iPads for
their in-field workers they'd use them).

For my use case the 70MB downloads are no good for me - a teacher in
country Australia will take a very long time to download 70MB and a mining
inspector in Papua New Guinea will take even longer on a satellite
connection (I think you American's might be spoiled for internet speed).
And it's also why I need smart-devices (or at least a medium range plan for
them - I never needed it today, just needed a strategy and a roadmap for
it), since "consumer" apps have to run on "consumer" platforms and Android
and iOS are fast becoming the dominant player in this space.

So (finally) understanding that my use case is a secondary one, I'm really
interested to know more about this Compact profile stuff for Java 8. I'm
assuming the Minimal Hotspot and compact profile will all run on a standard
desktop, i.e. there's nothing about it that will make it "embedded"

I'd love to know more about the "FX Embedded" project. Is this an actual
different implementation or just the FX code bundled up in a way that it
can be included as a JAR? It doesn't seem to be on any of the 3 compact
profiles so I am assuming there's a different approach for actually
including it - i.e. it's not a JRE command line thing like the rest of it?
Will we be able to run FX Embedded on the "compact JRE profile 1" on a
standard desktop or will it be specific to embedded hardware? If not will
be able to pull in FX regular and run it on profile 1 VMs? Can we leave out
things like charts and the web browser, etc, in order to make the JRE even
more lean (would it help?).

How can I get more info on this project, monitor it's progress and/or be
involved with early access, etc? Any and all links, tips, announcements and
resources would be of huge interest.

On a side note, I assume Oracle has noted the conversations on legal
problems with porting OpenJDK/OpenJFX to iOS? This compact JRE stuff opens
the door at a technical level to Android and iOS support but licencing
restrictions would still rule out iOS as I understand it.

On Tue, Nov 6, 2012 at 7:47 AM, John Smith <John_Smith at symantec.com> wrote:

> > Is the jre trimming option (ie project jigsaw precursor) still planned
> for java 8 and can you give us any indication on what this will look like
> and how it will work?
> There was a presentation at JavaOne by Bob Vandette which detailed how
> some of this may work:
> https://oracleus.activeevents.com/connect/fileDownload/session/CDC887FAEAD8ABE54064406AC304AD59/CON4538_Vandette.pdf
> The focus of the presentation is on java for embedded platforms, but there
> is discussion of jre trimming in general in there including a developmental
> tool named jrecreate and targeted, reduced functionality profiles supported
> by the javac and jar commands.
> -----Original Message-----
> From: openjfx-dev-bounces at openjdk.java.net [mailto:
> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski
> Sent: Friday, November 02, 2012 5:07 PM
> To: Richard Bair
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: JFX build and deployment - squeaking wheel
> > As I've mentioned before (and during the keynote at JavaOne 2012), this
> is where I want to put my effort. The difficult problem is being able to
> build installers from any system for any other system, but baring that, the
> rest is pretty solvable. We're open sourcing the javafx packager, which
> hopefully helps make this a little easier to contribute to.
> I am definitely watching for the open sourcing of that to happen. I'm
> hoping all the code around the native packager, the native launcher code
> for each platform and everything to do with native building will be part of
> that open sourced code. I'm hoping there will be no technical or legal
> barriers to us using that code within our own build tools and completely
> avoid the bundled jre build tools (so we don't have to wait months/years
> for our fixes to be officially included before our tools can be used).
> Is it all community work then or are there plans for any work to be done
> in this area from the official jfx team - and if so what/when? I don't want
> to double up on any work (as happened with the native launcher work - Igor
> and I wrote the same code because I didn't know he was working on it).
> Is the jre trimming option (ie project jigsaw precursor) still planned for
> java 8 and can you give us any indication on what this will look like and
> how it will work? Will the legals be solved as well as the technical issues?
> What contributions do you want as a number 1 priority. I tried to start AU
> because it was the only thing on this topic I've seen interest in from jfx
> and so I assumed it was something more likely to get picked up but Igor
> seemed to lose interest. If you had to pick one thing in this area to get
> done what would it be and if it was done when would be the earliest it
> would get included in a jfx release?

More information about the openjfx-dev mailing list