jpackage: uniform error messages on different platforms

when things go wrong launching an app packaged with jpackage, the behavior is different accross platform: - on windows it show a popup - on other platforms it logs to stdout I think it would be better if the behavior was consistent: - provide popups on other platforms when the program is launched

jpackage: better error messages when things go wrong ?

Many things can go wrong when launching an app package with jpackage (1). If the app doesn't work enough to get basic logging, then the only error message you get is "Failed to launch JVM" (with javapackager form jdk 8 you also had "Error Invoking Method"..) I think it would be a great

Re: RFR 8223593 : Refactor code for reallocating storage

Hi Ivan, Roger, What about "calcNewLength" ? The word "new" gives enough hint as to what the method does - it calculates the length of new array to be allocated instead of old one. Regards, Peter On 5/17/19 8:45 PM, Ivan Gerasimov wrote: Hi Roger! I think that not only the name, but also

Re: JDK 13 RFR of JDK-8224174: java.lang.Number has a default constructor

Hi Joe, Looks fine. Should the bug be labeled noreg-doc? Is this worthy of a CSR? It seems like make-work except that it does change the formal Java SE spec that is generated from javadoc. Roger On 5/19/19 3:09 PM, Joe Darcy wrote: Hello, While doing some other work, I noticed that

Re: RFR 8223593 : Refactor code for reallocating storage

On 5/20/19 11:11 AM, Ivan Gerasimov wrote: Hi Peter! On 5/19/19 11:17 PM, Peter Levart wrote: Hi Ivan, Roger, What about "calcNewLength" ? The word "new" gives enough hint as to what the method does - it calculates the length of new array to be allocated instead of old one. Yes, I

Re: RFR 8223593 : Refactor code for reallocating storage

Hi Peter! On 5/20/19 3:14 AM, Peter Levart wrote: On 5/20/19 11:11 AM, Ivan Gerasimov wrote: Hi Peter! On 5/19/19 11:17 PM, Peter Levart wrote: Hi Ivan, Roger, What about "calcNewLength" ? The word "new" gives enough hint as to what the method does - it calculates the length of new

Re: RFR 8223593 : Refactor code for reallocating storage

Hi Peter! On 5/19/19 11:17 PM, Peter Levart wrote: Hi Ivan, Roger, What about "calcNewLength" ? The word "new" gives enough hint as to what the method does - it calculates the length of new array to be allocated instead of old one. Yes, I think it was one of intermediate names. But then,

Re: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

* Thomas Stüfe: > Hi all, > > (old mail thread: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html) > > May I please have your reviews and opinions for the following bug fix: > > issue: https://bugs.openjdk.java.net/browse/JDK-8223777 > cr: >

RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

Hi all, (old mail thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html) May I please have your reviews and opinions for the following bug fix: issue: https://bugs.openjdk.java.net/browse/JDK-8223777 cr:

Re: RFR: jsr166 integration 2019-06

Adding trivial fix to this integration: 8224176: Fix inconsistencies in @jls tags in java.util.concurrent https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/jls/index.html https://bugs.openjdk.java.net/browse/JDK-8224176 On Thu, May 16, 2019 at 2:58 PM Martin Buchholz wrote: >

Re: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of should document better the exceptions thrown

Hi Vicente, In the CSR, the Summary should be about the change... "...MethodTypeDesc::of should document all exceptions. Avoid duplication between Summary and Problem. I would omit the part about "content of parameter" or "its contents" is null; It cannot happen and if it does, its more of

Re: JDK 13 RFR of JDK-8224175: Fix inconsistencies in @jls and @jvms tags

Looks good to me. -- Jon On 05/19/2019 12:36 PM, Joe Darcy wrote: Hello, Thanks to some tooling developed by Jon Gibbons, inconsistencies in the section names and numbers in the @jls and @jvms javadoc tags in the jdk and the names and numbers of the current specifications have been

Re: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented exception IllegalArgumentException

Hi Vicente, Looks ok. Can you ident the 2nd and subsequent lines of the javadoc tag, as is done in the other tags of the method. No need for another webrev. Thanks, Roger On 05/20/2019 01:07 PM, Vicente Romero wrote: how does it look now? Thanks, Vicente On 5/17/19 3:58 PM, Vicente Romero

Re: RFR: jsr166 integration 2019-06

Looks good to me -- Jon On 5/20/19 10:49 AM, Martin Buchholz wrote: Adding trivial fix to this integration: 8224176: Fix inconsistencies in @jls tags in java.util.concurrent https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/jls/index.html

