RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Philip Race]

SingleInstanceService. registerSingleInstance() says

If the {@code SingleInstanceListener} object is already registered, or
   98      * {@code slistener} is {@code null}, then the registration is skipped.


I don't see how that can be working as every call to

registerSingleInstanceForId creates a new instance and assigns
it to the static variable.

  114         instance = new SingleInstanceImpl();

Shouldn't this be wrapped in a synchronized null check ?

And what is the contract for equality of a SingleInstanceListener.

The API defines it as an interface but says nothing more .

And I'm not sure what is meant by the 2nd part of this below :-

36     /**
   37      * This method should be implemented by the application to
   38      * handle the single instance behaviour - how should the application
   39      * handle the arguments when another instance of the application is
   40      * invoked with params.

It is phrased like a question without a question mark.

Is it supposed to mean more like :

36     /**
   37      * This method must be implemented by the application to
   38      * handle the single instance behaviour. For example it will
           * need to resolve cases where the parameter list of the new
           * activation in conflict with the existing activation




-phil.

On 11/12/18, 12:22 PM, Philip Race wrote:
> Adding build-dev back ..
>
> I noticed that module jdk.jpackager.runtime requires java.desktop on 
> all platforms
>
> So far as I can tell this is for a Mac-only support for receiving and
> handling file open events. Probably it only makes sense or gets used
> when the API is used from a running desktop application.
>
> I might ask if we need this at all, but I definitely think it should
> not be required on all platforms if needed only for Mac even if
> we might want it on windows in a future version.
>
> Do we not envisage cases where you need the runtime API for
> some kind of daemon service for which there should be a singleton ?
> Do you really want to force the desktop module to be dragged along
> in such a case ?
>
> I think we should remove this dependency even if it means losing a
> MacOS feature at least for now.
>
> -phil.
>
> On 11/11/18, 2:40 PM, Andy Herrick wrote:
>> On 11/9/2018 5:25 PM, Andy Herrick wrote:
>>> This is an update to the Request For Review of the implementation of 
>>> the Java Packager Tool (jpackager) as described in JEP 343: 
>>> Packaging Tool <https://bugs.openjdk.java.net/browse/JDK-8200758>
>>>
>>> This refresh renames the packages used to jdk.jpackager and 
>>> jdk.jpackager.runtime, removes the JNLPConverter demo, adds an 
>>> initial set of automated tests, and contains fixes to the following 
>>> issues:
>>>
>>> JDK-8213324 jpackager deletes existing app directory without warning
>>> JDK-8213166 jpackager --argument arg is broken
>>> JDK-8213163 --app-image arg does not work creating exe installers
>>> JDK-8212089 Prepare packager for localization
>>> JDK-8212537 Create method and class description comments for main 
>>> functionality
>>> JDK-8213332 Create minimal automated tests for jpackager
>>> JDK-8213333 Fix issues found in jpackager with automated tests
>>> JDK-8213394 Stop using Log.info() except for expected output.
>>> JDK-8213345 Secondary Launchers broken on mac.
>>> JDK-8213156 rename packages for jpackager
>>> JDK-8213244 Fix all warnings in jpackager java code
>>> JDK-8212143 Remove native code that supports UserJvmOptionsService
>>> JDK-8213162 Association description in Inno Setup cannot contain 
>>> double quotes
>>>
>>> The following additional issues are targeted to be address in the 
>>> next few weeks:
>>> JDK-8212936     Makefile and other improvements for jpackager
>>> JDK-8212164     resolve jre.list and jre.module.list
>>> JDK-8213392     Enhance --help and --version
>>> JDK-8208652     File name is not passed to main() via file 
>>> association on OS X
>>> JDK-8212538     Determine standard way to determine if a Modular jar
>>> JDK-8213558     Create more unit tests
>> Note: The above issues are targeted to 'internal' - meaning we expect 
>> to resolve them in the sandbox before the initial push to JDK12.
>> Issues targeted to '12' are expected to be fixed after the initial push.
>>
>> /Andy
>>>
>>> Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/
>>>
>>> please send feedback to core-libs-dev at openjdk.java.net
>>>
>>> /Andy Herrick
>>>
>>