Draft JEP for new Packaging Tool (replacement for javapackager)
mike.ennen at gmail.com
Fri Jun 1 06:01:19 UTC 2018
Re-familiarizing myself with what javapackager offers, it seems the
following JavaFX related
features are present:
1.) The conversion of CSS to binary CSS
2.) The ability to specify a preloader
3.) the ability to specify the JavaFX Application class
The first one seems like a bit of feature-creep and could be replaced by
some other build
tool if third party developers really need that feature. They could
probably even use something
like maven-exec-plugin to manually call such a converter. Let's set this
one aside, then.
The second and third one are important for correctly launching a JavaFX
application. I would
think that in order for these to be easily accomplished flags would need to
be present in
"jpackager" for specifying them (namely, the preloader and Application
jpackager would need to do some "reflection" to try and determine whether
or not JavaFX is
being used (maybe by checking for its presence on the module path?) and
then, if so, get
the appropriate preloader and application class.
I only mention this because the JEP proposal specifically states
under "Non-Goals" but this might make things more complicated than they
need to be
in those two areas I mentioned above.
Other then that, this looks good to me and I think having a replacement for
is a good idea.
On Thu, May 31, 2018 at 1:56 PM, Kevin Rushforth <kevin.rushforth at oracle.com
> The existing javapackager doesn't really know much about JavaFX as it is,
> now that applet and Web Start are gone. I am not aware of anything that
> would preclude packaging up a JavaFX application. We will certainly test
> the ability to package up a JavaFX application.
> As for the schedule, I agree it isn't ideal, but it's too late for JDK 11.
> -- Kevin
> On 5/31/2018 1:25 PM, Michael Paus wrote:
>> is it possible to get a clear statement on whether it will be possible to
>> package a JavaFX application with the new packager in a similar way as it
>> is possible right now with the old packager? The texts are a little bit
>> vague there. I just don't know whether it is possible to create a packager
>> which does not know anything about the GUI framework which has been used by
>> an application.
>> I would also like to express my concerns about the schedule. The next
>> Java release (11) will be an LTS release and that means that there will not
>> be any packager for all those people who will have to stick with this
>> release for a long time. This is a huge step backward for Java because
>> there is then no good deployment technology anymore for a long time.
>> Am 31.05.18 um 02:11 schrieb Kevin Rushforth:
>>> I just sent an email to the core-libs-dev alias  proposing a new
>>> Packaging Tool as a replacement for javapackager. If you are interested in
>>> this JEP, you can follow and participate in the discussion there.
>>> -- Kevin
>>>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Ma
More information about the openjfx-dev