Re: RFR 8223593 : Refactor code for reallocating storage

Hi, I'm fine with newLength.  Thanks Peter for articulating what was missing from calcLength. The method name needs to make a positive contribution to comprehension. The three integer arguments don't contribute much, especially since they are constants in some cases, and in other cases are

Re: RFR: JDK-8223723: j.l.c.MethodTypeDesc.dropParameterTypes​ throws the undocumented exception: IllegalArgumentException

Hi Roger, On 5/17/19 4:53 PM, Roger Riggs wrote: Hi Vicente, Looks fine. Please add a "." at the end of the summary 2nd sentence. done BTW, are you aware of the range checking methods in java.util.Objects.checkFromToIndex(from, to, length)? They make it easy avoid to check all the

Re: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented exception IllegalArgumentException

how does it look now? Thanks, Vicente On 5/17/19 3:58 PM, Vicente Romero wrote: Hi Roger, Thanks for the review, my apologies, I made a mistake an applied the change to the wrong method. I have corrected the patch [1] and the CSR [2]. I have updated the language used as you suggested,

Re: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of should document better the exceptions thrown

ping, Thanks, Vicente On 5/17/19 12:55 PM, Vicente Romero wrote: Please review simple fix for [1] at [2] plus the CSR at [3]. This fix is simply documenting all the missing cases in which method java.lang.constant.MethodTypeDesc::of can throw exceptions. A test has been added to cover the

Re: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

Hi Florian, On Mon, May 20, 2019 at 4:24 PM Florian Weimer wrote: > * Thomas Stüfe: > > > Hi all, > > > > (old mail thread: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html > ) > > > > May I please have your reviews and opinions for the following bug fix: > > > >

Re: JDK 13 RFR of JDK-8224174: java.lang.Number has a default constructor

Hi Joe, > On May 20, 2019, at 8:58 AM, Joe Darcy wrote: > >> Looks fine. +1 >> Is this worthy of a CSR? It seems like make-work except that it does change >> the formal Java SE spec that is generated from javadoc. > > Fair point; new CSR at: > >

Re: RFR: jsr166 integration 2019-06

Looks good to me as well; thanks Martin, -Joe On 5/20/2019 11:11 AM, Jonathan Gibbons wrote: Looks good to me -- Jon On 5/20/19 10:49 AM, Martin Buchholz wrote: Adding trivial fix to this integration: 8224176: Fix inconsistencies in @jls tags in java.util.concurrent

RFR 7061590 : Javadoc issues in Charset and StandardCharsets

Hello! A few small javadoc issues. The most visible one is that the last dot in abbreviation a.k.a. is treated as a period, so the generated description appears broken (see [1] ): static

Re: RFR 7061590 : Javadoc issues in Charset and StandardCharsets

Ivan, You would do better to avoid the use of the shorthand "a.k.a." which may not be known to many readers.  In general, the style should be to avoid abbreviations like this, including e.g. i.e. etc. (sic) I recommend replacing "a.k.a." with "also known as:. -- Jon On 05/20/2019 11:48

Re: RFR 7061590 : Javadoc issues in Charset and StandardCharsets

