RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (original) (raw)

Philip Race philip.race at oracle.com
Mon Nov 12 21:40:57 UTC 2018

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

More information about the build-dev mailing list