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@openjdk.java.net
/Andy Herrick
