Re: Comments on jpackage (JEP 343)

(Sorry for non-threading, i read the digest) As you've been lacking feedback from people using the jpackage EA builds, here's mine FWIW. I've been quiet because it's been working well enough for us. That said, our needs and process probably simplify matters in that: 1. We're only producing

JPackage EA build 8 ( jdk-14-jpackage+1-8 )

core-libs-dev-requ...@openjdk.java.net wrote on 24/06/2019 20:12: I've been getting the new jpackage working with our project build. Generally everything's fine. One probable minor bug relating to JDK-8221333:  Replace Inno Setup with custom MSI wrapper for .exe bundler: The generated EXE ins

Re: Jpackage Windows shortcuts

FWIW uninstall working for me from Windows 10's "Apps & features" panel. Could it be doing something different when done from "Add/Remove Programs"? And (wild guessing) might that be related to the known bug about old versions not being uninstalled properly during upgrade?

Re: Jpackage Windows shortcuts

odd, fwiw I didn't have that problem with --create-installer exe. Possibly because I'm doing --create-image as a separate first step? The space-squashing actually happens in that step, and then before either --create-installer I put the spaces back into the exe and cfg filenames ... but possibl

Re: Jpackage Windows shortcuts

Does your application's name have spaces in it? I've found they don't work if it does. (Actually the bug is at the create-image step where it squashes those spaces in the filenames of the actual app launcher exe and cfg files; restoring them before doing the create-installer step fixes it for m

Re: jpackage custom resources not found

On 15/01/2019 17:36, Michael Hall wrote: On Jan 15, 2019, at 10:55 AM, Rachel Greenham wrote: My understanding was that this particular jdk build only exists for the sake of getting jpackage out there into our hands (hence my point about putting it out as a jlinked app instead), True, which

Re: jpackage custom resources not found

y building with. Wastes disk space too, but don't care about that, have plenty. :-) -- Rachel On 15/01/2019 16:33, Michael Hall wrote: On Jan 15, 2019, at 10:25 AM, Rachel Greenham wrote: ... simply that you don't *want* jpackage's jdk to be in your path, you don't want it to

Re: jpackage custom resources not found

working for me anyway. :-) I wonder if it would be easier if, while we're in this packager gap, to provide jpackage as a jlinked app image rather than a full jdk? Is that possible? -- Rachel On 15/01/2019 16:04, Michael Hall wrote: On Jan 15, 2019, at 9:18 AM, Rachel Greenham wrote: sure

Re: jpackage custom resources not found

surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie: emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, and then it doesn't get in the way of anything else. When you want to use jpackage invoke, directly, /opt/jdk-13/bin/jpackage, which is a path you

Re: Add convenience collect methods to the Stream interface

Although I do understand the reasoning (non-repeatability of streams), Stream not implementing Iterable is a minor but frequent annoyance for this precise reason. Using forEach() instead isn't always an option. Maybe Iterable can have a superinterface IterableOnce with the methods moved up to