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

[Bernd Eckenfels]

Hello,

I wonder if in the Windows temp case LocalLow is (still) the right place. If this Installer is not started in the low context it will endanger its extracted temp file by making them accessible to low integrity processes, right?

And if this should search %TEMP%., %LOCALAPPDATA%\temp first.

But the variables are known to have problems too, To be robust and Windows ready  compliant it looks like another jpackager runtime function for SHGetKnownFolderPath would be good (pretty sure it’s already used somewhere, just not with a stable API exposed?)

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> im Auftrag von Philip Race <philip.race at oracle.com>
Gesendet: Montag, November 12, 2018 10:55 PM
An: Andy Herrick
Cc: build-dev; core-libs-dev at openjdk.java.net
Betreff: Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

74
75 static String getTmpDir() {
76 String os = System.getProperty("os.name").toLowerCase();
77 if (os.contains("win")) {
78 return System.getProperty("user.home")
79 + "\\AppData\\LocalLow\\Sun\\Java\\JPackager\\tmp";
80 } else if (os.contains("mac") || os.contains("os x")) {
81 return System.getProperty("user.home")
82 + "/Library/Application Support/Oracle/Java/JPackager/tmp";
83 } else if (os.contains("nix") || os.contains("nux")
84 || os.contains("aix")) {
85 return System.getProperty("user.home") + "/.java/jpackager/tmp";
86 }
87
88 return System.getProperty("java.io.tmpdir");


This seems unduly complex, and I don't understand the implication of
supporting AIX .. or some unknown "Unix", when packager is targeted
only at mac, linux + windows.

I think its sufficient to look for the strings windows, macos and linux.
And if you want a persistent storage location then default to the "unix"
location if there's no match .. although I am not sure it makes sense
on platforms that aren't targeted by jpackager.

-phil.
>
> -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
>>>>
>>>