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

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

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

Can someone say whether the two-step package creation feature is implemented and explain how to use it? What is the plan for documentation? The command line help is inadequate. > On Oct 26, 2018, at 1:09 PM, Alan Snyder wrote: > > I noticed the following statement in the JEP: > > In this

Re: Re[2]: The new optimized version of Dual-Pivot Quicksort

Hi, Do you know if someone has written a complete JMH benchmark suite dedicated to Arrays.sort() ? with varying array size (trivial) but also testing lots of data distributions: (see Vladimir's tests) and possibly all variants (int, long, double, Object[] ) It could be part of the standard

Re[4]: The new optimized version of Dual-Pivot Quicksort

Hi Laurent, No information about JMH benchmarking. I use Bentley's test suite to compare algorithms. >Понедельник, 12 ноября 2018, 13:06 +03:00 от Laurent Bourgès >: > >Hi, > >Do you know if someone has written a complete JMH benchmark suite dedicated to >Arrays.sort() ? >with varying array

Re: Re[4]: The new optimized version of Dual-Pivot Quicksort

Dear Vladimir, No information about JMH benchmarking. > I like it as Alexey made the best framework to benchmark short operations, like sorting small arrays. For example, 1000 ints ~ 0.05ms on my i7 laptop at fixed freq = 2ghz. I use Bentley's test suite to compare algorithms. > Is it

Re:

Hi Vladimir, Excellent, I will try your test code asap. Le lun. 12 nov. 2018 à 12:25, Vladimir Yaroslavskiy a écrit : > Hi Laurent, > > The test suite was described in this paper > > Jon L. Bentley, M. Douglas McILroy > “Engineering a Sort Function”, 1993 > > I use Java version (a little bit

RFR - JDK-8203442 String::transform (Code Review) (was: RFR - JDK-8203442 String::transform (Code Review))

updated webrev: http://cr.openjdk.java.net/~jlaskey/8203442/webrev-02/index.html > On Sep 21, 2018, at 7:42 AM, Remi Forax wrote: > > - Mail original - >> De: "Alan Bateman" >> À: "Jim Laskey" , "core-libs-dev" >>

[no subject]

Hi Laurent, The test suite was described in this paper Jon L. Bentley, M. Douglas McILroy “Engineering a Sort Function”, 1993 I use Java version (a little bit extended), see attachment. What you need is to specified sorting classes in IntSorter.java and run BentleyBasher. Please let me know if

Re: RFR: 8213741: Consolidate Object and String Stringifiers

On 11/12/2018 03:24 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8213741/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8213741 Looks good to me. *) Not sure this is significantly better than String.valueOf(String.valueOf(s)), as original comment suggests:

RFR: 8213741: Consolidate Object and String Stringifiers

Hi, following up on JDK-8213478[1], this patch consolidates the use of "Stringifiers" in StringConcatFactory to use a single Stringifier for all String and Object arguments. This has the effect that repeated filters become much more common with the default implementation, and can reduce the

Re: RFR: 8213741: Consolidate Object and String Stringifiers

On 2018-11-12 16:56, Aleksey Shipilev wrote: On 11/12/2018 03:24 PM, Claes Redestad wrote: Webrev: http://cr.openjdk.java.net/~redestad/8213741/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213741 Looks good to me. Thanks! If anyone is wondering: With this and other recent

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, I like this version better :-) But I wonder if skip(n) returning a negative value (ns < 0) when n has been asserted to be > 0 should be considered as an error, and if an IOException should be thrown? I mean - in which cases can a call to skip(n) returning a negative value for a

Proposal: Add support for Process Groups to the JDK

Dear all, may I please hear your thoughts about the following proposal? We would like to add support for process groups to the JDK: the ability to put child processes into new or pre-existing process groups. We added this feature to our proprietary port some time ago and has been very useful in

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

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

On 11/12/2018 3: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

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

On 11/12/18, 1:45 PM, Andy Herrick wrote: On 11/12/2018 3: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.

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

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

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

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

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

On 11/12/2018 4:54 PM, Philip Race wrote: On 11/12/18, 1:45 PM, Andy Herrick wrote: On 11/12/2018 3: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

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

BTW there were also a few minor grammar issues in javadoc eg 41 * the option named "-singleton" must be specified on jpackager command line. "the jpackager" 84 * Registers {@code SingleInstanceListener} for current process. and 96 * Registers {@code SingleInstanceListener}