RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
andy.herrick at oracle.com
Tue Oct 30 17:10:38 UTC 2018
On 10/30/2018 12:09 PM, Alan Bateman wrote:
> On 30/10/2018 14:11, Andy Herrick wrote:
>>> What is the status of the JNLPConverter tool? I see it is included
>>> as a "demo" but maybe it would be better to host somewhere else as
>>> this is for developers migrating Java Web Start applications.
>> Our current plan is to deliver it only as a demo.
> This looks like a migration tool rather than a demo so not clear to me
> that this is the right approach. Also as the tool is for migration
> from Java Web Start when maybe it should be a tool hosted with the
> Oracle JDK download rather than something to put into the JDK.
>>> If I read the webrev correctly then it adds two modules, one with
>>> the jpackager tool and the other with an API. It would be useful to
>>> get a bit more information on the split. Also I think the name of
>>> the API module and the package that it exports needs discussion to
>>> make sure that the right names are chosen.
>> Yes - though we are currently using jdk.packager.services, we are
>> open to other suggestions as the name for these.
>> "jdk.packager.runtime" has also been suggested.
> Alex has suggested jdk.jpackager to avoid giving the impression that
> it's the "JDK packager". Also several existing tool modules have the
> tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...).
This seems reasonable, jdk.packager -> jdk.jpackager
still leaves the question of jdk.packager.services ->
jdk.jpackager.services (or jdk.jpackager.runtime) or something else ?
> Is the API to ensure that only one instance of the application is
> running really tied to the jpackager tool? Could it be used by
> applications that aren't packaged in with this tool? I'm asking in
> case there is a better name for this API module.
The current implementation is tied to the jpackager tool in that
newActivation (invoking a running app from a newly launched one) is
implemented in the native launchers used by jpackager.
This is a very interesting question none the less, as there seem to be
at least two ways this could be implemented for generic Java applications:
1.) implement it in the native java launcher(s)
2.) implement it entirely in Java, with a new "transfer control" method.
(Java Web Start implemented this in both the native javaws launcher, and
in pure Java, but it had control in Java before an app was launched,
where a normal Java app would not, so would need another transfer of
control method. An app could pass it's args to this method which would
return false (if these was no other instance), or invoke newActivation()
in the existing instance and return true (allowing the caller to clean
up and exit).
Such an API would be outside the scope of jpackager, but may impact our
decision to include a singleton interface in jpackager.
More information about the core-libs-dev