On 20/05/2019 19:48, Ivan Gerasimov wrote: Hello! A few small javadoc issues. The most visible one is that the last dot in abbreviation a.k.a. is treated as a period, so the generated description appears broken (see [1]

Re: RFR 7061590 : Javadoc issues in Charset and StandardCharsets

Thank you Jon and Alan for your suggestions! Here's the new webrev updated accordingly: http://cr.openjdk.java.net/~igerasim/7061590/01/webrev/ With kind regards, Ivan On 5/20/19 12:03 PM, Alan Bateman wrote: On 20/05/2019 19:48, Ivan Gerasimov wrote: Hello! A few small javadoc issues.

Jpackage and MacOs with gatekeeper

I have created a dmg file with jpackage on MacOS High Sierra version using jpackage. I would like to sign the dmg file but the signing parts do not seem work with this version of the OS. There seem to be several problems. 1. The program is hardcoded to look for an application certificate and

Re: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of should document better the exceptions thrown

Hi Roger, On 5/20/19 2:00 PM, Roger Riggs wrote: Hi Vicente, In the CSR, the Summary should be about the change... "...MethodTypeDesc::of should document all exceptions. Avoid duplication between Summary and Problem. thanks, I saw that you already modified the Summary I would omit the

jpackage multiple --add-exports

Hi! When using the JDK13-EA jpackage utility (https://jdk.java.net/jpackage) specifying multiple ‘--add-exports' arguments with ’--java-options' results in the executable only passing the first ‘--add-exports' to the JVM. For example, if the .cfg file generated by jpackage holds the following

RFR: JDK-8224222: Inno setup 6 broke jpackage

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Improve code detecting version of Inno Setup to make it work with Inno Setup v6 updates. [1] https://bugs.openjdk.java.net/browse/JDK-8224222 [2]

Re: JDK 13 RFR of JDK-8224174: java.lang.Number has a default constructor

Hi Roger, On 5/20/2019 6:00 AM, Roger Riggs wrote: Hi Joe, Looks fine. Should the bug be labeled noreg-doc? Sure; I wasn't planning to write any tests for it. Is this worthy of a CSR? It seems like make-work except that it does change the formal Java SE spec that is generated from

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

On 5/16/19 10:06 PM, Alan Snyder wrote: Could you explain the inconsistency in the specification that affects removeAll()? I don’t see it. It's the assumption that the operation can be reversed without changing its semantics. This isn't true, given the existence of SortedSet et. al. This is

Re: [13] RFR: 8224105: Cannot parse JapaneseDate string on some specified locales

Ping? Naoto On 5/17/19 3:43 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8224105 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8224105/webrev.00/ CLDR does not provide entire

Re: RFR (jdk13/java.xml) 8219692: DOM and SAX parser ignore namespace

Thanks Lance! Yikes, forgot the copyright header. The factory files are updated to 2019 now. The test file was okay as it was changed recently. http://cr.openjdk.java.net/~joehw/jdk13/8219692/webrev/ Best, Joe On 5/20/19, 4:09 PM,

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

On 5/16/19 11:48 PM, Peter Levart wrote: As Stuart says, optimizations mustn't change semantics. So is there a possibly narrower optimization, that doesn't change the semantics? Here's a sketch of one: - create a marker interface (could be JDK-internal) and mark all conforming Set

Re: RFR: JDK-8224222: Inno setup 6 broke jpackage

Alexander, I tried running other .exe from ISS install dir. They don't output anything meaningful. File version for all .exe files in ISS install dir is "0.0.0.0". Running isscc.exe without arguments doesn't output version number. Running isscc.exe with the empty project file was the only

Re: JDK 13 RFR of JDK-8224175: Fix inconsistencies in @jls and @jvms tags

Thumbs up on the JShell changes. -Robert On 5/19/19 12:36 PM, Joe Darcy wrote: Hello, Thanks to some tooling developed by Jon Gibbons, inconsistencies in the section names and numbers in the @jls and @jvms javadoc tags in the jdk and the names and numbers of the current specifications have

Re: RFR (jdk13/java.xml) 8219692: DOM and SAX parser ignore namespace

Hi Joe, As we discussed off-line, these changes look OK. Please double check that the copyright is updated in the relevant files. Best Lance > On May 20, 2019, at 7:06 PM, Joe Wang wrote: > > Please review an enhancement to the DOM and SAX factories. By default, > DOM/SAX factories created

Re: jpackage multiple --add-exports

I've been trying your example (or something I have created that is close to it) and thought I was seeing multiple --add-exports are passed to the VM in my case. But on closer look I think when I have 3 "--java-options --add-exports=..." jpackager options, I get the three expected lines in

Re: RFR: JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented exception IllegalArgumentException

thanks for the review, Vicente On 5/20/19 2:09 PM, Roger Riggs wrote: Hi Vicente, Looks ok. Can you ident the 2nd and subsequent lines of the javadoc tag, as is done in the other tags of the method. No need for another webrev. Thanks, Roger On 05/20/2019 01:07 PM, Vicente Romero wrote: how

Re: RFR: JDK-8224222: Inno setup 6 broke jpackage

Hi Alexey, Is there better way to figure out InnoSetup version? Creating empty project file seems complicated. If there no such way, then fix looks fine. Thanks, Alexander On 5/20/2019 8:27 AM, Alexey Semenyuk wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the

RFR (jdk13/java.xml) 8219692: DOM and SAX parser ignore namespace

Please review an enhancement to the DOM and SAX factories. By default, DOM/SAX factories created using the existing newInstance methods do not support XML Namespace. Parsers instantiated with such factories would therefore ignore namespaces. Users not realizing or unaware of the legacy setting