From alanb at openjdk.org  Sat Oct  1 07:21:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Oct 2022 07:21:51 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v9]
In-Reply-To: <gQMPe5GcAQCW66RZv7cvXbgrXtQDDyWlGzz1ejeo3L0=.afbaa62f-a307-4d4c-8715-7a2c39eb63e0@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <gQMPe5GcAQCW66RZv7cvXbgrXtQDDyWlGzz1ejeo3L0=.afbaa62f-a307-4d4c-8715-7a2c39eb63e0@github.com>
Message-ID: <IYtlWsuoszYU196i_KQ-BCEfA3XqFc6UmBtxr7OaycE=.379242d8-89c8-4786-93d6-ad80b7442f49@github.com>

On Fri, 30 Sep 2022 21:46:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional edits to Runtime and Thread specs.

The updates in ca369058 look okay to me, I don't have any more comments/issues.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9437

From amaembo at gmail.com  Sat Oct  1 07:24:10 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Sat, 1 Oct 2022 09:24:10 +0200
Subject: Collections.shuffle to accept RandomGenerator
In-Reply-To: <SJ0PR18MB4881EA7396DE6199472979CB83579@SJ0PR18MB4881.namprd18.prod.outlook.com>
References: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>
 <0AE34224-3FED-4A34-B8F0-E2E916959600@oracle.com>
 <SJ0PR18MB4881EA7396DE6199472979CB83579@SJ0PR18MB4881.namprd18.prod.outlook.com>
Message-ID: <CAE+3fjYg1PdD9P=GrcxUYpUhKqkobBbYD0Law61KLWRSQ6WwdQ@mail.gmail.com>

Thanks, Paul, Jason. I've filed an issue:
https://bugs.openjdk.org/browse/JDK-8294693

I'm not sure about the lifting shuffle() and making it an instance
method of List interface. The shuffle() is used much less often,
compared to sort(). Also, it produces an unspecified side-effect.
Namely, it updates the state of the supplied RandomGenerator.
Currently, it does this in a very stable way, calling nextInt() size-1
times for any list implementation. So if I initialize a RNG with a
specific seed, then shuffle several lists, they will be shuffled in
predictable manner, regardless of a particular list implementation.
This might be desired, e.g., to write tests or reproduce problems. If
we move it to an instance method, implementations might vary, and
passing identical RNG may produce different shuffle order for lists
with identical content but having different implementations. Moreover,
it may even leave RNG in a different state afterwards which may affect
subsequent operations performed with the same RNG. With sorting, any
implementation must produce the same result, so such questions don't
rise.

With best regards,
Tagir Valeev

On Thu, Sep 29, 2022 at 4:27 AM Jason Mehrens <jason_mehrens at hotmail.com> wrote:
>
> JDK20 has Random.from(RandomGenerator) which could be used to do something like Collections.shuffle(List, Random.from(rg)).
>
> List.shuffle(RandomGenerator ) would allow for more efficient CopyOnWriteArrayList shuffle.
>
> Jason
>
> ________________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
> Sent: Wednesday, September 28, 2022 10:36 AM
> To: Tagir Valeev
> Cc: core-libs-dev at openjdk.org
> Subject: Re: Collections.shuffle to accept RandomGenerator
>
> That looks reasonable.
>
> Thinking a little more broadly.
>
> We could also change Collections.shuffle(List) to use ThreadLocalRandom so it does not have to cache the Random instance, plus it has better concurrent and PRNG properties. The spec does not describe the precise details of randomness.
>
> It?s tempting to lift Collections.shuffle(List, RandomGenerator) to List.shuffle(RandomGenerator ), similar to what we did for Collections.sort, to align with that pattern and which also aligns with reverse of sequenced collections. There is likely not much performance advantage to do doing so as there was with sort, but that location is much easier to find and use IMHO. Since the method accepts RandomGenerator the compatibility risk would likely be low.
>
> Paul.
>
> > On Sep 27, 2022, at 3:11 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> >
> > Hello!
> >
> > Currently, Collections.shuffle(List, Random) accepts an outdated
> > Random class instead of RandomGenerator interface. It looks like,
> > RandomGenerator would suffice. The code change looks trivial (aside
> > from documentation and testing), as shuffle() implementation does not
> > need anything except nextInt:
> >
> > diff --git a/src/java.base/share/classes/java/util/Collections.java
> > b/src/java.base/share/classes/java/util/Collections.java
> > --- a/src/java.base/share/classes/java/util/Collections.java (revision
> > cab590517bf705418c7376edd5d7066b13b6dde8)
> > +++ b/src/java.base/share/classes/java/util/Collections.java (date
> > 1664273240190)
> > @@ -37,6 +37,7 @@
> > import java.util.function.IntFunction;
> > import java.util.function.Predicate;
> > import java.util.function.UnaryOperator;
> > +import java.util.random.RandomGenerator;
> > import java.util.stream.IntStream;
> > import java.util.stream.Stream;
> > import java.util.stream.StreamSupport;
> > @@ -454,8 +455,12 @@
> >      * @throws UnsupportedOperationException if the specified list or its
> >      *         list-iterator does not support the {@code set} operation.
> >      */
> > -    @SuppressWarnings({"rawtypes", "unchecked"})
> >     public static void shuffle(List<?> list, Random rnd) {
> > +        shuffle(list, (RandomGenerator) rnd);
> > +    }
> > +
> > +    @SuppressWarnings({"rawtypes", "unchecked"})
> > +    public static void shuffle(List<?> list, RandomGenerator rnd) {
> >         int size = list.size();
> >         if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
> >             for (int i=size; i>1; i--)
> >
> > What do you think? Should we implement this improvement? I think I can
> > contribute if there's a general agreement that such an enhancement
> > would be useful.
> >
> > With best regards,
> > Tagir Valeev
>

From tvaleev at openjdk.org  Sat Oct  1 08:16:56 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 1 Oct 2022 08:16:56 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface
Message-ID: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>

Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).

As we are here, it would also be nice to get rid of Collections.r static random generator which is used by default, and use ThreadLocalRandom instead. This will reduce the contention if shuffle() without explicit random generator is called from different threads concurrently.

-------------

Commit messages:
 - 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface

Changes: https://git.openjdk.org/jdk/pull/10520/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294693
  Stats: 128 lines in 2 files changed: 121 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10520.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10520/head:pull/10520

PR: https://git.openjdk.org/jdk/pull/10520

From amitchoudhary0523 at gmail.com  Sat Oct  1 09:58:52 2022
From: amitchoudhary0523 at gmail.com (Amit)
Date: Sat, 1 Oct 2022 15:28:52 +0530
Subject: Code for Console for Java JAR programs.
Message-ID: <CAFf+5zgA-a9FO9spiFPPm_e=01d0mO9ajEqOCpKHdAf-pAk8kA@mail.gmail.com>

Code for Console for Java JAR programs in case someone needs it.

Description: When you run a jar file by double-clicking on it, you
don't get console so all your input/output have to be on GUI. This
program solves this problem and gives users/programmers a console
which can be used for input/output as done on console by command line
programs. So, in effect this program gives a console for JAR programs.

-------------------------------------------------------------------------------------------

// License: This file has been released under APACHE LICENSE, VERSION 2.0.
// The license details can be found here:
https://www.apache.org/licenses/LICENSE-2.0

import java.io.*;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;

public class Console_For_JAR_Programs implements KeyListener, ActionListener {

    Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
    int screenWidth = screenSize.width;
    int screenHeight = screenSize.height;

    String title = null;

    JFrame jf = null;
    JTextArea jta = null;
    JScrollPane jsp = null;
    JMenuBar jmb = null;
    JMenu jm = null;
    JMenuItem jmi = null;

    // key codes
    int BACKSPACE = 8;
    int ENTER = 10;
    int PG_UP = 33; // do nothing for this key pressed
    int PG_DN = 34; // do nothing for this key pressed
    int END = 35;
    int HOME = 36;
    int LEFT_ARROW = 37;
    int UP_ARROW = 38; // do nothing for this key pressed
    //int RIGHT_ARROW = 39; // handled by JTextArea
    int DOWN_ARROW = 40; // do nothing for this key pressed

    int CTRL = 128;
    int A = 65; // disable ctrl-a
    int H = 72; // handle ctrl-h
    //int DELETE = 127; // handled by JTextArea

    int initialCaretPosition = 0;
    int endOfInputCaretPosition = 0;
    final Object lock1 = new Object();
    final Object lock2 = new Object();
    boolean inputAvailable = false;
    byte[] b = null;
    int len = -1;
    int indexIntoByteArray = -1;
    boolean newLineSent = false;
    byte endOfInput = -1;
    byte newLine = 10;
    boolean enterAlreadyPressedEarlier = false;

    @Override
    public void actionPerformed(ActionEvent ae) {
        int cCurrPos = jta.getCaretPosition();
        jta.selectAll();
        jta.copy();
        jta.select(cCurrPos, cCurrPos);
    } // end of actionPerformed

    @Override
    public void keyTyped(KeyEvent ke) {
    } // end of keyTyped

    @Override
    public void keyReleased(KeyEvent ke) {
    } // end of keyReleased

    @Override
    public void keyPressed(KeyEvent ke) {
        Thread.currentThread().getId();
        int keyCode = ke.getKeyCode();
        if ((keyCode == PG_UP) || (keyCode == PG_DN) || (keyCode ==
UP_ARROW) || (keyCode == DOWN_ARROW) || ((keyCode == A) &&
(ke.getModifiersEx() == CTRL))) {
            ke.consume();
        } else if ((keyCode == LEFT_ARROW) || (keyCode == BACKSPACE)
|| ((keyCode == H) && (ke.getModifiersEx() == CTRL))) {
            synchronized(lock1) {
                if (jta.getCaretPosition() <= initialCaretPosition) {
                    ke.consume();
                }
            } // end of synchronized block
        } else if (keyCode == HOME) {
            synchronized(lock1) {
                jta.setCaretPosition(initialCaretPosition);
                ke.consume();
            } // end of synchronized block
        } else if (keyCode == END) {
            synchronized(lock1) {
                jta.setCaretPosition(jta.getDocument().getLength());
                ke.consume();
            } // end of synchronized block
        } else if (keyCode == ENTER) {
            // this if block should not exit until all the input has been
            // processed.
            synchronized(lock1) {
                inputAvailable = true;
                endOfInputCaretPosition = jta.getDocument().getLength();
                //if ((endOfInputCaretPosition - initialCaretPosition) == 1) {
                    // only newline was entered, so increment
initialCaretPosition
                if ((enterAlreadyPressedEarlier == true) &&
(endOfInputCaretPosition - initialCaretPosition) > 0) {
                    // need to increment initialCaretPosition by 1 to
account for last enter pressed
                    initialCaretPosition++;
                }
                jta.setCaretPosition(jta.getDocument().getLength());
                enterAlreadyPressedEarlier = true;
                lock1.notifyAll();
            }
            // wait until all input has been processed
            synchronized(lock2) {
                //if (Thread.holdsLock(lock2) == true) {
System.out.println("Thread id: " + Thread.currentThread().getId() + ",
lock2 is held"); } else { System.out.println("Thread id: " +
Thread.currentThread().getId() + ", lock2 is _not_ held"); }
                try {
                    lock2.wait();
                } catch (Exception e) {
                    //System.out.println("Exception (debug:1): " +
e.getMessage());
                }
            }
        } // end of if else if
    } // end of keyPressed

    byte getNextByteFromJTextArea() {
        String s = "";
        Thread.currentThread().getId();
        synchronized(lock1) {
            //if (Thread.holdsLock(lock1) == true) {
System.out.println("Thread id: " + Thread.currentThread().getId() + ",
lock1 is held"); } else { System.out.println("Thread id: " +
Thread.currentThread().getId() + ", lock1 is _not_ held"); }
            if (inputAvailable == false) {
                try {
                    lock1.wait();
                } catch (Exception e) {
                    //System.out.println("Excpetion (debug:2): " +
e.getMessage());
                    //System.exit(1);
                } // end of try catch
            } // end of if inputAvailable

            if (newLineSent == true) {
                // send endOfInput now, all input has been prcocessed, anyone
                // waiting on lock2 should be woken up and some variables
                // should be re-initialized
                newLineSent = false;
                b = null;
                len = -1;
                indexIntoByteArray = -1;
                inputAvailable = false;
                initialCaretPosition = jta.getDocument().getLength();
                endOfInputCaretPosition = jta.getDocument().getLength();
                synchronized(lock2) {
                    //if (Thread.holdsLock(lock2) == true) {
                    //    System.out.println("lock2 is held..2..Thread
id = " + Thread.currentThread().getId());
                    //} else {
                    //    System.out.println("lock2 is ___not___
held..2..Thread id = " + Thread.currentThread().getId());
                    //}
                    lock2.notifyAll();
                    return endOfInput;
                }
            } // end of if newLineSent

            if (len == -1) { // read input
                len = endOfInputCaretPosition - initialCaretPosition;
                try {
                    s = jta.getText(initialCaretPosition, len);
                    b = s.getBytes(); // enter is still getting
processed, the text area
                                      // hasn't been updated with the
enter, so send a
                                      // newline once all bytes have been sent.
                } catch (Exception e) {
                    //System.out.println("Exception (debug:3): " +
e.getMessage());
                    if (b != null) {
                        Arrays.fill(b, (byte)(-1));
                    }
                } // end of try catch
            } // end of if len == -1

            // if control reaches here then it means that we have to send a byte
            indexIntoByteArray++;
            if (indexIntoByteArray == len) { // send newLine as all
input have been sent already
                newLineSent = true;
                return newLine;
            }
            if (b[indexIntoByteArray] == newLine) {
                newLineSent = true;
            }
            return b[indexIntoByteArray];
        } // end of synchronized block
    } // end of getNextByteFromJTextArea

    void outputToJTextArea(byte b) {
        Thread.currentThread().getId();
        synchronized(lock1) {
            char ch = (char)(b);
            String text = Character.toString(ch);
            jta.append(text);
            jta.setCaretPosition(jta.getDocument().getLength());
            initialCaretPosition = jta.getCaretPosition();
            enterAlreadyPressedEarlier = false;
        }
    } // end of outputToJTextArea

    void configureJTextAreaForInputOutput() {
        jta.addKeyListener(this);

        // remove all mouse listeners
        for (MouseListener listener : jta.getMouseListeners()) {
            //outputToJTextArea(jta, "\nRemoving mouse listener\n");
            jta.removeMouseListener(listener);
        }

        // remove all mouse motion listeners
        for (MouseMotionListener listener : jta.getMouseMotionListeners()) {
            //outputToJTextArea(jta, "\nRemoving mouse motion listener\n");
            jta.removeMouseMotionListener(listener);
        }

        // remove all mouse wheel listeners
        for (MouseWheelListener listener : jta.getMouseWheelListeners()) {
            //outputToJTextArea(jta, "\nRemoving mouse wheel listener\n");
            jta.removeMouseWheelListener(listener);
        }

        System.setIn(new InputStream() {
            @Override
            public int read() {
                // we need to sleep here because of some threading issues
                //try {
                //    Thread.sleep(1);
                //} catch (Exception e) {
                    //System.out.println("Exception (debug:4): " +
e.getMessage());
                //}
                byte b = getNextByteFromJTextArea();
                return ((int)(b));
            }
        });

        System.setOut(new PrintStream(new OutputStream() {
            @Override
            public void write(int b) {
                outputToJTextArea((byte)(b));
            }
        }));

        System.setErr(new PrintStream(new OutputStream() {
            @Override
            public void write(int b) {
                outputToJTextArea((byte)(b));
            }
        }));

    } // end of configureJTextAreaForInputOutput

    void createAndShowConsole() {
        title = "Console";
        jf = InitComponents.setupJFrameAndGet(title,
(3*screenWidth)/4, (3*screenHeight)/4);

        jta = InitComponents.setupJTextAreaAndGet("", 5000, 100, true,
true, true, false, 0, 0, 0, 0);
        jta.setBackground(Color.WHITE);
        jta.setForeground(Color.BLACK);
        jta.setCaretColor(Color.BLACK);
        jta.setFont(jta.getFont().deriveFont(13.5f));

        configureJTextAreaForInputOutput();

        jsp = InitComponents.setupScrollableJTextAreaAndGet(jta, 10,
10, (3*screenWidth)/4 - 33, (3*screenHeight)/4 - 79);
        jsp.setHorizontalScrollBarPolicy(ScrollPaneConstants.HORIZONTAL_SCROLLBAR_AS_NEEDED);
        jsp.setVerticalScrollBarPolicy(ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS);
        jf.add(jsp);

        jmb = InitComponents.setupJMenuBarAndGet();
        jm = InitComponents.setupJMenuAndGet("Copy All to Clipboard");
        jm.setBorder(BorderFactory.createLineBorder(Color.green, 2));
        jmi = InitComponents.setupJMenuItemAndGet("Copy All to Clipboard");
        jm.add(jmi);
        jmb.add(jm);
        jmi.addActionListener(this);
        jf.setJMenuBar(jmb);

        jf.setLocationRelativeTo(null);
        jf.setVisible(true);
    } // end of createAndShowConsole

    public static void main(String[] args) {
        Console_For_JAR_Programs cfjpv2 = new Console_For_JAR_Programs();
        cfjpv2.createAndShowConsole();

        while (true) {
            try {
                BufferedReader br = null;
                String input = "";
                System.out.println();
                System.out.print("Enter some input (BufferedReader
Example) (press enter after inputting): ");
                br = new BufferedReader(new InputStreamReader(System.in));
                input = br.readLine();
                System.out.print("User input was: " + input + "\n\n");
                //System.err.println("Is this getting printed?\n\n");

                System.out.print("Enter an int, then float, then a
string (Scanner Example): ");
                Scanner sc = new Scanner(System.in);
                int num = sc.nextInt();
                float f = sc.nextFloat();
                String s = sc.nextLine();
                System.out.println("Number: " + num);
                System.out.println("Float: " + f);
                System.out.println("String: " + s);

            } catch (Exception e) {
                //System.out.println("Exception (debug:5): " + e.getMessage());
            }
        } // end of while true
    } // end of main

} // end of Console_For_JAR_Programs

class InitComponents {

    public static JFrame setupJFrameAndGet(String title, int width,
int height) {
        JFrame tmpJF = new JFrame(title);
        tmpJF.setSize(width, height);
        tmpJF.setLocationRelativeTo(null);
        tmpJF.setLayout(null);
        tmpJF.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        return tmpJF;
    } // end of setupJFrameAndGet

    public static JTextArea setupJTextAreaAndGet(String text, int
rows, int columns, boolean setEditableFlag, boolean setLineWrapFlag,
boolean setWrapStyleWordFlag, boolean setBoundsFlag, int xpos, int
ypos, int width, int height) {
        JTextArea tmpJTA = new JTextArea(text, rows, columns);
        tmpJTA.setEditable(setEditableFlag);
        tmpJTA.setLineWrap(setLineWrapFlag);
        tmpJTA.setWrapStyleWord(setWrapStyleWordFlag);
        if (setBoundsFlag == true) {
            tmpJTA.setBounds(xpos, ypos, width, height);
        }
        return tmpJTA;
    } // end of setupJTextAreaAndGet

    public static JScrollPane setupScrollableJTextAreaAndGet(JTextArea
jta, int xpos, int ypos, int width, int height) {
        JScrollPane tmpJSP = new JScrollPane(jta);
        tmpJSP.setBounds(xpos, ypos, width, height);
        return tmpJSP;
    } // end of setupScrollableJTextAreaAndGet

    public static JMenuBar setupJMenuBarAndGet() {
        JMenuBar tmpJMB = new JMenuBar();
        return tmpJMB;
    } // end of setupJMenuBarAndGet

    public static JMenu setupJMenuAndGet(String text) {
        JMenu tmpJM = new JMenu(text);
        return tmpJM;
    } // end of setupJMenuAndGet

    public static JMenuItem setupJMenuItemAndGet(String text) {
        JMenuItem tmpJMI = new JMenuItem(text);
        return tmpJMI;
    } // end of setupJMenuItemAndGet

}// end of InitComponents

-------------------------------------------------------------------------------------------

From lancea at openjdk.org  Sat Oct  1 10:52:28 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 1 Oct 2022 10:52:28 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <OzS-leEMgHAR7JSa4RyIp4K5XrJZ38ZIdvfGiIfRqqg=.4409020a-7d1a-4f19-89d5-dbfe6f0f1302@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

Looks good Justin, thank you for removing the wrapper.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475

From weijun at openjdk.org  Sat Oct  1 15:02:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 1 Oct 2022 15:02:04 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <nFiCHw9g6IyGbqTuxvar8EhHobplelceRLF1KqsySv0=.5e63a863-e6c0-4f0a-a6cd-c972a0221308@github.com>
 <eM7WMgB7uVvIw-lqL8AzCf6zG-Xz6UUQQPibY5hRn6A=.80c398cb-9d26-4b94-b73c-50c85e438730@github.com>
 <RAPey5BSjlbfy8WMa3N39QofovAuJ1wnJdx9xm-lvJw=.12e7b645-4668-4810-a24f-4c6fc20cd9ed@github.com>
Message-ID: <azol0p7osOA4BoEFm_2HZT1U9GmKrrF4_vMq3o35hVE=.7e936b3f-a0fa-41e8-bf82-66f977688fd8@github.com>

On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?
>
> This is correct.
> AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../"

Thanks @prrace. And yes, git link is better.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From aturbanov at openjdk.org  Sat Oct  1 16:26:13 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 1 Oct 2022 16:26:13 GMT
Subject: RFR: 8294695: Remove redundant deprecation suppression in ThreadGroup
Message-ID: <rXOKKce8LqlA9RUDyGDseVApE8Ey7VTdGbVzOp0TaPE=.c89770fb-1247-4996-865e-ac0c4e925743@github.com>

This suppression were added with Loom integration, but method `Thread.getThreadGroup()` is not deprecated.
Let's cleanup code a bit.
https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094907.html

-------------

Commit messages:
 - [PATCH] Remove redundant deprecation suppression in ThreadGroup

Changes: https://git.openjdk.org/jdk/pull/10521/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10521&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294695
  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10521.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10521/head:pull/10521

PR: https://git.openjdk.org/jdk/pull/10521

From duke at openjdk.org  Sat Oct  1 18:01:02 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 1 Oct 2022 18:01:02 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails with
 OOME
Message-ID: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>

Fixes 8294541

-------------

Commit messages:
 - Fixed 8294541

Changes: https://git.openjdk.org/jdk/pull/10524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294541
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10524.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10524/head:pull/10524

PR: https://git.openjdk.org/jdk/pull/10524

From alanb at openjdk.org  Sat Oct  1 18:24:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Oct 2022 18:24:18 GMT
Subject: RFR: 8294695: Remove redundant deprecation suppression in
 ThreadGroup
In-Reply-To: <rXOKKce8LqlA9RUDyGDseVApE8Ey7VTdGbVzOp0TaPE=.c89770fb-1247-4996-865e-ac0c4e925743@github.com>
References: <rXOKKce8LqlA9RUDyGDseVApE8Ey7VTdGbVzOp0TaPE=.c89770fb-1247-4996-865e-ac0c4e925743@github.com>
Message-ID: <65ufOqZKFtrCEHSQw7pg1w2DXD0fCu6vkmE6wJ9djS8=.90c1b85d-c7bb-4fc7-b6df-b45791623608@github.com>

On Sat, 1 Oct 2022 16:17:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> This suppression were added with Loom integration, but method `Thread.getThreadGroup()` is not deprecated.
> Let's cleanup code a bit.
> https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094907.html

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10521

From duke at openjdk.org  Sat Oct  1 20:36:07 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 1 Oct 2022 20:36:07 GMT
Subject: RFR: 8294696 - draining buffer instead of falling back to
 super.transferTo
Message-ID: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>

This PR implements JDK-8294696.

-------------

Commit messages:
 - draining buffer instead of falling back to super.transferTo

Changes: https://git.openjdk.org/jdk/pull/10525/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294696
  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10525/head:pull/10525

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Sat Oct  1 20:37:35 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 1 Oct 2022 20:37:35 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo
 [v11]
In-Reply-To: <Krgv8GySho1g_UyeDrJa-4sc5HkbtPizXBCC3yk097k=.e6832aef-173d-4bde-a754-dd52cc3b0cb8@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <_la5Co3yx5ik1wt7Y6Bi7MDC3MCVUxIKxz_iQQp2TT8=.1023ef6d-266f-45f5-aa93-7218d0d89c10@github.com>
 <34XpvO2kWiaGOek0LRM_ZW5Wlkbp1pW5NzDaKZc3N1I=.93222a1d-3ed7-4700-9115-8bc47a077bbd@github.com>
 <Krgv8GySho1g_UyeDrJa-4sc5HkbtPizXBCC3yk097k=.e6832aef-173d-4bde-a754-dd52cc3b0cb8@github.com>
Message-ID: <bKgaWUr8d_WgtK0iR9VT7wsd2O9G2e4z15eVbXyVFFo=.52c06c3e-aaee-4acc-92cf-523e9dce49e6@github.com>

On Sun, 11 Sep 2022 08:04:36 GMT, Markus KARG <duke at openjdk.org> wrote:

> I think you are asking if is safe to leak a reference to the internal buffer. If there is no mark then it might be okay because there is no replay for an evil output stream to attack. However, I think it would require wider review to be confident that there aren't other interesting ways to break it; hence the suggestion in one of the earlier comments to keep it simple and limit it when there is no subclassing, no mark, and no bytes buffered. This does not prevent widening the conditions in the future.

@AlanBateman I opened [another PR](https://github.com/openjdk/jdk/pull/10525) to continue this discussion.

-------------

PR: https://git.openjdk.org/jdk/pull/6935

From jason_mehrens at hotmail.com  Sun Oct  2 01:48:01 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Sun, 2 Oct 2022 01:48:01 +0000
Subject: Collections.shuffle to accept RandomGenerator
In-Reply-To: <CAE+3fjYg1PdD9P=GrcxUYpUhKqkobBbYD0Law61KLWRSQ6WwdQ@mail.gmail.com>
References: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>
 <0AE34224-3FED-4A34-B8F0-E2E916959600@oracle.com>
 <SJ0PR18MB4881EA7396DE6199472979CB83579@SJ0PR18MB4881.namprd18.prod.outlook.com>
 <CAE+3fjYg1PdD9P=GrcxUYpUhKqkobBbYD0Law61KLWRSQ6WwdQ@mail.gmail.com>
Message-ID: <SJ0PR18MB48812F9068DA932E9F26044283589@SJ0PR18MB4881.namprd18.prod.outlook.com>

Tagir,

Yes I have mixed feeling about promoting shuffle to List.  I did notice that java.util.Arrays doesn't have a shuffle method.  Perhaps adding RandomGenerator shuffle and slice variant of shuffle to that class would be something to consider.  Array backed lists could then use that method to perform a shuffle without having to use asList.

Jason

________________________________________
From: Tagir Valeev <amaembo at gmail.com>
Sent: Saturday, October 1, 2022 2:24 AM
To: Jason Mehrens
Cc: Paul Sandoz; core-libs-dev at openjdk.org
Subject: Re: Collections.shuffle to accept RandomGenerator

Thanks, Paul, Jason. I've filed an issue:
https://bugs.openjdk.org/browse/JDK-8294693

I'm not sure about the lifting shuffle() and making it an instance
method of List interface. The shuffle() is used much less often,
compared to sort(). Also, it produces an unspecified side-effect.
Namely, it updates the state of the supplied RandomGenerator.
Currently, it does this in a very stable way, calling nextInt() size-1
times for any list implementation. So if I initialize a RNG with a
specific seed, then shuffle several lists, they will be shuffled in
predictable manner, regardless of a particular list implementation.
This might be desired, e.g., to write tests or reproduce problems. If
we move it to an instance method, implementations might vary, and
passing identical RNG may produce different shuffle order for lists
with identical content but having different implementations. Moreover,
it may even leave RNG in a different state afterwards which may affect
subsequent operations performed with the same RNG. With sorting, any
implementation must produce the same result, so such questions don't
rise.

With best regards,
Tagir Valeev

On Thu, Sep 29, 2022 at 4:27 AM Jason Mehrens <jason_mehrens at hotmail.com> wrote:
>
> JDK20 has Random.from(RandomGenerator) which could be used to do something like Collections.shuffle(List, Random.from(rg)).
>
> List.shuffle(RandomGenerator ) would allow for more efficient CopyOnWriteArrayList shuffle.
>
> Jason
>
> ________________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
> Sent: Wednesday, September 28, 2022 10:36 AM
> To: Tagir Valeev
> Cc: core-libs-dev at openjdk.org
> Subject: Re: Collections.shuffle to accept RandomGenerator
>
> That looks reasonable.
>
> Thinking a little more broadly.
>
> We could also change Collections.shuffle(List) to use ThreadLocalRandom so it does not have to cache the Random instance, plus it has better concurrent and PRNG properties. The spec does not describe the precise details of randomness.
>
> It?s tempting to lift Collections.shuffle(List, RandomGenerator) to List.shuffle(RandomGenerator ), similar to what we did for Collections.sort, to align with that pattern and which also aligns with reverse of sequenced collections. There is likely not much performance advantage to do doing so as there was with sort, but that location is much easier to find and use IMHO. Since the method accepts RandomGenerator the compatibility risk would likely be low.
>
> Paul.
>
> > On Sep 27, 2022, at 3:11 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> >
> > Hello!
> >
> > Currently, Collections.shuffle(List, Random) accepts an outdated
> > Random class instead of RandomGenerator interface. It looks like,
> > RandomGenerator would suffice. The code change looks trivial (aside
> > from documentation and testing), as shuffle() implementation does not
> > need anything except nextInt:
> >
> > diff --git a/src/java.base/share/classes/java/util/Collections.java
> > b/src/java.base/share/classes/java/util/Collections.java
> > --- a/src/java.base/share/classes/java/util/Collections.java (revision
> > cab590517bf705418c7376edd5d7066b13b6dde8)
> > +++ b/src/java.base/share/classes/java/util/Collections.java (date
> > 1664273240190)
> > @@ -37,6 +37,7 @@
> > import java.util.function.IntFunction;
> > import java.util.function.Predicate;
> > import java.util.function.UnaryOperator;
> > +import java.util.random.RandomGenerator;
> > import java.util.stream.IntStream;
> > import java.util.stream.Stream;
> > import java.util.stream.StreamSupport;
> > @@ -454,8 +455,12 @@
> >      * @throws UnsupportedOperationException if the specified list or its
> >      *         list-iterator does not support the {@code set} operation.
> >      */
> > -    @SuppressWarnings({"rawtypes", "unchecked"})
> >     public static void shuffle(List<?> list, Random rnd) {
> > +        shuffle(list, (RandomGenerator) rnd);
> > +    }
> > +
> > +    @SuppressWarnings({"rawtypes", "unchecked"})
> > +    public static void shuffle(List<?> list, RandomGenerator rnd) {
> >         int size = list.size();
> >         if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
> >             for (int i=size; i>1; i--)
> >
> > What do you think? Should we implement this improvement? I think I can
> > contribute if there's a general agreement that such an enhancement
> > would be useful.
> >
> > With best regards,
> > Tagir Valeev
>

From jwaters at openjdk.org  Sun Oct  2 10:16:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Oct 2022 10:16:45 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v29]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <atkse9IIAV_OQFcKB0z5zGQdkYFDLkunx1-FdfE6LAY=.f2014900-eb13-4bd4-bb48-b031f8910a63@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Finish

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/a4fa093e..6b43fc60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=27-28

  Stats: 331 lines in 63 files changed: 59 ins; 11 del; 261 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Sun Oct  2 10:19:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Oct 2022 10:19:18 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v30]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <iaJnilWb1sZIBigoO6TYwdXlQliDAf8wKXgPpwVWn_s=.7d286c28-0699-426a-9f3e-49ac691f76af@github.com>

> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rework
 - Cleanup
 - Finish
 - Merge remote-tracking branch 'upstream/master' into rework
 - Cleanup
 - Cleanup
 - JNU_ThrowByNameWithMessageAndLastError
 - Progress
 - Remove getErrorString
 - Merge remote-tracking branch 'upstream/master' into rework
 - ... and 5 more: https://git.openjdk.org/jdk/compare/058336df...962b90ca

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/6b43fc60..962b90ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=28-29

  Stats: 638 lines in 24 files changed: 418 ins; 159 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Sun Oct  2 10:44:07 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Oct 2022 10:44:07 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v31]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <6KLo6QWoXVZsz6btw25Ku75XDW3i947X0iFPkW8PS38=.6c484190-83d2-4d7b-b1ae-c375411b5218@github.com>

> WIP

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  NET_ThrowByNameWithLastError

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/962b90ca..67169553

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=29-30

  Stats: 40 lines in 17 files changed: 0 ins; 0 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From mik3hall at gmail.com  Sun Oct  2 13:36:53 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 2 Oct 2022 08:36:53 -0500
Subject: [External] : Re: RFR: 8293462: [macos] app image signature
 invalid when creating DMG or PKG from post processed signed image
In-Reply-To: <4D5AF283-2A40-42DA-B06B-9573BB7A8A22@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
 <9CC241FC-952A-46D6-BBF7-FC1CBE094AE0@gmail.com>
 <55C45641-6A82-4F9D-85DA-4A757AB209AD@gmail.com>
 <3642C6F3-E022-4C7B-B8CD-6A2FA0345583@oracle.com>
 <4D5AF283-2A40-42DA-B06B-9573BB7A8A22@gmail.com>
Message-ID: <A49F6A6B-D970-4E3C-B8EA-1B62D2A32E57@gmail.com>



> On Sep 27, 2022, at 4:27 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 27, 2022, at 2:48 PM, Alexander Matveev <alexander.matveev at oracle.com <mailto:alexander.matveev at oracle.com>> wrote:
>> 
>> Hi Michael,
>> 
>> It is not possible to provide a unique or hashed CFBundleIdentifier. We already implemented to throw error if ?strip-native-commands are not provided to jlink or if provided runtime contain bin directory.
>> Look at https://github.com/openjdk/jdk/pull/8666 <https://github.com/openjdk/jdk/pull/8666>
>> 
>> Thanks,
>> Alexander
>> 

Alexander,
FWIW I came up with another workaround/fix for this. 
Sort of as suggested it modifies the CFBundleIdentifier in the application java command's embedded Info.plist. 
To do this requires post-processing. So it is somewhat a use case for that and a test that some changes can be made to the jdk itself and still get a valid signed application.
The command is PlistZap
http://mikehall.pairserver.com/PlistZap.java
Historical basis for name?
https://www.jaymoseley.com/hercules/zap_utility/imaspzap.htm <https://www.jaymoseley.com/hercules/zap_utility/imaspzap.htm>
It was and probably still is a IBM mainframe program for doing disk patches or fixes. 
Early Apple java versions had 1 or 2 occasions where similar fixes were suggested so my java shell application includes an ?fzap? command. Some of that 20+ year old code is included in the above.
PlistZap finds the embedded Info.plist and changes only the part of the CFBundleIndentifier that is set to ?openjdk?. It replaces this with a random string based on all characters valid for a CFBundleIdentifier?
https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier <https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier>
So the basic structure of the current CFBundleIdentifier remains intact but you get I believe 63^7 randomness included. I think this should be sufficient to avoid collisions. But have done no direct testing. It would be easy enough. Generate a few hundred or few thousand random strings and make sure there are no duplicates.
I did find using a built jdk, for post-processing, rather than an installed jdk includes a ?-internal? in the CFBundleIdentifier so I added a ?-I? switch to the command for that. 
So anyhow, example of use shows file hex dumps at the change?

java -cp /Users/mjh PlistZap -i HalfPipe.app/Contents/runtime/Contents/Home/bin/java
Before...
3e00 66696572 3c2f6b65 793e0a20 20202020  fier</key>.     
3e10 2020203c 73747269 6e673e6e 65742e6a     <string>net.j
3e20 6176612e 6f70656e 6a646b2d 696e7465  ava.openjdk-inte
3e30 726e616c 2e6a6176 613c2f73 7472696e  rnal.java</strin
After...
3e00 66696572 3c2f6b65 793e0a20 20202020  fier</key>.     
3e10 2020203c 73747269 6e673e6e 65742e6a     <string>net.j
3e20 6176612e 6f776a6a 7552752d 696e7465  ava.owjjuRu-inte
3e30 726e616c 2e6a6176 613c2f73 7472696e  rnal.java</strin
done

Showing signature is still valid after signing?
codesign -v --verbose=4 "HalfPipe.app"                   
HalfPipe.app: valid on disk
HalfPipe.app: satisfies its Designated Requirement

And from the application it still works?
exec ${java.home}/bin/java -version
openjdk version "20-internal" 2023-03-21
OpenJDK Runtime Environment (build 20-internal-adhoc.mjh.jdk)
OpenJDK 64-Bit Server VM (build 20-internal-adhoc.mjh.jdk, mixed mode)

I realize there are possibly not enough applications involved for this to be a major concern but a hash like fix would be possible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221002/ae413251/attachment.htm>

From jwaters at openjdk.org  Sun Oct  2 13:54:12 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Oct 2022 13:54:12 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v32]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <7YJiFhgFKVyWN7rAVBiUHKvRuaN-lVLZXBMZK-22WSs=.1db0cb37-5149-4ca5-ad51-647fff5926e1@github.com>

> WIP

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Aesthetic
 - Fix JLI_Perror and JLI_Snprintf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/67169553..a14c55c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=30-31

  Stats: 53 lines in 2 files changed: 18 ins; 34 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From alanb at openjdk.org  Sun Oct  2 15:18:57 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 2 Oct 2022 15:18:57 GMT
Subject: RFR: 8294696 - draining buffer instead of falling back to
 super.transferTo
In-Reply-To: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
Message-ID: <snomWk-tCyQgfrEVNwJIQrM--xF6qsCjS1G3-RKJmck=.0d587ace-b826-4d16-8631-e575abcc7ead@github.com>

On Sat, 1 Oct 2022 20:29:23 GMT, Markus KARG <duke at openjdk.org> wrote:

> This PR implements JDK-8294696.

This change leaks a reference to the internal buffer to the wrapped class so I think we have to be cautious and make sure that it doesn't introduce any security concerns. Also you've changed the check for a mark in a subtle way - the spec is very clear that -1 is the value when there is no mark position, values less than -1 are not defined.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Sun Oct  2 18:01:27 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 2 Oct 2022 18:01:27 GMT
Subject: RFR: 8294696 - draining buffer instead of falling back to
 super.transferTo
In-Reply-To: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
Message-ID: <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>

On Sat, 1 Oct 2022 20:29:23 GMT, Markus KARG <duke at openjdk.org> wrote:

> This PR implements JDK-8294696.

I think the leak is actually not a problem. `ByteArrayInputStream::transferTo` does the same BTW, see https://github.com/openjdk/jdk/blob/68da02c7b536799ccca49e889c22f3e9a2691fb7/src/java.base/share/classes/java/io/ByteArrayInputStream.java#L206-L211
In case the wrapped stream would write into the leaked buffer, that "injected" data would be lost, as no replay can happen due to the `mark == -1`  safety check. So unless we remove that check (which is not planned), such "injected" data is never read.

The JavaDoc of `markpos` literally says:

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From jwaters at openjdk.org  Sun Oct  2 18:44:54 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Oct 2022 18:44:54 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v33]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <jKVhUVQ4_3zZ2FE9UU5Qss0EaJcCVllKlW9jvAmlzNg=.5e9a7329-f965-4f2a-b035-bea170269ef0@github.com>

> WIP

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Missing include on Windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/a14c55c8..a92df1d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=31-32

  Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Sun Oct  2 20:44:04 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 2 Oct 2022 20:44:04 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v34]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <ZmwZMrtZelxqcp8_FNnib2YCPNmowEVd7gy_AXnq6cw=.8eb3fb2a-8944-4572-8ef2-e54ce332de61@github.com>

> WIP

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Cast to void instead of void pointer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/a92df1d6..b89fb8b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=32-33

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From duke at openjdk.org  Sun Oct  2 20:57:12 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 2 Oct 2022 20:57:12 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
Message-ID: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>

`checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`

-------------

Commit messages:
 - 8294698: Remove unused 'checkedExceptions' param from MethodAccessorGenerator.generateMethod()

Changes: https://git.openjdk.org/jdk/pull/10526/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294698
  Stats: 16 lines in 4 files changed: 0 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10526/head:pull/10526

PR: https://git.openjdk.org/jdk/pull/10526

From darcy at openjdk.org  Sun Oct  2 22:06:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 2 Oct 2022 22:06:20 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <pCQ2BQu90c5Y1unot4E9spU79ReaV4hRXafN0Cfwsjw=.dce5abe4-ef72-412a-874d-dcda57317b6e@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From redestad at openjdk.org  Sun Oct  2 22:20:03 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 2 Oct 2022 22:20:03 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
Message-ID: <qJqDVbEFVeyoGJs0rp49j9j9Hl-08KS7pfOgDXSFzvw=.2071887a-c8ae-4c3a-9392-4b6a2ecf4e21@github.com>

On Sun, 2 Oct 2022 20:45:02 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`

Seems reasonable, although these generators should only rarely be used when doing reflection. I'm curious if you have some test or micro where the improvement shows?

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From svkamath at openjdk.org  Mon Oct  3 05:45:55 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 3 Oct 2022 05:45:55 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v12]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <boOgrSt4CuE9RvDrmiNMim1dXUKyqkXNpB_PIDwNQpk=.3b139c31-d49d-4177-b9b3-1a3740223825@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Updated instruction definition
 - Merge branch 'master'
 - Addressed review comment to update test case
 - Addressed review comments
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8289552
 - Addressed review comments
 - Added missing parantheses
 - Addressed review comments, updated microbenchmark
 - Updated copyright comment
 - Updated test cases as per review comments
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ac2b491b...69999ce4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/8ccc0657..69999ce4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=10-11

  Stats: 14672 lines in 427 files changed: 7255 ins; 5491 del; 1926 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From duke at openjdk.org  Mon Oct  3 05:54:31 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 3 Oct 2022 05:54:31 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
Message-ID: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>

> This PR implements JDK-8294696.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Checking explicitly -1 instead of < 0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10525/files
  - new: https://git.openjdk.org/jdk/pull/10525/files/0aee81f1..26d4f53f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10525/head:pull/10525

PR: https://git.openjdk.org/jdk/pull/10525

From alanb at openjdk.org  Mon Oct  3 05:54:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Oct 2022 05:54:32 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set
In-Reply-To: <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>
Message-ID: <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>

On Sun, 2 Oct 2022 17:57:35 GMT, Markus KARG <duke at openjdk.org> wrote:

> I think the leak is actually not a problem. 

BAIS is a fixed size. This is different to BIS where it wraps an input stream that may be changing, e.g. write an input stream to a file that is growing and call transferTo several times then you'll see what I mean. We need to mark sure we look at this very closely, that is all I'm saying.

> Regarding the `-1` check: I did that to align it with _all other_ checks of `markpos` in the existing source code of BIS. I can undo that change, but following your warning, shouldn't we fix _all other_ checks (independent of this PR) from `markpos < 0` to `markpos == -1` then?

Probably yes.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Mon Oct  3 06:22:10 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 3 Oct 2022 06:22:10 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set
In-Reply-To: <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>
 <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>
Message-ID: <q7Ou4D8IHf-8heC-XOCjaxgDq83PgN9qGfiibRu7Hmw=.ae86c088-6db6-45fb-98d6-a0e4179dcc7c@github.com>

On Mon, 3 Oct 2022 05:50:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Regarding the `-1` check: I did that to align it with _all other_ checks of `markpos` in the existing source code of BIS. I can undo that change, but following your warning, shouldn't we fix _all other_ checks (independent of this PR) from `markpos < 0` to `markpos == -1` then?
> 
> Probably yes.

I propose that I open another PR for that as those code locations are unrelated to the current PR, and this cross-method change might make the review more complex.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From jpai at openjdk.org  Mon Oct  3 06:28:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Oct 2022 06:28:26 GMT
Subject: RFR: 8294695: Remove redundant deprecation suppression in
 ThreadGroup
In-Reply-To: <rXOKKce8LqlA9RUDyGDseVApE8Ey7VTdGbVzOp0TaPE=.c89770fb-1247-4996-865e-ac0c4e925743@github.com>
References: <rXOKKce8LqlA9RUDyGDseVApE8Ey7VTdGbVzOp0TaPE=.c89770fb-1247-4996-865e-ac0c4e925743@github.com>
Message-ID: <5QQKJzTD5s1PEiO47_LPhJo4EQwGy1_TdvH_MawBj_M=.b2904ea4-af31-491f-b418-87caf38dc416@github.com>

On Sat, 1 Oct 2022 16:17:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> This suppression were added with Loom integration, but method `Thread.getThreadGroup()` is not deprecated.
> Let's cleanup code a bit.
> https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094907.html

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10521

From itakiguchi at openjdk.org  Mon Oct  3 07:16:29 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 3 Oct 2022 07:16:29 GMT
Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>
Message-ID: <iVATVZV3X2vYq-kic_T0AWP48-tn-2TaTC3X9b8okuk=.20eb250d-ff9b-4922-a3e5-8b1303e9a53e@github.com>

On Fri, 26 Aug 2022 09:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets.
>> |Charset|Mix|SBCS|DBCS|
>> | -- | -- | -- | -- |
>> | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 |
>> | Korean | Cp933 | Cp833 | Cp834 |
>> 
>> But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets.
>> 
>> I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency
>> |Charset|Mix|SBCS|DBCS|
>> | ------------- | ------------- | ------------- | ------------- |
>> | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 |
>> | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** |
>> | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | 
>> 
>> *1: Cp037 compatible
>
>> Use following options, like OpenJDK: `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047 20000 1 1` ICU4J `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047_P100-1995 20000 1 1`
>> 
>> Actually, I'm confused by this result. Previously, I was just comparing A/A with B/B on OpenJDK's charset. I didn't think ICU4J's result would make a difference.
> 
> My initial reaction is one of relief that the icu4j provider can be used with current JDK builds. This means there is an option should we decide to stop adding more EBCDIC charsets to the JDK.
> 
> The test uses IBM-1047 and I can't tell if the icu4j provider is used or not. Charset doesn't define a provider method but I think would be useful to print cs.getClass() or cs.getClass().getModule() so we know which Charset implementation is used. Also I think any discussion on performance would be better served with a JMH benchmark rather than a standalone test.

Hello @AlanBateman .
Sorry I'm late.

I created Charset SPI JAR `x-IBM1047_SPI` (`custom-charsets.jar`) which was ported from `sun.nio.cs.SingleByte.java` and `IBM1047.java` (generated one).

Test code:

package com.example;

import java.nio.charset.Charset;
import org.openjdk.jmh.annotations.Benchmark;

public class MyBenchmark {

    final static String s;

    static {
        char[] ca = new char[0x2000];
        for (int i = 0; i < ca.length; i++) {
            ca[i] = (char) (i & 0xFF);
        }
        s = new String(ca);
    }

    @Benchmark
    public void testIBM1047() throws Exception {
        byte[] ba = s.getBytes("IBM1047");
    }

    @Benchmark
    public void testIBM1047_SPI() throws Exception {
        byte[] ba = s.getBytes("x-IBM1047_SPI");
    }

}

All test related files are in [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834).

Test results are as follows on RHEL8.6 x86_64 (Intel Core i7 3520M) :

1.8.0_345-b01
Benchmark                     Mode  Cnt      Score     Error  Units
MyBenchmark.testIBM1047      thrpt   25  53213.092 ? 126.962  ops/s
MyBenchmark.testIBM1047_SPI  thrpt   25  47442.669 ? 349.003  ops/s


20-ea+17-1181
Benchmark                     Mode  Cnt       Score      Error  Units
MyBenchmark.testIBM1047      thrpt   25  136331.141 ? 1078.481  ops/s
MyBenchmark.testIBM1047_SPI  thrpt   25   51563.213 ?  843.238  ops/s

IBM1047 is 2.6 times faster than the SPI version on JDK20.
I think this results are related to **JEP 254: Compact Strings** .
As I requested before, we'd like to use `sun.nio.cs.SingleByte*` and `sun.nio.cs.DoubleByte*` class as public API.

-------------

PR: https://git.openjdk.org/jdk/pull/9399

From duke at openjdk.org  Mon Oct  3 07:36:22 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 3 Oct 2022 07:36:22 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream.transferTo uses undefined value
 range for markpos
Message-ID: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>

Fixes JDK-8294702

-------------

Commit messages:
 - Fixes JDK-8294702

Changes: https://git.openjdk.org/jdk/pull/10528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294702
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10528.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10528/head:pull/10528

PR: https://git.openjdk.org/jdk/pull/10528

From duke at openjdk.org  Mon Oct  3 07:36:22 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 3 Oct 2022 07:36:22 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream.transferTo uses undefined
 value range for markpos
In-Reply-To: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
Message-ID: <g370RpFegr6AyMyok9sYI8qb1qWzhf9qWEIVhVmDbAw=.33ec0690-1912-4ac4-8ffb-ec19cc8165d6@github.com>

On Mon, 3 Oct 2022 07:29:02 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8294702

@AlanBateman Kindly requesting review, as originally it was you who complained about using `< 0` in that class, see https://github.com/openjdk/jdk/pull/10525#issuecomment-1264966011.

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From duke at openjdk.org  Mon Oct  3 08:07:27 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 3 Oct 2022 08:07:27 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <qJqDVbEFVeyoGJs0rp49j9j9Hl-08KS7pfOgDXSFzvw=.2071887a-c8ae-4c3a-9392-4b6a2ecf4e21@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
 <qJqDVbEFVeyoGJs0rp49j9j9Hl-08KS7pfOgDXSFzvw=.2071887a-c8ae-4c3a-9392-4b6a2ecf4e21@github.com>
Message-ID: <qSdoG74SyGznPXYvlmKj_7XKWWk8LDqePPtGVXKzkGs=.6936ab52-0031-4f87-8559-9716559ca1fa@github.com>

On Sun, 2 Oct 2022 22:16:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`
>
> Seems reasonable, although these generators should only rarely be used when doing reflection. I'm curious if you have some test or micro where the improvement shows?

@cl4es this code is frequently invoked in Spring-based applications at start-up time. I couldn't design the benchmark for this particular case, assuming that in majority of cases `Method.getExceptionTypes()` returns a copy of an empty array I think we save about 12 ns and 16 bytes:

@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
public class ArrayCloneBenchmark {
  private final Object[] array = new Object[0];

  @Benchmark
  public Object[] cloneArray() {
    return array.clone();
  }
}


Benchmark                                                        Mode  Cnt    Score    Error   Units
ArrayCloneBenchmark.cloneArray                                   avgt   20   12,713 ?  0,484   ns/op
ArrayCloneBenchmark.cloneArray:?gc.alloc.rate                    avgt   20  800,247 ? 29,584  MB/sec
ArrayCloneBenchmark.cloneArray:?gc.alloc.rate.norm               avgt   20   16,004 ?  0,001    B/op
ArrayCloneBenchmark.cloneArray:?gc.churn.G1_Eden_Space           avgt   20  804,623 ? 38,424  MB/sec
ArrayCloneBenchmark.cloneArray:?gc.churn.G1_Eden_Space.norm      avgt   20   16,091 ?  0,455    B/op
ArrayCloneBenchmark.cloneArray:?gc.churn.G1_Survivor_Space       avgt   20    0,006 ?  0,002  MB/sec
ArrayCloneBenchmark.cloneArray:?gc.churn.G1_Survivor_Space.norm  avgt   20   ? 10??             B/op
ArrayCloneBenchmark.cloneArray:?gc.count                         avgt   20  286,000           counts
ArrayCloneBenchmark.cloneArray:?gc.time                          avgt   20  171,000               ms

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From alanb at openjdk.org  Mon Oct  3 08:28:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Oct 2022 08:28:26 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream.transferTo uses undefined
 value range for markpos
In-Reply-To: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
Message-ID: <Mv_oFMSez14TqWdxfaXYNftPtwlIvB1Hp22hBjvZd8k=.a02e1691-789f-4040-a364-b891cd0e5a75@github.com>

On Mon, 3 Oct 2022 07:29:02 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8294702

This looks fine, just change the description to "BufferedInputStream uses undefined ..." as this issue is nothing to do with transferTo.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10528

From rgiulietti at openjdk.org  Mon Oct  3 08:30:14 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Oct 2022 08:30:14 GMT
Subject: RFR: 8294705: Disable an assertion in
 test/jdk/java/util/DoubleStreamSums/CompensatedSums.java
Message-ID: <c7HjXcVRhWCTAZ1Tf7AM5YDvdyjdieIC2o9LPnZdYfU=.aeb7977f-2d7e-4775-afdf-46b87fa8eed5@github.com>

Disables a specific assertion that causes intermittent failures.

-------------

Commit messages:
 - 8294705: Disable an assertion in test/jdk/java/util/DoubleStreamSums/CompensatedSums.java

Changes: https://git.openjdk.org/jdk/pull/10529/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10529&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294705
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10529.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10529/head:pull/10529

PR: https://git.openjdk.org/jdk/pull/10529

From duke at openjdk.org  Mon Oct  3 08:32:37 2022
From: duke at openjdk.org (Sarawin9)
Date: Mon, 3 Oct 2022 08:32:37 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream.transferTo uses undefined
 value range for markpos
In-Reply-To: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
Message-ID: <vBk-bmAzw2w7PXqSeI9x6MhAIvKtcckUv0V-cA6D8oE=.58e23efb-d153-4704-812f-f52e3a8137d6@github.com>

On Mon, 3 Oct 2022 07:29:02 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8294702

Marked as reviewed by Sarawin9 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From qamai at openjdk.org  Mon Oct  3 08:36:30 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 3 Oct 2022 08:36:30 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <P3WD1fmVLCwmvGi1rEyYNJg9vRN0J8JgV8bn4eIHsc4=.186a8e48-1cb9-4e88-b2e2-7ca142fb9163@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
 <P3WD1fmVLCwmvGi1rEyYNJg9vRN0J8JgV8bn4eIHsc4=.186a8e48-1cb9-4e88-b2e2-7ca142fb9163@github.com>
Message-ID: <ix-SKa4ZivpVntpiwiIhQfRExnjCTZO2MbJkrw-je80=.294816e5-2607-4580-a108-bb90abd2701b@github.com>

On Fri, 30 Sep 2022 10:04:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comment to update test case
>
> src/hotspot/cpu/x86/x86.ad line 3674:
> 
>> 3672: %}
>> 3673: 
>> 3674: instruct convF2HF_mem_reg(memory mem, regF src, kReg ktmp, rRegI rtmp) %{
> 
> You can use `kmovwl` instead which will relax the avx512bw constraint, however, you will need avx512vl for `evcvtps2ph`. Thanks.

Rethink about it, you can get 0x01 by right shifting k0 to the right - `kshiftrw(ktmp, k0, 15)`

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From duke at openjdk.org  Mon Oct  3 08:41:11 2022
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 3 Oct 2022 08:41:11 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
 [v2]
In-Reply-To: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
Message-ID: <Znhpl9V1rAR4kktvts8g1Q75P-8HrX408c3vDTaU6_E=.e0ed8bb3-ec18-4c4e-b586-62b1c16f7b00@github.com>

> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.

Viktor Klang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8279361 - Error in documentation of third Stream.reduce method
  
  Removes the partial pseudo-code which omitted the details regarding the `combiner`
  as it was deemed confusing.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10469/files
  - new: https://git.openjdk.org/jdk/pull/10469/files/9bdd85b7..5f93e779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10469&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10469&range=00-01

  Stats: 47 lines in 4 files changed: 0 ins; 42 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10469.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10469/head:pull/10469

PR: https://git.openjdk.org/jdk/pull/10469

From duke at openjdk.org  Mon Oct  3 08:41:12 2022
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 3 Oct 2022 08:41:12 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
In-Reply-To: <W3qCfO8RX32vhX6PF1ldDke6_VcnGuiMJp8yTDaFUFY=.182f1c1f-dd31-4e2f-aac7-ccb751bf9bf1@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
 <W3qCfO8RX32vhX6PF1ldDke6_VcnGuiMJp8yTDaFUFY=.182f1c1f-dd31-4e2f-aac7-ccb751bf9bf1@github.com>
Message-ID: <JZkHTF3RVxyquvjowqI8CtEGNmJTiymyt42Cl9ZvxD0=.b92cea5f-90b3-44ef-810e-e8872848d863@github.com>

On Fri, 30 Sep 2022 21:34:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.
>
> Deleting the pseudocode might be the right way to go. To restate the meta-issue, a problem with pseudocode is that it's difficult to separate the accidental from the essential. With something that has as much essential complexity as parallel reduction, it seems like pseudocode introduces a lot of accidental complexity that can be confusing or misleading. So yeah, if pseudocode isn't helping, then get rid of it.

@stuart-marks I'm inclined to agree with you and I have updated this PR to remove the pseudo-code from all places I found it in./cc @PaulSandoz

-------------

PR: https://git.openjdk.org/jdk/pull/10469

From duke at openjdk.org  Mon Oct  3 08:45:34 2022
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 3 Oct 2022 08:45:34 GMT
Subject: RFR: 8279361: Error in documentation of third Stream.reduce method
 [v3]
In-Reply-To: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
References: <ZDScXuIYVuxEWWS2YvBff2WIm5IURggmJAJ6d7PQ9r8=.c4e324e0-a0ea-4c85-901e-0f77303b8f24@github.com>
Message-ID: <YfFBeWtFv3W1DHa_RaQi8g96jZNfvGbEOHU2V0rN4O8=.3fc70542-3324-4480-88d4-29a4f1c113fe@github.com>

> This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Updating the copyright year to 2022 for changes related to issue 8279361

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10469/files
  - new: https://git.openjdk.org/jdk/pull/10469/files/5f93e779..83706e0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10469&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10469&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10469.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10469/head:pull/10469

PR: https://git.openjdk.org/jdk/pull/10469

From alanb at openjdk.org  Mon Oct  3 08:53:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Oct 2022 08:53:35 GMT
Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <iVATVZV3X2vYq-kic_T0AWP48-tn-2TaTC3X9b8okuk=.20eb250d-ff9b-4922-a3e5-8b1303e9a53e@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>
 <iVATVZV3X2vYq-kic_T0AWP48-tn-2TaTC3X9b8okuk=.20eb250d-ff9b-4922-a3e5-8b1303e9a53e@github.com>
Message-ID: <m93ke-sbqGrG2rTVctm_idprBv-FqNs8eNRVf_9A3ic=.ee6bfb5f-78a3-4fd4-8bbc-7d19ea28766d@github.com>

On Mon, 3 Oct 2022 07:14:09 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Test results are as follows on RHEL8.6 x86_64 (Intel Core i7 3520M) :
> 
> ```
> 1.8.0_345-b01
> Benchmark                     Mode  Cnt      Score     Error  Units
> MyBenchmark.testIBM1047      thrpt   25  53213.092 ? 126.962  ops/s
> MyBenchmark.testIBM1047_SPI  thrpt   25  47442.669 ? 349.003  ops/s
> ```
> 
>  ```
> 20-ea+17-1181
> Benchmark                     Mode  Cnt       Score      Error  Units
> MyBenchmark.testIBM1047      thrpt   25  136331.141 ? 1078.481  ops/s
> MyBenchmark.testIBM1047_SPI  thrpt   25   51563.213 ?  843.238  ops/s
> ```
> 
> IBM1047 is 2.6 times faster than the SPI version on JDK20. I think this results are related to **JEP 254: Compact Strings** . As I requested before, we'd like to use `sun.nio.cs.SingleByte*` and `sun.nio.cs.DoubleByte*` class as public API.

I don't think that is a workable option. Maybe you could do more performance analysis on the providers that are using the SPI to see if there are any secure primitives that would make sense to expose in java.nio.charset.spi?  I'm hesitate to suggest adding base classes to java.nio.charset.spi but that may be something that could be exposed too.

-------------

PR: https://git.openjdk.org/jdk/pull/9399

From duke at openjdk.org  Mon Oct  3 09:41:24 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 3 Oct 2022 09:41:24 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <nry-aKoKUn-GECMSY3WNHJkn1MRQ8cgHZhtvw7L-tOs=.f6e5d4b6-c4ed-484a-8365-e475353fa148@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
 <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>
 <SEXLY0pFioXy1sOLP8x4qJLARtwQwBJFDso6n7RdZsg=.925b1fd6-6a1b-4371-b14a-006618f62040@github.com>
 <4ARgpqckW-WNkVGHuxIznh32zqRF75NlpGEDTQ7Nvlk=.ddcc063a-a821-49f6-b0fe-aaed1de2e3c6@github.com>
 <nry-aKoKUn-GECMSY3WNHJkn1MRQ8cgHZhtvw7L-tOs=.f6e5d4b6-c4ed-484a-8365-e475353fa148@github.com>
Message-ID: <jc2Z-EFQOuNL7FcE8i1SGkUJ1EIYXi0ciXwh_6PBkGg=.7e98b525-0fb7-424b-9ea3-aab3118c7e19@github.com>

On Thu, 29 Sep 2022 19:03:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Well, what concerns me with the current fix is that it is simply patching only the case for the Japanese setup. We don't know if the same failure would happen in other setups (I'm pretty sure the same failure would happen with some Chinese Windows setups) which makes the test fragile. If that happens, we are not sure if it is a real bug or a test case false positive at a glance. For that reason, I think we should only run tests on the setup where we are sure the false positive won't happen (by skipping other unknown host encodings). And for the purpose of this test, that should suffice the need.
>> Another option would be to actually check if the test string can be encoded with a CharsetEncoder, but that may be overkill.
>
> I don't think it will be many practical setups where this test fails. This test has been around for more than 2 years and this is the first accident.

At least, the results in different encodings are the same as before the fix.
How about not fixing the pattern for other encordings to avoid false negative?

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From rgiulietti at openjdk.org  Mon Oct  3 09:53:51 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Oct 2022 09:53:51 GMT
Subject: RFR: 8294509: The sign extension bug applies to 'public static int[]
 convertSeedBytesToInts(byte[] seed, int n, int z)' in RandomSupport
Message-ID: <hohBnlhoL1xDz4Lmfs_2uAZmfQ5wnXYxyxCSGyd7VBw=.e01b6087-a419-461d-9ffc-2d556fd12eea@github.com>

Fixes sign extension propagation to higher bits.

-------------

Commit messages:
 - 8294509: The sign extension bug applies to 'public static int[] convertSeedBytesToInts(byte[] seed, int n, int z)' in RandomSupport

Changes: https://git.openjdk.org/jdk/pull/10530/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294509
  Stats: 41 lines in 2 files changed: 39 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10530.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10530/head:pull/10530

PR: https://git.openjdk.org/jdk/pull/10530

From coffeys at openjdk.org  Mon Oct  3 10:30:54 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 3 Oct 2022 10:30:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Check for 0 security events

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/aed938d2..f8faecf4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=01-02

  Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Mon Oct  3 10:30:54 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 3 Oct 2022 10:30:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <j4k9R1AoIxafqLpYbXI7jAvBWX2S6BRsXGgLMyuH5_s=.f513dae6-42ac-4c83-b077-981c74779f4e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <QXIQe5EqORYqyigwI84XMHTEYvY3jM-ersDVdN9EeKo=.c0f4ab18-b7f9-4ee9-abc7-816fbd37ff5b@github.com>
 <tPKKm9gjnIZtbN189Qb-o0-Mv6fiNq9lm5lUJtjxXcM=.3b43450c-a7fa-4ce0-8004-3b5329597f6b@github.com>
 <5TadUhgSG09rHgRo7EFIblKjlnvHr-q2DGSGfV2ezF0=.6e824b66-846c-476f-a372-6d5260e3d399@github.com>
 <H5QVVX7TbXodlDE2Q4AtJVU2sTGe3px3Trr8J-o0C0g=.db75c32e-da1d-4e7a-bb1b-fa5c990069d7@github.com>
 <PGi2fwmUOQzOgYcQMCAAqSQQbZK-__--erPRuuyNJMg=.f35b927d-ae6f-47e5-9d4a-90660019e785@github.com>
 <leSw2o-uNaML1WUN_Koh9j9rxW6mkx75_hdFtjeWCYE=.26b43b59-3406-430e-9429-ab3ab3d9172e@github.com>
 <bcYWFVve9-ZRf5OoEB1oAW91ySR1BtUYG9uOtNE-x28=.35da7b5d-b0ed-4666-a00a-c7eabc363ab1@github.com>
 <_FWF1bciUEsK9fBUiOle73_FYQWgwOkS1PvPQqzfYxU=.59bb14be-7cd0-4b92-b80f-1c4869c8803e@github.com>
 <j4k9R1AoIxafqLpYbXI7jAvBWX2S6BRsXGgLMyuH5_s=.f513dae6-42ac-4c83-b077-981c74779f4e@github.com>
Message-ID: <k5OoMvRFJmm4EycfauwZe4YWDZFRGAiwqnH9i9miiQE=.cfbc2498-3e8f-432f-9a6a-4457c1188e94@github.com>

On Fri, 30 Sep 2022 19:32:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Thanks @egahlin  - maybe we can leave it at beginChunk setting then.
>> 
>> I've been doing some testing to satisfy myself that the impact of this event on performance is minimal, Running the new `emitInitialSecurityProperties()` is showing a cost of ~ 1.6ms (1602998 ns). 
>> 
>> This new Event itself doesn't trigger extra class loading AFAICT. I went back to a jdk 20 binary without this patch and ran some tests. 
>> 
>> `ProtectionDomain ` is a very early class to initialize [1] (initPhase2)
>> 
>> Without JFR, `java.security.Security` will initialize in a default JDK with a JMX `Agent.startLocalManagementAgent` call in a simple HelloWorld test which prints "Hello" and then sleeps  [2] - the JMX thread starts after about 3 seconds of runtime.
>> 
>> Without JFR and by using the `-XX:+DisableAttachMechanism` option, the Security class will not load in same test.
>> 
>> If JFR is on, then Security class is already being loaded, even without this patch [3]
>> 
>> [1]
>> 
>> 	at java.base/java.security.ProtectionDomain.<clinit>(ProtectionDomain.java:64)
>> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:316)
>> 	at java.base/java.lang.ClassLoader.<init>(ClassLoader.java:431)
>> 	at java.base/java.security.SecureClassLoader.<init>(SecureClassLoader.java:113)
>> 	at java.base/jdk.internal.loader.BuiltinClassLoader.<init>(BuiltinClassLoader.java:194)
>> 	at java.base/jdk.internal.loader.ClassLoaders$BootClassLoader.<init>(ClassLoaders.java:135)
>> 	at java.base/jdk.internal.loader.ClassLoaders.<clinit>(ClassLoaders.java:79)
>> 	at java.base/jdk.internal.loader.BootLoader.loadModule(BootLoader.java:120)
>> 	at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:266)
>> 	at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
>> 	at java.base/java.lang.System.initPhase2(System.java:2214)
>> 
>> 
>> [2]
>> 
>> 	at java.base/java.security.Security.<clinit>(Security.java:73)
>> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:93)
>> 	at java.base/sun.net.InetAddressCachePolicy$1.run(InetAddressCachePolicy.java:90)
>> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
>> 	at java.base/sun.net.InetAddressCachePolicy.<clinit>(InetAddressCachePolicy.java:89)
>> 	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:1005)
>> 	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1658)
>> 	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1524)
>> 	at java.base/java.net.InetAddress.getByName(InetAddress.java:1413)
>> 	at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:531)
>> 	at jdk.management.agent/jdk.internal.agent.Agent.startLocalManagementAgent(Agent.java:317)
>> 
>> 
>> [3]
>> 
>> 
>> 	at java.base/java.security.Security.<clinit>(Security.java:73)
>> 	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
>> 	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
>> 	at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
>> 	at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
>> 	at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
>> 	at java.base/java.security.AccessControlContext.<init>(AccessControlContext.java:270)
>> 	at java.base/java.security.AccessController.createWrapper(AccessController.java:649)
>> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:461)
>> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.doPrivilegedWithReturn(SecuritySupport.java:261)
>> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.getPathInProperty(SecuritySupport.java:331)
>> 	at jdk.jfr/jdk.jfr.internal.SecuritySupport.<clinit>(SecuritySupport.java:80)
>> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.checkAvailability(JVMSupport.java:46)
>> 	at jdk.jfr/jdk.jfr.internal.JVMSupport.<clinit>(JVMSupport.java:41)
>> 	at jdk.jfr/jdk.jfr.internal.Logger.<clinit>(Logger.java:41)
>> 	at jdk.jfr/jdk.jfr.internal.dcmd.AbstractDCmd.execute(AbstractDCmd.java:75)
>
> When support for the SM is removed, the dependency on `AccessController.doPrivileged` will be removed and there may no longer be a JFR dependency on loading the `Security` class. So, it is ok for now, but a solution that doesn't depend on this might be better in the long run.

fair point. Worse case scenario is that we don't record security properties on start up. Not the case for now though. I've added some extra code to check for this in the test.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mik3hall at gmail.com  Mon Oct  3 11:05:08 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 3 Oct 2022 06:05:08 -0500
Subject: [External] : Re: RFR: 8293462: [macos] app image signature
 invalid when creating DMG or PKG from post processed signed image
In-Reply-To: <A49F6A6B-D970-4E3C-B8EA-1B62D2A32E57@gmail.com>
References: <-sMR9P3CEZeJ31UFe7bzIcnC86rSErUVbY0GOymUoo4=.7c954bca-25c7-4fa0-9e2a-076ce2a485d4@github.com>
 <20F8AC2D-C71B-4892-A2F3-C9A07501046F@gmail.com>
 <707A13E7-9047-428B-86FA-C4DFA047146C@oracle.com>
 <D847BFBF-6DEE-4F39-8EF8-5E1CF3CE3453@gmail.com>
 <A80F3462-C69A-401D-BD23-26391CD96B8C@gmail.com>
 <9CC241FC-952A-46D6-BBF7-FC1CBE094AE0@gmail.com>
 <55C45641-6A82-4F9D-85DA-4A757AB209AD@gmail.com>
 <3642C6F3-E022-4C7B-B8CD-6A2FA0345583@oracle.com>
 <4D5AF283-2A40-42DA-B06B-9573BB7A8A22@gmail.com>
 <A49F6A6B-D970-4E3C-B8EA-1B62D2A32E57@gmail.com>
Message-ID: <A4ABE32E-9E0C-4CD9-844D-64005E0C6A21@gmail.com>



> On Oct 2, 2022, at 8:36 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> and a test that some changes can be made to the jdk itself and still get a valid signed application.

Alexander 

You may want to consider if this opens up a security vulnerability that doesn?t currently exist. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221003/4356c368/attachment-0001.htm>

From duke at openjdk.org  Mon Oct  3 11:05:48 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 3 Oct 2022 11:05:48 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos
In-Reply-To: <Mv_oFMSez14TqWdxfaXYNftPtwlIvB1Hp22hBjvZd8k=.a02e1691-789f-4040-a364-b891cd0e5a75@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <Mv_oFMSez14TqWdxfaXYNftPtwlIvB1Hp22hBjvZd8k=.a02e1691-789f-4040-a364-b891cd0e5a75@github.com>
Message-ID: <fnRudKERCJoaj2oGx2E4HLYakasokvRINc0Njqtjdm8=.b785727a-79b5-491e-a44d-11055d3c2cba@github.com>

On Mon, 3 Oct 2022 08:26:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks fine, just change the description to "BufferedInputStream uses undefined ..." as this issue is nothing to do with transferTo.

Done. Thanks! :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From redestad at openjdk.org  Mon Oct  3 11:07:24 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 3 Oct 2022 11:07:24 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
Message-ID: <Yc7jhro-T0I7AfbCkfhxOAM5S95WCMQRHrwkKjKoNac=.db8f57af-2add-407d-a430-3a91f166f583@github.com>

On Sun, 2 Oct 2022 20:45:02 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`

I agree that getting rid of the clone can help -- but since [JEP 416](https://openjdk.org/jeps/416) the generators modified here is mostly a fallback and the bulk of the use will use `MethodHandles` (unless you disable JEP 416 and fall back to the legacy impl). I was mostly curious if you had a startup or other benchmark running on mainline where the change you're doing here could be observed.

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From duke at openjdk.org  Mon Oct  3 11:10:24 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 3 Oct 2022 11:10:24 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos
In-Reply-To: <Mv_oFMSez14TqWdxfaXYNftPtwlIvB1Hp22hBjvZd8k=.a02e1691-789f-4040-a364-b891cd0e5a75@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <Mv_oFMSez14TqWdxfaXYNftPtwlIvB1Hp22hBjvZd8k=.a02e1691-789f-4040-a364-b891cd0e5a75@github.com>
Message-ID: <BmD6mHAEOXypDW8kxWb0shm4atD5wTPBwBhoCCDBe9Q=.41d3edee-baa7-4188-83bd-de3969519d52@github.com>

On Mon, 3 Oct 2022 08:26:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Fixes JDK-8294702
>
> This looks fine, just change the description to "BufferedInputStream uses undefined ..." as this issue is nothing to do with transferTo.

@AlanBateman Kindly requesting `/sponsor`: -)

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From redestad at openjdk.org  Mon Oct  3 11:12:34 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 3 Oct 2022 11:12:34 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
Message-ID: <wJ-0HrsdQfxTW3sOMvTj_z_pDOIwqUPKd-Q3QcRxKng=.9b137840-8194-43f4-9305-c72ce3b4a0e3@github.com>

On Sun, 2 Oct 2022 20:45:02 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`

Marked as reviewed by redestad (Reviewer).

Approving since changes are trivial and having less code never hurts

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From john_platts at hotmail.com  Mon Oct  3 11:36:13 2022
From: john_platts at hotmail.com (John Platts)
Date: Mon, 3 Oct 2022 11:36:13 +0000
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on
 Japanese Windows platform [v2]
In-Reply-To: <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
Message-ID: <SN6PR05MB583744B1D8DB2DC245BD02F89D5B9@SN6PR05MB5837.namprd05.prod.outlook.com>

The issue can be worked around on Windows 10 Version 1903 or later (including Windows 11) by modifying the src/java.base/windows/native/launcher/java.manifest file as follows:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0"
          xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
>
<assemblyIdentity
    name=""
    version=""
    processorArchitecture="X86"
    type="win32"
/>
<description>Java(TM) SE process</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>

  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>

  <!-- Indicate JDK is high-dpi aware. -->
  <asmv3:application>
    <asmv3:windowsSettings xmlns:dpi1="http://schemas.microsoft.com/SMI/2005/WindowsSettings"
                           xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"
                           xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings">
      <dpi1:dpiAware>true/PM</dpi1:dpiAware>
      <dpi2:dpiAwareness>PerMonitorV2, PerMonitor, system</dpi2:dpiAwareness>
      <!-- Use UTF-8 as the active code page on Windows 10 version 1903 or later -->
      <utf8:activeCodePage>UTF-8</utf8:activeCodePage>
    </asmv3:windowsSettings>
  </asmv3:application>

  <!-- Indicate this JDK version is Windows 7 compatible -->
   <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
      <application>
        <!-- Windows Vista -->
        <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
        <!-- Windows 7 -->
        <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
        <!-- Windows 8 -->
        <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
        <!-- Windows 8.1 -->
        <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
        <!-- Windows 10 -->
        <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
      </application>
    </compatibility>
</assembly>

The GetACP() and GetOEMCP() functions will both return 65001 on Windows 10 Version 1903 or later if the above changes are made to src/java.base/windows/native/launcher/java.manifest.

Also make sure that the sun.jnu.encoding property is set to UTF-8 if GetACP() returns 65001.

Note that it is possible for GetACP() and GetOEMCP() to return values other than 65001 on Windows 10 Version 1809 or earlier or if the JVM is embedded in an application that does not have the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting in its manifest.

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Naoto Sato <naoto at openjdk.org>
Sent: Wednesday, September 28, 2022 1:03 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: RFR: 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform [v2]

On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Could you please review the JDK-8293579 bug fixes?
>>
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give
>> the launcher the character which is encoded by Windows API WideCharToMultiByte()
>> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the
>> code point "?"(0x00e9) cannot be treated on Japanese Windows.
>>
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but
>> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with
>> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared
>> in this test and judged to be different characters, and return as failed.
>>
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to
>> give a character such as "?"(0x3042) as the launcher's argument instead of
>> "?"(0x00e9).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>
>   8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

test/jdk/tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java line 55:

> 53:         String encoding = System.getProperty("native.encoding");
> 54:         switch (encoding) {
> 55:         default:

What I meant by the previous comment was to replace this `default` clause to:

    case "Cp1252", "UTF-8" -> testString = new String(Character.toChars(0x00E9));

And for other unknown encodings:

    default -> {
        System.out.println("Test skipped"); // or better message
        return;
    }

And your fix:

    case "MS932", "SJIS" -> testString = new String(Character.toChars(0x3042));

This way only the encodings that are guaranteed to succeed are tested.

-------------

PR: https://git.openjdk.org/jdk/pull/10226
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221003/729d085d/attachment-0001.htm>

From duke at openjdk.org  Mon Oct  3 12:59:21 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 3 Oct 2022 12:59:21 GMT
Subject: Integrated: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
Message-ID: <tJw93XrrJdcdQw5VwhT3myV8s-W64k01NLWUmIHYHfU=.db106823-417a-4de3-aafe-b6adff7c466f@github.com>

On Sun, 2 Oct 2022 20:45:02 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`

This pull request has now been integrated.

Changeset: 46633e64
Author:    stsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46633e644a8ab94ceb75803bd40739214f8a60e8
Stats:     16 lines in 4 files changed: 0 ins; 12 del; 4 mod

8294698: Remove unused 'checkedExceptions' param from MethodAccessorGenerator.generateMethod()

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From jwaters at openjdk.org  Mon Oct  3 13:37:38 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 3 Oct 2022 13:37:38 GMT
Subject: RFR: 8292016: Split Windows API error handling from errors passed
 through the runtime in the JDK [v35]
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>

> WIP

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Naming

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9870/files
  - new: https://git.openjdk.org/jdk/pull/9870/files/b89fb8b8..1be7e721

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=33-34

  Stats: 63 lines in 13 files changed: 5 ins; 0 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/9870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870

PR: https://git.openjdk.org/jdk/pull/9870

From dsamersoff at openjdk.org  Mon Oct  3 15:11:38 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 3 Oct 2022 15:11:38 GMT
Subject: RFR: 8292016: Cleanup legacy error reporting in the JDK outside of
 HotSpot [v35]
In-Reply-To: <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
Message-ID: <_tGORytJS0OmSMKoP6TswalJYnLASUA5F8zEmWmmRvk=.b01c1ac2-3fee-4671-bdb3-649a605faf26@github.com>

On Mon, 3 Oct 2022 13:37:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A large section of error reporting code in the JDK does not properly handle WIN32 API errors and instead mixes them with errors originating from C. Since they can be rather easily replaced and coming up with an elegant solution proved to be too much of a hassle to be worth it, and some of the concerns they address no longer are an issue with current versions of the platforms supported by the JDK, they can be easily removed without much effect. The remaining utilities that are still needed now instead report directly from strerror, with a new subsystem for WIN32 errors put in place wherever required, to minimize confusion when they are used, which was a problem with earlier solutions to this issue.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naming

src/java.base/share/native/libjli/jli_util.h line 93:

> 91: 
> 92: /* Support for using perror with printf arguments */
> 93: #define JLI_Perror(...) \

Is it better to convert this to a function?

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From dsamersoff at openjdk.org  Mon Oct  3 15:17:19 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 3 Oct 2022 15:17:19 GMT
Subject: RFR: 8292016: Cleanup legacy error reporting in the JDK outside of
 HotSpot [v35]
In-Reply-To: <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
Message-ID: <iKi5yut0SfM5yFeMj0kGrud_HnkPzXNMg8P79S6EyHM=.1d7863b3-20c4-43b8-9763-bfb718263d67@github.com>

On Mon, 3 Oct 2022 13:37:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A large section of error reporting code in the JDK does not properly handle WIN32 API errors and instead mixes them with errors originating from C. Since they can be rather easily replaced and coming up with an elegant solution proved to be too much of a hassle to be worth it, and some of the concerns they address no longer are an issue with current versions of the platforms supported by the JDK, they can be easily removed without much effect. The remaining utilities that are still needed now instead report directly from strerror, with a new subsystem for WIN32 errors put in place wherever required, to minimize confusion when they are used, which was a problem with earlier solutions to this issue.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naming

src/java.base/share/native/libzip/zip_util.c line 871:

> 869: 
> 870:     if (zfd == -1) {
> 871: #ifdef _WIN32

1. Could we use strerror_s here?

2. It's better to encapsulate similar code to a separate function or macro, rather than add #ifdef _WIN32 in the middle of the code.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From dsamersoff at openjdk.org  Mon Oct  3 15:39:21 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 3 Oct 2022 15:39:21 GMT
Subject: RFR: 8292016: Cleanup legacy error reporting in the JDK outside of
 HotSpot [v35]
In-Reply-To: <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
Message-ID: <_x-Zql7uyiZQzveqoRLS--fQEJB_Qr5ChyQjUtnmoGY=.28982dc5-4831-439e-bf23-85e14dacf978@github.com>

On Mon, 3 Oct 2022 13:37:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A large section of error reporting code in the JDK does not properly handle WIN32 API errors and instead mixes them with errors originating from C. Since they can be rather easily replaced and coming up with an elegant solution proved to be too much of a hassle to be worth it, and some of the concerns they address no longer are an issue with current versions of the platforms supported by the JDK, they can be easily removed without much effect. The remaining utilities that are still needed now instead report directly from strerror, with a new subsystem for WIN32 errors put in place wherever required, to minimize confusion when they are used, which was a problem with earlier solutions to this issue.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naming

Please, move code like one below to a separate function rather than spreading #ifdef _WIN32 all over the code. 

#ifdef _WIN32
    /* The implementation on Windows uses the Windows API */
    char buf[256];
    size_t n = getLastWinErrorString(buf, sizeof(buf));
    if (n > 0) {
#else
    char* buf = NULL;
    const int error = errno;
    if (error != 0) buf = strerror(error);
    if (buf != NULL) {
#endif

-------------

Changes requested by dsamersoff (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9870

From aturbanov at openjdk.org  Mon Oct  3 16:06:37 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 3 Oct 2022 16:06:37 GMT
Subject: Integrated: 8294695: Remove redundant deprecation suppression in
 ThreadGroup
In-Reply-To: <rXOKKce8LqlA9RUDyGDseVApE8Ey7VTdGbVzOp0TaPE=.c89770fb-1247-4996-865e-ac0c4e925743@github.com>
References: <rXOKKce8LqlA9RUDyGDseVApE8Ey7VTdGbVzOp0TaPE=.c89770fb-1247-4996-865e-ac0c4e925743@github.com>
Message-ID: <hq_KwcDIijeZfScO1GA8MBIE2ThxaNr_LWSxUmpu0as=.fed50fef-c234-49cb-9c25-672d7da3eb2e@github.com>

On Sat, 1 Oct 2022 16:17:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> This suppression were added with Loom integration, but method `Thread.getThreadGroup()` is not deprecated.
> Let's cleanup code a bit.
> https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094907.html

This pull request has now been integrated.

Changeset: edfb18a7
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edfb18a724239ab426ffab038f312a6735625897
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8294695: Remove redundant deprecation suppression in ThreadGroup

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10521

From dnsimon at openjdk.org  Mon Oct  3 16:22:18 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 3 Oct 2022 16:22:18 GMT
Subject: RFR: 8237467: jlink plugin to save the argument files as input to
 jlink in the output image [v3]
In-Reply-To: <j5_mDwRCuf7-hAMY1TKsF7w1vh8D-PSdm-PIP32VRmU=.500c79b8-7b57-47cd-af51-9a75cb83665c@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
 <8jlZM_FhM9w2SdZxVmHgAZkSq3_g6h28yzP81CdOQUA=.9af83d24-3c15-4635-8603-bf6173c13b95@github.com>
 <j5_mDwRCuf7-hAMY1TKsF7w1vh8D-PSdm-PIP32VRmU=.500c79b8-7b57-47cd-af51-9a75cb83665c@github.com>
Message-ID: <V6jdpsS37aSpcQxvVG5gp-ytBMVjoWMbb2VHV_bkOKI=.ceea92d8-0162-421b-90db-da4b7e1b9610@github.com>

On Tue, 27 Sep 2022 22:38:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   SaveJlinkArgfilesPlugin should verify that jdk.jlink is in the output image
>
> Looks good.

Thanks for the reviews @mlchung !

-------------

PR: https://git.openjdk.org/jdk/pull/10445

From dnsimon at openjdk.org  Mon Oct  3 16:29:24 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 3 Oct 2022 16:29:24 GMT
Subject: Integrated: 8237467: jlink plugin to save the argument files as input
 to jlink in the output image
In-Reply-To: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
References: <ol0heS5-LEFjuZkoFjkdraX-9tjEQ371Pii5KkYyO1c=.1cdd4b7d-426d-4075-ac99-9460d0200904@github.com>
Message-ID: <8o5dYUDJxeoEZ9gFJHThZzZGFtXmvOv_SUZWoukrGao=.610e3869-fc73-47b2-8f25-e2419c8ae772@github.com>

On Tue, 27 Sep 2022 11:12:57 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds a new jlink plugin (`--save-jlink-argfiles=<filenames>`) to support persisting jlink options.
> 
> 
>> echo "--add-modules jdk.internal.vm.ci --add-options=-Dfoo=xyzzy --vendor-version="XyzzyVM 3.14.15" --vendor-bug-url=https://bugs.xyzzy.com/" > my_image.argfile
>> export ALL_MODULES=$(java --list-modules | sed 's:@.*::g' | tr '\n' ',')
>> jlink --keep-packaged-modules=my_image/jmods --add-modules $ALL_MODULES --output=my_image --save-jlink-argfiles my_image.argfile
>> my_image/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>> my_image/bin/jlink --add-modules=java.base --output=my_image2
>> my_image2/bin/java -XshowSettings:properties --version 2>&1 | grep yzzy
>     foo = xyzzy
>     java.vendor.url.bug = https://bugs.xyzzy.com/
>     java.vendor.version = XyzzyVM 3.14.15
> OpenJDK Runtime Environment XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon...)
> OpenJDK 64-Bit Server VM XyzzyVM 3.14.15 (build 20-internal-2022-09-22-0951036.dnsimon..., mixed mode)
>> my_image2/bin/java -d jdk.internal.vm.ci | head -1
> jdk.internal.vm.ci at 20-internal

This pull request has now been integrated.

Changeset: 4f44fd63
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f44fd63080d40d53a7751ebae93415aeb9b4a47
Stats:     414 lines in 6 files changed: 413 ins; 0 del; 1 mod

8237467: jlink plugin to save the argument files as input to jlink in the output image

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/10445

From mchung at openjdk.org  Mon Oct  3 16:48:27 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 3 Oct 2022 16:48:27 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <Yc7jhro-T0I7AfbCkfhxOAM5S95WCMQRHrwkKjKoNac=.db8f57af-2add-407d-a430-3a91f166f583@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
 <Yc7jhro-T0I7AfbCkfhxOAM5S95WCMQRHrwkKjKoNac=.db8f57af-2add-407d-a430-3a91f166f583@github.com>
Message-ID: <_3c1eJ5Ppi7rlgeRmLH4y9-q7qEYh-hzyrgpVsYEnBU=.1413f057-50cf-4cc2-9ea4-4dbfb97f9725@github.com>

On Mon, 3 Oct 2022 11:03:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I agree that getting rid of the clone can help -- but since [JEP 416](https://openjdk.org/jeps/416) the generators modified here is mostly a fallback and the bulk of the use will use `MethodHandles` (unless you disable JEP 416 and fall back to the legacy impl). I was mostly curious if you had a startup or other benchmark running on mainline where the change you're doing here could be observed.

@stsypanov like @cl4es said, I expect these dynamically generated methods should only be generated during very early VM startup.  Once the module system is initialized, it will use method handles.   

How do you run the spring-based applications when you observe these methods being called?   While this change is trivial and no harm to include this change, this code is planned to be removed in a future release.

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From asemenyuk at openjdk.org  Mon Oct  3 17:03:23 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Oct 2022 17:03:23 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
Message-ID: <cjcoZs5ZzcwoSHoj-gFxQ26PpdoizwaTgrYToknNO-w=.2b07ff6b-ed39-466b-8c68-b792fb0e0cf4@github.com>

On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Could you please review the JDK-8293579 bug fixes?
>> 
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
>> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
>> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
>> code point "?"(0x00e9) cannot be treated on Japanese Windows.
>> 
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
>> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
>> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
>> in this test and judged to be different characters, and return as failed.
>> 
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
>> give a character such as "?"(0x3042) as the launcher's argument instead of 
>> "?"(0x00e9).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From asemenyuk at openjdk.org  Mon Oct  3 17:03:25 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 3 Oct 2022 17:03:25 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <jc2Z-EFQOuNL7FcE8i1SGkUJ1EIYXi0ciXwh_6PBkGg=.7e98b525-0fb7-424b-9ea3-aab3118c7e19@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
 <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>
 <SEXLY0pFioXy1sOLP8x4qJLARtwQwBJFDso6n7RdZsg=.925b1fd6-6a1b-4371-b14a-006618f62040@github.com>
 <4ARgpqckW-WNkVGHuxIznh32zqRF75NlpGEDTQ7Nvlk=.ddcc063a-a821-49f6-b0fe-aaed1de2e3c6@github.com>
 <nry-aKoKUn-GECMSY3WNHJkn1MRQ8cgHZhtvw7L-tOs=.f6e5d4b6-c4ed-484a-8365-e475353fa148@github.com>
 <jc2Z-EFQOuNL7FcE8i1SGkUJ1EIYXi0ciXwh_6PBkGg=.7e98b525-0fb7-424b-9ea3-aab3118c7e19@github.com>
Message-ID: <lkZo0j276w4GSL0Q9iy0-Bycaxr_m8xCa6wd-CGf40s=.2718266a-e9eb-42ea-adde-ce693635b7f6@github.com>

On Mon, 3 Oct 2022 09:39:08 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I don't think it will be many practical setups where this test fails. This test has been around for more than 2 years and this is the first accident.
>
> At least, the results in different encodings are the same as before the fix.
> How about not fixing the pattern for other encordings to avoid false negative?

This looks good to me. The only requirement to the value of `testString` is that it is a letter outside of the Basic Latin character set.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From rgiulietti at openjdk.org  Mon Oct  3 17:14:17 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Oct 2022 17:14:17 GMT
Subject: RFR: 8294593: Check the size of the target on invocations of
 BigInteger::isProbablePrime
Message-ID: <HldMAGnhBPmqMuyhZ53KV45_eJftMqTPyi1s6sW9JQw=.92a13a34-f7db-4385-a21d-498fe57a4a24@github.com>

Throws an `ArithemticException` when the target is huge.

-------------

Commit messages:
 - 8294593: Check the size of the target on invocations of BigInteger::isProbablePrime

Changes: https://git.openjdk.org/jdk/pull/10541/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294593
  Stats: 24 lines in 2 files changed: 21 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10541.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10541/head:pull/10541

PR: https://git.openjdk.org/jdk/pull/10541

From rgiulietti at openjdk.org  Mon Oct  3 17:14:17 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Oct 2022 17:14:17 GMT
Subject: RFR: 8294593: Check the size of the target on invocations of
 BigInteger::isProbablePrime
In-Reply-To: <HldMAGnhBPmqMuyhZ53KV45_eJftMqTPyi1s6sW9JQw=.92a13a34-f7db-4385-a21d-498fe57a4a24@github.com>
References: <HldMAGnhBPmqMuyhZ53KV45_eJftMqTPyi1s6sW9JQw=.92a13a34-f7db-4385-a21d-498fe57a4a24@github.com>
Message-ID: <nOGhjy20Uv61nUUU7uF_lmx8LITKYSmUI1RRfVX-jwE=.d2673bed-7c5b-412e-afa9-3db29aaa900b@github.com>

On Mon, 3 Oct 2022 17:02:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Throws an `ArithemticException` when the target is huge.

This parallels the existing behavior in `BigInteger::nextProbablePrime`.

A separate CSR + PR will follow.

-------------

PR: https://git.openjdk.org/jdk/pull/10541

From darcy at openjdk.org  Mon Oct  3 17:19:20 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:19:20 GMT
Subject: RFR: 8294593: Check the size of the target on invocations of
 BigInteger::isProbablePrime
In-Reply-To: <HldMAGnhBPmqMuyhZ53KV45_eJftMqTPyi1s6sW9JQw=.92a13a34-f7db-4385-a21d-498fe57a4a24@github.com>
References: <HldMAGnhBPmqMuyhZ53KV45_eJftMqTPyi1s6sW9JQw=.92a13a34-f7db-4385-a21d-498fe57a4a24@github.com>
Message-ID: <rQiDZelCfWPMHz2fWrCFeETgUf-36P_vVO_WMR9yZU0=.cb31a6cc-3012-4d6e-87d1-bd5f1fbfa1c0@github.com>

On Mon, 3 Oct 2022 17:02:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Throws an `ArithemticException` when the target is huge.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10541

From darcy at openjdk.org  Mon Oct  3 17:20:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:20:53 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
Message-ID: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>

On Fri, 30 Sep 2022 20:25:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?

Filed a few follow-up bugs:

JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella)
JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 17:25:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:25:30 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v6]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <_UYUckHSBcJizYd7JBVbr6evdOrHu9h2MopGUlzrLR8=.b5c6d747-800b-462b-a19a-73a0f5096e3e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update doc directory files.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/fbaf3d4c..6bf7bf61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04-05

  Stats: 38 lines in 4 files changed: 0 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 17:29:45 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:29:45 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update make directory.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/6bf7bf61..224ed7a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=05-06

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From naoto at openjdk.org  Mon Oct  3 17:36:29 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Oct 2022 17:36:29 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
Message-ID: <ydQX6xjSt85Vre5_FwT6idC_yx_trB8uWXO-I9HYAKg=.11458e6a-3d6c-4f0d-b7af-16b81c051254@github.com>

On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Could you please review the JDK-8293579 bug fixes?
>> 
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
>> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
>> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
>> code point "?"(0x00e9) cannot be treated on Japanese Windows.
>> 
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
>> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
>> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
>> in this test and judged to be different characters, and return as failed.
>> 
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
>> give a character such as "?"(0x3042) as the launcher's argument instead of 
>> "?"(0x00e9).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

Marked as reviewed by naoto (Reviewer).

> The issue can be worked around on Windows 10 Version 1903 or later (including Windows 11) by modifying the src/java.base/windows/native/launcher/java.manifest file as follows: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"

This would be a good enhancement for the jpackage.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From naoto at openjdk.org  Mon Oct  3 17:36:30 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Oct 2022 17:36:30 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <lkZo0j276w4GSL0Q9iy0-Bycaxr_m8xCa6wd-CGf40s=.2718266a-e9eb-42ea-adde-ce693635b7f6@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
 <3ikhT4YbokA53IEoN9HdDhONo6d3WvhcRVk0-oFHE8I=.edec73e0-acdd-4075-88da-56dd095c82a3@github.com>
 <BJJGTJOIVveQI5SYr7kWG01xg9AGq1LhyCtaHM5zW4g=.a8cfd59a-778f-410b-a2c4-034229aba08f@github.com>
 <SEXLY0pFioXy1sOLP8x4qJLARtwQwBJFDso6n7RdZsg=.925b1fd6-6a1b-4371-b14a-006618f62040@github.com>
 <4ARgpqckW-WNkVGHuxIznh32zqRF75NlpGEDTQ7Nvlk=.ddcc063a-a821-49f6-b0fe-aaed1de2e3c6@github.com>
 <nry-aKoKUn-GECMSY3WNHJkn1MRQ8cgHZhtvw7L-tOs=.f6e5d4b6-c4ed-484a-8365-e475353fa148@github.com>
 <jc2Z-EFQOuNL7FcE8i1SGkUJ1EIYXi0ciXwh_6PBkGg=.7e98b525-0fb7-424b-9ea3-aab3118c7e19@github.com>
 <lkZo0j276w4GSL0Q9iy0-Bycaxr_m8xCa6wd-CGf40s=.2718266a-e9eb-42ea-adde-ce693635b7f6@github.com>
Message-ID: <YPXb22vjT_P5UaawhCNMepuV7BQ_ZOOc-vfSTdns7-Q=.5a3a3e99-2c8d-44d3-8f77-95385b2736bf@github.com>

On Mon, 3 Oct 2022 16:59:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> At least, the results in different encodings are the same as before the fix.
>> How about not fixing the pattern for other encordings to avoid false negative?
>
> This looks good to me. The only requirement to the value of `testString` is that it is a letter outside of the Basic Latin character set. So picking a letter that can be encoded in the active encoding works.

Although I still prefer preventing possible errors in the test, the change does not make it worse than before.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From darcy at openjdk.org  Mon Oct  3 17:38:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 17:38:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4]
In-Reply-To: <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <Sn1Gew6Bk0ucvOpjBNf4mBB5li1rhPh-eh1H-BzqZco=.eb3767db-d41b-4f9d-a95e-25523effaa19@github.com>
 <eCjWYSRQB0sC2mcoavSzqTGOt7Tw5GdAKAqnDRmq07A=.f8403857-eb3a-4069-940a-a4414a8b83e8@github.com>
 <xtCGcSpiMRaJNEOP0fgvF56wVK2gaB_x8Qym-i_lnZU=.33efcb67-350a-4b6d-8a0d-ffb13d5a6a4e@github.com>
 <H7mN4EfTvxE72FBcCrQ3MDstHI5Sm0u0fhH6o8YJRfU=.e61230a2-0413-4262-9142-76126c181725@github.com>
Message-ID: <w8oqOHIlJyGizESmriPdGYTsVqpLZya2cPRL-2FjHWE=.8730e026-5e1c-4b3f-9543-a8f3eb4a8c3c@github.com>

On Mon, 3 Oct 2022 17:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..?
> 
> Filed a few follow-up bugs:
> 
> JDK-8294724: Update openjdk.java.net => openjdk.org in tests (umbrella) JDK-8294725: Update openjdk.java.net => openjdk.org in java command man page

And also filed

JDK-8294728: Update openjdk.java.net => openjdk.org in hotspot unit test docs

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From svkamath at openjdk.org  Mon Oct  3 17:49:14 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 3 Oct 2022 17:49:14 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <5pqC4k2fyhaYIa9d6D3Dciv2ohYR-JCPvYW7lZsbXhw=.4a3071d6-39b8-4828-86a4-9c3871401844@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
 <5pqC4k2fyhaYIa9d6D3Dciv2ohYR-JCPvYW7lZsbXhw=.4a3071d6-39b8-4828-86a4-9c3871401844@github.com>
Message-ID: <V-xsTwphhiZDo7eRWz2riaA2p7JXNVeC3pYck1ljh2I=.c6da1721-a026-4911-82e4-6ea021f1b2c1@github.com>

On Fri, 30 Sep 2022 09:59:02 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comment to update test case
>
> Hi, would you be adding IR tests to verify the generation of the the newly introduced IR nodes?

@Bhavana-Kilambi, I plan to do this in a separate PR along with the gtest. Here's the bug https://bugs.openjdk.org/browse/JDK-8293323.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Mon Oct  3 17:49:17 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 3 Oct 2022 17:49:17 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <ix-SKa4ZivpVntpiwiIhQfRExnjCTZO2MbJkrw-je80=.294816e5-2607-4580-a108-bb90abd2701b@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
 <P3WD1fmVLCwmvGi1rEyYNJg9vRN0J8JgV8bn4eIHsc4=.186a8e48-1cb9-4e88-b2e2-7ca142fb9163@github.com>
 <ix-SKa4ZivpVntpiwiIhQfRExnjCTZO2MbJkrw-je80=.294816e5-2607-4580-a108-bb90abd2701b@github.com>
Message-ID: <Ji9rHFKZ1Fm-rhQ36_laIoSnK8_3RdRgcIJaevKQKf8=.a5b6c008-6f57-460d-88dd-6c00f32024ec@github.com>

On Mon, 3 Oct 2022 08:34:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 3674:
>> 
>>> 3672: %}
>>> 3673: 
>>> 3674: instruct convF2HF_mem_reg(memory mem, regF src, kReg ktmp, rRegI rtmp) %{
>> 
>> You can use `kmovwl` instead which will relax the avx512bw constraint, however, you will need avx512vl for `evcvtps2ph`. Thanks.
>
> Rethink about it, you can get 0x01 by right shifting k0 to the right - `kshiftrw(ktmp, k0, 15)`

@merykitty Thanks for the suggestion. I will update the instruct to use kmovwl. I will also experiment with kshiftrw and let you know.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From rgiulietti at openjdk.org  Mon Oct  3 18:05:34 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Oct 2022 18:05:34 GMT
Subject: Integrated: 8294593: Check the size of the target on invocations of
 BigInteger::isProbablePrime
In-Reply-To: <HldMAGnhBPmqMuyhZ53KV45_eJftMqTPyi1s6sW9JQw=.92a13a34-f7db-4385-a21d-498fe57a4a24@github.com>
References: <HldMAGnhBPmqMuyhZ53KV45_eJftMqTPyi1s6sW9JQw=.92a13a34-f7db-4385-a21d-498fe57a4a24@github.com>
Message-ID: <_luql0SO7u_5baSevbTRZ81i-EJ6gzb-oY7aXrcBUko=.3e0169aa-48b5-4cd8-b374-2496ad270421@github.com>

On Mon, 3 Oct 2022 17:02:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Throws an `ArithemticException` when the target is huge.

This pull request has now been integrated.

Changeset: 081691ad
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/081691adf42919237b2a5b71a4b1064c7112a79c
Stats:     24 lines in 2 files changed: 21 ins; 0 del; 3 mod

8294593: Check the size of the target on invocations of BigInteger::isProbablePrime

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/10541

From rgiulietti at openjdk.org  Mon Oct  3 18:45:24 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 3 Oct 2022 18:45:24 GMT
Subject: RFR: 8294730: Add @throws and @implNote clauses to
 BigInteger::isProblablePrime and BigInteger::nextProblablePrime
Message-ID: <eAoP-aMiw7G89Wx41vKW2Kojilr7P1jZjYVnGym61Wc=.e2e2cc0a-58b3-4112-979f-9be473d02317@github.com>

Completes the spec of [PR 10541](https://github.com/openjdk/jdk/pull/10541)

-------------

Commit messages:
 - 8294730: Add @throws and @implNote clauses to BigInteger::isProblablePrime and BigInteger::nextProblablePrime

Changes: https://git.openjdk.org/jdk/pull/10543/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294730
  Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10543.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10543/head:pull/10543

PR: https://git.openjdk.org/jdk/pull/10543

From bpb at openjdk.org  Mon Oct  3 19:06:27 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Oct 2022 19:06:27 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME
In-Reply-To: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
Message-ID: <RZCarHzA19DSdB8uNFlYOJGHhyhe0MNjvoXGCw4Eq28=.96ed5f70-2cd2-461d-9d59-d01eaa7c2c5d@github.com>

On Sat, 1 Oct 2022 17:54:37 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes 8294541

This patch still failed on macOS:

Seed from RandomFactory = 9174133304664648308L
test TransferTo.testNullPointerException(): success
test TransferTo.testStreamContents(): failure
java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.Arrays.copyOf(Arrays.java:3537)
	at java.base/java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
	at java.base/java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:132)
	at java.base/java.io.InputStream.transferTo(InputStream.java:791)
	at java.base/java.io.BufferedInputStream.implTransferTo(BufferedInputStream.java:611)
	at java.base/java.io.BufferedInputStream.transferTo(BufferedInputStream.java:595)
	at TransferTo.checkTransferredContents(TransferTo.java:198)
	at TransferTo.testStreamContents(TransferTo.java:133)

I wonder whether a `FileOutputStream` (open on a sparse file?) should be used instead of a `ByteArrayOutputStream` with heap memory cranked up?

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From almatvee at openjdk.org  Mon Oct  3 19:59:26 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 3 Oct 2022 19:59:26 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
Message-ID: <DrCrUHKs9NAxx62sI0rVdzXEEQuUtJYuo5G0CagFFRk=.4224d4fa-133e-4121-9f4b-cb94b94cb75b@github.com>

On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Could you please review the JDK-8293579 bug fixes?
>> 
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
>> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
>> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
>> code point "?"(0x00e9) cannot be treated on Japanese Windows.
>> 
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
>> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
>> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
>> in this test and judged to be different characters, and return as failed.
>> 
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
>> give a character such as "?"(0x3042) as the launcher's argument instead of 
>> "?"(0x00e9).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From smarks at openjdk.org  Mon Oct  3 20:01:28 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 3 Oct 2022 20:01:28 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
Message-ID: <bQEBDcHAxF3bl8n6ZNO_0JftP03AzoG7UFtb5LOSp5Y=.c5933a51-3a49-4aaf-8a19-9c0eb4be239d@github.com>

On Fri, 30 Sep 2022 17:24:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add discussion of numerical equality.
>  - Fix typo.

src/java.base/share/classes/java/lang/Double.java line 149:

> 147:  * equivalence relations can be defined over floating-point
> 148:  * values. Comparing numerical equality to various kinds of
> 149:  * equivalence:

The overall discussion is good, and the inclusion of numerical equality is good, but now this introductory paragraph is invalid. It starts off:

> While `==` is not an equivalence relation,

OK, this continues the discussion, picking up from the assertion several paragraphs above that `==` is not an equivalence relation. Then,

> several useful equivalence relations can be defined over floating-point values. Comparing numerical equality to various kinds of equivalence:

It sounds like what follows will be a list of equivalence relations that will be contrasted with numerical equality, yet the very first example is numerical equality and is _not_ an equivalence relation.

I think this just needs to be reworded to be more inclusive. Maybe something like, "the following is a comparison of various relations among floating-point values."

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From smarks at openjdk.org  Mon Oct  3 20:06:26 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 3 Oct 2022 20:06:26 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
Message-ID: <tBnueB_k8ZVSzE5KrYPy7iDiGKWcaTaGl_Dk8o5Xn7k=.22f8e2de-2832-475b-9bb7-29d61b7e8f2c@github.com>

On Fri, 30 Sep 2022 17:24:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add discussion of numerical equality.
>  - Fix typo.

src/java.base/share/classes/java/lang/Double.java line 181:

> 179:  * <li> {@code +0.0} and {@code -0.0} are distinguished from each other.
> 180:  * <li> every bit pattern encoding a NaN is considered equivalent to each other
> 181:  * <li> an infinite value is equivalent to an infinite value of the same sign

Seems like this line on infinities could be reworded. I wouldn't quibble over this except that I had to read it several times to figure out what it meant. The statement on NaN is universally quantified, whereas the statement on infinite values starts off sounding like an existential quantifier. Possibly: "all infinite values of the same sign are considered equivalent to each other."

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From prr at openjdk.org  Mon Oct  3 20:08:19 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 3 Oct 2022 20:08:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
Message-ID: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>

On Mon, 3 Oct 2022 17:29:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make directory.

src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:

> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
> 35:  *
> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.

The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
At this point I'd prefer that this be updated to point to JDK 17, as in
https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
So it is a defined, known, compatible version.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 20:37:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:11 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - Revert unintended update to binary file.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7a8d31f3...4055f1a6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/224ed7a0..4055f1a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=06-07

  Stats: 5510 lines in 75 files changed: 3554 ins; 1669 del; 287 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From darcy at openjdk.org  Mon Oct  3 20:37:14 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 3 Oct 2022 20:37:14 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v7]
In-Reply-To: <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <-_gZsyDFTlHjj-7UiLaIjMBikGCJU8M2Kz9D7dm-20I=.7eacd8cd-6f3c-4a9d-9bbb-18291146b58e@github.com>
 <RJ23ZyPLKtf2O6dWE_xNJZ8m11z66OmIB24BuZ3lAXA=.39b0cdf3-bb6e-4d9a-a6ec-6efb20f1ebee@github.com>
Message-ID: <hGRiPhKIV8XCNGN7oJ010i5zPMJJlaYU7XzaP-c0vjM=.dee8d1ca-3312-4540-9f43-879aeffe7431@github.com>

On Mon, 3 Oct 2022 20:04:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make directory.
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 36:
> 
>> 34:  * https://git.openjdk.org/jdk/blob/master/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c
>> 35:  *
>> 36:  * Also note that the API is used in the jaccessinspector and jaccesswalker tools.
> 
> The problem with this is, is that anyone who gets JDK 20 (or 21 the LTS) will be forever more then pointed at the OpenJDK "tip" and if we made an incompatible ABI change, that would be a problem.
> At this point I'd prefer that this be updated to point to JDK 17, as in
> https://github.com/openjdk/jdk17/blob/master/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp
> So it is a defined, known, compatible version.

Updated to refer to JDK 17 specifically.

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From bchristi at openjdk.org  Mon Oct  3 20:38:34 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 3 Oct 2022 20:38:34 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <c0yL64t_RWZ7ujH3QlOgoH-s2IqtiDHOy3v_DPxQTuc=.53dc7c6e-01f9-40c7-b9c8-7812fba79640@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

Looks good.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10475

From jjg at openjdk.org  Mon Oct  3 20:46:17 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 3 Oct 2022 20:46:17 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v4]
In-Reply-To: <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
Message-ID: <M9tTeYjizIr5wugG1Pe3S6lbkQ3YNkYDLU5rrQd_J5w=.87ef3853-3cfd-493a-bec9-2f9abd75ae4d@github.com>

On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove comment typo
>  - Remove test wrapper

src/java.base/share/classes/java/text/DigitList.java line 796:

> 794:         temp.append("x10^");
> 795:         temp.append(decimalAt);
> 796:         return temp.toString();

This could use chained method calls and avoid the local variable completely.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Mon Oct  3 21:22:03 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 3 Oct 2022 21:22:03 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v5]
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove temp var
  
  Remove temp variables and replace with method chaining when possible

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10475/files
  - new: https://git.openjdk.org/jdk/pull/10475/files/442c2a4e..cf564a8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10475&range=03-04

  Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10475.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10475/head:pull/10475

PR: https://git.openjdk.org/jdk/pull/10475

From stuart.marks at oracle.com  Mon Oct  3 21:32:34 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 3 Oct 2022 14:32:34 -0700
Subject: Collections.shuffle to accept RandomGenerator
In-Reply-To: <SJ0PR18MB48812F9068DA932E9F26044283589@SJ0PR18MB4881.namprd18.prod.outlook.com>
References: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>
 <0AE34224-3FED-4A34-B8F0-E2E916959600@oracle.com>
 <SJ0PR18MB4881EA7396DE6199472979CB83579@SJ0PR18MB4881.namprd18.prod.outlook.com>
 <CAE+3fjYg1PdD9P=GrcxUYpUhKqkobBbYD0Law61KLWRSQ6WwdQ@mail.gmail.com>
 <SJ0PR18MB48812F9068DA932E9F26044283589@SJ0PR18MB4881.namprd18.prod.outlook.com>
Message-ID: <501a7a87-950b-ee32-f9da-d77e7ad5fdd1@oracle.com>

I'm ok with not adding a default shuffle() method to List. Shuffling does seem 
fairly rare, and it potentially has a some semantic issues regarding updates to the 
RNG state. Those would make it difficult to specify or to override without possibly 
breaking the contract.

Having a List::shuffle default method might provide a path toward solving the issues 
with shuffing a CopyOnWriteArrayList, as described recently [1]. However, that seems 
like an extremely rare case, and there's a workaround (albeit fairly painful). And 
there are some things that COWAL simply doesn't support (like modifications from a 
ListIterator) or are unspecified (modifications to a subList).

The Arrays class does need some attention and probably should be considered 
separately. It's lacking some other things too, like reverse(). One issue with 
modifying the Arrays class is providing overloads for some or all of the primitives. 
We've kind of held off because adding primitive overloads adds to the clutter of an 
already-cluttered class. There are some functions that support only "common" 
primitives int/long/double (see Arrays::setAll) which reduces the clutter; but I've 
missed overloads for certain arrays like byte[].

(I'm not saying not to do this; I'm saying this is more than dropping in a single 
Arrays::shuffle method.)

I'm not sure we want to change the behavior of the existing Collections::shuffle 
with respect to ThreadLocalRandom. It seems like there are some weird tradeoffs 
here; see JDK-8218282 [2].

s'marks


[1]: https://mail.openjdk.org/pipermail/core-libs-dev/2022-August/093777.html

[2]: https://bugs.openjdk.org/browse/JDK-8218282


On 10/1/22 6:48 PM, Jason Mehrens wrote:
> Tagir,
> 
> Yes I have mixed feeling about promoting shuffle to List.  I did notice that java.util.Arrays doesn't have a shuffle method.  Perhaps adding RandomGenerator shuffle and slice variant of shuffle to that class would be something to consider.  Array backed lists could then use that method to perform a shuffle without having to use asList.
> 
> Jason
> 
> ________________________________________
> From: Tagir Valeev <amaembo at gmail.com>
> Sent: Saturday, October 1, 2022 2:24 AM
> To: Jason Mehrens
> Cc: Paul Sandoz; core-libs-dev at openjdk.org
> Subject: Re: Collections.shuffle to accept RandomGenerator
> 
> Thanks, Paul, Jason. I've filed an issue:
> https://bugs.openjdk.org/browse/JDK-8294693
> 
> I'm not sure about the lifting shuffle() and making it an instance
> method of List interface. The shuffle() is used much less often,
> compared to sort(). Also, it produces an unspecified side-effect.
> Namely, it updates the state of the supplied RandomGenerator.
> Currently, it does this in a very stable way, calling nextInt() size-1
> times for any list implementation. So if I initialize a RNG with a
> specific seed, then shuffle several lists, they will be shuffled in
> predictable manner, regardless of a particular list implementation.
> This might be desired, e.g., to write tests or reproduce problems. If
> we move it to an instance method, implementations might vary, and
> passing identical RNG may produce different shuffle order for lists
> with identical content but having different implementations. Moreover,
> it may even leave RNG in a different state afterwards which may affect
> subsequent operations performed with the same RNG. With sorting, any
> implementation must produce the same result, so such questions don't
> rise.
> 
> With best regards,
> Tagir Valeev
> 
> On Thu, Sep 29, 2022 at 4:27 AM Jason Mehrens <jason_mehrens at hotmail.com> wrote:
>>
>> JDK20 has Random.from(RandomGenerator) which could be used to do something like Collections.shuffle(List, Random.from(rg)).
>>
>> List.shuffle(RandomGenerator ) would allow for more efficient CopyOnWriteArrayList shuffle.
>>
>> Jason
>>
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
>> Sent: Wednesday, September 28, 2022 10:36 AM
>> To: Tagir Valeev
>> Cc: core-libs-dev at openjdk.org
>> Subject: Re: Collections.shuffle to accept RandomGenerator
>>
>> That looks reasonable.
>>
>> Thinking a little more broadly.
>>
>> We could also change Collections.shuffle(List) to use ThreadLocalRandom so it does not have to cache the Random instance, plus it has better concurrent and PRNG properties. The spec does not describe the precise details of randomness.
>>
>> It?s tempting to lift Collections.shuffle(List, RandomGenerator) to List.shuffle(RandomGenerator ), similar to what we did for Collections.sort, to align with that pattern and which also aligns with reverse of sequenced collections. There is likely not much performance advantage to do doing so as there was with sort, but that location is much easier to find and use IMHO. Since the method accepts RandomGenerator the compatibility risk would likely be low.
>>
>> Paul.
>>
>>> On Sep 27, 2022, at 3:11 AM, Tagir Valeev <amaembo at gmail.com> wrote:
>>>
>>> Hello!
>>>
>>> Currently, Collections.shuffle(List, Random) accepts an outdated
>>> Random class instead of RandomGenerator interface. It looks like,
>>> RandomGenerator would suffice. The code change looks trivial (aside
>>> from documentation and testing), as shuffle() implementation does not
>>> need anything except nextInt:
>>>
>>> diff --git a/src/java.base/share/classes/java/util/Collections.java
>>> b/src/java.base/share/classes/java/util/Collections.java
>>> --- a/src/java.base/share/classes/java/util/Collections.java (revision
>>> cab590517bf705418c7376edd5d7066b13b6dde8)
>>> +++ b/src/java.base/share/classes/java/util/Collections.java (date
>>> 1664273240190)
>>> @@ -37,6 +37,7 @@
>>> import java.util.function.IntFunction;
>>> import java.util.function.Predicate;
>>> import java.util.function.UnaryOperator;
>>> +import java.util.random.RandomGenerator;
>>> import java.util.stream.IntStream;
>>> import java.util.stream.Stream;
>>> import java.util.stream.StreamSupport;
>>> @@ -454,8 +455,12 @@
>>>       * @throws UnsupportedOperationException if the specified list or its
>>>       *         list-iterator does not support the {@code set} operation.
>>>       */
>>> -    @SuppressWarnings({"rawtypes", "unchecked"})
>>>      public static void shuffle(List<?> list, Random rnd) {
>>> +        shuffle(list, (RandomGenerator) rnd);
>>> +    }
>>> +
>>> +    @SuppressWarnings({"rawtypes", "unchecked"})
>>> +    public static void shuffle(List<?> list, RandomGenerator rnd) {
>>>          int size = list.size();
>>>          if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
>>>              for (int i=size; i>1; i--)
>>>
>>> What do you think? Should we implement this improvement? I think I can
>>> contribute if there's a general agreement that such an enhancement
>>> would be useful.
>>>
>>> With best regards,
>>> Tagir Valeev
>>

From duke at openjdk.org  Mon Oct  3 21:37:08 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 3 Oct 2022 21:37:08 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v4]
In-Reply-To: <M9tTeYjizIr5wugG1Pe3S6lbkQ3YNkYDLU5rrQd_J5w=.87ef3853-3cfd-493a-bec9-2f9abd75ae4d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <CDP31ApvZYF4Tg2urnsB2ZHolOhvzj6CLGVQ5CrsGW8=.e4191df2-af79-49a3-9230-3e601192e5d6@github.com>
 <M9tTeYjizIr5wugG1Pe3S6lbkQ3YNkYDLU5rrQd_J5w=.87ef3853-3cfd-493a-bec9-2f9abd75ae4d@github.com>
Message-ID: <vLxHg_gfX5k05jakI8asWsOWefvgBSFB322-G7XuUh0=.390df7e4-ac0e-42aa-99ba-b2d29a8ef216@github.com>

On Mon, 3 Oct 2022 20:42:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove comment typo
>>  - Remove test wrapper
>
> src/java.base/share/classes/java/text/DigitList.java line 796:
> 
>> 794:         temp.append("x10^");
>> 795:         temp.append(decimalAt);
>> 796:         return temp.toString();
> 
> This could use chained method calls and avoid the local variable completely.

Thanks for pointing that out, made the switch there and in the getDouble() method as well.

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From smarks at openjdk.org  Mon Oct  3 21:49:48 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 3 Oct 2022 21:49:48 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface
In-Reply-To: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
Message-ID: <V9yXPiTULzDOnfUvs_8TsdhODsZnePVpIWnai0lmW1E=.ea069d1b-a8b3-4640-b0fb-5ae7612ea293@github.com>

On Sat, 1 Oct 2022 08:06:44 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
> 
> As we are here, it would also be nice to get rid of Collections.r static random generator which is used by default, and use ThreadLocalRandom instead. This will reduce the contention if shuffle() without explicit random generator is called from different threads concurrently.

See my comments in [JDK-8218282](https://bugs.openjdk.org/browse/JDK-8218282). While updating the one-arg Collections::shuffle to use ThreadLocalRandom seems obvious, it's not clear to me that we actually want to do that.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From duke at openjdk.org  Mon Oct  3 22:48:55 2022
From: duke at openjdk.org (Chris Hennick)
Date: Mon, 3 Oct 2022 22:48:55 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v14]
In-Reply-To: <bLPYyKu-bV3Blq9kH9-YW_uc6ltGFiogng4u-_Qeq68=.8d90a88e-0b6c-434a-b290-bc6441887781@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <bLPYyKu-bV3Blq9kH9-YW_uc6ltGFiogng4u-_Qeq68=.8d90a88e-0b6c-434a-b290-bc6441887781@github.com>
Message-ID: <-GZpkEHj3c5bmu_eEuXkyQD2ETvfaecmOxt1vwGSRXc=.ddfc7cd7-c1ae-4a5f-b137-3ab9a5cde24c@github.com>

On Sun, 19 Jun 2022 23:38:36 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewrite Javadoc

Update: just waiting for approval from work to obtain c6a.metal, c6i.metal and c6g.metal instances for long enough to run the benchmarks before and after.

-------------

PR: https://git.openjdk.org/jdk/pull/8131

From iklam at openjdk.org  Tue Oct  4 01:16:22 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Oct 2022 01:16:22 GMT
Subject: RFR: 8294740: Add cgroups keyword to TestDockerBasic.java
Message-ID: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>

Please review this trivial fix.  TestDockerBasic.java uses cgroups features so it should be tagged with `@key cgroups`.

-------------

Commit messages:
 - 8294740: Add cgroups keyword to TestDockerBasic.java

Changes: https://git.openjdk.org/jdk/pull/10547/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10547&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294740
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10547.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10547/head:pull/10547

PR: https://git.openjdk.org/jdk/pull/10547

From mseledtsov at openjdk.org  Tue Oct  4 01:16:22 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Tue, 4 Oct 2022 01:16:22 GMT
Subject: RFR: 8294740: Add cgroups keyword to TestDockerBasic.java
In-Reply-To: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>
References: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>
Message-ID: <fjKlfLDOjoLvRwP_pD0SsLtLx80031QCh5EFYbDpRNg=.707af155-709a-402b-b3d7-15209f4c0466@github.com>

On Tue, 4 Oct 2022 01:03:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial fix.  TestDockerBasic.java uses cgroups features so it should be tagged with `@key cgroups`.

Marked as reviewed by mseledtsov (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/10547

From dholmes at openjdk.org  Tue Oct  4 01:16:23 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Oct 2022 01:16:23 GMT
Subject: RFR: 8294740: Add cgroups keyword to TestDockerBasic.java
In-Reply-To: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>
References: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>
Message-ID: <JDrxM2O6iPMtpwngreyITb4m5xdQf_AvjSQj0EfrbF4=.f9b46891-4f48-4aab-ac78-4ddda7a110f0@github.com>

On Tue, 4 Oct 2022 01:03:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial fix.  TestDockerBasic.java uses cgroups features so it should be tagged with `@key cgroups`.

Looks good and trivial. Thanks for the quick fix.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10547

From iklam at openjdk.org  Tue Oct  4 03:17:55 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Oct 2022 03:17:55 GMT
Subject: RFR: 8294740: Add cgroups keyword to TestDockerBasic.java
In-Reply-To: <JDrxM2O6iPMtpwngreyITb4m5xdQf_AvjSQj0EfrbF4=.f9b46891-4f48-4aab-ac78-4ddda7a110f0@github.com>
References: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>
 <JDrxM2O6iPMtpwngreyITb4m5xdQf_AvjSQj0EfrbF4=.f9b46891-4f48-4aab-ac78-4ddda7a110f0@github.com>
Message-ID: <w6e-tDuv73P3SAhhxJpLzGtlBzchjnY0CMIV7rHuncA=.951e67e9-b7e8-470c-901f-8dd7199493ab@github.com>

On Tue, 4 Oct 2022 01:10:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this trivial fix.  TestDockerBasic.java uses cgroups features so it should be tagged with `@key cgroups`.
>
> Looks good and trivial. Thanks for the quick fix.

Thanks @dholmes-ora and @mseledts for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/10547

From iklam at openjdk.org  Tue Oct  4 03:24:57 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Oct 2022 03:24:57 GMT
Subject: Integrated: 8294740: Add cgroups keyword to TestDockerBasic.java
In-Reply-To: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>
References: <MMlrt2FwYjjLpnnpRoGLx3FNv-qDXgkyumK0DuNFfhA=.d9f5d4a9-a444-4eb4-9c9a-2b5989458ff4@github.com>
Message-ID: <UgSaocYcn-4EicZ057Wevi_DjR9YJIy3KlCDlljMdsI=.891f0ebd-590c-47d5-a82e-96a3f65ba09c@github.com>

On Tue, 4 Oct 2022 01:03:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial fix.  TestDockerBasic.java uses cgroups features so it should be tagged with `@key cgroups`.

This pull request has now been integrated.

Changeset: ae79af2a
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae79af2ad67b51a7608f4c9060421dd175cabf3f
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8294740: Add cgroups keyword to TestDockerBasic.java

Reviewed-by: mseledtsov, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/10547

From dholmes at openjdk.org  Tue Oct  4 04:42:11 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Oct 2022 04:42:11 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v9]
In-Reply-To: <gQMPe5GcAQCW66RZv7cvXbgrXtQDDyWlGzz1ejeo3L0=.afbaa62f-a307-4d4c-8715-7a2c39eb63e0@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <gQMPe5GcAQCW66RZv7cvXbgrXtQDDyWlGzz1ejeo3L0=.afbaa62f-a307-4d4c-8715-7a2c39eb63e0@github.com>
Message-ID: <Q7tTqg2L2-Kh4rjLM5J66BO1iyMzCvYipMgmlPrhGkM=.d9f1582a-ef2a-49f2-8a12-78ddc5b09081@github.com>

On Fri, 30 Sep 2022 21:46:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional edits to Runtime and Thread specs.

Looks good! Noting further from me. Thanks @stuart-marks !

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9437

From darcy at openjdk.org  Tue Oct  4 05:30:04 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Oct 2022 05:30:04 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <DsT0dICpGdqWlhkY6E6I50NmTQ7Y8mVJ29fchW8xPbk=.ed23a8f0-6982-4af2-874a-4c28e2e247ef@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
 <DsT0dICpGdqWlhkY6E6I50NmTQ7Y8mVJ29fchW8xPbk=.ed23a8f0-6982-4af2-874a-4c28e2e247ef@github.com>
Message-ID: <z3zSNaGzj7y4dh2vEmFPYzk1Y_s2ASMTxE6pL8SjYU4=.b5eeb80e-88aa-4542-9157-da66b75fe154@github.com>

On Fri, 30 Sep 2022 20:08:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add discussion of numerical equality.
>>  - Fix typo.
>
> src/java.base/share/classes/java/lang/Double.java line 166:
> 
>> 164:  * equivalence relation for {@code double} values {@code a} and {@code b} is
>> 165:  * implemented by the expression
>> 166:  * <br>{@code Double.doubleTo}<code><b>Raw</b></code>{@code LongBits(a) == Double.doubleTo}<code><b>Raw</b></code>{@code LongBits(b)}<br>
> 
> Place in a code snippet since it's hard to read in source otherwise? Snippets allow for highlighting e.g.
> 
> /**
>  * {@snippet :
>  * Double.doubleToRawLongBits(a) == Double.doubleToRawLongBits(b) // @highlight substring="Raw"
>  * }
>  */

Before sending out the PR, I used a snippet, but it formatted the code using too much vertical space for the definition list. I didn't look to see if there was a "compact" styling option that could be used.

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From dholmes at openjdk.org  Tue Oct  4 05:47:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Oct 2022 05:47:58 GMT
Subject: RFR: 8292016: Cleanup legacy error reporting in the JDK outside of
 HotSpot [v35]
In-Reply-To: <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
Message-ID: <oLzbJ-oDkOK9CJskugo8l0PymNJU7OBAE58TUos5XK4=.41efd644-8389-4d88-8575-5672e2a05c1a@github.com>

On Mon, 3 Oct 2022 13:37:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A large section of error reporting code in the JDK does not properly handle WIN32 API errors and instead mixes them with errors originating from C. Since they can be rather easily replaced and coming up with an elegant solution proved to be too much of a hassle to be worth it, and some of the concerns they address no longer are an issue with current versions of the platforms supported by the JDK, they can be easily removed without much effect. The remaining utilities that are still needed now instead report directly from strerror, with a new subsystem for WIN32 errors put in place wherever required, to minimize confusion when they are used, which was a problem with earlier solutions to this issue.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naming

> JNU_ThrowByNameWithStrerror
> JNU_ThrowByNamePerror
> JNU_ThrowIOExceptionWithIOError

The problem with this kind of naming is that the user of the API for which these functions are then called, should not have to know anything about the origins of the actual error code/string. The call-sites really do want to say `ThrowXXXWithLastError`.

Maybe I'm wrong to believe that they can be ignorant of the the details but the level of abstraction seems wrong to me.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From darcy at openjdk.org  Tue Oct  4 05:55:00 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Oct 2022 05:55:00 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v3]
In-Reply-To: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
Message-ID: <a5trvqw-dMN6_0I3Wut2-wWD7MVK5V_OY-49mtB2er8=.19ecf9f2-b739-4ac4-8572-5bc2e90767aa@github.com>

> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8294539
 - Add discussion of numerical equality.
 - Fix typo.
 - JDK-8294539: Augment discussion of equivlance relations on floating-point values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10498/files
  - new: https://git.openjdk.org/jdk/pull/10498/files/58543643..3a7dfbeb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=01-02

  Stats: 8367 lines in 209 files changed: 5462 ins; 2077 del; 828 mod
  Patch: https://git.openjdk.org/jdk/pull/10498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10498/head:pull/10498

PR: https://git.openjdk.org/jdk/pull/10498

From darcy at openjdk.org  Tue Oct  4 05:55:03 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Oct 2022 05:55:03 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <tBnueB_k8ZVSzE5KrYPy7iDiGKWcaTaGl_Dk8o5Xn7k=.22f8e2de-2832-475b-9bb7-29d61b7e8f2c@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
 <tBnueB_k8ZVSzE5KrYPy7iDiGKWcaTaGl_Dk8o5Xn7k=.22f8e2de-2832-475b-9bb7-29d61b7e8f2c@github.com>
Message-ID: <zB4LDjRI0_FXjyDYpoUbQQa6z6l7J4JIHLY1BbF-72c=.24fd9778-176c-45ea-9805-93414dc09c3b@github.com>

On Mon, 3 Oct 2022 20:04:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add discussion of numerical equality.
>>  - Fix typo.
>
> src/java.base/share/classes/java/lang/Double.java line 181:
> 
>> 179:  * <li> {@code +0.0} and {@code -0.0} are distinguished from each other.
>> 180:  * <li> every bit pattern encoding a NaN is considered equivalent to each other
>> 181:  * <li> an infinite value is equivalent to an infinite value of the same sign
> 
> Seems like this line on infinities could be reworded. I wouldn't quibble over this except that I had to read it several times to figure out what it meant. The statement on NaN is universally quantified, whereas the statement on infinite values starts off sounding like an existential quantifier. Possibly: "all infinite values of the same sign are considered equivalent to each other."

Update as suggested and added some cross-links in from BigDecimal; thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From alanb at openjdk.org  Tue Oct  4 06:51:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Oct 2022 06:51:20 GMT
Subject: RFR: 8292016: Cleanup legacy error reporting in the JDK outside of
 HotSpot [v35]
In-Reply-To: <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
Message-ID: <zlU-ooqNm_BH9FdtyAoEVwxWBYGnkw8a6xSQfMBAgc8=.dab125ee-8a67-406f-a931-dab7ba383ed5@github.com>

On Mon, 3 Oct 2022 13:37:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A large section of error reporting code in the JDK does not properly handle WIN32 API errors and instead mixes them with errors originating from C. Since they can be rather easily replaced and coming up with an elegant solution proved to be too much of a hassle to be worth it, and some of the concerns they address no longer are an issue with current versions of the platforms supported by the JDK, they can be easily removed without much effect. The remaining utilities that are still needed now instead report directly from strerror, with a new subsystem for WIN32 errors put in place wherever required, to minimize confusion when they are used, which was a problem with earlier solutions to this issue.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naming

I skimmed through the latest version. I think most of the changes at the use-sites need to be reverted as they are just too confusing and error prone. Maybe this PR should be changed back to draft until there is some agreement on this topic?

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From jbhateja at openjdk.org  Tue Oct  4 06:52:56 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 4 Oct 2022 06:52:56 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <Ji9rHFKZ1Fm-rhQ36_laIoSnK8_3RdRgcIJaevKQKf8=.a5b6c008-6f57-460d-88dd-6c00f32024ec@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
 <P3WD1fmVLCwmvGi1rEyYNJg9vRN0J8JgV8bn4eIHsc4=.186a8e48-1cb9-4e88-b2e2-7ca142fb9163@github.com>
 <ix-SKa4ZivpVntpiwiIhQfRExnjCTZO2MbJkrw-je80=.294816e5-2607-4580-a108-bb90abd2701b@github.com>
 <Ji9rHFKZ1Fm-rhQ36_laIoSnK8_3RdRgcIJaevKQKf8=.a5b6c008-6f57-460d-88dd-6c00f32024ec@github.com>
Message-ID: <iQs_nJCjhU4rE0iAVLPaKVGlH8LGx7gqlznFb0vyY8s=.ec7c05b6-39fd-4644-8169-56daa35b85ad@github.com>

On Mon, 3 Oct 2022 17:47:00 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Rethink about it, you can get 0x01 by right shifting k0 to the right - `kshiftrw(ktmp, k0, 15)`
>
> @merykitty Thanks for the suggestion. I will update the instruct to use kmovwl. I will also experiment with kshiftrw and let you know.

> You can use `kmovwl` instead which will relax the avx512bw constraint, however, you will need avx512vl for `evcvtps2ph`. Thanks.

Yes, in general all AVX512VL targets support AVX512BW, but cloud instances give freedom to enable custom features. Regarding K0, as per section "15.6.1.1" of SDM, expectation is that K0 can appear in source and destination of regular non predication context, k0 should always contain all true mask so it should be unmodifiable for subsequent usages i.e. should not be present as destination of a mask manipulating instruction. Your suggestion is to have that in source but it may not work either. Changing existing sequence to use kmovw and replace AVX512BW with AVX512VL will again mean introducing an additional predication check for this pattern.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From alanb at openjdk.org  Tue Oct  4 06:58:54 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Oct 2022 06:58:54 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos
In-Reply-To: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
Message-ID: <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>

On Mon, 3 Oct 2022 07:29:02 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8294702

src/java.base/share/classes/java/io/BufferedInputStream.java line 546:

> 544:     private void implReset() throws IOException {
> 545:         getBufIfOpen(); // Cause exception if closed
> 546:         if (markpos == -1)

Just looking at this one again and it might be better to not change implReset. If a broken subclass were to set markpos to less than -1 then the reset() method would throw and avoid a more confusing IIOOBE or other exception.

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From mbaesken at openjdk.org  Tue Oct  4 08:00:21 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Oct 2022 08:00:21 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v4]
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  enhance test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10300/files
  - new: https://git.openjdk.org/jdk/pull/10300/files/3c2f0938..701c7628

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10300&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10300&range=02-03

  Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10300.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10300/head:pull/10300

PR: https://git.openjdk.org/jdk/pull/10300

From mbaesken at openjdk.org  Tue Oct  4 08:00:23 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Oct 2022 08:00:23 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v3]
In-Reply-To: <uZcnYBHyBXqeRaeNzPmB4rxNjZUuyd6iHou9YGddxC0=.49777030-f05e-46d6-952c-1f127da597b2@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <uZcnYBHyBXqeRaeNzPmB4rxNjZUuyd6iHou9YGddxC0=.49777030-f05e-46d6-952c-1f127da597b2@github.com>
Message-ID: <IlNOJ_ATk0of0rnHXh8GspTA3YLjr7aXAKRX-p6ALhw=.a8874943-3851-4bc6-b826-04cda29f9200@github.com>

On Fri, 30 Sep 2022 10:51:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
>> 
>> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
>> 
>> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
>> Exception in thread "main" java.util.NoSuchElementException: No value present
>>         at java.base/java.util.Optional.get(Optional.java:148)
>>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>> 
>> So an additional  check might be a good idea.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust test

Hi Mandy, thanks for the advice , I enhanced the test.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From qamai at openjdk.org  Tue Oct  4 09:11:28 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Oct 2022 09:11:28 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <iQs_nJCjhU4rE0iAVLPaKVGlH8LGx7gqlznFb0vyY8s=.ec7c05b6-39fd-4644-8169-56daa35b85ad@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
 <P3WD1fmVLCwmvGi1rEyYNJg9vRN0J8JgV8bn4eIHsc4=.186a8e48-1cb9-4e88-b2e2-7ca142fb9163@github.com>
 <ix-SKa4ZivpVntpiwiIhQfRExnjCTZO2MbJkrw-je80=.294816e5-2607-4580-a108-bb90abd2701b@github.com>
 <Ji9rHFKZ1Fm-rhQ36_laIoSnK8_3RdRgcIJaevKQKf8=.a5b6c008-6f57-460d-88dd-6c00f32024ec@github.com>
 <iQs_nJCjhU4rE0iAVLPaKVGlH8LGx7gqlznFb0vyY8s=.ec7c05b6-39fd-4644-8169-56daa35b85ad@github.com>
Message-ID: <i8tl8yTM_cC7ZZi-871jbW-3HvqXQNMHjTIxfqnZiFc=.4034a16e-b3ad-4346-9f99-9797fcf4a7dc@github.com>

On Tue, 4 Oct 2022 06:49:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @merykitty Thanks for the suggestion. I will update the instruct to use kmovwl. I will also experiment with kshiftrw and let you know.
>
>> You can use `kmovwl` instead which will relax the avx512bw constraint, however, you will need avx512vl for `evcvtps2ph`. Thanks.
> 
> Yes, in general all AVX512VL targets support AVX512BW, but cloud instances give freedom to enable custom features. Regarding K0, as per section "15.6.1.1" of SDM, expectation is that K0 can appear in source and destination of regular non predication context, k0 should always contain all true mask so it should be unmodifiable for subsequent usages i.e. should not be present as destination of a mask manipulating instruction. Your suggestion is to have that in source but it may not work either. Changing existing sequence to use kmovw and replace AVX512BW with AVX512VL will again mean introducing an additional predication check for this pattern.

Ah I get it, the encoding of k0 is treated specially in predicated instructions to refer to an all-set mask, but the register itself may not actually contain that value. So usage in `kshiftrw` may fail. In that case I think we can generate an all-set mask on the fly using `kxnorw(ktmp, ktmp)` to save a GPR in this occasion. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From shade at openjdk.org  Tue Oct  4 10:03:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Oct 2022 10:03:21 GMT
Subject: RFR: 8294509: The sign extension bug applies to 'public static
 int[] convertSeedBytesToInts(byte[] seed, int n, int z)' in RandomSupport
In-Reply-To: <hohBnlhoL1xDz4Lmfs_2uAZmfQ5wnXYxyxCSGyd7VBw=.e01b6087-a419-461d-9ffc-2d556fd12eea@github.com>
References: <hohBnlhoL1xDz4Lmfs_2uAZmfQ5wnXYxyxCSGyd7VBw=.e01b6087-a419-461d-9ffc-2d556fd12eea@github.com>
Message-ID: <et0lnLyLZ7XrMlHlpaizf8i4hrY7f8kZSwo28vY6aaY=.19b3b780-2497-4d76-8f99-9a6c8948958d@github.com>

On Mon, 3 Oct 2022 09:45:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Fixes sign extension propagation to higher bits.

This looks good! Remarkably, SonarCloud reports the bug on this line ("Prevent "int" promotion by adding '& 0xff' to this expression"), but I skipped it when generating the reports, d'uh.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10530

From rgiulietti at openjdk.org  Tue Oct  4 10:28:43 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 4 Oct 2022 10:28:43 GMT
Subject: Integrated: 8294509: The sign extension bug applies to 'public static
 int[] convertSeedBytesToInts(byte[] seed, int n,
 int z)' in RandomSupport
In-Reply-To: <hohBnlhoL1xDz4Lmfs_2uAZmfQ5wnXYxyxCSGyd7VBw=.e01b6087-a419-461d-9ffc-2d556fd12eea@github.com>
References: <hohBnlhoL1xDz4Lmfs_2uAZmfQ5wnXYxyxCSGyd7VBw=.e01b6087-a419-461d-9ffc-2d556fd12eea@github.com>
Message-ID: <9WH3PXJBGUqcLG9FaBAXcJBHDaOKu-gdQt-lAtZSoM4=.2b8ad0ac-409e-4251-95ca-700b6e61646f@github.com>

On Mon, 3 Oct 2022 09:45:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Fixes sign extension propagation to higher bits.

This pull request has now been integrated.

Changeset: 5a9cd336
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a9cd33632862aa2249794902d4168a7fe143054
Stats:     41 lines in 2 files changed: 39 ins; 0 del; 2 mod

8294509: The sign extension bug applies to 'public static int[] convertSeedBytesToInts(byte[] seed, int n, int z)' in RandomSupport

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/jdk/pull/10530

From duke at openjdk.org  Tue Oct  4 11:45:24 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 4 Oct 2022 11:45:24 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <_3c1eJ5Ppi7rlgeRmLH4y9-q7qEYh-hzyrgpVsYEnBU=.1413f057-50cf-4cc2-9ea4-4dbfb97f9725@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
 <Yc7jhro-T0I7AfbCkfhxOAM5S95WCMQRHrwkKjKoNac=.db8f57af-2add-407d-a430-3a91f166f583@github.com>
 <_3c1eJ5Ppi7rlgeRmLH4y9-q7qEYh-hzyrgpVsYEnBU=.1413f057-50cf-4cc2-9ea4-4dbfb97f9725@github.com>
Message-ID: <z9dTyMjfYLDb7OTQC0R33kABqYdh-7GlN0IcMYZ87iw=.9cb7faaa-98e4-4040-a7b2-289dfc07a5a7@github.com>

On Mon, 3 Oct 2022 16:44:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I agree that getting rid of the clone can help -- but since [JEP 416](https://openjdk.org/jeps/416) the generators modified here is mostly a fallback and the bulk of the use will use `MethodHandles` (unless you disable JEP 416 and fall back to the legacy impl). I was mostly curious if you had a startup or other benchmark running on mainline where the change you're doing here could be observed.
>
>> I agree that getting rid of the clone can help -- but since [JEP 416](https://openjdk.org/jeps/416) the generators modified here is mostly a fallback and the bulk of the use will use `MethodHandles` (unless you disable JEP 416 and fall back to the legacy impl). I was mostly curious if you had a startup or other benchmark running on mainline where the change you're doing here could be observed.
> 
> @stsypanov like @cl4es said, I expect these dynamically generated methods should only be generated during very early VM startup.  Once the module system is initialized, it will use method handles.   
> 
> How do you run the spring-based applications when you observe these methods being called?   While this change is trivial and no harm to include this change, this code is planned to be removed in a future release.

@mlchung I can put here a stack trace of the application invoking the code if you are interested

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From redestad at openjdk.org  Tue Oct  4 11:57:26 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 4 Oct 2022 11:57:26 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <z9dTyMjfYLDb7OTQC0R33kABqYdh-7GlN0IcMYZ87iw=.9cb7faaa-98e4-4040-a7b2-289dfc07a5a7@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
 <Yc7jhro-T0I7AfbCkfhxOAM5S95WCMQRHrwkKjKoNac=.db8f57af-2add-407d-a430-3a91f166f583@github.com>
 <_3c1eJ5Ppi7rlgeRmLH4y9-q7qEYh-hzyrgpVsYEnBU=.1413f057-50cf-4cc2-9ea4-4dbfb97f9725@github.com>
 <z9dTyMjfYLDb7OTQC0R33kABqYdh-7GlN0IcMYZ87iw=.9cb7faaa-98e4-4040-a7b2-289dfc07a5a7@github.com>
Message-ID: <MiAiUnLou3VUV7Hh-fVf0kwCqBojsgUEhAVv_lmJYk4=.4742f250-88e1-4e16-8143-d676637d518d@github.com>

On Tue, 4 Oct 2022 11:41:31 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>>> I agree that getting rid of the clone can help -- but since [JEP 416](https://openjdk.org/jeps/416) the generators modified here is mostly a fallback and the bulk of the use will use `MethodHandles` (unless you disable JEP 416 and fall back to the legacy impl). I was mostly curious if you had a startup or other benchmark running on mainline where the change you're doing here could be observed.
>> 
>> @stsypanov like @cl4es said, I expect these dynamically generated methods should only be generated during very early VM startup.  Once the module system is initialized, it will use method handles.   
>> 
>> How do you run the spring-based applications when you observe these methods being called?   While this change is trivial and no harm to include this change, this code is planned to be removed in a future release.
>
> @mlchung I can put here a stack trace of the application invoking the code if you are interested

@stsypanov would be helpful to understand when this code still gets executed. Also note that JEP 416 was integrated in JDK 18 so some details about the runtime would be necessary to get a complete picture.

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From jwaters at openjdk.org  Tue Oct  4 12:29:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Oct 2022 12:29:29 GMT
Subject: RFR: 8292016: Cleanup legacy error reporting in the JDK outside of
 HotSpot [v35]
In-Reply-To: <oLzbJ-oDkOK9CJskugo8l0PymNJU7OBAE58TUos5XK4=.41efd644-8389-4d88-8575-5672e2a05c1a@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
 <oLzbJ-oDkOK9CJskugo8l0PymNJU7OBAE58TUos5XK4=.41efd644-8389-4d88-8575-5672e2a05c1a@github.com>
Message-ID: <kkd9odeW8LusP2tMhq6gYe-jyvsyarM8KB5kagTOlV0=.5cd8930c-a892-452d-88b1-3469489b6aa7@github.com>

On Tue, 4 Oct 2022 05:44:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > JNU_ThrowByNameWithStrerror
> > JNU_ThrowByNamePerror
> > JNU_ThrowIOExceptionWithIOError
> 
> The problem with this kind of naming is that the user of the API for which these functions are then called, should not have to know anything about the origins of the actual error code/string. The call-sites really do want to say `ThrowXXXWithLastError`.

That's a good point for the first 2, but I do feel like it would be helpful to specify the kind of error the utilities that are more specialized (NET_ThrowNewWithLastError and JNU_ThrowIOExceptionWithLastError for instance), since both use very different subsystems on Windows and POSIX, which means they can be segregated accordingly. In my opinion the specific error type could be specified after "Last" instead of replacing it as a compromise. The tricky part comes with the first 2 (JNU_ThrowByNameWithLastError and JNU_ThrowByNameWithMessageAndLastError), which are for general use, but their original implementations fell back to the initial problematic mixing of WIN32 and errno errors, and leaving their names unchanged might just result in more ambiguity at the callsites they're used at. I also don't think I came up with particularly good names for them though, and honestly I'm at a bit of a loss as to what should be done with them at this point, hopefully more reviews can come in wit
 h some insight on this end.

> Maybe I'm wrong to believe that they can be ignorant of the details but the level of abstraction seems wrong to me.

The issue with that was Thomas's initial concerns that you can't really use the last error like this without at least some knowledge about the origin and nature of the actual error itself (WIN32 completely bypassing errno on Windows, and APIs on POSIX arbitrarily using it sometimes but using a return value instead to signal an error other times). I did try to address that by making it a little more specific with this patch, but it still seems there's a better way to do it than this...

I'll try to address the other reviews in the meantime though, before coming back to this.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From duke at openjdk.org  Tue Oct  4 12:29:36 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 4 Oct 2022 12:29:36 GMT
Subject: RFR: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform [v2]
In-Reply-To: <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
 <25y_sJVHa9QDx4VcfIJDu9RsAO2EYVfCAcpfWthsczw=.d19ddb42-2cad-497d-8345-1918823fdbfb@github.com>
Message-ID: <WrkylH7V3o0Nk1eRadS1gYyT6SxrEu41B2hvXWeeMqs=.971fc4bc-d41a-42e7-b314-5cacb52d14fe@github.com>

On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> Could you please review the JDK-8293579 bug fixes?
>> 
>> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
>> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
>> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
>> code point "?"(0x00e9) cannot be treated on Japanese Windows.
>> 
>> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
>> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
>> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
>> in this test and judged to be different characters, and return as failed.
>> 
>> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
>> give a character such as "?"(0x3042) as the launcher's argument instead of 
>> "?"(0x00e9).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

Thank you for all reviews. I hope this fix integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From jwaters at openjdk.org  Tue Oct  4 12:31:02 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Oct 2022 12:31:02 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v6]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <L6fkZVcXQX4Ds-FBRu45qm0Day5aGR8b5YxYFhPphww=.536fe2ae-9f5b-496b-beb9-9a130b581d4c@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-4
 - Merge branch 'openjdk:master' into patch-4
 - Back out change to DLL_ERROR4 for separate RFE
 - Missing spacing between errors
 - Introduce warning when system error cannot be determined
 - LoadLibrary checks should explicitly use NULL
 - Dump error (if any) when libraries fail to load
 - Prettify DLL_ERROR4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/284ac2f4..93306172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=04-05

  Stats: 19121 lines in 447 files changed: 10613 ins; 6888 del; 1620 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Tue Oct  4 12:33:20 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Oct 2022 12:33:20 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v7]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <n4WnNevBkVHjZkbuMXy5zJshni0z2NAh8pwnqqYPrMc=.b5081163-5d2a-4eb2-a4fc-e43f3187ed06@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update java_md.h

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/93306172..9cb28eab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Tue Oct  4 12:44:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Oct 2022 12:44:28 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v8]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <FTsYlGw2VUDo7CiP7wMlzqbFbfmzX346oZaayh9_DZE=.d6e6ce0c-4f9a-4f82-b31a-fa6c352d96cd@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update java_md.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/9cb28eab..2f3e12ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=06-07

  Stats: 74 lines in 1 file changed: 70 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Tue Oct  4 12:46:50 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Oct 2022 12:46:50 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v9]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <ZIlKjOGNji8CTfpbkDif4TK4DwoRwTK-1K0pibdspGI=.9c77cc4a-42b4-4353-a0a8-fa04096dd945@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to JLI_ReportErrorMessageSys

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/2f3e12ce..a3762867

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=07-08

  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Tue Oct  4 12:50:22 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Oct 2022 12:50:22 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v10]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <bFYUKD0ajUopi2wd989DWzWvXKk3yXEOYKbKBFvOXz0=.85e9e1c7-5a9a-4e14-a313-d2f7ad1ee001@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Make DLL_ERROR4 look a little better without changing what it means

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/a3762867..0a0b56eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Tue Oct  4 13:03:26 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 4 Oct 2022 13:03:26 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v10]
In-Reply-To: <bFYUKD0ajUopi2wd989DWzWvXKk3yXEOYKbKBFvOXz0=.85e9e1c7-5a9a-4e14-a313-d2f7ad1ee001@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <bFYUKD0ajUopi2wd989DWzWvXKk3yXEOYKbKBFvOXz0=.85e9e1c7-5a9a-4e14-a313-d2f7ad1ee001@github.com>
Message-ID: <VsAEG1dxjR9n3QInJfObE-M0yAcD8Yu8n0U6CJ_y8LQ=.b1562fa1-549b-4be7-9c5f-97632aabdfa5@github.com>

On Tue, 4 Oct 2022 12:50:22 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make DLL_ERROR4 look a little better without changing what it means

Results from usage in JDK-8288293
Failure to load the JVM (before):
`Error: loading: D:\Eclipse\Workspace\HotSpot\jdk\build\windows-x86_64-server-release\jdk\bin\server\jvm.dll`
Failure to load the JVM (after):
`Error: Could not load D:\Eclipse\Workspace\HotSpot\jdk\build\windows-x86_64-server-release\jdk\bin\server\jvm.dll: The specified module could not be found`

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From mchhipa at openjdk.org  Tue Oct  4 13:18:57 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 4 Oct 2022 13:18:57 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes: descendant, 
 descendant-or-self, following, following-sibling
Message-ID: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>

Added test cases for xpath Axis:
1. descendant
2. descendant-or-self
3. following
4. following-sibling

-------------

Commit messages:
 - JDK-8289509 : Improve test coverage for XPath Axes: descendant, descendant-or-self
 - JDK-8289509 : Improve test coverage for XPath Axes: descendant, descendant-or-self, following, following-sibling

Changes: https://git.openjdk.org/jdk/pull/10557/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10557&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289509
  Stats: 308 lines in 2 files changed: 308 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10557.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10557/head:pull/10557

PR: https://git.openjdk.org/jdk/pull/10557

From mchhipa at openjdk.org  Tue Oct  4 13:18:57 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 4 Oct 2022 13:18:57 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling
In-Reply-To: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
Message-ID: <_vP0nuIk22x56GukP7YCydfQhKS_b8SMCkd3iD4GXkI=.286638cc-1a30-4ee3-accc-76fcc996fed5@github.com>

On Tue, 4 Oct 2022 13:01:40 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Added test cases for xpath Axis:
> 1. descendant
> 2. descendant-or-self
> 3. following
> 4. following-sibling

Hi @JoeWang-Java , @bwhuang-us , Could you please review this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From psandoz at openjdk.org  Tue Oct  4 15:20:27 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 4 Oct 2022 15:20:27 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <z3zSNaGzj7y4dh2vEmFPYzk1Y_s2ASMTxE6pL8SjYU4=.b5eeb80e-88aa-4542-9157-da66b75fe154@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
 <DsT0dICpGdqWlhkY6E6I50NmTQ7Y8mVJ29fchW8xPbk=.ed23a8f0-6982-4af2-874a-4c28e2e247ef@github.com>
 <z3zSNaGzj7y4dh2vEmFPYzk1Y_s2ASMTxE6pL8SjYU4=.b5eeb80e-88aa-4542-9157-da66b75fe154@github.com>
Message-ID: <tWTteTWmJDO-VI8SUtizVB4lmLpDrqHnkXI-VRNRF68=.abb5fd0b-930d-4c11-b875-55814eca5b13@github.com>

On Tue, 4 Oct 2022 05:26:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Double.java line 166:
>> 
>>> 164:  * equivalence relation for {@code double} values {@code a} and {@code b} is
>>> 165:  * implemented by the expression
>>> 166:  * <br>{@code Double.doubleTo}<code><b>Raw</b></code>{@code LongBits(a) == Double.doubleTo}<code><b>Raw</b></code>{@code LongBits(b)}<br>
>> 
>> Place in a code snippet since it's hard to read in source otherwise? Snippets allow for highlighting e.g.
>> 
>> /**
>>  * {@snippet :
>>  * Double.doubleToRawLongBits(a) == Double.doubleToRawLongBits(b) // @highlight substring="Raw"
>>  * }
>>  */
>
> Before sending out the PR, I used a snippet, but it formatted the code using too much vertical space for the definition list. I didn't look to see if there was a "compact" styling option that could be used.

Ok, i am not aware of a compact style.

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From duke at openjdk.org  Tue Oct  4 15:48:29 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 4 Oct 2022 15:48:29 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos
In-Reply-To: <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>
Message-ID: <91DREBRbEGaHsnU6yXl89oMf3SRJBLnsUh30Vb-n_x4=.800d2f58-53f6-4a39-b120-3cb8e58cbb94@github.com>

On Tue, 4 Oct 2022 06:55:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Fixes JDK-8294702
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 546:
> 
>> 544:     private void implReset() throws IOException {
>> 545:         getBufIfOpen(); // Cause exception if closed
>> 546:         if (markpos == -1)
> 
> Just looking at this one again and it might be better to not change implReset. If a broken subclass were to set markpos to less than -1 then the reset() method would throw and avoid a more confusing IIOOBE or other exception.

This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change *here*, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From smarks at openjdk.org  Tue Oct  4 15:48:30 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 4 Oct 2022 15:48:30 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v3]
In-Reply-To: <a5trvqw-dMN6_0I3Wut2-wWD7MVK5V_OY-49mtB2er8=.19ecf9f2-b739-4ac4-8572-5bc2e90767aa@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <a5trvqw-dMN6_0I3Wut2-wWD7MVK5V_OY-49mtB2er8=.19ecf9f2-b739-4ac4-8572-5bc2e90767aa@github.com>
Message-ID: <5A2GSsicepZ4AdGtdqvnJblGPbH7sJea5uw_bmWlYLc=.487812d4-3e5e-4535-ac70-337efce2a193@github.com>

On Tue, 4 Oct 2022 05:55:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8294539
>  - Add discussion of numerical equality.
>  - Fix typo.
>  - JDK-8294539: Augment discussion of equivlance relations on floating-point values

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From duke at openjdk.org  Tue Oct  4 15:50:30 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 4 Oct 2022 15:50:30 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME
In-Reply-To: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
Message-ID: <tO5FSnkrW87MqtjS22bbZ_mFbRnwpIiCZJKfiqQ6Ik0=.32f15544-74c3-4226-8ccb-34a9f1bc91a0@github.com>

On Sat, 1 Oct 2022 17:54:37 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes 8294541

As the files are not zero'ed by intention (to detect differences), sparse won't help, so next you'd eventually run into quota trouble (IIRC we already had this a year ago). IMHO we should increase RAM a bit further (really, it is cheap these days), or reduce that size of the tested data itself.

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From alanb at openjdk.org  Tue Oct  4 15:55:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Oct 2022 15:55:18 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos
In-Reply-To: <91DREBRbEGaHsnU6yXl89oMf3SRJBLnsUh30Vb-n_x4=.800d2f58-53f6-4a39-b120-3cb8e58cbb94@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>
 <91DREBRbEGaHsnU6yXl89oMf3SRJBLnsUh30Vb-n_x4=.800d2f58-53f6-4a39-b120-3cb8e58cbb94@github.com>
Message-ID: <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>

On Tue, 4 Oct 2022 15:44:48 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedInputStream.java line 546:
>> 
>>> 544:     private void implReset() throws IOException {
>>> 545:         getBufIfOpen(); // Cause exception if closed
>>> 546:         if (markpos == -1)
>> 
>> Just looking at this one again and it might be better to not change implReset. If a broken subclass were to set markpos to less than -1 then the reset() method would throw and avoid a more confusing IIOOBE or other exception.
>
> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change *here*, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?

> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change _here_, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?

This looks to be the only that would corrupt the current position (pos).

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From alanb at openjdk.org  Tue Oct  4 15:58:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Oct 2022 15:58:26 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME
In-Reply-To: <tO5FSnkrW87MqtjS22bbZ_mFbRnwpIiCZJKfiqQ6Ik0=.32f15544-74c3-4226-8ccb-34a9f1bc91a0@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
 <tO5FSnkrW87MqtjS22bbZ_mFbRnwpIiCZJKfiqQ6Ik0=.32f15544-74c3-4226-8ccb-34a9f1bc91a0@github.com>
Message-ID: <5beCYM-rlWAb5k1kkR-yFh2O-y_za292Y4Oa3boHV7I=.22b5010d-7cae-4e57-af69-f1e50f5af6be@github.com>

On Tue, 4 Oct 2022 15:48:18 GMT, Markus KARG <duke at openjdk.org> wrote:

> As the files are not zero'ed by intention (to detect differences), sparse won't help, so next you'd eventually run into quota trouble (IIRC we already had this a year ago). IMHO we should increase RAM a bit further (really, it is cheap these days), or reduce that size of the tested data itself.

I also pasted an example into the bug where 1Gb isn't enough. If it requires too much then the test may have to be skipped on 32-bit builds.

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From duke at openjdk.org  Tue Oct  4 17:30:04 2022
From: duke at openjdk.org (Chris Hennick)
Date: Tue, 4 Oct 2022 17:30:04 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v15]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <FkrSdNoaTyruDb4PR-wtTga0P_AZezoH12fTxAX8UQk=.e9a38d97-53d9-4215-9667-f7e3779bc9f0@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Rewrite Javadoc
 - Simplify Javadoc description
 - Weaken contract of computeWinsorizedNextExponential to save max/min calls
 - Revert "Bugfix: need a thread-local instance for throughput test"
   
   This reverts commit d903efe57225e916a5450ac31437123050e3377c.
 - More sensible benchmark-mode settings
 - Bugfix: need a thread-local instance for throughput test
 - Split out PRNG benchmarks into org.openjdk.bench.java.util.random
 - Add JMH
 - Fix rounding error in computeNextExponential; use FMA
   
   Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution; this fixes that by tracking the multiple of exponentialX0 as a long.
   
   Add computeWinsorizedNextExponential for testability

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/d1c9bafd..c94a09e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=13-14

  Stats: 381291 lines in 6418 files changed: 204420 ins; 125420 del; 51451 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Tue Oct  4 17:32:11 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 4 Oct 2022 17:32:11 GMT
Subject: Integrated: 8293579:
 tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese
 Windows platform
In-Reply-To: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
References: <ROgI801Y_MVdXiCKPYVtwN9C5kDZTT3gdAo4pnCACbs=.618721ad-4cc5-4db7-a923-3bf740e35181@github.com>
Message-ID: <_PfGsN3JRy0oRfhveGjCoh1iVFsQkYBGSMiSMA2HmUo=.35e5339e-4905-4389-90fb-5bf9c9c7c392@github.com>

On Fri, 9 Sep 2022 08:30:55 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8293579 bug fixes?
> 
> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give 
> the launcher the character which is encoded by Windows API WideCharToMultiByte() 
> from UNICODE "?"(0x00e9) as an argument. However, this test fails because the 
> code point "?"(0x00e9) cannot be treated on Japanese Windows.
> 
> WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, but 
> the code point "?"(0x00e9) does not exist in Shift-JIS, and it is replaced with 
> "e"(0x0065) as substitute. Therefore, "?"(0x00e9) and "e"(0x0065) are compared 
> in this test and judged to be different characters, and return as failed.
> 
> So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to 
> give a character such as "?"(0x3042) as the launcher's argument instead of 
> "?"(0x00e9).

This pull request has now been integrated.

Changeset: 121d4a51
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/121d4a5119f98adf30fa759563eec843a6e37d61
Stats:     14 lines in 1 file changed: 12 ins; 0 del; 2 mod

8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform

Reviewed-by: asemenyuk, naoto, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/10226

From duke at openjdk.org  Tue Oct  4 17:36:56 2022
From: duke at openjdk.org (Chris Hennick)
Date: Tue, 4 Oct 2022 17:36:56 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v16]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <GKQOg02og11alcCgOGPGZ2wn41zf6g5RylUm74Glr_k=.e5ad1226-a6ee-412f-8508-08946ef11eae@github.com>

> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`.

Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:

  Add parameter to enable/disable fixed PRNG seed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/c94a09e5..b75139c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=14-15

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From cjplummer at openjdk.org  Tue Oct  4 18:23:32 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Oct 2022 18:23:32 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <XthWrxywPU-tw6sJgFSvCBHFFWiJ28ZomsCejRLM6xA=.433b9877-8e1d-4162-bb6f-60abceddec1e@github.com>
 <bj6-5xC1mWXfuzSDLowQQPxYmo9OcqnW0XYnGLvEW0c=.c97b6b36-8590-47af-bdc2-e94f2230af08@github.com>
Message-ID: <CR61AGqmsFAARRtaenUEX9DJvp3BC5TknkAuUGNXr8w=.ba3ebdbf-056c-46b7-8762-3e6aff4f1edd@github.com>

On Wed, 28 Sep 2022 15:32:11 GMT, Michael Ernst <mernst at openjdk.org> wrote:

> The title was edited by someone other than me, as you can see from the PR history.

The PR title needs to match the CR synopsis, so update the CR first, and then update the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From bchristi at openjdk.org  Tue Oct  4 18:24:34 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Oct 2022 18:24:34 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v5]
In-Reply-To: <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
Message-ID: <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>

On Mon, 3 Oct 2022 21:22:03 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove temp var
>   
>   Remove temp variables and replace with method chaining when possible

Changes requested by bchristi (Reviewer).

src/java.base/share/classes/java/text/DigitList.java line 161:

> 159:     public final double getDouble() {
> 160:         if (count == 0) {
> 161:             return 0.0;

The doc for this method is incorrect:

* If (count == 0) this throws a NumberFormatException, which
* mimics Long.parseLong().

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From mchung at openjdk.org  Tue Oct  4 18:30:28 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Oct 2022 18:30:28 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v4]
In-Reply-To: <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
Message-ID: <7BU8aR7BZe9YcZoXu2CsoZ8K6OKzJOkaze6yNvE_aCc=.7bc3d1a4-ed59-4535-aaa9-f0550584b8c9@github.com>

On Tue, 4 Oct 2022 08:00:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
>> 
>> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
>> 
>> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
>> Exception in thread "main" java.util.NoSuchElementException: No value present
>>         at java.base/java.util.Optional.get(Optional.java:148)
>>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>> 
>> So an additional  check might be a good idea.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enhance test

Looks good.  Thanks for fixing this.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10300

From prr at openjdk.org  Tue Oct  4 18:42:44 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 4 Oct 2022 18:42:44 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <sHOtl2OQ9-SEwkAbYNVq8gBaJMrW-my-5CBX2s1avkI=.8c95a200-f440-4e98-907f-2060e620c5b6@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/571e4932...4055f1a6

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From duke at openjdk.org  Tue Oct  4 18:46:14 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 4 Oct 2022 18:46:14 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v5]
In-Reply-To: <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
 <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>
Message-ID: <08qgcEKEf6WzestzSY9xiXCA1tLbdb4zEfCtAh1UF90=.bc631d76-0c99-4967-9108-87f277aaeddd@github.com>

On Tue, 4 Oct 2022 18:20:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove temp var
>>   
>>   Remove temp variables and replace with method chaining when possible
>
> src/java.base/share/classes/java/text/DigitList.java line 161:
> 
>> 159:     public final double getDouble() {
>> 160:         if (count == 0) {
>> 161:             return 0.0;
> 
> The doc for this method is incorrect:
> 
> * If (count == 0) this throws a NumberFormatException, which
> * mimics Long.parseLong().

I believe that relates to https://bugs.openjdk.org/browse/JDK-8170389

Which I can address in a separate PR

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From naoto at openjdk.org  Tue Oct  4 18:46:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Oct 2022 18:46:14 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v5]
In-Reply-To: <08qgcEKEf6WzestzSY9xiXCA1tLbdb4zEfCtAh1UF90=.bc631d76-0c99-4967-9108-87f277aaeddd@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
 <Js1_DOMQhbgKxw4sht8sWxdKxSBVNBnQIIPwBFNFEqk=.8a5b4c79-b64c-4944-9490-6709be0e2c00@github.com>
 <08qgcEKEf6WzestzSY9xiXCA1tLbdb4zEfCtAh1UF90=.bc631d76-0c99-4967-9108-87f277aaeddd@github.com>
Message-ID: <Gav1KJeEKgHMIxaiL51B4DisgS3IYmCw8MqVtwTxz9Q=.d934cb9c-7c9a-4d69-a492-f412deff59a6@github.com>

On Tue, 4 Oct 2022 18:42:52 GMT, Justin Lu <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DigitList.java line 161:
>> 
>>> 159:     public final double getDouble() {
>>> 160:         if (count == 0) {
>>> 161:             return 0.0;
>> 
>> The doc for this method is incorrect:
>> 
>> * If (count == 0) this throws a NumberFormatException, which
>> * mimics Long.parseLong().
>
> I believe that relates to https://bugs.openjdk.org/browse/JDK-8170389
> 
> Which I can address in a separate PR

Good catch! Also, I think the comment should compare it with `Double.parseDouble()`

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From darcy at openjdk.org  Tue Oct  4 19:31:57 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Oct 2022 19:31:57 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v4]
In-Reply-To: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
Message-ID: <I8-1XRkOU9fCb7gvEhHAOnbsrj7h9g0b_U34G725C98=.c3fc982a-719f-4a57-a1bc-e08edec038bd@github.com>

> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add additional explanatory paragraph.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10498/files
  - new: https://git.openjdk.org/jdk/pull/10498/files/3a7dfbeb..aaac7312

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=02-03

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10498/head:pull/10498

PR: https://git.openjdk.org/jdk/pull/10498

From darcy at openjdk.org  Tue Oct  4 19:31:57 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Oct 2022 19:31:57 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <zB4LDjRI0_FXjyDYpoUbQQa6z6l7J4JIHLY1BbF-72c=.24fd9778-176c-45ea-9805-93414dc09c3b@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
 <tBnueB_k8ZVSzE5KrYPy7iDiGKWcaTaGl_Dk8o5Xn7k=.22f8e2de-2832-475b-9bb7-29d61b7e8f2c@github.com>
 <zB4LDjRI0_FXjyDYpoUbQQa6z6l7J4JIHLY1BbF-72c=.24fd9778-176c-45ea-9805-93414dc09c3b@github.com>
Message-ID: <w6fJvJUNPTEKOaKNqwc1jz4tqR6JnJWhHdGurNdFoag=.95fe178d-da23-4925-aa1b-f99cf7893114@github.com>

On Tue, 4 Oct 2022 05:50:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Double.java line 181:
>> 
>>> 179:  * <li> {@code +0.0} and {@code -0.0} are distinguished from each other.
>>> 180:  * <li> every bit pattern encoding a NaN is considered equivalent to each other
>>> 181:  * <li> an infinite value is equivalent to an infinite value of the same sign
>> 
>> Seems like this line on infinities could be reworded. I wouldn't quibble over this except that I had to read it several times to figure out what it meant. The statement on NaN is universally quantified, whereas the statement on infinite values starts off sounding like an existential quantifier. Possibly: "all infinite values of the same sign are considered equivalent to each other."
>
> Update as suggested and added some cross-links in from BigDecimal; thanks.

PS To further spell things out, I added an additional trailing paragraph:

"For two binary floating-point values a and b, if neither of a and b is zero or NaN, then the three relations numerical equality, bit-wise equivalence, and representation equivalence of a and b have the same true/false value. In other words, for binary floating-point values, the three relations only differ if at least one argument is zero or NaN."

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From darcy at openjdk.org  Tue Oct  4 19:56:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Oct 2022 19:56:21 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v5]
In-Reply-To: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
Message-ID: <BNOkejO3lWWtVdQ-F2zluGQD99tg6QH1T9N0qTipBww=.505b336d-977f-4335-bd59-98b0422be0a3@github.com>

> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Appease jcheck; reflow paragraphs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10498/files
  - new: https://git.openjdk.org/jdk/pull/10498/files/aaac7312..8aca6b30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10498&range=03-04

  Stats: 16 lines in 1 file changed: 2 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10498.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10498/head:pull/10498

PR: https://git.openjdk.org/jdk/pull/10498

From bchristi at openjdk.org  Tue Oct  4 20:21:23 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Oct 2022 20:21:23 GMT
Subject: RFR: 8294397: Replace StringBuffer with StringBuilder within
 java.text [v5]
In-Reply-To: <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
 <NR722EcO9p9-GrFsQ9qSPqziMoNtdTVoa2nNEjzKY_c=.d2bf224d-1f48-4f38-b418-2a0e33d7625d@github.com>
Message-ID: <8eLvxvzT0L8G4yyg42K3xOsiTf5IAe3DYmqwHCzogo4=.4c20bf2f-991f-42e9-b7da-21db4d5fde21@github.com>

On Mon, 3 Oct 2022 21:22:03 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
>> 
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove temp var
>   
>   Remove temp variables and replace with method chaining when possible

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From duke at openjdk.org  Tue Oct  4 21:56:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 4 Oct 2022 21:56:28 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <MiAiUnLou3VUV7Hh-fVf0kwCqBojsgUEhAVv_lmJYk4=.4742f250-88e1-4e16-8143-d676637d518d@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
 <Yc7jhro-T0I7AfbCkfhxOAM5S95WCMQRHrwkKjKoNac=.db8f57af-2add-407d-a430-3a91f166f583@github.com>
 <_3c1eJ5Ppi7rlgeRmLH4y9-q7qEYh-hzyrgpVsYEnBU=.1413f057-50cf-4cc2-9ea4-4dbfb97f9725@github.com>
 <z9dTyMjfYLDb7OTQC0R33kABqYdh-7GlN0IcMYZ87iw=.9cb7faaa-98e4-4040-a7b2-289dfc07a5a7@github.com>
 <MiAiUnLou3VUV7Hh-fVf0kwCqBojsgUEhAVv_lmJYk4=.4742f250-88e1-4e16-8143-d676637d518d@github.com>
Message-ID: <UmfmQIjvZWOleijfSZGjbjYjYed0NXCxXUCfLDHYv48=.d9e59d5b-d2cd-4bc9-80e7-09d31fdcdac6@github.com>

On Tue, 4 Oct 2022 11:55:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @mlchung I can put here a stack trace of the application invoking the code if you are interested
>
> @stsypanov would be helpful to understand when this code still gets executed. Also note that JEP 416 was integrated in JDK 18 so some details about the runtime would be necessary to get a complete picture.

@cl4es @mlchung here's the stacktrace of my app running on Java 19:

generate:136, MethodAccessorGenerator (jdk.internal.reflect)
generateSerializationConstructor:107, MethodAccessorGenerator (jdk.internal.reflect)
generateConstructor:420, ReflectionFactory (jdk.internal.reflect)
newConstructorForSerialization:412, ReflectionFactory (jdk.internal.reflect)
getSerializableConstructor:1444, ObjectStreamClass (java.io)
run:412, ObjectStreamClass$2 (java.io)
run:384, ObjectStreamClass$2 (java.io)
executePrivileged:778, AccessController (java.security)
doPrivileged:319, AccessController (java.security)
<init>:384, ObjectStreamClass (java.io)
computeValue:110, ObjectStreamClass$Caches$1 (java.io)
computeValue:107, ObjectStreamClass$Caches$1 (java.io)
computeValue:73, ClassCache$1 (java.io)
computeValue:70, ClassCache$1 (java.io)
getFromHashMap:229, ClassValue (java.lang)
getFromBackup:211, ClassValue (java.lang)
get:117, ClassValue (java.lang)
get:84, ClassCache (java.io)
lookup:363, ObjectStreamClass (java.io)
lookup:246, ObjectStreamClass (java.io)
<clinit>:27, Result (org.junit.runner)
run:132, JUnitCore (org.junit.runner)
startRunnerWithArgs:69, JUnit4IdeaTestRunner (com.intellij.junit4)
execute:38, IdeaTestRunner$Repeater$1 (com.intellij.rt.junit)
repeat:11, TestsRepeater (com.intellij.rt.execution.junit)
startRunnerWithArgs:35, IdeaTestRunner$Repeater (com.intellij.rt.junit)
prepareStreamsAndStart:235, JUnitStarter (com.intellij.rt.junit)
main:54, JUnitStarter (com.intellij.rt.junit)


![image](https://user-images.githubusercontent.com/10835776/193937346-a16f69f2-a666-4d99-9b02-d7ec95fe6909.png)

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From mchung at openjdk.org  Tue Oct  4 22:00:37 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 4 Oct 2022 22:00:37 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
Message-ID: <LD_LkqaVMquaXVm3CJbWSIgEtO6-9sHe0vFv7JbF1M0=.aeea5b98-1221-4bc3-80ec-8579c151e51a@github.com>

On Sun, 2 Oct 2022 20:45:02 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`

Thanks.  This is for serialization and not the use of the core reflection which is what JEP 416 covered.

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From duke at openjdk.org  Tue Oct  4 22:02:27 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 4 Oct 2022 22:02:27 GMT
Subject: RFR: 8294698: Remove unused 'checkedExceptions' param from
 MethodAccessorGenerator.generateMethod()
In-Reply-To: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
References: <zQW1wQYzmK-0m5_u0pgOgT-1ekTqoUtpyizKGYctZyw=.2b0f1f79-8dfb-491a-b390-8b7dc0bc6f06@github.com>
Message-ID: <qosC7In04wQj4L-TkDkMmM-yz6FI2g6PUrhGxrcZZsU=.557c04c1-1b11-4145-8f94-0529ddc43953@github.com>

On Sun, 2 Oct 2022 20:45:02 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> `checkedExceptions` param of `MethodAccessorGenerator.generateMethod()` is unused and should be removed in order to prevent allocations from `Method.getExceptionTypes()`

Is it going to be covered with new reflection sometimes?

-------------

PR: https://git.openjdk.org/jdk/pull/10526

From jjg at openjdk.org  Tue Oct  4 23:20:24 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 4 Oct 2022 23:20:24 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <tWTteTWmJDO-VI8SUtizVB4lmLpDrqHnkXI-VRNRF68=.abb5fd0b-930d-4c11-b875-55814eca5b13@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
 <DsT0dICpGdqWlhkY6E6I50NmTQ7Y8mVJ29fchW8xPbk=.ed23a8f0-6982-4af2-874a-4c28e2e247ef@github.com>
 <z3zSNaGzj7y4dh2vEmFPYzk1Y_s2ASMTxE6pL8SjYU4=.b5eeb80e-88aa-4542-9157-da66b75fe154@github.com>
 <tWTteTWmJDO-VI8SUtizVB4lmLpDrqHnkXI-VRNRF68=.abb5fd0b-930d-4c11-b875-55814eca5b13@github.com>
Message-ID: <hh151Z-yK2Wwa-VAm4O6KNgStgh5ux3BN3e2Rk83BFU=.5cf9acea-69b4-48f6-b229-a0902b316da7@github.com>

On Tue, 4 Oct 2022 15:18:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Before sending out the PR, I used a snippet, but it formatted the code using too much vertical space for the definition list. I didn't look to see if there was a "compact" styling option that could be used.
>
> Ok, i am not aware of a compact style.

Filed [JDK-8294814](https://bugs.openjdk.org/browse/JDK-8294814)

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From duke at openjdk.org  Tue Oct  4 23:21:01 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 4 Oct 2022 23:21:01 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy between
 javadoc and code
Message-ID: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>

Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
Fix: Update doc to match code, compared to Double.parseDouble() accordingly.

-------------

Commit messages:
 - Update java doc to reflect code

Changes: https://git.openjdk.org/jdk/pull/10567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8170389
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10567.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10567/head:pull/10567

PR: https://git.openjdk.org/jdk/pull/10567

From smarks at openjdk.org  Tue Oct  4 23:36:07 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 4 Oct 2022 23:36:07 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v2]
In-Reply-To: <w6fJvJUNPTEKOaKNqwc1jz4tqR6JnJWhHdGurNdFoag=.95fe178d-da23-4925-aa1b-f99cf7893114@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <esL7scbswpM_Y8MCwbQTxk-Ohh4rMkDlvUO1-NeeQ_A=.890adc61-1331-4ce1-a804-b812ef85cae3@github.com>
 <tBnueB_k8ZVSzE5KrYPy7iDiGKWcaTaGl_Dk8o5Xn7k=.22f8e2de-2832-475b-9bb7-29d61b7e8f2c@github.com>
 <zB4LDjRI0_FXjyDYpoUbQQa6z6l7J4JIHLY1BbF-72c=.24fd9778-176c-45ea-9805-93414dc09c3b@github.com>
 <w6fJvJUNPTEKOaKNqwc1jz4tqR6JnJWhHdGurNdFoag=.95fe178d-da23-4925-aa1b-f99cf7893114@github.com>
Message-ID: <vrW6XK5j3am0Ua3ehW7h-fdBGcIt3ThSpCkdKco87tw=.ffc7613c-3c05-4f89-9995-01e81f4e5039@github.com>

On Tue, 4 Oct 2022 19:28:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update as suggested and added some cross-links in from BigDecimal; thanks.
>
> PS To further spell things out, I added an additional trailing paragraph:
> 
> "For two binary floating-point values a and b, if neither of a and b is zero or NaN, then the three relations numerical equality, bit-wise equivalence, and representation equivalence of a and b have the same true/false value. In other words, for binary floating-point values, the three relations only differ if at least one argument is zero or NaN."

The additional paragraph sounds fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From psandoz at openjdk.org  Tue Oct  4 23:45:30 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 4 Oct 2022 23:45:30 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v5]
In-Reply-To: <BNOkejO3lWWtVdQ-F2zluGQD99tg6QH1T9N0qTipBww=.505b336d-977f-4335-bd59-98b0422be0a3@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <BNOkejO3lWWtVdQ-F2zluGQD99tg6QH1T9N0qTipBww=.505b336d-977f-4335-bd59-98b0422be0a3@github.com>
Message-ID: <Y6dCXi3j4_spGfGKlYsOPoPT_bwUxSkUilxeUN3-i0w=.774ee7be-bd55-4380-aa59-a12a859de4a5@github.com>

On Tue, 4 Oct 2022 19:56:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck; reflow paragraphs.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From darcy at openjdk.org  Wed Oct  5 00:22:22 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 00:22:22 GMT
Subject: Integrated: JDK-8294539: Augment discussion of equivalence relations
 on floating-point values
In-Reply-To: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
Message-ID: <be5rjQUhsz2_LQbxM8_ideujYIodwjDmdhIgedFaIBc=.b363d418-26be-4992-ab82-e188faf2571a@github.com>

On Thu, 29 Sep 2022 22:14:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.

This pull request has now been integrated.

Changeset: 1dafbe3f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1dafbe3f944fdb3027df38a886fd15abc3b476a7
Stats:     71 lines in 2 files changed: 64 ins; 0 del; 7 mod

8294539: Augment discussion of equivalence relations on floating-point values

Reviewed-by: psandoz, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From smarks at openjdk.org  Wed Oct  5 00:57:25 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 5 Oct 2022 00:57:25 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <1K85uSytblPO01nn-KY8v2-9TjTtIc_BrBWsqeltmok=.f1f48df5-359b-4984-b47f-f123f7e1c164@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>
 <1K85uSytblPO01nn-KY8v2-9TjTtIc_BrBWsqeltmok=.f1f48df5-359b-4984-b47f-f123f7e1c164@github.com>
Message-ID: <f-h2ekZHxMpKwDR3DguYcvuswDCzTLE-vMLVIocu5OY=.82cef259-461b-4e51-9dc3-0bbf686cccc8@github.com>

On Wed, 31 Aug 2022 05:47:21 GMT, liach <duke at openjdk.org> wrote:

>> liach has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Move tests
>>  - Merge branch 'master' into fix/identityhashmap-default
>>  - Fix assertions
>>  - Revamp test and changes. Let ci run the tests
>>  - Fix indent
>>  - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)
>
> Let's wait

@liach Thanks for merging in a recent master. I started looking at this now. The tests and implementation look good. I've run this through our internal build&test system and the results look good too.

Per @dfuch comment of June 1 I also looked at various method specs to see whether they would need to be updated to have reference-equality semantics. The specs are all in mostly pretty good shape, but I did add a few clauses here and there and I also added some cross-references, so I think the spec is overall much tighter now.

I've pushed a branch with my proposed spec changes. Please merge from

https://github.com/stuart-marks/jdk/tree/JDK-8178355-IdentityHashMap

which should be based on the current head of this PR branch.

The next step would be the CSR. I'd suggest updating in the (slightly) revised specs of remove() and replace() in the Specification section, but otherwise leaving them pretty much as they are, and not bothering with diffs for all the other tweaks I did. I'll generate a specdiff (internal tool, sorry, basically a structured HTML diff) and then post that to the CSR to provide a complete record of the changes.

-------------

PR: https://git.openjdk.org/jdk/pull/8259

From smarks at openjdk.org  Wed Oct  5 03:34:47 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 5 Oct 2022 03:34:47 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v10]
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <692vZWTJM4sXBNePspQmJv-rOTPey2xbAqIc7UisxsY=.4d5cb6d8-739f-417f-adb1-67a61a956121@github.com>

> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._

Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
 - Additional edits to Runtime and Thread specs.
 - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
 - Minor adjustments
 - Revise Implementation Note discussing JNI Invocation API.
 - Updates from Alan, David, and Alex.
 - More edits from Alex's suggestions.
 - More updates after discussion with Alex.
 - Updates after conversation with Alan:
   - specify that starting a shutdown hook explicitly has an unspecified
     effect on the shutdown sequence
   - link Thread class doc to shutdown sequence
   - link to Thread.UncaughtExceptionHandler
   - clarify that only live non-daemon threads are significant
   - use "thread termination" to conform to the text in the Thread class
   - adjust line breaks and whitespace
 - Additional wording changes to Runtime specs.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/c273feff...9fa2950d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9437/files
  - new: https://git.openjdk.org/jdk/pull/9437/files/ca369058..9fa2950d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9437&range=08-09

  Stats: 16840 lines in 388 files changed: 8252 ins; 7002 del; 1586 mod
  Patch: https://git.openjdk.org/jdk/pull/9437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9437/head:pull/9437

PR: https://git.openjdk.org/jdk/pull/9437

From duke at openjdk.org  Wed Oct  5 03:40:27 2022
From: duke at openjdk.org (liach)
Date: Wed, 5 Oct 2022 03:40:27 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v6]
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <Iz3MYWJPmJlwieCqNAkqV4SDz0V1f3Y1jnOM8Koq6Zo=.bdf6c8aa-c592-4136-a54b-11bd32da8e1e@github.com>

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

liach has updated the pull request incrementally with one additional commit since the last revision:

  Spec updates and clarifications.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8259/files
  - new: https://git.openjdk.org/jdk/pull/8259/files/fc2218f0..6874dc84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8259&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8259&range=04-05

  Stats: 33 lines in 1 file changed: 18 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/8259.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8259/head:pull/8259

PR: https://git.openjdk.org/jdk/pull/8259

From duke at openjdk.org  Wed Oct  5 03:53:17 2022
From: duke at openjdk.org (liach)
Date: Wed, 5 Oct 2022 03:53:17 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v6]
In-Reply-To: <Iz3MYWJPmJlwieCqNAkqV4SDz0V1f3Y1jnOM8Koq6Zo=.bdf6c8aa-c592-4136-a54b-11bd32da8e1e@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <Iz3MYWJPmJlwieCqNAkqV4SDz0V1f3Y1jnOM8Koq6Zo=.bdf6c8aa-c592-4136-a54b-11bd32da8e1e@github.com>
Message-ID: <0BFWr6RwkNNFNsXqQai6rY6lT9Spz8_1qJnX85v3kF0=.ddb2bc97-2a93-471a-934c-e2e45f1a2468@github.com>

On Wed, 5 Oct 2022 03:40:27 GMT, liach <duke at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec updates and clarifications.

I have updated the specification section of the CSR with the updated `remove` and `replace` spec (adding parentheses around equality expressions and replace "to" with "with") and pulled your branch.

-------------

PR: https://git.openjdk.org/jdk/pull/8259

From smarks at openjdk.org  Wed Oct  5 04:12:20 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 5 Oct 2022 04:12:20 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v10]
In-Reply-To: <692vZWTJM4sXBNePspQmJv-rOTPey2xbAqIc7UisxsY=.4d5cb6d8-739f-417f-adb1-67a61a956121@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <692vZWTJM4sXBNePspQmJv-rOTPey2xbAqIc7UisxsY=.4d5cb6d8-739f-417f-adb1-67a61a956121@github.com>
Message-ID: <NXkq1zaB4zLL9WC8kduSEOSXPnbjf9MqV0qRaMp_daA=.072252e2-a165-4d2c-92eb-91284bdc8600@github.com>

On Wed, 5 Oct 2022 03:34:47 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
>  - Additional edits to Runtime and Thread specs.
>  - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
>  - Minor adjustments
>  - Revise Implementation Note discussing JNI Invocation API.
>  - Updates from Alan, David, and Alex.
>  - More edits from Alex's suggestions.
>  - More updates after discussion with Alex.
>  - Updates after conversation with Alan:
>    - specify that starting a shutdown hook explicitly has an unspecified
>      effect on the shutdown sequence
>    - link Thread class doc to shutdown sequence
>    - link to Thread.UncaughtExceptionHandler
>    - clarify that only live non-daemon threads are significant
>    - use "thread termination" to conform to the text in the Thread class
>    - adjust line breaks and whitespace
>  - Additional wording changes to Runtime specs.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/fd88b65e...9fa2950d

CSR drafted, please review:

https://bugs.openjdk.org/browse/JDK-8294817

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From errael at raelity.com  Wed Oct  5 04:38:58 2022
From: errael at raelity.com (Ernie Rael)
Date: Tue, 4 Oct 2022 21:38:58 -0700
Subject: Sequenced Collections
In-Reply-To: <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
 <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
 <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>
 <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>
Message-ID: <d5f1c419-0eb5-6c98-2d9c-9dcc248f6db3@raelity.com>

Summary of key points (maybe the mail was TL;DR)

  * SequencedCollection methods addFirst,addLast are the only methods in
    Collection hierarchy (AFAIK) that might modify the collection and do
    not return/signal if the collection was modified. Seems like
    offerFirst,offerLast are more consistent with Collections and still
    avoid method proliferation.
  * With LinkedHashSet, seems like listIterator is missing. Rather than
    making that part of SequencedCollection, maybe an "interface
    ListIterable { ListIterator listIterator(int index); }". In addition
    to modification, bi-directional might also be optional, to support
    it's use with list equals.

-ernie

On 9/26/22 11:31 AM, Ernie Rael wrote:
> A SequencedCollection listIterator() is missed; it's useful for 
> List.equals, or to implement a List in general. LinkedHashSet seems 
> incomplete without it. Even something like "ListIterator 
> Collections.forwardListIterator(int index, iterator)", if compatible 
> with equals() of the various list types, would be handy. Doesn't 
> forward only work for sublist?. Only traversal, optional modification. 
> Modification is tricky; an add might have an implicit remove for a 
> Set. If not part of SequencedCollection, maybe "interface 
> ListIteratorProvider { ListIterator listIterator(int index); }" to tag 
> as needed.
>
> This message is primarily about "definition of change and equals" and 
> "pluggable eviction policy"; they're discussed through a simple MRU 
> example implemented with a SequencedSet and a capacity limit. The 
> 'changed' concept comes from Collection<>.
>
> // MRU implementation recommendations:
> //????? - implement List<> for equals
> //????? - modifications only permitted through direct MRU methods
> public interface MRU<E> extends Collection<E> {
> ??? boolean addItem(E key);??????? // return changed
> ??? boolean removeItem(E key);???? // remove(E) contract
> ??? boolean setCapacity(int size); // return changed
> ??? int getCapacity();
> ??? void clear();
> ??? boolean addAll(Collection< ? extends E> c);
> ??? public static <E> MRU<E> synchronizedMRU(MRU<E> mru) {...}
> }
>
> To check out SequencedCollection I sketched out an implementation of 
> MRU, see below. Currently I have two implementations based on 
> LinkedList and LinkedHashSet, each has some ugly stuff. The 
> implementation based on SequencedSet below is clean. All the MRU 
> methods are easily implemented without consideration of the actual 
> implementation, but AddAll() is problematic. removeItem() is included 
> to allow external EvictionPolicy.
>
> Is there a preferred direction for performance? I'm guessing the only 
> difference might be going through a "reversed()" view.
>
> Definition of "change" and "equals()" in a SequencedCollection
> ==============================================================
> The SequencedCollection uses "void addFirst(e)", there's no indication 
> if the collection is changed; this is the only place I'm aware of in 
> the Collections universe where a functional add operation does not 
> indicate changed when it may or may not change the collection (I 
> didn't look, just guessing). List and Set both have "changed" 
> consistent with their "equals()".
>
> Consistent with List equals, the MRU addItem() implementation returns 
> changed true if either sequence or content changed.
>
> The MRU implementation as shown may have an inaccurate return from 
> addAll(); it's possible that "changed == true && 
> before.equals(after)". Collection specifies the addAll() return. It's 
> expensive to produce an accurate result from addAll(). I suppose it 
> could be argued that the definition of changed is ambiguous in this 
> case. Document that AddAll() may return a false positive.
>
> Thinking out loud... In SequencedSet a method getChanged() returning 
> an EnumSet with SEQUENCE_CHANGED, CONTENTS_CHANGED bits. Could 
> automatically clear the bits on every operation or require an explicit 
> call to clear the bits. This wouldn't help the addAll() problem, but 
> supports a workaround for addFirst/addLast.
>
> pluggable Eviction Policy
> =========================
> In my earlier message, when I shifted to refer to an eviction policy, 
> I acknowledge that even a simple builtin policy was inappropriate. 
> While this thread may not be the best place to discuss it, I'll make 
> this comment here; can start another thread if there's reason.
>
> It's tricky to extend a Collection and implement an Eviction Policy 
> without support from the collection. For example, if there are several 
> ways to add to the collection, then in general each must be 
> intercepted and handled. It may be that simply overriding add(E) is 
> sufficient, but the source for the implementation must be examined for 
> each implementation and on every release.
>
> This suggests an "interface EvictionPolicy" (or EvictionPolicySupport) 
> which, at a minimum, is invoked whenever the collection's size 
> increases; could be invoked whenever the collection is modified. 
> Something like an optional setEvictionPolicy(ep), or solely by 
> implementation.
>
> MRU implementation example
> ==========================
>
> /** MRU SequenceSet implementation. Newest/mru at start of list */
> public abstract class AbstractMRU<E>
> extends AbstractSequentialList<E> implements MRU<E> {
> ??? protected final SequencedSet<E> seqset;
> ??? protected int capacity = Integer.MAX_VALUE;
>
> ??? public AbstractMRU(SequencedSet<E> c, int capacity) {
> ??????? this.seqset = c;
> ??????? setCapacity(capacity);
> ??? }
>
> ??? @Override public int size() { return seqset.size(); }
> ??? @Override public Iterator() { return seqset.iterator(); }
> ??? @Override public boolean addAll(Collection<? extends E> c) { 
> addAllInFront(c); }
> ??? @Override public void clear() { seqset.clear(); }
> ??? @Override public boolean addItem(E key) {
> ??????? if(key == null)
> ??????????? throw new IllegalArgExcept();
> ??????? if(Objects.equals(key, peekMRU())) return false; // no change
> ??????? seqset.addFirst(key);
> ??????? evict();
> ??????? return true; // must have changed since not early return
> ??? }
> ??? @Override public boolean removeItem(E key) { return 
> seqset.remove(key); }
>
> ??? @Override boolean setCapacity(int capacity) { // return changed
> ??????? if(capacity < 0)
> ??????????? throw new IllegalArgumentException("Size must be >= 0");
> ??????? this.capacity = capacity;
> ??????? return evict();
> ??? }
> ??? @Override public int getCapacity() { return capacity; }
>
> ??? protected E peekMRU() { return seqset.isEmpty ? null : 
> seqset.getFirst(); }
> ??? protected boolean evict() { // return true if size changed
> ??????? int extra = size() - capacity;
> ??????? if(extra <= 0)
> ??????????? return false;
> ??????? while(--extra >= 0) seqset.removeLast();
> ??????? return true;
> ??? }
> ??? protectd abstract boolean addAllInFront(Collection<? extends E> c);
> }
>
> /**
> ?* Newest at the front of the list (opposite of LinkedHashset defaults).
> ?* This is not dependent on how SeqSet is implemented,
> ?* but just put it down here to get the mess out of the way.
> ?*/
> public LinkedHashSetMRU<E> extends AbstractMRU<E> {
> ??? public LinkedHashSetMRU(int numElements) {
> super(LinkedHashSet.newLinkedHashSet<E>(numElements), numElements);
> ??? }
>
> ??? protected boolean addAllInFront(Collection<? extends E> c) {
> ??????? // TODO: check null item
> ??????? boolean modified;
> ??????? if(c instanceof SequencedCollection sq) {
> ??????????? for(e : sq.reversed())
> ??????????????? modified |= seqset.addFirst(e);
> ??????? } else {
> ??????????? // lazy
> ??????????? for(e : new ArrayList(c).reversed())
> ??????????????? modified |= seqset.addFirst(e);
> ??????? }
> ??????? return evict() || modified;
> ??? }
>
> ??? // TODO:??? implement ListIterator's iterator(index),
> ??? //????????? only forward iteration should be OK for equals.
> ??? // ListIterator listIterator(int index)
> ??? //???? { return Collections.forwardListIterator(index, 
> seqset.iterator()); }
>
> ??? // Could handle equals for both List,Set.
> ??? // Just List equals seems OK. Use MRU.containsAll directly for Set 
> equals.
> ??? @Override public boolean equals(Object o) {
> ??????? if (o == this)
> ??????????? return true;
> ??????? if (!(o instanceof List))
> ??????????? return false;
> ??????? Iterator<E> e1 = seqset.iterator();
> ??????? Iterator<?> e2 = ((List<?>) o).iterator();
> ??????? while (e1.hasNext() && e2.hasNext())
> ??????????? if(!Objects.equals(e1.next(), e2.next())
> ??????????????? return false;
> ??????? return !(e1.hasNext() || e2.hasNext());
> ??? }
> }
>
>
> On 9/21/22 5:38 PM, Stuart Marks wrote:
>> Hi, yes, this is the right place to discuss Sequenced Collections. 
>> I'm glad you find it promising.
>>
>> Note that Sequenced Collections actually has very little 
>> implementation in it, aside from various reversed views of things. 
>> The actual data is still stored in existing concrete collections such 
>> as ArrayList, ArrayDeque, LinkedHashMap, and TreeMap.
>>
>> I think Sequenced Collections has the right set of abstractions in it 
>> as it stands, and I don't want to expand its scope by talking about 
>> additional concepts like size limits or eviction policy.
>>
>> However, those things are quite reasonable to discuss independently 
>> of the current Sequenced Collections proposal. Having a maximum size 
>> on a collection seems independent of sequencing. An eviction policy 
>> *might* be based on the sequence, but it might not; consider the 
>> various eviction policies available for a cache library such as 
>> Caffeine [1].
>>
>> [1] https://github.com/ben-manes/caffeine/wiki
>>
>> However, I'm somewhat skeptical of trying to build things like 
>> eviction policies directly into collections. It's tempting to add a 
>> simple thing like a size and just throw away things in some 
>> well-defined order whenever the size is exceeded. The problem is that 
>> if this policy doesn't do *exactly* what you want to do, then you're 
>> out of luck.
>>
>> The current (pre Sequenced Collections) LinkedHashMap is a good 
>> example of this. It's suitable for a least-recently-inserted 
>> expiration policy; there's a method removeEldestEntry() that programs 
>> can use to implement a simple policy, size-based or otherwise. 
>> (Unfortunately they have to subclass-and-override, but whatever.) The 
>> problem is that it allows removal of only one element -- the eldest 
>> (first) element.
>>
>> If you want to change the policy of insertion order of an LHM, you 
>> have only one alternative: access order. Enabling this has some weird 
>> side effects though. For example, get() now rearranges the order of 
>> entries in the map, and is thus a structural modification -- which 
>> means that it spoils any iterators over the map's views.
>>
>> These are both fairly common cases, which is probably why they were 
>> added. But they're not very flexible, and if you want to do something 
>> slightly different, you're on your own -- and it's pretty hard to 
>> implement your own policy, because LHM lacks a bunch of essential 
>> operations.
>>
>> Where the Sequenced Collections proposal helps is that instead of 
>> adding more policies, it adds the missing primitive operations. You 
>> can add/get/remove at either end, and you can reposition mappings to 
>> either end. If you have some different recent-usage policy or some 
>> unusual cache eviction policy that I've never heard of, you can use 
>> the primitives to implement it yourself. That's much better than 
>> trying to bake a few more specific cases into LinkedHashMap or other 
>> collections.
>>
>>> Is there a discussion about making the SynchronizedCollection family 
>>> of classes public? 
>>
>> No. Synchronizing on every collection operation is the wrong level of 
>> abstraction. Typical collection usage involves too much external 
>> iteration and too much check-then-act logic. Callers would have to 
>> wrap those in synchronized blocks, and in general they don't know 
>> when that's necessary. Certain transaction-style operations (like 
>> Map::computeIfAbsent) can be made to work, but those are all pretty 
>> low level.
>>
>> s'marks
>>
>>
>>
>> On 9/21/22 9:32 AM, Ernie Rael wrote:
>>> ?> I don't see why you think a general collection...
>>>
>>> I thought the Subject would be sufficient to indicate that I was not 
>>> talking about collections in general. I should have been more 
>>> precise with my words; guess I was just excited by a bi-directional 
>>> ordered set.
>>>
>>> The MRU _example_ is useful; the current collections handle it 
>>> poorly and Sequenced Collections is ideal. Caches with an eviction 
>>> policy are common; I suspect caches will be a common use for 
>>> SequencedSet family. Note there are fixed sized Collections and 
>>> SequencedCollection borrows heavily from that family. Perhaps this 
>>> issue should be considered in the context of adding an **Eviction 
>>> Policy** to appropriate collections.
>>>
>>> MRU is a Collection; for example, I pass an MRU to a persistence 
>>> mechanism that takes a collection. Saying "all methods offered by 
>>> `Collection` should [not] even be part of an `MRU` interface" is 
>>> innacurate, especially when considered in the context of a 
>>> SequencedCollection.
>>>
>>> -ernie
>>>
>>> PS - Loosely related is extending a Collection and providing a 
>>> synchronized version. Is there a discussion about making the 
>>> SynchronizedCollection family of classes public?
>>>
>>>
>>> On 9/21/22 4:22 AM, John Hendrikx wrote:
>>>> I don't see why you think a general collection, that is in 99.9% of 
>>>> the cases not used to implement an MRU, should burden every call to 
>>>> #add with a check to see if it isn't exceeding its maximum size or 
>>>> to see if a maximum size has been set.
>>>>
>>>> This is much better done by composition, as I don't think all 
>>>> methods offered by `Collection` should even be part of an `MRU` 
>>>> interface.
>>>>
>>>> --John
>>>>
>>>> On 20/09/2022 21:08, Ernie Rael wrote:
>>>>> (There may be a better place to send this, let me know where)
>>>>>
>>>>> Suggesting an option to limit the size of the collection, e.g 
>>>>> "setMaxSize(int)", default of zero means no limit.
>>>>>
>>>>> I put together "interface MRU<E> extends Collection<E>" some 
>>>>> months ago, it has two implementations based on LinkedList and 
>>>>> LinkedHashSet. The code can be seen at 
>>>>> https://sourceforge.net/p/jvi/raelity-lib/ci/default/tree/lib/src/main/java/com/raelity/lib/ 
>>>>>
>>>>>
>>>>> A SequencedCollection, as outlined in the JEP draft 2020/09/01, 
>>>>> would be almost perfect to implement MRU; I've run into most of 
>>>>> the problems/issues discussed in the JEP draft.
>>>>>
>>>>> The MRU is a cache, as I use it; it typically has a max size for 
>>>>> the collection. Handling this natively in the collection would be 
>>>>> ideal; if an add operation would overflow, remove the item at the 
>>>>> other end. Note that addAll() is used when initializing from 
>>>>> backing store.
>>>>>
>>>>> FYI, I use a "Supplier<Integer>" to the constructor to provide 
>>>>> maxSize, but a property makes much more sense. I'll make that 
>>>>> change in MRU for sanity, and get rid of the trim() method. 
>>>>> setMaxSize can do the trim.
>>>>>
>>>>> -ernie
>>>>>
>>>>
>>>
>>
>
>


From ihse at openjdk.org  Wed Oct  5 05:59:48 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Oct 2022 05:59:48 GMT
Subject: Integrated: 8294376: Minimize disabled warnings in java.base
In-Reply-To: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
References: <R7_lfTjzEBkN-TAZxMd75nnuJ2_ZwAJfcqq-Z1Erhk0=.2aa5ecbd-14bb-4808-9087-21d084c77f8a@github.com>
Message-ID: <g68lvrSZDEifvYshvevs8EE828noJh7g86tkfUdmMPg=.652cd9d2-3de0-4b30-ba9b-b28477881329@github.com>

On Mon, 26 Sep 2022 15:31:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in java.base native libraries.
> 
> Any warnings that were only triggered in a few files were removed from the library as a whole, and changed to be only disabled for those files.
> 
> Some warnings didn't trigger in any file anymore, and could just be removed.

This pull request has now been integrated.

Changeset: 755958e5
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/755958e5ee40f83f3deb5c922d51e425e3bd412c
Stats:     26 lines in 2 files changed: 8 ins; 4 del; 14 mod

8294376: Minimize disabled warnings in java.base

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10426

From mbaesken at openjdk.org  Wed Oct  5 07:28:24 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Oct 2022 07:28:24 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v4]
In-Reply-To: <7BU8aR7BZe9YcZoXu2CsoZ8K6OKzJOkaze6yNvE_aCc=.7bc3d1a4-ed59-4535-aaa9-f0550584b8c9@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
 <7BU8aR7BZe9YcZoXu2CsoZ8K6OKzJOkaze6yNvE_aCc=.7bc3d1a4-ed59-4535-aaa9-f0550584b8c9@github.com>
Message-ID: <Pjbo9Y9N_HGZj-f7EKJOEoDo8jaJTqOyAZ0bPeKFizU=.9bbca48b-d7ea-46d9-9de4-a0cb70fb601f@github.com>

On Tue, 4 Oct 2022 18:26:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Looks good. Thanks for fixing this.

Thanks for the review !  Do I need a second review for those tools like in hotspot ?

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From alanb at openjdk.org  Wed Oct  5 07:34:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 07:34:23 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v4]
In-Reply-To: <Pjbo9Y9N_HGZj-f7EKJOEoDo8jaJTqOyAZ0bPeKFizU=.9bbca48b-d7ea-46d9-9de4-a0cb70fb601f@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
 <7BU8aR7BZe9YcZoXu2CsoZ8K6OKzJOkaze6yNvE_aCc=.7bc3d1a4-ed59-4535-aaa9-f0550584b8c9@github.com>
 <Pjbo9Y9N_HGZj-f7EKJOEoDo8jaJTqOyAZ0bPeKFizU=.9bbca48b-d7ea-46d9-9de4-a0cb70fb601f@github.com>
Message-ID: <_XPoxP-vq41eFoVUOxjjH7xeNaOCY7T3RsiUci1uk1k=.3fea2be9-3cfe-4442-b983-51c30104987d@github.com>

On Wed, 5 Oct 2022 07:24:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Looks good. Thanks for fixing this.
> 
> Thanks for the review ! Do I need a second review for those tools like in hotspot ?

One reviewer is okay here and Mandy is the expert on this tool. So I think you are good to go.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From mbaesken at openjdk.org  Wed Oct  5 07:38:30 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Oct 2022 07:38:30 GMT
Subject: Integrated: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present
In-Reply-To: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
Message-ID: <2uuAU_lqgrTjrw7wD1rKve3W7_tec4gh8svEXUnDn-g=.0ac41791-ecbe-44f1-9bde-8b58e5d4c30d@github.com>

On Fri, 16 Sep 2022 08:26:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
> 
> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
> 
> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
> Exception in thread "main" java.util.NoSuchElementException: No value present
>         at java.base/java.util.Optional.get(Optional.java:148)
>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> 
> So an additional  check might be a good idea.

This pull request has now been integrated.

Changeset: 953ce8da
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/953ce8da2c7ddd60b09a18c7875616a2477e5ba5
Stats:     268 lines in 8 files changed: 264 ins; 0 del; 4 mod

8293701: jdeps InverseDepsAnalyzer runs into NoSuchElementException: No value present

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From ihse at openjdk.org  Wed Oct  5 07:43:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 5 Oct 2022 07:43:19 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v8]
In-Reply-To: <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
 <IOhGRORrJpR6DLUZUsSzM6WleiMFX-IWLfdFSQeDD8Q=.e7433c0f-ddec-43a7-a1f5-19c30c50cc0b@github.com>
Message-ID: <VwPBSkgS79Le2mS0S-MK5Zsm49GZ3eIHj-M-yyHovZg=.219c7fcd-da16-4b54-b50f-6b203107fde2@github.com>

On Mon, 3 Oct 2022 20:37:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
>> 
>> Updates were made using a shell script. I"ll run a copyright updater before any push.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Update accessibility URLs.
>  - Merge branch 'master' into JDK-8294618
>  - Update make directory.
>  - Update doc directory files.
>  - Update hg URLs to git.
>  - Merge branch 'master' into JDK-8294618
>  - http -> https
>  - Undo manpage update.
>  - Update copyright.
>  - Revert unintended update to binary file.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/72d7bf5d...4055f1a6

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From alanb at openjdk.org  Wed Oct  5 07:50:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 07:50:45 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system
Message-ID: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>

This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.

-------------

Commit messages:
 - Make close idempotent
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10562/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10562&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291429
  Stats: 53 lines in 3 files changed: 47 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10562.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10562/head:pull/10562

PR: https://git.openjdk.org/jdk/pull/10562

From alanb at openjdk.org  Wed Oct  5 08:36:28 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 08:36:28 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v4]
In-Reply-To: <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
Message-ID: <P8R91aOWIeRCpiAAPVycbr22hk1gtjnVqAc3SW1TtLI=.f9c65c7e-31ce-492a-ad66-59be918631ed@github.com>

On Tue, 4 Oct 2022 08:00:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We noticed that with certain jar file input, jdeps runs into the following exception, this happens with jdk11, 17 and 20.
>> 
>> jdeps.exe --multi-release 11 --module-path . --inverse --package com.sap.nw.performance.supa.client test.jar
>> 
>> Inverse transitive dependences matching packages [com.sap.nw.performance.supa.client]
>> Exception in thread "main" java.util.NoSuchElementException: No value present
>>         at java.base/java.util.Optional.get(Optional.java:148)
>>         at jdk.jdeps/com.sun.tools.jdeps.InverseDepsAnalyzer.lambda$inverseDependences$2(InverseDepsAnalyzer.java:150)
>>         at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>         at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
>>         at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>         at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>> 
>> So an additional  check might be a good idea.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enhance test

test/langtools/tools/jdeps/optionalDependency/OptionalDependencyTest.java line 74:

> 72:     @Test
> 73:     public void optionalDependenceNotResolved() {
> 74:         JdepsRunner jdepsRunner = new JdepsRunner("--module-path", "m2.jar:m3.jar",

Just a heads-up that this test is failing in our CI because this needs to use File.pathSeparator rather than ":". Here's the exception:


test OptionalDependencyTest.optionalDependenceNotResolved(): failure
java.nio.file.InvalidPathException: Illegal char <:> at index 6: m2.jar:m3.jar
	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232)
	at java.base/java.nio.file.Path.of(Path.java:147)
	at java.base/java.nio.file.Paths.get(Paths.java:69)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.createModulePathFinder(JdepsConfiguration.java:582)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.appModulePath(JdepsConfiguration.java:473)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.buildConfig(JdepsTask.java:584)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:558)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:534)
	at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:65)
	at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:78)
	at JdepsRunner.run(JdepsRunner.java:68)
	at OptionalDependencyTest.optionalDependenceNotResolved(OptionalDependencyTest.java:77)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:93)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1588)

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From mbaesken at openjdk.org  Wed Oct  5 08:46:32 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Oct 2022 08:46:32 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v4]
In-Reply-To: <P8R91aOWIeRCpiAAPVycbr22hk1gtjnVqAc3SW1TtLI=.f9c65c7e-31ce-492a-ad66-59be918631ed@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
 <P8R91aOWIeRCpiAAPVycbr22hk1gtjnVqAc3SW1TtLI=.f9c65c7e-31ce-492a-ad66-59be918631ed@github.com>
Message-ID: <bEIaZ7SHN4huYeHO1y6GwoEifwI5qZQgj1zyYlj2nDo=.62b16d00-c6c9-490f-ae10-936f795f9967@github.com>

On Wed, 5 Oct 2022 08:33:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   enhance test
>
> test/langtools/tools/jdeps/optionalDependency/OptionalDependencyTest.java line 74:
> 
>> 72:     @Test
>> 73:     public void optionalDependenceNotResolved() {
>> 74:         JdepsRunner jdepsRunner = new JdepsRunner("--module-path", "m2.jar:m3.jar",
> 
> Just a heads-up that this test is failing in our CI because this needs to use File.pathSeparator rather than ":". Here's the exception:
> 
> 
> test OptionalDependencyTest.optionalDependenceNotResolved(): failure
> java.nio.file.InvalidPathException: Illegal char <:> at index 6: m2.jar:m3.jar
> 	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> 	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> 	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232)
> 	at java.base/java.nio.file.Path.of(Path.java:147)
> 	at java.base/java.nio.file.Paths.get(Paths.java:69)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.createModulePathFinder(JdepsConfiguration.java:582)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.appModulePath(JdepsConfiguration.java:473)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.buildConfig(JdepsTask.java:584)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:558)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:534)
> 	at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:65)
> 	at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:78)
> 	at JdepsRunner.run(JdepsRunner.java:68)
> 	at OptionalDependencyTest.optionalDependenceNotResolved(OptionalDependencyTest.java:77)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> 	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> 	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> 	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> 	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> 	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:764)
> 	at org.testng.TestRunner.run(TestRunner.java:585)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> 	at org.testng.TestNG.runSuites(TestNG.java:1069)
> 	at org.testng.TestNG.run(TestNG.java:1037)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:93)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:1588)

Hi Alan, thanks for the heads up. I created https://bugs.openjdk.org/browse/JDK-8294840 .

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From mbaesken at openjdk.org  Wed Oct  5 09:30:35 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Oct 2022 09:30:35 GMT
Subject: RFR: JDK-8294837: unify Windows 2019 version check in os_windows and
 java_props_md
Message-ID: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>

Currently the buildNumber check for Windows 2019 server differs in os_windows.cpp and java_props_md.c ( java_props_md.c still checks pre GA versions , this is probably not necessary any more ).
The check should be unified.

-------------

Commit messages:
 - unify Win 2019 build number check in os_windows.cpp and java_props_md.c

Changes: https://git.openjdk.org/jdk/pull/10570/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294837
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10570.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10570/head:pull/10570

PR: https://git.openjdk.org/jdk/pull/10570

From rgiulietti at openjdk.org  Wed Oct  5 10:02:49 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 10:02:49 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - 8294456: Fix misleading-indentation warnings in JDK
   
   Merge branch 'master' into JDK-8294456
 - 8294456: Fix misleading-indentation warnings in JDK

-------------

Changes: https://git.openjdk.org/jdk/pull/10487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=01
  Stats: 9 lines in 4 files changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10487.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10487/head:pull/10487

PR: https://git.openjdk.org/jdk/pull/10487

From rgiulietti at openjdk.org  Wed Oct  5 10:08:31 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 10:08:31 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <56bmZbja-KHTjSDqWCsX7s2RwGkpyWIDwGLBua1d5FA=.063111f6-4ad4-4508-9ae1-7e55a9810261@github.com>

On Wed, 5 Oct 2022 10:02:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

I had to solve a merge conflict after https://github.com/openjdk/jdk/pull/10426 was integrated.
I think my changes need another review on the conflicting file.

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From shade at openjdk.org  Wed Oct  5 10:20:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 10:20:33 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>

On Wed, 5 Oct 2022 10:02:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:

> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
> 298:         undef unused-function stringop-truncation, \

Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From jwaters at openjdk.org  Wed Oct  5 11:00:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 5 Oct 2022 11:00:16 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v11]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <d2btcWCgRfp4tbOTrizgK0heDfAb4DT8NkfQwacbuVk=.08e06133-0b68-4769-8333-9f47abc1f613@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
> 
> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-4
 - Make DLL_ERROR4 look a little better without changing what it means
 - Revert changes to JLI_ReportErrorMessageSys
 - Update java_md.c
 - Update java_md.h
 - Merge branch 'openjdk:master' into patch-4
 - Merge branch 'openjdk:master' into patch-4
 - Back out change to DLL_ERROR4 for separate RFE
 - Missing spacing between errors
 - Introduce warning when system error cannot be determined
 - ... and 3 more: https://git.openjdk.org/jdk/compare/32b83751...e7bef513

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/0a0b56eb..e7bef513

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=09-10

  Stats: 837 lines in 37 files changed: 462 ins; 259 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Wed Oct  5 11:03:41 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 5 Oct 2022 11:03:41 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v12]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <DKG8cJ_HHRREbs_Dvia4HP6ZP3klH-p5VDwCiFSN1zY=.17e42ec3-4743-41d3-9439-b53d43e2ac39@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
> 
> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Use - instead of : as a separator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/e7bef513..fb62a9a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=10-11

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Wed Oct  5 11:03:44 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 5 Oct 2022 11:03:44 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v11]
In-Reply-To: <d2btcWCgRfp4tbOTrizgK0heDfAb4DT8NkfQwacbuVk=.08e06133-0b68-4769-8333-9f47abc1f613@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <d2btcWCgRfp4tbOTrizgK0heDfAb4DT8NkfQwacbuVk=.08e06133-0b68-4769-8333-9f47abc1f613@github.com>
Message-ID: <7-AzrxeV4UIRSEZSD9MeAc5zyGZdxtGVuvq4_5cutoc=.a7869d62-7e70-455d-9a38-8eab21052f36@github.com>

On Wed, 5 Oct 2022 11:00:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-4
>  - Make DLL_ERROR4 look a little better without changing what it means
>  - Revert changes to JLI_ReportErrorMessageSys
>  - Update java_md.c
>  - Update java_md.h
>  - Merge branch 'openjdk:master' into patch-4
>  - Merge branch 'openjdk:master' into patch-4
>  - Back out change to DLL_ERROR4 for separate RFE
>  - Missing spacing between errors
>  - Introduce warning when system error cannot be determined
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/e9cb88a8...e7bef513

Minor change:
From
`Error: Could not load D:\Eclipse\Workspace\HotSpot\jdk\build\windows-x86_64-server-release\jdk\bin\server\jvm.dll: The specified module could not be found`
to
`Error: Could not load D:\Eclipse\Workspace\HotSpot\jdk\build\windows-x86_64-server-release\jdk\bin\server\jvm.dll - The specified module could not be found`

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From rgiulietti at openjdk.org  Wed Oct  5 12:03:22 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 12:03:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
Message-ID: <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>

On Wed, 5 Oct 2022 10:16:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - 8294456: Fix misleading-indentation warnings in JDK
>>    
>>    Merge branch 'master' into JDK-8294456
>>  - 8294456: Fix misleading-indentation warnings in JDK
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:
> 
>> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
>> 298:         undef unused-function stringop-truncation, \
> 
> Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.

What is the problem with Awt2d? Other conflicts?

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From shade at openjdk.org  Wed Oct  5 12:11:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 12:11:21 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
Message-ID: <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>

On Wed, 5 Oct 2022 12:01:00 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:
>> 
>>> 296:     HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>>> 297:     DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
>>> 298:         undef unused-function stringop-truncation, \
>> 
>> Ok, let's not touch this global warning and rename the issue to "Fix misleading-indentation warnings in core JDK libraries". Leave the Awt2d change to another day.
>
> What is the problem with Awt2d? Other conflicts?

I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From aivanov at openjdk.org  Wed Oct  5 13:27:29 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 13:27:29 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <PnxcaX4A0UPATWCWR6qBg7AHmu1d6spEkRYu5mpKFME=.e81f7c64-59d7-48a9-b74a-254af1cc1a18@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

Changes requested by aivanov (Reviewer).

src/hotspot/share/opto/memnode.cpp line 2365:

> 2363:   if (x != this)  return x;
> 2364: 
> 2365:   // Take apart the address into an oop and offset.

?and _an_ offset??

src/java.xml/share/classes/org/w3c/dom/Document.java line 293:

> 291:      * <code>systemId</code>, and <code>notationName</code> attributes are
> 292:      * copied. If a <code>deep</code> import is requested, the descendants
> 293:      * of the source <code>Entity</code> are recursively imported and

This class may come from a 3rd party library. Anyone from `java.xml` can confirm it?

test/hotspot/jtreg/vmTestbase/nsk/share/locks/DeadlockMaker.java line 31:

> 29: /*
> 30:  * Class used to create deadlocked threads. It is possible create 2 or more deadlocked thread, also
> 31:  * is possible to specify resource of which type should lock each deadlocked thread

Suggestion:

 * it is possible to specify resource of which type should lock each deadlocked thread

It doesn't sound right without _?it?_.

test/jdk/com/sun/jdi/connect/spi/GeneratedConnectors.java line 28:

> 26:  * @summary Unit test for "Pluggable Connectors and Transports" feature.
> 27:  *
> 28:  * When a transport service is deployed the virtual machine

Suggestion:

 * When a transport service is deployed, the virtual machine

Let's add a comma for clarity.

test/jdk/java/security/testlibrary/SimpleOCSPServer.java line 445:

> 443: 
> 444:     /**
> 445:      * Check the status database for revocation information on one or more

Suggestion:

     * Check the status database for revocation information of one or more

test/jdk/sun/jvmstat/testlibrary/utils.sh line 181:

> 179:         if [ $? -eq 0 ]
> 180:         then
> 181:             # it's still lingering, now it is hard

Suggestion:

            # it's still lingering, now hit it hard

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From rgiulietti at openjdk.org  Wed Oct  5 13:50:23 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 13:50:23 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
 <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
Message-ID: <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>

On Wed, 5 Oct 2022 12:07:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> What is the problem with Awt2d? Other conflicts?
>
> I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.

Awt2dLibraries.gmk in https://github.com/openjdk/jdk/pull/10453 seems more about clang if I'm not mistaken, while this change is about gcc.
The JDK successfully builds on several platforms with this change.

What else could go wrong? I'm asking because I'm not a build engineering expert at all.

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From shade at openjdk.org  Wed Oct  5 13:54:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 13:54:10 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in JDK [v2]
In-Reply-To: <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
 <LhmYvUkg786sWFBhYRIew2felVmcThp2M1tAfsQENtQ=.a4ea41ea-8f6a-4eb4-8d8f-7cb03807a306@github.com>
 <1UQyX79zIVU7mGxkOTSULe7S7DZNDUjOy6NPnSP8V1c=.ddb4d2f9-f784-4fe2-9eb1-bb29349ecb55@github.com>
 <c7hWjn16Z60UOPEWegOIMbAk8RkWYbNvV_gEoPLbwZU=.8bf3e6e6-5fbd-4d3d-9662-b5e099ff6a89@github.com>
 <-dZ60_xB0xnIsH6YI7kFMQgtyaeLyYn60Ik0aK4ctzE=.66561a3c-2f68-40a2-a256-3f30b66ff444@github.com>
Message-ID: <0vEUzzox7stDb-K4l3Tlj3p5dyUDCKYcm3LcJC9DAd0=.1d0d5f0b-ec4e-40d0-9e6f-7ffae1e9d875@github.com>

On Wed, 5 Oct 2022 13:46:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I am not completely sure all `misleading-indentation` warnings are fixed in Awt2d, this would require some more testing. I'd defer that to #10453.
>
> Awt2dLibraries.gmk in https://github.com/openjdk/jdk/pull/10453 seems more about clang if I'm not mistaken, while this change is about gcc.
> The JDK successfully builds on several platforms with this change.
> 
> What else could go wrong? I'm asking because I'm not a build engineering expert at all.

This could fail the build on some toolchains. Cleanliness and least surprise: this PR changes the particular files, and so it should remove the warnings for those specific files.

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From rgiulietti at openjdk.org  Wed Oct  5 14:06:21 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 14:06:21 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v3]
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8294456: Fix misleading-indentation warnings in JDK

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10487/files
  - new: https://git.openjdk.org/jdk/pull/10487/files/4581b7dd..7b455e5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10487&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10487.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10487/head:pull/10487

PR: https://git.openjdk.org/jdk/pull/10487

From rgiulietti at openjdk.org  Wed Oct  5 14:06:24 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Oct 2022 14:06:24 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v2]
In-Reply-To: <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <7giapr_DpXaQA6Y8-_wOpgpeFoxE_HlUWemRVVUapD8=.2d98a8d1-1802-4cda-9936-9c4eefd0f1d0@github.com>
Message-ID: <jdqZWOfEPFZIDV15uRNw-D7L7OUcQLJG2D1V26WOGZw=.a9bd1fcc-ab7e-445f-9878-998a7150fd13@github.com>

On Wed, 5 Oct 2022 10:02:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8294456: Fix misleading-indentation warnings in JDK
>    
>    Merge branch 'master' into JDK-8294456
>  - 8294456: Fix misleading-indentation warnings in JDK

Restored `misleading-indentation` warning in `Awt2dLibraries.gmk`

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From alanb at openjdk.org  Wed Oct  5 14:14:27 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 14:14:27 GMT
Subject: RFR: JDK-8294837: unify Windows 2019 version check in os_windows
 and java_props_md
In-Reply-To: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
References: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
Message-ID: <ROu0JhO0Tf8bFbS-22IzEGs-VG8pz1q4oUrgFi_kmM0=.45620b5c-0493-4987-b470-56c5f1d9cf22@github.com>

On Wed, 5 Oct 2022 09:21:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the buildNumber check for Windows 2019 server differs in os_windows.cpp and java_props_md.c ( java_props_md.c still checks pre GA versions , this is probably not necessary any more ).
> The check should be unified.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10570

From aivanov at openjdk.org  Wed Oct  5 14:17:13 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Oct 2022 14:17:13 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <VFoXow0glQ610il1bDU1a3KC6dP3S7cxr63T2tRJRZE=.46f798ba-af7c-4aea-9ca8-ce706658b5cc@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

I agree with everyone who said the PR should be broken to smaller pieces so that it touches code / tests in one or two packages, modules. It would be easier to review, you would need to get an approval from reviewers in a one or two specific areas. At this time, this PR touches files in 11 areas according the number of labels which correspond to a specific mailing list where discussions for the area are held.

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From rriggs at openjdk.org  Wed Oct  5 14:38:20 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Oct 2022 14:38:20 GMT
Subject: RFR: JDK-8294837: unify Windows 2019 version check in os_windows
 and java_props_md
In-Reply-To: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
References: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
Message-ID: <LegqQPtfnN94XLyXVU47VrPgUPGIrkRiQE2ayu432BQ=.cb2943e7-d1c7-4c1b-b5a8-ca3c57e20781@github.com>

On Wed, 5 Oct 2022 09:21:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the buildNumber check for Windows 2019 server differs in os_windows.cpp and java_props_md.c ( java_props_md.c still checks pre GA versions , this is probably not necessary any more ).
> The check should be unified.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10570

From mbaesken at openjdk.org  Wed Oct  5 14:45:23 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Oct 2022 14:45:23 GMT
Subject: Integrated: JDK-8294840: langtools OptionalDependencyTest.java use
 File.pathSeparator
In-Reply-To: <mrKDltO_UimBy50cTpIBQz3h4Ta5LvGMfUbXi9Wcyw4=.44c5efdb-b10a-4402-b740-50e0a442763d@github.com>
References: <mrKDltO_UimBy50cTpIBQz3h4Ta5LvGMfUbXi9Wcyw4=.44c5efdb-b10a-4402-b740-50e0a442763d@github.com>
Message-ID: <XHoG2I4P4Z7LxM4m1Dgxt0LUiki8BEr69SltWlqsCgg=.ea07930f-bcf4-4889-b207-f856c8932453@github.com>

On Wed, 5 Oct 2022 11:01:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test/langtools/tools/jdeps/optionalDependency/OptionalDependencyTest.java:
> introduced with 8293701 needs to use File.pathSeparator instead of ":" to work on all platforms.

This pull request has now been integrated.

Changeset: f531dae4
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f531dae4a0ffd2a5663cf4a4bde581d68fc728d5
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8294840: langtools OptionalDependencyTest.java use File.pathSeparator

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10572

From shade at openjdk.org  Wed Oct  5 15:05:22 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 15:05:22 GMT
Subject: RFR: 8294456: Fix misleading-indentation warnings in core JDK
 libraries [v3]
In-Reply-To: <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
 <61eXki6R0QjODAaLPVm1PrjNlPD5LCjbvzeG9Iz12o8=.8f33b181-7ced-4ed8-bdd2-037e43fa56ec@github.com>
Message-ID: <kASsj6bokAL0NZ2yQiugQbCEYx9nS6Y8DhMkTqyIZdo=.f4e6c2c7-0173-4ac0-a0fb-de0628e79255@github.com>

On Wed, 5 Oct 2022 14:06:21 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8294456: Fix misleading-indentation warnings in JDK

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From duke at openjdk.org  Wed Oct  5 15:26:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 5 Oct 2022 15:26:28 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v4]
In-Reply-To: <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
Message-ID: <aPNNK94Vi7YNvHRZvUWVnJSmfq0RBnygUEKsOmDk9FA=.3fa2208c-04cd-4da4-919f-36e124f50ca2@github.com>

On Mon, 29 Aug 2022 08:46:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
>> 
>> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = in.read();
>>     int ch2 = in.read();
>>     int ch3 = in.read();
>>     int ch4 = in.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>         throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
>> 
>> Benchmarking:
>> 
>> baseline:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
>> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
>> 
>> patch:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
>> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8292698: Reuse existing code
>  - Merge branch 'master' into 8292698
>  - 8292698: Fix copyright year
>  - 8292698: Revert dubious changes
>  - 8292698: Improve performance of reading from DataInputStream

Anyone to sponsor, or should I get more approves?

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From alanb at openjdk.org  Wed Oct  5 15:27:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 15:27:05 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread") from
 tests
Message-ID: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>

This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10577/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10577&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293810
  Stats: 52 lines in 6 files changed: 0 ins; 51 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10577.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10577/head:pull/10577

PR: https://git.openjdk.org/jdk/pull/10577

From alanb at openjdk.org  Wed Oct  5 15:27:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 15:27:10 GMT
Subject: RFR: 8294697: java/lang/Thread/virtual/ThreadAPI.testGetStackTrace2
 failed with non-empty stack trace
Message-ID: <WEYx8PgPO6fUu85mAAN90JoC3j2rl0nHdcKivQM65B0=.c4eb27ff-28cf-4914-9601-72b0afe9ac1e@github.com>

This is a test-only change. ThreadAPI.testGetStackTrace2 tests the stack trace of a virtual thread that has started but has not executed it. The test currently attempts to saturate all carrier threads before starting a target thread. The test is not reliable and failed at least once with a debug build and -Xcomp. The test is changed to use a custom scheduler that discards the task so the thread doesn't execute. The resulting test is much simpler and removes 3s from the execution time.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10576/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10576&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294697
  Stats: 36 lines in 1 file changed: 0 ins; 30 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10576.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10576/head:pull/10576

PR: https://git.openjdk.org/jdk/pull/10576

From aefimov at openjdk.org  Wed Oct  5 15:32:45 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 5 Oct 2022 15:32:45 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory
 filters to JNDI implementation
Message-ID: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>

### Summary of the change
This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 

These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.

The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.

Links:

- [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
- [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)

### List of code changes

- Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
- `java.security` and `module-info.java` files have been updated with a documentation for the new properties
- To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.

#### NamingManagerHelper changes
Changes performed to construct the `NamingManagerHelper` class:
- `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
- `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.


### Test changes
New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
- LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
- RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 

### Testing
tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
No failures observed for the modified regression tests.

-------------

Commit messages:
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

Changes: https://git.openjdk.org/jdk/pull/10578/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290368
  Stats: 1446 lines in 22 files changed: 1099 ins; 303 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From dfuchs at openjdk.org  Wed Oct  5 15:45:13 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Oct 2022 15:45:13 GMT
Subject: RFR: 8294697:
 java/lang/Thread/virtual/ThreadAPI.testGetStackTrace2 failed with non-empty
 stack trace
In-Reply-To: <WEYx8PgPO6fUu85mAAN90JoC3j2rl0nHdcKivQM65B0=.c4eb27ff-28cf-4914-9601-72b0afe9ac1e@github.com>
References: <WEYx8PgPO6fUu85mAAN90JoC3j2rl0nHdcKivQM65B0=.c4eb27ff-28cf-4914-9601-72b0afe9ac1e@github.com>
Message-ID: <CwUo73lUjLAoQLoGH49sXtkyeKtHTCCr-ZSCmz2RHy8=.3f232ed9-9d66-4dea-b6bc-e9b098202ede@github.com>

On Wed, 5 Oct 2022 14:05:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only change. ThreadAPI.testGetStackTrace2 tests the stack trace of a virtual thread that has started but has not executed it. The test currently attempts to saturate all carrier threads before starting a target thread. The test is not reliable and failed at least once with a debug build and -Xcomp. The test is changed to use a custom scheduler that discards the task so the thread doesn't execute. The resulting test is much simpler and removes 3s from the execution time.

This looks reasonable to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10576

From dfuchs at openjdk.org  Wed Oct  5 15:51:04 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Oct 2022 15:51:04 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <3kAWQXlRXyCRqCR-ocy_VaXCQls5ozpMLjGj0-Z4kH0=.674a358d-a544-449c-8d9d-b0a60a2f5a40@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

Changes to java.net and javax.management look fine to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10577

From stuart.marks at oracle.com  Wed Oct  5 16:34:07 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 5 Oct 2022 09:34:07 -0700
Subject: Sequenced Collections
In-Reply-To: <d5f1c419-0eb5-6c98-2d9c-9dcc248f6db3@raelity.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
 <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
 <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>
 <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>
 <d5f1c419-0eb5-6c98-2d9c-9dcc248f6db3@raelity.com>
Message-ID: <62bf9d22-0ea2-10b9-fabf-78c0d68a880a@oracle.com>



On 10/4/22 9:38 PM, Ernie Rael wrote:
> Summary of key points (maybe the mail was TL;DR)

OK thanks, I was still mulling over the previous email wondering which parts were 
significant enough to reply to.

>  ?* SequencedCollection methods addFirst,addLast are the only methods in
>  ?? Collection hierarchy (AFAIK) that might modify the collection and do
>  ?? not return/signal if the collection was modified. Seems like
>  ?? offerFirst,offerLast are more consistent with Collections and still
>  ?? avoid method proliferation.

The problem is that the boolean return values from add() and from offerX() mean 
different things, and having them be adjacent on List would be confusing. (Yes, 
they're both present on Deque, which is one of the reasons Deque is too 
complicated.) And we couldn't adjust the semantics of SequencedCollection.offerX() 
to match add(), as that would clash with the existing semantics on Deque.

 From your other messages it seems like you want the boolean return value in order 
to keep track of whether the collection changed such that it affects equals() and 
hashCode(). There are other methods that might modify collections where you can't 
tell whether they actually modified the collection; consider Collection::clear or 
List::replaceAll. So I don't think the boolean return value from add/offer is really 
buying you all that much.

>  ?* With LinkedHashSet, seems like listIterator is missing. Rather than
>  ?? making that part of SequencedCollection, maybe an "interface
>  ?? ListIterable { ListIterator listIterator(int index); }". In addition
>  ?? to modification, bi-directional might also be optional, to support
>  ?? it's use with list equals.

ListIterator has indexes and so it's pretty much tied to List. Maybe what you're 
missing from LinkedHashSet is the ability to insert or reposition an element 
somewhere in the middle? This is certainly a valid use case, but it's quite rare, 
and I'm not sure I'd want to support it using an Iterator style mechanism anyway.

Surveying the usages of ListIterator, I found that it's mainly used for iteration in 
reverse, and secondarily for replacing all the elements of a List (somewhat 
supplanted by replaceAll). We did run into one case where ListIterator was used to 
edit items within a list but it turned out to be INCREDIBLY clumsy to use. So if we 
want to support that (fairly rare) use case, I wouldn't start with a ListIterator or 
some variant with indexes removed. I'd also want to see use cases before considering 
adding new mechanisms.

s'marks

From mullan at openjdk.org  Wed Oct  5 16:35:19 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Oct 2022 16:35:19 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <jiHt2B8xjKmpyAYrlhu-PNEEjHyN0fZK03etrAJfkDY=.66486cb1-1776-4295-aa3c-b7aa9426b011@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10577

From darcy at openjdk.org  Wed Oct  5 16:39:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:39:32 GMT
Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v9]
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <T3sWlUnikg_EsuKqJ5PFiXj8IDAbk0fYG-WR3iLLvTw=.19912185-605f-4201-8022-0ffb7e00342d@github.com>

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8294618
 - Update accessibility URLs.
 - Merge branch 'master' into JDK-8294618
 - Update make directory.
 - Update doc directory files.
 - Update hg URLs to git.
 - Merge branch 'master' into JDK-8294618
 - http -> https
 - Undo manpage update.
 - Update copyright.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8aa24fec...eba2bd4b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10501/files
  - new: https://git.openjdk.org/jdk/pull/10501/files/4055f1a6..eba2bd4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=07-08

  Stats: 1452 lines in 87 files changed: 912 ins; 312 del; 228 mod
  Patch: https://git.openjdk.org/jdk/pull/10501.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501

PR: https://git.openjdk.org/jdk/pull/10501

From jwaters at openjdk.org  Wed Oct  5 16:40:16 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 5 Oct 2022 16:40:16 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v13]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <8nmAhTC5tubNWCLn89kWO4hQaP9ILZvgkx1ZtqMS9yY=.c794b8f4-0e50-472b-9c9a-993a2b24d8d2@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
> 
> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-4
 - Use - instead of : as a separator
 - Merge branch 'openjdk:master' into patch-4
 - Make DLL_ERROR4 look a little better without changing what it means
 - Revert changes to JLI_ReportErrorMessageSys
 - Update java_md.c
 - Update java_md.h
 - Merge branch 'openjdk:master' into patch-4
 - Merge branch 'openjdk:master' into patch-4
 - Back out change to DLL_ERROR4 for separate RFE
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8365afd1...aadf6275

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/fb62a9a9..aadf6275

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=11-12

  Stats: 131 lines in 21 files changed: 58 ins; 32 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From darcy at openjdk.org  Wed Oct  5 16:52:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 5 Oct 2022 16:52:27 GMT
Subject: Integrated: JDK-8294618: Update openjdk.java.net => openjdk.org
In-Reply-To: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
References: <y6aytrnr0lnKYroOFuSfx9wfJRKbdZqh2j_Gz-Wx-I0=.0b7ae14a-c0c6-45ff-be27-62a3fa13a7df@github.com>
Message-ID: <vtc6z3XjCCr9yLV3usCQemL0opkJB2S_3H8IZGWwD_A=.7c03befe-b74b-48e0-ad2d-3594d6ebc1b5@github.com>

On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated.
> 
> Updates were made using a shell script. I"ll run a copyright updater before any push.

This pull request has now been integrated.

Changeset: 536c9a51
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/536c9a512ea90d97a1ae5310453410d55db98bdd
Stats:     128 lines in 45 files changed: 0 ins; 0 del; 128 mod

8294618: Update openjdk.java.net => openjdk.org

Reviewed-by: mikael, iris, joehw, prr, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/10501

From naoto at openjdk.org  Wed Oct  5 16:56:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Oct 2022 16:56:20 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code
In-Reply-To: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
Message-ID: <itIE_NOK617w5AreAgxmW6MeAgGhhKgZvMQQCbZhQPc=.8dfaba77-263b-4502-ac1e-c0fe87323e6e@github.com>

On Tue, 4 Oct 2022 23:11:57 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.

Looks good to me. Since you are only modifying the comments, please add `noreg-doc` label to the JIRA issue.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10567

From mchung at openjdk.org  Wed Oct  5 17:02:30 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Oct 2022 17:02:30 GMT
Subject: RFR: JDK-8293701: jdeps InverseDepsAnalyzer runs into
 NoSuchElementException: No value present [v4]
In-Reply-To: <P8R91aOWIeRCpiAAPVycbr22hk1gtjnVqAc3SW1TtLI=.f9c65c7e-31ce-492a-ad66-59be918631ed@github.com>
References: <MT-F_Hc-QkWhMeh9eIK6PGLC1OVCNCqZAK5PHSdc2VY=.d49562dd-363e-40a9-91a7-77ce06608a3d@github.com>
 <163i8wMx7dhVczAEPtQXDvCVYQtG8BTsirisE-WM36Y=.b824c6c4-ef84-4aa1-93a6-c33bf0b11541@github.com>
 <P8R91aOWIeRCpiAAPVycbr22hk1gtjnVqAc3SW1TtLI=.f9c65c7e-31ce-492a-ad66-59be918631ed@github.com>
Message-ID: <X8-il7Yqu5F_6lKtUNrpBFuroHcGmLH2uWtx78RjWkM=.ad403319-8454-4c8a-99c4-a922156cdd45@github.com>

On Wed, 5 Oct 2022 08:33:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   enhance test
>
> test/langtools/tools/jdeps/optionalDependency/OptionalDependencyTest.java line 74:
> 
>> 72:     @Test
>> 73:     public void optionalDependenceNotResolved() {
>> 74:         JdepsRunner jdepsRunner = new JdepsRunner("--module-path", "m2.jar:m3.jar",
> 
> Just a heads-up that this test is failing in our CI because this needs to use File.pathSeparator rather than ":". Here's the exception:
> 
> 
> test OptionalDependencyTest.optionalDependenceNotResolved(): failure
> java.nio.file.InvalidPathException: Illegal char <:> at index 6: m2.jar:m3.jar
> 	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> 	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> 	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232)
> 	at java.base/java.nio.file.Path.of(Path.java:147)
> 	at java.base/java.nio.file.Paths.get(Paths.java:69)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.createModulePathFinder(JdepsConfiguration.java:582)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.appModulePath(JdepsConfiguration.java:473)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.buildConfig(JdepsTask.java:584)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:558)
> 	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:534)
> 	at jdk.jdeps/com.sun.tools.jdeps.Main.run(Main.java:65)
> 	at jdk.jdeps/com.sun.tools.jdeps.Main$JDepsToolProvider.run(Main.java:78)
> 	at JdepsRunner.run(JdepsRunner.java:68)
> 	at OptionalDependencyTest.optionalDependenceNotResolved(OptionalDependencyTest.java:77)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> 	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> 	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> 	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> 	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> 	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:764)
> 	at org.testng.TestRunner.run(TestRunner.java:585)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> 	at org.testng.TestNG.runSuites(TestNG.java:1069)
> 	at org.testng.TestNG.run(TestNG.java:1037)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:93)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:1588)

@AlanBateman thanks for reporting this.  Sorry I missed this from my review.

-------------

PR: https://git.openjdk.org/jdk/pull/10300

From smarks at openjdk.org  Wed Oct  5 18:11:29 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 5 Oct 2022 18:11:29 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v6]
In-Reply-To: <Iz3MYWJPmJlwieCqNAkqV4SDz0V1f3Y1jnOM8Koq6Zo=.bdf6c8aa-c592-4136-a54b-11bd32da8e1e@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <Iz3MYWJPmJlwieCqNAkqV4SDz0V1f3Y1jnOM8Koq6Zo=.bdf6c8aa-c592-4136-a54b-11bd32da8e1e@github.com>
Message-ID: <3aMAiap7sQe4e8ovyA7TWJROgMlKbzcThReZQkNATqg=.808e501b-9cdc-4e7d-984d-ceebae841b4f@github.com>

On Wed, 5 Oct 2022 03:40:27 GMT, liach <duke at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec updates and clarifications.

OK, thanks for the updates. I've attached a specdiff and have tweaked the CSR in a few places and I've marked it reviewed. Go ahead and mark it Finalized.

(I could actually do this myself, but I'd have to reassign the CSR to myself, make it Finalized, then reassign it back to you. That would save a messaging round-trip, but it would generate more notification spam. Plus I figured I'd give you the pleasure of hitting the **Finalize** button. :-D )

-------------

PR: https://git.openjdk.org/jdk/pull/8259

From bhuang at openjdk.org  Wed Oct  5 18:22:00 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 5 Oct 2022 18:22:00 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling
In-Reply-To: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
Message-ID: <9Sx_NY_p64qT2Y6zaAfFlpwM9nCGsFdbbucUcgiJZe0=.f498e85c-b67f-4165-8849-b2e7f3128302@github.com>

On Tue, 4 Oct 2022 13:01:40 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Added test cases for xpath Axis:
> 1. descendant
> 2. descendant-or-self
> 3. following
> 4. following-sibling

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpDescendantTest.java line 59:

> 57:                 {"/Customers/Customer[@id='x1']/descendant::Address", "/Customers/Customer[@id='x1']/Address"},
> 58:                 {"/Customers/Customer[@id='x1']/descendant::*", "/Customers/Customer[@id='x1']//*"},
> 59:                 {"/Customers/foo:Customer/foo:Address/descendant::*", "/Customers/foo:Customer/foo:Address//*"},

It would be good to add a test case to address the grandchildren or grand-grandchildren nodes from the context node. e.g.
`/Customers/descendant::Street`
`/Customers//Street`

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpDescendantTest.java line 65:

> 63:                 {"/Customers/Customer[@id='x1']/descendant-or-self::Address", "/Customers/Customer[@id = 'x1']/Address"},
> 64:                 {"/Customers/Customer[@id='x1']/descendant-or-self::*", "/Customers/Customer[@id='x1'] | /Customers/Customer[@id = 'x1']//*"},
> 65:                 {"/Customers/foo:Customer/foo:Address/descendant-or-self::*", "/Customers/foo:Customer/foo:Address | /Customers/foo:Customer/foo:Address//*"}

In the spec, there is a special note saying, "the location path //para[1] does not mean the same as the location path /descendant::para[1]". Based on this, it would be good to add a position test case for descendant. e.g.
`/Customers/descendant::Street[2]`
`/Customers/descendant::Street[position()=2]`
`//Street[2]`
`(//Street)[2]`

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpDescendantTest.java line 108:

> 106:         };
> 107:     }
> 108: 

It would be good to have a predicate test with descendant. e.g.
`//*[not(descendant::*)]`
`//*[descendant::Street and ancestor::Customer]`

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFollowingTest.java line 56:

> 54:                 {"/Customers/Customer[@id='x1']/following::Address", "/Customers/Customer[@id != 'x1']/Address"},
> 55:                 {"/Customers/Customer[@id='x1']/following::*", "/Customers/Customer[@id != 'x1']/descendant-or-self::* | /Customers/foo:Customer/descendant-or-self::*"},
> 56:                 {"/Customers/foo:Customer/foo:Address/following::*", "/Customers/foo:Customer/foo:Age | /Customers/foo:Customer/foo:ClubMember"},

It would be good to access the grandchildren or grand-grandchildren following nodes. e.g.
`//Customer/following::Street`
`//following::Street`

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFollowingTest.java line 64:

> 62:                 {"/Customers/Customer[@id='x1']/following-sibling::*", "/Customers/Customer[@id != 'x1'] | /Customers/foo:Customer"},
> 63:                 {"/Customers/foo:Customer/foo:Address/following-sibling::*", "/Customers/foo:Customer/foo:Age | /Customers/foo:Customer/foo:ClubMember"}
> 64:         };

It would be good to add a position test. e.g.
`//Customer/following::Street[2]`
`//following::Street[2]`
`//Customer/following-sibling::Customer[2]`
`//following-sibling::Customer[2]`

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFollowingTest.java line 108:

> 106:         };
> 107:     }
> 108: 

It would be good to add a predicate test for following. e.g.
`//foo:Customer/*[not(following::*)]`
`//*[not(following::*) and not(preceding::*)]`
`//Street[following::Street and preceding::Street]`

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From bhuang at openjdk.org  Wed Oct  5 18:22:02 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 5 Oct 2022 18:22:02 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling
In-Reply-To: <9Sx_NY_p64qT2Y6zaAfFlpwM9nCGsFdbbucUcgiJZe0=.f498e85c-b67f-4165-8849-b2e7f3128302@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
 <9Sx_NY_p64qT2Y6zaAfFlpwM9nCGsFdbbucUcgiJZe0=.f498e85c-b67f-4165-8849-b2e7f3128302@github.com>
Message-ID: <CtGU2-fCT8aVwqN-eKX6-5gVclNMVwqaVkiOL_wjQu0=.610d51f2-442d-4fcc-b002-a7f58fe5f138@github.com>

On Wed, 5 Oct 2022 18:09:53 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> Added test cases for xpath Axis:
>> 1. descendant
>> 2. descendant-or-self
>> 3. following
>> 4. following-sibling
>
> test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFollowingTest.java line 108:
> 
>> 106:         };
>> 107:     }
>> 108: 
> 
> It would be good to add a predicate test for following. e.g.
> `//foo:Customer/*[not(following::*)]`
> `//*[not(following::*) and not(preceding::*)]`
> `//Street[following::Street and preceding::Street]`

Also good for following-sibling.

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From naoto at openjdk.org  Wed Oct  5 18:35:25 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Oct 2022 18:35:25 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code
In-Reply-To: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
Message-ID: <Gu3dO0axi4-g47ibsoGBx1bs_1UfSsQhRCA_exJKPwQ=.fa1c9744-380a-4630-b4eb-a9ea1dfff65d@github.com>

On Tue, 4 Oct 2022 23:11:57 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.

Turned out that the comment was not aligning with the behavior of `Double.parseDouble("")`, as it throws `NumberFormatException` (Thanks to @LanceAndersen who let me know). So how about changing it to:

If (count == 0) this returns 0.0, unlike Double.parseDouble("") which throws NumberFormatException

It also applies to `getLong()`, and you may want to add comments `getBigDecimal()` for consistency with other `getXXX()` methods (without "unlike ..." part though).

-------------

PR: https://git.openjdk.org/jdk/pull/10567

From mchung at openjdk.org  Wed Oct  5 18:42:25 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 5 Oct 2022 18:42:25 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <83iSGxB9O0_LEGHtSUf0AsrmJohOpOfVgI8ZpCs-NxQ=.1bc56ba2-eecd-492a-8d58-d2fed72a4f76@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10577

From duke at openjdk.org  Wed Oct  5 18:47:30 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 5 Oct 2022 18:47:30 GMT
Subject: Integrated: 8294397: Replace StringBuffer with StringBuilder within
 java.text
In-Reply-To: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
References: <sOCGzVnab45zx25vTpf0Gxsra6mkMFld3P3FvkrWWNs=.01dd3e30-e18b-4c8c-b478-5c2d00f4ec24@github.com>
Message-ID: <JCvnP2YV6bKf4sudLPtCtdpUEV67d93eDfHxvI-xGEY=.eebff242-4353-4617-bc40-b2b7c8dee4cc@github.com>

On Wed, 28 Sep 2022 22:54:33 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unnecessary instances of StringBuffer within java.text (internal only)
> 
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method names

This pull request has now been integrated.

Changeset: 87acfee3
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87acfee3c3e8dbc36b87e449f69fda6fca0088f6
Stats:     90 lines in 7 files changed: 10 ins; 35 del; 45 mod

8294397: Replace StringBuffer with StringBuilder within java.text

Reviewed-by: lancea, naoto, bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/10475

From cjplummer at openjdk.org  Wed Oct  5 19:09:27 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Oct 2022 19:09:27 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system
In-Reply-To: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
Message-ID: <V7PfeW1matvyCWPgpM3Re1vyi9PIQE2949-llVv4wSU=.a1bcd756-290c-4b08-83a9-08ee75dec267@github.com>

On Tue, 4 Oct 2022 17:59:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 30:

> 28:  *   platform and virtual threads in deadlock
> 29:  * @enablePreview
> 30:  * @modules java.base/java.lang:+open java.management

Can you explain the need for this change?

test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 68:

> 66:     public static void main(String[] args) throws Exception {
> 67:         // need at least two carrier threads due to pinning
> 68:         VThreadRunner.ensureParallelism(2);

In this test case why is there no need to maintain a reference to the returned AutoCloseable? Isn't there a chance it can be collected and the old parallelism value restored while the test is running.

test/lib/jdk/test/lib/thread/VThreadRunner.java line 32:

> 30: 
> 31: /**
> 32:  * Helper class for running tests tasks in a virtual thread.

"tests" => "test"

test/lib/jdk/test/lib/thread/VThreadRunner.java line 149:

> 147:      * Ensures that the virtual thread scheduler's target parallelism is at least the
> 148:      * given size. If the current parallelism is less than size then it is changed to
> 149:      * size. This method returns an AutoCloseable, its close method restores the

"     * size. This method returns an AutoCloseable whose close method..."

test/lib/jdk/test/lib/thread/VThreadRunner.java line 176:

> 174:                     if (!closed) {
> 175:                         closed = true;
> 176:                         pool.setParallelism(parallelism);

What is the rationale for restoring the parallelism? It's just a test. Is this really necessary? Are we reusing the JVM to run other tests, and even if we are does it matter?

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From alanb at openjdk.org  Wed Oct  5 19:36:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 19:36:26 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system
In-Reply-To: <V7PfeW1matvyCWPgpM3Re1vyi9PIQE2949-llVv4wSU=.a1bcd756-290c-4b08-83a9-08ee75dec267@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <V7PfeW1matvyCWPgpM3Re1vyi9PIQE2949-llVv4wSU=.a1bcd756-290c-4b08-83a9-08ee75dec267@github.com>
Message-ID: <fdDcwk1-PnQOZdj3ENmVrV-FGyWFc_tYaqBXmjZIHX0=.57aceaf8-9199-4cbc-a9be-1d3bf1de478d@github.com>

On Wed, 5 Oct 2022 19:02:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 30:
> 
>> 28:  *   platform and virtual threads in deadlock
>> 29:  * @enablePreview
>> 30:  * @modules java.base/java.lang:+open java.management
> 
> Can you explain the need for this change?

That is jtreg foo to open java.lang, needed to access a private field.

> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 68:
> 
>> 66:     public static void main(String[] args) throws Exception {
>> 67:         // need at least two carrier threads due to pinning
>> 68:         VThreadRunner.ensureParallelism(2);
> 
> In this test case why is there no need to maintain a reference to the returned AutoCloseable? Isn't there a chance it can be collected and the old parallelism value restored while the test is running.

This test doesn't need to restore it so it doesn't keep a reference and not an issue if it is GC'ed.

> test/lib/jdk/test/lib/thread/VThreadRunner.java line 176:
> 
>> 174:                     if (!closed) {
>> 175:                         closed = true;
>> 176:                         pool.setParallelism(parallelism);
> 
> What is the rationale for restoring the parallelism? It's just a test. Is this really necessary? Are we reusing the JVM to run other tests, and even if we are does it matter?

Look at the ThreadAPI test as an example. It's a TestNG with dozens of test methods. All but one can run on single core systems.

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From cjplummer at openjdk.org  Wed Oct  5 19:50:12 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Oct 2022 19:50:12 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system
In-Reply-To: <fdDcwk1-PnQOZdj3ENmVrV-FGyWFc_tYaqBXmjZIHX0=.57aceaf8-9199-4cbc-a9be-1d3bf1de478d@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <V7PfeW1matvyCWPgpM3Re1vyi9PIQE2949-llVv4wSU=.a1bcd756-290c-4b08-83a9-08ee75dec267@github.com>
 <fdDcwk1-PnQOZdj3ENmVrV-FGyWFc_tYaqBXmjZIHX0=.57aceaf8-9199-4cbc-a9be-1d3bf1de478d@github.com>
Message-ID: <e0zV6_GFJnsaYz5k4xunMf-36Yd68Cf8KKFHWJOTR28=.b8ab14fa-8319-465e-a5b2-b14a0ab734a9@github.com>

On Wed, 5 Oct 2022 19:30:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 30:
>> 
>>> 28:  *   platform and virtual threads in deadlock
>>> 29:  * @enablePreview
>>> 30:  * @modules java.base/java.lang:+open java.management
>> 
>> Can you explain the need for this change?
>
> That is jtreg foo to open java.lang, needed to access a private field.

ok

>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 68:
>> 
>>> 66:     public static void main(String[] args) throws Exception {
>>> 67:         // need at least two carrier threads due to pinning
>>> 68:         VThreadRunner.ensureParallelism(2);
>> 
>> In this test case why is there no need to maintain a reference to the returned AutoCloseable? Isn't there a chance it can be collected and the old parallelism value restored while the test is running.
>
> This test doesn't need to restore it so it doesn't keep a reference and not an issue if it is GC'ed.

It's not a matter of whether or not the test needs to restore it. It _will_ restore it if there is a GC, and if this happens before the test completes, it could find itself without enough carrier threads.

>> test/lib/jdk/test/lib/thread/VThreadRunner.java line 176:
>> 
>>> 174:                     if (!closed) {
>>> 175:                         closed = true;
>>> 176:                         pool.setParallelism(parallelism);
>> 
>> What is the rationale for restoring the parallelism? It's just a test. Is this really necessary? Are we reusing the JVM to run other tests, and even if we are does it matter?
>
> Look at the ThreadAPI test as an example. It's a TestNG with dozens of test methods. All but one can run on single core systems.

Ok.

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From alanb at openjdk.org  Wed Oct  5 20:02:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Oct 2022 20:02:25 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system
In-Reply-To: <e0zV6_GFJnsaYz5k4xunMf-36Yd68Cf8KKFHWJOTR28=.b8ab14fa-8319-465e-a5b2-b14a0ab734a9@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <V7PfeW1matvyCWPgpM3Re1vyi9PIQE2949-llVv4wSU=.a1bcd756-290c-4b08-83a9-08ee75dec267@github.com>
 <fdDcwk1-PnQOZdj3ENmVrV-FGyWFc_tYaqBXmjZIHX0=.57aceaf8-9199-4cbc-a9be-1d3bf1de478d@github.com>
 <e0zV6_GFJnsaYz5k4xunMf-36Yd68Cf8KKFHWJOTR28=.b8ab14fa-8319-465e-a5b2-b14a0ab734a9@github.com>
Message-ID: <3UQVu9kA7RNhBX5c4zhjvw1Ho8JGWwIMgmPujk-Q_Jc=.7406856a-620c-45d7-b3a1-aabc1f05577c@github.com>

On Wed, 5 Oct 2022 19:44:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This test doesn't need to restore it so it doesn't keep a reference and not an issue if it is GC'ed.
>
> It's not a matter of whether or not the test needs to restore it. It _will_ restore it if there is a GC, and if this happens before the test completes, it could find itself without enough carrier threads.

No, restoration requires a call to close. Maybe you are assuming that AutoCloseable implementations setup a cleaner to do that?

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From cjplummer at openjdk.org  Wed Oct  5 20:27:12 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Oct 2022 20:27:12 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system
In-Reply-To: <3UQVu9kA7RNhBX5c4zhjvw1Ho8JGWwIMgmPujk-Q_Jc=.7406856a-620c-45d7-b3a1-aabc1f05577c@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <V7PfeW1matvyCWPgpM3Re1vyi9PIQE2949-llVv4wSU=.a1bcd756-290c-4b08-83a9-08ee75dec267@github.com>
 <fdDcwk1-PnQOZdj3ENmVrV-FGyWFc_tYaqBXmjZIHX0=.57aceaf8-9199-4cbc-a9be-1d3bf1de478d@github.com>
 <e0zV6_GFJnsaYz5k4xunMf-36Yd68Cf8KKFHWJOTR28=.b8ab14fa-8319-465e-a5b2-b14a0ab734a9@github.com>
 <3UQVu9kA7RNhBX5c4zhjvw1Ho8JGWwIMgmPujk-Q_Jc=.7406856a-620c-45d7-b3a1-aabc1f05577c@github.com>
Message-ID: <h6zw_86KPjSG42o9_F-_qEXJMbHrq28P03FUkASpwNE=.79167c1e-0ed0-4396-9d2e-e07b5f488d55@github.com>

On Wed, 5 Oct 2022 19:58:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's not a matter of whether or not the test needs to restore it. It _will_ restore it if there is a GC, and if this happens before the test completes, it could find itself without enough carrier threads.
>
> No, restoration requires a call to close. Maybe you are assuming that AutoCloseable implementations setup a cleaner to do that?

Yes, that was my point of confusion. I thought collection triggered calling close, but I see now when you want it to be closed, you rely on try-with-resources to call close() method.

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From sspitsyn at openjdk.org  Wed Oct  5 20:37:21 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 5 Oct 2022 20:37:21 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system
In-Reply-To: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
Message-ID: <JhumKP_qYThDNMAQDdgBAB_LJuULfEVO7RrJMwC9jWw=.d82645e5-2478-460e-9587-88ead0e71d2c@github.com>

On Tue, 4 Oct 2022 17:59:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From duke at openjdk.org  Wed Oct  5 20:49:52 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 5 Oct 2022 20:49:52 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v2]
In-Reply-To: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
Message-ID: <hmWlBpaexL4nX5FTUVmKRVuWcb7V5SLUVtnmhQx_3Hk=.a2078095-e0c0-4069-9434-ad8eaa7de9df@github.com>

> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Update doc code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10567/files
  - new: https://git.openjdk.org/jdk/pull/10567/files/55679168..f6b7d078

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10567&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10567&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10567.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10567/head:pull/10567

PR: https://git.openjdk.org/jdk/pull/10567

From lancea at openjdk.org  Wed Oct  5 21:01:27 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 5 Oct 2022 21:01:27 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v2]
In-Reply-To: <hmWlBpaexL4nX5FTUVmKRVuWcb7V5SLUVtnmhQx_3Hk=.a2078095-e0c0-4069-9434-ad8eaa7de9df@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
 <hmWlBpaexL4nX5FTUVmKRVuWcb7V5SLUVtnmhQx_3Hk=.a2078095-e0c0-4069-9434-ad8eaa7de9df@github.com>
Message-ID: <axjaXbhQ_p27YWPR96AZekvQLkxcbnTJTlmyLMZ4MBo=.e2aaee72-b1e4-4d32-91c7-6c871e5a0511@github.com>

On Wed, 5 Oct 2022 20:49:52 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
>> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update doc code

src/java.base/share/classes/java/text/DigitList.java line 198:

> 196: 
> 197:     /**
> 198:      * Utility routine to get the value of the digit list.

new BigDecimal("") will also throw a NumberFormatException so I would add a similar comment for count as done above for getLong/Double()

-------------

PR: https://git.openjdk.org/jdk/pull/10567

From duke at openjdk.org  Wed Oct  5 21:21:55 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 5 Oct 2022 21:21:55 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v2]
In-Reply-To: <axjaXbhQ_p27YWPR96AZekvQLkxcbnTJTlmyLMZ4MBo=.e2aaee72-b1e4-4d32-91c7-6c871e5a0511@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
 <hmWlBpaexL4nX5FTUVmKRVuWcb7V5SLUVtnmhQx_3Hk=.a2078095-e0c0-4069-9434-ad8eaa7de9df@github.com>
 <axjaXbhQ_p27YWPR96AZekvQLkxcbnTJTlmyLMZ4MBo=.e2aaee72-b1e4-4d32-91c7-6c871e5a0511@github.com>
Message-ID: <VKtdSKzQgOdqQJJ9pNkUUbCjt0Tscr9jmqVOgF9tL1E=.ec2bf327-2560-49c9-80db-a764e95b694e@github.com>

On Wed, 5 Oct 2022 20:57:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update doc code
>
> src/java.base/share/classes/java/text/DigitList.java line 198:
> 
>> 196: 
>> 197:     /**
>> 198:      * Utility routine to get the value of the digit list.
> 
> new BigDecimal("") will also throw a NumberFormatException so I would add a similar comment for count as done above for getLong/Double()

Thanks Lance, will make that change

-------------

PR: https://git.openjdk.org/jdk/pull/10567

From duke at openjdk.org  Wed Oct  5 21:26:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 5 Oct 2022 21:26:09 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v3]
In-Reply-To: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
Message-ID: <szH1mZxqcf9F2wHzJU8HKLn0Qwe77gCnWFbVIowUcvk=.55e30d19-37c0-47b7-9f30-9712fdc32356@github.com>

> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Update Doc
  
  Update getBigDecimal to match other getXXX() methods in DigitList

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10567/files
  - new: https://git.openjdk.org/jdk/pull/10567/files/f6b7d078..7975d25e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10567&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10567&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10567.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10567/head:pull/10567

PR: https://git.openjdk.org/jdk/pull/10567

From joehw at openjdk.org  Wed Oct  5 22:10:21 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 5 Oct 2022 22:10:21 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling
In-Reply-To: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
Message-ID: <t0j5I4jNZuav7L3EN_06rZSCzXQZYtkDEwol1JZiQqw=.3ac5a6fe-ddac-4122-ae43-41a96b4f1cbf@github.com>

On Tue, 4 Oct 2022 13:01:40 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Added test cases for xpath Axis:
> 1. descendant
> 2. descendant-or-self
> 3. following
> 4. following-sibling

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpDescendantTest.java line 41:

> 39: /*
> 40:  * @test
> 41:  * @bug 8289510

s/8289510/8289509

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFollowingTest.java line 39:

> 37: /*
> 38:  * @test
> 39:  * @bug 8289510

s/8289510/8289509

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From joehw at openjdk.org  Wed Oct  5 22:10:24 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 5 Oct 2022 22:10:24 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling
In-Reply-To: <9Sx_NY_p64qT2Y6zaAfFlpwM9nCGsFdbbucUcgiJZe0=.f498e85c-b67f-4165-8849-b2e7f3128302@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
 <9Sx_NY_p64qT2Y6zaAfFlpwM9nCGsFdbbucUcgiJZe0=.f498e85c-b67f-4165-8849-b2e7f3128302@github.com>
Message-ID: <ZbxBHimXuV5QfZxk0gs6Uzegjs4PijL61GuvoxfnLKY=.a963c951-9b4b-47fd-90ea-4bc753c55f55@github.com>

On Wed, 5 Oct 2022 17:28:08 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> Added test cases for xpath Axis:
>> 1. descendant
>> 2. descendant-or-self
>> 3. following
>> 4. following-sibling
>
> test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpDescendantTest.java line 65:
> 
>> 63:                 {"/Customers/Customer[@id='x1']/descendant-or-self::Address", "/Customers/Customer[@id = 'x1']/Address"},
>> 64:                 {"/Customers/Customer[@id='x1']/descendant-or-self::*", "/Customers/Customer[@id='x1'] | /Customers/Customer[@id = 'x1']//*"},
>> 65:                 {"/Customers/foo:Customer/foo:Address/descendant-or-self::*", "/Customers/foo:Customer/foo:Address | /Customers/foo:Customer/foo:Address//*"}
> 
> In the spec, there is a special note saying, "the location path //para[1] does not mean the same as the location path /descendant::para[1]". Based on this, it would be good to add a position test case for descendant. e.g.
> `/Customers/descendant::Street[2]`
> `/Customers/descendant::Street[position()=2]`
> `//Street[2]`
> `(//Street)[2]`

A more cosmetic suggestion besides Bill's technical comments, these lines are a bit too long. We still like the good old  80-character rule (slightly longer is ok), easier for people who use the Sdiffs.

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From errael at raelity.com  Wed Oct  5 22:36:05 2022
From: errael at raelity.com (Ernie Rael)
Date: Wed, 5 Oct 2022 15:36:05 -0700
Subject: Sequenced Collections
In-Reply-To: <62bf9d22-0ea2-10b9-fabf-78c0d68a880a@oracle.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
 <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
 <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>
 <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>
 <d5f1c419-0eb5-6c98-2d9c-9dcc248f6db3@raelity.com>
 <62bf9d22-0ea2-10b9-fabf-78c0d68a880a@oracle.com>
Message-ID: <fd778c1f-3521-7386-0800-281f002c45ed@raelity.com>

On 10/5/22 9:34 AM, Stuart Marks wrote:
>
>
> On 10/4/22 9:38 PM, Ernie Rael wrote:
>> Summary of key points (maybe the mail was TL;DR)
>
> OK thanks, I was still mulling over the previous email wondering which 
> parts were significant enough to reply to.
>
>> ??* SequencedCollection methods addFirst,addLast are the only methods in
>> ??? Collection hierarchy (AFAIK) that might modify the collection and do
>> ??? not return/signal if the collection was modified. Seems like
>> ??? offerFirst,offerLast are more consistent with Collections and still
>> ??? avoid method proliferation.
>
> The problem is that the boolean return values from add() and from 
> offerX() mean different things, and having them be adjacent on List 
> would be confusing. (Yes, they're both present on Deque, which is one 
> of the reasons Deque is too complicated.) And we couldn't adjust the 
> semantics of SequencedCollection.offerX() to match add(), as that 
> would clash with the existing semantics on Deque.


It is not uncommon for a sub-interface/sub-class to clarify the precise 
meaning of a method. If there's a general definition of 
SequencedCollection.offerFirst(e), then the Deque definition clarifies 
the meaning in that context. Consider:

Collections.add(e) - Returns true if this collection changed as a result 
of the call
List.add(e) - Return true
Set.add(e) - Returns true if this set did not already contain the 
specified element


>
> From your other messages it seems like you want the boolean return 
> value in order to keep track of whether the collection changed such 
> that it affects equals() and hashCode(). 


No, I was just discussing the relationship of change and equals() when 
working with a SequencedCollection; it's more observations around using 
SeqCol. It's interesting that an addAll() can permute the structure, and 
end up at the same place.


> There are other methods that might modify collections where you can't 
> tell whether they actually modified the collection; consider 
> Collection::clear or List::replaceAll. 


I'll be more precise: methods that work with a single item return/signal 
change; most bulk operators such as removeif(), retainAll(), 
removeAll(), addAll() also return/signal change.

My main point is that "void SequencedCollection.addFirst(e)" is 
inconsistent with Collections' design. clear() is, well, clear(). 
replaceAll() seems to be an exception (a lone exception?).


> So I don't think the boolean return value from add/offer is really 
> buying you all that much.


When I put together a class based on a Collection, I like to follow the 
general design pattern. Not sure if/when I may have used the "return 
change" when using a collection. But when sub-classing a collection, 
since everything does it, so do I; I'll return change in any additional 
methods I might add. Consistent, least surprise...


>
>> ??* With LinkedHashSet, seems like listIterator is missing. Rather than
>> ??? making that part of SequencedCollection, maybe an "interface
>> ??? ListIterable { ListIterator listIterator(int index); }". In addition
>> ??? to modification, bi-directional might also be optional, to support
>> ??? it's use with list equals.
>
> ListIterator has indexes and so it's pretty much tied to List. Maybe 
> what you're missing from LinkedHashSet 


I want to be able to do List.equals(SequencedCollection) and vice versa 
(in particular with LinkedHashSet). In the list equals() implementations 
I've looked at, they all use two ListIterator to do the compare; only 
forward iteration.? For equals(), I think can wrap the 
SequencedCollection iterator in a forward, uni-directional listIterator, 
a little messy, and use that for equals(); support from the 
infrastructure would be nice. Which is where the idea of "ListIterator 
Collections.listIterator(iterator, index)" in the other email comes from.

Some daydreaming: For equals(), indexes don't matter except for 
initialization. And as far as "index ... tied to list", if 
SequencedCollection had a listIterator, I think I could form 
sub-sequence from that, with only forward iteration. But 
sub-SequencedCollection is a different topic. My usage requirement now 
is for equals().

Lists may include index, but they don't really depend on it unless 
they're RandomAccess; consider LinkedList. I don't see how indexes have 
a bearing on this discussion; in a listIterator the index is 
contained/maintained in the iterator.


> is the ability to insert or reposition an element somewhere in the 
> middle? This is certainly a valid use case, but it's quite rare, and 
> I'm not sure I'd want to support it using an Iterator style mechanism 
> anyway.
>
> Surveying the usages of ListIterator, 


The implicit use by equals() is missing.


> I found that it's mainly used for iteration in reverse, and 
> secondarily for replacing all the elements of a List (somewhat 
> supplanted by replaceAll). We did run into one case where ListIterator 
> was used to edit items within a list but it turned out to be 
> INCREDIBLY clumsy to use. So if we want to support that (fairly rare) 
> use case, I wouldn't start with a ListIterator or some variant with 
> indexes removed. I'd also want to see use cases before considering 
> adding new mechanisms.
>
> s'marks
>


From smarks at openjdk.org  Wed Oct  5 23:46:48 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 5 Oct 2022 23:46:48 GMT
Subject: RFR: 8290036: Define and specify Runtime shutdown sequence [v10]
In-Reply-To: <692vZWTJM4sXBNePspQmJv-rOTPey2xbAqIc7UisxsY=.4d5cb6d8-739f-417f-adb1-67a61a956121@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
 <692vZWTJM4sXBNePspQmJv-rOTPey2xbAqIc7UisxsY=.4d5cb6d8-739f-417f-adb1-67a61a956121@github.com>
Message-ID: <MULoHR8QV3Cmc5glc4AMhzyvgUXaArOmqPIFXTGz7zI=.9177a668-ebf7-40f1-ad4a-a06aebff9b06@github.com>

On Wed, 5 Oct 2022 03:34:47 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
>  - Additional edits to Runtime and Thread specs.
>  - Merge branch 'master' into JDK-8290036-Runtime-addShutdownHook-spec
>  - Minor adjustments
>  - Revise Implementation Note discussing JNI Invocation API.
>  - Updates from Alan, David, and Alex.
>  - More edits from Alex's suggestions.
>  - More updates after discussion with Alex.
>  - Updates after conversation with Alan:
>    - specify that starting a shutdown hook explicitly has an unspecified
>      effect on the shutdown sequence
>    - link Thread class doc to shutdown sequence
>    - link to Thread.UncaughtExceptionHandler
>    - clarify that only live non-daemon threads are significant
>    - use "thread termination" to conform to the text in the Thread class
>    - adjust line breaks and whitespace
>  - Additional wording changes to Runtime specs.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/feeda6bc...9fa2950d

I guess I got into a race with the bot and lost. Retrying.

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From smarks at openjdk.org  Wed Oct  5 23:46:49 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 5 Oct 2022 23:46:49 GMT
Subject: Integrated: 8290036: Define and specify Runtime shutdown sequence
In-Reply-To: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
References: <4pUrHIZDNlvl7wEeEXp9XdBv0g1Bviyp_JUhKvHRw8w=.8d0e31a4-2762-460c-b2dc-49bf5b89eb21@github.com>
Message-ID: <s7FVkSFnGkdq3ZcO5MkLLyPN2re9GCpoeNqtYu9lgqM=.64d3a1f5-4aad-4af7-baae-12a971e6eef5@github.com>

On Fri, 8 Jul 2022 23:00:15 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> The concept of the shutdown sequence needs to be specified more clearly. This PR adds text for this into the class specification of `java.lang.Runtime`. Also includes adjustments to related areas in `addShutdownHook`, `halt`, and in the `System` and `Thread` classes. The changes here should coordinate with similar changes to JLS 12.8, JVMS 5.7, and the Invocation API chapter of the _JNI Specification._

This pull request has now been integrated.

Changeset: d4142d84
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4142d8441172fc54c9abf0a735c30b0ac8638c5
Stats:     194 lines in 3 files changed: 77 ins; 49 del; 68 mod

8290036: Define and specify Runtime shutdown sequence

Reviewed-by: dholmes, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/9437

From john.r.rose at oracle.com  Wed Oct  5 23:55:47 2022
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 05 Oct 2022 16:55:47 -0700
Subject: Collections.shuffle to accept RandomGenerator
In-Reply-To: <501a7a87-950b-ee32-f9da-d77e7ad5fdd1@oracle.com>
References: <CAE+3fjasa2Y8qZQiYNE8Dw2G8iXFmR9z3LruksGOiFMHEKeEiQ@mail.gmail.com>
 <0AE34224-3FED-4A34-B8F0-E2E916959600@oracle.com>
 <SJ0PR18MB4881EA7396DE6199472979CB83579@SJ0PR18MB4881.namprd18.prod.outlook.com>
 <CAE+3fjYg1PdD9P=GrcxUYpUhKqkobBbYD0Law61KLWRSQ6WwdQ@mail.gmail.com>
 <SJ0PR18MB48812F9068DA932E9F26044283589@SJ0PR18MB4881.namprd18.prod.outlook.com>
 <501a7a87-950b-ee32-f9da-d77e7ad5fdd1@oracle.com>
Message-ID: <EE17F7A3-433F-4579-9D4C-EC93452377A4@oracle.com>

On 3 Oct 2022, at 14:32, Stuart Marks wrote:

> ?
> The Arrays class does need some attention and probably should be considered separately. It's lacking some other things too, like reverse(). One issue with modifying the Arrays class is providing overloads for some or all of the primitives. We've kind of held off because adding primitive overloads adds to the clutter of an already-cluttered class. There are some functions that support only "common" primitives int/long/double (see Arrays::setAll) which reduces the clutter; but I've missed overloads for certain arrays like byte[].
>
> (I'm not saying not to do this; I'm saying this is more than dropping in a single Arrays::shuffle method.)

FTR, since we are talking about shuffles and other permutations, I?d like to bring up a pet RFE for Arrays:

<https://bugs.openjdk.org/browse/JDK-8265378>
Arrays.sort should provide optional external comparator for int and long arrays

And to round out a story that?s been bubbling in my mind for a while, here is another pet RFE to keep it company:

<https://bugs.openjdk.org/browse/JDK-8294879>
Arrays.sort should be accompanied by permutation vector operations


From amenkov at openjdk.org  Thu Oct  6 02:32:50 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Oct 2022 02:32:50 GMT
Subject: RFR: 8289561: java/lang/instrument/NativeMethodPrefixAgent.java fails
 with
 "ERROR: Injection failure: java.lang.UnsupportedOperationException: Records
 requires ASM8"
Message-ID: <Mnc9H3Uab0EHgE5gNRz1aqOHdMYFPuywDMojmleIo2U=.91cfbb51-4304-40bb-bd6f-b31b2981924f@github.com>

Test failure is a duplicate of [JDK-8284777](https://bugs.openjdk.org/browse/JDK-8284777), but the test needs to be updated:
- the test instruments all loaded classes, so need to updated ASM version to support records and permits;
  Instrumentor.addNativeMethodTrackingInjection is used only by this test;
- return empty array from transforming does not cause test failure, added code to handle agent errors

-------------

Commit messages:
 - Fixed test

Changes: https://git.openjdk.org/jdk/pull/10589/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10589&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289561
  Stats: 18 lines in 3 files changed: 12 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10589.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10589/head:pull/10589

PR: https://git.openjdk.org/jdk/pull/10589

From jpai at openjdk.org  Thu Oct  6 04:40:28 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Oct 2022 04:40:28 GMT
Subject: RFR: 8294697:
 java/lang/Thread/virtual/ThreadAPI.testGetStackTrace2 failed with non-empty
 stack trace
In-Reply-To: <WEYx8PgPO6fUu85mAAN90JoC3j2rl0nHdcKivQM65B0=.c4eb27ff-28cf-4914-9601-72b0afe9ac1e@github.com>
References: <WEYx8PgPO6fUu85mAAN90JoC3j2rl0nHdcKivQM65B0=.c4eb27ff-28cf-4914-9601-72b0afe9ac1e@github.com>
Message-ID: <Cvx4KlgHIQt8Nn1Yy7f4xM_tVFZKARwWHBx9TDACb3A=.fb4fc5b6-df89-4395-9cda-f338dc2d384a@github.com>

On Wed, 5 Oct 2022 14:05:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only change. ThreadAPI.testGetStackTrace2 tests the stack trace of a virtual thread that has started but has not executed it. The test currently attempts to saturate all carrier threads before starting a target thread. The test is not reliable and failed at least once with a debug build and -Xcomp. The test is changed to use a custom scheduler that discards the task so the thread doesn't execute. The resulting test is much simpler and removes 3s from the execution time.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10576

From darcy at openjdk.org  Thu Oct  6 05:14:44 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Oct 2022 05:14:44 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v3]
In-Reply-To: <szH1mZxqcf9F2wHzJU8HKLn0Qwe77gCnWFbVIowUcvk=.55e30d19-37c0-47b7-9f30-9712fdc32356@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
 <szH1mZxqcf9F2wHzJU8HKLn0Qwe77gCnWFbVIowUcvk=.55e30d19-37c0-47b7-9f30-9712fdc32356@github.com>
Message-ID: <YwtSHd-WMvCdJxmjz5HfsRZ_5vb_97YBUc94snQIT34=.0bb9177a-b114-4f9c-ad52-8ffffc4b0d45@github.com>

On Wed, 5 Oct 2022 21:26:09 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
>> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Doc
>   
>   Update getBigDecimal to match other getXXX() methods in DigitList

Sorry; didn't look closely enough before applying the csr label.

-------------

PR: https://git.openjdk.org/jdk/pull/10567

From svkamath at openjdk.org  Thu Oct  6 06:28:04 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 6 Oct 2022 06:28:04 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:

  Updated instruct to use kmovw

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9781/files
  - new: https://git.openjdk.org/jdk/pull/9781/files/69999ce4..a00c3ecd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9781.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781

PR: https://git.openjdk.org/jdk/pull/9781

From svkamath at openjdk.org  Thu Oct  6 06:28:06 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 6 Oct 2022 06:28:06 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v11]
In-Reply-To: <i8tl8yTM_cC7ZZi-871jbW-3HvqXQNMHjTIxfqnZiFc=.4034a16e-b3ad-4346-9f99-9797fcf4a7dc@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com>
 <P3WD1fmVLCwmvGi1rEyYNJg9vRN0J8JgV8bn4eIHsc4=.186a8e48-1cb9-4e88-b2e2-7ca142fb9163@github.com>
 <ix-SKa4ZivpVntpiwiIhQfRExnjCTZO2MbJkrw-je80=.294816e5-2607-4580-a108-bb90abd2701b@github.com>
 <Ji9rHFKZ1Fm-rhQ36_laIoSnK8_3RdRgcIJaevKQKf8=.a5b6c008-6f57-460d-88dd-6c00f32024ec@github.com>
 <iQs_nJCjhU4rE0iAVLPaKVGlH8LGx7gqlznFb0vyY8s=.ec7c05b6-39fd-4644-8169-56daa35b85ad@github.com>
 <i8tl8yTM_cC7ZZi-871jbW-3HvqXQNMHjTIxfqnZiFc=.4034a16e-b3ad-4346-9f99-9797fcf4a7dc@github.com>
Message-ID: <Dhs_ANvftEExf2st0CKBSdzOOzV46J1ZviQWHRpIskw=.27cbf6af-cf93-4851-9e67-1de23685da1d@github.com>

On Tue, 4 Oct 2022 09:07:42 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> You can use `kmovwl` instead which will relax the avx512bw constraint, however, you will need avx512vl for `evcvtps2ph`. Thanks.
>> 
>> Yes, in general all AVX512VL targets support AVX512BW, but cloud instances give freedom to enable custom features. Regarding K0, as per section "15.6.1.1" of SDM, expectation is that K0 can appear in source and destination of regular non predication context, k0 should always contain all true mask so it should be unmodifiable for subsequent usages i.e. should not be present as destination of a mask manipulating instruction. Your suggestion is to have that in source but it may not work either. Changing existing sequence to use kmovw and replace AVX512BW with AVX512VL will again mean introducing an additional predication check for this pattern.
>
> Ah I get it, the encoding of k0 is treated specially in predicated instructions to refer to an all-set mask, but the register itself may not actually contain that value. So usage in `kshiftrw` may fail. In that case I think we can generate an all-set mask on the fly using `kxnorw(ktmp, ktmp, ktmp)` to save a GPR in this occasion. Thanks.

Hi @merykitty, I am seeing performance regression with kxnorw instruction. So I have updated the PR with kmovwl. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From dholmes at openjdk.org  Thu Oct  6 06:54:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Oct 2022 06:54:24 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <xndg_YdJvyfaN6dM3UBlXbEWjghJi8nc2nQuPdO6nDg=.a20ceffd-d2dc-4cbc-8372-1e27749b6c04@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

I'm still somewhat perplexed as the launcher appears to to try and deal with this as I said before "see JLI_AddArgsFromEnvVar and the use of the relaunch field". So something seems amiss here. If that logic is not supposed to deal with the current problem, then what exactly is it intended for?

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From mbaesken at openjdk.org  Thu Oct  6 07:13:20 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Oct 2022 07:13:20 GMT
Subject: RFR: JDK-8294837: unify Windows 2019 version check in os_windows
 and java_props_md
In-Reply-To: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
References: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
Message-ID: <kxRVlFXeCHNg5K6S-mLkFYlzpRcVVcr2fQqLy_TNfgs=.7d97449f-474f-4938-aec4-b0ff5b42052a@github.com>

On Wed, 5 Oct 2022 09:21:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the buildNumber check for Windows 2019 server differs in os_windows.cpp and java_props_md.c ( java_props_md.c still checks pre GA versions , this is probably not necessary any more ).
> The check should be unified.

Hi Roger and Alan, thanks for the reviews.

-------------

PR: https://git.openjdk.org/jdk/pull/10570

From mbaesken at openjdk.org  Thu Oct  6 07:14:34 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Oct 2022 07:14:34 GMT
Subject: Integrated: JDK-8294837: unify Windows 2019 version check in
 os_windows and java_props_md
In-Reply-To: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
References: <m2V95-4yl-Rdx1RL8xxsmoohKHZtoLz58nib72iWL28=.c32d9c96-fabe-42e5-835f-1c27ed4f495c@github.com>
Message-ID: <26Wn-Vz3Bmitxk-fM156w1jiFDzooiImjqxLnbA-daM=.599de0f2-c70b-47e8-9e77-0e72eab23dbc@github.com>

On Wed, 5 Oct 2022 09:21:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the buildNumber check for Windows 2019 server differs in os_windows.cpp and java_props_md.c ( java_props_md.c still checks pre GA versions , this is probably not necessary any more ).
> The check should be unified.

This pull request has now been integrated.

Changeset: 7012d4ba
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7012d4ba5529f8d5b3db508ac4924073ae1eb4cd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8294837: unify Windows 2019 version check in os_windows and java_props_md

Reviewed-by: alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/10570

From alanb at openjdk.org  Thu Oct  6 08:02:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Oct 2022 08:02:52 GMT
Subject: Integrated: 8294697:
 java/lang/Thread/virtual/ThreadAPI.testGetStackTrace2 failed with non-empty
 stack trace
In-Reply-To: <WEYx8PgPO6fUu85mAAN90JoC3j2rl0nHdcKivQM65B0=.c4eb27ff-28cf-4914-9601-72b0afe9ac1e@github.com>
References: <WEYx8PgPO6fUu85mAAN90JoC3j2rl0nHdcKivQM65B0=.c4eb27ff-28cf-4914-9601-72b0afe9ac1e@github.com>
Message-ID: <DxzHp9FOkKRjtY_8T1HzGMBglpPuessVBYpIzS1eHnQ=.f1674896-cf66-4d72-a1ec-df254abfa811@github.com>

On Wed, 5 Oct 2022 14:05:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only change. ThreadAPI.testGetStackTrace2 tests the stack trace of a virtual thread that has started but has not executed it. The test currently attempts to saturate all carrier threads before starting a target thread. The test is not reliable and failed at least once with a debug build and -Xcomp. The test is changed to use a custom scheduler that discards the task so the thread doesn't execute. The resulting test is much simpler and removes 3s from the execution time.

This pull request has now been integrated.

Changeset: ad7b7d40
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad7b7d40ce7b71d9e1e13e1b92f3ca6b30e635a2
Stats:     36 lines in 1 file changed: 0 ins; 30 del; 6 mod

8294697: java/lang/Thread/virtual/ThreadAPI.testGetStackTrace2 failed with non-empty stack trace

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10576

From rgiulietti at openjdk.org  Thu Oct  6 09:35:09 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Oct 2022 09:35:09 GMT
Subject: Integrated: 8294456: Fix misleading-indentation warnings in core JDK
 libraries
In-Reply-To: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
References: <uo2D27qy4gR40a3vxvTaGXNwXqPsPiAYq4yFaGtFae4=.f26d475a-f3ff-42c7-87ca-6dffe67b12db@github.com>
Message-ID: <p6anLs2K5nMnmfJGCi71-RbijOfCBjjLd-pwBJQgucg=.0ed1c704-1575-4ff0-9c9e-754ec656ca72@github.com>

On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This fixes misleading indentations, which allows enabling the (currently disabled) `misleading-indentation` warning flag on two `.gmk` files.

This pull request has now been integrated.

Changeset: 2ceebf68
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ceebf681ffd6f9bf6967fd81b30d721bc010b94
Stats:     8 lines in 3 files changed: 1 ins; 1 del; 6 mod

8294456: Fix misleading-indentation warnings in core JDK libraries

Reviewed-by: shade, rriggs, iris, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/10487

From lancea at openjdk.org  Thu Oct  6 11:02:07 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Oct 2022 11:02:07 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v3]
In-Reply-To: <szH1mZxqcf9F2wHzJU8HKLn0Qwe77gCnWFbVIowUcvk=.55e30d19-37c0-47b7-9f30-9712fdc32356@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
 <szH1mZxqcf9F2wHzJU8HKLn0Qwe77gCnWFbVIowUcvk=.55e30d19-37c0-47b7-9f30-9712fdc32356@github.com>
Message-ID: <qHsaTej3Gk7y7nr4yFSWUgqugfbqGpwMRNSnCmLteCQ=.42ab8dd5-0061-4a06-bc0e-5106a35dd4f0@github.com>

On Wed, 5 Oct 2022 21:26:09 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
>> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Doc
>   
>   Update getBigDecimal to match other getXXX() methods in DigitList

Looks fine Justin.

Please make sure the comments are < 80 characters and if they are longer break them into two lines as they seem like they might be long

-------------

PR: https://git.openjdk.org/jdk/pull/10567

From dfuchs at openjdk.org  Thu Oct  6 11:22:20 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Oct 2022 11:22:20 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <O8EDWJ0ksKUKoE72THDCaNbw0MNpkTHPgoonYpRFA2k=.8f1638af-b667-4805-a5f9-a9781f7c69ad@github.com>

On Wed, 5 Oct 2022 15:23:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Marked as reviewed by dfuchs (Reviewer).

I am glad to see this RFE. It looks like a big change but most of it is actually reorganisation of internal code, so thanks for explaining its making off :-) It helps a lot for the review.  I have looked at the code and I believe it looks good. I don't see any alternative to the reorganisation that could make the changes smaller - so I'm OK with the proposed solution. Thanks for documenting the new properties in their respective module info, as well as in the security properties file.

I had only a cursory look at the tests but they seem comprehensive. Good work.

I am approving on the condition to make sure that all JNDI tests (as well as tier1, tier2, tier3) are run before integrating.

Also please get an approval from a security-libs maintainer for the changes to the security properties file before integrating.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From chegar at openjdk.org  Thu Oct  6 11:46:18 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Thu, 6 Oct 2022 11:46:18 GMT
Subject: RFR: 8293810: Remove granting of RuntimePermission("stopThread")
 from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <Hfnu4n_J8gncUt_HBO8L8uPVRIRc18Jp3CX_VU1Jmko=.b2d9ee11-3034-40e0-bcdd-1a950f1683e3@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

LGTM

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10577

From jwaters at openjdk.org  Thu Oct  6 12:45:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 6 Oct 2022 12:45:08 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v14]
In-Reply-To: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
Message-ID: <mtKKcCUpQeelxOO2Xpgm4uxXIEQpbSgYrXduYcEsOdw=.91d14691-aac9-4691-baee-cfde0adaae86@github.com>

> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
> 
> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-4
 - Merge branch 'openjdk:master' into patch-4
 - Use - instead of : as a separator
 - Merge branch 'openjdk:master' into patch-4
 - Make DLL_ERROR4 look a little better without changing what it means
 - Revert changes to JLI_ReportErrorMessageSys
 - Update java_md.c
 - Update java_md.h
 - Merge branch 'openjdk:master' into patch-4
 - Merge branch 'openjdk:master' into patch-4
 - ... and 6 more: https://git.openjdk.org/jdk/compare/3b1b25a0...c3113cac

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9749/files
  - new: https://git.openjdk.org/jdk/pull/9749/files/aadf6275..c3113cac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=12-13

  Stats: 773 lines in 72 files changed: 327 ins; 144 del; 302 mod
  Patch: https://git.openjdk.org/jdk/pull/9749.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Thu Oct  6 12:45:13 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 6 Oct 2022 12:45:13 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v13]
In-Reply-To: <8nmAhTC5tubNWCLn89kWO4hQaP9ILZvgkx1ZtqMS9yY=.c794b8f4-0e50-472b-9c9a-993a2b24d8d2@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <8nmAhTC5tubNWCLn89kWO4hQaP9ILZvgkx1ZtqMS9yY=.c794b8f4-0e50-472b-9c9a-993a2b24d8d2@github.com>
Message-ID: <fvxu7eCUjk2kDQg0LwcmYZSSCiNcvSajUVJU0FNBMy4=.dd26f369-9c44-4a4e-92d2-1db29273b051@github.com>

On Wed, 5 Oct 2022 16:40:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-4
>  - Use - instead of : as a separator
>  - Merge branch 'openjdk:master' into patch-4
>  - Make DLL_ERROR4 look a little better without changing what it means
>  - Revert changes to JLI_ReportErrorMessageSys
>  - Update java_md.c
>  - Update java_md.h
>  - Merge branch 'openjdk:master' into patch-4
>  - Merge branch 'openjdk:master' into patch-4
>  - Back out change to DLL_ERROR4 for separate RFE
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/2923d2f4...aadf6275

Successful merge with latest, change should now be ready for review

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From alanb at openjdk.org  Thu Oct  6 13:39:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Oct 2022 13:39:25 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system [v2]
In-Reply-To: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
Message-ID: <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>

> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Replace try-with-resource with try-finally
 - Merge
 - Make close idempotent
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10562/files
  - new: https://git.openjdk.org/jdk/pull/10562/files/5ac95695..bc2c3f13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10562&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10562&range=00-01

  Stats: 1769 lines in 125 files changed: 861 ins; 452 del; 456 mod
  Patch: https://git.openjdk.org/jdk/pull/10562.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10562/head:pull/10562

PR: https://git.openjdk.org/jdk/pull/10562

From alanb at openjdk.org  Thu Oct  6 13:39:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Oct 2022 13:39:25 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system [v2]
In-Reply-To: <h6zw_86KPjSG42o9_F-_qEXJMbHrq28P03FUkASpwNE=.79167c1e-0ed0-4396-9d2e-e07b5f488d55@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <V7PfeW1matvyCWPgpM3Re1vyi9PIQE2949-llVv4wSU=.a1bcd756-290c-4b08-83a9-08ee75dec267@github.com>
 <fdDcwk1-PnQOZdj3ENmVrV-FGyWFc_tYaqBXmjZIHX0=.57aceaf8-9199-4cbc-a9be-1d3bf1de478d@github.com>
 <e0zV6_GFJnsaYz5k4xunMf-36Yd68Cf8KKFHWJOTR28=.b8ab14fa-8319-465e-a5b2-b14a0ab734a9@github.com>
 <3UQVu9kA7RNhBX5c4zhjvw1Ho8JGWwIMgmPujk-Q_Jc=.7406856a-620c-45d7-b3a1-aabc1f05577c@github.com>
 <h6zw_86KPjSG42o9_F-_qEXJMbHrq28P03FUkASpwNE=.79167c1e-0ed0-4396-9d2e-e07b5f488d55@github.com>
Message-ID: <gYB6g0PCvmMHGmpCAneH3plj4HFYxwT-OP1w2BB14dQ=.7b461bd5-c954-4ebc-aefe-c47061c5b031@github.com>

On Wed, 5 Oct 2022 20:24:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> No, restoration requires a call to close. Maybe you are assuming that AutoCloseable implementations setup a cleaner to do that?
>
> Yes, that was my point of confusion. I thought collection triggered calling close, but I see now when you want it to be closed, you rely on try-with-resources to call close() method.

I've updated it to replace the use of try-with-resources with a try-finally that explicitly restores and maybe that will be easier to understand.

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From redestad at openjdk.org  Thu Oct  6 14:08:36 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 6 Oct 2022 14:08:36 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v14]
In-Reply-To: <cRHwYd-jhuiSyh4Ng3gqw1tikwOx7aw7wXqRAMnVO9w=.bc7b22d7-a02e-4751-92a4-a9eb10087a1d@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <Kzoo-86lD3frnSC7QG4g7Vs-NMn69QemAB6piLkyGQ8=.f2fe2d84-9d71-4ab3-a38c-13583b944f43@github.com>
 <cRHwYd-jhuiSyh4Ng3gqw1tikwOx7aw7wXqRAMnVO9w=.bc7b22d7-a02e-4751-92a4-a9eb10087a1d@github.com>
Message-ID: <9ibkhqwpDkMG9Loo9BactHBM0oNVv7kWaZtVV-QgG9s=.ceffd84b-6293-4e31-984b-3909dae93f86@github.com>

On Tue, 14 Jun 2022 13:54:46 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reenable SpecialArraysHashCode by default
>
> Still working on it, other work priorities have popped up. I'm taking the approach of outlining the longer string approach in a dedicated runtime stub. This makes the code easier and it doesn't have a performance impact given the stub is only called on longer strings (the cost of the call is thus amortised by the faster execution).

@luhenry notified me that he won't be able to continue working on this for now. I've started looking at this and am scoping out what's needed to finishing the work. To be continued in a new PR (soon!)

-------------

PR: https://git.openjdk.org/jdk/pull/7700

From sspitsyn at openjdk.org  Thu Oct  6 14:31:09 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 6 Oct 2022 14:31:09 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system [v2]
In-Reply-To: <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
Message-ID: <MQ0UEvDKh3_hDIwWZd5IoHJJKjSGuHho5wXAGlJ21Uc=.2f29db01-9950-4fc2-ba5b-0eeeabbd46ac@github.com>

On Thu, 6 Oct 2022 13:39:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Replace try-with-resource with try-finally
>  - Merge
>  - Make close idempotent
>  - Initial commit

The update looks more clear.
Thanks,
Serguei

test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 790:

> 788:             VThreadRunner.setParallelism(previousParallelism);
> 789:         }
> 790:     }

Just a side note to be aware about a potential problem.
This won't work correctly if there are more than one such tests executed in VM at the same time.
Then there can be a race to restore the parallelism value.
But it seems is not the case.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10562

From prappo at openjdk.org  Thu Oct  6 14:35:20 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Oct 2022 14:35:20 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>
Message-ID: <IDbm-8O6WIU3UVM8RfCgwumVv07BW1zqbpVkwYNhjps=.31e7c071-18d8-4278-a0cd-21a00d26e9ac@github.com>

On Fri, 30 Sep 2022 19:15:17 GMT, Phil Race <prr at openjdk.org> wrote:

> If the docs end up the same as you say that is fine by me since for the two ImageIO classes that seems to be what we'd want.

Since this change does not affect HTML pages for java.desktop, I take it as "approved".

> But inheritDoc behaviour is still "surprising". I've never been sure I understood it and now I'm just sure I don't.
> 
> 1. The two ImageIO methods don't have @OverRide or _anything_ and yet javadoc infers
>    they'd want to inherit the docs from the interface .. clever javadoc .. I guess I can see
>    that some doc is better than none so this is OK
> 2. When it does inherit I'd expected that it copies the EXACT and ENTIRE javadoc
>    from the super-interface, which for your change to work can't be all its doing.
>    You've added JUST
>    /**
> 
> * @throws SomeExceptionSubType blah-blah
>   */
> 
> and yet javadoc somehow figures out this is to be ADDED to the super-type doc for the method and not replace it .. ???
> 
> 3. What the old code was doing seems to me to be "natural" to the extent any of
>    this does and the fix you are preparing would add to the surprising behaviours ..

Let me try to clarify exception documentation inheritance for you.

A method **never** inherits exception documentation unless that method explicitly requests to do so. A method that wants to inherit documentation for a particular exception has two options: use a doc comment or use a method declaration.

Let's see how those options work. Suppose, a method wants to inherit documentation for an exception `X`. To inherit documentation through a doc comment, the method adds the following exception tag (`@throws` or `@exception`) to that method's doc comment:


?    @throws X {@inheritDoc}


To inherit documentation through a method declaration, the method lists `X` in that method's `throws` clause:


?    throws ..., X, ...


If a method chooses neither of those options, then that method won't inherit exception documentation for `X` (assuming that exception documentation for `X` exists in the supermethod).

Here's an informal, simplified, but conceptually correct version of the algorithm that javadoc uses to document exceptions thrown by a method:

  Step 1. For each exception tag, do the following. If an exception tag does not have `{@inheritDoc}` in its description, add an entry for the exception that this tag describes to the "Throws:" section. Otherwise, look for corresponding documentation in the supermethod, to which apply this step (Step 1) recursively.

  Step 2. For each exception from the `throws` clause, do the following. If an exception has not been documented on the previous step, document it using corresponding documentation in the supermethod, to which apply this algorithm (both steps in order) recursively.

A few notes on the algorithm: 

* Exception tags are examined prior to the `throws` clause. This allows a method to **override** documentation that could be otherwise inherited from the supermethod: if the method provides exception tags for a particular exception, then documentation for that exception will be found on Step 1 and, hence, won't be looked for in the supermethod on Step 2.


  ?    @throws X <overriding-description>


* If a method wants to **add** documentation for a particular exception, rather than **override** it, the method should both add documentation and inherit it using tags:


  ?    @throws X <additional-description>
  ?    @throws X {@inheritDoc}


The above model might explain a common **misconception** according to which methods inherit documentation for checked exceptions and do not inherit it for unchecked exceptions. In reality, javadoc treats all exceptions equally. It's just that if a method throws a checked exception, that exception (or its superclass) must be listed in that method's `throws` clause. Now, if such an exception is not documented by that method but documented by the supermethod, that exception documentation is inherited. That gives a false impression that the documentation is inherited because the exception is checked. In fact, the documentation would still be inherited if that exception, listed in the `throws` clause, were unchecked.

The above is how it has been working (barring bugs) since documentation comment inheritance appeared in its current form. Implicit inheritance (filling in missing text) appeared in JDK 1.3, explicit inheritance (`{@inheritDoc}`) appeared in JDK 1.4, auto-inheriting documentation for subclasses of exceptions whose documentation is inherited (JDK-4947455) appeared in JDK 5.

Back to this PR change in `java.desktop`. `ImageInputStreamImpl.readBoolean` inherits `EOFException` documentation not because that method doesn't have a doc comment of its own and, thus, inherits "the exact and entire" doc comment from its supermethod (`ImageInputStream.readBoolean`). It's because that when the algorithm reaches Step 2 and tries to find documentation for `IOException` (because it is listed in the `throws` clause), JDK-4947455 kicks in. And JDK-4947455 says that if a method inherits documentation for a particular exception, it should also inherit documentation for that exception's subclasses. So, javadoc goes ahead and inherits documentation for `IOException`, because it's a direct match, and for `EOFException`, because it's a subclass of `IOException`. 

To inherit `EOFException` documentation after JDK-4947455 has been reverted and, thus, the subclassing :magic_wand: has gone, `ImageInputStreamImpl.readBoolean` has two options: 

* list `EOFException` in the `throws` clause
* `@throws EOFException {@inheritDoc}`

Thanks to the current implementation of documentation inheritance, any of the above can be done **before** JDK-4947455 is reverted. For now doing so just adds a redundant but harmless inheritance route, which will become the only route in time. For this PR to be less disruptive and qualify as "noreg-doc" I chose to add an exception tag rather than amend the `throws` clause.

I hope that my reply clarifies the matter. Documentation inheritance can be surprising. We're trying hard to capture its model and simplify it where possible. We are constantly improving the Documentation Comment Specification for the Standard Doclet[^1] (spec), but since documentation inheritance is a popular topic which is often misunderstood, along with improving the spec in this area, we might also provide a less formal document dedicated to documentation inheritance.

[^1]: https://docs.oracle.com/en/java/javase/19/docs/specs/javadoc/doc-comment-spec.html

-------------

PR: https://git.openjdk.org/jdk/pull/10449

From alanb at openjdk.org  Thu Oct  6 14:56:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Oct 2022 14:56:14 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system [v2]
In-Reply-To: <MQ0UEvDKh3_hDIwWZd5IoHJJKjSGuHho5wXAGlJ21Uc=.2f29db01-9950-4fc2-ba5b-0eeeabbd46ac@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
 <MQ0UEvDKh3_hDIwWZd5IoHJJKjSGuHho5wXAGlJ21Uc=.2f29db01-9950-4fc2-ba5b-0eeeabbd46ac@github.com>
Message-ID: <NCth16t6ZXvUjqCl4H2xxH-R9nsL1YiCYp26QLr7B-Y=.86653823-4ebe-4cd5-8faf-764c937fec3b@github.com>

On Thu, 6 Oct 2022 14:26:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Just a side note to be aware about a potential problem.
> This won't work correctly if there are more than one such tests executed in VM at the same time.
> Then there can be a race to restore the parallelism value.
> But it seems is not the case.

That's right but jtreg runs tests sequentially in the same VM (when in agentVM mode, and sameVM mode in the past. JUnit does have support for parallelism but we aren't using it in any of these tests.

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From jjg at openjdk.org  Thu Oct  6 15:05:56 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 6 Oct 2022 15:05:56 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <lySOn6EkcX5ybd_-t8TFRBQfB51zAnoq5Bz79HZQmws=.f4be94e4-88d9-43c2-b052-0034e957738e@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

I'm marking the change as approved, in terms of the cumulative efforts of those who have commented.

I've browsed all the changes and read the jshell files in more detail, since no once else has so far.

I understand the reason for the change, and generally approve of undoing the magic of the old feature in JDK-8287796. That being said, the proposed state is "not great", and feels like the interim stage of "one step back, to take two steps forward", even though I do not have a good sense at this time of what that future direction might be.

So, looks OK for now, but I hope we revisit this issue again sometime.  Thanks, in general, for taking on this topic.

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10449

From cjplummer at openjdk.org  Thu Oct  6 15:33:18 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 6 Oct 2022 15:33:18 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system [v2]
In-Reply-To: <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
Message-ID: <ms4uw0RL2z_gBaOxqML1s50BRBz6A7hZ2MlbIcXeAtk=.3a1f54e4-d814-456c-a5c2-466f92afc6fd@github.com>

On Thu, 6 Oct 2022 13:39:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Replace try-with-resource with try-finally
>  - Merge
>  - Make close idempotent
>  - Initial commit

If these tests are ever run with the virtual thread wrapper, will we end up being short a carrier thread? It's unclear to me if the tests will always have at least one unpinned carrier thread to work with.

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From rriggs at openjdk.org  Thu Oct  6 16:30:22 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Oct 2022 16:30:22 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>

On Wed, 5 Oct 2022 15:23:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Nice work, but a few comments.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 91:

> 89:     }
> 90: 
> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {

This construct in which the supplied lambda fills in the serialClass is pretty obscure. 
Perhaps the variable name can be "serialClass" to match the only non-default method in ObjectInputFilter would give a better hint.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 92:

> 90: 
> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {
> 92:         Status result = switch(scheme) {

The handling of the selection of the filter could be more direct.
You can change the argument to checkInput to be ObjectInputFilter and pass the desired filter; LDAP_FILTER, RMI_FITLER, or GLOBAL_FILTER.
And make the check of the GLOBAL_FILTER conditional on it not having already been evaluated.
Then it will be the case that there must always be a specific filter.

The callers are all local to the class and would change to pass the desired filter.

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 173:

> 171:                                            DEFAULT_GLOBAL_SP_VALUE));
> 172: 
> 173:     // A system-wide LDAP specific object factories filter constructed from the system

Where does the IllegalArgumentException from ObjectInputFilter.create get handled or reported?
If the property value is illformed, the error should be enough to diagnose and correct the property.

test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java line 46:

> 44:  * @build LDAPServer LDAPTestUtils TestFactory
> 45:  *
> 46:  * @run main/othervm LdapFactoriesFilterTest false

Are any of these filter property cases, malformed and would produce an error from ObjectInputFilter.create?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From mullan at openjdk.org  Thu Oct  6 17:25:25 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Oct 2022 17:25:25 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <LBmZPtn1wTQZx2KBRmnRMugEcvp0VOEAr1-Feg4Meqc=.f0c6e19d-d9af-4f9f-8390-7eb4b788acfc@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

Marked as reviewed by mullan (Reviewer).

src/java.base/share/classes/jdk/internal/access/JavaSecurityAccess.java line 32:

> 30: import java.security.PrivilegedAction;
> 31: import java.security.ProtectionDomain;
> 32: import java.util.Properties;

Update copyright on this file.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From alanb at openjdk.org  Thu Oct  6 17:51:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Oct 2022 17:51:13 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system [v2]
In-Reply-To: <ms4uw0RL2z_gBaOxqML1s50BRBz6A7hZ2MlbIcXeAtk=.3a1f54e4-d814-456c-a5c2-466f92afc6fd@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
 <ms4uw0RL2z_gBaOxqML1s50BRBz6A7hZ2MlbIcXeAtk=.3a1f54e4-d814-456c-a5c2-466f92afc6fd@github.com>
Message-ID: <ikY3884nSbUYquuddz2I7T21i6cy9ezoNFxGclsB8H0=.bd091143-a14b-49e0-ac1c-672748c04b3f@github.com>

On Thu, 6 Oct 2022 15:31:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If these tests are ever run with the virtual thread wrapper, will we end up being short a carrier thread? It's unclear to me if the tests will always have at least one unpinned carrier thread to work with.

There's nothing inherit here that prevents use of the jtreg main wrapper with only a single carrier thread. That is, the helper class used by these tests will allow the underlying carrier to be released while waiting for the test running in another virtual thread to finish. However, there are a few issues that are problematic right now, one being that TestNG's test method invoker (specifically MethodInvocationHelper) pins. In time we will see if we have any similar issues with JUnit tests. So issues for the future if there the jtreg main wrapper is integrated, not an issue for this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From duke at openjdk.org  Thu Oct  6 20:43:30 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 6 Oct 2022 20:43:30 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v4]
In-Reply-To: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
Message-ID: <jP9xO5LhyF0e-Le6GEQD0TvRp-Byn1IhxDWu_J9ptOg=.9d5b0fc0-5beb-4613-bae6-180805a54196@github.com>

> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Refactor comment length
  
  Make under 80 chars

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10567/files
  - new: https://git.openjdk.org/jdk/pull/10567/files/7975d25e..cafcab83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10567&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10567&range=02-03

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10567.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10567/head:pull/10567

PR: https://git.openjdk.org/jdk/pull/10567

From duke at openjdk.org  Thu Oct  6 20:43:31 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 6 Oct 2022 20:43:31 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v3]
In-Reply-To: <qHsaTej3Gk7y7nr4yFSWUgqugfbqGpwMRNSnCmLteCQ=.42ab8dd5-0061-4a06-bc0e-5106a35dd4f0@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
 <szH1mZxqcf9F2wHzJU8HKLn0Qwe77gCnWFbVIowUcvk=.55e30d19-37c0-47b7-9f30-9712fdc32356@github.com>
 <qHsaTej3Gk7y7nr4yFSWUgqugfbqGpwMRNSnCmLteCQ=.42ab8dd5-0061-4a06-bc0e-5106a35dd4f0@github.com>
Message-ID: <EJ9KgRzZN1WpQ9bsQV0BqHkuH-OJB6kmHy-XsNfavaE=.4ea9b6c8-c0cd-4abd-b8f9-d334aec1dcaa@github.com>

On Thu, 6 Oct 2022 10:58:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Looks fine Justin.
> 
> Please make sure the comments are < 80 characters and if they are longer break them into two lines as they seem like they might be long

@LanceAndersen Made the change, thanks Lance

-------------

PR: https://git.openjdk.org/jdk/pull/10567

From lancea at openjdk.org  Thu Oct  6 20:48:23 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Oct 2022 20:48:23 GMT
Subject: RFR: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code [v4]
In-Reply-To: <jP9xO5LhyF0e-Le6GEQD0TvRp-Byn1IhxDWu_J9ptOg=.9d5b0fc0-5beb-4613-bae6-180805a54196@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
 <jP9xO5LhyF0e-Le6GEQD0TvRp-Byn1IhxDWu_J9ptOg=.9d5b0fc0-5beb-4613-bae6-180805a54196@github.com>
Message-ID: <hDii0pleQZqISZpnQ38U8-lgsCsFmwlSFDincqBwDok=.3b1b6049-7caa-4cdd-a635-24023456d2e0@github.com>

On Thu, 6 Oct 2022 20:43:30 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
>> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor comment length
>   
>   Make under 80 chars

thank you Justin :-)

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10567

From duke at openjdk.org  Thu Oct  6 21:38:48 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 6 Oct 2022 21:38:48 GMT
Subject: RFR: 6560981: (cal) unused local variables in GregorianCalendar, etc.
Message-ID: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>

Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.

Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.

Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

-------------

Commit messages:
 - Update copyright
 - Remove unusued/redundant code

Changes: https://git.openjdk.org/jdk/pull/10585/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6560981
  Stats: 9 lines in 3 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10585.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10585/head:pull/10585

PR: https://git.openjdk.org/jdk/pull/10585

From naoto at openjdk.org  Thu Oct  6 21:53:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Oct 2022 21:53:14 GMT
Subject: RFR: 6560981: (cal) unused local variables in GregorianCalendar, 
 etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <bv7n4TnMxBkpD7yllMvHzBDi0UjqXzuI_i8IuOqhWgk=.86101fe9-8394-4047-86d5-e79c306ea534@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10585

From bchristi at openjdk.org  Thu Oct  6 22:15:26 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 6 Oct 2022 22:15:26 GMT
Subject: RFR: 6560981: (cal) unused local variables in GregorianCalendar, 
 etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <ZCsVYRYfabwYNqbJHSLyoiJgv_AF7JegAPwCUeN_nDQ=.958f0381-5b90-48ee-a3de-bdafbfc8c80e@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

Looks fine

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10585

From iris at openjdk.org  Thu Oct  6 22:15:28 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 6 Oct 2022 22:15:28 GMT
Subject: RFR: 6560981: (cal) unused local variables in GregorianCalendar, 
 etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <E7fQn2cZOuw7fxyMZUQWzo9tKvq17rdGN-trvldQ7Zo=.dc0d895c-6e7c-471f-8dcc-0c512a77275a@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10585

From duke at openjdk.org  Thu Oct  6 23:20:31 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 6 Oct 2022 23:20:31 GMT
Subject: Integrated: 6560981: (cal) unused local variables in
 GregorianCalendar, etc.
In-Reply-To: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
References: <QijzbfTGw3K3We6p2YkfMf9xZ87itmZT3V8qSZGMJqQ=.72debe4f-b7fc-4776-98f1-efa05be05683@github.com>
Message-ID: <WcBGom90hV2XFskBrWdeOsTjSst_qYdodqvIbTp38b8=.f9bc82fb-3654-4695-82f8-6e2a578c7001@github.com>

On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and Base Calendar.
> 
> Fix: Removed all unused variables in bug description except normalizedYear in JapaneseImpericalCalendar.getActualMaximum.() as there was no matching unused variable within that method.
> 
> Additionally removed realDayOfYear in GregorianCalendar.computeFields.() due to redundancy.

This pull request has now been integrated.

Changeset: d4c9a880
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4c9a88073479ff05e6c07ed599c546826d6f6ba
Stats:     9 lines in 3 files changed: 0 ins; 6 del; 3 mod

6560981: (cal) unused local variables in GregorianCalendar, etc.

Reviewed-by: naoto, bchristi, iris

-------------

PR: https://git.openjdk.org/jdk/pull/10585

From alanb at openjdk.org  Fri Oct  7 06:19:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 06:19:32 GMT
Subject: Integrated: 8293810: Remove granting of
 RuntimePermission("stopThread") from tests
In-Reply-To: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
References: <Z7p0NE_0PAsgXEA3epaDfplsZcrkMPJNeWTCzisaylQ=.2ba242a6-4de7-40de-8a3f-0e77e5fb8bf5@github.com>
Message-ID: <s5gfCl3wJO7dcqmUrPBoxSeEIAyNIJIvLUYpdTBq8Cw=.de27381b-1ff5-48ec-8ac4-5e77aedab2f4@github.com>

On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to remove the granting of RuntimePermission("stopThread") from the tests. With Thread.stop changed to throw UOE it means there is nothing that requires this permission.

This pull request has now been integrated.

Changeset: 0ad6803a
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ad6803ac2bba063d15ce8284a09da36b4cced81
Stats:     52 lines in 6 files changed: 0 ins; 51 del; 1 mod

8293810: Remove granting of RuntimePermission("stopThread") from tests

Reviewed-by: dfuchs, mullan, mchung, chegar

-------------

PR: https://git.openjdk.org/jdk/pull/10577

From cjplummer at openjdk.org  Fri Oct  7 06:39:26 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 7 Oct 2022 06:39:26 GMT
Subject: RFR: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on
 single core system [v2]
In-Reply-To: <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
 <O-0xFC7M-od4Iieg5SDdJl3Mjz3t2rJOwJc_bMCMMJg=.5ec2e3ae-11d1-4504-85fa-0ed7d098d478@github.com>
Message-ID: <sMDCIcD_OiCwR89NgiikTNCEK1SODxSWVL_uKcVWA3I=.1e7bd614-2a70-415c-9225-6476bcc14943@github.com>

On Thu, 6 Oct 2022 13:39:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Replace try-with-resource with try-finally
>  - Merge
>  - Make close idempotent
>  - Initial commit

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From alanb at openjdk.org  Fri Oct  7 08:17:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 08:17:48 GMT
Subject: Integrated: 8291429: java/lang/Thread/virtual/ThreadAPI.java timed out
 on single core system
In-Reply-To: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
References: <XZ2RNOnsmPIHT-NGowcaL-cmF2gefrK93BOOB7p3OhU=.8310fdf9-9f92-4384-9966-df012300c3f0@github.com>
Message-ID: <cFgxxMRCyToUXUGFHHDFCdEcWtozxEwarlerMo6RtPQ=.ac76245a-5849-4285-9697-97f9dc66a56e@github.com>

On Tue, 4 Oct 2022 17:59:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change for two tests for virtual threads that hang/timeout on single core systems. The two tests involve pinning and require at least two carrier threads. The test lib used by these tests is updated to define a new method that ensures parallelism is at least a given value and both tests are updated to use this. There are a number of tests in the debugger area that may potentially use this in the future.

This pull request has now been integrated.

Changeset: 1fda8421
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fda8421b976dc19b6f977e38d8d87f493e1a1fd
Stats:     61 lines in 4 files changed: 51 ins; 0 del; 10 mod

8291429: java/lang/Thread/virtual/ThreadAPI.java timed out on single core system

Reviewed-by: sspitsyn, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/10562

From alanb at openjdk.org  Fri Oct  7 12:53:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Oct 2022 12:53:30 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
Message-ID: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>

On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst <mernst at openjdk.org> wrote:

>> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni
>
> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reinstate typos in Apache code that is copied into the JDK
>  - Merge ../jdk-openjdk into typos-typos
>  - Remove file that was removed upstream
>  - Fix inconsistency in capitalization
>  - Undo change in zlip
>  - Fix typos

src/java.se/share/data/jdwp/jdwp.spec line 101:

> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
> 100:         "in the target VM. This includes platform threads created with the Thread "
> 101:         "API and all native threads attached to the target VM with JNI code."

The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From jwaters at openjdk.org  Fri Oct  7 13:39:54 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Oct 2022 13:39:54 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v4]
In-Reply-To: <0uuBnaZ4vxnwvwqPZzTniup_5ZxVSs_iq47NGmUzLFg=.09f9ee79-d50a-40ab-87aa-37a1a36e7699@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <YpqRSl4_ig_8CXiL0w4oC_z4kqMcdaPkZjLyVv2czwc=.4f6aaf57-05d9-4419-ba34-91ae5acc2e51@github.com>
 <V9xmRxsE7_y4bgVcy7Cv7kG9Vtt1WqVJDcNehT6jlx4=.de8ac5c9-dad7-4ec1-b327-6647bdc0b1c1@github.com>
 <0uuBnaZ4vxnwvwqPZzTniup_5ZxVSs_iq47NGmUzLFg=.09f9ee79-d50a-40ab-87aa-37a1a36e7699@github.com>
Message-ID: <EntA2_l-wVdQiC1ZRdX_vrfzv_XGyR0L-7inQ-kDQ2A=.7a0aa097-9c86-4e20-a659-d4681977880f@github.com>

On Sun, 7 Aug 2022 07:57:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Nothing I could find in the tests that suggest they use this message as input, and none of them have failed with this patch, so I guess that's a good thing? :P
>> 
>> I am slightly concerned with going the route of 2 different calls for WIN32 and the C runtime, since `JLI_ReportErrorMessageSys` is a shared function, only the implementations differ from platform to platform. I can't think of any solution off the top of my head to implement such a change without drastically changing either the Unix variant as well, or the declaration's signature in the shared header unfortunately.
>> 
>> I was initially hesitant to change the formatting of spacing between the caller's message and system error, since the original intention for leaving it up to the caller may have been to allow for better flexibility. Also a concern was any behaviour differences that might result with the Unix variant, but it seems like the 2 format their messages entirely differently - While Windows appends the system error to the end of message without any formatting, Unix prints it on an entirely separate line above the message the caller passed it:
>> 
>> JNIEXPORT void JNICALL
>> JLI_ReportErrorMessageSys(const char* fmt, ...) {
>>     va_list vl;
>>     char *emsg;
>> 
>>     /*
>>      * TODO: its safer to use strerror_r but is not available on
>>      * Solaris 8. Until then....
>>      */
>>     emsg = strerror(errno);
>>     if (emsg != NULL) {
>>         fprintf(stderr, "%s\n", emsg);
>>     }
>> 
>>     va_start(vl, fmt);
>>     vfprintf(stderr, fmt, vl);
>>     fprintf(stderr, "\n");
>>     va_end(vl);
>> }
>> 
>> 
>>> If you can make the fix for the CRT extra info small, I'd go for it.
>> 
>> I don't quite get what you mean by that, should I revert the changes made to the freeit checks?
>
>> Nothing I could find in the tests that suggest they use this message as input, and none of them have failed with this patch, so I guess that's a good thing? :P
> 
> Oh, that is fine :) Thanks for looking. I just mentioned it since you are new-ish. The tests that run as part of GHAs are only a tiny subset of all tests though, therefore there can be tests that fail and you would not notice.
> 
> About the rest, starting to pull a thread somewhere and then noticing that the thread gets longer and longer is a normal thing. Then its up to you to decide whether fixing the isolated issue is worth it or whether more code needs to be reworked.
> 
> Cheers, Thomas

@tstuefe Do you think this should be ok now, since all reliance on [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) has been dropped?

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From duke at openjdk.org  Fri Oct  7 14:25:41 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 7 Oct 2022 14:25:41 GMT
Subject: RFR: 8286394: Address possibly lossy conversions in jdk.naming.dns
Message-ID: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>

Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning

I tested this build and it doesn't give any warnings on this file

-------------

Commit messages:
 - added int cast and reenabled warning for lossy conversion

Changes: https://git.openjdk.org/jdk/pull/10607/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286394
  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10607.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10607/head:pull/10607

PR: https://git.openjdk.org/jdk/pull/10607

From rriggs at openjdk.org  Fri Oct  7 14:37:14 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Oct 2022 14:37:14 GMT
Subject: RFR: 8286394: Address possibly lossy conversions in jdk.naming.dns
In-Reply-To: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
References: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
Message-ID: <etd42HG31qyS7qJDyw1WSao3dM2lrQnbuDcjbhbMROw=.3f0ea55a-9bcc-4de9-9f68-5708e3cc2f26@github.com>

On Fri, 7 Oct 2022 14:14:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning
> 
> I tested this build and it doesn't give any warnings on this file

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10607

From aefimov at openjdk.org  Fri Oct  7 14:55:29 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 7 Oct 2022 14:55:29 GMT
Subject: RFR: 8286394: Address possibly lossy conversions in jdk.naming.dns
In-Reply-To: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
References: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
Message-ID: <2C6dgLdGl6jh2hWZ_orw0I0qAlGkQ7bDuC2mf4nKkbw=.3691e3fc-ec0c-406d-b71c-b69cb4b932e8@github.com>

On Fri, 7 Oct 2022 14:14:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning
> 
> I tested this build and it doesn't give any warnings on this file

Marked as reviewed by aefimov (Committer).

Looks good. I can help with sponsoring this change.

-------------

PR: https://git.openjdk.org/jdk/pull/10607

From mchhipa at openjdk.org  Fri Oct  7 15:36:16 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 7 Oct 2022 15:36:16 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling [v2]
In-Reply-To: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
Message-ID: <ajidYv5T5AisWrnkMWub0Hlj0gbGnlwpL7cDMDa8A5A=.dde4a608-d4c3-4b4c-b059-21ce67202e05@github.com>

> Added test cases for xpath Axis:
> 1. descendant
> 2. descendant-or-self
> 3. following
> 4. following-sibling

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented the review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10557/files
  - new: https://git.openjdk.org/jdk/pull/10557/files/a3aeea91..5489dcf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10557&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10557&range=00-01

  Stats: 47 lines in 2 files changed: 30 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10557.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10557/head:pull/10557

PR: https://git.openjdk.org/jdk/pull/10557

From duke at openjdk.org  Fri Oct  7 16:08:11 2022
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 7 Oct 2022 16:08:11 GMT
Subject: Integrated: 8286394: Address possibly lossy conversions in
 jdk.naming.dns
In-Reply-To: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
References: <l1_iyh7y9_miGXeVopY9JvMF8jmRy7MY3n-8PzVcHYY=.0fa1eefa-eeed-46de-bbe1-0855c247d103@github.com>
Message-ID: <F_33FlpPuwSqImI1_V6lu_OT_LM0vubW_8flVkfil2g=.af20dd70-d378-4b97-8540-b48560df22ad@github.com>

On Fri, 7 Oct 2022 14:14:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Added an int cast for the `timeoutLeft` assignment, looking through the code and other uses of the variable it seems to show no issues with lossy conversion. As part of this I removed the file to disable the conversion warning
> 
> I tested this build and it doesn't give any warnings on this file

This pull request has now been integrated.

Changeset: 67210abd
Author:    Darragh Clarke <Darragh.clarke at oracle.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67210abd04683a3a16ec8af0948030a934e5ce15
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8286394: Address possibly lossy conversions in jdk.naming.dns

Reviewed-by: rriggs, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/10607

From tvaleev at openjdk.org  Sat Oct  8 15:35:14 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 8 Oct 2022 15:35:14 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v2]
In-Reply-To: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
Message-ID: <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>

> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Remove Random -> ThreadLocalRandom change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10520/files
  - new: https://git.openjdk.org/jdk/pull/10520/files/40a69fec..6fa7d942

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=00-01

  Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10520.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10520/head:pull/10520

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Sat Oct  8 15:35:14 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 8 Oct 2022 15:35:14 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface
In-Reply-To: <V9yXPiTULzDOnfUvs_8TsdhODsZnePVpIWnai0lmW1E=.ea069d1b-a8b3-4640-b0fb-5ae7612ea293@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <V9yXPiTULzDOnfUvs_8TsdhODsZnePVpIWnai0lmW1E=.ea069d1b-a8b3-4640-b0fb-5ae7612ea293@github.com>
Message-ID: <i2kcppANELX9NojIChjHr0TLVAEP5Dd0pm2kgeOExec=.df275f40-6734-468e-bdb4-2dd11d0299a3@github.com>

On Mon, 3 Oct 2022 21:46:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> See my comments in [JDK-8218282](https://bugs.openjdk.org/browse/JDK-8218282). While updating the one-arg Collections::shuffle to use ThreadLocalRandom seems obvious, it's not clear to me that we actually want to do that.

@stuart-marks thank you for the information. As this part is controversial, and there's a separate issue for it, I'll remove it from my PR and edit the description, so it could be addressed separately.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From xgong at openjdk.org  Sat Oct  8 15:36:32 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sat, 8 Oct 2022 15:36:32 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <XrjIlTKui_L8wN6LbEub4sv4DbaPOXhWOLop6Hnqbf4=.d74fd93f-ffcb-49b1-81f6-e8354b8ac0b7@github.com>

On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

Ping again, could anyone please help to take a review at this PR? Thanks in advance!

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From duke at openjdk.org  Sat Oct  8 15:57:56 2022
From: duke at openjdk.org (Justin Lu)
Date: Sat, 8 Oct 2022 15:57:56 GMT
Subject: Integrated: 8170389: java.text.DigitList.getDouble() : Controversy
 between javadoc and code
In-Reply-To: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
References: <agMC30gc4BtByOvN1NXvtvXfLtPWWkXltMNn0E5K2tM=.1d6608f0-8c4c-4609-a783-aff6d165339e@github.com>
Message-ID: <8QANQhHWbnz5NUvGHZyvrzhKrJXDWEPGF0pFoyAEHR4=.5d5bf433-f7be-4510-88df-4b1da84cb2ee@github.com>

On Tue, 4 Oct 2022 23:11:57 GMT, Justin Lu <duke at openjdk.org> wrote:

> Problem: Outdated doc does not match code. Claimed to throw exception and compared to Long method.
> Fix: Update doc to match code, compared to Double.parseDouble() accordingly.

This pull request has now been integrated.

Changeset: d39d8c85
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d39d8c856a7f659c8835084e88e70989ad664ecc
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8170389: java.text.DigitList.getDouble() : Controversy between javadoc and code

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/10567

From duke at openjdk.org  Sat Oct  8 21:45:29 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 8 Oct 2022 21:45:29 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME [v2]
In-Reply-To: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
Message-ID: <suHBL5GnTS5Nw6esZyFgRclwM8Ytib0-G7QVC42sTaw=.7fcd0ba1-29b3-4be8-bf07-b27eb04e6c01@github.com>

> Fixes 8294541

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Fixed two more reported cases using 1.2 GiB

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10524/files
  - new: https://git.openjdk.org/jdk/pull/10524/files/394b68fa..6dda3f1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10524&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10524&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10524.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10524/head:pull/10524

PR: https://git.openjdk.org/jdk/pull/10524

From duke at openjdk.org  Sat Oct  8 21:45:31 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 8 Oct 2022 21:45:31 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME
In-Reply-To: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
Message-ID: <55-Su89ZSrAO2Qam1ffA5RbOl-T4N_hTguh21qLKNec=.80a4e955-83ba-4324-a5bb-13eacaa617c7@github.com>

On Sat, 1 Oct 2022 17:54:37 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes 8294541

I increased `-Xmx` from 1G to 1.2G, and cannot reproduce the reported cases anymore. I gave it ten more random attempts which all passed, too.

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From alanb at openjdk.org  Sun Oct  9 06:51:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 9 Oct 2022 06:51:09 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME [v2]
In-Reply-To: <suHBL5GnTS5Nw6esZyFgRclwM8Ytib0-G7QVC42sTaw=.7fcd0ba1-29b3-4be8-bf07-b27eb04e6c01@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
 <suHBL5GnTS5Nw6esZyFgRclwM8Ytib0-G7QVC42sTaw=.7fcd0ba1-29b3-4be8-bf07-b27eb04e6c01@github.com>
Message-ID: <O_L1y1-gGgi4R69WHAGa_fgAU7wuxgG3dgMLjLdbilg=.20870743-fceb-4859-b796-3abb936c98fb@github.com>

On Sat, 8 Oct 2022 21:45:29 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes 8294541
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed two more reported cases using 1.2 GiB

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From alanb at openjdk.org  Sun Oct  9 06:51:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 9 Oct 2022 06:51:09 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME
In-Reply-To: <55-Su89ZSrAO2Qam1ffA5RbOl-T4N_hTguh21qLKNec=.80a4e955-83ba-4324-a5bb-13eacaa617c7@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
 <55-Su89ZSrAO2Qam1ffA5RbOl-T4N_hTguh21qLKNec=.80a4e955-83ba-4324-a5bb-13eacaa617c7@github.com>
Message-ID: <33OtzLgT08r6xIV1l9lbFVaF5HFtzwBkXH-4ls0JVrk=.941ba39e-20ae-4b55-960f-f501ea32c261@github.com>

On Sat, 8 Oct 2022 21:40:37 GMT, Markus KARG <duke at openjdk.org> wrote:

> I increased `-Xmx` from 1G to 1.2G, and cannot reproduce the reported cases anymore. I gave it ten more random attempts which all passed, too.

I did some testing with this value and it does seem be enough.  The alternative is to reduce MAX_SIZE_INCR.

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From jwaters at openjdk.org  Sun Oct  9 08:14:46 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 9 Oct 2022 08:14:46 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
Message-ID: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>

The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.

-------------

Commit messages:
 - Remove Windows specific JLI_Snprintf implementation
 - Remove Windows JLI_Snprintf definition

Changes: https://git.openjdk.org/jdk/pull/10625/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295017
  Stats: 43 lines in 2 files changed: 9 ins; 34 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10625.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10625/head:pull/10625

PR: https://git.openjdk.org/jdk/pull/10625

From jwaters at openjdk.org  Sun Oct  9 08:17:15 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 9 Oct 2022 08:17:15 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v2]
In-Reply-To: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
Message-ID: <h2EFnW0YCl3H5Dv-QxhFvpejOM9clpe_YtIFoAUtDgI=.9c3167e4-5dc6-490b-86da-e8bb7a796787@github.com>

> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Comment formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10625/files
  - new: https://git.openjdk.org/jdk/pull/10625/files/d021c774..35de1467

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10625.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10625/head:pull/10625

PR: https://git.openjdk.org/jdk/pull/10625

From duke at openjdk.org  Sun Oct  9 08:24:20 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Oct 2022 08:24:20 GMT
Subject: RFR: 8294541 - java/io/BufferedInputStream/TransferTo.java fails
 with OOME [v2]
In-Reply-To: <suHBL5GnTS5Nw6esZyFgRclwM8Ytib0-G7QVC42sTaw=.7fcd0ba1-29b3-4be8-bf07-b27eb04e6c01@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
 <suHBL5GnTS5Nw6esZyFgRclwM8Ytib0-G7QVC42sTaw=.7fcd0ba1-29b3-4be8-bf07-b27eb04e6c01@github.com>
Message-ID: <yQ5TbQxWC5n1cnpqeAfH3GjKaON_C-UjurPA45tIf5o=.fc265db3-4154-4646-ace7-849298035446@github.com>

On Sat, 8 Oct 2022 21:45:29 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes 8294541
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed two more reported cases using 1.2 GiB

Did a final test with `MIN_SIZE = 100_000_000` and it did pass. So I agree that it should be safe to /integrate now. Thanks, Alan! :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From aefimov at openjdk.org  Sun Oct  9 11:52:18 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Sun, 9 Oct 2022 11:52:18 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Refactor checkInput, better reporting for invalid filter patterns
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/1a5e83e0..091677e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=00-01

  Stats: 20702 lines in 557 files changed: 11293 ins; 7286 del; 2123 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Sun Oct  9 11:52:19 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Sun, 9 Oct 2022 11:52:19 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
Message-ID: <iIX4TKhkeic7UYz3cnTnQCpdadV80j4EHCbDGB6Wyww=.603d6594-cecd-4d94-a889-c0a816288849@github.com>

On Thu, 6 Oct 2022 16:10:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Refactor checkInput, better reporting for invalid filter patterns
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Additional comments/formatting cleanup.
>>  - More tests clean-up. Code/doc comments cleanup.
>>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation
>
> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 91:
> 
>> 89:     }
>> 90: 
>> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {
> 
> This construct in which the supplied lambda fills in the serialClass is pretty obscure. 
> Perhaps the variable name can be "serialClass" to match the only non-default method in ObjectInputFilter would give a better hint.

Thanks - `serialClass` name reads better.

> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 92:
> 
>> 90: 
>> 91:     private static boolean checkInput(String scheme, FactoryInfo factoryInfo) {
>> 92:         Status result = switch(scheme) {
> 
> The handling of the selection of the filter could be more direct.
> You can change the argument to checkInput to be ObjectInputFilter and pass the desired filter; LDAP_FILTER, RMI_FITLER, or GLOBAL_FILTER.
> And make the check of the GLOBAL_FILTER conditional on it not having already been evaluated.
> Then it will be the case that there must always be a specific filter.
> 
> The callers are all local to the class and would change to pass the desired filter.

Thank you - refactored as suggested.

> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 173:
> 
>> 171:                                            DEFAULT_GLOBAL_SP_VALUE));
>> 172: 
>> 173:     // A system-wide LDAP specific object factories filter constructed from the system
> 
> Where does the IllegalArgumentException from ObjectInputFilter.create get handled or reported?
> If the property value is illformed, the error should be enough to diagnose and correct the property.

That is a good point - the current state of reporting for a malformed filter pattern can be improved:
First filter check with `check*Filter` throws `java.lang.ExceptionInInitializerError` with a cause set to `java.lang.IllegalArgumentException` with filter pattern error. But subsequent checks throw `java.lang.NoClassDefFoundError: Could not initialize class com.sun.naming.internal.ObjectFactoriesFilter`.

To address that one interface and two new records have been added to represent a factory filter state:
 - `ConfiguredFilter` - interface for representing a filter created with `ObjectInputFilter.create` from a pattern.
 - `ValidFilter implements ConfiguredFilter` - stores `ObjectInputFilter` constructed from a valid filter pattern.
 - `InvalidFilter implements ConfiguredFilter` - stores `IllegalArgumentException` generated by parsing of an invalid filter pattern. The stored `IAE` is used to report malformed filter pattern each time specific filter is consulted.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Sun Oct  9 11:53:55 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Sun, 9 Oct 2022 11:53:55 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <y-Jnl54-CrqTmGiyh5tnBy1vIHBduFUPS8CchzEBzyw=.54948997-dbf6-446d-b964-94e2352a8020@github.com>
Message-ID: <fWzSIKrBYtbLZJ06p_xubuo6L6I4PkRpYuY_Ytp_6As=.e80026a6-667f-4e99-b3b6-34e09ca8b456@github.com>

On Thu, 6 Oct 2022 16:24:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Refactor checkInput, better reporting for invalid filter patterns
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Additional comments/formatting cleanup.
>>  - More tests clean-up. Code/doc comments cleanup.
>>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation
>
> test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java line 46:
> 
>> 44:  * @build LDAPServer LDAPTestUtils TestFactory
>> 45:  *
>> 46:  * @run main/othervm LdapFactoriesFilterTest false
> 
> Are any of these filter property cases, malformed and would produce an error from ObjectInputFilter.create?

There were no such cases.
Now, RMI and LDAP tests have been modified to run with malformed filter patterns which produce an error from `ObjectInputFilter.create`. 
Also, new cases were added to check that illegal patterns in one of RMI or LDAP filters not preventing other one from being used.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From duke at openjdk.org  Sun Oct  9 13:58:57 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Oct 2022 13:58:57 GMT
Subject: Integrated: 8294541 - java/io/BufferedInputStream/TransferTo.java
 fails with OOME
In-Reply-To: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
References: <u6N9wnRnNl3Y7mRgGl-ZJTFFQoIvmSPfoJDbxjDKhhw=.3e421f42-d4ca-4dea-98e9-e5c7d88720f6@github.com>
Message-ID: <QMs7nklcpAoGI97_3fZypWwbFtXGoZHh_QzvqTsT63o=.155122cc-d04e-492e-8707-ac1c423a1617@github.com>

On Sat, 1 Oct 2022 17:54:37 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes 8294541

This pull request has now been integrated.

Changeset: 8713dfa6
Author:    Markus Karg <markus at headcrashing.eu>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8713dfa64ef4c55c8b9a3be8aab2bb5e16c627da
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

8294541: java/io/BufferedInputStream/TransferTo.java fails with OOME

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/10524

From duke at openjdk.org  Sun Oct  9 14:08:40 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Oct 2022 14:08:40 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos [v2]
In-Reply-To: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
Message-ID: <2yCtIvt-Xj22wNiupyJmcMn33dJSax8eleycjgMqoNg=.94d67626-23d3-4b07-b9c2-7148f3df7227@github.com>

> Fixes JDK-8294702

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Modified to < 0 as proposed by Alan Batement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10528/files
  - new: https://git.openjdk.org/jdk/pull/10528/files/9b8310ad..8fefccfc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10528&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10528&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10528.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10528/head:pull/10528

PR: https://git.openjdk.org/jdk/pull/10528

From duke at openjdk.org  Sun Oct  9 14:08:41 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Oct 2022 14:08:41 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos [v2]
In-Reply-To: <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>
 <91DREBRbEGaHsnU6yXl89oMf3SRJBLnsUh30Vb-n_x4=.800d2f58-53f6-4a39-b120-3cb8e58cbb94@github.com>
 <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>
Message-ID: <nqmeUBp4JBvIz_jQr493dRtvILSmKoWSS2sKojqOk38=.fd7cd183-2c67-4faa-a184-9c3f8fdce70e@github.com>

On Tue, 4 Oct 2022 15:53:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change *here*, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?
>
>> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change _here_, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?
> 
> This looks to be the only that would corrupt the current position (pos). 
> 
> @bplb plans to look at this too, another set of eyes would be good on this point.

@AlanBateman Checking `< 0` just here, as per your proposal. ? 

@bplb Kindly requesting `/sponsor`. ?

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From duke at openjdk.org  Sun Oct  9 14:09:56 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Oct 2022 14:09:56 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <tVTC5lYv8cHkQExVd2mUHo5j2FeWm5FWwyhGoSxQU70=.cad5cab8-706c-4b5a-9e24-778c02eba677@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

@bplb Kindly requesting review. ?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From kbarrett at openjdk.org  Sun Oct  9 18:00:57 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 18:00:57 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v2]
In-Reply-To: <h2EFnW0YCl3H5Dv-QxhFvpejOM9clpe_YtIFoAUtDgI=.9c3167e4-5dc6-490b-86da-e8bb7a796787@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <h2EFnW0YCl3H5Dv-QxhFvpejOM9clpe_YtIFoAUtDgI=.9c3167e4-5dc6-490b-86da-e8bb7a796787@github.com>
Message-ID: <kGXpji39JjfxotSflD-mCrkijgrAVejZRUesFPtKUto=.41401ab1-bee8-4ca7-98e9-acb363f5d0c2@github.com>

On Sun, 9 Oct 2022 08:17:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment formatting

src/java.base/share/native/libjli/jli_util.h line 91:

> 89:  * https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference
> 90:  * /snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
> 91:  */

I don't think the comment about the *lack* of a workaround is needed, just adding clutter.  But this isn't code I have much involvement with.  Other than that, the change looks fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10625

From dholmes at openjdk.org  Mon Oct 10 04:39:01 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 04:39:01 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v14]
In-Reply-To: <mtKKcCUpQeelxOO2Xpgm4uxXIEQpbSgYrXduYcEsOdw=.91d14691-aac9-4691-baee-cfde0adaae86@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <mtKKcCUpQeelxOO2Xpgm4uxXIEQpbSgYrXduYcEsOdw=.91d14691-aac9-4691-baee-cfde0adaae86@github.com>
Message-ID: <mumKK5K4ngw0VgVWBpxYRpAn9hgDI6QwsSfY_H5Ez4s=.43f8f8fe-57d3-4622-b8e8-1a6152eb7037@github.com>

On Thu, 6 Oct 2022 12:45:08 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues.
>> 
>> See https://bugs.openjdk.org/browse/JDK-8292016 and the related Pull Request for the reason that the existing JLI error reporting utility was not used in this enhancement
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-4
>  - Merge branch 'openjdk:master' into patch-4
>  - Use - instead of : as a separator
>  - Merge branch 'openjdk:master' into patch-4
>  - Make DLL_ERROR4 look a little better without changing what it means
>  - Revert changes to JLI_ReportErrorMessageSys
>  - Update java_md.c
>  - Update java_md.h
>  - Merge branch 'openjdk:master' into patch-4
>  - Merge branch 'openjdk:master' into patch-4
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/fe291396...c3113cac

src/java.base/windows/native/libjli/java_md.h line 48:

> 46:  */
> 47: 
> 48: void reportWithLastWindowsError(const char* message, ...);

Why does this need to be exported in the header file? Are you expecting other code to call this?

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From dholmes at openjdk.org  Mon Oct 10 05:17:41 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 05:17:41 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v2]
In-Reply-To: <h2EFnW0YCl3H5Dv-QxhFvpejOM9clpe_YtIFoAUtDgI=.9c3167e4-5dc6-490b-86da-e8bb7a796787@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <h2EFnW0YCl3H5Dv-QxhFvpejOM9clpe_YtIFoAUtDgI=.9c3167e4-5dc6-490b-86da-e8bb7a796787@github.com>
Message-ID: <ODEZte4zq2T_i4l3gc0t4cjc-5PUMQ1DrlZPC7HotEk=.03ee2927-2b64-4410-9f43-e24c4b05e052@github.com>

On Sun, 9 Oct 2022 08:17:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment formatting

Looks good modulo the comment block.

-------------

PR: https://git.openjdk.org/jdk/pull/10625

From dholmes at openjdk.org  Mon Oct 10 05:17:43 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 05:17:43 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v2]
In-Reply-To: <kGXpji39JjfxotSflD-mCrkijgrAVejZRUesFPtKUto=.41401ab1-bee8-4ca7-98e9-acb363f5d0c2@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <h2EFnW0YCl3H5Dv-QxhFvpejOM9clpe_YtIFoAUtDgI=.9c3167e4-5dc6-490b-86da-e8bb7a796787@github.com>
 <kGXpji39JjfxotSflD-mCrkijgrAVejZRUesFPtKUto=.41401ab1-bee8-4ca7-98e9-acb363f5d0c2@github.com>
Message-ID: <R0u67J14fLJD2ooajt1tL3nHMJwrLx64lFiXFozJgbo=.afed8856-1511-4191-b039-f722133e2977@github.com>

On Sun, 9 Oct 2022 17:58:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment formatting
>
> src/java.base/share/native/libjli/jli_util.h line 91:
> 
>> 89:  * https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference
>> 90:  * /snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 91:  */
> 
> I don't think the comment about the *lack* of a workaround is needed, just adding clutter.  But this isn't code I have much involvement with.  Other than that, the change looks fine.

I agree, we don't document the absence of a workaround.

-------------

PR: https://git.openjdk.org/jdk/pull/10625

From jpai at openjdk.org  Mon Oct 10 07:21:54 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 07:21:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <o7TrYfjkQIrkZNh298CrsjG1huBZFuCsEMo6tIhqXEE=.6acdcc2a-a59f-4dbe-ba23-f56c05b5de1c@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 29:

> 27: 
> 28: import jdk.jfr.*;
> 29: import jdk.jfr.internal.MirrorEvent;

Hello Sean, this `MirrorEvent` appears to be an unused import. Furthermore, as far as I know, in `core-libs` the `*` wildcard imports aren't typically used. I don't know if it's OK to use it here in the `jdk.jfr` module.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From jpai at openjdk.org  Mon Oct 10 07:25:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 07:25:52 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <qbACrjxw4wqSsVAbuSIznhXSphkW2gn1fIs-q2RD9e4=.a645aa14-4d28-4f3a-b4e5-ffdc8f261f28@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 318:

> 316:                 InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
> 317:                 e.key = (String) entry.getKey();
> 318:                 e.value = (String) entry.getValue();

To avoid any (odd/unexpected) `ClassCastException` here, perhaps this loop can be changed to something like:

for (Set<String> name : p.stringPropertyNames()) {
    InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
    e.key = name;
    e.value = p.getProperty(name);

Since this code anyway wants to deal with string key/values, this wouldn't introduce any functional change and yet at the same time prevent any unexpected/theoretical `ClassCastException`s

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From alanb at openjdk.org  Mon Oct 10 07:33:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Oct 2022 07:33:53 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/java.base/share/classes/java/security/ProtectionDomain.java line 76:

> 74:     static class JavaSecurityAccessImpl implements JavaSecurityAccess {
> 75:         /* cache a copy for recording purposes */
> 76:         static Properties initialSecurityProperties;

This doesn't look very clean. Could the Security class hold the initial security properties and provide an accessor method that JavaSecurityAccess:getIinitialProperties could use?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From jpai at openjdk.org  Mon Oct 10 08:10:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 08:10:58 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 33:

> 31: @Category({"Java Development Kit", "Security"})
> 32: @Label("Initial Security Property")
> 33: @Name("jdk.InitialSecurityProperty")

Should we name this to `jdk.InitialSecurityProperties` and the label to `Initial Security Properties`, to be more accurate?

src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 35:

> 33: @Name("jdk.InitialSecurityProperty")
> 34: @Description("Initial Security Properties")
> 35: public final class InitialSecurityPropertyEvent extends AbstractJDKEvent {

The event naming guidelines here https://docs.oracle.com/en/java/javase/17/jfapi/guidelines-naming-and-labeling-events.html recommend leaving out `Event` from the class name. So, maybe we should call this `InitialSecurityProperties`?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aturbanov at openjdk.org  Mon Oct 10 10:17:48 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 10 Oct 2022 10:17:48 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
Message-ID: <K6x6H3pf32exC22lIpC-dqxbW-qKzRiuKioq11y6DTw=.8c34b910-2472-4221-926b-9afa38f3bc2f@github.com>

On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for 0 security events

test/jdk/java/security/Security/ConfigFileTest.java line 132:

> 130:                         .shouldNotContain(EXPECTED_DEBUG_OUTPUT)
> 131:                         .shouldNotContain(UNEXPECTED_DEBUG_OUTPUT);
> 132:             } else{

let's add one space after `else`

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From egahlin at openjdk.org  Mon Oct 10 10:33:11 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 10 Oct 2022 10:33:11 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
Message-ID: <TOy9MQJ0WIHlFSzciiyVssrPo1qHV67m8pR5f1zgkUs=.848fd2b0-2701-4b13-b5a7-4a6e4d205454@github.com>

On Mon, 10 Oct 2022 08:06:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 35:
> 
>> 33: @Name("jdk.InitialSecurityProperty")
>> 34: @Description("Initial Security Properties")
>> 35: public final class InitialSecurityPropertyEvent extends AbstractJDKEvent {
> 
> The event naming guidelines here https://docs.oracle.com/en/java/javase/17/jfapi/guidelines-naming-and-labeling-events.html recommend leaving out `Event` from the class name. So, maybe we should call this `InitialSecurityProperties`?

The documentation is somewhat misleading. If the event has a name annotation, I think it's fine to call the class Event, because name will override the class name.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aturbanov at openjdk.org  Mon Oct 10 10:35:01 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 10 Oct 2022 10:35:01 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
Message-ID: <Y85uuln2T09SqeRPceibPlJTK_D8axQNXgseWiY9UZo=.12d07524-8e08-4d1e-8bde-8fdf1f20c706@github.com>

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor hotspot gtest
>  - Separate into function. Fix comment.

test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 224:

> 222:             "1:name=systemd:/user.slice/user-1000.slice/user at 1000.service/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-3c00b338-5b65-439f-8e97-135e183d135d.scope\n" +
> 223:             "0::/user.slice/user-1000.slice/user at 1000.service/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-3c00b338-5b65-439f-8e97-135e183d135d.scope\n";
> 224:     private  String cgroupv1SelfPrefixContent = "9:memory:/user.slice/user-1000.slice/session-3.scope\n";

Let's remove one redundant space
Suggestion:

    private String cgroupv1SelfPrefixContent = "9:memory:/user.slice/user-1000.slice/session-3.scope\n";

-------------

PR: https://git.openjdk.org/jdk/pull/8629

From dfuchs at openjdk.org  Mon Oct 10 11:21:46 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Oct 2022 11:21:46 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
Message-ID: <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>

On Sun, 9 Oct 2022 11:52:18 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Refactor checkInput, better reporting for invalid filter patterns
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Additional comments/formatting cleanup.
>  - More tests clean-up. Code/doc comments cleanup.
>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

Changes requested by dfuchs (Reviewer).

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 99:

> 97:             return globalResult == Status.ALLOWED;
> 98:         }
> 99: 

If I'm not mistaken there's  no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From egahlin at openjdk.org  Mon Oct 10 11:31:54 2022
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 10 Oct 2022 11:31:54 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
Message-ID: <a3WRkH2oSRMn1ifrGEgOsTMHB9xT6O44qEijZdpB4OA=.37e9a8f5-cc82-48a3-98cf-f19a3ebceb0e@github.com>

On Mon, 10 Oct 2022 08:04:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 33:
> 
>> 31: @Category({"Java Development Kit", "Security"})
>> 32: @Label("Initial Security Property")
>> 33: @Name("jdk.InitialSecurityProperty")
> 
> Should we name this to `jdk.InitialSecurityProperties` and the label to `Initial Security Properties`, to be more accurate?

There is one property per event, so it uses the same naming convention as jdk.InitialSystemProperty

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From jwaters at openjdk.org  Mon Oct 10 11:59:55 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 11:59:55 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v3]
In-Reply-To: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
Message-ID: <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>

> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Comment documenting change isn't required
 - Merge branch 'openjdk:master' into patch-1
 - Comment formatting
 - Remove Windows specific JLI_Snprintf implementation
 - Remove Windows JLI_Snprintf definition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10625/files
  - new: https://git.openjdk.org/jdk/pull/10625/files/35de1467..9149aae1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=01-02

  Stats: 104 lines in 6 files changed: 2 ins; 97 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10625.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10625/head:pull/10625

PR: https://git.openjdk.org/jdk/pull/10625

From jwaters at openjdk.org  Mon Oct 10 12:00:53 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 12:00:53 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v14]
In-Reply-To: <mumKK5K4ngw0VgVWBpxYRpAn9hgDI6QwsSfY_H5Ez4s=.43f8f8fe-57d3-4622-b8e8-1a6152eb7037@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <mtKKcCUpQeelxOO2Xpgm4uxXIEQpbSgYrXduYcEsOdw=.91d14691-aac9-4691-baee-cfde0adaae86@github.com>
 <mumKK5K4ngw0VgVWBpxYRpAn9hgDI6QwsSfY_H5Ez4s=.43f8f8fe-57d3-4622-b8e8-1a6152eb7037@github.com>
Message-ID: <viMRjrZ8ZmZZ0jqFstr0CixAH4_vBELpZLPC4ocIDQ8=.3a8310cb-6028-43e6-9321-b7365695d9b9@github.com>

On Mon, 10 Oct 2022 04:35:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-4
>>  - Merge branch 'openjdk:master' into patch-4
>>  - Use - instead of : as a separator
>>  - Merge branch 'openjdk:master' into patch-4
>>  - Make DLL_ERROR4 look a little better without changing what it means
>>  - Revert changes to JLI_ReportErrorMessageSys
>>  - Update java_md.c
>>  - Update java_md.h
>>  - Merge branch 'openjdk:master' into patch-4
>>  - Merge branch 'openjdk:master' into patch-4
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ad28ef9e...c3113cac
>
> src/java.base/windows/native/libjli/java_md.h line 48:
> 
>> 46:  */
>> 47: 
>> 48: void reportWithLastWindowsError(const char* message, ...);
> 
> Why does this need to be exported in the header file? Are you expecting other code to call this?

I left that in there since it would possibly be a useful utility to have for other JLI code that might need to work with Windows errors in the future

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From jwaters at openjdk.org  Mon Oct 10 11:59:56 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 11:59:56 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v2]
In-Reply-To: <R0u67J14fLJD2ooajt1tL3nHMJwrLx64lFiXFozJgbo=.afed8856-1511-4191-b039-f722133e2977@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <h2EFnW0YCl3H5Dv-QxhFvpejOM9clpe_YtIFoAUtDgI=.9c3167e4-5dc6-490b-86da-e8bb7a796787@github.com>
 <kGXpji39JjfxotSflD-mCrkijgrAVejZRUesFPtKUto=.41401ab1-bee8-4ca7-98e9-acb363f5d0c2@github.com>
 <R0u67J14fLJD2ooajt1tL3nHMJwrLx64lFiXFozJgbo=.afed8856-1511-4191-b039-f722133e2977@github.com>
Message-ID: <_02cjOK0AMcoTHXGR7nW9TTqm-2ECZCXj6iHgWHZt9k=.c3277263-7aeb-4d3d-a0ac-5afb0f749047@github.com>

On Mon, 10 Oct 2022 05:06:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/native/libjli/jli_util.h line 91:
>> 
>>> 89:  * https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference
>>> 90:  * /snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>>> 91:  */
>> 
>> I don't think the comment about the *lack* of a workaround is needed, just adding clutter.  But this isn't code I have much involvement with.  Other than that, the change looks fine.
>
> I agree, we don't document the absence of a workaround.

Removed the comment as requested

-------------

PR: https://git.openjdk.org/jdk/pull/10625

From jwaters at openjdk.org  Mon Oct 10 12:05:59 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 12:05:59 GMT
Subject: RFR: 8292016: Cleanup legacy error reporting in the JDK outside of
 HotSpot [v35]
In-Reply-To: <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
 <Aj-SIAPpZXnvYGfPLlgjYLQKb-hISCw_oSfh1l3Cw2k=.7ee6fbd8-1665-4aad-bbe1-39ec2d933399@github.com>
Message-ID: <6WwMRowvN-kQ7FarkLaqvoTzuri379ZdSHuTiwlXbXo=.32112bd1-0aa0-46a6-8b35-5209cc969d3d@github.com>

On Mon, 3 Oct 2022 13:37:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> A large section of error reporting code in the JDK does not properly handle WIN32 API errors and instead mixes them with errors originating from C. Since they can be rather easily replaced and coming up with an elegant solution proved to be too much of a hassle to be worth it, and some of the concerns they address no longer are an issue with current versions of the platforms supported by the JDK, they can be easily removed without much effect. The remaining utilities that are still needed now instead report directly from strerror, with a new subsystem for WIN32 errors put in place wherever required, to minimize confusion when they are used, which was a problem with earlier solutions to this issue.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naming

Closing - Will narrow the fix to JLI for now in another changeset

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From jwaters at openjdk.org  Mon Oct 10 12:05:59 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 10 Oct 2022 12:05:59 GMT
Subject: Withdrawn: 8292016: Cleanup legacy error reporting in the JDK outside
 of HotSpot
In-Reply-To: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
References: <LhjyT1fsUX9AYN46ivbrfcYVEVYP57u1hFfSTBofQmg=.d2266045-be6b-4c48-ab8f-076541c04a72@github.com>
Message-ID: <lbP6FFpLWDJhEHdFwCarfmkr9puM5fyi-OJc0Nbihz0=.bb6cd43f-2450-46ac-a926-7006e40ec626@github.com>

On Sun, 14 Aug 2022 16:21:31 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> A large section of error reporting code in the JDK does not properly handle WIN32 API errors and instead mixes them with errors originating from C. Since they can be rather easily replaced and coming up with an elegant solution proved to be too much of a hassle to be worth it, and some of the concerns they address no longer are an issue with current versions of the platforms supported by the JDK, they can be easily removed without much effect. The remaining utilities that are still needed now instead report directly from strerror, with a new subsystem for WIN32 errors put in place wherever required, to minimize confusion when they are used, which was a problem with earlier solutions to this issue.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9870

From aefimov at openjdk.org  Mon Oct 10 12:09:53 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 10 Oct 2022 12:09:53 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
 <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
Message-ID: <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>

On Mon, 10 Oct 2022 11:16:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> If I'm not mistaken there's no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?

Yes - there is no point, and that will reduce number of `checkInput` calls on a specific filter, if it is not the global one. That's how it will look like:

    private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
        var globalFilter = GLOBAL_FILTER.filter();
        var specificFilter = filter.filter();
        Status globalResult = globalFilter.checkInput(serialClass);

        // Check if a specific filter is the global one
        if (filter == GLOBAL_FILTER) {
            return globalResult == Status.ALLOWED;
        }
        return switch (globalResult) {
            case ALLOWED -> specificFilter.checkInput(serialClass) != Status.REJECTED;
            case REJECTED -> false;
            case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
        };
    }


The `if (filter == GLOBAL_FILTER) {` check can be also removed but without it the `checkInput` will be called twice on global filter for the case where `specific == global`, ie call from the `checkGlobalFilter`.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From dfuchs at openjdk.org  Mon Oct 10 13:18:47 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Oct 2022 13:18:47 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
 <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
 <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>
Message-ID: <yUWuUtt0sdbS8tN7ha-M5RT0qobBEoLjWVpjWzgvBJY=.9d6c0165-b200-4165-a9cc-78fcc592865b@github.com>

On Mon, 10 Oct 2022 12:07:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 99:
>> 
>>> 97:             return globalResult == Status.ALLOWED;
>>> 98:         }
>>> 99: 
>> 
>> If I'm not mistaken there's  no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?
>
>> If I'm not mistaken there's no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?
> 
> Yes - there is no point, and that will reduce number of `checkInput` calls on a specific filter, if it is not the global one. That's how it will look like:
> 
>     private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
>         var globalFilter = GLOBAL_FILTER.filter();
>         var specificFilter = filter.filter();
>         Status globalResult = globalFilter.checkInput(serialClass);
> 
>         // Check if a specific filter is the global one
>         if (filter == GLOBAL_FILTER) {
>             return globalResult == Status.ALLOWED;
>         }
>         return switch (globalResult) {
>             case ALLOWED -> specificFilter.checkInput(serialClass) != Status.REJECTED;
>             case REJECTED -> false;
>             case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
>         };
>     }
> 
> 
> The `if (filter == GLOBAL_FILTER) {` check can be also removed but without it the `checkInput` will be called twice on global filter for the case where `specific == global`, ie call from the `checkGlobalFilter`.

The code above LGTM. An alternative could be:


    private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
        var globalFilter = GLOBAL_FILTER.filter();
        var specificFilter = filter.filter();
        Status globalResult = globalFilter.checkInput(serialClass);

        return switch (globalResult) {
            case ALLOWED -> filter == GLOBAL || specificFilter.checkInput(serialClass) != Status.REJECTED;
            case REJECTED -> false;
            case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
        };
    }


but I believe your proposed code reads better.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Mon Oct 10 13:23:14 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Oct 2022 13:23:14 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <a3WRkH2oSRMn1ifrGEgOsTMHB9xT6O44qEijZdpB4OA=.37e9a8f5-cc82-48a3-98cf-f19a3ebceb0e@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <eGyUThcjXuJgWAhE7GgaOpuUsTOERCmDvFJVYR3qfQo=.fe06e149-93b2-49cb-97cb-e8f19a449173@github.com>
 <a3WRkH2oSRMn1ifrGEgOsTMHB9xT6O44qEijZdpB4OA=.37e9a8f5-cc82-48a3-98cf-f19a3ebceb0e@github.com>
Message-ID: <JbBf_7VgjgdDMdBE2Y1KsK0WIqTjYpGb_KmEFQWSOuc=.02cee9e2-882e-4c98-a49b-5719d6901964@github.com>

On Mon, 10 Oct 2022 11:29:52 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 33:
>> 
>>> 31: @Category({"Java Development Kit", "Security"})
>>> 32: @Label("Initial Security Property")
>>> 33: @Name("jdk.InitialSecurityProperty")
>> 
>> Should we name this to `jdk.InitialSecurityProperties` and the label to `Initial Security Properties`, to be more accurate?
>
> There is one property per event, so it uses the same naming convention as jdk.InitialSystemProperty

You are right indeed - I overlooked the part where this PR loops over these properties and creates one event per property.

>> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 35:
>> 
>>> 33: @Name("jdk.InitialSecurityProperty")
>>> 34: @Description("Initial Security Properties")
>>> 35: public final class InitialSecurityPropertyEvent extends AbstractJDKEvent {
>> 
>> The event naming guidelines here https://docs.oracle.com/en/java/javase/17/jfapi/guidelines-naming-and-labeling-events.html recommend leaving out `Event` from the class name. So, maybe we should call this `InitialSecurityProperties`?
>
> The documentation is somewhat misleading. If the event has a name annotation, I think it's fine to call the class Event, because name will override the class name.

Thank you Erik for that detail. Looks fine to me then.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mullan at openjdk.org  Mon Oct 10 14:22:48 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Oct 2022 14:22:48 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
Message-ID: <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>

On Mon, 10 Oct 2022 07:31:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/java.base/share/classes/java/security/ProtectionDomain.java line 76:
> 
>> 74:     static class JavaSecurityAccessImpl implements JavaSecurityAccess {
>> 75:         /* cache a copy for recording purposes */
>> 76:         static Properties initialSecurityProperties;
> 
> This doesn't look very clean. Could the Security class hold the initial security properties and provide an accessor method that JavaSecurityAccess:getIinitialProperties could use?

Agree, and alternatively, it seems cleaner to add a new SharedSecrets class for `java.security.Security` and remove the dependency on PD.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aefimov at openjdk.org  Mon Oct 10 14:28:07 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 10 Oct 2022 14:28:07 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Change checkInput to be the global filter centric

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/091677e9..528489b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=01-02

  Stats: 10 lines in 1 file changed: 2 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Mon Oct 10 14:28:07 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 10 Oct 2022 14:28:07 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v2]
In-Reply-To: <yUWuUtt0sdbS8tN7ha-M5RT0qobBEoLjWVpjWzgvBJY=.9d6c0165-b200-4165-a9cc-78fcc592865b@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <TxvpJvwZDS5zUt3vkzyE-_BylDdqpvO0zJL1p1tKkUk=.55af0baf-2cb4-440f-a752-cc9b74bd6834@github.com>
 <oKoUiJM3hEdhR9GBx_GrgjHiEr4UqglFgfQwZHWsSNk=.b100b032-e6d7-496a-bf07-ae5359e71c87@github.com>
 <4YGkWQ0wZfSZrB3GFRGqLK_sQM-vXBzlAHTng-FYbnU=.398da33d-0a1f-4db7-99e9-ed7b3e35f7a1@github.com>
 <yUWuUtt0sdbS8tN7ha-M5RT0qobBEoLjWVpjWzgvBJY=.9d6c0165-b200-4165-a9cc-78fcc592865b@github.com>
Message-ID: <0hkdcfr9GPSGfL4O5O09w97gG5i8-EA9gDikAWxlmLs=.ffa91af6-2232-40d9-acf2-6c7f67d46228@github.com>

On Mon, 10 Oct 2022 13:14:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> If I'm not mistaken there's no point in checking the specific filter if the global filter state is REJECTED. So instead of switching on the specificResult below, maybe you should change the logic to switch on the globalResult instead and only call the specific filter if needed?
>> 
>> Yes - there is no point, and that will reduce number of `checkInput` calls on a specific filter, if it is not the global one. That's how it will look like:
>> 
>>     private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
>>         var globalFilter = GLOBAL_FILTER.filter();
>>         var specificFilter = filter.filter();
>>         Status globalResult = globalFilter.checkInput(serialClass);
>> 
>>         // Check if a specific filter is the global one
>>         if (filter == GLOBAL_FILTER) {
>>             return globalResult == Status.ALLOWED;
>>         }
>>         return switch (globalResult) {
>>             case ALLOWED -> specificFilter.checkInput(serialClass) != Status.REJECTED;
>>             case REJECTED -> false;
>>             case UNDECIDED -> specificFilter.checkInput(serialClass) == Status.ALLOWED;
>>         };
>>     }
>> 
>> 
>> The `if (filter == GLOBAL_FILTER) {` check can be also removed but without it the `checkInput` will be called twice on global filter for the case where `specific == global`, ie call from the `checkGlobalFilter`.
>
> The code above LGTM. An alternative could be:
> 
> 
>     private static boolean checkInput(ConfiguredFilter filter, FactoryInfo serialClass) {
>         var globalFilter = GLOBAL_FILTER.filter();
>         var specificFilter = filter.filter();
>         Status globalResult = globalFilter.checkInput(serialClass);
> 
>         return switch (globalResult) {
>             case ALLOWED -> filter == GLOBAL || specificFilter.checkInput(serialClass) != Status.REJECTED;
>             case REJECTED -> false;
>             case UNDECIDED -> filter != GLOBAL && specificFilter.checkInput(serialClass) == Status.ALLOWED;
>         };
>     }
> 
> 
> but I believe your proposed code reads better.

Thanks - pushed as 528489b

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From dfuchs at openjdk.org  Mon Oct 10 14:41:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Oct 2022 14:41:27 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <I_V0K_pQjNkHO2P2M_JoUAfo_v2muyqOvLZq-PHMeCs=.d66d4a50-07be-4911-8917-8e299758476e@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From prappo at openjdk.org  Mon Oct 10 16:57:21 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 10 Oct 2022 16:57:21 GMT
Subject: Integrated: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited
In-Reply-To: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
Message-ID: <5x7fG0iSo2qnkGEPeTumleeWMpV15E_qSXdIrdVHoUY=.369c8b00-4a6e-4f50-9ca7-62be5556be8e@github.com>

On Tue, 27 Sep 2022 11:43:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
> 
> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
> 
> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
> 
> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
> 
>     public class Subtype extends Supertype {
> 
>         @Override
>         public void m() throws SuperException {
>     ...
> 
>     public class Supertype {
> 
>         /**
>          * @throws SuperException general problem
>          * @throws SubExceptionA  specific problem A
>          * @throws SubExceptionB  specific problem B
>          */
>         public void m() throws SuperException {
>     ...
> 
>     public class SuperException extends Exception {
>     ...
> 
>     public class SubExceptionA extends SuperException {
>     ...
> 
>     public class SubExceptionB extends SuperException {
>     ...
> 
> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
> 
>     public void m()
>            throws SuperException
> 
>     Overrides:
>         m in class Supertype
>     Throws:
>         SuperException - general problem
>         SubExceptionA - specific problem A
>         SubExceptionB - specific problem B 
> 
> It works for checked and unchecked exceptions, for methods in classes and interfaces.
> 
> 
> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
> 
> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
> 
> 
> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

This pull request has now been integrated.

Changeset: eb90c4fc
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb90c4fc0479379c8c1452afca8f37746c762e18
Stats:     320 lines in 14 files changed: 310 ins; 0 del; 10 mod

8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited

Reviewed-by: jjg

-------------

PR: https://git.openjdk.org/jdk/pull/10449

From bhuang at openjdk.org  Mon Oct 10 18:27:48 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 18:27:48 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to validate
 i18n compliance
Message-ID: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>

The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 

In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.

-------------

Commit messages:
 - Update keytool i18n test.

Changes: https://git.openjdk.org/jdk/pull/10635/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294994
  Stats: 407 lines in 2 files changed: 395 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From coffeys at openjdk.org  Mon Oct 10 19:23:51 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 10 Oct 2022 19:23:51 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v4]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <y4e8nEYTOQ4XjLUzOwtzKTQKImMO4yvitpmb5xpQRKk=.a16d72af-bf4c-4792-9a62-ac1437cd705f@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Address Oct 10 review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/f8faecf4..323938d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=02-03

  Stats: 22 lines in 6 files changed: 9 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Mon Oct 10 19:23:52 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 10 Oct 2022 19:23:52 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
Message-ID: <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>

On Mon, 10 Oct 2022 14:19:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/ProtectionDomain.java line 76:
>> 
>>> 74:     static class JavaSecurityAccessImpl implements JavaSecurityAccess {
>>> 75:         /* cache a copy for recording purposes */
>>> 76:         static Properties initialSecurityProperties;
>> 
>> This doesn't look very clean. Could the Security class hold the initial security properties and provide an accessor method that JavaSecurityAccess:getIinitialProperties could use?
>
> Agree, and alternatively, it seems cleaner to add a new SharedSecrets class for `java.security.Security` and remove the dependency on PD.

modified code to have Security class hold the initial properties and provided an accessor method

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Mon Oct 10 19:23:56 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 10 Oct 2022 19:23:56 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <o7TrYfjkQIrkZNh298CrsjG1huBZFuCsEMo6tIhqXEE=.6acdcc2a-a59f-4dbe-ba23-f56c05b5de1c@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <o7TrYfjkQIrkZNh298CrsjG1huBZFuCsEMo6tIhqXEE=.6acdcc2a-a59f-4dbe-ba23-f56c05b5de1c@github.com>
Message-ID: <Zuvegr4Pv59B6shXJosepTjILF-5PEzwNG7zzSZu0xI=.81f11cbd-a06f-422d-9b4c-cac0776ce391@github.com>

On Mon, 10 Oct 2022 07:19:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check for 0 security events
>
> src/jdk.jfr/share/classes/jdk/jfr/events/InitialSecurityPropertyEvent.java line 29:
> 
>> 27: 
>> 28: import jdk.jfr.*;
>> 29: import jdk.jfr.internal.MirrorEvent;
> 
> Hello Sean, this `MirrorEvent` appears to be an unused import. Furthermore, as far as I know, in `core-libs` the `*` wildcard imports aren't typically used. I don't know if it's OK to use it here in the `jdk.jfr` module.

Thanks Jai - I removed the unused import and reverted to non-wildcard import use

> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 318:
> 
>> 316:                 InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
>> 317:                 e.key = (String) entry.getKey();
>> 318:                 e.value = (String) entry.getValue();
> 
> To avoid any (odd/unexpected) `ClassCastException` here, perhaps this loop can be changed to something like:
> 
> for (Set<String> name : p.stringPropertyNames()) {
>     InitialSecurityPropertyEvent e = new InitialSecurityPropertyEvent();
>     e.key = name;
>     e.value = p.getProperty(name);
> 
> Since this code anyway wants to deal with string key/values, this wouldn't introduce any functional change and yet at the same time prevent any unexpected/theoretical `ClassCastException`s

nice - wasn't aware of that method in Properties. Code updated.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From kbarrett at openjdk.org  Mon Oct 10 19:48:46 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 10 Oct 2022 19:48:46 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v3]
In-Reply-To: <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>
Message-ID: <qN2Y5b_Gvmq0y9Vi7Ry281mfrVBwVKapzihgDc2zIFk=.ba7cdf66-00ad-41fc-8725-1e54595b9f80@github.com>

On Mon, 10 Oct 2022 11:59:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Comment documenting change isn't required
>  - Merge branch 'openjdk:master' into patch-1
>  - Comment formatting
>  - Remove Windows specific JLI_Snprintf implementation
>  - Remove Windows JLI_Snprintf definition

Looks good.

-------------

PR: https://git.openjdk.org/jdk/pull/10625

From naoto at openjdk.org  Mon Oct 10 19:54:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Oct 2022 19:54:10 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>

On Mon, 10 Oct 2022 18:18:55 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.

Looks good overall. Some minor suggestions.

test/jdk/sun/security/tools/keytool/i18n.java line 62:

> 60:  * @library /test/lib
> 61:  * @run main/manual/othervm i18n zh CN
> 62:  */

Do you need to triplicate these `@test` tags? Would 3-lines of `@run` suffice?
Also setting the locale by `-Duser.language/country` and `getProperty` them in the main would be preferable to passing them as the test case arguments.

test/jdk/sun/security/tools/keytool/i18n.java line 250:

> 248:     private Thread currentThread = null;
> 249: 
> 250:     public static class DialogBuilder {

This seems to be a boilerplate for displaying the panel. Could this be separated from the test and converted into some library?

test/jdk/sun/security/tools/keytool/i18n.java line 334:

> 332:         } else if (args.length == 2) {
> 333:             Locale.setDefault(Locale.of(args[0], args[1]));
> 334:         }

Can be eliminated with the suggestion above.

test/jdk/sun/security/tools/keytool/i18n.java line 335:

> 333:             Locale.setDefault(Locale.of(args[0], args[1]));
> 334:         }
> 335:         final String LANG = Locale.getDefault().getDisplayLanguage();

Instead of `getDisplayLanguage()`, it should issue `getDisplayName()`, as for `zh-CN` case, it simply displays `Chinese` in the current impl. It's ambiguous whether it is simplified or traditional.
Also, `LANG` should be lowercase, as it is not a constant.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From svkamath at openjdk.org  Mon Oct 10 20:15:54 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 10 Oct 2022 20:15:54 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v8]
In-Reply-To: <Fp6o1eyQn6Q9CJbGMIc9BpRYGV05HvZLyXD5tBLq6L4=.f2d0c5a4-c2d2-406e-8024-69c8c941365b@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com>
 <QdS7Tx2gk2HR7Y-qe6Ig8_QgyGRi5i3k14aERVEHTs4=.b5839efb-e45f-4700-b9d6-7fca6d61cd77@github.com>
 <frb3je6a390Xqi6O21nZc6GVwti4hYcTm0MQZi2EXTk=.56910d50-38bf-4af6-9e16-6766b772b0bd@github.com>
 <m1OYhjDuNDzdJpvJdYw8wxy-GqRRGgTn1nH_tiSVp28=.4073f671-bfad-4778-b823-abca57cb40a6@github.com>
 <xi5R9hmey3jw8jHASbCLtq5tU3gGnu77E7w-qavRFRU=.c6cea845-8d8e-4c7d-9004-f0339decf162@github.com>
 <Fp6o1eyQn6Q9CJbGMIc9BpRYGV05HvZLyXD5tBLq6L4=.f2d0c5a4-c2d2-406e-8024-69c8c941365b@github.com>
Message-ID: <8Hz7TtN3qVWn324XlTdBZCCdUbSQfBFwNudrf65mMIs=.9b78e1af-2a21-469e-961b-607e36884637@github.com>

On Fri, 30 Sep 2022 17:24:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov I spoke too soon. All the GHA tests passed in the dummy draft PR I created using Smita's patch:
>> https://github.com/openjdk/jdk/pull/10500
>> Please take a look. No build failures reported and all tier1 tests passed.
>
>> @sviswa7 The failure is due to [JDK-8293618](https://bugs.openjdk.org/browse/JDK-8293618), @smita-kamath please merge with master. Thanks.
> 
> Yes, I tested with latest JDK sources which includes JDK-8293618.

@vnkozlov, I have implemented all of the reviewers comments. Could you kindly test this patch? Thanks a lot for your help.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From bpb at openjdk.org  Mon Oct 10 20:43:52 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Oct 2022 20:43:52 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <nMRTqoWz-lQVlQPD-io-OK_VC2f00tvZ57bZaEN6xts=.9649b36f-6020-4dfe-99cd-7d4c5811e394@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

Isn't a test needed here which fails without but passes with the proposed change?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From bpb at openjdk.org  Mon Oct 10 20:51:48 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Oct 2022 20:51:48 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos [v2]
In-Reply-To: <nqmeUBp4JBvIz_jQr493dRtvILSmKoWSS2sKojqOk38=.fd7cd183-2c67-4faa-a184-9c3f8fdce70e@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>
 <91DREBRbEGaHsnU6yXl89oMf3SRJBLnsUh30Vb-n_x4=.800d2f58-53f6-4a39-b120-3cb8e58cbb94@github.com>
 <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>
 <nqmeUBp4JBvIz_jQr493dRtvILSmKoWSS2sKojqOk38=.fd7cd183-2c67-4faa-a184-9c3f8fdce70e@github.com>
Message-ID: <gB9C6zxVfIvnL_KtPcpP2tLSFBIbKU6kSJYvkbQEtyQ=.8a1fea83-9750-474e-a3ec-a14a2ccdbf95@github.com>

On Sun, 9 Oct 2022 14:04:45 GMT, Markus KARG <duke at openjdk.org> wrote:

>>> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change _here_, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?
>> 
>> This looks to be the only that would corrupt the current position (pos). 
>> 
>> @bplb plans to look at this too, another set of eyes would be good on this point.
>
> @AlanBateman Checking `< 0` just here, as per your proposal. ? 
> 
> @bplb Kindly requesting `/sponsor`. ?

I don't see any problems here, but I question to a degree the value of the change which is not really fixing any observed broken behavior but cosmetically restricting `markpos` to the specified range `[-1, pos]` instead of `[Integer.MIN_VALUE, pos]`.

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From mullan at openjdk.org  Mon Oct 10 20:58:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Oct 2022 20:58:47 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
Message-ID: <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>

On Mon, 10 Oct 2022 19:19:44 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Agree, and alternatively, it seems cleaner to add a new SharedSecrets class for `java.security.Security` and remove the dependency on PD.
>
> modified code to have Security class hold the initial properties and provided an accessor method

What about creating a new `JavaSecurityPropertiesAccess` class and moving the accessor method there? It seems it would be cleaner to remove the dependency on PD in the long run.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From kvn at openjdk.org  Mon Oct 10 21:10:10 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 10 Oct 2022 21:10:10 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
Message-ID: <66be8SJdxPOqmqsQ1YIwS4zM4GwPerypGIf8IbfxhRs=.1d03c94a-f3e5-40ae-999e-bdd5f328170d@github.com>

On Thu, 6 Oct 2022 06:28:04 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated instruct to use kmovw

I started new testing.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From bhuang at openjdk.org  Mon Oct 10 21:53:49 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 21:53:49 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion
Message-ID: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>

This task converts 5 manual tests to automated tests.

sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
sun/security/provider/PolicyParser/ExtDirsChange.java 
sun/security/provider/PolicyParser/ExtDirs.java 
java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
javax/crypto/CryptoPermissions/InconsistentEntries.java

-------------

Commit messages:
 - Converted security manual tests to automated tests.

Changes: https://git.openjdk.org/jdk/pull/10637/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295087
  Stats: 210 lines in 13 files changed: 100 ins; 37 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Mon Oct 10 22:27:37 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 22:27:37 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
Message-ID: <oG1gymJ04OGUoOFaoTXnocMaWsQH6ZZHnpqWr8xNf90=.81642b67-c620-4c87-80d9-5c9cb121ddd5@github.com>

On Mon, 10 Oct 2022 19:45:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.
>
> test/jdk/sun/security/tools/keytool/i18n.java line 62:
> 
>> 60:  * @library /test/lib
>> 61:  * @run main/manual/othervm i18n zh CN
>> 62:  */
> 
> Do you need to triplicate these `@test` tags? Would 3-lines of `@run` suffice?
> Also setting the locale by `-Duser.language/country` and `getProperty` them in the main would be preferable to passing them as the test case arguments.

Sure, I can make a change to use the system property. 
Regarding your first question, a test with multiple 'run' fails and terminates on the first test failure. So I would prefer to have multiple tests rather than multiple 'run' in a single test that it allows jtreg to run all the tests independently.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From bhuang at openjdk.org  Mon Oct 10 22:29:56 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 22:29:56 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <UUbp93ieb0Vghr0BqO-BsbMvVHwSOuFccU439oqQ5dk=.230454ce-b153-482d-ab06-4bf3113684f6@github.com>
Message-ID: <6d1N8oLNhw4y1MVIxbJmmsKRegc5cHC0DrCrvgDiga4=.4307cd90-2a64-4aab-9ffb-f9ffd295cb71@github.com>

On Mon, 10 Oct 2022 19:47:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.
>
> test/jdk/sun/security/tools/keytool/i18n.java line 250:
> 
>> 248:     private Thread currentThread = null;
>> 249: 
>> 250:     public static class DialogBuilder {
> 
> This seems to be a boilerplate for displaying the panel. Could this be separated from the test and converted into some library?

Sure, we can move this code to the library as there is no test code in it.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From bhuang at openjdk.org  Mon Oct 10 23:23:00 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 10 Oct 2022 23:23:00 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10635/files
  - new: https://git.openjdk.org/jdk/pull/10635/files/7812f3c4..a36cd005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=00-01

  Stats: 203 lines in 2 files changed: 113 ins; 78 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From mchung at openjdk.org  Mon Oct 10 23:41:46 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 10 Oct 2022 23:41:46 GMT
Subject: RFR: 8295104: Break VarHandle tests into separate @test to reduce test
 execution time
Message-ID: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>

This separates `@run` into its own `@test` that they can be run concurrently.

-------------

Commit messages:
 - 8295104: Break VarHandle tests into separate @test to reduce test execution time

Changes: https://git.openjdk.org/jdk/pull/10641/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295104
  Stats: 176 lines in 17 files changed: 176 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10641.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10641/head:pull/10641

PR: https://git.openjdk.org/jdk/pull/10641

From stuart.marks at oracle.com  Tue Oct 11 00:54:21 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 10 Oct 2022 17:54:21 -0700
Subject: [External] : Re: Sequenced Collections
In-Reply-To: <fd778c1f-3521-7386-0800-281f002c45ed@raelity.com>
References: <f6edafc8-03f1-4f3a-1382-592688785c6e@raelity.com>
 <06ca6cc9-4d35-e327-5d03-2378302f72dd@gmail.com>
 <024fe055-c94e-94e2-cf21-bca828304929@raelity.com>
 <44ff182d-f251-e62f-9560-a7e8d325187e@oracle.com>
 <c2dbf1a8-c772-0568-f428-8b0b71557818@raelity.com>
 <d5f1c419-0eb5-6c98-2d9c-9dcc248f6db3@raelity.com>
 <62bf9d22-0ea2-10b9-fabf-78c0d68a880a@oracle.com>
 <fd778c1f-3521-7386-0800-281f002c45ed@raelity.com>
Message-ID: <2091d0d8-b4a6-a17d-bceb-5df9dd47b60f@oracle.com>

It sounds like you're after some generalized notion of "consistency", and the fact 
that offer*() return a boolean whereas add*() do not seems inconsistent. 
Unfortunately, the methods have different semantics. After add(obj), obj is *always* 
a member of the collection, whereas after offer*(obj), obj *might or might not* be a 
member of the collection. The semantics of addFirst/addLast are more closely aligned 
with those of the add*() methods on Collection, so I decided to promote 
addFirst/addLast to SequencedCollection instead of offerFirst/offerLast.

On your other point, if you want to compare elements of a SequencedCollection to 
those of another, in encounter order, you can just use regular Iterators for that. 
ListIterator isn't necessary.

s'marks

On 10/5/22 3:36 PM, Ernie Rael wrote:
> On 10/5/22 9:34 AM, Stuart Marks wrote:
>>
>>
>> On 10/4/22 9:38 PM, Ernie Rael wrote:
>>> Summary of key points (maybe the mail was TL;DR)
>>
>> OK thanks, I was still mulling over the previous email wondering which parts were 
>> significant enough to reply to.
>>
>>> ??* SequencedCollection methods addFirst,addLast are the only methods in
>>> ??? Collection hierarchy (AFAIK) that might modify the collection and do
>>> ??? not return/signal if the collection was modified. Seems like
>>> ??? offerFirst,offerLast are more consistent with Collections and still
>>> ??? avoid method proliferation.
>>
>> The problem is that the boolean return values from add() and from offerX() mean 
>> different things, and having them be adjacent on List would be confusing. (Yes, 
>> they're both present on Deque, which is one of the reasons Deque is too 
>> complicated.) And we couldn't adjust the semantics of SequencedCollection.offerX() 
>> to match add(), as that would clash with the existing semantics on Deque.
> 
> 
> It is not uncommon for a sub-interface/sub-class to clarify the precise meaning of a 
> method. If there's a general definition of SequencedCollection.offerFirst(e), then 
> the Deque definition clarifies the meaning in that context. Consider:
> 
> Collections.add(e) - Returns true if this collection changed as a result of the call
> List.add(e) - Return true
> Set.add(e) - Returns true if this set did not already contain the specified element
> 
> 
>>
>> From your other messages it seems like you want the boolean return value in order 
>> to keep track of whether the collection changed such that it affects equals() and 
>> hashCode(). 
> 
> 
> No, I was just discussing the relationship of change and equals() when working with 
> a SequencedCollection; it's more observations around using SeqCol. It's interesting 
> that an addAll() can permute the structure, and end up at the same place.
> 
> 
>> There are other methods that might modify collections where you can't tell whether 
>> they actually modified the collection; consider Collection::clear or 
>> List::replaceAll. 
> 
> 
> I'll be more precise: methods that work with a single item return/signal change; 
> most bulk operators such as removeif(), retainAll(), removeAll(), addAll() also 
> return/signal change.
> 
> My main point is that "void SequencedCollection.addFirst(e)" is inconsistent with 
> Collections' design. clear() is, well, clear(). replaceAll() seems to be an 
> exception (a lone exception?).
> 
> 
>> So I don't think the boolean return value from add/offer is really buying you all 
>> that much.
> 
> 
> When I put together a class based on a Collection, I like to follow the general 
> design pattern. Not sure if/when I may have used the "return change" when using a 
> collection. But when sub-classing a collection, since everything does it, so do I; 
> I'll return change in any additional methods I might add. Consistent, least surprise...
> 
> 
>>
>>> ??* With LinkedHashSet, seems like listIterator is missing. Rather than
>>> ??? making that part of SequencedCollection, maybe an "interface
>>> ??? ListIterable { ListIterator listIterator(int index); }". In addition
>>> ??? to modification, bi-directional might also be optional, to support
>>> ??? it's use with list equals.
>>
>> ListIterator has indexes and so it's pretty much tied to List. Maybe what you're 
>> missing from LinkedHashSet 
> 
> 
> I want to be able to do List.equals(SequencedCollection) and vice versa (in 
> particular with LinkedHashSet). In the list equals() implementations I've looked at, 
> they all use two ListIterator to do the compare; only forward iteration.? For 
> equals(), I think can wrap the SequencedCollection iterator in a forward, 
> uni-directional listIterator, a little messy, and use that for equals(); support 
> from the infrastructure would be nice. Which is where the idea of "ListIterator 
> Collections.listIterator(iterator, index)" in the other email comes from.
> 
> Some daydreaming: For equals(), indexes don't matter except for initialization. And 
> as far as "index ... tied to list", if SequencedCollection had a listIterator, I 
> think I could form sub-sequence from that, with only forward iteration. But 
> sub-SequencedCollection is a different topic. My usage requirement now is for equals().
> 
> Lists may include index, but they don't really depend on it unless they're 
> RandomAccess; consider LinkedList. I don't see how indexes have a bearing on this 
> discussion; in a listIterator the index is contained/maintained in the iterator.
> 
> 
>> is the ability to insert or reposition an element somewhere in the middle? This is 
>> certainly a valid use case, but it's quite rare, and I'm not sure I'd want to 
>> support it using an Iterator style mechanism anyway.
>>
>> Surveying the usages of ListIterator, 
> 
> 
> The implicit use by equals() is missing.
> 
> 
>> I found that it's mainly used for iteration in reverse, and secondarily for 
>> replacing all the elements of a List (somewhat supplanted by replaceAll). We did 
>> run into one case where ListIterator was used to edit items within a list but it 
>> turned out to be INCREDIBLY clumsy to use. So if we want to support that (fairly 
>> rare) use case, I wouldn't start with a ListIterator or some variant with indexes 
>> removed. I'd also want to see use cases before considering adding new mechanisms.
>>
>> s'marks
>>
> 

From dholmes at openjdk.org  Tue Oct 11 01:42:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 01:42:24 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v14]
In-Reply-To: <viMRjrZ8ZmZZ0jqFstr0CixAH4_vBELpZLPC4ocIDQ8=.3a8310cb-6028-43e6-9321-b7365695d9b9@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <mtKKcCUpQeelxOO2Xpgm4uxXIEQpbSgYrXduYcEsOdw=.91d14691-aac9-4691-baee-cfde0adaae86@github.com>
 <mumKK5K4ngw0VgVWBpxYRpAn9hgDI6QwsSfY_H5Ez4s=.43f8f8fe-57d3-4622-b8e8-1a6152eb7037@github.com>
 <viMRjrZ8ZmZZ0jqFstr0CixAH4_vBELpZLPC4ocIDQ8=.3a8310cb-6028-43e6-9321-b7365695d9b9@github.com>
Message-ID: <v3cLGh8mVuZhCoB7Kstt6Oc-edhrJO-DWiPuqIUESfE=.fa1c0925-fcca-4c81-bc42-f5f606ba62fe@github.com>

On Mon, 10 Oct 2022 11:58:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.base/windows/native/libjli/java_md.h line 48:
>> 
>>> 46:  */
>>> 47: 
>>> 48: void reportWithLastWindowsError(const char* message, ...);
>> 
>> Why does this need to be exported in the header file? Are you expecting other code to call this?
>
> I left that in there since it would possibly be a useful utility to have for other JLI code that might need to work with Windows errors in the future

In that case shouldn't the `JLI_xxx` naming scheme be retained?

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From smarks at openjdk.org  Tue Oct 11 01:52:21 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 11 Oct 2022 01:52:21 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v2]
In-Reply-To: <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
Message-ID: <wWpYAP9XlU0gg_Tle1H5wkVhFzdYJLPOJP_47B4fQS8=.6ba5dc04-d614-48b7-8e82-12136046c1d3@github.com>

On Sat, 8 Oct 2022 15:35:14 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Random -> ThreadLocalRandom change

test/jdk/java/util/Collections/Shuffle.java line 92:

> 90:             throw new RuntimeException(list.getClass() + ": " + list + " != " + copy);
> 91:         }
> 92:     }

Is there a way to factor out the `shuffle` calls and thereby collapse these two methods into one? Is it worth it? I'm thinking you could pass in a `Consumer<List<Integer>>`.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From smarks at openjdk.org  Tue Oct 11 02:00:19 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 11 Oct 2022 02:00:19 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v2]
In-Reply-To: <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
Message-ID: <vGKadVAnDHm9KuCOV8B5b2uBQCT_XXOh0TPRnkwwE6I=.46178e8b-1320-451c-9da5-a31bafdf5090@github.com>

On Sat, 8 Oct 2022 15:35:14 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Random -> ThreadLocalRandom change

test/jdk/java/util/Collections/Shuffle.java line 66:

> 64:         RandomGeneratorFactory<RandomGenerator> factory = RandomGeneratorFactory.getDefault();
> 65:         list.sort(null);
> 66:         Collections.shuffle(list, factory.create(1));

This assumes that the default factory will accept a seed value that initializes its state so that the pseudorandom sequence is repeatable. Not an unreasonable assumption, but `create(long)` essentially says that it can ignore the seed, and `getDefault` says the algorithm may change over time. On the other hand if something does change such that the pseudorandom sequence isn't repeatable, this test will most likely fail immediately. I was poking around for an explicit way to request some kind of PRNG that's guaranteed to be started in repeatable state, but I couldn't find one. Hmmm.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From dholmes at openjdk.org  Tue Oct 11 02:03:25 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 02:03:25 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v3]
In-Reply-To: <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>
Message-ID: <iFdzsokxjgv0NGYH-8o-9U8e6ItaBgoUxmii-I4ZcRE=.00b23800-fe28-485b-95bc-0a6ab3777852@github.com>

On Mon, 10 Oct 2022 11:59:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Comment documenting change isn't required
>  - Merge branch 'openjdk:master' into patch-1
>  - Comment formatting
>  - Remove Windows specific JLI_Snprintf implementation
>  - Remove Windows JLI_Snprintf definition

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10625

From smarks at openjdk.org  Tue Oct 11 02:04:22 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 11 Oct 2022 02:04:22 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v2]
In-Reply-To: <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
Message-ID: <7B07btJvICIuVCs1iuZlnlwWwwHmqeVJQPRsDlx6aC4=.fe3598fe-76b1-4178-b346-9e477ce0a38a@github.com>

On Sat, 8 Oct 2022 15:35:14 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Random -> ThreadLocalRandom change

src/java.base/share/classes/java/util/Collections.java line 485:

> 483:      *         list-iterator does not support the {@code set} operation.
> 484:      * @since 20
> 485:      */

It looks like this comment was copied from `shuffle(List, Random)` and `shuffle(List)` which is fine. But since this method is now preferred over the others, maybe we can reduce the duplication and have those other methods simply be defined in terms of this one. We'd have to come up with the right "weasel words" to describe the source of randomness used by `shuffle(List)`. In addition, if you don't want to deprecate the other methods, perhaps some wording can be found that clearly indicates this new method is now the preferred one.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From kvn at openjdk.org  Tue Oct 11 02:09:31 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 11 Oct 2022 02:09:31 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
Message-ID: <GZKrFuQcvw-3aPdQwz1HHGj3Jzljru0DhQPKElFzJGg=.a85f7b85-75b2-412a-9e63-31033226469a@github.com>

On Thu, 6 Oct 2022 06:28:04 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated instruct to use kmovw

Latest version v12 passed my tier1-4 testing. Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9781

From amitchoudhary0523 at gmail.com  Tue Oct 11 06:38:33 2022
From: amitchoudhary0523 at gmail.com (Amit)
Date: Tue, 11 Oct 2022 12:08:33 +0530
Subject: Examples Of Many Java Swing Components In One Program.
Message-ID: <CAFf+5zhufpcpjxek5o9MMw51BNhYGYmfnFy_f92dg5szX7O1mA@mail.gmail.com>

Code for many Java Swing Components In One Program in case someone needs it.

Description: The program
Examples_Of_Many_Swing_Components_In_One_Program contains examples of
many swing components - that is, how to initialize them and use them.
You can use code from this program in your code. Where applicable,
appropriate listeners are also implemented.

Components covered are: JButton, JLabel, ToolTip, JTextField,
JFormattedTextField, JCheckBox, JRadioButton, JFileChooser,
JPasswordField, Scrollable JTextArea, Scrollable JList, JComboBox,
JProgressBar, JSlider, Scrollable JTree, JSpinner, JColorChooser,
JOptionPane, JDialog, JPopupMenu, JToggleButton, JSeparator, JToolBar,
JMenuBar, JMenu, JMenuItem, JCheckBoxMenuItem, JRadioButtonMenuItem.

-------------------------------------------------------------------------------------------

import java.io.*;
import javax.swing.*;
import javax.swing.event.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;
import java.util.List;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeEvent;
import java.text.*;
import javax.swing.tree.*;
import java.time.*;
import java.time.format.*;

public class Examples_Of_Many_Swing_Components_In_One_Program extends
MouseAdapter implements ActionListener,

                        ItemListener,

                        ListSelectionListener,

                        ChangeListener,

                        PropertyChangeListener,

                        TreeSelectionListener {

    Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
    int screenWidth = screenSize.width;
    int screenHeight = screenSize.height;
    int midScreenWidth = screenWidth / 2;
    int xMargin = screenWidth/10;
    // vertical gap between components
    int vGap = 25;
    int lineLabelHeight = 10;
    int currentYPos = 0;
    int componentHeight = 25;
    int buttonWidth = 100;
    Color lightBlue = new Color(173, 216, 230);

    JFrame jf = null;
    JPanel jp = null;
    JButton jbButtonExample = null;
    JTextField jtfTextFieldExample = null;
    JButton jbTextFieldExample = null;
    JFormattedTextField jftfFormattedTextFieldExample = null;
    JButton jbFormattedTextFieldExample = null;
    JCheckBox jcb1CheckBoxExample = null;
    JCheckBox jcb2CheckBoxExample = null;
    JCheckBox jcb3CheckBoxExample = null;
    JCheckBox jcb4CheckBoxExample = null;
    JLabel jlCheckBoxExample = null;
    JRadioButton jrb1RadioButtonExample = null;
    JRadioButton jrb2RadioButtonExample = null;
    JRadioButton jrb3RadioButtonExample = null;
    JRadioButton jrb4RadioButtonExample = null;
    JLabel jlRadioButtonExample = null;
    JButton jbFileChooserExample = null;
    JTextField jtfFileChooserExample = null;
    JTextField jpfPasswordFieldExample = null;
    JButton jbPasswordFieldExample = null;
    JTextArea jtaTextAreaExample = null;
    JScrollPane jspScrollableTextAreaExample = null;
    JButton jbScrollableTextAreaExample = null;
    JList<String> jlistScrollableListExample = null;
    JScrollPane jspScrollableListExample = null;
    JLabel jlScrollableListExample = null;
    JComboBox<String> jcbComboBoxExample = null;
    JLabel jlComboBoxExample = null;
    JProgressBar jpbProgressBarExample = null;
    JButton jbProgressBarExample = null;
    JLabel jlProgressBarExample = null;
    boolean stopThreadProgressBarExample = false;
    JSlider jsSliderExample = null;
    JLabel jlSliderExample = null;
    JTree jtreeScrollableTreeExample = null;
    JScrollPane jspScrollableTreeExample = null;
    JLabel jlScrollableTreeExample = null;
    JSpinner jsSpinnerExample = null;
    JLabel jlSpinnerExample = null;
    JColorChooser jccColorChooserExample = null;
    JLabel jlColorChooserExample = null;
    JButton jbOptionPaneExamplesMessage = null;
    JButton jbOptionPaneExamplesInput = null;
    JButton jbOptionPaneExamplesConfirm = null;
    JButton jbOptionPaneExamplesOption = null;
    JDialog jdDialogExample = null;
    JComboBox jcbDialogExample = null;
    JFormattedTextField jftfDialogExample = null;
    JList jlistDialogExample = null;
    JButton jbDialogExample1 = null;
    JButton jbDialogExample2 = null;
    JDialog jdScrollableDialogExample = null;
    JPanel jpScrollableDialogPanel = null;
    JButton jbDisplayScrollableDialog = null;
    JButton jbCloseScrollableDialog = null;
    JPopupMenu jpmPopupMenuExample = null;
    JMenuItem jmiPopupMenuExample1 = null;
    JMenuItem jmiPopupMenuExample2 = null;
    JToggleButton jtbToggleButtonExample = null;
    JButton jbToolBarExample = null;
    JComboBox jcbToolBarExample = null;
    JMenuBar jmb = null;
    JMenu jm = null;
    JMenu jmSubMenu = null;
    JMenuItem jmiMenuItemExample = null;
    JCheckBoxMenuItem jcbmiCheckBoxMenuItemExample = null;
    JRadioButtonMenuItem jrbmiRadioButtonMenuItem1 = null;
    JRadioButtonMenuItem jrbmiRadioButtonMenuItem2 = null;

    @Override
    public void actionPerformed(ActionEvent ae) {
        Object source = ae.getSource();
        if (source == jbButtonExample) {
            JOptionPane.showMessageDialog(jf, "You clicked the
button!", "Info", JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jbTextFieldExample) {
            String text = "You entered: " + jtfTextFieldExample.getText();
            JOptionPane.showMessageDialog(jf, text, "Info",
JOptionPane.INFORMATION_MESSAGE);
        } else if ((source == jrb1RadioButtonExample) || (source ==
jrb2RadioButtonExample) || (source == jrb3RadioButtonExample) ||
(source == jrb4RadioButtonExample)) {
            String text = "You selected " + "\"" +
((JRadioButton)source).getText() + "\".";
            jlRadioButtonExample.setText(text);
        } else if (source == jbFileChooserExample) {
            JFileChooser jfc = new JFileChooser();
            if ((jfc.showOpenDialog(jf)) == JFileChooser.APPROVE_OPTION) {
                File selectedFile = jfc.getSelectedFile();
                jtfFileChooserExample.setText(selectedFile.getAbsolutePath());
            }
        } else if (source == jbPasswordFieldExample) {
            String text = "You entered: " + jpfPasswordFieldExample.getText();
            JOptionPane.showMessageDialog(jf, text, "Info",
JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jbScrollableTextAreaExample) {
            String text = "You wrote: " + jtaTextAreaExample.getText();
            JOptionPane.showMessageDialog(jf, text, "Info",
JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jcbComboBoxExample) {
            // source is used here to show that selected item can be
gotten from source
            // instead of using jcbComboBoxExample.
            String text = (String)(((JComboBox)source).getSelectedItem());
            if (text.isBlank() == true) {
                jlComboBoxExample.setText(text);
            } else {
                text = "You selected \"" + text + "\".";
                jlComboBoxExample.setText(text);
            }
        } else if (source == jbProgressBarExample) {
            String buttonText = jbProgressBarExample.getText();
            if ((buttonText.equals("Start Task") == true) ||
(buttonText.equals("Start Task Again") == true)) {
                // example of anonymous subclass
                Thread thread = new Thread() {
                    @Override
                    public void run() {
                        int progress = 10;
                        while (progress <= 100) {
                            if (stopThreadProgressBarExample == true) {
                                stopThreadProgressBarExample = false;
                                jpbProgressBarExample.setValue(0);
                                jbProgressBarExample.setText("Start
Task Again");
                                jlProgressBarExample.setText("Task cancelled.");
                                return;
                            } // end of if stopThreadProgressBarExample
                            jlProgressBarExample.setText("Task is running..");
                            jpbProgressBarExample.setValue(progress);
                            if (progress == 100) {
                                break;
                            }
                            try { Thread.sleep(1000); } catch (Exception e) {}
                            progress = progress + 10;
                        } // end of while
                        jbProgressBarExample.setText("Start Task Again");
                        jlProgressBarExample.setText("Task completed.");
                    }
                }; // end of new thread
                thread.start();
                jbProgressBarExample.setText("Cancel Task");
            } else if (buttonText.equals("Cancel Task") == true) {
                stopThreadProgressBarExample = true;
            } // end of if else (comparing strings)
        } else if (source == jbToolBarExample) {
            JOptionPane.showMessageDialog(jf, "You clicked Button 1.",
"Info", JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jcbToolBarExample) {
            // source is used here to show that selected item can be
gotten from source
            // instead of using jcbToolBarExample.
            String text = (String)(((JComboBox)source).getSelectedItem());
            if (text.isBlank() == false) {
                text = "You selected \"" + text + "\".";
                JOptionPane.showMessageDialog(jf, text, "Info",
JOptionPane.INFORMATION_MESSAGE);
            }
        } else if (source == jmiMenuItemExample) {
            String text = "This one program implements examples of
many swing components.";
            JOptionPane.showMessageDialog(jf, text, "Info",
JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jcbmiCheckBoxMenuItemExample) {
            if (jcbmiCheckBoxMenuItemExample.isSelected() == true) {
                JOptionPane.showMessageDialog(jf, "You have selected
check box menu item", "Info", JOptionPane.INFORMATION_MESSAGE);
            } else {
                JOptionPane.showMessageDialog(jf, "You have unselected
check box menu item", "Info", JOptionPane.INFORMATION_MESSAGE);
            }
        } else if (source == jrbmiRadioButtonMenuItem1) {
            jp.setBackground(Color.WHITE);
        } else if (source == jrbmiRadioButtonMenuItem2) {
            jp.setBackground(null);
        } else if (source == jmiPopupMenuExample1) {
            LocalTime time = LocalTime.now();
            DateTimeFormatter formatter =
DateTimeFormatter.ofPattern("hh:mm a");
            String text = time.format(formatter);
            JOptionPane.showMessageDialog(jf, text, "Current Time",
JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jmiPopupMenuExample2) {
            LocalDate date = LocalDate.now();
            DateTimeFormatter formatter =
DateTimeFormatter.ofPattern("dd-LLL-yyyy");
            String text = date.format(formatter);
            JOptionPane.showMessageDialog(jf, text, "Today's Date",
JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jbDialogExample2) {
            jcbDialogExample.setSelectedIndex(0);
            jftfDialogExample.setText("");
            jlistDialogExample.clearSelection();
            jdDialogExample.setVisible(true);
        } else if (source == jbDialogExample1) {
            String text = "";
            boolean error = false;
            String textMonth = "";
            String textYear = "";
            String textCountry = "";

            textMonth = (String)(jcbDialogExample.getSelectedItem());
            if (jftfDialogExample.getValue() != null) {
                textYear = jftfDialogExample.getText();
            }
            if (jlistDialogExample.getSelectedValue() != null) {
                textCountry = (String)(jlistDialogExample.getSelectedValue());
            }

            if (textMonth.isBlank() == true) {
                error = true;
                text = "Please select your month of birth.\n";
            }
            if (textYear.isBlank() == true) {
                error = true;
                text = text + "Please enter your year of birth.\n";
            } else if (Integer.valueOf(textYear) <= 0) {
                error = true;
                text = text + "Please enter a valid year of birth.\n";
            }
            if (textCountry.isBlank() == true) {
                error = true;
                text = text + "Please select your country of birth.\n";
            }

            if (error == true) {
                JOptionPane.showMessageDialog(jf, text, "Error",
JOptionPane.ERROR_MESSAGE);
            } else {
                text = "";
                text = "Your month of birth is: " + textMonth + "\n";
                text = text + "Your year of birth is: " + textYear + "\n";
                text = text + "Your counry of birth is: " + textCountry + "\n";
                JOptionPane.showMessageDialog(jf, text, "Your
deatils", JOptionPane.INFORMATION_MESSAGE);
            }
        } else if (source == jbDisplayScrollableDialog) {
            jdScrollableDialogExample.setVisible(true);
        } else if (source == jbCloseScrollableDialog) {
            jdScrollableDialogExample.dispose();
        } else if (source == jbOptionPaneExamplesMessage) {
            JOptionPane.showMessageDialog(jf, "This is a Message
Dialog Box.", "Message Dialog Box", JOptionPane.INFORMATION_MESSAGE);
        } else if (source == jbOptionPaneExamplesInput) {
            String text = "You entered: ";
            String input  = JOptionPane.showInputDialog(jf, "Please
input some text below:", "Input Dialog Box",
JOptionPane.PLAIN_MESSAGE);
            if (input != null) {
                text = text + input;
                JOptionPane.showMessageDialog(jf, text, "Text you
entered", JOptionPane.INFORMATION_MESSAGE);
            }
        } else if (source == jbOptionPaneExamplesConfirm) {
            JPasswordField jpf = new JPasswordField();
            int result = JOptionPane.showConfirmDialog(jf, jpf,
"Please input your password", JOptionPane.OK_CANCEL_OPTION,
JOptionPane.PLAIN_MESSAGE);
            if (result == JOptionPane.OK_OPTION) {
                String text = "Your password is: " + new
String(jpf.getPassword());
                JOptionPane.showMessageDialog(jf, text, "Your
password", JOptionPane.INFORMATION_MESSAGE);
            }
        } else if (source == jbOptionPaneExamplesOption) {
            /*
            JRadioButton jrb1 = new JRadioButton("Proceed");
            JRadioButton jrb2 = new JRadioButton("Do not proceed, stop here");
            JRadioButton jrb3 = new JRadioButton("Do not proceed, revert back");
            Object[] objs = {jrb1, jrb2, jrb3, "Submit"};
            */
            Object[] objs = new Object[4];
            objs[0] = new JRadioButton("Proceed");
            objs[1] = new JRadioButton("Do not proceed, stop here");
            objs[2] = new JRadioButton("Do not proceed, revert back");
            objs[3] = "Submit";

            ButtonGroup bg = new ButtonGroup();
            bg.add((JRadioButton)(objs[0]));
            bg.add((JRadioButton)(objs[1]));
            bg.add((JRadioButton)(objs[2]));

            int result = JOptionPane.showOptionDialog(jf, "Please
select a radio button", "Option Dialog Box",
JOptionPane.DEFAULT_OPTION, JOptionPane.PLAIN_MESSAGE, null, objs,
null);
            if (result == 3) { // 3 is the index of "Submit"
                String text = "";
                // if-else-if should be used but I am using ifs only
to see that whether
                // more than one radio button gets selected or not or
whether something
                // wrong is happening in UI.
                if ((((JRadioButton)(objs[0]))).isSelected() == true) {
                    text = text + "You selected: \"Proceed\".";
                }
                if ((((JRadioButton)(objs[1]))).isSelected() == true) {
                    text = text + "You selected: \"Do not proceed,
stop here\".";
                }
                if ((((JRadioButton)(objs[2]))).isSelected() == true) {
                    text = text + "You selected: \"Do not proceed,
revert back\".";
                }
                if (text.isBlank() == true) {
                    text = "Nothing selected.";
                }
                JOptionPane.showMessageDialog(jf, text, "Your selected
choice", JOptionPane.INFORMATION_MESSAGE);
            }
            //String text = "Result is: " + result;
            //JOptionPane.showMessageDialog(jf, text, "Info",
JOptionPane.INFORMATION_MESSAGE);
        }
    } // end of actionPerformed

    // for JCheckBox and JToggleButton
    @Override
    public void itemStateChanged(ItemEvent ie) {
        String text = "";
        Object source = ie.getItemSelectable();
        if ((source == jcb1CheckBoxExample) || (source ==
jcb2CheckBoxExample) || (source == jcb3CheckBoxExample) || (source ==
jcb4CheckBoxExample)) {
            if (ie.getStateChange() == ItemEvent.SELECTED) {
                text = "You selected ";
            } else {
                text = "You unselected ";
            }
            text = text + "\"" + ((JCheckBox)source).getText() + "\".";
            jlCheckBoxExample.setText(text);
        } else if (source == jtbToggleButtonExample) {
            if (jtbToggleButtonExample.isSelected() == true) {
                jtbToggleButtonExample.setText("ON");
                jtbToggleButtonExample.setOpaque(true);
                jtbToggleButtonExample.setBackground(Color.GREEN);
            } else {
                jtbToggleButtonExample.setText("OFF");
                jtbToggleButtonExample.setOpaque(true);
                jtbToggleButtonExample.setBackground(Color.YELLOW);
            }
        }
    } // end of itemStateChanged

    // for JList
    @Override
    public void valueChanged(ListSelectionEvent lse) {
        String text = "";
        Object source = lse.getSource();
        if (source == jlistScrollableListExample) {
            List<String> lst =
jlistScrollableListExample.getSelectedValuesList();
            if (lst.size() <= 0) {
                jlScrollableListExample.setText(text);
            } else {
                text = "Your selected items are: ";
                boolean first = true;
                for (String str : lst) {
                    if (first == false) {
                        text = text + ", ";
                    }
                    text = text + str;
                    first = false;
                } // end of for loop
                text = text + ".";
                jlScrollableListExample.setText(text);
            } // end of if else
        } // end of if source
    } // end of valueChanged

    // for JSlider, JSpinner, and JColorChooser
    @Override
    public void stateChanged(ChangeEvent ce) {
        String text = "";
        Object source = ce.getSource();
        if (source == jsSliderExample) {
            JSlider jsSource = (JSlider)source;
            if (!jsSource.getValueIsAdjusting()) {
                int value = (int)(jsSource.getValue());
                text = "The current value from slider is: " + value;
                jlSliderExample.setText(text);
            }
        } else if (source == jsSpinnerExample) {
            JSpinner jspnSource = (JSpinner)source;
            SpinnerModel sm = jspnSource.getModel();
            if (sm instanceof SpinnerNumberModel) {
                text = "The current value from spinner is: " +
((SpinnerNumberModel)(sm)).getNumber().intValue();
                jlSpinnerExample.setText(text);
            } else {
                text = "Something went wrong.";
                jlSpinnerExample.setText(text);
            }
        } else if (source == jccColorChooserExample.getSelectionModel()) {
            Color newColor = jccColorChooserExample.getColor();
            jlColorChooserExample.setBackground(newColor);
        }
    } // end of stateChanged

    // for JFormattedTextField
    @Override
    public void propertyChange(PropertyChangeEvent pce) {
        Object source = pce.getSource();
        if (source == jftfFormattedTextFieldExample) {
            double amount =
((Number)(jftfFormattedTextFieldExample.getValue())).doubleValue();
            String text = "You entered amount: " + amount;
            JOptionPane.showMessageDialog(jf, text, "Info",
JOptionPane.INFORMATION_MESSAGE);
        }
    } // end of propertyChange

    // for JTree
    @Override
    public void valueChanged(TreeSelectionEvent tse) {
        String text = "";
        Object source = tse.getSource();
        if (source == jtreeScrollableTreeExample) {
            DefaultMutableTreeNode node =
(DefaultMutableTreeNode)(((JTree)source).getLastSelectedPathComponent());
            if (node == null) {
                jlScrollableTreeExample.setText(text);
            } else {
                text = "You selected: " + node.getUserObject().toString();
                jlScrollableTreeExample.setText(text);
            }
        }
    } // end of valueChanged

    // for JPopupMenu to show up
    @Override
    public void mousePressed(MouseEvent e) {
        //JOptionPane.showMessageDialog(jf, "Mouse Pressed", "Info",
JOptionPane.INFORMATION_MESSAGE);
        if (e.isPopupTrigger()) {
            jpmPopupMenuExample.show(e.getComponent(), e.getX(), e.getY());
        }
    } // end of mousePressed

    // for JPopupMenu to show up
    @Override
    public void mouseReleased(MouseEvent e) {
        //JOptionPane.showMessageDialog(jf, "Mouse Released", "Info",
JOptionPane.INFORMATION_MESSAGE);
        if (e.isPopupTrigger()) {
            jpmPopupMenuExample.show(e.getComponent(), e.getX(), e.getY());
        }
    } // end of mouseReleased

    //void createJFrameExample() {
        //jf = SwingLibrary.setupJFrameAndGet("Learn Java Swing GUI
Programming By Examples", screenWidth, screenHeight);
        //jf = SwingLibrary.setupJFrameAndGet("Learn Java Swing GUI
Programming By Examples", 0, 0);
        //jf.setVisible(true);
    //} // end of addJFrameExample

    void createScrollableJFrameExample() {
        ArrayList<Object> a =
SwingLibrary.setupScrollableJFrameAndGetFrameAndPanel("Learn Java
Swing GUI Programming By Examples", screenWidth, screenHeight + 4500);
        jf = (JFrame)(a.get(0));
        jp = (JPanel)(a.get(1));
    } // end of addScrollableJFrameExample

    void addJButtonExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Button Example", 0, currentYPos, screenWidth,
componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        jbButtonExample = SwingLibrary.setupJButtonAndGet("Click Me!",
this, true, midScreenWidth - 50, currentYPos, buttonWidth,
componentHeight);
        jp.add(jbButtonExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJButtonExample

    void addJLabelExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Label Example", 0, currentYPos, screenWidth,
componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("This is a label!",
true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
midScreenWidth - 100, currentYPos, 200, componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJLabelExample

    void addToolTipExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Tool Tip Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Hover the mouse
over me to see the tool tip!", true, Color.GREEN,
SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
150, currentYPos, 300, componentHeight);
        jl.setToolTipText("This is a tool tip!");
        // show tool tip immediately
        ToolTipManager.sharedInstance().setInitialDelay(0);
        // keep tool tip showing
        ToolTipManager.sharedInstance().setDismissDelay(Integer.MAX_VALUE);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addToolTipExample

    void addJTextFieldExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Text Field Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Enter some text in
below field:", false, null, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight;
        jtfTextFieldExample =
SwingLibrary.setupJTextFieldAndGet(xMargin, currentYPos, screenWidth -
(xMargin*2), componentHeight);
        jp.add(jtfTextFieldExample);
        currentYPos = currentYPos + componentHeight + vGap;
        jbTextFieldExample = SwingLibrary.setupJButtonAndGet("Submit",
this, true, midScreenWidth - 50, currentYPos, buttonWidth,
componentHeight);
        jp.add(jbTextFieldExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJTextFieldExample

    void addJFormattedTextFieldExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Formatted Text Field Example", 0,
currentYPos, screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Enter some number
in below formatted field (it accepts numbers only):", false, null,
SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
200, currentYPos, 400, componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight;
        jftfFormattedTextFieldExample =
SwingLibrary.setupJFormattedTextFieldAndGet(NumberFormat.getNumberInstance(),
1000, this, "value", xMargin, currentYPos, screenWidth - (xMargin*2),
componentHeight);
        jp.add(jftfFormattedTextFieldExample);
        currentYPos = currentYPos + componentHeight + vGap;
        jbFormattedTextFieldExample =
SwingLibrary.setupJButtonAndGet("Click to shift focus away from
formatted field", this, true, midScreenWidth - 200, currentYPos, 400,
componentHeight);
        jp.add(jbFormattedTextFieldExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJFormattedTextFieldExample

    void addJCheckBoxExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Check Box Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Select/Unselect a
checkbox", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight;
        jcb1CheckBoxExample = SwingLibrary.setupJCheckBoxAndGet("One",
false, this, midScreenWidth - 100, currentYPos, 200, componentHeight);
        jp.add(jcb1CheckBoxExample);
        currentYPos = currentYPos + componentHeight;
        jcb2CheckBoxExample = SwingLibrary.setupJCheckBoxAndGet("Two",
false, this, midScreenWidth - 100, currentYPos, 200, componentHeight);
        jp.add(jcb2CheckBoxExample);
        currentYPos = currentYPos + componentHeight;
        jcb3CheckBoxExample =
SwingLibrary.setupJCheckBoxAndGet("Three", false, this, midScreenWidth
- 100, currentYPos, 200, componentHeight);
        jp.add(jcb3CheckBoxExample);
        currentYPos = currentYPos + componentHeight;
        jcb4CheckBoxExample =
SwingLibrary.setupJCheckBoxAndGet("Four", false, this, midScreenWidth
- 100, currentYPos, 200, componentHeight);
        jp.add(jcb4CheckBoxExample);
        currentYPos = currentYPos + componentHeight;
        jlCheckBoxExample = SwingLibrary.setupJLabelAndGet("", true,
Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
midScreenWidth - 100, currentYPos, 200, componentHeight);
        jp.add(jlCheckBoxExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJCheckBoxExample

    void addJRadioButtonExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Radio Button Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Select a radio
button", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight;
        jrb1RadioButtonExample =
SwingLibrary.setupJRadioButtonAndGet("A", false, this, midScreenWidth
- 100, currentYPos, 200, componentHeight);
        jp.add(jrb1RadioButtonExample);
        currentYPos = currentYPos + componentHeight;
        jrb2RadioButtonExample =
SwingLibrary.setupJRadioButtonAndGet("B", false, this, midScreenWidth
- 100, currentYPos, 200, componentHeight);
        jp.add(jrb2RadioButtonExample);
        currentYPos = currentYPos + componentHeight;
        jrb3RadioButtonExample =
SwingLibrary.setupJRadioButtonAndGet("C", false, this, midScreenWidth
- 100, currentYPos, 200, componentHeight);
        jp.add(jrb3RadioButtonExample);
        currentYPos = currentYPos + componentHeight;
        jrb4RadioButtonExample =
SwingLibrary.setupJRadioButtonAndGet("D", false, this, midScreenWidth
- 100, currentYPos, 200, componentHeight);
        jp.add(jrb4RadioButtonExample);

        // add all radio buttons to a button group so that only one radio button
        // can be selected at a time
        ButtonGroup bg = SwingLibrary.setupButtonGroupAndGet();
        bg.add(jrb1RadioButtonExample);
        bg.add(jrb2RadioButtonExample);
        bg.add(jrb3RadioButtonExample);
        bg.add(jrb4RadioButtonExample);

        currentYPos = currentYPos + componentHeight;
        jlRadioButtonExample = SwingLibrary.setupJLabelAndGet("",
true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
midScreenWidth - 100, currentYPos, 200, componentHeight);
        jp.add(jlRadioButtonExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJRadioButtonExample

    void addJFileChooserExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("File Chooser Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Select a file by
clicking Browse button below:", true, Color.GREEN,
SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
150, currentYPos, 300, componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight + 4;
        jbFileChooserExample =
SwingLibrary.setupJButtonAndGet("Browse", this, true, midScreenWidth -
50, currentYPos, buttonWidth, componentHeight);
        jp.add(jbFileChooserExample);
        currentYPos = currentYPos + componentHeight + vGap;
        jl = SwingLibrary.setupJLabelAndGet("The path to file that you
choose will appear below:", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight + 4;
        jtfFileChooserExample =
SwingLibrary.setupJTextFieldAndGet(xMargin, currentYPos, screenWidth -
(xMargin*2), componentHeight);
        jp.add(jtfFileChooserExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJFileChooserExample

    void addJPasswordFieldExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Password Field Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Enter some text
(password) in below field:", false, null, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight;
        jpfPasswordFieldExample =
SwingLibrary.setupJPasswordFieldAndGet(xMargin, currentYPos,
screenWidth - (xMargin*2), componentHeight);
        jp.add(jpfPasswordFieldExample);
        currentYPos = currentYPos + componentHeight + vGap;
        jbPasswordFieldExample =
SwingLibrary.setupJButtonAndGet("Submit", this, true, midScreenWidth -
50, currentYPos, buttonWidth, componentHeight);
        jp.add(jbPasswordFieldExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJPasswordFieldExample

    void addScrollableJTextAreaExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Scrollable Text Area Example", 0,
currentYPos, screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Write something in
Text Area below:", false, null, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight;
        jtaTextAreaExample = SwingLibrary.setupJTextAreaAndGet("", 10,
100, true, true, true, false, 0, 0, 0, 0);
        jspScrollableTextAreaExample =
SwingLibrary.setupScrollableJTextAreaAndGet(jtaTextAreaExample,
(xMargin*5)/2, currentYPos, screenWidth - (xMargin*5),
componentHeight*4);
        jp.add(jspScrollableTextAreaExample);
        currentYPos = currentYPos + componentHeight*4 + vGap;
        jbScrollableTextAreaExample =
SwingLibrary.setupJButtonAndGet("Submit", this, true, midScreenWidth -
50, currentYPos, buttonWidth, componentHeight);
        jp.add(jbScrollableTextAreaExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addScrollableJTextAreaExample

    void addScrollableJListExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Scrollable List Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Select/Unselect
item(s) from list", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight + 4;

        // add items to default list model
        DefaultListModel<String> dlm = new DefaultListModel<>();
        dlm.addElement("One");
        dlm.addElement("Two");
        dlm.addElement("Three");
        dlm.addElement("Four");
        dlm.addElement("Five");
        dlm.addElement("Six");
        dlm.addElement("Seven");
        dlm.addElement("Eight");
        dlm.addElement("Nine");
        dlm.addElement("Ten");

        jlistScrollableListExample =
SwingLibrary.setupJListAndGet(dlm,
ListSelectionModel.MULTIPLE_INTERVAL_SELECTION, 3, -1, this, false, 0,
0, 0, 0);
        jspScrollableListExample =
SwingLibrary.setupScrollableJListAndGet(jlistScrollableListExample,
xMargin*4, currentYPos, screenWidth - (xMargin*8), componentHeight*4);
        jp.add(jspScrollableListExample);
        currentYPos = currentYPos + componentHeight*4 + vGap;
        jlScrollableListExample = SwingLibrary.setupJLabelAndGet("",
true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
xMargin, currentYPos, screenWidth - (xMargin*2), componentHeight);
        jp.add(jlScrollableListExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addScrollableJListExample

    void addJComboBoxExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Combo Box Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Select an item
from combo box", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight + 4;

        // add items to default list model
        DefaultComboBoxModel<String> dcbm = new DefaultComboBoxModel<>();
        dcbm.addElement("");
        dcbm.addElement("A");
        dcbm.addElement("B");
        dcbm.addElement("C");
        dcbm.addElement("D");
        dcbm.addElement("E");
        dcbm.addElement("V");
        dcbm.addElement("W");
        dcbm.addElement("X");
        dcbm.addElement("Y");
        dcbm.addElement("Z");

        jcbComboBoxExample = SwingLibrary.setupJComboBoxAndGet(dcbm,
0, this, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jcbComboBoxExample);
        currentYPos = currentYPos + componentHeight*4 + vGap;
        jlComboBoxExample = SwingLibrary.setupJLabelAndGet("", true,
Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
midScreenWidth - 100, currentYPos, 200, componentHeight);
        jp.add(jlComboBoxExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJComboBoxExample

    void addJProgressBarExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Progress Bar Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        jlProgressBarExample = SwingLibrary.setupJLabelAndGet("Task
not started.", false, null, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jlProgressBarExample);
        currentYPos = currentYPos + componentHeight;
        jpbProgressBarExample =
SwingLibrary.setupJProgressBarAndGet(SwingConstants.HORIZONTAL, 0,
100, 0, true, true, true, xMargin, currentYPos, screenWidth -
(xMargin*2), componentHeight);
        jp.add(jpbProgressBarExample);
        currentYPos = currentYPos + componentHeight + vGap;
        jbProgressBarExample = SwingLibrary.setupJButtonAndGet("Start
Task", this, true, midScreenWidth - 100, currentYPos, 200,
componentHeight);
        jp.add(jbProgressBarExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJProgressBarExample

    void addJSliderExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Slider Example", 0, currentYPos, screenWidth,
componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        jsSliderExample =
SwingLibrary.setupJSliderAndGet(SwingConstants.HORIZONTAL, 0, 100, 20,
1, 10, true, true, this, true, xMargin, currentYPos, screenWidth -
(xMargin*2), componentHeight*2);
        jp.add(jsSliderExample);
        currentYPos = currentYPos + componentHeight*2 + vGap;
        jlSliderExample = SwingLibrary.setupJLabelAndGet("The current
value from slider is: 20", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 110, currentYPos, 220,
componentHeight);
        jp.add(jlSliderExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJSliderExample

    void addScrollableJTreeExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Scrollable Tree Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("You can select any
node in the tree.", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 110, currentYPos, 220,
componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight + 4;

        // create tree nodes
        DefaultMutableTreeNode rootNode = new DefaultMutableTreeNode("Names");

        DefaultMutableTreeNode j = new DefaultMutableTreeNode("J");
        DefaultMutableTreeNode james = new DefaultMutableTreeNode("James");
        DefaultMutableTreeNode jerrod = new DefaultMutableTreeNode("Jerrod");
        j.add(james);
        j.add(jerrod);
        rootNode.add(j);

        DefaultMutableTreeNode n = new DefaultMutableTreeNode("N");
        DefaultMutableTreeNode nathan = new DefaultMutableTreeNode("Nathan");
        DefaultMutableTreeNode nicholas = new
DefaultMutableTreeNode("Nicholas");
        n.add(nathan);
        n.add(nicholas);
        rootNode.add(n);

        DefaultMutableTreeNode v = new DefaultMutableTreeNode("V");
        DefaultMutableTreeNode vincent = new DefaultMutableTreeNode("Vincent");
        v.add(vincent);
        rootNode.add(v);

        jtreeScrollableTreeExample =
SwingLibrary.setupJTreeAndGet(rootNode,
TreeSelectionModel.SINGLE_TREE_SELECTION, this, false, 0, 0, 0, 0);
        jspScrollableTreeExample =
SwingLibrary.setupScrollableJTreeAndGet(jtreeScrollableTreeExample,
xMargin*4, currentYPos, screenWidth - (xMargin*8), componentHeight*4);
        jp.add(jspScrollableTreeExample);
        currentYPos = currentYPos + componentHeight*4 + vGap;
        jlScrollableTreeExample = SwingLibrary.setupJLabelAndGet("",
true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
midScreenWidth - 110, currentYPos, 220, componentHeight);
        jp.add(jlScrollableTreeExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addScrollableJTree example

    void addJSpinnerExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Spinner Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jl = SwingLibrary.setupJLabelAndGet("Click on up arrow
or down arrow of the spinner to set a value.", true, Color.GREEN,
SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
200, currentYPos, 400, componentHeight);
        jp.add(jl);
        currentYPos = currentYPos + componentHeight*2;
        SpinnerNumberModel snm = new SpinnerNumberModel(20, 1, null, 1);
        jsSpinnerExample = SwingLibrary.setupJSpinnerAndGet(snm,
false, this, xMargin*4, currentYPos, screenWidth - (xMargin*8),
componentHeight);
        jp.add(jsSpinnerExample);
        currentYPos = currentYPos + componentHeight + vGap;
        jlSpinnerExample = SwingLibrary.setupJLabelAndGet("The current
value from spinner is: 20", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
componentHeight);
        jp.add(jlSpinnerExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJSpinnerExample

    void addJColorChooserExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Color Chooser Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        jlColorChooserExample = SwingLibrary.setupJLabelAndGet("Select
a color and the background of this label will change to that color.",
true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
midScreenWidth - 250, currentYPos, 500, componentHeight);
        jp.add(jlColorChooserExample);
        currentYPos = currentYPos + componentHeight*2;
        jccColorChooserExample =
SwingLibrary.setupJColorChooserAndGet(Color.GREEN, true, "Choose a
color", this, xMargin*2, currentYPos, screenWidth - (xMargin*4),
componentHeight*12);
        jp.add(jccColorChooserExample);
        currentYPos = currentYPos + componentHeight*12 + vGap;
        addLineLabel(currentYPos);
    } // end of addJColorChooserExample

    void addJOptionPaneExamples() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Option Pane Examples", 0, currentYPos,
screenWidth, componentHeight);

        currentYPos = currentYPos + componentHeight + vGap;
        jbOptionPaneExamplesMessage =
SwingLibrary.setupJButtonAndGet("Click to see the Message Dialog Box",
this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
        jp.add(jbOptionPaneExamplesMessage);

        currentYPos = currentYPos + componentHeight + vGap;
        jbOptionPaneExamplesInput =
SwingLibrary.setupJButtonAndGet("Click to see the Input Dialog Box",
this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
        jp.add(jbOptionPaneExamplesInput);

        currentYPos = currentYPos + componentHeight + vGap;
        jbOptionPaneExamplesConfirm =
SwingLibrary.setupJButtonAndGet("Click to see the Confirm Dialog Box",
this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
        jp.add(jbOptionPaneExamplesConfirm);

        currentYPos = currentYPos + componentHeight + vGap;
        jbOptionPaneExamplesOption =
SwingLibrary.setupJButtonAndGet("Click to see the Option Dialog Box",
this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
        jp.add(jbOptionPaneExamplesOption);

        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJOptionPaneExample

    void addJDialogExample() {
        int dialogWidth = 336;
        int dialogHeight = 350;
        int midDialogWidth = dialogWidth/2;
        int jdXPos = 10;
        int jdYPos = 10;
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Dialog Example", 0, currentYPos, screenWidth,
componentHeight);
        currentYPos = currentYPos + vGap;

        jdDialogExample = SwingLibrary.setupJDialogAndGet(jf,
"Details", true, dialogWidth, dialogHeight);

        JLabel jl = SwingLibrary.setupJLabelAndGet("Select your month
of birth from combo box:", false, null, SwingConstants.LEFT,
SwingConstants.CENTER, true, jdXPos, jdYPos, 300, componentHeight);
        jdDialogExample.add(jl);
        DefaultComboBoxModel<String> dcbm = new DefaultComboBoxModel<>();
        dcbm.addElement("");
        dcbm.addElement("Jan");
        dcbm.addElement("Feb");
        dcbm.addElement("Mar");
        dcbm.addElement("Apr");
        dcbm.addElement("May");
        dcbm.addElement("Jun");
        dcbm.addElement("Jul");
        dcbm.addElement("Aug");
        dcbm.addElement("Sep");
        dcbm.addElement("Oct");
        dcbm.addElement("Nov");
        dcbm.addElement("Dec");
        jdYPos = jdYPos + componentHeight;
        jcbDialogExample = SwingLibrary.setupJComboBoxAndGet(dcbm, 0,
null, true, jdXPos, jdYPos, 300, componentHeight);
        jdDialogExample.add(jcbDialogExample);

        jdYPos = jdYPos + componentHeight*2;
        jl = SwingLibrary.setupJLabelAndGet("Enter your year of birth
in text field (4 digits):", false, null, SwingConstants.LEFT,
SwingConstants.CENTER, true, jdXPos, jdYPos, 300, componentHeight);
        jdDialogExample.add(jl);
        jdYPos = jdYPos + componentHeight;
        NumberFormat format = NumberFormat.getIntegerInstance();
        format.setGroupingUsed(false);
        format.setMinimumIntegerDigits(0);
        format.setMaximumIntegerDigits(4);
        jftfDialogExample =
SwingLibrary.setupJFormattedTextFieldAndGet(format, null, null, null,
jdXPos, jdYPos, 300, componentHeight);
        jdDialogExample.add(jftfDialogExample);

        jdYPos = jdYPos + componentHeight*2;
        jl = SwingLibrary.setupJLabelAndGet("Select your country of
birth from list:", false, null, SwingConstants.LEFT,
SwingConstants.CENTER, true, jdXPos, jdYPos, 300, componentHeight);
        jdDialogExample.add(jl);
        DefaultListModel<String> dlm = new DefaultListModel<>();
        dlm.addElement("USA");
        dlm.addElement("Outside USA");
        jdYPos = jdYPos + componentHeight;
        jlistDialogExample = SwingLibrary.setupJListAndGet(dlm,
ListSelectionModel.SINGLE_SELECTION, 2, -1, null, true, jdXPos,
jdYPos, 300, componentHeight*2 - 14);
        jdDialogExample.add(jlistDialogExample);

        jdYPos = jdYPos + componentHeight*3;
        jbDialogExample1 = SwingLibrary.setupJButtonAndGet("Submit",
this, true, midDialogWidth - 50, jdYPos, 100, componentHeight);
        jdDialogExample.add(jbDialogExample1);

        currentYPos = currentYPos + componentHeight;
        jbDialogExample2 = SwingLibrary.setupJButtonAndGet("Click to
see the dialog box", this, true, midScreenWidth - 150, currentYPos,
buttonWidth*3, componentHeight);
        jp.add(jbDialogExample2);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJDialogExample

    void addScrollableJDialogExample() {
        int dialogWidth = 400;
        int dialogHeight = 400;
        int midDialogWidth = dialogWidth/2;
        int panelWidth = 420;
        int panelHeight = 570;
        int jdYPos = 10;
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Scrollable Dialog Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + vGap;

        ArrayList<Object> a =
SwingLibrary.setupScrollableJDialogAndGetDialogAndPanel(jf, "List of
Labels", true, dialogWidth, dialogHeight, panelWidth, panelHeight);
        jdScrollableDialogExample = (JDialog)(a.get(0));
        jpScrollableDialogPanel = (JPanel)(a.get(1));

        JLabel jl = null;
        String text = null;
        for (int i = 0; i < 15; i++) {
            text = "This is label " + (i + 1);
            jl = SwingLibrary.setupJLabelAndGet(text, true,
Color.BLACK, SwingConstants.LEFT, SwingConstants.CENTER, true, 10,
jdYPos, 400, componentHeight);
            jl.setForeground(Color.WHITE);
            jdYPos = jdYPos + 35;
            jpScrollableDialogPanel.add(jl);
        }

        jbCloseScrollableDialog =
SwingLibrary.setupJButtonAndGet("Close", this, true, midDialogWidth -
50, jdYPos, 100, componentHeight);
        jpScrollableDialogPanel.add(jbCloseScrollableDialog);

        currentYPos = currentYPos + componentHeight;
        jbDisplayScrollableDialog =
SwingLibrary.setupJButtonAndGet("Click to see the scrollable dialog
box", this, true, midScreenWidth - 150, currentYPos, buttonWidth*3,
componentHeight);
        jp.add(jbDisplayScrollableDialog);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addScrollableJDialogExample

    void addJPopupMenuExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Popup Menu Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jlPopupMenuExample =
SwingLibrary.setupJLabelAndGet("Right click anywhere in the frame to
the see the popup menu.", true, Color.GREEN, SwingConstants.CENTER,
SwingConstants.CENTER, true, midScreenWidth - 250, currentYPos, 500,
componentHeight);
        jp.add(jlPopupMenuExample);
        jpmPopupMenuExample = new JPopupMenu("Popup Menu");
        jmiPopupMenuExample1 = SwingLibrary.setupJMenuItemAndGet("Show
current time", this, null, null, null);
        jpmPopupMenuExample.add(jmiPopupMenuExample1);
        jpmPopupMenuExample.addSeparator();
        jmiPopupMenuExample2 = SwingLibrary.setupJMenuItemAndGet("Show
today's date", this, null, null, null);
        jpmPopupMenuExample.add(jmiPopupMenuExample2);

        // Add mouse listener on JPanel so that clicking anywhere on
JPanel will bring up the popup menu.
        jp.addMouseListener(this);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJPopupMenuExample

    void addJToggleButtonExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Toggle Button Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        jtbToggleButtonExample =
SwingLibrary.setupJToggleButtonAndGet("OFF", this, true, Color.YELLOW,
true, midScreenWidth - 50, currentYPos, buttonWidth, componentHeight);
        jp.add(jtbToggleButtonExample);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJToggleButtonExample

    void addJSeparatorExample() {
        currentYPos = currentYPos + vGap;
        addHeadingLabel("Separator Example", 0, currentYPos,
screenWidth, componentHeight);
        currentYPos = currentYPos + componentHeight + vGap;
        JLabel jlSeparatorExample =
SwingLibrary.setupJLabelAndGet("Below are the separators.", true,
Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
midScreenWidth - 100, currentYPos, 200, componentHeight);
        jp.add(jlSeparatorExample);
        currentYPos = currentYPos + componentHeight + vGap;
        JSeparator sep1 =
SwingLibrary.setupJSeparatorAndGet(SwingConstants.HORIZONTAL,
Color.YELLOW, true, xMargin*2, currentYPos, screenWidth - (xMargin*4),
componentHeight);
        jp.add(sep1);
        currentYPos = currentYPos + componentHeight + vGap;
        JSeparator sep2 =
SwingLibrary.setupJSeparatorAndGet(SwingConstants.HORIZONTAL,
Color.GREEN, true, xMargin*2, currentYPos, screenWidth - (xMargin*4),
componentHeight);
        jp.add(sep2);
        currentYPos = currentYPos + componentHeight + vGap;
        addLineLabel(currentYPos);
    } // end of addJSeparatorExample

    void addJToolBarExample() {
        JToolBar jtbToolBarExample = new JToolBar("Tool Bar",
SwingConstants.HORIZONTAL);
        jbToolBarExample = SwingLibrary.setupJButtonAndGet("Button 1",
this, false, 0, 0, 0, 0);
        jtbToolBarExample.add(jbToolBarExample);
        jtbToolBarExample.addSeparator();
        // Now, add a combo box to tool bar
        DefaultComboBoxModel<String> dcbm = new DefaultComboBoxModel<>();
        dcbm.addElement("");
        dcbm.addElement("Item 1");
        dcbm.addElement("Item 2");
        dcbm.addElement("Item 3");
        dcbm.addElement("Item 4");
        jcbToolBarExample = SwingLibrary.setupJComboBoxAndGet(dcbm, 0,
this, false, 0, 0, 0, 0);
        jtbToolBarExample.add(jcbToolBarExample);
        //jtbToolBarExample.setBorderPainted(true);
        jf.add(jtbToolBarExample, BorderLayout.NORTH);
    } // end of addJToolBarExample

    void addJMenuItemsExample() {
        KeyStroke k = KeyStroke.getKeyStroke(KeyEvent.VK_I,
InputEvent.CTRL_DOWN_MASK);
        jmb = SwingLibrary.setupJMenuBarAndGet(null, Color.GREEN);
        jm = SwingLibrary.setupJMenuAndGet("Help", Color.BLACK, Color.YELLOW);
        jmSubMenu = SwingLibrary.setupJMenuAndGet("More Help",
Color.BLUE, Color.YELLOW);
        jmiMenuItemExample =
SwingLibrary.setupJMenuItemAndGet("About", this, k, null,
Color.WHITE);
        jcbmiCheckBoxMenuItemExample = new JCheckBoxMenuItem("Show a
message dialog box");
        jcbmiCheckBoxMenuItemExample.addActionListener(this);
        jrbmiRadioButtonMenuItem1 = new JRadioButtonMenuItem("Change
background color to white");
        jrbmiRadioButtonMenuItem1.addActionListener(this);
        jrbmiRadioButtonMenuItem2 = new JRadioButtonMenuItem("Change
background color to default");
        jrbmiRadioButtonMenuItem2.addActionListener(this);
        ButtonGroup bg = SwingLibrary.setupButtonGroupAndGet();
        bg.add(jrbmiRadioButtonMenuItem1);
        bg.add(jrbmiRadioButtonMenuItem2);
        jmSubMenu.add(jmiMenuItemExample);
        jmSubMenu.addSeparator();
        jmSubMenu.add(jcbmiCheckBoxMenuItemExample);
        jmSubMenu.addSeparator();
        jmSubMenu.add(jrbmiRadioButtonMenuItem1);
        jmSubMenu.add(jrbmiRadioButtonMenuItem2);
        jm.add(jmSubMenu);
        jmb.add(jm);
        jf.setJMenuBar(jmb);
    } // end of addJMenuItemsExample

    void createAndShowSwingGUIExamples() {
        //createJFrameExample();
        createScrollableJFrameExample();
        addJButtonExample();
        addJLabelExample();
        addToolTipExample();
        addJTextFieldExample();
        addJFormattedTextFieldExample();
        addJCheckBoxExample();
        addJRadioButtonExample();
        addJFileChooserExample();
        addJPasswordFieldExample();
        addScrollableJTextAreaExample();
        addScrollableJListExample();
        addJComboBoxExample();
        addJProgressBarExample();
        addJSliderExample();
        addScrollableJTreeExample();
        addJSpinnerExample();
        addJColorChooserExample();
        addJOptionPaneExamples();
        addJDialogExample();
        addScrollableJDialogExample();
        addJPopupMenuExample();
        addJToggleButtonExample();
        addJSeparatorExample();
        addJToolBarExample();
        addJMenuItemsExample();

        // Frame has been created, all examples have been added, now
show the frame
        jf.setVisible(true);
    } // end of createAndShowSwingExamples

    void addHeadingLabel(String text, int xpos, int ypos, int width,
int height) {
        //JLabel jl = SwingLibrary.setupJLabelAndGet(text, true,
Color.YELLOW, SwingConstants.CENTER, SwingConstants.CENTER, true,
xpos, ypos, width, height);
        JLabel jl = SwingLibrary.setupJLabelAndGet(text, true,
lightBlue, SwingConstants.CENTER, SwingConstants.CENTER, true, xpos,
ypos, width, height);
        jp.add(jl);
    } // end of addHeadingLabel

    void addLineLabel(int ypos) {
        JLabel jl = SwingLibrary.setupJLabelAndGet("", true,
Color.BLACK, SwingConstants.CENTER, SwingConstants.CENTER, true, 0,
ypos, screenWidth, lineLabelHeight);
        jp.add(jl);
        currentYPos = currentYPos + lineLabelHeight;
    } // end of addLineLabel

    public static void main(String[] args) {
        Examples_Of_Many_Swing_Components_In_One_Program eomsciop =
new Examples_Of_Many_Swing_Components_In_One_Program();
        eomsciop.createAndShowSwingGUIExamples();
    } // end of main

} // end of Examples_Of_Many_Swing_Components_In_One_Program

class SwingLibrary {

    // if width is 0 then the frame is maximized horizontally
    // if height is 0 then the frame is maximized vertically
    public static JFrame setupJFrameAndGet(String title, int width,
int height) {
        int state = 0;
        JFrame tmpJF = new JFrame(title);
        if (width == 0) {
            state = state | JFrame.MAXIMIZED_HORIZ;
        }
        if (height == 0) {
            state = state | JFrame.MAXIMIZED_VERT;
        }
        if ((width != 0) || (height != 0)) {
            tmpJF.setSize(width, height);
        }
        tmpJF.setExtendedState(tmpJF.getExtendedState() | state);
        tmpJF.setLocationRelativeTo(null);
        tmpJF.setLayout(null);
        tmpJF.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        return tmpJF;
    } // end of setupJFrameAndGet

    // width and height are the preferred width and height of JPanel
    public static ArrayList<Object>
setupScrollableJFrameAndGetFrameAndPanel(String title, int width, int
height) {
        JFrame tmpJF = new JFrame(title);
        tmpJF.setExtendedState(tmpJF.getExtendedState() |
JFrame.MAXIMIZED_BOTH);
        tmpJF.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        //tmpJF.setLayout(null);

        JPanel tmpJP = new JPanel();
        //tmpJP.setBounds(xpos, ypos, width + 1000, height + 1000);
        tmpJP.setPreferredSize(new Dimension(width, height));
        tmpJP.setLayout(null);

        JScrollPane tmpJSPFrame = new JScrollPane(tmpJP,
JScrollPane.VERTICAL_SCROLLBAR_ALWAYS,
JScrollPane.HORIZONTAL_SCROLLBAR_ALWAYS);
        tmpJSPFrame.getHorizontalScrollBar().setUnitIncrement(10);
        tmpJSPFrame.getVerticalScrollBar().setUnitIncrement(10);
        tmpJF.add(tmpJSPFrame);

        ArrayList<Object> tmpA = new ArrayList<>();
        tmpA.add((Object) (tmpJF));
        tmpA.add((Object) (tmpJP));

        return tmpA;
    } // end of setupScrollableJFrameAndGetFrameAndPanel

    // actLisObj: object which implements action listener
    public static JButton setupJButtonAndGet(String text, Object
actLisObj, boolean setBoundsFlag, int xpos, int ypos, int width, int
height) {
        JButton tmpJB = new JButton(text);
        if (setBoundsFlag == true) {
            tmpJB.setBounds(xpos, ypos, width, height);
        }
        tmpJB.addActionListener((ActionListener) actLisObj);
        return tmpJB;
    } // end of setupJButtonAndGet

    // halign: horizontal alignment of text, valign: vertical alignment of text
    public static JLabel setupJLabelAndGet(String text, boolean
opaque, Color bg, int halign, int valign, boolean setBoundsFlag, int
xpos, int ypos, int width, int height) {
        JLabel tmpJL = new JLabel(text);
        if (setBoundsFlag == true) {
            tmpJL.setBounds(xpos, ypos, width, height);
        }
        tmpJL.setOpaque(opaque);
        if (bg != null) {
            tmpJL.setBackground(bg);
        }
        tmpJL.setHorizontalAlignment(halign);
        tmpJL.setVerticalAlignment(valign);
        return tmpJL;
    } // end of setupJlabelAndGet

    public static JTextField setupJTextFieldAndGet(int xpos, int ypos,
int width, int height) {
        JTextField tmpJTF = new JTextField();
        tmpJTF.setBounds(xpos, ypos, width, height);
        return tmpJTF;
    } // end of setupJTextFieldAndGet

    public static JFormattedTextField
setupJFormattedTextFieldAndGet(Format fmt, Object initialVal, Object
propertyChangeLis, String propertyToListenFor, int xpos, int ypos, int
width, int height) {
        JFormattedTextField tmpJFTF = new JFormattedTextField(fmt);
        tmpJFTF.setValue(initialVal);
        tmpJFTF.addPropertyChangeListener(propertyToListenFor,
(PropertyChangeListener) propertyChangeLis);
        tmpJFTF.setBounds(xpos, ypos, width, height);
        return tmpJFTF;
    } // end of setupJFormattedTextFieldAndGet

    // itemLisObj: object which implements item listener
    public static JCheckBox setupJCheckBoxAndGet(String text, boolean
state, Object itemLisObj, int xpos, int ypos, int width, int height) {
        JCheckBox tmpJCB = new JCheckBox(text, state);
        tmpJCB.setBounds(xpos, ypos, width, height);
        tmpJCB.addItemListener((ItemListener) itemLisObj);
        return tmpJCB;
    } // end of setupJCheckBoxAndGet

    // actLisObj: object which implements action listener
    public static JRadioButton setupJRadioButtonAndGet(String text,
boolean state, Object actLisObj, int xpos, int ypos, int width, int
height) {
        JRadioButton tmpJRB = new JRadioButton(text, state);
        tmpJRB.setBounds(xpos, ypos, width, height);
        tmpJRB.addActionListener((ActionListener) actLisObj);
        return tmpJRB;
    } // end of setupJRadioButtonAndGet

    public static ButtonGroup setupButtonGroupAndGet() {
        return new ButtonGroup();
    } // end of setupButtonGroupAndGet

    public static JPasswordField setupJPasswordFieldAndGet(int xpos,
int ypos, int width, int height) {
        JPasswordField tmpJPF = new JPasswordField();
        tmpJPF.setBounds(xpos, ypos, width, height);
        return tmpJPF;
    } // end of setupJPasswordFieldAndGet

    public static JTextArea setupJTextAreaAndGet(String text, int
rows, int columns, boolean setEditableFlag, boolean setLineWrapFlag,
boolean setWrapStyleWordFlag, boolean setBoundsFlag, int xpos, int
ypos, int width, int height) {
        JTextArea tmpJTA = new JTextArea(text, rows, columns);
        tmpJTA.setEditable(setEditableFlag);
        tmpJTA.setLineWrap(setLineWrapFlag);
        tmpJTA.setWrapStyleWord(setWrapStyleWordFlag);
        if (setBoundsFlag == true) {
            tmpJTA.setBounds(xpos, ypos, width, height);
        }
        return tmpJTA;
    } // end of setupJTextAreaAndGet

    public static JScrollPane setupScrollableJTextAreaAndGet(JTextArea
jta, int xpos, int ypos, int width, int height) {
        JScrollPane tmpJSP = new JScrollPane(jta);
        tmpJSP.setBounds(xpos, ypos, width, height);
        return tmpJSP;
    } // end of setupScrollableJTextAreaAndGet

    public static JList<String> setupJListAndGet(ListModel<String> lm,
int selectionMode, int visibleRowCount, int initialSelectedIndex,
Object listSelLisObj, boolean setBoundsFlag, int xpos, int ypos, int
width, int height) {
        JList<String> tmpJList = new JList<>(lm);
        tmpJList.setSelectionMode(selectionMode);
        tmpJList.setVisibleRowCount(visibleRowCount);
        if (initialSelectedIndex >= 0) {
            tmpJList.setSelectedIndex(initialSelectedIndex);
        }
        tmpJList.addListSelectionListener((ListSelectionListener)
listSelLisObj);
        if (setBoundsFlag == true) {
            tmpJList.setBounds(xpos, ypos, width, height);
        }
        return tmpJList;
    } // end of setupJListAndGet

    public static JScrollPane setupScrollableJListAndGet(JList jlist,
int xpos, int ypos, int width, int height) {
        JScrollPane tmpJSP = new JScrollPane(jlist);
        tmpJSP.setBounds(xpos, ypos, width, height);
        return tmpJSP;
    } // end of setupScrollableJListAndGet

    public static JComboBox<String>
setupJComboBoxAndGet(ComboBoxModel<String> cbm, int
initialSelectedIndex, Object actLisObj, boolean setBoundsFlag, int
xpos, int ypos, int width, int height) {
        JComboBox<String> tmpJComboBox = new JComboBox<>(cbm);
        if (initialSelectedIndex >= 0) {
            tmpJComboBox.setSelectedIndex(initialSelectedIndex);
        }
        tmpJComboBox.addActionListener((ActionListener) actLisObj);
        if (setBoundsFlag == true) {
            tmpJComboBox.setBounds(xpos, ypos, width, height);
        }
        return tmpJComboBox;
    } // end of setupJComboBoxAndGet

    public static JProgressBar setupJProgressBarAndGet(int
orientation, int min, int max, int initialVal, boolean
borderPaintedFlag, boolean stringPaintedFlag, boolean setBoundsFlag,
int xpos, int ypos, int width, int height) {
        JProgressBar tmpJPB = new JProgressBar(orientation, min, max);
        tmpJPB.setValue(initialVal);
        tmpJPB.setBorderPainted(borderPaintedFlag);
        tmpJPB.setStringPainted(stringPaintedFlag);
        if (setBoundsFlag == true) {
            tmpJPB.setBounds(xpos, ypos, width, height);
        }
        return tmpJPB;
    } // end of setupJProgressBarAndGet

    public static JSlider setupJSliderAndGet(int orientation, int min,
int max, int initialVal, int minorTickSpacing, int majorTickSpacing,
boolean paintTicksFlag, boolean paintLabelsFlag, Object changeLisObj,
boolean setBoundsFlag, int xpos, int ypos, int width, int height) {
        JSlider tmpJS = new JSlider(orientation, min, max, initialVal);
        tmpJS.setMinorTickSpacing(minorTickSpacing);
        tmpJS.setMajorTickSpacing(majorTickSpacing);
        tmpJS.setPaintTicks(paintTicksFlag);
        tmpJS.setPaintLabels(paintLabelsFlag);
        tmpJS.addChangeListener((ChangeListener) changeLisObj);
        if (setBoundsFlag == true) {
            tmpJS.setBounds(xpos, ypos, width, height);
        }
        return tmpJS;
    } // end of setupJSliderAndGet

    public static JTree setupJTreeAndGet(DefaultMutableTreeNode
rootNode, int selectionMode, Object treeSelLisObj, boolean
setBoundsFlag, int xpos, int ypos, int width, int height) {
        JTree tmpJTree = new JTree(rootNode);
        tmpJTree.getSelectionModel().setSelectionMode(selectionMode);
        tmpJTree.addTreeSelectionListener((TreeSelectionListener)
treeSelLisObj);
        if (setBoundsFlag == true) {
            tmpJTree.setBounds(xpos, ypos, width, height);
        }
        return tmpJTree;
    } // end of setupJTreeAndGet

    public static JScrollPane setupScrollableJTreeAndGet(JTree jtree,
int xpos, int ypos, int width, int height) {
        JScrollPane tmpJSP = new JScrollPane(jtree);
        tmpJSP.setBounds(xpos, ypos, width, height);
        return tmpJSP;
    } // end of setupScrollableJTreeAndGet

    public static JSpinner setupJSpinnerAndGet(SpinnerModel sm,
boolean editableFlag, Object spinnerChangeLisObj, int xpos, int ypos,
int width, int height) {
        JSpinner tmpJSPN = new JSpinner(sm);
        tmpJSPN.addChangeListener((ChangeListener) spinnerChangeLisObj);
        if (editableFlag == false) {
            JComponent editor = tmpJSPN.getEditor();
            if (editor instanceof JSpinner.DefaultEditor) {
                ((JSpinner.DefaultEditor)
editor).getTextField().setEditable(editableFlag);
            } else {
                System.out.println("Error: Could not set editableFlag
for JSpinner.");
            }
        }
        tmpJSPN.setBounds(xpos, ypos, width, height);
        return tmpJSPN;
    } // end of setupJSpinnerAndGet

    public static JColorChooser setupJColorChooserAndGet(Color
initialColor, boolean borderTitleFlag, String borderTitle, Object
colorChooserChangeLisObj, int xpos, int ypos, int width, int height) {
        JColorChooser tmpJCC = new JColorChooser(initialColor);
        tmpJCC.getSelectionModel().addChangeListener((ChangeListener)
colorChooserChangeLisObj);
        if (borderTitleFlag == true) {
            tmpJCC.setBorder(BorderFactory.createTitledBorder(borderTitle));
        }
        tmpJCC.setBounds(xpos, ypos, width, height);
        return tmpJCC;
    } // end of setupJColorChooserAndGet

    public static JDialog setupJDialogAndGet(Frame owner, String
title, boolean modal, int width, int height) {
        JDialog tmpJD = new JDialog(owner, title, modal);
        tmpJD.setSize(width, height);
        tmpJD.setLocationRelativeTo(null);
        tmpJD.setLayout(null);
        tmpJD.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);
        return tmpJD;
    } // end of setupJDialogAndGet

    public static ArrayList<Object>
setupScrollableJDialogAndGetDialogAndPanel(Frame owner, String title,
boolean modal, int dialogWidth, int dialogHeight, int panelWidth, int
panelHeight) {
        JDialog tmpJD = new JDialog(owner, title, modal);
        tmpJD.setSize(dialogWidth, dialogHeight);
        tmpJD.setLocationRelativeTo(null);
        tmpJD.setLayout(null);
        tmpJD.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);

        JPanel tmpJP = new JPanel();
        tmpJP.setPreferredSize(new Dimension(panelWidth, panelHeight));
        tmpJP.setLayout(null);

        ScrollPane sp = new ScrollPane(ScrollPane.SCROLLBARS_ALWAYS);
        sp.getHAdjustable().setUnitIncrement(10);
        sp.getVAdjustable().setUnitIncrement(10);
        sp.add(tmpJP);
        tmpJD.getRootPane().setContentPane(sp);

        ArrayList<Object> tmpA = new ArrayList<>();
        tmpA.add((Object) (tmpJD));
        tmpA.add((Object) (tmpJP));

        return tmpA;
    } // end of setupScrollableJDialogAndGetDialogAndPanel

    public static JToggleButton setupJToggleButtonAndGet(String text,
Object itemLisObj, boolean opaque, Color bgcolor, boolean
setBoundsFlag, int xpos, int ypos, int width, int height) {
        JToggleButton tmpJTB = new JToggleButton(text);
        if (setBoundsFlag == true) {
            tmpJTB.setBounds(xpos, ypos, width, height);
        }
        tmpJTB.addItemListener((ItemListener) itemLisObj);
        tmpJTB.setOpaque(opaque);
        tmpJTB.setBackground(bgcolor);
        return tmpJTB;
    } // end of setupJToggleButtonAndGet

    public static JSeparator setupJSeparatorAndGet(int orientation,
Color bgcolor, boolean setBoundsFlag, int xpos, int ypos, int width,
int height) {
        JSeparator tmpJS = new JSeparator(orientation);
        tmpJS.setBackground(bgcolor);
        if (setBoundsFlag == true) {
            tmpJS.setBounds(xpos, ypos, width, height);
        }
        return tmpJS;
    } // end of setupJSeparatorAndGet

    public static JMenuBar setupJMenuBarAndGet(Color fgcolor, Color bgcolor) {
        JMenuBar tmpJMB = new JMenuBar();
        tmpJMB.setOpaque(true);
        tmpJMB.setForeground(fgcolor);
        tmpJMB.setBackground(bgcolor);
        return tmpJMB;
    } // end of setupJMenuBarAndGet

    public static JMenu setupJMenuAndGet(String text, Color fgcolor,
Color bgcolor) {
        JMenu tmpJM = new JMenu(text);
        tmpJM.setOpaque(true);
        tmpJM.setForeground(fgcolor);
        tmpJM.setBackground(bgcolor);
        return tmpJM;
    } // end of setupJMenuAndGet

    public static JMenuItem setupJMenuItemAndGet(String text, Object
actLisObj, KeyStroke k, Color fgcolor, Color bgcolor) {
        JMenuItem tmpJMI = new JMenuItem(text);
        tmpJMI.setOpaque(true);
        tmpJMI.setForeground(fgcolor);
        tmpJMI.setBackground(bgcolor);
        tmpJMI.setAccelerator(k);
        if (actLisObj != null) {
            tmpJMI.addActionListener((ActionListener) actLisObj);
        }
        return tmpJMI;
    } // end of setupJMenuItemAndGet

} // end of SwingLibrary

-------------------------------------------------------------------------------------------

From aturbanov at openjdk.org  Tue Oct 11 07:54:28 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 11 Oct 2022 07:54:28 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling [v2]
In-Reply-To: <ajidYv5T5AisWrnkMWub0Hlj0gbGnlwpL7cDMDa8A5A=.dde4a608-d4c3-4b4c-b059-21ce67202e05@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
 <ajidYv5T5AisWrnkMWub0Hlj0gbGnlwpL7cDMDa8A5A=.dde4a608-d4c3-4b4c-b059-21ce67202e05@github.com>
Message-ID: <YDQsTSaENnJG6VIewn1fpRSJjr9RfGLrUb3LSDuzpUg=.2032dbe9-204f-4a95-9691-418b4d7164a7@github.com>

On Fri, 7 Oct 2022 15:36:16 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added test cases for xpath Axis:
>> 1. descendant
>> 2. descendant-or-self
>> 3. following
>> 4. following-sibling
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFollowingTest.java line 44:

> 42:  * @summary Tests for XPath following/following-sibling axis specifier.
> 43:  */
> 44: public class XPathExpFollowingTest extends  XPathTestBase {

Suggestion:

public class XPathExpFollowingTest extends XPathTestBase {

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From aturbanov at openjdk.org  Tue Oct 11 08:02:24 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 11 Oct 2022 08:02:24 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v4]
In-Reply-To: <y4e8nEYTOQ4XjLUzOwtzKTQKImMO4yvitpmb5xpQRKk=.a16d72af-bf4c-4792-9a62-ac1437cd705f@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <y4e8nEYTOQ4XjLUzOwtzKTQKImMO4yvitpmb5xpQRKk=.a16d72af-bf4c-4792-9a62-ac1437cd705f@github.com>
Message-ID: <eKCWbI-k7k5lP7nvJT-uuObDQI1mn3yGDsnpwx4Iumk=.509eb66a-2949-4a06-bc23-9623c6fb1a0c@github.com>

On Mon, 10 Oct 2022 19:23:51 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Oct 10 review comments

test/lib/jdk/test/lib/jfr/EventNames.java line 195:

> 193:     public final static String X509Certificate = PREFIX + "X509Certificate";
> 194:     public final static String X509Validation = PREFIX + "X509Validation";
> 195:     public final static String InitialSecurityProperty = PREFIX + "InitialSecurityProperty";

Let's unify order of modifiers in this file. Some fields use `public final static` and some `public static final`

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From david.holmes at oracle.com  Tue Oct 11 08:54:04 2022
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Oct 2022 18:54:04 +1000
Subject: Examples Of Many Java Swing Components In One Program.
In-Reply-To: <CAFf+5zhufpcpjxek5o9MMw51BNhYGYmfnFy_f92dg5szX7O1mA@mail.gmail.com>
References: <CAFf+5zhufpcpjxek5o9MMw51BNhYGYmfnFy_f92dg5szX7O1mA@mail.gmail.com>
Message-ID: <a8357c5b-9616-7f19-83b0-12c5d56ff774@oracle.com>

On 11/10/2022 4:38 pm, Amit wrote:
> Code for many Java Swing Components In One Program in case someone needs it.

We used to have a Swing demo in the JDK ... don't know what happened to it.

David

> Description: The program
> Examples_Of_Many_Swing_Components_In_One_Program contains examples of
> many swing components - that is, how to initialize them and use them.
> You can use code from this program in your code. Where applicable,
> appropriate listeners are also implemented.
> 
> Components covered are: JButton, JLabel, ToolTip, JTextField,
> JFormattedTextField, JCheckBox, JRadioButton, JFileChooser,
> JPasswordField, Scrollable JTextArea, Scrollable JList, JComboBox,
> JProgressBar, JSlider, Scrollable JTree, JSpinner, JColorChooser,
> JOptionPane, JDialog, JPopupMenu, JToggleButton, JSeparator, JToolBar,
> JMenuBar, JMenu, JMenuItem, JCheckBoxMenuItem, JRadioButtonMenuItem.
> 
> -------------------------------------------------------------------------------------------
> 
> import java.io.*;
> import javax.swing.*;
> import javax.swing.event.*;
> import java.awt.*;
> import java.awt.event.*;
> import java.util.*;
> import java.util.List;
> import java.beans.PropertyChangeListener;
> import java.beans.PropertyChangeEvent;
> import java.text.*;
> import javax.swing.tree.*;
> import java.time.*;
> import java.time.format.*;
> 
> public class Examples_Of_Many_Swing_Components_In_One_Program extends
> MouseAdapter implements ActionListener,
> 
>                          ItemListener,
> 
>                          ListSelectionListener,
> 
>                          ChangeListener,
> 
>                          PropertyChangeListener,
> 
>                          TreeSelectionListener {
> 
>      Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
>      int screenWidth = screenSize.width;
>      int screenHeight = screenSize.height;
>      int midScreenWidth = screenWidth / 2;
>      int xMargin = screenWidth/10;
>      // vertical gap between components
>      int vGap = 25;
>      int lineLabelHeight = 10;
>      int currentYPos = 0;
>      int componentHeight = 25;
>      int buttonWidth = 100;
>      Color lightBlue = new Color(173, 216, 230);
> 
>      JFrame jf = null;
>      JPanel jp = null;
>      JButton jbButtonExample = null;
>      JTextField jtfTextFieldExample = null;
>      JButton jbTextFieldExample = null;
>      JFormattedTextField jftfFormattedTextFieldExample = null;
>      JButton jbFormattedTextFieldExample = null;
>      JCheckBox jcb1CheckBoxExample = null;
>      JCheckBox jcb2CheckBoxExample = null;
>      JCheckBox jcb3CheckBoxExample = null;
>      JCheckBox jcb4CheckBoxExample = null;
>      JLabel jlCheckBoxExample = null;
>      JRadioButton jrb1RadioButtonExample = null;
>      JRadioButton jrb2RadioButtonExample = null;
>      JRadioButton jrb3RadioButtonExample = null;
>      JRadioButton jrb4RadioButtonExample = null;
>      JLabel jlRadioButtonExample = null;
>      JButton jbFileChooserExample = null;
>      JTextField jtfFileChooserExample = null;
>      JTextField jpfPasswordFieldExample = null;
>      JButton jbPasswordFieldExample = null;
>      JTextArea jtaTextAreaExample = null;
>      JScrollPane jspScrollableTextAreaExample = null;
>      JButton jbScrollableTextAreaExample = null;
>      JList<String> jlistScrollableListExample = null;
>      JScrollPane jspScrollableListExample = null;
>      JLabel jlScrollableListExample = null;
>      JComboBox<String> jcbComboBoxExample = null;
>      JLabel jlComboBoxExample = null;
>      JProgressBar jpbProgressBarExample = null;
>      JButton jbProgressBarExample = null;
>      JLabel jlProgressBarExample = null;
>      boolean stopThreadProgressBarExample = false;
>      JSlider jsSliderExample = null;
>      JLabel jlSliderExample = null;
>      JTree jtreeScrollableTreeExample = null;
>      JScrollPane jspScrollableTreeExample = null;
>      JLabel jlScrollableTreeExample = null;
>      JSpinner jsSpinnerExample = null;
>      JLabel jlSpinnerExample = null;
>      JColorChooser jccColorChooserExample = null;
>      JLabel jlColorChooserExample = null;
>      JButton jbOptionPaneExamplesMessage = null;
>      JButton jbOptionPaneExamplesInput = null;
>      JButton jbOptionPaneExamplesConfirm = null;
>      JButton jbOptionPaneExamplesOption = null;
>      JDialog jdDialogExample = null;
>      JComboBox jcbDialogExample = null;
>      JFormattedTextField jftfDialogExample = null;
>      JList jlistDialogExample = null;
>      JButton jbDialogExample1 = null;
>      JButton jbDialogExample2 = null;
>      JDialog jdScrollableDialogExample = null;
>      JPanel jpScrollableDialogPanel = null;
>      JButton jbDisplayScrollableDialog = null;
>      JButton jbCloseScrollableDialog = null;
>      JPopupMenu jpmPopupMenuExample = null;
>      JMenuItem jmiPopupMenuExample1 = null;
>      JMenuItem jmiPopupMenuExample2 = null;
>      JToggleButton jtbToggleButtonExample = null;
>      JButton jbToolBarExample = null;
>      JComboBox jcbToolBarExample = null;
>      JMenuBar jmb = null;
>      JMenu jm = null;
>      JMenu jmSubMenu = null;
>      JMenuItem jmiMenuItemExample = null;
>      JCheckBoxMenuItem jcbmiCheckBoxMenuItemExample = null;
>      JRadioButtonMenuItem jrbmiRadioButtonMenuItem1 = null;
>      JRadioButtonMenuItem jrbmiRadioButtonMenuItem2 = null;
> 
>      @Override
>      public void actionPerformed(ActionEvent ae) {
>          Object source = ae.getSource();
>          if (source == jbButtonExample) {
>              JOptionPane.showMessageDialog(jf, "You clicked the
> button!", "Info", JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jbTextFieldExample) {
>              String text = "You entered: " + jtfTextFieldExample.getText();
>              JOptionPane.showMessageDialog(jf, text, "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          } else if ((source == jrb1RadioButtonExample) || (source ==
> jrb2RadioButtonExample) || (source == jrb3RadioButtonExample) ||
> (source == jrb4RadioButtonExample)) {
>              String text = "You selected " + "\"" +
> ((JRadioButton)source).getText() + "\".";
>              jlRadioButtonExample.setText(text);
>          } else if (source == jbFileChooserExample) {
>              JFileChooser jfc = new JFileChooser();
>              if ((jfc.showOpenDialog(jf)) == JFileChooser.APPROVE_OPTION) {
>                  File selectedFile = jfc.getSelectedFile();
>                  jtfFileChooserExample.setText(selectedFile.getAbsolutePath());
>              }
>          } else if (source == jbPasswordFieldExample) {
>              String text = "You entered: " + jpfPasswordFieldExample.getText();
>              JOptionPane.showMessageDialog(jf, text, "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jbScrollableTextAreaExample) {
>              String text = "You wrote: " + jtaTextAreaExample.getText();
>              JOptionPane.showMessageDialog(jf, text, "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jcbComboBoxExample) {
>              // source is used here to show that selected item can be
> gotten from source
>              // instead of using jcbComboBoxExample.
>              String text = (String)(((JComboBox)source).getSelectedItem());
>              if (text.isBlank() == true) {
>                  jlComboBoxExample.setText(text);
>              } else {
>                  text = "You selected \"" + text + "\".";
>                  jlComboBoxExample.setText(text);
>              }
>          } else if (source == jbProgressBarExample) {
>              String buttonText = jbProgressBarExample.getText();
>              if ((buttonText.equals("Start Task") == true) ||
> (buttonText.equals("Start Task Again") == true)) {
>                  // example of anonymous subclass
>                  Thread thread = new Thread() {
>                      @Override
>                      public void run() {
>                          int progress = 10;
>                          while (progress <= 100) {
>                              if (stopThreadProgressBarExample == true) {
>                                  stopThreadProgressBarExample = false;
>                                  jpbProgressBarExample.setValue(0);
>                                  jbProgressBarExample.setText("Start
> Task Again");
>                                  jlProgressBarExample.setText("Task cancelled.");
>                                  return;
>                              } // end of if stopThreadProgressBarExample
>                              jlProgressBarExample.setText("Task is running..");
>                              jpbProgressBarExample.setValue(progress);
>                              if (progress == 100) {
>                                  break;
>                              }
>                              try { Thread.sleep(1000); } catch (Exception e) {}
>                              progress = progress + 10;
>                          } // end of while
>                          jbProgressBarExample.setText("Start Task Again");
>                          jlProgressBarExample.setText("Task completed.");
>                      }
>                  }; // end of new thread
>                  thread.start();
>                  jbProgressBarExample.setText("Cancel Task");
>              } else if (buttonText.equals("Cancel Task") == true) {
>                  stopThreadProgressBarExample = true;
>              } // end of if else (comparing strings)
>          } else if (source == jbToolBarExample) {
>              JOptionPane.showMessageDialog(jf, "You clicked Button 1.",
> "Info", JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jcbToolBarExample) {
>              // source is used here to show that selected item can be
> gotten from source
>              // instead of using jcbToolBarExample.
>              String text = (String)(((JComboBox)source).getSelectedItem());
>              if (text.isBlank() == false) {
>                  text = "You selected \"" + text + "\".";
>                  JOptionPane.showMessageDialog(jf, text, "Info",
> JOptionPane.INFORMATION_MESSAGE);
>              }
>          } else if (source == jmiMenuItemExample) {
>              String text = "This one program implements examples of
> many swing components.";
>              JOptionPane.showMessageDialog(jf, text, "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jcbmiCheckBoxMenuItemExample) {
>              if (jcbmiCheckBoxMenuItemExample.isSelected() == true) {
>                  JOptionPane.showMessageDialog(jf, "You have selected
> check box menu item", "Info", JOptionPane.INFORMATION_MESSAGE);
>              } else {
>                  JOptionPane.showMessageDialog(jf, "You have unselected
> check box menu item", "Info", JOptionPane.INFORMATION_MESSAGE);
>              }
>          } else if (source == jrbmiRadioButtonMenuItem1) {
>              jp.setBackground(Color.WHITE);
>          } else if (source == jrbmiRadioButtonMenuItem2) {
>              jp.setBackground(null);
>          } else if (source == jmiPopupMenuExample1) {
>              LocalTime time = LocalTime.now();
>              DateTimeFormatter formatter =
> DateTimeFormatter.ofPattern("hh:mm a");
>              String text = time.format(formatter);
>              JOptionPane.showMessageDialog(jf, text, "Current Time",
> JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jmiPopupMenuExample2) {
>              LocalDate date = LocalDate.now();
>              DateTimeFormatter formatter =
> DateTimeFormatter.ofPattern("dd-LLL-yyyy");
>              String text = date.format(formatter);
>              JOptionPane.showMessageDialog(jf, text, "Today's Date",
> JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jbDialogExample2) {
>              jcbDialogExample.setSelectedIndex(0);
>              jftfDialogExample.setText("");
>              jlistDialogExample.clearSelection();
>              jdDialogExample.setVisible(true);
>          } else if (source == jbDialogExample1) {
>              String text = "";
>              boolean error = false;
>              String textMonth = "";
>              String textYear = "";
>              String textCountry = "";
> 
>              textMonth = (String)(jcbDialogExample.getSelectedItem());
>              if (jftfDialogExample.getValue() != null) {
>                  textYear = jftfDialogExample.getText();
>              }
>              if (jlistDialogExample.getSelectedValue() != null) {
>                  textCountry = (String)(jlistDialogExample.getSelectedValue());
>              }
> 
>              if (textMonth.isBlank() == true) {
>                  error = true;
>                  text = "Please select your month of birth.\n";
>              }
>              if (textYear.isBlank() == true) {
>                  error = true;
>                  text = text + "Please enter your year of birth.\n";
>              } else if (Integer.valueOf(textYear) <= 0) {
>                  error = true;
>                  text = text + "Please enter a valid year of birth.\n";
>              }
>              if (textCountry.isBlank() == true) {
>                  error = true;
>                  text = text + "Please select your country of birth.\n";
>              }
> 
>              if (error == true) {
>                  JOptionPane.showMessageDialog(jf, text, "Error",
> JOptionPane.ERROR_MESSAGE);
>              } else {
>                  text = "";
>                  text = "Your month of birth is: " + textMonth + "\n";
>                  text = text + "Your year of birth is: " + textYear + "\n";
>                  text = text + "Your counry of birth is: " + textCountry + "\n";
>                  JOptionPane.showMessageDialog(jf, text, "Your
> deatils", JOptionPane.INFORMATION_MESSAGE);
>              }
>          } else if (source == jbDisplayScrollableDialog) {
>              jdScrollableDialogExample.setVisible(true);
>          } else if (source == jbCloseScrollableDialog) {
>              jdScrollableDialogExample.dispose();
>          } else if (source == jbOptionPaneExamplesMessage) {
>              JOptionPane.showMessageDialog(jf, "This is a Message
> Dialog Box.", "Message Dialog Box", JOptionPane.INFORMATION_MESSAGE);
>          } else if (source == jbOptionPaneExamplesInput) {
>              String text = "You entered: ";
>              String input  = JOptionPane.showInputDialog(jf, "Please
> input some text below:", "Input Dialog Box",
> JOptionPane.PLAIN_MESSAGE);
>              if (input != null) {
>                  text = text + input;
>                  JOptionPane.showMessageDialog(jf, text, "Text you
> entered", JOptionPane.INFORMATION_MESSAGE);
>              }
>          } else if (source == jbOptionPaneExamplesConfirm) {
>              JPasswordField jpf = new JPasswordField();
>              int result = JOptionPane.showConfirmDialog(jf, jpf,
> "Please input your password", JOptionPane.OK_CANCEL_OPTION,
> JOptionPane.PLAIN_MESSAGE);
>              if (result == JOptionPane.OK_OPTION) {
>                  String text = "Your password is: " + new
> String(jpf.getPassword());
>                  JOptionPane.showMessageDialog(jf, text, "Your
> password", JOptionPane.INFORMATION_MESSAGE);
>              }
>          } else if (source == jbOptionPaneExamplesOption) {
>              /*
>              JRadioButton jrb1 = new JRadioButton("Proceed");
>              JRadioButton jrb2 = new JRadioButton("Do not proceed, stop here");
>              JRadioButton jrb3 = new JRadioButton("Do not proceed, revert back");
>              Object[] objs = {jrb1, jrb2, jrb3, "Submit"};
>              */
>              Object[] objs = new Object[4];
>              objs[0] = new JRadioButton("Proceed");
>              objs[1] = new JRadioButton("Do not proceed, stop here");
>              objs[2] = new JRadioButton("Do not proceed, revert back");
>              objs[3] = "Submit";
> 
>              ButtonGroup bg = new ButtonGroup();
>              bg.add((JRadioButton)(objs[0]));
>              bg.add((JRadioButton)(objs[1]));
>              bg.add((JRadioButton)(objs[2]));
> 
>              int result = JOptionPane.showOptionDialog(jf, "Please
> select a radio button", "Option Dialog Box",
> JOptionPane.DEFAULT_OPTION, JOptionPane.PLAIN_MESSAGE, null, objs,
> null);
>              if (result == 3) { // 3 is the index of "Submit"
>                  String text = "";
>                  // if-else-if should be used but I am using ifs only
> to see that whether
>                  // more than one radio button gets selected or not or
> whether something
>                  // wrong is happening in UI.
>                  if ((((JRadioButton)(objs[0]))).isSelected() == true) {
>                      text = text + "You selected: \"Proceed\".";
>                  }
>                  if ((((JRadioButton)(objs[1]))).isSelected() == true) {
>                      text = text + "You selected: \"Do not proceed,
> stop here\".";
>                  }
>                  if ((((JRadioButton)(objs[2]))).isSelected() == true) {
>                      text = text + "You selected: \"Do not proceed,
> revert back\".";
>                  }
>                  if (text.isBlank() == true) {
>                      text = "Nothing selected.";
>                  }
>                  JOptionPane.showMessageDialog(jf, text, "Your selected
> choice", JOptionPane.INFORMATION_MESSAGE);
>              }
>              //String text = "Result is: " + result;
>              //JOptionPane.showMessageDialog(jf, text, "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          }
>      } // end of actionPerformed
> 
>      // for JCheckBox and JToggleButton
>      @Override
>      public void itemStateChanged(ItemEvent ie) {
>          String text = "";
>          Object source = ie.getItemSelectable();
>          if ((source == jcb1CheckBoxExample) || (source ==
> jcb2CheckBoxExample) || (source == jcb3CheckBoxExample) || (source ==
> jcb4CheckBoxExample)) {
>              if (ie.getStateChange() == ItemEvent.SELECTED) {
>                  text = "You selected ";
>              } else {
>                  text = "You unselected ";
>              }
>              text = text + "\"" + ((JCheckBox)source).getText() + "\".";
>              jlCheckBoxExample.setText(text);
>          } else if (source == jtbToggleButtonExample) {
>              if (jtbToggleButtonExample.isSelected() == true) {
>                  jtbToggleButtonExample.setText("ON");
>                  jtbToggleButtonExample.setOpaque(true);
>                  jtbToggleButtonExample.setBackground(Color.GREEN);
>              } else {
>                  jtbToggleButtonExample.setText("OFF");
>                  jtbToggleButtonExample.setOpaque(true);
>                  jtbToggleButtonExample.setBackground(Color.YELLOW);
>              }
>          }
>      } // end of itemStateChanged
> 
>      // for JList
>      @Override
>      public void valueChanged(ListSelectionEvent lse) {
>          String text = "";
>          Object source = lse.getSource();
>          if (source == jlistScrollableListExample) {
>              List<String> lst =
> jlistScrollableListExample.getSelectedValuesList();
>              if (lst.size() <= 0) {
>                  jlScrollableListExample.setText(text);
>              } else {
>                  text = "Your selected items are: ";
>                  boolean first = true;
>                  for (String str : lst) {
>                      if (first == false) {
>                          text = text + ", ";
>                      }
>                      text = text + str;
>                      first = false;
>                  } // end of for loop
>                  text = text + ".";
>                  jlScrollableListExample.setText(text);
>              } // end of if else
>          } // end of if source
>      } // end of valueChanged
> 
>      // for JSlider, JSpinner, and JColorChooser
>      @Override
>      public void stateChanged(ChangeEvent ce) {
>          String text = "";
>          Object source = ce.getSource();
>          if (source == jsSliderExample) {
>              JSlider jsSource = (JSlider)source;
>              if (!jsSource.getValueIsAdjusting()) {
>                  int value = (int)(jsSource.getValue());
>                  text = "The current value from slider is: " + value;
>                  jlSliderExample.setText(text);
>              }
>          } else if (source == jsSpinnerExample) {
>              JSpinner jspnSource = (JSpinner)source;
>              SpinnerModel sm = jspnSource.getModel();
>              if (sm instanceof SpinnerNumberModel) {
>                  text = "The current value from spinner is: " +
> ((SpinnerNumberModel)(sm)).getNumber().intValue();
>                  jlSpinnerExample.setText(text);
>              } else {
>                  text = "Something went wrong.";
>                  jlSpinnerExample.setText(text);
>              }
>          } else if (source == jccColorChooserExample.getSelectionModel()) {
>              Color newColor = jccColorChooserExample.getColor();
>              jlColorChooserExample.setBackground(newColor);
>          }
>      } // end of stateChanged
> 
>      // for JFormattedTextField
>      @Override
>      public void propertyChange(PropertyChangeEvent pce) {
>          Object source = pce.getSource();
>          if (source == jftfFormattedTextFieldExample) {
>              double amount =
> ((Number)(jftfFormattedTextFieldExample.getValue())).doubleValue();
>              String text = "You entered amount: " + amount;
>              JOptionPane.showMessageDialog(jf, text, "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          }
>      } // end of propertyChange
> 
>      // for JTree
>      @Override
>      public void valueChanged(TreeSelectionEvent tse) {
>          String text = "";
>          Object source = tse.getSource();
>          if (source == jtreeScrollableTreeExample) {
>              DefaultMutableTreeNode node =
> (DefaultMutableTreeNode)(((JTree)source).getLastSelectedPathComponent());
>              if (node == null) {
>                  jlScrollableTreeExample.setText(text);
>              } else {
>                  text = "You selected: " + node.getUserObject().toString();
>                  jlScrollableTreeExample.setText(text);
>              }
>          }
>      } // end of valueChanged
> 
>      // for JPopupMenu to show up
>      @Override
>      public void mousePressed(MouseEvent e) {
>          //JOptionPane.showMessageDialog(jf, "Mouse Pressed", "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          if (e.isPopupTrigger()) {
>              jpmPopupMenuExample.show(e.getComponent(), e.getX(), e.getY());
>          }
>      } // end of mousePressed
> 
>      // for JPopupMenu to show up
>      @Override
>      public void mouseReleased(MouseEvent e) {
>          //JOptionPane.showMessageDialog(jf, "Mouse Released", "Info",
> JOptionPane.INFORMATION_MESSAGE);
>          if (e.isPopupTrigger()) {
>              jpmPopupMenuExample.show(e.getComponent(), e.getX(), e.getY());
>          }
>      } // end of mouseReleased
> 
>      //void createJFrameExample() {
>          //jf = SwingLibrary.setupJFrameAndGet("Learn Java Swing GUI
> Programming By Examples", screenWidth, screenHeight);
>          //jf = SwingLibrary.setupJFrameAndGet("Learn Java Swing GUI
> Programming By Examples", 0, 0);
>          //jf.setVisible(true);
>      //} // end of addJFrameExample
> 
>      void createScrollableJFrameExample() {
>          ArrayList<Object> a =
> SwingLibrary.setupScrollableJFrameAndGetFrameAndPanel("Learn Java
> Swing GUI Programming By Examples", screenWidth, screenHeight + 4500);
>          jf = (JFrame)(a.get(0));
>          jp = (JPanel)(a.get(1));
>      } // end of addScrollableJFrameExample
> 
>      void addJButtonExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Button Example", 0, currentYPos, screenWidth,
> componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbButtonExample = SwingLibrary.setupJButtonAndGet("Click Me!",
> this, true, midScreenWidth - 50, currentYPos, buttonWidth,
> componentHeight);
>          jp.add(jbButtonExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJButtonExample
> 
>      void addJLabelExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Label Example", 0, currentYPos, screenWidth,
> componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("This is a label!",
> true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> midScreenWidth - 100, currentYPos, 200, componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJLabelExample
> 
>      void addToolTipExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Tool Tip Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Hover the mouse
> over me to see the tool tip!", true, Color.GREEN,
> SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
> 150, currentYPos, 300, componentHeight);
>          jl.setToolTipText("This is a tool tip!");
>          // show tool tip immediately
>          ToolTipManager.sharedInstance().setInitialDelay(0);
>          // keep tool tip showing
>          ToolTipManager.sharedInstance().setDismissDelay(Integer.MAX_VALUE);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addToolTipExample
> 
>      void addJTextFieldExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Text Field Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Enter some text in
> below field:", false, null, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight;
>          jtfTextFieldExample =
> SwingLibrary.setupJTextFieldAndGet(xMargin, currentYPos, screenWidth -
> (xMargin*2), componentHeight);
>          jp.add(jtfTextFieldExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbTextFieldExample = SwingLibrary.setupJButtonAndGet("Submit",
> this, true, midScreenWidth - 50, currentYPos, buttonWidth,
> componentHeight);
>          jp.add(jbTextFieldExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJTextFieldExample
> 
>      void addJFormattedTextFieldExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Formatted Text Field Example", 0,
> currentYPos, screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Enter some number
> in below formatted field (it accepts numbers only):", false, null,
> SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
> 200, currentYPos, 400, componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight;
>          jftfFormattedTextFieldExample =
> SwingLibrary.setupJFormattedTextFieldAndGet(NumberFormat.getNumberInstance(),
> 1000, this, "value", xMargin, currentYPos, screenWidth - (xMargin*2),
> componentHeight);
>          jp.add(jftfFormattedTextFieldExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbFormattedTextFieldExample =
> SwingLibrary.setupJButtonAndGet("Click to shift focus away from
> formatted field", this, true, midScreenWidth - 200, currentYPos, 400,
> componentHeight);
>          jp.add(jbFormattedTextFieldExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJFormattedTextFieldExample
> 
>      void addJCheckBoxExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Check Box Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Select/Unselect a
> checkbox", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight;
>          jcb1CheckBoxExample = SwingLibrary.setupJCheckBoxAndGet("One",
> false, this, midScreenWidth - 100, currentYPos, 200, componentHeight);
>          jp.add(jcb1CheckBoxExample);
>          currentYPos = currentYPos + componentHeight;
>          jcb2CheckBoxExample = SwingLibrary.setupJCheckBoxAndGet("Two",
> false, this, midScreenWidth - 100, currentYPos, 200, componentHeight);
>          jp.add(jcb2CheckBoxExample);
>          currentYPos = currentYPos + componentHeight;
>          jcb3CheckBoxExample =
> SwingLibrary.setupJCheckBoxAndGet("Three", false, this, midScreenWidth
> - 100, currentYPos, 200, componentHeight);
>          jp.add(jcb3CheckBoxExample);
>          currentYPos = currentYPos + componentHeight;
>          jcb4CheckBoxExample =
> SwingLibrary.setupJCheckBoxAndGet("Four", false, this, midScreenWidth
> - 100, currentYPos, 200, componentHeight);
>          jp.add(jcb4CheckBoxExample);
>          currentYPos = currentYPos + componentHeight;
>          jlCheckBoxExample = SwingLibrary.setupJLabelAndGet("", true,
> Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> midScreenWidth - 100, currentYPos, 200, componentHeight);
>          jp.add(jlCheckBoxExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJCheckBoxExample
> 
>      void addJRadioButtonExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Radio Button Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Select a radio
> button", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight;
>          jrb1RadioButtonExample =
> SwingLibrary.setupJRadioButtonAndGet("A", false, this, midScreenWidth
> - 100, currentYPos, 200, componentHeight);
>          jp.add(jrb1RadioButtonExample);
>          currentYPos = currentYPos + componentHeight;
>          jrb2RadioButtonExample =
> SwingLibrary.setupJRadioButtonAndGet("B", false, this, midScreenWidth
> - 100, currentYPos, 200, componentHeight);
>          jp.add(jrb2RadioButtonExample);
>          currentYPos = currentYPos + componentHeight;
>          jrb3RadioButtonExample =
> SwingLibrary.setupJRadioButtonAndGet("C", false, this, midScreenWidth
> - 100, currentYPos, 200, componentHeight);
>          jp.add(jrb3RadioButtonExample);
>          currentYPos = currentYPos + componentHeight;
>          jrb4RadioButtonExample =
> SwingLibrary.setupJRadioButtonAndGet("D", false, this, midScreenWidth
> - 100, currentYPos, 200, componentHeight);
>          jp.add(jrb4RadioButtonExample);
> 
>          // add all radio buttons to a button group so that only one radio button
>          // can be selected at a time
>          ButtonGroup bg = SwingLibrary.setupButtonGroupAndGet();
>          bg.add(jrb1RadioButtonExample);
>          bg.add(jrb2RadioButtonExample);
>          bg.add(jrb3RadioButtonExample);
>          bg.add(jrb4RadioButtonExample);
> 
>          currentYPos = currentYPos + componentHeight;
>          jlRadioButtonExample = SwingLibrary.setupJLabelAndGet("",
> true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> midScreenWidth - 100, currentYPos, 200, componentHeight);
>          jp.add(jlRadioButtonExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJRadioButtonExample
> 
>      void addJFileChooserExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("File Chooser Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Select a file by
> clicking Browse button below:", true, Color.GREEN,
> SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
> 150, currentYPos, 300, componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight + 4;
>          jbFileChooserExample =
> SwingLibrary.setupJButtonAndGet("Browse", this, true, midScreenWidth -
> 50, currentYPos, buttonWidth, componentHeight);
>          jp.add(jbFileChooserExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jl = SwingLibrary.setupJLabelAndGet("The path to file that you
> choose will appear below:", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight + 4;
>          jtfFileChooserExample =
> SwingLibrary.setupJTextFieldAndGet(xMargin, currentYPos, screenWidth -
> (xMargin*2), componentHeight);
>          jp.add(jtfFileChooserExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJFileChooserExample
> 
>      void addJPasswordFieldExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Password Field Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Enter some text
> (password) in below field:", false, null, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight;
>          jpfPasswordFieldExample =
> SwingLibrary.setupJPasswordFieldAndGet(xMargin, currentYPos,
> screenWidth - (xMargin*2), componentHeight);
>          jp.add(jpfPasswordFieldExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbPasswordFieldExample =
> SwingLibrary.setupJButtonAndGet("Submit", this, true, midScreenWidth -
> 50, currentYPos, buttonWidth, componentHeight);
>          jp.add(jbPasswordFieldExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJPasswordFieldExample
> 
>      void addScrollableJTextAreaExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Scrollable Text Area Example", 0,
> currentYPos, screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Write something in
> Text Area below:", false, null, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight;
>          jtaTextAreaExample = SwingLibrary.setupJTextAreaAndGet("", 10,
> 100, true, true, true, false, 0, 0, 0, 0);
>          jspScrollableTextAreaExample =
> SwingLibrary.setupScrollableJTextAreaAndGet(jtaTextAreaExample,
> (xMargin*5)/2, currentYPos, screenWidth - (xMargin*5),
> componentHeight*4);
>          jp.add(jspScrollableTextAreaExample);
>          currentYPos = currentYPos + componentHeight*4 + vGap;
>          jbScrollableTextAreaExample =
> SwingLibrary.setupJButtonAndGet("Submit", this, true, midScreenWidth -
> 50, currentYPos, buttonWidth, componentHeight);
>          jp.add(jbScrollableTextAreaExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addScrollableJTextAreaExample
> 
>      void addScrollableJListExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Scrollable List Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Select/Unselect
> item(s) from list", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight + 4;
> 
>          // add items to default list model
>          DefaultListModel<String> dlm = new DefaultListModel<>();
>          dlm.addElement("One");
>          dlm.addElement("Two");
>          dlm.addElement("Three");
>          dlm.addElement("Four");
>          dlm.addElement("Five");
>          dlm.addElement("Six");
>          dlm.addElement("Seven");
>          dlm.addElement("Eight");
>          dlm.addElement("Nine");
>          dlm.addElement("Ten");
> 
>          jlistScrollableListExample =
> SwingLibrary.setupJListAndGet(dlm,
> ListSelectionModel.MULTIPLE_INTERVAL_SELECTION, 3, -1, this, false, 0,
> 0, 0, 0);
>          jspScrollableListExample =
> SwingLibrary.setupScrollableJListAndGet(jlistScrollableListExample,
> xMargin*4, currentYPos, screenWidth - (xMargin*8), componentHeight*4);
>          jp.add(jspScrollableListExample);
>          currentYPos = currentYPos + componentHeight*4 + vGap;
>          jlScrollableListExample = SwingLibrary.setupJLabelAndGet("",
> true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> xMargin, currentYPos, screenWidth - (xMargin*2), componentHeight);
>          jp.add(jlScrollableListExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addScrollableJListExample
> 
>      void addJComboBoxExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Combo Box Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Select an item
> from combo box", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight + 4;
> 
>          // add items to default list model
>          DefaultComboBoxModel<String> dcbm = new DefaultComboBoxModel<>();
>          dcbm.addElement("");
>          dcbm.addElement("A");
>          dcbm.addElement("B");
>          dcbm.addElement("C");
>          dcbm.addElement("D");
>          dcbm.addElement("E");
>          dcbm.addElement("V");
>          dcbm.addElement("W");
>          dcbm.addElement("X");
>          dcbm.addElement("Y");
>          dcbm.addElement("Z");
> 
>          jcbComboBoxExample = SwingLibrary.setupJComboBoxAndGet(dcbm,
> 0, this, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jcbComboBoxExample);
>          currentYPos = currentYPos + componentHeight*4 + vGap;
>          jlComboBoxExample = SwingLibrary.setupJLabelAndGet("", true,
> Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> midScreenWidth - 100, currentYPos, 200, componentHeight);
>          jp.add(jlComboBoxExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJComboBoxExample
> 
>      void addJProgressBarExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Progress Bar Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jlProgressBarExample = SwingLibrary.setupJLabelAndGet("Task
> not started.", false, null, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jlProgressBarExample);
>          currentYPos = currentYPos + componentHeight;
>          jpbProgressBarExample =
> SwingLibrary.setupJProgressBarAndGet(SwingConstants.HORIZONTAL, 0,
> 100, 0, true, true, true, xMargin, currentYPos, screenWidth -
> (xMargin*2), componentHeight);
>          jp.add(jpbProgressBarExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbProgressBarExample = SwingLibrary.setupJButtonAndGet("Start
> Task", this, true, midScreenWidth - 100, currentYPos, 200,
> componentHeight);
>          jp.add(jbProgressBarExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJProgressBarExample
> 
>      void addJSliderExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Slider Example", 0, currentYPos, screenWidth,
> componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jsSliderExample =
> SwingLibrary.setupJSliderAndGet(SwingConstants.HORIZONTAL, 0, 100, 20,
> 1, 10, true, true, this, true, xMargin, currentYPos, screenWidth -
> (xMargin*2), componentHeight*2);
>          jp.add(jsSliderExample);
>          currentYPos = currentYPos + componentHeight*2 + vGap;
>          jlSliderExample = SwingLibrary.setupJLabelAndGet("The current
> value from slider is: 20", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 110, currentYPos, 220,
> componentHeight);
>          jp.add(jlSliderExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJSliderExample
> 
>      void addScrollableJTreeExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Scrollable Tree Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("You can select any
> node in the tree.", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 110, currentYPos, 220,
> componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight + 4;
> 
>          // create tree nodes
>          DefaultMutableTreeNode rootNode = new DefaultMutableTreeNode("Names");
> 
>          DefaultMutableTreeNode j = new DefaultMutableTreeNode("J");
>          DefaultMutableTreeNode james = new DefaultMutableTreeNode("James");
>          DefaultMutableTreeNode jerrod = new DefaultMutableTreeNode("Jerrod");
>          j.add(james);
>          j.add(jerrod);
>          rootNode.add(j);
> 
>          DefaultMutableTreeNode n = new DefaultMutableTreeNode("N");
>          DefaultMutableTreeNode nathan = new DefaultMutableTreeNode("Nathan");
>          DefaultMutableTreeNode nicholas = new
> DefaultMutableTreeNode("Nicholas");
>          n.add(nathan);
>          n.add(nicholas);
>          rootNode.add(n);
> 
>          DefaultMutableTreeNode v = new DefaultMutableTreeNode("V");
>          DefaultMutableTreeNode vincent = new DefaultMutableTreeNode("Vincent");
>          v.add(vincent);
>          rootNode.add(v);
> 
>          jtreeScrollableTreeExample =
> SwingLibrary.setupJTreeAndGet(rootNode,
> TreeSelectionModel.SINGLE_TREE_SELECTION, this, false, 0, 0, 0, 0);
>          jspScrollableTreeExample =
> SwingLibrary.setupScrollableJTreeAndGet(jtreeScrollableTreeExample,
> xMargin*4, currentYPos, screenWidth - (xMargin*8), componentHeight*4);
>          jp.add(jspScrollableTreeExample);
>          currentYPos = currentYPos + componentHeight*4 + vGap;
>          jlScrollableTreeExample = SwingLibrary.setupJLabelAndGet("",
> true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> midScreenWidth - 110, currentYPos, 220, componentHeight);
>          jp.add(jlScrollableTreeExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addScrollableJTree example
> 
>      void addJSpinnerExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Spinner Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Click on up arrow
> or down arrow of the spinner to set a value.", true, Color.GREEN,
> SwingConstants.CENTER, SwingConstants.CENTER, true, midScreenWidth -
> 200, currentYPos, 400, componentHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + componentHeight*2;
>          SpinnerNumberModel snm = new SpinnerNumberModel(20, 1, null, 1);
>          jsSpinnerExample = SwingLibrary.setupJSpinnerAndGet(snm,
> false, this, xMargin*4, currentYPos, screenWidth - (xMargin*8),
> componentHeight);
>          jp.add(jsSpinnerExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jlSpinnerExample = SwingLibrary.setupJLabelAndGet("The current
> value from spinner is: 20", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 150, currentYPos, 300,
> componentHeight);
>          jp.add(jlSpinnerExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJSpinnerExample
> 
>      void addJColorChooserExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Color Chooser Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jlColorChooserExample = SwingLibrary.setupJLabelAndGet("Select
> a color and the background of this label will change to that color.",
> true, Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> midScreenWidth - 250, currentYPos, 500, componentHeight);
>          jp.add(jlColorChooserExample);
>          currentYPos = currentYPos + componentHeight*2;
>          jccColorChooserExample =
> SwingLibrary.setupJColorChooserAndGet(Color.GREEN, true, "Choose a
> color", this, xMargin*2, currentYPos, screenWidth - (xMargin*4),
> componentHeight*12);
>          jp.add(jccColorChooserExample);
>          currentYPos = currentYPos + componentHeight*12 + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJColorChooserExample
> 
>      void addJOptionPaneExamples() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Option Pane Examples", 0, currentYPos,
> screenWidth, componentHeight);
> 
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbOptionPaneExamplesMessage =
> SwingLibrary.setupJButtonAndGet("Click to see the Message Dialog Box",
> this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
>          jp.add(jbOptionPaneExamplesMessage);
> 
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbOptionPaneExamplesInput =
> SwingLibrary.setupJButtonAndGet("Click to see the Input Dialog Box",
> this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
>          jp.add(jbOptionPaneExamplesInput);
> 
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbOptionPaneExamplesConfirm =
> SwingLibrary.setupJButtonAndGet("Click to see the Confirm Dialog Box",
> this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
>          jp.add(jbOptionPaneExamplesConfirm);
> 
>          currentYPos = currentYPos + componentHeight + vGap;
>          jbOptionPaneExamplesOption =
> SwingLibrary.setupJButtonAndGet("Click to see the Option Dialog Box",
> this, true, midScreenWidth - 150, currentYPos, 300, componentHeight);
>          jp.add(jbOptionPaneExamplesOption);
> 
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJOptionPaneExample
> 
>      void addJDialogExample() {
>          int dialogWidth = 336;
>          int dialogHeight = 350;
>          int midDialogWidth = dialogWidth/2;
>          int jdXPos = 10;
>          int jdYPos = 10;
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Dialog Example", 0, currentYPos, screenWidth,
> componentHeight);
>          currentYPos = currentYPos + vGap;
> 
>          jdDialogExample = SwingLibrary.setupJDialogAndGet(jf,
> "Details", true, dialogWidth, dialogHeight);
> 
>          JLabel jl = SwingLibrary.setupJLabelAndGet("Select your month
> of birth from combo box:", false, null, SwingConstants.LEFT,
> SwingConstants.CENTER, true, jdXPos, jdYPos, 300, componentHeight);
>          jdDialogExample.add(jl);
>          DefaultComboBoxModel<String> dcbm = new DefaultComboBoxModel<>();
>          dcbm.addElement("");
>          dcbm.addElement("Jan");
>          dcbm.addElement("Feb");
>          dcbm.addElement("Mar");
>          dcbm.addElement("Apr");
>          dcbm.addElement("May");
>          dcbm.addElement("Jun");
>          dcbm.addElement("Jul");
>          dcbm.addElement("Aug");
>          dcbm.addElement("Sep");
>          dcbm.addElement("Oct");
>          dcbm.addElement("Nov");
>          dcbm.addElement("Dec");
>          jdYPos = jdYPos + componentHeight;
>          jcbDialogExample = SwingLibrary.setupJComboBoxAndGet(dcbm, 0,
> null, true, jdXPos, jdYPos, 300, componentHeight);
>          jdDialogExample.add(jcbDialogExample);
> 
>          jdYPos = jdYPos + componentHeight*2;
>          jl = SwingLibrary.setupJLabelAndGet("Enter your year of birth
> in text field (4 digits):", false, null, SwingConstants.LEFT,
> SwingConstants.CENTER, true, jdXPos, jdYPos, 300, componentHeight);
>          jdDialogExample.add(jl);
>          jdYPos = jdYPos + componentHeight;
>          NumberFormat format = NumberFormat.getIntegerInstance();
>          format.setGroupingUsed(false);
>          format.setMinimumIntegerDigits(0);
>          format.setMaximumIntegerDigits(4);
>          jftfDialogExample =
> SwingLibrary.setupJFormattedTextFieldAndGet(format, null, null, null,
> jdXPos, jdYPos, 300, componentHeight);
>          jdDialogExample.add(jftfDialogExample);
> 
>          jdYPos = jdYPos + componentHeight*2;
>          jl = SwingLibrary.setupJLabelAndGet("Select your country of
> birth from list:", false, null, SwingConstants.LEFT,
> SwingConstants.CENTER, true, jdXPos, jdYPos, 300, componentHeight);
>          jdDialogExample.add(jl);
>          DefaultListModel<String> dlm = new DefaultListModel<>();
>          dlm.addElement("USA");
>          dlm.addElement("Outside USA");
>          jdYPos = jdYPos + componentHeight;
>          jlistDialogExample = SwingLibrary.setupJListAndGet(dlm,
> ListSelectionModel.SINGLE_SELECTION, 2, -1, null, true, jdXPos,
> jdYPos, 300, componentHeight*2 - 14);
>          jdDialogExample.add(jlistDialogExample);
> 
>          jdYPos = jdYPos + componentHeight*3;
>          jbDialogExample1 = SwingLibrary.setupJButtonAndGet("Submit",
> this, true, midDialogWidth - 50, jdYPos, 100, componentHeight);
>          jdDialogExample.add(jbDialogExample1);
> 
>          currentYPos = currentYPos + componentHeight;
>          jbDialogExample2 = SwingLibrary.setupJButtonAndGet("Click to
> see the dialog box", this, true, midScreenWidth - 150, currentYPos,
> buttonWidth*3, componentHeight);
>          jp.add(jbDialogExample2);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJDialogExample
> 
>      void addScrollableJDialogExample() {
>          int dialogWidth = 400;
>          int dialogHeight = 400;
>          int midDialogWidth = dialogWidth/2;
>          int panelWidth = 420;
>          int panelHeight = 570;
>          int jdYPos = 10;
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Scrollable Dialog Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + vGap;
> 
>          ArrayList<Object> a =
> SwingLibrary.setupScrollableJDialogAndGetDialogAndPanel(jf, "List of
> Labels", true, dialogWidth, dialogHeight, panelWidth, panelHeight);
>          jdScrollableDialogExample = (JDialog)(a.get(0));
>          jpScrollableDialogPanel = (JPanel)(a.get(1));
> 
>          JLabel jl = null;
>          String text = null;
>          for (int i = 0; i < 15; i++) {
>              text = "This is label " + (i + 1);
>              jl = SwingLibrary.setupJLabelAndGet(text, true,
> Color.BLACK, SwingConstants.LEFT, SwingConstants.CENTER, true, 10,
> jdYPos, 400, componentHeight);
>              jl.setForeground(Color.WHITE);
>              jdYPos = jdYPos + 35;
>              jpScrollableDialogPanel.add(jl);
>          }
> 
>          jbCloseScrollableDialog =
> SwingLibrary.setupJButtonAndGet("Close", this, true, midDialogWidth -
> 50, jdYPos, 100, componentHeight);
>          jpScrollableDialogPanel.add(jbCloseScrollableDialog);
> 
>          currentYPos = currentYPos + componentHeight;
>          jbDisplayScrollableDialog =
> SwingLibrary.setupJButtonAndGet("Click to see the scrollable dialog
> box", this, true, midScreenWidth - 150, currentYPos, buttonWidth*3,
> componentHeight);
>          jp.add(jbDisplayScrollableDialog);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addScrollableJDialogExample
> 
>      void addJPopupMenuExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Popup Menu Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jlPopupMenuExample =
> SwingLibrary.setupJLabelAndGet("Right click anywhere in the frame to
> the see the popup menu.", true, Color.GREEN, SwingConstants.CENTER,
> SwingConstants.CENTER, true, midScreenWidth - 250, currentYPos, 500,
> componentHeight);
>          jp.add(jlPopupMenuExample);
>          jpmPopupMenuExample = new JPopupMenu("Popup Menu");
>          jmiPopupMenuExample1 = SwingLibrary.setupJMenuItemAndGet("Show
> current time", this, null, null, null);
>          jpmPopupMenuExample.add(jmiPopupMenuExample1);
>          jpmPopupMenuExample.addSeparator();
>          jmiPopupMenuExample2 = SwingLibrary.setupJMenuItemAndGet("Show
> today's date", this, null, null, null);
>          jpmPopupMenuExample.add(jmiPopupMenuExample2);
> 
>          // Add mouse listener on JPanel so that clicking anywhere on
> JPanel will bring up the popup menu.
>          jp.addMouseListener(this);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJPopupMenuExample
> 
>      void addJToggleButtonExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Toggle Button Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          jtbToggleButtonExample =
> SwingLibrary.setupJToggleButtonAndGet("OFF", this, true, Color.YELLOW,
> true, midScreenWidth - 50, currentYPos, buttonWidth, componentHeight);
>          jp.add(jtbToggleButtonExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJToggleButtonExample
> 
>      void addJSeparatorExample() {
>          currentYPos = currentYPos + vGap;
>          addHeadingLabel("Separator Example", 0, currentYPos,
> screenWidth, componentHeight);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JLabel jlSeparatorExample =
> SwingLibrary.setupJLabelAndGet("Below are the separators.", true,
> Color.GREEN, SwingConstants.CENTER, SwingConstants.CENTER, true,
> midScreenWidth - 100, currentYPos, 200, componentHeight);
>          jp.add(jlSeparatorExample);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JSeparator sep1 =
> SwingLibrary.setupJSeparatorAndGet(SwingConstants.HORIZONTAL,
> Color.YELLOW, true, xMargin*2, currentYPos, screenWidth - (xMargin*4),
> componentHeight);
>          jp.add(sep1);
>          currentYPos = currentYPos + componentHeight + vGap;
>          JSeparator sep2 =
> SwingLibrary.setupJSeparatorAndGet(SwingConstants.HORIZONTAL,
> Color.GREEN, true, xMargin*2, currentYPos, screenWidth - (xMargin*4),
> componentHeight);
>          jp.add(sep2);
>          currentYPos = currentYPos + componentHeight + vGap;
>          addLineLabel(currentYPos);
>      } // end of addJSeparatorExample
> 
>      void addJToolBarExample() {
>          JToolBar jtbToolBarExample = new JToolBar("Tool Bar",
> SwingConstants.HORIZONTAL);
>          jbToolBarExample = SwingLibrary.setupJButtonAndGet("Button 1",
> this, false, 0, 0, 0, 0);
>          jtbToolBarExample.add(jbToolBarExample);
>          jtbToolBarExample.addSeparator();
>          // Now, add a combo box to tool bar
>          DefaultComboBoxModel<String> dcbm = new DefaultComboBoxModel<>();
>          dcbm.addElement("");
>          dcbm.addElement("Item 1");
>          dcbm.addElement("Item 2");
>          dcbm.addElement("Item 3");
>          dcbm.addElement("Item 4");
>          jcbToolBarExample = SwingLibrary.setupJComboBoxAndGet(dcbm, 0,
> this, false, 0, 0, 0, 0);
>          jtbToolBarExample.add(jcbToolBarExample);
>          //jtbToolBarExample.setBorderPainted(true);
>          jf.add(jtbToolBarExample, BorderLayout.NORTH);
>      } // end of addJToolBarExample
> 
>      void addJMenuItemsExample() {
>          KeyStroke k = KeyStroke.getKeyStroke(KeyEvent.VK_I,
> InputEvent.CTRL_DOWN_MASK);
>          jmb = SwingLibrary.setupJMenuBarAndGet(null, Color.GREEN);
>          jm = SwingLibrary.setupJMenuAndGet("Help", Color.BLACK, Color.YELLOW);
>          jmSubMenu = SwingLibrary.setupJMenuAndGet("More Help",
> Color.BLUE, Color.YELLOW);
>          jmiMenuItemExample =
> SwingLibrary.setupJMenuItemAndGet("About", this, k, null,
> Color.WHITE);
>          jcbmiCheckBoxMenuItemExample = new JCheckBoxMenuItem("Show a
> message dialog box");
>          jcbmiCheckBoxMenuItemExample.addActionListener(this);
>          jrbmiRadioButtonMenuItem1 = new JRadioButtonMenuItem("Change
> background color to white");
>          jrbmiRadioButtonMenuItem1.addActionListener(this);
>          jrbmiRadioButtonMenuItem2 = new JRadioButtonMenuItem("Change
> background color to default");
>          jrbmiRadioButtonMenuItem2.addActionListener(this);
>          ButtonGroup bg = SwingLibrary.setupButtonGroupAndGet();
>          bg.add(jrbmiRadioButtonMenuItem1);
>          bg.add(jrbmiRadioButtonMenuItem2);
>          jmSubMenu.add(jmiMenuItemExample);
>          jmSubMenu.addSeparator();
>          jmSubMenu.add(jcbmiCheckBoxMenuItemExample);
>          jmSubMenu.addSeparator();
>          jmSubMenu.add(jrbmiRadioButtonMenuItem1);
>          jmSubMenu.add(jrbmiRadioButtonMenuItem2);
>          jm.add(jmSubMenu);
>          jmb.add(jm);
>          jf.setJMenuBar(jmb);
>      } // end of addJMenuItemsExample
> 
>      void createAndShowSwingGUIExamples() {
>          //createJFrameExample();
>          createScrollableJFrameExample();
>          addJButtonExample();
>          addJLabelExample();
>          addToolTipExample();
>          addJTextFieldExample();
>          addJFormattedTextFieldExample();
>          addJCheckBoxExample();
>          addJRadioButtonExample();
>          addJFileChooserExample();
>          addJPasswordFieldExample();
>          addScrollableJTextAreaExample();
>          addScrollableJListExample();
>          addJComboBoxExample();
>          addJProgressBarExample();
>          addJSliderExample();
>          addScrollableJTreeExample();
>          addJSpinnerExample();
>          addJColorChooserExample();
>          addJOptionPaneExamples();
>          addJDialogExample();
>          addScrollableJDialogExample();
>          addJPopupMenuExample();
>          addJToggleButtonExample();
>          addJSeparatorExample();
>          addJToolBarExample();
>          addJMenuItemsExample();
> 
>          // Frame has been created, all examples have been added, now
> show the frame
>          jf.setVisible(true);
>      } // end of createAndShowSwingExamples
> 
>      void addHeadingLabel(String text, int xpos, int ypos, int width,
> int height) {
>          //JLabel jl = SwingLibrary.setupJLabelAndGet(text, true,
> Color.YELLOW, SwingConstants.CENTER, SwingConstants.CENTER, true,
> xpos, ypos, width, height);
>          JLabel jl = SwingLibrary.setupJLabelAndGet(text, true,
> lightBlue, SwingConstants.CENTER, SwingConstants.CENTER, true, xpos,
> ypos, width, height);
>          jp.add(jl);
>      } // end of addHeadingLabel
> 
>      void addLineLabel(int ypos) {
>          JLabel jl = SwingLibrary.setupJLabelAndGet("", true,
> Color.BLACK, SwingConstants.CENTER, SwingConstants.CENTER, true, 0,
> ypos, screenWidth, lineLabelHeight);
>          jp.add(jl);
>          currentYPos = currentYPos + lineLabelHeight;
>      } // end of addLineLabel
> 
>      public static void main(String[] args) {
>          Examples_Of_Many_Swing_Components_In_One_Program eomsciop =
> new Examples_Of_Many_Swing_Components_In_One_Program();
>          eomsciop.createAndShowSwingGUIExamples();
>      } // end of main
> 
> } // end of Examples_Of_Many_Swing_Components_In_One_Program
> 
> class SwingLibrary {
> 
>      // if width is 0 then the frame is maximized horizontally
>      // if height is 0 then the frame is maximized vertically
>      public static JFrame setupJFrameAndGet(String title, int width,
> int height) {
>          int state = 0;
>          JFrame tmpJF = new JFrame(title);
>          if (width == 0) {
>              state = state | JFrame.MAXIMIZED_HORIZ;
>          }
>          if (height == 0) {
>              state = state | JFrame.MAXIMIZED_VERT;
>          }
>          if ((width != 0) || (height != 0)) {
>              tmpJF.setSize(width, height);
>          }
>          tmpJF.setExtendedState(tmpJF.getExtendedState() | state);
>          tmpJF.setLocationRelativeTo(null);
>          tmpJF.setLayout(null);
>          tmpJF.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>          return tmpJF;
>      } // end of setupJFrameAndGet
> 
>      // width and height are the preferred width and height of JPanel
>      public static ArrayList<Object>
> setupScrollableJFrameAndGetFrameAndPanel(String title, int width, int
> height) {
>          JFrame tmpJF = new JFrame(title);
>          tmpJF.setExtendedState(tmpJF.getExtendedState() |
> JFrame.MAXIMIZED_BOTH);
>          tmpJF.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>          //tmpJF.setLayout(null);
> 
>          JPanel tmpJP = new JPanel();
>          //tmpJP.setBounds(xpos, ypos, width + 1000, height + 1000);
>          tmpJP.setPreferredSize(new Dimension(width, height));
>          tmpJP.setLayout(null);
> 
>          JScrollPane tmpJSPFrame = new JScrollPane(tmpJP,
> JScrollPane.VERTICAL_SCROLLBAR_ALWAYS,
> JScrollPane.HORIZONTAL_SCROLLBAR_ALWAYS);
>          tmpJSPFrame.getHorizontalScrollBar().setUnitIncrement(10);
>          tmpJSPFrame.getVerticalScrollBar().setUnitIncrement(10);
>          tmpJF.add(tmpJSPFrame);
> 
>          ArrayList<Object> tmpA = new ArrayList<>();
>          tmpA.add((Object) (tmpJF));
>          tmpA.add((Object) (tmpJP));
> 
>          return tmpA;
>      } // end of setupScrollableJFrameAndGetFrameAndPanel
> 
>      // actLisObj: object which implements action listener
>      public static JButton setupJButtonAndGet(String text, Object
> actLisObj, boolean setBoundsFlag, int xpos, int ypos, int width, int
> height) {
>          JButton tmpJB = new JButton(text);
>          if (setBoundsFlag == true) {
>              tmpJB.setBounds(xpos, ypos, width, height);
>          }
>          tmpJB.addActionListener((ActionListener) actLisObj);
>          return tmpJB;
>      } // end of setupJButtonAndGet
> 
>      // halign: horizontal alignment of text, valign: vertical alignment of text
>      public static JLabel setupJLabelAndGet(String text, boolean
> opaque, Color bg, int halign, int valign, boolean setBoundsFlag, int
> xpos, int ypos, int width, int height) {
>          JLabel tmpJL = new JLabel(text);
>          if (setBoundsFlag == true) {
>              tmpJL.setBounds(xpos, ypos, width, height);
>          }
>          tmpJL.setOpaque(opaque);
>          if (bg != null) {
>              tmpJL.setBackground(bg);
>          }
>          tmpJL.setHorizontalAlignment(halign);
>          tmpJL.setVerticalAlignment(valign);
>          return tmpJL;
>      } // end of setupJlabelAndGet
> 
>      public static JTextField setupJTextFieldAndGet(int xpos, int ypos,
> int width, int height) {
>          JTextField tmpJTF = new JTextField();
>          tmpJTF.setBounds(xpos, ypos, width, height);
>          return tmpJTF;
>      } // end of setupJTextFieldAndGet
> 
>      public static JFormattedTextField
> setupJFormattedTextFieldAndGet(Format fmt, Object initialVal, Object
> propertyChangeLis, String propertyToListenFor, int xpos, int ypos, int
> width, int height) {
>          JFormattedTextField tmpJFTF = new JFormattedTextField(fmt);
>          tmpJFTF.setValue(initialVal);
>          tmpJFTF.addPropertyChangeListener(propertyToListenFor,
> (PropertyChangeListener) propertyChangeLis);
>          tmpJFTF.setBounds(xpos, ypos, width, height);
>          return tmpJFTF;
>      } // end of setupJFormattedTextFieldAndGet
> 
>      // itemLisObj: object which implements item listener
>      public static JCheckBox setupJCheckBoxAndGet(String text, boolean
> state, Object itemLisObj, int xpos, int ypos, int width, int height) {
>          JCheckBox tmpJCB = new JCheckBox(text, state);
>          tmpJCB.setBounds(xpos, ypos, width, height);
>          tmpJCB.addItemListener((ItemListener) itemLisObj);
>          return tmpJCB;
>      } // end of setupJCheckBoxAndGet
> 
>      // actLisObj: object which implements action listener
>      public static JRadioButton setupJRadioButtonAndGet(String text,
> boolean state, Object actLisObj, int xpos, int ypos, int width, int
> height) {
>          JRadioButton tmpJRB = new JRadioButton(text, state);
>          tmpJRB.setBounds(xpos, ypos, width, height);
>          tmpJRB.addActionListener((ActionListener) actLisObj);
>          return tmpJRB;
>      } // end of setupJRadioButtonAndGet
> 
>      public static ButtonGroup setupButtonGroupAndGet() {
>          return new ButtonGroup();
>      } // end of setupButtonGroupAndGet
> 
>      public static JPasswordField setupJPasswordFieldAndGet(int xpos,
> int ypos, int width, int height) {
>          JPasswordField tmpJPF = new JPasswordField();
>          tmpJPF.setBounds(xpos, ypos, width, height);
>          return tmpJPF;
>      } // end of setupJPasswordFieldAndGet
> 
>      public static JTextArea setupJTextAreaAndGet(String text, int
> rows, int columns, boolean setEditableFlag, boolean setLineWrapFlag,
> boolean setWrapStyleWordFlag, boolean setBoundsFlag, int xpos, int
> ypos, int width, int height) {
>          JTextArea tmpJTA = new JTextArea(text, rows, columns);
>          tmpJTA.setEditable(setEditableFlag);
>          tmpJTA.setLineWrap(setLineWrapFlag);
>          tmpJTA.setWrapStyleWord(setWrapStyleWordFlag);
>          if (setBoundsFlag == true) {
>              tmpJTA.setBounds(xpos, ypos, width, height);
>          }
>          return tmpJTA;
>      } // end of setupJTextAreaAndGet
> 
>      public static JScrollPane setupScrollableJTextAreaAndGet(JTextArea
> jta, int xpos, int ypos, int width, int height) {
>          JScrollPane tmpJSP = new JScrollPane(jta);
>          tmpJSP.setBounds(xpos, ypos, width, height);
>          return tmpJSP;
>      } // end of setupScrollableJTextAreaAndGet
> 
>      public static JList<String> setupJListAndGet(ListModel<String> lm,
> int selectionMode, int visibleRowCount, int initialSelectedIndex,
> Object listSelLisObj, boolean setBoundsFlag, int xpos, int ypos, int
> width, int height) {
>          JList<String> tmpJList = new JList<>(lm);
>          tmpJList.setSelectionMode(selectionMode);
>          tmpJList.setVisibleRowCount(visibleRowCount);
>          if (initialSelectedIndex >= 0) {
>              tmpJList.setSelectedIndex(initialSelectedIndex);
>          }
>          tmpJList.addListSelectionListener((ListSelectionListener)
> listSelLisObj);
>          if (setBoundsFlag == true) {
>              tmpJList.setBounds(xpos, ypos, width, height);
>          }
>          return tmpJList;
>      } // end of setupJListAndGet
> 
>      public static JScrollPane setupScrollableJListAndGet(JList jlist,
> int xpos, int ypos, int width, int height) {
>          JScrollPane tmpJSP = new JScrollPane(jlist);
>          tmpJSP.setBounds(xpos, ypos, width, height);
>          return tmpJSP;
>      } // end of setupScrollableJListAndGet
> 
>      public static JComboBox<String>
> setupJComboBoxAndGet(ComboBoxModel<String> cbm, int
> initialSelectedIndex, Object actLisObj, boolean setBoundsFlag, int
> xpos, int ypos, int width, int height) {
>          JComboBox<String> tmpJComboBox = new JComboBox<>(cbm);
>          if (initialSelectedIndex >= 0) {
>              tmpJComboBox.setSelectedIndex(initialSelectedIndex);
>          }
>          tmpJComboBox.addActionListener((ActionListener) actLisObj);
>          if (setBoundsFlag == true) {
>              tmpJComboBox.setBounds(xpos, ypos, width, height);
>          }
>          return tmpJComboBox;
>      } // end of setupJComboBoxAndGet
> 
>      public static JProgressBar setupJProgressBarAndGet(int
> orientation, int min, int max, int initialVal, boolean
> borderPaintedFlag, boolean stringPaintedFlag, boolean setBoundsFlag,
> int xpos, int ypos, int width, int height) {
>          JProgressBar tmpJPB = new JProgressBar(orientation, min, max);
>          tmpJPB.setValue(initialVal);
>          tmpJPB.setBorderPainted(borderPaintedFlag);
>          tmpJPB.setStringPainted(stringPaintedFlag);
>          if (setBoundsFlag == true) {
>              tmpJPB.setBounds(xpos, ypos, width, height);
>          }
>          return tmpJPB;
>      } // end of setupJProgressBarAndGet
> 
>      public static JSlider setupJSliderAndGet(int orientation, int min,
> int max, int initialVal, int minorTickSpacing, int majorTickSpacing,
> boolean paintTicksFlag, boolean paintLabelsFlag, Object changeLisObj,
> boolean setBoundsFlag, int xpos, int ypos, int width, int height) {
>          JSlider tmpJS = new JSlider(orientation, min, max, initialVal);
>          tmpJS.setMinorTickSpacing(minorTickSpacing);
>          tmpJS.setMajorTickSpacing(majorTickSpacing);
>          tmpJS.setPaintTicks(paintTicksFlag);
>          tmpJS.setPaintLabels(paintLabelsFlag);
>          tmpJS.addChangeListener((ChangeListener) changeLisObj);
>          if (setBoundsFlag == true) {
>              tmpJS.setBounds(xpos, ypos, width, height);
>          }
>          return tmpJS;
>      } // end of setupJSliderAndGet
> 
>      public static JTree setupJTreeAndGet(DefaultMutableTreeNode
> rootNode, int selectionMode, Object treeSelLisObj, boolean
> setBoundsFlag, int xpos, int ypos, int width, int height) {
>          JTree tmpJTree = new JTree(rootNode);
>          tmpJTree.getSelectionModel().setSelectionMode(selectionMode);
>          tmpJTree.addTreeSelectionListener((TreeSelectionListener)
> treeSelLisObj);
>          if (setBoundsFlag == true) {
>              tmpJTree.setBounds(xpos, ypos, width, height);
>          }
>          return tmpJTree;
>      } // end of setupJTreeAndGet
> 
>      public static JScrollPane setupScrollableJTreeAndGet(JTree jtree,
> int xpos, int ypos, int width, int height) {
>          JScrollPane tmpJSP = new JScrollPane(jtree);
>          tmpJSP.setBounds(xpos, ypos, width, height);
>          return tmpJSP;
>      } // end of setupScrollableJTreeAndGet
> 
>      public static JSpinner setupJSpinnerAndGet(SpinnerModel sm,
> boolean editableFlag, Object spinnerChangeLisObj, int xpos, int ypos,
> int width, int height) {
>          JSpinner tmpJSPN = new JSpinner(sm);
>          tmpJSPN.addChangeListener((ChangeListener) spinnerChangeLisObj);
>          if (editableFlag == false) {
>              JComponent editor = tmpJSPN.getEditor();
>              if (editor instanceof JSpinner.DefaultEditor) {
>                  ((JSpinner.DefaultEditor)
> editor).getTextField().setEditable(editableFlag);
>              } else {
>                  System.out.println("Error: Could not set editableFlag
> for JSpinner.");
>              }
>          }
>          tmpJSPN.setBounds(xpos, ypos, width, height);
>          return tmpJSPN;
>      } // end of setupJSpinnerAndGet
> 
>      public static JColorChooser setupJColorChooserAndGet(Color
> initialColor, boolean borderTitleFlag, String borderTitle, Object
> colorChooserChangeLisObj, int xpos, int ypos, int width, int height) {
>          JColorChooser tmpJCC = new JColorChooser(initialColor);
>          tmpJCC.getSelectionModel().addChangeListener((ChangeListener)
> colorChooserChangeLisObj);
>          if (borderTitleFlag == true) {
>              tmpJCC.setBorder(BorderFactory.createTitledBorder(borderTitle));
>          }
>          tmpJCC.setBounds(xpos, ypos, width, height);
>          return tmpJCC;
>      } // end of setupJColorChooserAndGet
> 
>      public static JDialog setupJDialogAndGet(Frame owner, String
> title, boolean modal, int width, int height) {
>          JDialog tmpJD = new JDialog(owner, title, modal);
>          tmpJD.setSize(width, height);
>          tmpJD.setLocationRelativeTo(null);
>          tmpJD.setLayout(null);
>          tmpJD.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);
>          return tmpJD;
>      } // end of setupJDialogAndGet
> 
>      public static ArrayList<Object>
> setupScrollableJDialogAndGetDialogAndPanel(Frame owner, String title,
> boolean modal, int dialogWidth, int dialogHeight, int panelWidth, int
> panelHeight) {
>          JDialog tmpJD = new JDialog(owner, title, modal);
>          tmpJD.setSize(dialogWidth, dialogHeight);
>          tmpJD.setLocationRelativeTo(null);
>          tmpJD.setLayout(null);
>          tmpJD.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);
> 
>          JPanel tmpJP = new JPanel();
>          tmpJP.setPreferredSize(new Dimension(panelWidth, panelHeight));
>          tmpJP.setLayout(null);
> 
>          ScrollPane sp = new ScrollPane(ScrollPane.SCROLLBARS_ALWAYS);
>          sp.getHAdjustable().setUnitIncrement(10);
>          sp.getVAdjustable().setUnitIncrement(10);
>          sp.add(tmpJP);
>          tmpJD.getRootPane().setContentPane(sp);
> 
>          ArrayList<Object> tmpA = new ArrayList<>();
>          tmpA.add((Object) (tmpJD));
>          tmpA.add((Object) (tmpJP));
> 
>          return tmpA;
>      } // end of setupScrollableJDialogAndGetDialogAndPanel
> 
>      public static JToggleButton setupJToggleButtonAndGet(String text,
> Object itemLisObj, boolean opaque, Color bgcolor, boolean
> setBoundsFlag, int xpos, int ypos, int width, int height) {
>          JToggleButton tmpJTB = new JToggleButton(text);
>          if (setBoundsFlag == true) {
>              tmpJTB.setBounds(xpos, ypos, width, height);
>          }
>          tmpJTB.addItemListener((ItemListener) itemLisObj);
>          tmpJTB.setOpaque(opaque);
>          tmpJTB.setBackground(bgcolor);
>          return tmpJTB;
>      } // end of setupJToggleButtonAndGet
> 
>      public static JSeparator setupJSeparatorAndGet(int orientation,
> Color bgcolor, boolean setBoundsFlag, int xpos, int ypos, int width,
> int height) {
>          JSeparator tmpJS = new JSeparator(orientation);
>          tmpJS.setBackground(bgcolor);
>          if (setBoundsFlag == true) {
>              tmpJS.setBounds(xpos, ypos, width, height);
>          }
>          return tmpJS;
>      } // end of setupJSeparatorAndGet
> 
>      public static JMenuBar setupJMenuBarAndGet(Color fgcolor, Color bgcolor) {
>          JMenuBar tmpJMB = new JMenuBar();
>          tmpJMB.setOpaque(true);
>          tmpJMB.setForeground(fgcolor);
>          tmpJMB.setBackground(bgcolor);
>          return tmpJMB;
>      } // end of setupJMenuBarAndGet
> 
>      public static JMenu setupJMenuAndGet(String text, Color fgcolor,
> Color bgcolor) {
>          JMenu tmpJM = new JMenu(text);
>          tmpJM.setOpaque(true);
>          tmpJM.setForeground(fgcolor);
>          tmpJM.setBackground(bgcolor);
>          return tmpJM;
>      } // end of setupJMenuAndGet
> 
>      public static JMenuItem setupJMenuItemAndGet(String text, Object
> actLisObj, KeyStroke k, Color fgcolor, Color bgcolor) {
>          JMenuItem tmpJMI = new JMenuItem(text);
>          tmpJMI.setOpaque(true);
>          tmpJMI.setForeground(fgcolor);
>          tmpJMI.setBackground(bgcolor);
>          tmpJMI.setAccelerator(k);
>          if (actLisObj != null) {
>              tmpJMI.addActionListener((ActionListener) actLisObj);
>          }
>          return tmpJMI;
>      } // end of setupJMenuItemAndGet
> 
> } // end of SwingLibrary
> 
> -------------------------------------------------------------------------------------------

From shade at openjdk.org  Tue Oct 11 09:31:30 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 09:31:30 GMT
Subject: RFR: 8295104: Break VarHandle tests into separate @test to reduce
 test execution time
In-Reply-To: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
References: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
Message-ID: <URX0WsnTDF8D2mU68cXHiA8vSeA6eBAHaxbWMu23l5s=.b97352fd-864b-4e18-8b22-dcc5ceb7f945@github.com>

On Mon, 10 Oct 2022 23:16:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This separates `@run` into its own `@test` that they can be run concurrently.

I did consider when working on `VarHandle` tests recently, but figured this split penalizes the total CPU time quite significantly. Given that these tests run in `tier1`, when there is significant external parallelism already, it seems to waste time for little gain.

Please run `java/lang/invoke/VarHandles` and `tier1` with `time` to ballpark the time changes on your test systems.

-------------

PR: https://git.openjdk.org/jdk/pull/10641

From kevin.rushforth at oracle.com  Tue Oct 11 11:17:45 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 11 Oct 2022 04:17:45 -0700
Subject: Examples Of Many Java Swing Components In One Program.
In-Reply-To: <a8357c5b-9616-7f19-83b0-12c5d56ff774@oracle.com>
References: <CAFf+5zhufpcpjxek5o9MMw51BNhYGYmfnFy_f92dg5szX7O1mA@mail.gmail.com>
 <a8357c5b-9616-7f19-83b0-12c5d56ff774@oracle.com>
Message-ID: <702e6103-a19f-2d60-9ae8-e207e917d787@oracle.com>

It's still there.

https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc/SwingSet2

Btw, client-libs-dev at openjdk.org (included) is the relevant mailing list 
for this message, not core-libs-dev.

-- Kevin


On 10/11/2022 1:54 AM, David Holmes wrote:
> On 11/10/2022 4:38 pm, Amit wrote:
>> Code for many Java Swing Components In One Program in case someone 
>> needs it.
>
> We used to have a Swing demo in the JDK ... don't know what happened 
> to it.
>
> David
>
>> Description: The program
>> Examples_Of_Many_Swing_Components_In_One_Program contains examples of
>> many swing components - that is, how to initialize them and use them.
>> You can use code from this program in your code. Where applicable,
>> appropriate listeners are also implemented.

snip



From coffeys at openjdk.org  Tue Oct 11 11:30:28 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 11 Oct 2022 11:30:28 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
Message-ID: <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>

On Mon, 10 Oct 2022 20:54:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> modified code to have Security class hold the initial properties and provided an accessor method
>
> What about creating a new `JavaSecurityPropertiesAccess` class and moving the accessor method there? It seems it would be cleaner to remove the dependency on PD in the long run.

@seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 

In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mchhipa at openjdk.org  Tue Oct 11 11:31:53 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 11 Oct 2022 11:31:53 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling [v3]
In-Reply-To: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
Message-ID: <K-i0sSdLreFbevKVPfQA4fqiXNWsHfIdiakwhfPw5ak=.8c02435e-09aa-4cd8-b0b3-87a857c7025e@github.com>

> Added test cases for xpath Axis:
> 1. descendant
> 2. descendant-or-self
> 3. following
> 4. following-sibling

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Added predicate tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10557/files
  - new: https://git.openjdk.org/jdk/pull/10557/files/5489dcf1..7dd36ecb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10557&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10557&range=01-02

  Stats: 25 lines in 2 files changed: 20 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10557.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10557/head:pull/10557

PR: https://git.openjdk.org/jdk/pull/10557

From alanb at openjdk.org  Tue Oct 11 11:35:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Oct 2022 11:35:25 GMT
Subject: RFR: 8295104: Break VarHandle tests into separate @test to reduce
 test execution time
In-Reply-To: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
References: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
Message-ID: <1PdooTQUN4wIvLeoLYKm3A9ti04VXFotSrwK3urIPyk=.b01b23cf-33e5-4777-8649-e12d3b920fd6@github.com>

On Mon, 10 Oct 2022 23:16:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This separates `@run` into its own `@test` that they can be run concurrently.

I wouldn't expect it to change the execution time of tier1_part1 but it may help with test selection, maybe combined with putting understandable ids or jtreg keywords. Maybe there is a question here on whether individual tests should exercise -Xint and the compiler modes themselves or whether larger groups of tests should be run with these options in higher tiers.

-------------

PR: https://git.openjdk.org/jdk/pull/10641

From shade at openjdk.org  Tue Oct 11 11:38:42 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 11:38:42 GMT
Subject: RFR: 8295104: Break VarHandle tests into separate @test to reduce
 test execution time
In-Reply-To: <1PdooTQUN4wIvLeoLYKm3A9ti04VXFotSrwK3urIPyk=.b01b23cf-33e5-4777-8649-e12d3b920fd6@github.com>
References: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
 <1PdooTQUN4wIvLeoLYKm3A9ti04VXFotSrwK3urIPyk=.b01b23cf-33e5-4777-8649-e12d3b920fd6@github.com>
Message-ID: <ZNYCSuCX82KexkeFM64yFeAlO8i7Itfo2KHjHCDGLzg=.a583fcdd-bb25-4f75-a0c9-efc4b39f42ef@github.com>

On Tue, 11 Oct 2022 11:31:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wouldn't expect it to change the execution time of tier1_part1

I have *seen* the change in total CPU time when I tried to do the same thing this PR does. This is why I bailed on doing the same thing PR proposes. Cutting out the tests into parallel `@test` blocks is not a straightforward thing to do: you need to have significantly large tests to get a parallelism benefit that covers the additional overhead of doing more JVMs.

This is why my PRs that do this kind of transformation show `time`-s before/after the change, where one can see that `wall` time gets reduced (parallelism benefit), while `usr+sys` times stay more or less the same (overhead penalties). I insist doing this for any kind of test parallelism changes.

-------------

PR: https://git.openjdk.org/jdk/pull/10641

From mullan at openjdk.org  Tue Oct 11 12:41:26 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Oct 2022 12:41:26 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
 <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
Message-ID: <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>

On Tue, 11 Oct 2022 11:28:10 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> What about creating a new `JavaSecurityPropertiesAccess` class and moving the accessor method there? It seems it would be cleaner to remove the dependency on PD in the long run.
>
> @seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 
> 
> In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?

Maybe I am missing something. If this JFR event is enabled, and the properties have not yet been accessed, then it seems ok for JFR to load the `Security` class when JFR is started since the user is interested in this event.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From duke at openjdk.org  Tue Oct 11 13:11:56 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 11 Oct 2022 13:11:56 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <nMRTqoWz-lQVlQPD-io-OK_VC2f00tvZ57bZaEN6xts=.9649b36f-6020-4dfe-99cd-7d4c5811e394@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <nMRTqoWz-lQVlQPD-io-OK_VC2f00tvZ57bZaEN6xts=.9649b36f-6020-4dfe-99cd-7d4c5811e394@github.com>
Message-ID: <wk9WRfBop-vWxqvNmS8hxukXT0gEC5LqnBagBuJHHM8=.c5284ca5-0651-4c7b-9944-577f4466d709@github.com>

On Mon, 10 Oct 2022 20:41:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Isn't a test needed here which fails without but passes with the proposed change?

I do not see such a *need*, as this is solely a performance improvement, not a fixed bug or added functionality. If the majority of this team wants to have such a test, then please clearly instruct me to write one. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Tue Oct 11 13:12:05 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 11 Oct 2022 13:12:05 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos [v2]
In-Reply-To: <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>
 <91DREBRbEGaHsnU6yXl89oMf3SRJBLnsUh30Vb-n_x4=.800d2f58-53f6-4a39-b120-3cb8e58cbb94@github.com>
 <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>
Message-ID: <GO0KbG63dunqa6qBwcQWPxLVlwFoFzJKevWNmE_9RYc=.8bff05aa-2f04-4781-8c97-1694bfc9571c@github.com>

On Tue, 4 Oct 2022 15:53:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change *here*, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?
>
>> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change _here_, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?
> 
> This looks to be the only that would corrupt the current position (pos). 
> 
> @bplb plans to look at this too, another set of eyes would be good on this point.

This PR originates from @AlanBateman who asked me to change my use of `== 1` to `< 0`. Per his opinion, using `< 0` is allegedly wrong, as it violates the spec of `markpos`. As it either it is wrong *everywhere* or *nowhere*, he agreed that this should be fixed. So guys, please discuss with each other what way you finally want it to be like. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From coffeys at openjdk.org  Tue Oct 11 13:13:45 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 11 Oct 2022 13:13:45 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
 <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
 <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
Message-ID: <gvBuel-mv6ErQQAZ7Cy16yj4aY_gnnKYn9heMJDPfoY=.707c8b59-4f66-4828-8ee3-cbb0e215412f@github.com>

On Tue, 11 Oct 2022 12:39:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 
>> 
>> In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?
>
> Maybe I am missing something. If this JFR event is enabled, and the properties have not yet been accessed, then it seems ok for JFR to load the `Security` class when JFR is started since the user is interested in this event.

My own thoughts here would be that the JFR event system should try and avoid side effects in such areas. If the Security class hasn't been loaded at time of recording, then I'd argue that the number InitialSecurityProperty events should be zero. (which is not possible at the moment since JFR does trigger Security class loading itself anyway)

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From weijun at openjdk.org  Tue Oct 11 15:19:21 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Oct 2022 15:19:21 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
Message-ID: <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>

On Mon, 10 Oct 2022 23:23:00 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

I have a question, why must this test be manual? Can't we compare the localized texts?

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From rriggs at openjdk.org  Tue Oct 11 15:41:13 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Oct 2022 15:41:13 GMT
Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime
 Libraries or jvm.dll cannot be loaded [v14]
In-Reply-To: <v3cLGh8mVuZhCoB7Kstt6Oc-edhrJO-DWiPuqIUESfE=.fa1c0925-fcca-4c81-bc42-f5f606ba62fe@github.com>
References: <IdxxRKvKstLJYI8b4e6jS8pyiUFyqvcrMqYCZaYE0-4=.d50784a0-724f-4bcc-b878-47a414645845@github.com>
 <mtKKcCUpQeelxOO2Xpgm4uxXIEQpbSgYrXduYcEsOdw=.91d14691-aac9-4691-baee-cfde0adaae86@github.com>
 <mumKK5K4ngw0VgVWBpxYRpAn9hgDI6QwsSfY_H5Ez4s=.43f8f8fe-57d3-4622-b8e8-1a6152eb7037@github.com>
 <viMRjrZ8ZmZZ0jqFstr0CixAH4_vBELpZLPC4ocIDQ8=.3a8310cb-6028-43e6-9321-b7365695d9b9@github.com>
 <v3cLGh8mVuZhCoB7Kstt6Oc-edhrJO-DWiPuqIUESfE=.fa1c0925-fcca-4c81-bc42-f5f606ba62fe@github.com>
Message-ID: <yFNtZEPbGO_O4a69k0ygwUYWr42PgjpQLqaQWwd3QUU=.231f0e9e-34e5-4d93-a4a5-2179db502f9b@github.com>

On Tue, 11 Oct 2022 01:38:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I left that in there since it would possibly be a useful utility to have for other JLI code that might need to work with Windows errors in the future
>
> In that case shouldn't the `JLI_xxx` naming scheme be retained?

$0.02, leave it for local use until its needed elsewhere, it is easier to maintain if the scope of use is unambiguous.

-------------

PR: https://git.openjdk.org/jdk/pull/9749

From bpb at openjdk.org  Tue Oct 11 15:43:50 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Oct 2022 15:43:50 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos [v2]
In-Reply-To: <2yCtIvt-Xj22wNiupyJmcMn33dJSax8eleycjgMqoNg=.94d67626-23d3-4b07-b9c2-7148f3df7227@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <2yCtIvt-Xj22wNiupyJmcMn33dJSax8eleycjgMqoNg=.94d67626-23d3-4b07-b9c2-7148f3df7227@github.com>
Message-ID: <x6aWs1da9kKWMnPXU-rcHIyRY_r_wGU1vJZ_Hcqbxz4=.25b618c5-15bc-4c7a-a3d3-2c0594f05413@github.com>

On Sun, 9 Oct 2022 14:08:40 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Fixes JDK-8294702
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified to < 0 as proposed by Alan Batement

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From bpb at openjdk.org  Tue Oct 11 15:43:52 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Oct 2022 15:43:52 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos [v2]
In-Reply-To: <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <PXfS9JwnJbhZG-DumZxpk7tmc6CmiLbtoB-gn6LbKhM=.49562360-05d4-455e-bccd-3d2996d00cce@github.com>
 <91DREBRbEGaHsnU6yXl89oMf3SRJBLnsUh30Vb-n_x4=.800d2f58-53f6-4a39-b120-3cb8e58cbb94@github.com>
 <_GEVCPOFb6ztGEoJ6PQfXOmBQXma8JIpz-rgsOc9g5I=.39b3b52c-4da7-4503-969f-80f900e164d1@github.com>
Message-ID: <KqfsVVxOPlZTbO5KdLhe0mqnx0_oDTkOXA_d82YVKHU=.e5964752-a264-4481-8af1-1c5439f9f514@github.com>

On Tue, 4 Oct 2022 15:53:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change *here*, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?
>
>> This is true, but if a broken subclass sets markpos to less than -1 then lots of code lines will work incorrectly -- including `transferTo` which was the starting point of your change proposal. So do you really only want undo the change _here_, or is it better drop this PR and even use `< 0` in `transferTo`, as I originally proposed?
> 
> This looks to be the only that would corrupt the current position (pos). 
> 
> @bplb plans to look at this too, another set of eyes would be good on this point.

> This PR originates from @AlanBateman who asked me to change my use of `== 1` to `< 0`. Per his opinion, using `< 0` is allegedly wrong, as it violates the spec of `markpos`. As it either it is wrong _everywhere_ or _nowhere_, he agreed that this should be fixed. So guys, please discuss with each other what way you finally want it to be like. Thanks.

I am aware of the context and agree that `-1 <= markpos <= pos` should be `true`, but am simply pointing out that it does not really fix an observable problem and no change is without risk.

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From duke at openjdk.org  Tue Oct 11 15:56:18 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 11 Oct 2022 15:56:18 GMT
Subject: RFR: JDK-8294702 - BufferedInputStream uses undefined value range
 for markpos [v2]
In-Reply-To: <x6aWs1da9kKWMnPXU-rcHIyRY_r_wGU1vJZ_Hcqbxz4=.25b618c5-15bc-4c7a-a3d3-2c0594f05413@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
 <2yCtIvt-Xj22wNiupyJmcMn33dJSax8eleycjgMqoNg=.94d67626-23d3-4b07-b9c2-7148f3df7227@github.com>
 <x6aWs1da9kKWMnPXU-rcHIyRY_r_wGU1vJZ_Hcqbxz4=.25b618c5-15bc-4c7a-a3d3-2c0594f05413@github.com>
Message-ID: <uJ3pQAjMhR3wPtUxt1IcrYflJCY8o1RjmmFY4fP1G5g=.763bf7f3-ad1e-4e73-9dfd-927cd96d30db@github.com>

On Tue, 11 Oct 2022 15:40:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified to < 0 as proposed by Alan Batement
>
> Marked as reviewed by bpb (Reviewer).

@bplb Kindly requesting to repeat `/sponsor`. :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From rgiulietti at openjdk.org  Tue Oct 11 15:57:19 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 11 Oct 2022 15:57:19 GMT
Subject: RFR: 8295155: Incorrect javadoc of java.base module
Message-ID: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>

Simple doc correction.

-------------

Commit messages:
 - 8295155: Incorrect javadoc of java.base module

Changes: https://git.openjdk.org/jdk/pull/10658/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295155
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10658.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10658/head:pull/10658

PR: https://git.openjdk.org/jdk/pull/10658

From duke at openjdk.org  Tue Oct 11 16:12:20 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 11 Oct 2022 16:12:20 GMT
Subject: Integrated: JDK-8294702 - BufferedInputStream uses undefined value
 range for markpos
In-Reply-To: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
References: <wCKFeZRvXs70gMl4zsFUYybZQtaVWsPE__I43rbhl1w=.56dc8e1a-d687-4980-b723-fb598ff9bf4b@github.com>
Message-ID: <cJe3vspOqSK_RPlXnqdKgwhn34QGkc6d9SDylRvGs2c=.b7fa3bbf-5dba-44b5-812f-325fb12a595a@github.com>

On Mon, 3 Oct 2022 07:29:02 GMT, Markus KARG <duke at openjdk.org> wrote:

> Fixes JDK-8294702

This pull request has now been integrated.

Changeset: 619cd825
Author:    Markus Karg <markus at headcrashing.eu>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/619cd825b53465c4d533d5cab70070c08964fa91
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8294702: BufferedInputStream uses undefined value range for markpos

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/10528

From alanb at openjdk.org  Tue Oct 11 16:25:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Oct 2022 16:25:15 GMT
Subject: RFR: 8295155: Incorrect javadoc of java.base module
In-Reply-To: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
References: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
Message-ID: <UNnysUkIhvgndxopq_C3nJxQ3gyFgzmqif5COp9dElk=.4c8a85e6-6b47-4b9e-ad65-28e25fb9e893@github.com>

On Tue, 11 Oct 2022 15:48:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Simple doc correction.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10658

From rriggs at openjdk.org  Tue Oct 11 16:25:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Oct 2022 16:25:15 GMT
Subject: RFR: 8295155: Incorrect javadoc of java.base module
In-Reply-To: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
References: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
Message-ID: <wyO7njtI7-31f0uqcc6EMIqTSEyTgWbx_wgneSxgPJc=.e49dfd8d-5096-4c72-9a34-edc9fa7511aa@github.com>

On Tue, 11 Oct 2022 15:48:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Simple doc correction.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10658

From bpb at openjdk.org  Tue Oct 11 16:28:20 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Oct 2022 16:28:20 GMT
Subject: RFR: 8295155: Incorrect javadoc of java.base module
In-Reply-To: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
References: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
Message-ID: <U0XutYo6Ik5uwuwsukyk8Tsq288VcQRHMJdtEBCRD-I=.b9cb4540-ef22-482b-bfb5-c54e3dccf7b0@github.com>

On Tue, 11 Oct 2022 15:48:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Simple doc correction.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10658

From iris at openjdk.org  Tue Oct 11 16:31:34 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 11 Oct 2022 16:31:34 GMT
Subject: RFR: 8295155: Incorrect javadoc of java.base module
In-Reply-To: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
References: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
Message-ID: <JfSJRedfKLKhE-0yWnc19QzrPvqKkqdEz6ur0jqa6OM=.391b4c16-a48a-4432-9fb2-3d7e5ca38c2f@github.com>

On Tue, 11 Oct 2022 15:48:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Simple doc correction.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10658

From jvernee at openjdk.org  Tue Oct 11 16:58:46 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 11 Oct 2022 16:58:46 GMT
Subject: RFR: 8295155: Incorrect javadoc of java.base module
In-Reply-To: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
References: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
Message-ID: <kE7ISO1AKJrCmKKgZuJcHwbi1JvNvRsrJYOtltRS3xE=.ac592b30-075f-408e-8792-8ef3dd51656e@github.com>

On Tue, 11 Oct 2022 15:48:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Simple doc correction.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10658

From rgiulietti at openjdk.org  Tue Oct 11 17:01:38 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 11 Oct 2022 17:01:38 GMT
Subject: Integrated: 8295155: Incorrect javadoc of java.base module
In-Reply-To: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
References: <gykMfdxgGT20y4LUiWYHaV-bsPHklPUVQtMQW2GdEGg=.6e3df73b-e9dd-491c-a6b9-5e8ce563d395@github.com>
Message-ID: <whL5CZZLVHnY6kadoc5Pf5VJWP4D2cELwpP-1VSzbiM=.c7d65c37-f5b8-4b17-b2ca-6f0bb9422a64@github.com>

On Tue, 11 Oct 2022 15:48:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Simple doc correction.

This pull request has now been integrated.

Changeset: 2586b1a3
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2586b1a3c1e1c653e2e7e3398a1955882161193e
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8295155: Incorrect javadoc of java.base module

Reviewed-by: alanb, rriggs, bpb, iris, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/10658

From svkamath at openjdk.org  Tue Oct 11 17:03:24 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 11 Oct 2022 17:03:24 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <66be8SJdxPOqmqsQ1YIwS4zM4GwPerypGIf8IbfxhRs=.1d03c94a-f3e5-40ae-999e-bdd5f328170d@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
 <66be8SJdxPOqmqsQ1YIwS4zM4GwPerypGIf8IbfxhRs=.1d03c94a-f3e5-40ae-999e-bdd5f328170d@github.com>
Message-ID: <cxn5tjWHWpBzE7cOSGkqvriYsku5W6097w4bua8UtNw=.fb7e49b5-2da6-4bad-a671-6d466c1da7e3@github.com>

On Mon, 10 Oct 2022 21:05:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated instruct to use kmovw
>
> I started new testing.

@vnkozlov Thank you for reviewing the patch.

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From naoto at openjdk.org  Tue Oct 11 17:08:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Oct 2022 17:08:41 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
 <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
Message-ID: <TXZt3gfVDzpleZaEp_Qt_cjO2YVByYdiBgFbNpnpVOY=.6ea536d2-245d-4374-ab7d-ab256eae5ae1@github.com>

On Tue, 11 Oct 2022 15:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I have a question, why must this test be manual? Can't we compare the localized texts?

Thought about that, but it could be a nuisance if we compared word-to-word translations, considering the situation if an engineer made some changes in the English resource bundle, but l10n may not come at the same time which is guaranteed to fail.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From bhuang at openjdk.org  Tue Oct 11 17:08:41 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 11 Oct 2022 17:08:41 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <TXZt3gfVDzpleZaEp_Qt_cjO2YVByYdiBgFbNpnpVOY=.6ea536d2-245d-4374-ab7d-ab256eae5ae1@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
 <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
 <TXZt3gfVDzpleZaEp_Qt_cjO2YVByYdiBgFbNpnpVOY=.6ea536d2-245d-4374-ab7d-ab256eae5ae1@github.com>
Message-ID: <Hznob_JJlKWR3g7hg3cCf8rsWmWMkxjXMW1BgHg-ruo=.fb14c4fc-609f-4b43-9124-3b8db19b2518@github.com>

On Tue, 11 Oct 2022 17:03:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I have a question, why must this test be manual? Can't we compare the localized texts?

@wangweij Good question. We can definitely compare the localized texts at least some keywords. The fact that automation is one of the goals of this task. In terms of localization, perhaps in our tests we can reuse the resource bundles implemented in these tools to turn english texts into localized texts.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From svkamath at openjdk.org  Tue Oct 11 17:08:51 2022
From: svkamath at openjdk.org (Smita Kamath)
Date: Tue, 11 Oct 2022 17:08:51 GMT
Subject: Integrated: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
Message-ID: <e1zBoM5c3qEHtno6hsrxnruGnq4Gs-s1FxmLlmtcvvY=.c5769bf4-4a5a-4a70-a5ff-ff7c37c6c430@github.com>

On Fri, 5 Aug 2022 16:36:23 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8289552: Make intrinsic conversions between bit representations of half precision values and floats

This pull request has now been integrated.

Changeset: 07946aa4
Author:    Smita Kamath <svkamath at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07946aa49c97c93bd11675a9b0b90d07c83f2a94
Stats:     350 lines in 19 files changed: 339 ins; 5 del; 6 mod

8289552: Make intrinsic conversions between bit representations of half precision values and floats

Reviewed-by: kvn, sviswanathan, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/9781

From prappo at openjdk.org  Tue Oct 11 17:20:03 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Oct 2022 17:20:03 GMT
Subject: RFR: 8295168: Remove superfluous period in @throws tag description
Message-ID: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>

Please review this utmost trivial fix for an issue discovered while working on something else in jdk.javadoc. As far as I can see, this is the only case of `{@inheritDoc}` not being the sole content of a `@throws` description in JDK.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10664/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295168
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10664.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10664/head:pull/10664

PR: https://git.openjdk.org/jdk/pull/10664

From mchung at openjdk.org  Tue Oct 11 17:28:15 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Oct 2022 17:28:15 GMT
Subject: RFR: 8295104: Break VarHandle tests into separate @test to reduce
 test execution time
In-Reply-To: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
References: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
Message-ID: <WctPrDM-H6ECpafE0uvF2Txd1hi2acYlY5H05s8N8HU=.1ec9594b-660f-4ce4-b55f-bbe647dd39f6@github.com>

On Mon, 10 Oct 2022 23:16:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This separates `@run` into its own `@test` that they can be run concurrently.

Ok, thanks for the input.  Instead of breaking into separate `@test` blocks, we should look at how these tests can be broken up and which cases really need to exercise -Xint and compiler modes.  I think the test cases expecting UOE, OOBE, etc should not need to run with -Xint and compiler modes.

-------------

PR: https://git.openjdk.org/jdk/pull/10641

From naoto at openjdk.org  Tue Oct 11 17:30:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Oct 2022 17:30:22 GMT
Subject: RFR: 8295168: Remove superfluous period in @throws tag description
In-Reply-To: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
References: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
Message-ID: <wmBq3dmTxKJ__65m_viXK7PUXYajLuqCirZrEx1w7EQ=.c6067da5-7441-4f21-909f-5352822df6dc@github.com>

On Tue, 11 Oct 2022 17:11:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this utmost trivial fix for an issue discovered while working on something else in jdk.javadoc. As far as I can see, this is the only case of `{@inheritDoc}` not being the sole content of a `@throws` description in JDK.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10664

From bpb at openjdk.org  Tue Oct 11 17:30:22 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Oct 2022 17:30:22 GMT
Subject: RFR: 8295168: Remove superfluous period in @throws tag description
In-Reply-To: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
References: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
Message-ID: <-dtCO1fy-Ye2MgCpx_LEMwD7U8I3QH7x2xLKyQFgM6w=.07604507-ea3a-4b74-943f-e61556031aac@github.com>

On Tue, 11 Oct 2022 17:11:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this utmost trivial fix for an issue discovered while working on something else in jdk.javadoc. As far as I can see, this is the only case of `{@inheritDoc}` not being the sole content of a `@throws` description in JDK.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10664

From lancea at openjdk.org  Tue Oct 11 17:52:17 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 11 Oct 2022 17:52:17 GMT
Subject: RFR: 8295168: Remove superfluous period in @throws tag description
In-Reply-To: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
References: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
Message-ID: <okTjeP25ZpMmamfdVXwI-_uALgOeWZI7EG2wsmZaODw=.eb967c82-66b0-4011-8022-e1d531153db1@github.com>

On Tue, 11 Oct 2022 17:11:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this utmost trivial fix for an issue discovered while working on something else in jdk.javadoc. As far as I can see, this is the only case of `{@inheritDoc}` not being the sole content of a `@throws` description in JDK.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10664

From bhuang at openjdk.org  Tue Oct 11 18:09:36 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 11 Oct 2022 18:09:36 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling [v3]
In-Reply-To: <K-i0sSdLreFbevKVPfQA4fqiXNWsHfIdiakwhfPw5ak=.8c02435e-09aa-4cd8-b0b3-87a857c7025e@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
 <K-i0sSdLreFbevKVPfQA4fqiXNWsHfIdiakwhfPw5ak=.8c02435e-09aa-4cd8-b0b3-87a857c7025e@github.com>
Message-ID: <5z-T0OO7kXPv2YxGf0qYJ0sKPl6QvZLh-4urhWv_KZg=.a88916b1-c07d-402a-b1c3-8febd6e38bef@github.com>

On Tue, 11 Oct 2022 11:31:53 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added test cases for xpath Axis:
>> 1. descendant
>> 2. descendant-or-self
>> 3. following
>> 4. following-sibling
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added predicate tests.

Marked as reviewed by bhuang (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From iris at openjdk.org  Tue Oct 11 18:19:21 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 11 Oct 2022 18:19:21 GMT
Subject: RFR: 8295168: Remove superfluous period in @throws tag description
In-Reply-To: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
References: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
Message-ID: <-bvc4eLkyvJLdSSNPLrNCrgdMJ8D9j3byLD9ACLSvzM=.a57745d6-dd45-499c-adc0-d657e5e4018d@github.com>

On Tue, 11 Oct 2022 17:11:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this utmost trivial fix for an issue discovered while working on something else in jdk.javadoc. As far as I can see, this is the only case of `{@inheritDoc}` not being the sole content of a `@throws` description in JDK.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10664

From joehw at openjdk.org  Tue Oct 11 19:40:33 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 11 Oct 2022 19:40:33 GMT
Subject: RFR: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling [v3]
In-Reply-To: <K-i0sSdLreFbevKVPfQA4fqiXNWsHfIdiakwhfPw5ak=.8c02435e-09aa-4cd8-b0b3-87a857c7025e@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
 <K-i0sSdLreFbevKVPfQA4fqiXNWsHfIdiakwhfPw5ak=.8c02435e-09aa-4cd8-b0b3-87a857c7025e@github.com>
Message-ID: <EAfznBnKLMzgq239Gq6A0j1ikvrEO8DN7V6s1fE80aM=.0a78fb25-1c46-4d7d-bc27-65d925d6d71c@github.com>

On Tue, 11 Oct 2022 11:31:53 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Added test cases for xpath Axis:
>> 1. descendant
>> 2. descendant-or-self
>> 3. following
>> 4. following-sibling
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added predicate tests.

Thanks for the update.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10557

From prappo at openjdk.org  Tue Oct 11 19:49:10 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Oct 2022 19:49:10 GMT
Subject: Integrated: 8295168: Remove superfluous period in @throws tag
 description
In-Reply-To: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
References: <myy4XcYc87kwIk0s0MNcksycghE4BNlFKAGQy5zPL6g=.e1c81fa4-1bdc-408e-b722-6379ff544a74@github.com>
Message-ID: <CRsQfZSGk1VZyot-KbDcdjpMGrkxIUTNQSCDyMXEWRw=.61a0aafe-7e12-4664-85e5-1e8d52b5ab71@github.com>

On Tue, 11 Oct 2022 17:11:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this utmost trivial fix for an issue discovered while working on something else in jdk.javadoc. As far as I can see, this is the only case of `{@inheritDoc}` not being the sole content of a `@throws` description in JDK.

This pull request has now been integrated.

Changeset: 3a980b97
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a980b972f72b5bbfd7bb63b433ae562890dbcf2
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8295168: Remove superfluous period in @throws tag description

Reviewed-by: bpb, naoto, lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/10664

From rriggs at openjdk.org  Tue Oct 11 20:02:06 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Oct 2022 20:02:06 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <DR-uyBBpPw3Axz2hKRE5BW5atXyhNR7fL738Pwig5Zs=.4580adaf-6bc8-4fca-bba9-d570d7809a59@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10578

From mchung at openjdk.org  Tue Oct 11 20:19:09 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 11 Oct 2022 20:19:09 GMT
Subject: Withdrawn: 8295104: Break VarHandle tests into separate @test to
 reduce test execution time
In-Reply-To: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
References: <EPZi52xrpozokJ8IH31TUqxv-CVj3I1soGjVmq4xyu0=.99038917-1f65-4273-8bab-bdd6431e0852@github.com>
Message-ID: <bVcF6qxCElRgIa5U9o1Tx4jG3bdTGeexFKpyrjk6yuA=.4d08e57e-d480-459e-8b85-ecb597d059f3@github.com>

On Mon, 10 Oct 2022 23:16:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This separates `@run` into its own `@test` that they can be run concurrently.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10641

From bpb at openjdk.org  Tue Oct 11 20:50:15 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Oct 2022 20:50:15 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160" [v3]
In-Reply-To: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
Message-ID: <iDOpaRU7KU29Acy1wikMUPhbLmJMheRY_ShRLep2GMc=.027ffeab-ae14-4a3f-9a99-8dbc0ded68f1@github.com>

> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - 8291911: Minor formatting cleanup in test
 - Merge
 - 8291911: work in progress
 - 8291911: Account for quotas on Windows.
 - 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9856/files
  - new: https://git.openjdk.org/jdk/pull/9856/files/991dc9a6..81296309

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9856&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9856&range=01-02

  Stats: 183635 lines in 2941 files changed: 90047 ins; 74842 del; 18746 mod
  Patch: https://git.openjdk.org/jdk/pull/9856.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9856/head:pull/9856

PR: https://git.openjdk.org/jdk/pull/9856

From bpb at openjdk.org  Tue Oct 11 21:04:03 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Oct 2022 21:04:03 GMT
Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with
 "53687091200 != 161051996160" [v3]
In-Reply-To: <iDOpaRU7KU29Acy1wikMUPhbLmJMheRY_ShRLep2GMc=.027ffeab-ae14-4a3f-9a99-8dbc0ded68f1@github.com>
References: <hiHVLJUNxuALrLC5xiE9RgTKHO_HQ-IRxI7ZYdRrjQA=.a6a20de6-1348-4247-bac5-6d7c1281cc5d@github.com>
 <iDOpaRU7KU29Acy1wikMUPhbLmJMheRY_ShRLep2GMc=.027ffeab-ae14-4a3f-9a99-8dbc0ded68f1@github.com>
Message-ID: <8lugQws8BJOVh-fO_ev12pcmRYX3tgeCv8OsZY1kx58=.6940447a-68d9-49dc-8301-17673073bdbd@github.com>

On Tue, 11 Oct 2022 20:50:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8291911: Minor formatting cleanup in test
>  - Merge
>  - 8291911: work in progress
>  - 8291911: Account for quotas on Windows.
>  - 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160"

Commit 8129630943ae98e79bceff18c20a5cb71d30ffd9 passed 50 repeats on the Unix platforms and 150 on Windows.

-------------

PR: https://git.openjdk.org/jdk/pull/9856

From mark.reinhold at oracle.com  Tue Oct 11 23:17:20 2022
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Tue, 11 Oct 2022 23:17:20 +0000
Subject: New candidate JEP: 431: Sequenced Collections
Message-ID: <20221011231719.86821547E2D@eggemoggin.niobe.net>

https://openjdk.org/jeps/431

  Summary: Introduce new interfaces to represent collections with a
  defined encounter order. Each such collection has a well-defined first
  element, second element, and so forth, up to the last element. It also
  provides uniform APIs for accessing its first and last elements, and
  for processing its elements in reverse order.

- Mark

From duke at openjdk.org  Wed Oct 12 00:10:03 2022
From: duke at openjdk.org (David Alvarez)
Date: Wed, 12 Oct 2022 00:10:03 GMT
Subject: RFR: 8295173: (tz) Update Timezone Data to 2022e
Message-ID: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>

Please, review this PR for an update of timezone data. No changes besides the import were needed.

-------------

Commit messages:
 - (tz) Update Timezone Data to 2022e

Changes: https://git.openjdk.org/jdk/pull/10666/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10666&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295173
  Stats: 80 lines in 5 files changed: 22 ins; 12 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/10666.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10666/head:pull/10666

PR: https://git.openjdk.org/jdk/pull/10666

From bhuang at openjdk.org  Wed Oct 12 01:42:11 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 01:42:11 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
 <s4P5r9Nt_1K7e3lMgfpbB9qeaOsIx1_TQn-rlgHbYrQ=.69bb1924-a137-4b53-980b-cd932e877c98@github.com>
Message-ID: <t0Le2-UKI7k4Bf3ZerhkW_uq-GRmSPPzxStm--dJd8o=.9319753f-bfd7-4612-bf47-0a49b98fbcb1@github.com>

On Tue, 11 Oct 2022 15:17:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented review comments.
>
> I have a question, why must this test be manual? Can't we compare the localized texts?

Hi @wangweij, I have a discussion with @naotoj about automating this test. Here is a summary.

1. We can't hard code localized texts into the test and compare to the localized message form the tool. The main reason is mentioned above by @naotoj. Another reason is that localization sometimes may come in slightly different, correctness of translation is not the goal of this test.

2. We can't do a word-to-word comparison. But even so, we can't rely on the same resource bundle used by the tools for localization validation. It provokes a risk that test may fail to detect any localization error in the tool as they use the same mechanism.

3. It makes a bit more sense for this test being a manual test because it matches the look-and-feel criteria. With someone looking into the result, at least it can raise a flag if something doesn?t look right. And only engineers can do this.

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From ysatowse at openjdk.org  Wed Oct 12 02:05:05 2022
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 12 Oct 2022 02:05:05 GMT
Subject: RFR: 8295173: (tz) Update Timezone Data to 2022e
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <etwG9IEB7pT5bjK6_ptbrZSV-u7ZX9KsT6SYhtnbXEI=.1d0bee35-0fa3-4338-95fb-b8a233f8e1fc@github.com>

On Wed, 12 Oct 2022 00:01:50 GMT, David Alvarez <duke at openjdk.org> wrote:

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

We normally run test/jdk/java/util/TimeZone/tools/share/Makefile with the JDK integrating new timezone data in order to generate test/jdk/java/util/TimeZone/TimeZoneData/{VERSION, aliases.txt, displaynamex.txt), which are used by some tests.  With tz2022e integrated JDK, the displaynames.txt seems to be updated along with the changes in tzdata2022e.  Since the changes are just removing the entries for Asia/Amman and Asia/Damascus from displaynamex.txt, the will be no impact for the test runs.  But I would suggest these may want to be included for consistency.

diff --git a/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt b/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt
index b3823958ae4..2f2786f1c69 100644
--- a/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt
+++ b/test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt
@@ -97,9 +97,7 @@ America/Winnipeg CST CDT
 America/Yakutat AKST AKDT
 America/Yellowknife MST MDT
 Antarctica/Macquarie AEST AEDT
-Asia/Amman EET EEST
 Asia/Beirut EET EEST
-Asia/Damascus EET EEST
 Asia/Famagusta EET EEST
 Asia/Gaza EET EEST
 Asia/Hebron EET EEST

-------------

PR: https://git.openjdk.org/jdk/pull/10666

From duke at openjdk.org  Wed Oct 12 04:35:08 2022
From: duke at openjdk.org (David Alvarez)
Date: Wed, 12 Oct 2022 04:35:08 GMT
Subject: RFR: 8295173: (tz) Update Timezone Data to 2022e [v2]
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <7ttKgbE_WY33wQTCW3VvbGui3XVnpks9CynFzx0eNgA=.83c050d8-b63b-4644-a002-3d57c909a24a@github.com>

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

David Alvarez has updated the pull request incrementally with one additional commit since the last revision:

  Update displaynames.txt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10666/files
  - new: https://git.openjdk.org/jdk/pull/10666/files/ffbbfa84..869d7b3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10666&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10666&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10666.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10666/head:pull/10666

PR: https://git.openjdk.org/jdk/pull/10666

From duke at openjdk.org  Wed Oct 12 04:35:09 2022
From: duke at openjdk.org (David Alvarez)
Date: Wed, 12 Oct 2022 04:35:09 GMT
Subject: RFR: 8295173: (tz) Update Timezone Data to 2022e
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <D8Clt_iQ_BvbOT-DynkauyAx5KmnVkR8whQ1d6TK4uM=.9ecf7d43-87a1-454a-aaf1-e03e26706932@github.com>

On Wed, 12 Oct 2022 00:01:50 GMT, David Alvarez <duke at openjdk.org> wrote:

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

Thanks for the explanation!. I've run that Makefile and i can see the new files, including a displaynames.txt that matches what you're sending. I will update this PR with the proper change

-------------

PR: https://git.openjdk.org/jdk/pull/10666

From eliu at openjdk.org  Wed Oct 12 05:51:04 2022
From: eliu at openjdk.org (Eric Liu)
Date: Wed, 12 Oct 2022 05:51:04 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <rFS4yz42zEnj7MJ5kH3W6G2FN-yX0oMI3SNCFSaPqis=.007eabbb-f789-49ad-b38a-0513f7ab2cfb@github.com>

On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

AArch64 part looks good to me.

-------------

Marked as reviewed by eliu (Committer).

PR: https://git.openjdk.org/jdk/pull/10332

From ihse at openjdk.org  Wed Oct 12 09:52:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 09:52:26 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
Message-ID: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>

Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

-------------

Commit messages:
 - 8295205: Add jcheck whitespace checking for markdown files

Changes: https://git.openjdk.org/jdk/pull/10671/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10671&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295205
  Stats: 34 lines in 9 files changed: 0 ins; 0 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/10671.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10671/head:pull/10671

PR: https://git.openjdk.org/jdk/pull/10671

From tvaleev at openjdk.org  Wed Oct 12 13:02:07 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 12 Oct 2022 13:02:07 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v2]
In-Reply-To: <wWpYAP9XlU0gg_Tle1H5wkVhFzdYJLPOJP_47B4fQS8=.6ba5dc04-d614-48b7-8e82-12136046c1d3@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
 <wWpYAP9XlU0gg_Tle1H5wkVhFzdYJLPOJP_47B4fQS8=.6ba5dc04-d614-48b7-8e82-12136046c1d3@github.com>
Message-ID: <WIVG8ix4y_A-wJljVU-tIvnUFDuv8F0lD9qOKqLEDj4=.5e39f890-f295-4791-8f63-c19150f5af84@github.com>

On Tue, 11 Oct 2022 01:48:41 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove Random -> ThreadLocalRandom change
>
> test/jdk/java/util/Collections/Shuffle.java line 92:
> 
>> 90:             throw new RuntimeException(list.getClass() + ": " + list + " != " + copy);
>> 91:         }
>> 92:     }
> 
> Is there a way to factor out the `shuffle` calls and thereby collapse these two methods into one? Is it worth it? I'm thinking you could pass in a `Consumer<List<Integer>>`.

Good idea, thanks! Will do.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Wed Oct 12 13:14:08 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 12 Oct 2022 13:14:08 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v2]
In-Reply-To: <vGKadVAnDHm9KuCOV8B5b2uBQCT_XXOh0TPRnkwwE6I=.46178e8b-1320-451c-9da5-a31bafdf5090@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
 <vGKadVAnDHm9KuCOV8B5b2uBQCT_XXOh0TPRnkwwE6I=.46178e8b-1320-451c-9da5-a31bafdf5090@github.com>
Message-ID: <AQtYvouiCkukd6pCLgqb4Q2K7q3lp73mq51Bc1Ii9Pc=.26f84dfb-e0a2-4500-962f-cf12d5b9df66@github.com>

On Tue, 11 Oct 2022 01:56:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove Random -> ThreadLocalRandom change
>
> test/jdk/java/util/Collections/Shuffle.java line 66:
> 
>> 64:         RandomGeneratorFactory<RandomGenerator> factory = RandomGeneratorFactory.getDefault();
>> 65:         list.sort(null);
>> 66:         Collections.shuffle(list, factory.create(1));
> 
> This assumes that the default factory will accept a seed value that initializes its state so that the pseudorandom sequence is repeatable. Not an unreasonable assumption, but `create(long)` essentially says that it can ignore the seed, and `getDefault` says the algorithm may change over time. On the other hand if something does change such that the pseudorandom sequence isn't repeatable, this test will most likely fail immediately. I was poking around for an explicit way to request some kind of PRNG that's guaranteed to be started in repeatable state, but I couldn't find one. Hmmm.

Oh, that's an unfortunate detail, I didn't know about this. We can explicitly request a JumpableGenerator, like "Xoshiro256PlusPlus" and then copy it via `copy()` method. What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From erikj at openjdk.org  Wed Oct 12 13:19:22 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Oct 2022 13:19:22 GMT
Subject: RFR: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <2owj2BREdvPlEo70s1rAvPywZeUPcimsej24fiAHyB4=.26f3a76b-0765-49ea-882d-591748bf1dcf@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

Thank you! Since I enabled visible whitespace in emacs (to be able to properly edit makefiles) editing any file where trailing whitespace isn't enforced makes my eyes bleed. :)

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10671

From tvaleev at openjdk.org  Wed Oct 12 13:26:29 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 12 Oct 2022 13:26:29 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
Message-ID: <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>

> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Fixes according to review
  
  1. Reduce duplication in tests
  2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
  3. Simplify documentation for shuffle(List, Random) to avoid duplication.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10520/files
  - new: https://git.openjdk.org/jdk/pull/10520/files/6fa7d942..127e44ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10520&range=01-02

  Stats: 38 lines in 2 files changed: 2 ins; 26 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10520.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10520/head:pull/10520

PR: https://git.openjdk.org/jdk/pull/10520

From tvaleev at openjdk.org  Wed Oct 12 13:26:30 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 12 Oct 2022 13:26:30 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v2]
In-Reply-To: <7B07btJvICIuVCs1iuZlnlwWwwHmqeVJQPRsDlx6aC4=.fe3598fe-76b1-4178-b346-9e477ce0a38a@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <hEr173XFTuAlThh362pTbKBoTK-Yt8EM4043D6jatSU=.70d01304-52e3-49d3-8059-502bbe7c3c24@github.com>
 <7B07btJvICIuVCs1iuZlnlwWwwHmqeVJQPRsDlx6aC4=.fe3598fe-76b1-4178-b346-9e477ce0a38a@github.com>
Message-ID: <UieAEKHIz3IgsGXt6LDKTHMn1HWXui6hA7pS1TDzf-M=.2c93bf8d-0fe8-4038-bbda-286a6205ab28@github.com>

On Tue, 11 Oct 2022 02:00:40 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove Random -> ThreadLocalRandom change
>
> src/java.base/share/classes/java/util/Collections.java line 485:
> 
>> 483:      *         list-iterator does not support the {@code set} operation.
>> 484:      * @since 20
>> 485:      */
> 
> It looks like this comment was copied from `shuffle(List, Random)` and `shuffle(List)` which is fine. But since this method is now preferred over the others, maybe we can reduce the duplication and have those other methods simply be defined in terms of this one. We'd have to come up with the right "weasel words" to describe the source of randomness used by `shuffle(List)`. In addition, if you don't want to deprecate the other methods, perhaps some wording can be found that clearly indicates this new method is now the preferred one.

I updated the documentation, please take a look. Deprecation sounds not a good idea, as if you want to use a randomness source that happens to extend Random class (e.g., ThreadLocalRandom.current()), compiler will link it to the old method. This is totally fine, and you should not get a deprecation warning.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From ihse at openjdk.org  Wed Oct 12 13:34:32 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 13:34:32 GMT
Subject: Integrated: 8295205: Add jcheck whitespace checking for markdown files
In-Reply-To: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
References: <JwAKg2dZVM1FL866mSl5HD8OaLQn1cpUHfV_BSEpIBs=.6d783546-3b70-4858-b070-d7476d12b58c@github.com>
Message-ID: <4JUC33BHEbQxyvmLXseCLGOGURYFR_6f0uHcyJaGUkc=.cb1528a9-2718-4bfc-9a70-dce6a9e4db00@github.com>

On Wed, 12 Oct 2022 09:44:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Markdown files are basically source code for documentation. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

This pull request has now been integrated.

Changeset: 86078423
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/860784238ea1f3e4a817fc3c28fb89cfee7549dd
Stats:     34 lines in 9 files changed: 0 ins; 0 del; 34 mod

8295205: Add jcheck whitespace checking for markdown files

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10671

From jwaters at openjdk.org  Wed Oct 12 13:36:36 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Oct 2022 13:36:36 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v4]
In-Reply-To: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
Message-ID: <zxnvYF4bxmI-byOyOQAFKiDW9Mq9UBJ0v-M2w-kGTGQ=.073e15d1-d78e-417b-b663-a40645185671@github.com>

> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-1
 - Comment documenting change isn't required
 - Merge branch 'openjdk:master' into patch-1
 - Comment formatting
 - Remove Windows specific JLI_Snprintf implementation
 - Remove Windows JLI_Snprintf definition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10625/files
  - new: https://git.openjdk.org/jdk/pull/10625/files/9149aae1..8ac9b519

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=02-03

  Stats: 7257 lines in 143 files changed: 5279 ins; 912 del; 1066 mod
  Patch: https://git.openjdk.org/jdk/pull/10625.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10625/head:pull/10625

PR: https://git.openjdk.org/jdk/pull/10625

From naoto at openjdk.org  Wed Oct 12 16:14:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Oct 2022 16:14:28 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v2]
In-Reply-To: <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <LrQdv-4eOuuaNH35ihrGOLCpy0M1JX1kknFDvl32ECk=.ef9cbd68-c262-4cab-adbb-feeaccc23b43@github.com>
Message-ID: <qDqXEgE8gASVTwohMaAZL3DYpAzQurzoQICQApcpCdw=.562c873e-5426-40ab-b24d-89f2d5974e58@github.com>

On Mon, 10 Oct 2022 23:23:00 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Looks much better now. A minor comment on the library.

test/lib/jdk/test/lib/TestUI.java line 30:

> 28: import java.awt.event.WindowEvent;
> 29: 
> 30: public class TestUI {

I would expect some class description for this library. Also, could the library name be more descriptive than "TestUI"?

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From rriggs at openjdk.org  Wed Oct 12 16:38:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Oct 2022 16:38:15 GMT
Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException
 when a process on Windows returns an exit code of 259
Message-ID: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>

Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259.
As described in the bug report, `waitFor()` should be sensitive to the exit value.
Previously, it erroneously threw IllegalStateException.
Added a test to verify.

-------------

Commit messages:
 - 8294899: Process.waitFor() throws IllegalThreadStateException

Changes: https://git.openjdk.org/jdk/pull/10680/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10680&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294899
  Stats: 50 lines in 2 files changed: 49 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10680.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10680/head:pull/10680

PR: https://git.openjdk.org/jdk/pull/10680

From bhuang at openjdk.org  Wed Oct 12 18:03:19 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 18:03:19 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v3]
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <4aosQzAkhEDzQJGGmKkrXlqNuzcC6CrQf4L5ri6ny8o=.bdb6a3a4-dd6c-4931-910a-704058413bd3@github.com>

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Added documentation to UIBuilder.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10635/files
  - new: https://git.openjdk.org/jdk/pull/10635/files/a36cd005..b808c0a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=01-02

  Stats: 267 lines in 3 files changed: 160 ins; 105 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From mchhipa at openjdk.org  Wed Oct 12 18:16:34 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 12 Oct 2022 18:16:34 GMT
Subject: Integrated: JDK-8289509 : Improve test coverage for XPath Axes:
 descendant, descendant-or-self, following, following-sibling
In-Reply-To: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
References: <HZT_rQr8S4S0E3HQ8N8RfOEjTQ38IaTcOoysprkoOaY=.7f9c498b-a58b-41e4-a6df-f768b7c5b0db@github.com>
Message-ID: <zWpRP5DkB51EXWI_iVdsEUA3B3ZaLCWTsDYp5io9AX0=.5f03f7d0-ded2-4560-a562-9fb7c296f879@github.com>

On Tue, 4 Oct 2022 13:01:40 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Added test cases for xpath Axis:
> 1. descendant
> 2. descendant-or-self
> 3. following
> 4. following-sibling

This pull request has now been integrated.

Changeset: 1961e81e
Author:    Mahendra Chhipa <mchhipa at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1961e81e02e707cd0c8241aa3af6ddabf7668589
Stats:     358 lines in 2 files changed: 358 ins; 0 del; 0 mod

8289509: Improve test coverage for XPath Axes: descendant, descendant-or-self, following, following-sibling

Reviewed-by: bhuang, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10557

From bhuang at openjdk.org  Wed Oct 12 18:31:16 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 18:31:16 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v4]
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <RKFYi2Kv9-fIuAyvg0YBEBwRHxb2RYCK_v8AFg7qPow=.00febe82-bd61-492b-a9f2-f03c70d7afc0@github.com>

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Fixed typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10635/files
  - new: https://git.openjdk.org/jdk/pull/10635/files/b808c0a5..4c08a3e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10635&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10635.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10635/head:pull/10635

PR: https://git.openjdk.org/jdk/pull/10635

From naoto at openjdk.org  Wed Oct 12 20:11:13 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Oct 2022 20:11:13 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
Message-ID: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>

Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

-------------

Commit messages:
 - 8295232: "java.locale.useOldISOCodes" property is read lazily

Changes: https://git.openjdk.org/jdk/pull/10683/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295232
  Stats: 71 lines in 3 files changed: 69 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10683.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10683/head:pull/10683

PR: https://git.openjdk.org/jdk/pull/10683

From lancea at openjdk.org  Wed Oct 12 20:22:02 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 12 Oct 2022 20:22:02 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <gbN1qPx3mY59A7B2ctZfFMdbxZjo3uUIyJW_fVbSScg=.882835b0-dd15-42a7-b029-84c0b7f8a600@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10683

From bpb at openjdk.org  Wed Oct 12 20:35:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Oct 2022 20:35:01 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <QAmXl-Uvs-hFz5PDlpaqPKk8beY0F6Amu6JQdww0dSM=.547b1100-a038-4861-8c98-c163b6faacec@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10683

From naoto at openjdk.org  Wed Oct 12 20:53:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Oct 2022 20:53:07 GMT
Subject: RFR: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance [v4]
In-Reply-To: <RKFYi2Kv9-fIuAyvg0YBEBwRHxb2RYCK_v8AFg7qPow=.00febe82-bd61-492b-a9f2-f03c70d7afc0@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
 <RKFYi2Kv9-fIuAyvg0YBEBwRHxb2RYCK_v8AFg7qPow=.00febe82-bd61-492b-a9f2-f03c70d7afc0@github.com>
Message-ID: <lr7Zbd6n4nOHLZSkinyO7iv1zNVp2ybeg4OnrrOhzgY=.58ae0071-46db-4772-80e9-cba73b471d1c@github.com>

On Wed, 12 Oct 2022 18:31:16 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
>> 
>> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From iris at openjdk.org  Wed Oct 12 21:22:05 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 12 Oct 2022 21:22:05 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <41HXWAXtYCL2DQ4hp6yrDLZkOmcOpGDP6_6eILYBeDo=.85b426ab-9cc7-403e-ba73-768cffb8fd40@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10683

From rriggs at openjdk.org  Wed Oct 12 21:25:30 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Oct 2022 21:25:30 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <aQoUKIMHYzBATE31nPyc2OFrIJJYkw0vm4ylgV7PjxQ=.bd10b320-f228-4448-a05e-860c4e797e43@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10683

From bhuang at openjdk.org  Wed Oct 12 22:20:28 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 12 Oct 2022 22:20:28 GMT
Subject: Integrated: JDK-8294994: Update Jarsigner and Keytool i18n tests to
 validate i18n compliance
In-Reply-To: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
References: <8aH7LoghDBgN2f5AwkzaF17uhpL-b0jpc1QaD_dQm6c=.870a781a-f3b5-4198-af41-41d6718ec4bd@github.com>
Message-ID: <JwZZkExq0NKv2jpXbjvE4tthBJK7JVMARWDQ8Z6TxSo=.f6806f6e-8a37-410a-a17b-b98e34a75597@github.com>

On Mon, 10 Oct 2022 18:18:55 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> The jarsigner and keytool are localized into English, German, Japanese and Simplified Chinese. This task is to modify the existing i18n tests to validate i18n compliance in these tools. 
> 
> In addition, this task also contains changes for manual test enhancement and simplification which originated from [JDK-8292663](https://bugs.openjdk.org/browse/JDK-8292663).

This pull request has now been integrated.

Changeset: ac194142
Author:    Bill Huang <bhuang at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac1941425bdb1a25aa3364eef9eb1092ee716761
Stats:     497 lines in 3 files changed: 485 ins; 2 del; 10 mod

8294994: Update Jarsigner and Keytool i18n tests to validate i18n compliance

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/10635

From jbhateja at openjdk.org  Thu Oct 13 07:26:06 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 13 Oct 2022 07:26:06 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <_wyFWAET_qXwwj-9Iq9AsPAGbT3AXIwN6HujmwZVRPw=.9c652886-4255-4c03-89d9-e3c74f9f319a@github.com>

On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

src/hotspot/share/opto/vectorIntrinsics.cpp line 2949:

> 2947:   } else if (elem_bt == T_DOUBLE) {
> 2948:     iota = gvn().transform(new VectorCastL2XNode(iota, vt));
> 2949:   }

Since we are loading constants from stub initialized memory locations, defining new stubs for floating point iota indices may eliminate need for costly conversion instructions. Specially on X86 conversion b/w Long and Double is only supported by AVX512DQ targets and intrinsification may fail for legacy targets.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2978:

> 2976:       case T_DOUBLE: {
> 2977:         scale = gvn().transform(new ConvI2LNode(scale));
> 2978:         scale = gvn().transform(new ConvL2DNode(scale));

Prior target support check for these IR nodes may prevent surprises in the backend.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2978:

> 2976:       case T_DOUBLE: {
> 2977:         scale = gvn().transform(new ConvI2LNode(scale));
> 2978:         scale = gvn().transform(new ConvL2DNode(scale));

Any specific reason for not directly using ConvI2D for double case.

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From xgong at openjdk.org  Thu Oct 13 07:32:07 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 13 Oct 2022 07:32:07 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <_wyFWAET_qXwwj-9Iq9AsPAGbT3AXIwN6HujmwZVRPw=.9c652886-4255-4c03-89d9-e3c74f9f319a@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
 <_wyFWAET_qXwwj-9Iq9AsPAGbT3AXIwN6HujmwZVRPw=.9c652886-4255-4c03-89d9-e3c74f9f319a@github.com>
Message-ID: <nfFdnOPHhVzZjo0VFxyUIZC2T_DjfzuLFSMNL710iOU=.b2edff64-df5d-4415-a533-268ed1444f9d@github.com>

On Thu, 13 Oct 2022 07:18:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
>> 
>> This patch adds the vector intrinsic implementation of it. The steps are:
>> 
>>   1) Load the const "iota" vector.
>> 
>>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
>> 
>>   2) Compute indexes with "`vec + iota * scale`"
>> 
>> Here is the performance result to the new added micro benchmark on ARM NEON:
>> 
>> Benchmark                              Gain
>> IndexVectorBenchmark.byteIndexVector   1.477
>> IndexVectorBenchmark.doubleIndexVector 5.031
>> IndexVectorBenchmark.floatIndexVector  5.342
>> IndexVectorBenchmark.intIndexVector    5.529
>> IndexVectorBenchmark.longIndexVector   3.177
>> IndexVectorBenchmark.shortIndexVector  5.841
>> 
>> 
>> Please help to review and share the feedback! Thanks in advance!
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2978:
> 
>> 2976:       case T_DOUBLE: {
>> 2977:         scale = gvn().transform(new ConvI2LNode(scale));
>> 2978:         scale = gvn().transform(new ConvL2DNode(scale));
> 
> Any specific reason for not directly using ConvI2D for double case.

Good catch, I think it's ok to use ConvI2D here. I will change this. Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From duke at openjdk.org  Thu Oct 13 10:12:16 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 13 Oct 2022 10:12:16 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder()
In-Reply-To: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
Message-ID: <EtIloSWPA7uboRnKs8YgZws17VCp_TqmM6anNz2JbIg=.2b0650f7-0e89-43e4-862f-3a11e5f5ae81@github.com>

On Wed, 17 Aug 2022 11:23:57 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
> 
> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?

Let's wait

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From coffeys at openjdk.org  Thu Oct 13 10:36:27 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 10:36:27 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <pEvO6BeoHA_sbDL7bhubQFZotGm9XmAMY2ep8nKVvNo=.98e1a149-a23a-4458-ae80-dfec3402e8b9@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Marked as reviewed by coffeys (Reviewer).

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 38:

> 36: import jdk.internal.util.StaticProperty;
> 37: import jdk.internal.vm.annotation.Stable;
> 38: import sun.security.action.GetPropertyAction;

unused import can be removed "sun.security.action.GetPropertyAction"

-------------

PR: https://git.openjdk.org/jdk/pull/10683

From jpai at openjdk.org  Thu Oct 13 12:32:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 12:32:05 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <2LlIOshAZkGspRSquIBSNWRjLcyCHuVgC2RGXuhPrc4=.70400537-b1a7-4a53-8b1b-f76285cde5b5@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 59:

> 57:      * @return true - if the factory is allowed to be instantiated; false - otherwise
> 58:      */
> 59:     public static boolean checkGlobalFilter(Class<?> serialClass) {

I think the `serialClass` param should be renamed to `factoryClass` or something like that, since I think the `serialClass` reference comes from serialization/deserialization usage.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 12:37:08 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 12:37:08 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <FGZbktWLAcghlwjFdTrPV6vrZZkyK5FBv7Jx64AkfjA=.2e34222d-3f26-48b9-b6b2-fb9db51d52e9@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.base/share/conf/security/java.security line 1408:

> 1406: # references bound to LDAP contexts. The factory class named by the reference instance will
> 1407: # be matched against this filter. The filter property supports pattern-based filter syntax
> 1408: # with the same format as jdk.serialFilter.

Hello Aleksei, as far as I can see the `jdk.serialFilter` allows for additional details like `limits` (example: `maxdepth=value`). Should we note here that this JNDI specific property will ignore those configurations?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 12:41:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 12:41:09 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.base/share/conf/security/java.security line 1423:

> 1421: #
> 1422: # The default pattern value allows any object factory class defined in the java.naming module
> 1423: # to be specified by the reference instance, but rejects any other.

Should this instead say:
> The default pattern value allows any object factory class belonging to the `com.sun.jndi.ldap` and its sub-packages of the `java.naming` module to be specified by the reference instance...?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:23:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:23:10 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <5WZp2QFcNIapf6FaRhY6JWf3ZBCr930jLAlF-BYmXUg=.accba2c1-84c5-49b4-b978-bc7c320c1b89@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 109:

> 107:      * @see java.lang.SecurityManager#checkSetFactory
> 108:      */
> 109:     public static synchronized void setObjectFactoryBuilder(

Perhaps remove the `synchronized` from this method and the getter, now that the synchronization has moved to the `NamingManagerHelper` class?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:33:10 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:33:10 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <ingf31EKum851vQsVe04hBXRAwENQ0AUtWeEqSYulKE=.58863a5f-dbea-48f0-8c63-4e084bd9870c@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/com/sun/naming/internal/NamingManagerHelper.java line 416:

> 414:     /**
> 415:      * Package-private; used by DirectoryManager and NamingManager.
> 416:      */

This comment is no longer relevant, given that this is now an internal private field of this class.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:39:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:39:17 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <cTG4s1RthBsc-_3HHzk_LdZgasfGBgpL98pSjULfIaU=.d990e794-ca0c-4f08-be49-cca1ed4b8a4c@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.base/share/conf/security/java.security line 1410:

> 1408: # with the same format as jdk.serialFilter.
> 1409: #
> 1410: # Each pattern is matched against the factory class name to allow or disallow it's

I believe this should be `its` instead of `it's`

src/java.base/share/conf/security/java.security line 1411:

> 1409: #
> 1410: # Each pattern is matched against the factory class name to allow or disallow it's
> 1411: # instantiation. The access to a factory class is allowed only when its not rejected by this filter

and here it should be `it's` instead of `its`

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From rriggs at openjdk.org  Thu Oct 13 13:58:19 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Oct 2022 13:58:19 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <FGZbktWLAcghlwjFdTrPV6vrZZkyK5FBv7Jx64AkfjA=.2e34222d-3f26-48b9-b6b2-fb9db51d52e9@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <FGZbktWLAcghlwjFdTrPV6vrZZkyK5FBv7Jx64AkfjA=.2e34222d-3f26-48b9-b6b2-fb9db51d52e9@github.com>
Message-ID: <eptZUHUsJFrKtALEGpIxXHbFHlpwPuniJpQ-n0oowUY=.e1744050-962c-4ac2-8e9d-055221cd470d@github.com>

On Thu, 13 Oct 2022 12:34:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.base/share/conf/security/java.security line 1408:
> 
>> 1406: # references bound to LDAP contexts. The factory class named by the reference instance will
>> 1407: # be matched against this filter. The filter property supports pattern-based filter syntax
>> 1408: # with the same format as jdk.serialFilter.
> 
> Hello Aleksei, as far as I can see the `jdk.serialFilter` allows for additional details like `limits` (example: `maxdepth=value`). Should we note here that this JNDI specific property will ignore those configurations?

Yes, worth noting, but I would say they are "unused", not ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jpai at openjdk.org  Thu Oct 13 13:58:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Oct 2022 13:58:20 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
Message-ID: <hC0IplTN6hRI7nQrsmxqczSRpnP_iObiGarvFCyjCMw=.46e10839-a7e7-4da0-aff5-b8efa16b7061@github.com>

On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change checkInput to be the global filter centric

src/java.naming/share/classes/com/sun/naming/internal/NamingManagerHelper.java line 81:

> 79:                 // No factory found, so return original refInfo.
> 80:                 // Will reach this point if factory class is not in
> 81:                 // class path and reference does not contain a URL for it

I think this "Will reach this point ..." part should be updated to note that the code will additionally reach here if the factory class is disallowed by the filters.

Similar change would be needed for the comment in `getDirObjectInstance` method.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From jwaters at openjdk.org  Thu Oct 13 14:48:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 13 Oct 2022 14:48:29 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v5]
In-Reply-To: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
Message-ID: <LAdK3zAvSQiFX2AAa4BvHwfNUUeSG8ye-qbEKWlmzbc=.968c8988-6132-4cf1-b81c-4e9274bfd5c8@github.com>

> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-1
 - Merge branch 'openjdk:master' into patch-1
 - Comment documenting change isn't required
 - Merge branch 'openjdk:master' into patch-1
 - Comment formatting
 - Remove Windows specific JLI_Snprintf implementation
 - Remove Windows JLI_Snprintf definition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10625/files
  - new: https://git.openjdk.org/jdk/pull/10625/files/8ac9b519..a24ef092

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10625&range=03-04

  Stats: 2113 lines in 62 files changed: 1331 ins; 653 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/10625.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10625/head:pull/10625

PR: https://git.openjdk.org/jdk/pull/10625

From jwaters at openjdk.org  Thu Oct 13 14:48:30 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 13 Oct 2022 14:48:30 GMT
Subject: RFR: 8295017: Remove Windows specific workaround in JLI_Snprintf
 [v3]
In-Reply-To: <iFdzsokxjgv0NGYH-8o-9U8e6ItaBgoUxmii-I4ZcRE=.00b23800-fe28-485b-95bc-0a6ab3777852@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
 <Tve0iW0pLnP3F4ZzUhSWwI6XxEH-e1xPhUpXT1hQwqI=.39a8204c-842e-45a2-9b62-760582f62382@github.com>
 <iFdzsokxjgv0NGYH-8o-9U8e6ItaBgoUxmii-I4ZcRE=.00b23800-fe28-485b-95bc-0a6ab3777852@github.com>
Message-ID: <0wUuynDia128uyCaMmWi7BltH8HQcyI-CKcyGcP_Ucc=.89942c4d-b2a5-4fd2-8599-0c43745057a6@github.com>

On Tue, 11 Oct 2022 02:01:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Comment documenting change isn't required
>>  - Merge branch 'openjdk:master' into patch-1
>>  - Comment formatting
>>  - Remove Windows specific JLI_Snprintf implementation
>>  - Remove Windows JLI_Snprintf definition
>
> Looks good. Thanks.

@dholmes-ora could I trouble you for a sponsor? Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10625

From naoto at openjdk.org  Thu Oct 13 16:00:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 16:00:56 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
In-Reply-To: <pEvO6BeoHA_sbDL7bhubQFZotGm9XmAMY2ep8nKVvNo=.98e1a149-a23a-4458-ae80-dfec3402e8b9@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
 <pEvO6BeoHA_sbDL7bhubQFZotGm9XmAMY2ep8nKVvNo=.98e1a149-a23a-4458-ae80-dfec3402e8b9@github.com>
Message-ID: <F9qIEaHSKaSsFed0PxMx7GrZRAmrsfKa-8VWQMHkJxg=.d04f9932-acb0-472c-9c7a-0285b382760c@github.com>

On Thu, 13 Oct 2022 10:33:32 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 38:
> 
>> 36: import jdk.internal.util.StaticProperty;
>> 37: import jdk.internal.vm.annotation.Stable;
>> 38: import sun.security.action.GetPropertyAction;
> 
> unused import can be removed "sun.security.action.GetPropertyAction"

Thanks, Sean. Will remove this unnecessary import before the integration.

-------------

PR: https://git.openjdk.org/jdk/pull/10683

From coffeys at openjdk.org  Thu Oct 13 16:06:13 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 16:06:13 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v5]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - test update
 - Merge branch 'master' into secEvent-8292177
 - Use stringPropertyNames()
 - Refactor getter method name
 - Restore ProtectionDomain to original
 - Store properties cache in Security class
 - Remove unused import
 - Address Oct 10 review comments
 - Check for 0 security events
 - Null check on Properties
 - ... and 7 more: https://git.openjdk.org/jdk/compare/3644e26c...3a347dae

-------------

Changes: https://git.openjdk.org/jdk/pull/10394/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=04
  Stats: 255 lines in 12 files changed: 252 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Thu Oct 13 16:08:07 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 16:08:07 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v3]
In-Reply-To: <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <AbUWOlrfzxEMrmU2OBP3bdWjxfBU32gDzjJosocIS8w=.1d570af9-14ff-4852-aa48-f7f6d80204bf@github.com>
 <ao03C0kQS19ihYPzd2Aj8jIFpF6w6Bsevwtu_k5fkj8=.44b1a465-ad73-4793-b59c-dcaeb395fb37@github.com>
 <Z6kSUIZI6X50nqx0uJey1T6UijG4wAyc7yJsf9SXqZc=.f6133751-acca-40c8-8e94-b82738e54c64@github.com>
 <WsDzSX8fN79oD9-x8YnQY0UOGDcgJtrfYoPEyx285Wk=.04ed575c-bf05-4650-8af4-3f0504aaa908@github.com>
 <FaYqZrXdZ3QVPZGzax46dl8v574FwPdS_y_KNqRDHUo=.6963af2e-9fa5-47e8-aead-f139cb605f55@github.com>
 <VsBRivnPXk8BouUPpEghIR5vTsFeXQfZ6CNNT3XB1XQ=.fe78283c-d371-4c92-8d0c-eac7187bacda@github.com>
 <o3DXb6ujIK5-7uA2sDqQ5JXYJ-JJjPycj4TY3hfJq7c=.5ad6bcf8-81d0-42e6-b379-96290ede19e3@github.com>
Message-ID: <D8TG79W6XZC2rkrQ6a8MZjKQ7iX4nZUeC-KrThk2VlU=.caf70d0c-5644-46f4-8242-10b4adfa555a@github.com>

On Tue, 11 Oct 2022 12:39:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @seanjmullan  - I looked at that approach. The `SharedSecrets.getJavaSecurityAccess().getInitialProperties();` call may trigger early initialization of the `java.security.Security` class - I'm not sure if we want that. ProtectionDomain class is currently loaded early in the JDK boot cycle. 
>> 
>> In fact the change suggested by @AlanBateman yesterday also has possibility to trigger unnecessary loading of the Security class. I might revert to the original design where we store the cached Properties in ProtectionDomain ?
>
> Maybe I am missing something. If this JFR event is enabled, and the properties have not yet been accessed, then it seems ok for JFR to load the `Security` class when JFR is started since the user is interested in this event.

After further conversation with @seanjmullan , a sharedSecrets accessor for the Properties map should be ok. Edits pushed.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From naoto at openjdk.org  Thu Oct 13 16:10:04 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 16:10:04 GMT
Subject: RFR: 8295232: "java.locale.useOldISOCodes" property is read lazily
 [v2]
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <GgAAVn3QxlrQFJuUroZa6oM71CgGhQoaHFdSOjsY12g=.c94954e6-ee7f-4b4e-86a8-91a0d463eca2@github.com>

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10683/files
  - new: https://git.openjdk.org/jdk/pull/10683/files/20bc893d..c920070b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10683&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10683&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10683.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10683/head:pull/10683

PR: https://git.openjdk.org/jdk/pull/10683

From naoto at openjdk.org  Thu Oct 13 16:24:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 16:24:17 GMT
Subject: Integrated: 8295232: "java.locale.useOldISOCodes" property is read
 lazily
In-Reply-To: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
References: <UHaCMlss0Azd2VyZ_y1HqEt_DHSgPy8QyLcIQzxnXr4=.6021a06e-ea38-4113-bd2e-25c38224c8a7@github.com>
Message-ID: <9N0y7WJW_hvIYy3547YRh5z6uZRNzuLwFOxmPHwFKfg=.b1af8721-86be-465b-9ca0-00973b8ed606@github.com>

On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed to utilize `StaticProperty` so that the system property value for `java.locale.useOldISOCodes` set on the command line is honored even with lazy `Locale` initialization.

This pull request has now been integrated.

Changeset: 4224d451
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4224d45132b98e4f7bb7a96b696692d2f0bf645e
Stats:     72 lines in 3 files changed: 69 ins; 2 del; 1 mod

8295232: "java.locale.useOldISOCodes" property is read lazily

Reviewed-by: lancea, bpb, iris, rriggs, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/10683

From ron.pressler at oracle.com  Thu Oct 13 17:06:07 2022
From: ron.pressler at oracle.com (Ron Pressler)
Date: Thu, 13 Oct 2022 17:06:07 +0000
Subject: JEP400 vs new Scanner(System.in)
In-Reply-To: <CAK6PxWOtEndtbecUdr1Pgw=O4_9iq_kupCPzFgA5t+aFSrVV5g@mail.gmail.com>
References: <CAK6PxWOtEndtbecUdr1Pgw=O4_9iq_kupCPzFgA5t+aFSrVV5g@mail.gmail.com>
Message-ID: <AF424E7E-5B47-4E27-AB3E-BBE54DCB410E@oracle.com>

Hi.

The appropriate list is core-libs-dev, where this discussion should continue.

System.in is the standard input, which may or may not be the keyboard. For keyboard input, take a look at the java.io.Console class [1], in particular its charset and reader methods.

[1]: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/io/Console.html

? Ron

On 13 Oct 2022, at 16:20, Reinier Zwitserloot <reinier at zwitserloot.com<mailto:reinier at zwitserloot.com>> wrote:

PREAMBLE: I?m not entirely certain amber-dev is the appropriate venue. If not, where should this be discussed? It?s not quite a bug but nearly so, and not quite a simple feature request either.

JDK18 brought JEP400 which changes the default charset encoding to UTF-8. This, probably out of necessity, goes quite far, in that Charset.defaultCharset() is now more or less a constant - always returns UTF_8. It?s now quite difficult to retrieve the OS-configured encoding (the ?native? encoding).

However, that does mean one of the most common lines in all of java?s history, is now necessarily buggy: new Scanner(System.in) is now broken. Always, unless your docs specifically state that you must feed the app UTF_8 data. Linting tools ought to flag it down as incorrect. It?s incorrect In a nasty way too: Initially it seems to work fine, but if you?re on an OS whose native encoding isn?t UTF-8, this is subtly broken; enter non-ASCII characters on the command line and the app doesn?t handle them appropriately. A bug that is literally utterly undiscoverable on macs and most linux computers, even. How can you figure out your code is broken if all the machines you test it on use UTF-8 as an OS default?

This affects beginning java programmers particularly (who tend to be writing some command line-interactive apps at first). In light of Brian Goetz?s post ?Paving the Onramp? (https://openjdk.org/projects/amber/design-notes/on-ramp) - the experience for new users is evidently of some importance to the OpenJDK team. In light of that, the current state of writing command line interactive java apps is inconsistent with that goal.

The right way to read system input in a way that works in both pre- and post-JEP400 JVM editions appears to be, as far as I can tell:


Charset nativeCharset = Charset.forName(System.getProperty("native.encoding", Charset.defaultEncoding().name());
Scanner sc = new Scanner(System.in, nativeCharset);

I?ll risk the hyperbole: That?s.. atrocious. Hopefully I?m missing something!

Breaking _thousands_ of blogs, tutorials, stack overflow answers, and books in the process, everything that contains new Scanner(System.in). Even sysin interaction that doesn?t use scanner is likely broken; the general strategy then becomes:


new InputStreamReader(System.in);

which suffers from the same problem.

I see a few directions for trying to address this; I?m not quite sure which way would be most appropriate:


  *   Completely re-work keyboard input, in light of Paving the on-ramp. Scanner has always been a problematic API if used for keyboard input, in that the default delimiter isn?t convenient. I think the single most common beginner java stackoverflow question is the bizarre interaction between scanner?s nextLine() and scanner?s next(), and to make matters considerably worse, the proper fix (which is to call .useDelimiter(?\\R?) on the scanner first) is said in less than 1% of answers; the vast majority of tutorials and answers tell you to call .nextLine() after every .nextX() call. A suboptimal suggestion (it now means using space to delimit your input is broken). Scanner is now also quite inconsistent: The constructor goes for ?internet standard?, using UTF-8 as a default even if the OS does not, but the locale does go by platform default, which affects double parsing amongst other things: scanner.nextDouble() will require you to use commas as fractions separator if your OS is configured to use the Dutch locale, for example. It?s weird that scanner neither fully follows common platform-independent expectations (english locale, UTF-8), nor local-platform expectation (OS-configured locale and OS-configured charset). One way out is to make a new API for ?command line apps? and take into account Paving the on-ramp?s plans when designing it.
  *   Rewrite specifically the new Scanner(InputStream) constructor as defaulting to native encoding even when everything else in java defaults to UTF-8 now, because that constructor is 99% used for System.in. Scanner has its own File-based constructor, so new Scanner(Files.newInputStream(..)) is quite rare.
  *   Define that constructor to act as follows: the charset used is the platform default (i.e., from JDK18 and up, UTF-8), unless arg == System.in is true, in which case the scanner uses native encoding. This is a bit bizarre to write in the spec but does the right thing in the most circumstances and unbreaks thousands of tutorials, blogs, and answer sites, and is most convenient to code against. That?s usually the case with voodoo magic (because this surely risks being ?too magical?): It?s convenient and does the right thing almost always, at the risk of being hard to fathom and producing convoluted spec documentation.
  *   Attach the problem that what?s really broken isn?t so much scanner, it?s System.in itself: byte based, of course, but now that all java methods default to UTF-8, almost all interactions with it (given that most System.in interaction is char-based, not byte-based) are now also broken. Create a second field or method in System that gives you a Reader instead of an InputStream, with the OS-native encoding applied to make it. This still leaves those thousands of tutorials broken, but at least the proper code is now simply new Scanner(System.charIn()) or whatnot, instead of the atrocious snippet above.
  *   Even less impactful, make a new method in Charset to get the native encoding without having to delve into System.getProperty(). Charset.nativeEncoding() seems like a method that should exist. Unfortunately this would be of no help to create code that works pre- and post-JEP400, but in time, having code that only works post-JEP400 is fine, I assume.
  *   Create a new concept ?represents a stream that would use platform native encoding if characters are read/written to it?, have System.in return true for this, and have filterstreams like BufferedInputStream just pass the call through, then redefine relevant APIs such as Scanner and PrintStream (e.g. anything that internalises conversion from bytes to characters) to pick charset encoding (native vs UTF8) based on that property. This is a more robust take on ?new Scanner(System.in) should do the right thing'. Possibly the in/out/err streams that Process gives you should also have this flag set.


If it was up to me, I think a multitude of steps are warranted, each relatively simple.


  *   Create Charset.nativeEncoding(). Which simply returns Charset.forName(System.getProperty(?native.encoding?). But with the advantage that its shorter, doesn?t require knowing a magic string, and will fail at compile time if compiled against versions that predate the existence of the native.encoding property, instead of NPEs at runtime.
  *   Create System.charIn(). Which just returns an InputStreamReader wrapped around System.in, but with native encoding applied.
  *   Put the job of how java apps do basic command line stuff on the agenda as a thing that should probably be addressed in the next 5 years or so, maybe after the steps laid out in Paving the on-ramp are more fleshed out.
  *   In order to avoid problems, before the next LTS goes out, re-spec new Scanner(System.in) to default to native encoding, specifically when the passed inputstream is identical to System.in. Don?t bother with trying to introduce an abstracted ?prefers native encoding? flag system.

 --Reinier Zwitserloot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221013/904f277b/attachment-0001.htm>

From aefimov at openjdk.org  Thu Oct 13 17:45:26 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 17:45:26 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <2LlIOshAZkGspRSquIBSNWRjLcyCHuVgC2RGXuhPrc4=.70400537-b1a7-4a53-8b1b-f76285cde5b5@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <2LlIOshAZkGspRSquIBSNWRjLcyCHuVgC2RGXuhPrc4=.70400537-b1a7-4a53-8b1b-f76285cde5b5@github.com>
Message-ID: <17uHllhsdXbhG6eiXncEdORpmBQPpeTGzOUnjHZtXeU=.f9b4b754-ff9d-4b8d-98ae-b9b34b86ae40@github.com>

On Thu, 13 Oct 2022 12:29:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 59:
> 
>> 57:      * @return true - if the factory is allowed to be instantiated; false - otherwise
>> 58:      */
>> 59:     public static boolean checkGlobalFilter(Class<?> serialClass) {
> 
> I think the `serialClass` param should be renamed to `factoryClass` or something like that, since I think the `serialClass` reference comes from serialization/deserialization usage.

The name comes from `ObjectInputFilter.FilterInfo` - it's been renamed from `factoryClass`to make it clear that the supplied lambda fills-in the non-default `ObjectInputFilter.FilterInfo.serialClass()` method.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From bpb at openjdk.org  Thu Oct 13 18:49:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Oct 2022 18:49:01 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v9]
In-Reply-To: <peqHjRD2zqUTKxU_1raX0gwcT0FbgHFulMa85fBCFCc=.8eb4c1ee-dd5a-48d3-be94-c2993d9bc3da@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <peqHjRD2zqUTKxU_1raX0gwcT0FbgHFulMa85fBCFCc=.8eb4c1ee-dd5a-48d3-be94-c2993d9bc3da@github.com>
Message-ID: <RCDIa9G95mobZkkznaiFgx5-uSYvJMMWk_mmDn69s1w=.13f0d023-fdcb-4c54-aac4-98b136da57f3@github.com>

On Fri, 26 Aug 2022 22:20:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - 6478546: Revert use of temporary direct buffers; move parameter checks to Java layer
>  - Merge
>  - 6478546: Eliminate a subtraction from RandomAccessFile.bufferSize()
>  - Merge
>  - 6478546: Miscellaneous cleanup
>  - Merge
>  - Merge
>  - 6478546: Use dynamically sized temporary direct buffers
>  - Merge
>  - Merge
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e9f1800...2532c0b3

Moving to draft.

-------------

PR: https://git.openjdk.org/jdk/pull/8235

From naoto at openjdk.org  Thu Oct 13 18:58:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Oct 2022 18:58:56 GMT
Subject: RFR: 8295173: (tz) Update Timezone Data to 2022e [v2]
In-Reply-To: <7ttKgbE_WY33wQTCW3VvbGui3XVnpks9CynFzx0eNgA=.83c050d8-b63b-4644-a002-3d57c909a24a@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
 <7ttKgbE_WY33wQTCW3VvbGui3XVnpks9CynFzx0eNgA=.83c050d8-b63b-4644-a002-3d57c909a24a@github.com>
Message-ID: <aXyNegN4lK5fulhitXeLfG4sgh90xJlvpVdFvbnQ9vo=.ee1a1b6f-8f64-4686-b203-4ed5c90b58c0@github.com>

On Wed, 12 Oct 2022 04:35:08 GMT, David Alvarez <duke at openjdk.org> wrote:

>> Please, review this PR for an update of timezone data. No changes besides the import were needed.
>
> David Alvarez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update displaynames.txt

Looks good. Thanks for the fix.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10666

From aefimov at openjdk.org  Thu Oct 13 19:23:53 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 19:23:53 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <5WZp2QFcNIapf6FaRhY6JWf3ZBCr930jLAlF-BYmXUg=.accba2c1-84c5-49b4-b978-bc7c320c1b89@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <5WZp2QFcNIapf6FaRhY6JWf3ZBCr930jLAlF-BYmXUg=.accba2c1-84c5-49b4-b978-bc7c320c1b89@github.com>
Message-ID: <c2IMKzhWSsPJBAGb469Fz-TJ7AqwsTD6H0C-bsyioxY=.db536863-cf53-4951-8f4c-7baf531e80b9@github.com>

On Thu, 13 Oct 2022 13:18:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 109:
> 
>> 107:      * @see java.lang.SecurityManager#checkSetFactory
>> 108:      */
>> 109:     public static synchronized void setObjectFactoryBuilder(
> 
> Perhaps remove the `synchronized` from this method and the getter, now that the synchronization has moved to the `NamingManagerHelper` class?

Agreed - I think it is safe to remove `synchronized`. I doubt that there is a code that relies on `synchronized (javax.naming.spi.NamingManager.class)` to prevent other code setting the factory builder (also it can be set only once), therefore it should be ok to remove `synchronized`.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From mullan at openjdk.org  Thu Oct 13 19:31:44 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Oct 2022 19:31:44 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v5]
In-Reply-To: <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>
Message-ID: <gfGORysX8ROdaRi0EHYjQijgnmIrSS3ag7cxrQWK6k8=.3b547c3b-4dcc-47cc-9d33-1af57df7bc92@github.com>

On Thu, 13 Oct 2022 16:06:13 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - test update
>  - Merge branch 'master' into secEvent-8292177
>  - Use stringPropertyNames()
>  - Refactor getter method name
>  - Restore ProtectionDomain to original
>  - Store properties cache in Security class
>  - Remove unused import
>  - Address Oct 10 review comments
>  - Check for 0 security events
>  - Null check on Properties
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3644e26c...3a347dae

Changes requested by mullan (Reviewer).

src/java.base/share/classes/java/security/Security.java line 68:

> 66: 
> 67:     /* cache a copy for recording purposes */
> 68:     static Properties initialSecurityProperties;

This can be `private` now.

src/java.base/share/classes/java/security/Security.java line 184:

> 182:     }
> 183: 
> 184:     static Properties getInitialSecurityProperties() {

Don't think we need this method anymore.

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From aefimov at openjdk.org  Thu Oct 13 19:38:51 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 19:38:51 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>
Message-ID: <sFnmPA7BE8YtR8gegvlv_bmhqL6NTDp3Q6VNu1WbMpA=.a80d42c8-65a0-435e-af89-e0c73b2da44f@github.com>

On Thu, 13 Oct 2022 12:37:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change checkInput to be the global filter centric
>
> src/java.base/share/conf/security/java.security line 1423:
> 
>> 1421: #
>> 1422: # The default pattern value allows any object factory class defined in the java.naming module
>> 1423: # to be specified by the reference instance, but rejects any other.
> 
> Should this instead say:
>> The default pattern value allows any object factory class belonging to the `com.sun.jndi.ldap` and its sub-packages of the `java.naming` module to be specified by the reference instance...?

I would prefer to keep a filter default value explanation sentences simpler since exact default values are listed just one line after.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Thu Oct 13 19:52:09 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 13 Oct 2022 19:52:09 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v4]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <EkFZCfoZecPOqLipwqiQiDzE-81sl1SmTOGA9h8Ke-I=.c401ce02-e88a-4355-a8b6-eb3983ab1da6@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Remove factory builder synchronization from NamingManager. Update comments/docs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/528489b0..53806048

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=02-03

  Stats: 26 lines in 3 files changed: 9 ins; 3 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From coffeys at openjdk.org  Thu Oct 13 19:53:27 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 19:53:27 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v6]
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <kcuxYSNa864tHJgrAiKK28Ky2W_KeyFcEk-aMqIpTiI=.494d9939-ac22-4747-a767-13c9f43d1158@github.com>

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:

 - remove previous edit
 - Use blessed modifier order in EventNames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10394/files
  - new: https://git.openjdk.org/jdk/pull/10394/files/3a347dae..138004ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10394&range=04-05

  Stats: 148 lines in 2 files changed: 0 ins; 4 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/10394.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10394/head:pull/10394

PR: https://git.openjdk.org/jdk/pull/10394

From coffeys at openjdk.org  Thu Oct 13 19:53:31 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 13 Oct 2022 19:53:31 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v5]
In-Reply-To: <gfGORysX8ROdaRi0EHYjQijgnmIrSS3ag7cxrQWK6k8=.3b547c3b-4dcc-47cc-9d33-1af57df7bc92@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <VzGjx4hmH8-cm8fvniAvbtQPKCxYcXzWCdkDIb7Eu8M=.6ce16586-df50-4873-8a93-581a30e5e02a@github.com>
 <gfGORysX8ROdaRi0EHYjQijgnmIrSS3ag7cxrQWK6k8=.3b547c3b-4dcc-47cc-9d33-1af57df7bc92@github.com>
Message-ID: <ThBhW4D3Nb1PKRb2VTXN_UipNBkp7ZzxYSdfkmwP4qE=.adb5be4d-4be7-4f01-9f6e-3b96f67b36dc@github.com>

On Thu, 13 Oct 2022 19:19:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - test update
>>  - Merge branch 'master' into secEvent-8292177
>>  - Use stringPropertyNames()
>>  - Refactor getter method name
>>  - Restore ProtectionDomain to original
>>  - Store properties cache in Security class
>>  - Remove unused import
>>  - Address Oct 10 review comments
>>  - Check for 0 security events
>>  - Null check on Properties
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3644e26c...3a347dae
>
> src/java.base/share/classes/java/security/Security.java line 184:
> 
>> 182:     }
>> 183: 
>> 184:     static Properties getInitialSecurityProperties() {
> 
> Don't think we need this method anymore.

Thanks - did another pass through the edits and caught these.  Patch updated.

[Use blessed modifier order in EventNames]


[remove previous edit]

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From mullan at openjdk.org  Thu Oct 13 20:48:45 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Oct 2022 20:48:45 GMT
Subject: RFR: 8292177: InitialSecurityProperty JFR event [v6]
In-Reply-To: <kcuxYSNa864tHJgrAiKK28Ky2W_KeyFcEk-aMqIpTiI=.494d9939-ac22-4747-a767-13c9f43d1158@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
 <kcuxYSNa864tHJgrAiKK28Ky2W_KeyFcEk-aMqIpTiI=.494d9939-ac22-4747-a767-13c9f43d1158@github.com>
Message-ID: <_Wyi6Cde0JI9dTfKlk6KTxxafSPWLwurYoIxxkQ07mo=.ca0f0473-973f-405b-8db4-42e699115cb2@github.com>

On Thu, 13 Oct 2022 19:53:27 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New JFR event to record state of initial security properties.
>>  
>> Debug output is also now added for these properties via -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove previous edit
>  - Use blessed modifier order in EventNames

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From duke at openjdk.org  Thu Oct 13 20:53:57 2022
From: duke at openjdk.org (David Alvarez)
Date: Thu, 13 Oct 2022 20:53:57 GMT
Subject: Integrated: 8295173: (tz) Update Timezone Data to 2022e
In-Reply-To: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
References: <JTEp-UUQWLODPt4BXwCSCWxZ755xaYvttKzCtKldHx8=.dd0124e4-aa90-47c0-bba7-a8013c25b2e0@github.com>
Message-ID: <fmECM7ctYtz-IY0gWfswOYrecKAzXbROGRYiaiML4-E=.e9e13778-f774-47a4-b68e-16e55aba47f9@github.com>

On Wed, 12 Oct 2022 00:01:50 GMT, David Alvarez <duke at openjdk.org> wrote:

> Please, review this PR for an update of timezone data. No changes besides the import were needed.

This pull request has now been integrated.

Changeset: 21407dec
Author:    David Alvarez <alvdavi at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21407dec0156301871a83328615e4d975c4287c4
Stats:     82 lines in 6 files changed: 22 ins; 14 del; 46 mod

8295173: (tz) Update Timezone Data to 2022e

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/10666

From duke at openjdk.org  Thu Oct 13 21:22:24 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 13 Oct 2022 21:22:24 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a jlink
 image
Message-ID: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>

Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".

Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

-------------

Commit messages:
 - Fixes JDK-8240567

Changes: https://git.openjdk.org/jdk/pull/10704/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8240567
  Stats: 50 lines in 1 file changed: 45 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Thu Oct 13 21:49:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 13 Oct 2022 21:49:23 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder()
In-Reply-To: <lkOBF5TWrSZ2oI639Ak3qKiKHvS9e1JTeCZwlVWmFvE=.cd97b61c-937a-4855-97c8-1e7c7eba0123@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <0k3bK-V3WVOGjeoVQLdqCTL5NjaXcH5paqcR14qs58I=.0c35ac24-b79b-4428-92de-3a3770294939@github.com>
 <lkOBF5TWrSZ2oI639Ak3qKiKHvS9e1JTeCZwlVWmFvE=.cd97b61c-937a-4855-97c8-1e7c7eba0123@github.com>
Message-ID: <wkC8i7MLTpNBlC1us471k1Jd3lwBk1IGpT-RRxEDHMo=.06580ccd-ff2a-4ba1-a28a-3a47b1886649@github.com>

On Sat, 20 Aug 2022 19:17:18 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TreeMap.java line 3318:
>> 
>>> 3316:             // Adapt or create a key-based comparator
>>> 3317:             Comparator<? super K> treeComparator = tree.comparator;
>>> 3318:             return Map.Entry.comparingByKey(treeComparator == null ? natural() : treeComparator);
>> 
>> You can probably have:
>> 
>> return treeComparator == nul ?
>>         Map.Entry.comparingByKey() :
>>         Map.Entry.comparingByKey(treeComparator);
>> 
>> instead.
>
> Nope, there'd be a compilation error

It'll work?fine if?an?unchecked?cast is?used:
Suggestion:

            @SuppressWarnings("unchecked")
            Comparator<Map.Entry<K, V>> entryComparator = treeComparator == null ?
                    (Comparator) Map.Entry.comparingByKey()
                    Map.Entry.comparingByKey(treeComparator);
            return entryComparator;


This?also ensures?that when?`treeComparator` is?`null`, this?method keeps?returning a?constant?lambda.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From iklam at openjdk.org  Thu Oct 13 22:01:54 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 22:01:54 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData
Message-ID: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>

Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.

-------------

Commit messages:
 - 8295302: Do not use ArrayList when LambdaForm has a single ClassData

Changes: https://git.openjdk.org/jdk/pull/10706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295302
  Stats: 32 lines in 1 file changed: 20 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10706.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10706/head:pull/10706

PR: https://git.openjdk.org/jdk/pull/10706

From duke at openjdk.org  Thu Oct 13 22:01:58 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 13 Oct 2022 22:01:58 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup
Message-ID: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>

Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 

Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 

Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

-------------

Commit messages:
 - Adjust template to reduce whitespace
 - Re-add modified BasicDateTime test contents removed by generated template
 - Adjust template to cleanup errors

Changes: https://git.openjdk.org/jdk/pull/10684/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10684&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295000
  Stats: 312 lines in 20 files changed: 205 ins; 6 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/10684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10684/head:pull/10684

PR: https://git.openjdk.org/jdk/pull/10684

From vlivanov at openjdk.org  Thu Oct 13 22:34:44 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 13 Oct 2022 22:34:44 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData
In-Reply-To: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
Message-ID: <sCa9S67Qgci0q7CCDCKiphlfqQtq69zhu7ka0w8PjkM=.77d3b5df-ab2f-49f2-a688-47f0f13979a6@github.com>

On Thu, 13 Oct 2022 21:53:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 321:

> 319:     private MemberName loadMethod(byte[] classFile) {
> 320:         Class<?> invokerClass = LOOKUP.makeHiddenClassDefiner(className, classFile, Set.of())
> 321:                                       .defineClass(true, classDataValues());

Why not just put it in `classDataValues()` instead?


    Object classDataValues() {
        final List<ClassData> cd = classData;
        return switch(cd.size()) {
            case 0 -> null; // flatten for zero case
            case 1 -> cd.get(0).value; // flatten for single value case
            case 2 -> List.of(cd.get(0).value, cd.get(1).value);
            ...


And it also covers zero case for free.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 389:

> 387:         mv.visitMethodInsn(Opcodes.INVOKESTATIC, "java/lang/invoke/MethodHandles",
> 388:                            "classData", "(Ljava/lang/Class;)Ljava/lang/Object;", false);
> 389:         if (classData.size() == 1) {

if (classData.size() < 2) {

It works for zero case, because `checkcast` always succeeds on nulls.

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From jwaters at openjdk.org  Thu Oct 13 23:54:11 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 13 Oct 2022 23:54:11 GMT
Subject: Integrated: 8295017: Remove Windows specific workaround in
 JLI_Snprintf
In-Reply-To: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
References: <iN4qq5TGmyFQcwF-qy9-YFiTjAgvOXi1JthiGQvt9S4=.caa3e9f9-df99-4e83-bcdf-e0012fdeab17@github.com>
Message-ID: <kZz4y2SiMpUa_aFrP8cBTx0wxp80hfewb_o_tIHSUQM=.60b62ac7-a256-4062-9553-fb30c0ec7480@github.com>

On Sun, 9 Oct 2022 08:03:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The C99 snprintf is available with Visual Studio 2015 and above, alongside Windows 10 and the UCRT, and is no longer identical to the outdated Windows _snprintf. Since support for the Visual C++ 2017 compiler was removed a while ago, we can now safely remove the compatibility workaround on Windows and have JLI_Snprintf simply delegate to snprintf.

This pull request has now been integrated.

Changeset: 2b4830a3
Author:    Julian Waters <jwaters at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b4830a3959496372719270614a58737cf4deb2f
Stats:     36 lines in 2 files changed: 2 ins; 34 del; 0 mod

8295017: Remove Windows specific workaround in JLI_Snprintf

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/10625

From bchristi at openjdk.org  Fri Oct 14 00:42:05 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 14 Oct 2022 00:42:05 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>

On Thu, 13 Oct 2022 01:02:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/BasicByteObject.java line 232:

> 230: 
> 231:     private static Byte negate(Byte v) {
> 232:         return (byte) -v.byteValue();

We want to be returning a `Byte`, so casting to `(byte)` doesn't seem right to me.

`Byte.valueOf()` takes a `byte` and returns a `Byte`, so using that as the replacement for `new Byte`, we get:
`return Byte.valueOf(-v.byteValue());`
Is there a way to get the template to do that?

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From duke at openjdk.org  Fri Oct 14 02:22:59 2022
From: duke at openjdk.org (jmehrens)
Date: Fri, 14 Oct 2022 02:22:59 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
Message-ID: <SkCt4Rq9h5SHMoClLu-hk8ZDEMRs4hhLEAyHiNFiqRU=.38b44f51-8dad-4763-b754-ae7dc38572b4@github.com>

On Wed, 12 Oct 2022 13:26:29 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes according to review
>   
>   1. Reduce duplication in tests
>   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>   3. Simplify documentation for shuffle(List, Random) to avoid duplication.

Should this PR be held back by JEP: 431: Sequenced Collections?

Depending on the final API for SequencedCollection I would think it would be possible to shuffle the contents of a sequenced collection (accessed order set) if replaceAll(java.util.function.UnaryOperator) was added from List.  Shuffle could be implemented like the current non-random access branch today but replace the ListIterator logic with replaceAll.

Waiting for that API to settle might save us from having to add another shuffle overload to Collections.  Currently there is a workaround to shuffle with a RandomGenerator by using the wrapper which should remove some of the pressure to get this into a release quickly.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From iklam at openjdk.org  Fri Oct 14 04:37:22 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Oct 2022 04:37:22 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
Message-ID: <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>

> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @iwanowww comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10706/files
  - new: https://git.openjdk.org/jdk/pull/10706/files/793f24ce..5a800f0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10706&range=00-01

  Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10706.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10706/head:pull/10706

PR: https://git.openjdk.org/jdk/pull/10706

From iklam at openjdk.org  Fri Oct 14 04:44:02 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Oct 2022 04:44:02 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <sCa9S67Qgci0q7CCDCKiphlfqQtq69zhu7ka0w8PjkM=.77d3b5df-ab2f-49f2-a688-47f0f13979a6@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <sCa9S67Qgci0q7CCDCKiphlfqQtq69zhu7ka0w8PjkM=.77d3b5df-ab2f-49f2-a688-47f0f13979a6@github.com>
Message-ID: <czuNsd4DMBINjKR16LwYbpq85nN_9NkA6YHT54xfz00=.78d1b34f-859c-4122-9542-641d7631af03@github.com>

On Thu, 13 Oct 2022 22:29:03 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iwanowww comments
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 321:
> 
>> 319:     private MemberName loadMethod(byte[] classFile) {
>> 320:         Class<?> invokerClass = LOOKUP.makeHiddenClassDefiner(className, classFile, Set.of())
>> 321:                                       .defineClass(true, classDataValues());
> 
> Why not just put it in `classDataValues()` instead?
> 
> 
>     Object classDataValues() {
>         final List<ClassData> cd = classData;
>         return switch(cd.size()) {
>             case 0 -> null; // flatten for zero case
>             case 1 -> cd.get(0).value; // flatten for single value case
>             case 2 -> List.of(cd.get(0).value, cd.get(1).value);
>             ...
> 
> 
> And it also covers zero case for free.

I fixed it as you suggested. I also changed the method to private to make sure no one else is using this method.

> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 389:
> 
>> 387:         mv.visitMethodInsn(Opcodes.INVOKESTATIC, "java/lang/invoke/MethodHandles",
>> 388:                            "classData", "(Ljava/lang/Class;)Ljava/lang/Object;", false);
>> 389:         if (classData.size() == 1) {
> 
> if (classData.size() < 2) {
> 
> It works for zero case, because `checkcast` always succeeds on nulls.

Actually the zero case is already handled here:


    static void clinit(ClassWriter cw, String className, List<ClassData> classData) {
        if (classData.isEmpty())
            return;


No `<clinit>` method is generated because we have no static field to initialize.

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From vlivanov at openjdk.org  Fri Oct 14 04:51:03 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 14 Oct 2022 04:51:03 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
Message-ID: <sO5wruQxDHPOyPKsyR6DiVx4BiHeeF1RjDYnL3P6HBU=.88efdf6f-acf4-4e9b-a9cc-46fa5fe8591e@github.com>

On Fri, 14 Oct 2022 04:37:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iwanowww comments

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10706

From jpai at openjdk.org  Fri Oct 14 06:14:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Oct 2022 06:14:02 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <GOnGa913EJP5z4E7wVAu1kIGoFidP-hKqnrD7tQv_Dc=.695e46ef-617a-4406-a76c-629f18d52cc8@github.com>

On Thu, 13 Oct 2022 21:15:16 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Hello Oliver, the GitHub actions job failures appear related to this change. For example:


Error occurred during initialization of boot layer
java.lang.VerifyError: Method does not expect a return value
Exception Details:
  Location:
    jdk/internal/module/SystemModules$default.moduleDescriptorsSub0([Ljava/lang/module/ModuleDescriptor;)V @18441: areturn
  Reason:
    Type 'jdk/internal/module/Builder' (current frame, stack[309]) is not assignable to top (from method signature)
  Current Frame:
    bci: @18441
    flags: { }
    locals: { 'jdk/internal/module/Builder', '[Ljava/lang/module/ModuleDescriptor;', 'java/util/Set', top, 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set', 'java/util/Set' }
    stack: { 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Bui
 lder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder'
 , 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jd
 k/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/int
 ernal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal
 /module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/modu
 le/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Bu
 ilder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder
 ', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'j
 dk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', 'jdk/internal/module/Builder' }
  Bytecode:

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From forax at univ-mlv.fr  Fri Oct 14 08:20:51 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 14 Oct 2022 10:20:51 +0200 (CEST)
Subject: New candidate JEP: 431: Sequenced Collections
In-Reply-To: <20221011231719.86821547E2D@eggemoggin.niobe.net>
References: <20221011231719.86821547E2D@eggemoggin.niobe.net>
Message-ID: <1020834747.25340915.1665735651688.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "mark reinhold" <mark.reinhold at oracle.com>
> To: "Stuart Marks" <stuart.marks at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>, "jdk-dev" <jdk-dev at openjdk.org>
> Sent: Wednesday, October 12, 2022 1:17:20 AM
> Subject: New candidate JEP: 431: Sequenced Collections

> https://openjdk.org/jeps/431
> 
>  Summary: Introduce new interfaces to represent collections with a
>  defined encounter order. Each such collection has a well-defined first
>  element, second element, and so forth, up to the last element. It also
>  provides uniform APIs for accessing its first and last elements, and
>  for processing its elements in reverse order.

People will again think that i'm the grumpy guy but i prefer to voice my concerns.

- nobody cares, i'm back from Devoxx and nobody cares about Sequenced Collections, i've tried to ask several friends what they think about it and the answer was "meh".
  The bar to introduce new interfaces in the collection API is really really high given how the Java ecosystem works.
  Once a library starts to use those interfaces as method parameter, it pressures the other library authors to write methods that provides object typed as those interfaces.
  Not enough people care and the cost for the community (not only Oracle) is high, it looks like a recipe for failure.

- LinkedHashMap can be tweaked in two ways, by passing an access order as 3rd parameter of the constructor or by overriding removeEldesEntry(), in both cases the resulting LinkedHashMap is at odds with the contract of SequencedMap but the compiler will happily allow to see those LinkedHashMap as SequencedMap.

- LinkedHashMap/LinkedHashSet are dinosaurs, there are more efficient implementations of the concepts of ordered set / ordered map both in term of memory footprint and runtime execution, so adding new interfaces without exploring new implementations using Valhalla value class and in relation with the Collection Literal JEP seems premature to me.

> 
> - Mark

R?mi

From duke at openjdk.org  Fri Oct 14 08:53:24 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 14 Oct 2022 08:53:24 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v2]
In-Reply-To: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
Message-ID: <2N8BNMCVcJ9n5AuvRo9nou-R5x5GWgw2vMauqoJVR24=.ec1d9443-4ecb-4267-8cf6-c0aa06921753@github.com>

> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
> 
> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/TreeMap.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9901/files
  - new: https://git.openjdk.org/jdk/pull/9901/files/259348a7..ab4cfa2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9901/head:pull/9901

PR: https://git.openjdk.org/jdk/pull/9901

From duke at openjdk.org  Fri Oct 14 08:57:08 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 14 Oct 2022 08:57:08 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v2]
In-Reply-To: <wkC8i7MLTpNBlC1us471k1Jd3lwBk1IGpT-RRxEDHMo=.06580ccd-ff2a-4ba1-a28a-3a47b1886649@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <0k3bK-V3WVOGjeoVQLdqCTL5NjaXcH5paqcR14qs58I=.0c35ac24-b79b-4428-92de-3a3770294939@github.com>
 <lkOBF5TWrSZ2oI639Ak3qKiKHvS9e1JTeCZwlVWmFvE=.cd97b61c-937a-4855-97c8-1e7c7eba0123@github.com>
 <wkC8i7MLTpNBlC1us471k1Jd3lwBk1IGpT-RRxEDHMo=.06580ccd-ff2a-4ba1-a28a-3a47b1886649@github.com>
Message-ID: <w42Yaj-a_IaM1NtX0McrEfKgVtvvdDOSZdH4HiJ6u1w=.75f4dcd7-e1bc-4001-9e8c-5c2f3178e303@github.com>

On Thu, 13 Oct 2022 21:46:15 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Nope, there'd be a compilation error
>
> It'll work?fine if?an?unchecked?cast is?used:
> Suggestion:
> 
>             @SuppressWarnings("unchecked")
>             Comparator<Map.Entry<K, V>> entryComparator = treeComparator == null ?
>                     (Comparator) Map.Entry.comparingByKey()
>                     Map.Entry.comparingByKey(treeComparator);
>             return entryComparator;
> 
> 
> This?also ensures?that when?`treeComparator` is?`null`, this?method keeps?returning a?constant?lambda.

This one looks fine, accepted.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From mbaesken at openjdk.org  Fri Oct 14 11:25:31 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Oct 2022 11:25:31 GMT
Subject: RFR: JDK-8295325: tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java
 fails on Linux ppc64le
Message-ID: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>

The test tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le because it assumes that vm.jvmci is
available on all platforms but this is currently not the case on Linux ppc64le.
Error is :

Error: Module jdk.internal.vm.ci not found
java.lang.module.FindException: Module jdk.internal.vm.ci not found
at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
at java.base/java.lang.module.Resolver.resolve(Resolver.java:129)
at java.base/java.lang.module.Configuration.resolve(Configuration.java:420)
at java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:551)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:439)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:291)
at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
at tests.Helper.generateDefaultImage(Helper.java:257)
at SaveJlinkArgfilesPluginTest.main(SaveJlinkArgfilesPluginTest.java:66)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
at java.base/java.lang.Thread.run(Thread.java:1591)

-------------

Commit messages:
 - JDK-8295325

Changes: https://git.openjdk.org/jdk/pull/10713/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10713&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295325
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10713.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10713/head:pull/10713

PR: https://git.openjdk.org/jdk/pull/10713

From alanb at openjdk.org  Fri Oct 14 11:31:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Oct 2022 11:31:09 GMT
Subject: RFR: JDK-8295325:
 tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le
In-Reply-To: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
References: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
Message-ID: <4SkPJg4xB4Y60qyJmEJ_GZiPZzYKY16dbL_apt1th4s=.22c34cab-4fc7-441f-b838-c18164fdef6b@github.com>

On Fri, 14 Oct 2022 11:16:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le because it assumes that vm.jvmci is
> available on all platforms but this is currently not the case on Linux ppc64le.
> Error is :
> 
> Error: Module jdk.internal.vm.ci not found
> java.lang.module.FindException: Module jdk.internal.vm.ci not found
> at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
> at java.base/java.lang.module.Resolver.resolve(Resolver.java:129)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:420)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
> at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:551)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:439)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:291)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
> at tests.Helper.generateDefaultImage(Helper.java:257)
> at SaveJlinkArgfilesPluginTest.main(SaveJlinkArgfilesPluginTest.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> at java.base/java.lang.Thread.run(Thread.java:1591)

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10713

From mchhipa at openjdk.org  Fri Oct 14 11:32:06 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 14 Oct 2022 11:32:06 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>

On Mon, 10 Oct 2022 21:39:05 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Changes requested by mchhipa (Committer).

test/jdk/java/security/Policy/Root/Root.java line 48:

> 46:     private static final Path TARGET = Paths.get(ROOT, ".java.policy");
> 47:     public static void main(String[] args) throws Exception {
> 48:         Files.copy(SOURCE, TARGET, StandardCopyOption.REPLACE_EXISTING);

Could you please use the testng framework for initial setup of test.

test/jdk/java/security/Policy/Root/Root.java line 57:

> 55: 
> 56:     private static void test() throws Exception{
> 57:         ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(

No need to create ProceesBuilder if use the testng framework

test/jdk/java/security/Policy/Root/Root.java line 64:

> 62:         OutputAnalyzer output = new OutputAnalyzer(proc);
> 63:         output.stdoutShouldNotBeEmpty();
> 64:         output.shouldContain("Test succeeded");

p.implies() returns boolean value, instead of checking for string "Test succeded", use Assert.assertTrue()

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 31:

> 29:  * @summary Test limited/default_local.policy containing inconsistent entries
> 30:  * @library /test/lib
> 31:  * @run driver InconsistentEntries

Use the testng framework.

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 76:

> 74:         OutputAnalyzer output = new OutputAnalyzer(proc);
> 75:         output.shouldContain("Test completed successfully");
> 76:         System.out.println("Test passed.");

Please use testng framework instead of creating ProcessBuilder

test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 105:

> 103:             } catch (ExceptionInInitializerError e) {
> 104:                 e.printStackTrace();
> 105:                 System.out.println("Test completed successfully");

This test can be rewritten and use @Test(expectedException = ExceptionInInitializerError.class) instead of creating the ProcessBuilder to capture the output.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From duke at openjdk.org  Fri Oct 14 12:11:06 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 14 Oct 2022 12:11:06 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v2]
In-Reply-To: <2N8BNMCVcJ9n5AuvRo9nou-R5x5GWgw2vMauqoJVR24=.ec1d9443-4ecb-4267-8cf6-c0aa06921753@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <2N8BNMCVcJ9n5AuvRo9nou-R5x5GWgw2vMauqoJVR24=.ec1d9443-4ecb-4267-8cf6-c0aa06921753@github.com>
Message-ID: <QCv3D8suq_jvTscqyis56_TkSFK_7rL6jJXw0Wxe2g4=.ae8a854a-4961-4e2d-a79c-b29ae8e14698@github.com>

On Fri, 14 Oct 2022 08:53:24 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
>> 
>> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/TreeMap.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/java/util/TreeMap.java line 3320:

> 3318:             @SuppressWarnings("unchecked")
> 3319:             Comparator<Map.Entry<K, V>> entryComparator = treeComparator == null ?
> 3320:                     (Comparator) Map.Entry.comparingByKey()

Missed?a?colon:
Suggestion:

                    (Comparator) Map.Entry.comparingByKey() :

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From duke at openjdk.org  Fri Oct 14 12:22:16 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 14 Oct 2022 12:22:16 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v2]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <bGRg0k4KaP3mWVrMYPiqU_vMG6fZ6bnxSOFbWwiZmrw=.13502d98-76c5-47e6-acca-ad7961f70dae@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Fix generated RETURN statement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/44c00a65..a19f2fee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From alanb at openjdk.org  Fri Oct 14 12:28:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Oct 2022 12:28:03 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v2]
In-Reply-To: <bGRg0k4KaP3mWVrMYPiqU_vMG6fZ6bnxSOFbWwiZmrw=.13502d98-76c5-47e6-acca-ad7961f70dae@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <bGRg0k4KaP3mWVrMYPiqU_vMG6fZ6bnxSOFbWwiZmrw=.13502d98-76c5-47e6-acca-ad7961f70dae@github.com>
Message-ID: <1W_jcv0KDIhQ6_W6X5ZopaGRtaF_TgNqr32Qy03-Fxs=.f170a839-0dc4-4878-ace6-ad31e8b7c0bc@github.com>

On Fri, 14 Oct 2022 12:22:16 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix generated RETURN statement

This one has been on my list to fix for sometime, it's okay if you take it. Can you look at the tests in test/jdk/tools/jlink, that is where we will need to add the test for this.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From hannesgreule at outlook.de  Fri Oct 14 14:51:28 2022
From: hannesgreule at outlook.de (Hannes Greule)
Date: Fri, 14 Oct 2022 16:51:28 +0200
Subject: Confusing exception message in MethodHandles#tableSwitch
Message-ID: <AM9PR03MB7818E9A78F024879EEF2D6E9AF249@AM9PR03MB7818.eurprd03.prod.outlook.com>

Hi, I hope this is the right mailing list.

I recently fiddled around with MethodHandles#tableSwitch and stumbled 
across a confusing exception message. As a simple example, consider 
following code:

import java.lang.invoke.*;
import static java.lang.invoke.MethodType.*;
import static java.lang.invoke.MethodHandles.*;

class TableSwitch {
         public static void main(String[] args) {
                 MethodHandle defaultCase = zero(int.class);
                 MethodHandle zero = identity(int.class);
                 MethodHandle mh = tableSwitch(defaultCase, zero);
         }
}

Executing it will cause following stacktrace:
Exception in thread "main" java.lang.IllegalArgumentException: Case 
actions must have int as leading parameter: [MethodHandle(int)int]
         at 
java.base/java.lang.invoke.MethodHandles.tableSwitchChecks(MethodHandles.java:7862)
         at 
java.base/java.lang.invoke.MethodHandles.tableSwitch(MethodHandles.java:7850)
         at TableSwitch.main(TableSwitch.java:9)

As you can see, all printed method handles *have* int as leading 
parameter. The actual issue comes from the defaultCase method handle, 
which does not take any arguments. However, it is not part of the error 
message.
Furthermore, this exception is *only* thrown if the defaultCase doesn't 
match (see [1]). If one of the other cases doesn't match, a separate 
exception is thrown.

I suggest to change the exception message to make it more clear that the 
defaultCase has the wrong type.

By the way, the exception message if the targets/caseActions array is 
empty will always print an empty array. While that's not confusing, it 
could probably improved too.

Greetings
Hannes

[1] 
https://github.com/openjdk/jdk/blob/b8b9b97a1a3e07777da2e39ac4779ef7b77434c7/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#L7859

From coffeys at openjdk.org  Fri Oct 14 15:45:23 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Oct 2022 15:45:23 GMT
Subject: RFR: 8292033: Move jdk.X509Certificate event logic to JCA layer
Message-ID: <X_krbxoT0IccqA9Bp0Sa_5TW40V2vGvK3TgZkkPiwS0=.4f60b7eb-00f1-4b88-b0c1-83b718798171@github.com>

By moving the JFR event up to the java.security.cert.CertificateFactory class, we can record all generate cert events, including those from 3rd party providers. I've also altered the logic so that an event is genertate for every generate cert call (not just ones missing from the JDK provider implementation cache)

test case also updated to capture new logic

-------------

Commit messages:
 - restore import style
 - Merge branch 'master' into 8292033-x509Event
 - Minor clean up
 - Merge branch 'master' into 8292033-x509Event
 - update commit method name
 - Record all X509 generate events
 - fix up merge
 - merge with master
 - 8292033

Changes: https://git.openjdk.org/jdk/pull/10422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10422&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292033
  Stats: 121 lines in 6 files changed: 61 ins; 49 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10422.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10422/head:pull/10422

PR: https://git.openjdk.org/jdk/pull/10422

From bhuang at openjdk.org  Fri Oct 14 15:55:43 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 14 Oct 2022 15:55:43 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion
In-Reply-To: <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>
Message-ID: <bmQOg7gqjEWiMVTCEnVY1RUqFeOssuxk8veYu0W67kM=.a68b3625-1649-4c58-8a89-12cc0fdf7ba6@github.com>

On Fri, 14 Oct 2022 11:00:44 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> test/jdk/java/security/Policy/Root/Root.java line 48:
> 
>> 46:     private static final Path TARGET = Paths.get(ROOT, ".java.policy");
>> 47:     public static void main(String[] args) throws Exception {
>> 48:         Files.copy(SOURCE, TARGET, StandardCopyOption.REPLACE_EXISTING);
> 
> Could you please use the testng framework for initial setup of test.

This is a @driver test that copies the Root.policy file to the home directory before running the RootTest in a new JVM. The reason is that upon the start of the new JVM it loads the default system-wide policy file and the default user policy file which is the Root.policy we just copied. With the testng framework, there is no way to load the custom user policy file without reinstalling the security manager in the test, that said, it doesn't match what the manual test does.

> test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 31:
> 
>> 29:  * @summary Test limited/default_local.policy containing inconsistent entries
>> 30:  * @library /test/lib
>> 31:  * @run driver InconsistentEntries
> 
> Use the testng framework.

Same reason as Root.java. The custom policy file needs to place in Java home directory before running the test.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From mdoerr at openjdk.org  Fri Oct 14 15:57:11 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 14 Oct 2022 15:57:11 GMT
Subject: RFR: JDK-8295325:
 tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le
In-Reply-To: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
References: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
Message-ID: <ojDaErV9ed9xbrag6vbwOeytbvX_5gYNsx5rsMRSyKU=.6067e476-a302-4bdb-91c0-7e736c5823a5@github.com>

On Fri, 14 Oct 2022 11:16:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le because it assumes that vm.jvmci is
> available on all platforms but this is currently not the case on Linux ppc64le.
> Error is :
> 
> Error: Module jdk.internal.vm.ci not found
> java.lang.module.FindException: Module jdk.internal.vm.ci not found
> at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
> at java.base/java.lang.module.Resolver.resolve(Resolver.java:129)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:420)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
> at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:551)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:439)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:291)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
> at tests.Helper.generateDefaultImage(Helper.java:257)
> at SaveJlinkArgfilesPluginTest.main(SaveJlinkArgfilesPluginTest.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> at java.base/java.lang.Thread.run(Thread.java:1591)

Thanks for fixing it!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10713

From duke at openjdk.org  Fri Oct 14 16:02:21 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 14 Oct 2022 16:02:21 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v3]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <bxLo6Fbt2R3Im58kC6WPnoYiMTFXRZEuZhhSSSvICgI=.fac86190-dabd-4ba6-99fd-7f9a54a188d8@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Reduce number of included ModuleDescriptors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/a19f2fee..f5a2596c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=01-02

  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From alanb at openjdk.org  Fri Oct 14 16:10:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Oct 2022 16:10:00 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v3]
In-Reply-To: <bxLo6Fbt2R3Im58kC6WPnoYiMTFXRZEuZhhSSSvICgI=.fac86190-dabd-4ba6-99fd-7f9a54a188d8@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <bxLo6Fbt2R3Im58kC6WPnoYiMTFXRZEuZhhSSSvICgI=.fac86190-dabd-4ba6-99fd-7f9a54a188d8@github.com>
Message-ID: <EZbqfiKpgQpULbkiKxCRLSbsJr7tXKMQp6B-Fy06hPs=.f8f10356-110c-48dc-be17-65b25acf97f9@github.com>

On Fri, 14 Oct 2022 16:02:21 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce number of included ModuleDescriptors

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 705:

> 703:             // Here the method is "manually split" based on the heuristics that 99 ModuleDescriptors are smaller than 64kb
> 704:             // The other implementation possibility is to use msplit (https://github.com/cretz/msplit). However, this seemed too much effort.
> 705:             for (int index = 0; index < moduleInfos.size(); index++) {

This comment will need to be cleaned up a bit to remove the reference to the "msplit" project and changed to be more consistent with the existing comments.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From aefimov at openjdk.org  Fri Oct 14 16:19:41 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 14 Oct 2022 16:19:41 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Remove factory builder synchronization from NamingManager. Update comments/docs.
 - Change checkInput to be the global filter centric
 - Refactor checkInput, better reporting for invalid filter patterns
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/53806048..b3849168

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=03-04

  Stats: 15973 lines in 334 files changed: 11307 ins; 2971 del; 1695 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From dfuchs at openjdk.org  Fri Oct 14 16:38:36 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Oct 2022 16:38:36 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
Message-ID: <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>

On Fri, 14 Oct 2022 16:19:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Remove factory builder synchronization from NamingManager. Update comments/docs.
>  - Change checkInput to be the global filter centric
>  - Refactor checkInput, better reporting for invalid filter patterns
>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>  - Additional comments/formatting cleanup.
>  - More tests clean-up. Code/doc comments cleanup.
>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

src/java.base/share/conf/security/java.security line 1388:

> 1386: # are unused.
> 1387: #
> 1388: # Each class name pattern is matched against the factory class name to allow or disallow its

It appears that for those protocols for which there is no specific filter, a factory class will be accepted only if the global filter returns ALLOWED - which contradicts what is written here (where it says that the class is allowed if it's not REJECTED). Is this something that has changed with this fix - or was the documentation wrong before?

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From mchung at openjdk.org  Fri Oct 14 16:40:06 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Oct 2022 16:40:06 GMT
Subject: RFR: JDK-8295325:
 tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le
In-Reply-To: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
References: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
Message-ID: <i1If-78oNrP_xcwX4hBBcw51u2vHH0u6jkxtXqgBeSo=.d73495a5-1155-457d-83f8-5ac675ac46a1@github.com>

On Fri, 14 Oct 2022 11:16:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le because it assumes that vm.jvmci is
> available on all platforms but this is currently not the case on Linux ppc64le.
> Error is :
> 
> Error: Module jdk.internal.vm.ci not found
> java.lang.module.FindException: Module jdk.internal.vm.ci not found
> at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
> at java.base/java.lang.module.Resolver.resolve(Resolver.java:129)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:420)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
> at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:551)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:439)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:291)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
> at tests.Helper.generateDefaultImage(Helper.java:257)
> at SaveJlinkArgfilesPluginTest.main(SaveJlinkArgfilesPluginTest.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> at java.base/java.lang.Thread.run(Thread.java:1591)

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10713

From mchung at openjdk.org  Fri Oct 14 16:59:59 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Oct 2022 16:59:59 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
Message-ID: <rdxUOdPVaJeXVdYLim6friENrR1kKTStSVe29zlWF3k=.922e5a80-fa4c-4891-a784-160def0da92b@github.com>

On Fri, 14 Oct 2022 04:37:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iwanowww comments

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 291:

> 289:         final List<ClassData> cd = classData;
> 290:         return switch(cd.size()) {
> 291:             case 0 -> null;

`List.of()` always returns the same singleton instance and does not cause any object allocation.  I prefer to keep the `classDataValues()` to return `List<Object>`

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From mchung at openjdk.org  Fri Oct 14 17:15:00 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Oct 2022 17:15:00 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <rdxUOdPVaJeXVdYLim6friENrR1kKTStSVe29zlWF3k=.922e5a80-fa4c-4891-a784-160def0da92b@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
 <rdxUOdPVaJeXVdYLim6friENrR1kKTStSVe29zlWF3k=.922e5a80-fa4c-4891-a784-160def0da92b@github.com>
Message-ID: <11q66gbNm_Nn9HZzITVxIJ3uVrh8CTzyJWydly9lIIw=.42c91314-8510-430e-9b17-ea59a8368122@github.com>

On Fri, 14 Oct 2022 16:57:47 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iwanowww comments
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 291:
> 
>> 289:         final List<ClassData> cd = classData;
>> 290:         return switch(cd.size()) {
>> 291:             case 0 -> null;
> 
> `List.of()` always returns the same singleton instance and does not cause any object allocation.  I prefer to keep the `classDataValues()` to return `List<Object>`

Ah, I now see why you have to change the signature because of the single element case.  I made my comment too quickly. 

A couple of suggestions:
Please add a javadoc for this method to describe what this method returns for different cases.   It's better to move this method close to `clinit` as they are tightly coupled.

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From aefimov at openjdk.org  Fri Oct 14 17:30:02 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 14 Oct 2022 17:30:02 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
 <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
Message-ID: <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>

On Fri, 14 Oct 2022 16:35:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Remove factory builder synchronization from NamingManager. Update comments/docs.
>>  - Change checkInput to be the global filter centric
>>  - Refactor checkInput, better reporting for invalid filter patterns
>>  - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
>>  - Additional comments/formatting cleanup.
>>  - More tests clean-up. Code/doc comments cleanup.
>>  - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
>>  - 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation
>
> src/java.base/share/conf/security/java.security line 1388:
> 
>> 1386: # are unused.
>> 1387: #
>> 1388: # Each class name pattern is matched against the factory class name to allow or disallow its
> 
> It appears that for those protocols for which there is no specific filter, a factory class will be accepted only if the global filter returns ALLOWED - which contradicts what is written here (where it says that the class is allowed if it's not REJECTED). Is this something that has changed with this fix - or was the documentation wrong before?

Very good catch Daniel! It is with this fix and I believe the code needs to be change to match what is written for the global filter here:
What we've had before in `checkInput`:

    private static boolean checkInput(FactoryInfo factoryInfo) {
        Status result = GLOBAL.checkInput(factoryInfo);
        return result != Status.REJECTED;

What we have now:

        if (filter == GLOBAL_FILTER) {
            return globalResult == Status.ALLOWED;
        }


I think it needs to be changed to (to match the description for global filter):

        if (filter == GLOBAL_FILTER) {
            return globalResult != Status.REJECTED;
        }

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From rriggs at openjdk.org  Fri Oct 14 17:48:04 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Oct 2022 17:48:04 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
 <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
 <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>
Message-ID: <QS-ou-X1c4It5-vKse8h6YSFZqoYVqwh7I6EdfuRN-0=.b649ffbb-8288-4484-8032-e1c0c627caef@github.com>

On Fri, 14 Oct 2022 17:27:34 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 1388:
>> 
>>> 1386: # are unused.
>>> 1387: #
>>> 1388: # Each class name pattern is matched against the factory class name to allow or disallow its
>> 
>> It appears that for those protocols for which there is no specific filter, a factory class will be accepted only if the global filter returns ALLOWED - which contradicts what is written here (where it says that the class is allowed if it's not REJECTED). Is this something that has changed with this fix - or was the documentation wrong before?
>
> Very good catch Daniel! It is with this fix and I believe the code needs to be change to match what is written for the global filter here:
> What we've had before in `checkInput`:
> 
>     private static boolean checkInput(FactoryInfo factoryInfo) {
>         Status result = GLOBAL.checkInput(factoryInfo);
>         return result != Status.REJECTED;
> 
> What we have now:
> 
>         if (filter == GLOBAL_FILTER) {
>             return globalResult == Status.ALLOWED;
>         }
> 
> 
> I think it needs to be changed to (to match the description for global filter):
> 
>         if (filter == GLOBAL_FILTER) {
>             return globalResult != Status.REJECTED;
>         }

In the general composition of filters, it is preferable that UNDECIDED is treated as REJECTED.
That keeps unintentional holes in a filter from being permissive.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From rriggs at openjdk.org  Fri Oct 14 18:30:38 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Oct 2022 18:30:38 GMT
Subject: RFR: 8295370: Update java.io.ObjectStreamField to use
 Class.descriptorString
Message-ID: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>

The code in ObjectStreamField for constructing type signatures should be replaced by Class.descriptorString(). 
The corresponding change is made in ObjectStreamClass.
There is no change to the contents of the type strings and the existing tests will cover it.

-------------

Commit messages:
 - 8295370: Update java.io.ObjectStreamField to use Class.descriptorString

Changes: https://git.openjdk.org/jdk/pull/10714/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10714&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295370
  Stats: 59 lines in 2 files changed: 0 ins; 53 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10714.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10714/head:pull/10714

PR: https://git.openjdk.org/jdk/pull/10714

From bpb at openjdk.org  Fri Oct 14 18:47:58 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Oct 2022 18:47:58 GMT
Subject: RFR: 8295370: Update java.io.ObjectStreamField to use
 Class.descriptorString
In-Reply-To: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
References: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
Message-ID: <j6ZjhjTifFBh7kVMZrhxT7OUXtN4pbekwLWFda1RyV8=.fbc4f507-3b70-4257-bb3c-5dd41365034d@github.com>

On Fri, 14 Oct 2022 18:23:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The code in ObjectStreamField for constructing type signatures should be replaced by Class.descriptorString(). 
> The corresponding change is made in ObjectStreamClass.
> There is no change to the contents of the type strings and the existing tests will cover it.

Looks good.

-------------

Changes requested by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10714

From duke at openjdk.org  Fri Oct 14 19:03:11 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 14 Oct 2022 19:03:11 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v3]
In-Reply-To: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
Message-ID: <BFu8_BHci1RjqZIPZ1vKD7e0TeVxQutLMQlTUSTJs_4=.5e8e87c0-5b34-464b-a73c-8a09eae11394@github.com>

> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
> 
> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/TreeMap.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9901/files
  - new: https://git.openjdk.org/jdk/pull/9901/files/ab4cfa2c..a55957e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9901/head:pull/9901

PR: https://git.openjdk.org/jdk/pull/9901

From mchung at openjdk.org  Fri Oct 14 19:07:57 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 14 Oct 2022 19:07:57 GMT
Subject: RFR: 8295370: Update java.io.ObjectStreamField to use
 Class.descriptorString
In-Reply-To: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
References: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
Message-ID: <THevFZ81cWLs1gvKoluDfYhuUo9iHyhKfThLvsKVMWM=.2a8af09a-8a07-4576-bcbd-01e6512f0d59@github.com>

On Fri, 14 Oct 2022 18:23:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The code in ObjectStreamField for constructing type signatures should be replaced by Class.descriptorString(). 
> The corresponding change is made in ObjectStreamClass.
> There is no change to the contents of the type strings and the existing tests will cover it.

Looks good.  Glad to see the existing code of constructing the descriptor be replaced with `Class::descriptorString`.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10714

From duke at openjdk.org  Fri Oct 14 19:23:47 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 14 Oct 2022 19:23:47 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v3]
In-Reply-To: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
Message-ID: <MArA0eyZFF8RhZgMQFWE-mYaxjMyGDy-6r-TDKkutlc=.f70d9f83-3da5-4c3e-86be-e831e632e064@github.com>

> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - new approach: print warning in StaticProperty.java
 - Merge branch 'master' into improve-directory-not-existing-error-message
 - add the change for nio and update the code according to the comments
 - new approach
 - change based on the review
 - updating according to the comments
 - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
 - update error message
 - error message for non-existing directory
 - improve error message when file directory does not exist

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9989/files
  - new: https://git.openjdk.org/jdk/pull/9989/files/cacf41d6..abb19138

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9989&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9989&range=01-02

  Stats: 92095 lines in 1709 files changed: 45132 ins; 36514 del; 10449 mod
  Patch: https://git.openjdk.org/jdk/pull/9989.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9989/head:pull/9989

PR: https://git.openjdk.org/jdk/pull/9989

From duke at openjdk.org  Fri Oct 14 19:25:54 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 14 Oct 2022 19:25:54 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
Message-ID: <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>

> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist

Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into improve-directory-not-existing-error-message
 - new approach: print warning in StaticProperty.java
 - Merge branch 'master' into improve-directory-not-existing-error-message
 - add the change for nio and update the code according to the comments
 - new approach
 - change based on the review
 - updating according to the comments
 - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
 - update error message
 - error message for non-existing directory
 - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc

-------------

Changes: https://git.openjdk.org/jdk/pull/9989/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9989&range=03
  Stats: 160 lines in 7 files changed: 147 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9989.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9989/head:pull/9989

PR: https://git.openjdk.org/jdk/pull/9989

From duke at openjdk.org  Fri Oct 14 19:30:53 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 14 Oct 2022 19:30:53 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
Message-ID: <bpyNml24C7lKzQeaQ-w3-StWPlubcLyn-AHd9btx1ng=.cef0f39c-1bad-4cd8-97c6-855ee888ad87@github.com>

On Fri, 14 Oct 2022 19:25:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - new approach: print warning in StaticProperty.java
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - add the change for nio and update the code according to the comments
>  - new approach
>  - change based on the review
>  - updating according to the comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
>  - update error message
>  - error message for non-existing directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc

New approach,
1) Print warning message inside StaticProperty.java when JVM start
2) Remove the print-out inside TempFileHelper.java and File.java
3) Keep one test file as TempDirectoryNotExisting
4) The order of the code was changed in System.java since StaticProperty.java needs "out print-stream" to be initialized before using it to print a warning message.

-------------

PR: https://git.openjdk.org/jdk/pull/9989

From rriggs at openjdk.org  Fri Oct 14 21:03:55 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Oct 2022 21:03:55 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
Message-ID: <m-3cUuCep9y_L23UwE-l4wiN51IqLMWpkXrS1Ba13qQ=.36d4d145-ea91-43f7-a16e-3a139f651df2@github.com>

On Fri, 14 Oct 2022 19:25:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - new approach: print warning in StaticProperty.java
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - add the change for nio and update the code according to the comments
>  - new approach
>  - change based on the review
>  - updating according to the comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
>  - update error message
>  - error message for non-existing directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc

The check for the tmp directory should be delayed until it is the property is used.
If temp files are not used, it only increases startup time without any benefit (usually the directory exists).

Putting the check and printing a warning in the static initialization of Files.TempDirectory will
delay its evaluation until it is needed and the initialization order in System will not need to be changed.
Changing the initialization order is always has some risks.

-------------

PR: https://git.openjdk.org/jdk/pull/9989

From bpb at openjdk.org  Fri Oct 14 22:35:41 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Oct 2022 22:35:41 GMT
Subject: RFR: 8295370: Update java.io.ObjectStreamField to use
 Class.descriptorString
In-Reply-To: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
References: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
Message-ID: <gH4whOL9oPMUef6lssV0wG3OtmL4MtBzKpmUIoVgT2g=.f1f1eb5c-4cfa-4a6a-a55d-b5d3dbede324@github.com>

On Fri, 14 Oct 2022 18:23:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The code in ObjectStreamField for constructing type signatures should be replaced by Class.descriptorString(). 
> The corresponding change is made in ObjectStreamClass.
> There is no change to the contents of the type strings and the existing tests will cover it.

Approved. I hit the wrong radio button before.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10714

From duke at openjdk.org  Fri Oct 14 23:12:38 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 14 Oct 2022 23:12:38 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v4]
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <SLv11AzpJpVp3Ad3y3KJPzkkxZl8KG0U3MXfw0Ds-Pc=.a407245e-f545-4d90-9f75-173431c8c57f@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:

 - Begin to craft test
 - Reduce comment text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10704/files
  - new: https://git.openjdk.org/jdk/pull/10704/files/f5a2596c..7c39bd3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=02-03

  Stats: 66 lines in 2 files changed: 61 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10704.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Fri Oct 14 23:12:40 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 14 Oct 2022 23:12:40 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v2]
In-Reply-To: <1W_jcv0KDIhQ6_W6X5ZopaGRtaF_TgNqr32Qy03-Fxs=.f170a839-0dc4-4878-ace6-ad31e8b7c0bc@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <bGRg0k4KaP3mWVrMYPiqU_vMG6fZ6bnxSOFbWwiZmrw=.13502d98-76c5-47e6-acca-ad7961f70dae@github.com>
 <1W_jcv0KDIhQ6_W6X5ZopaGRtaF_TgNqr32Qy03-Fxs=.f170a839-0dc4-4878-ace6-ad31e8b7c0bc@github.com>
Message-ID: <Tj2G9XnNK-qnRJC40_NpeL3GJxkJ8aLzVNH5rmUzhfs=.350486dd-deb9-4621-b676-7b12138bf9e7@github.com>

On Fri, 14 Oct 2022 12:25:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you look at the tests in test/jdk/tools/jlink, that is where we will need to add the test for this.

I looked and started to create some Java files at [`7c39bd3` (#10704)](https://github.com/openjdk/jdk/pull/10704/commits/7c39bd3ec8251bf6e0c48a9e4842a942b918c8b7). However, it is still very hard to me to figure out which tool to call how (because I am used to "gradle" build magic).

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Fri Oct 14 23:12:43 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 14 Oct 2022 23:12:43 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v3]
In-Reply-To: <EZbqfiKpgQpULbkiKxCRLSbsJr7tXKMQp6B-Fy06hPs=.f8f10356-110c-48dc-be17-65b25acf97f9@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <bxLo6Fbt2R3Im58kC6WPnoYiMTFXRZEuZhhSSSvICgI=.fac86190-dabd-4ba6-99fd-7f9a54a188d8@github.com>
 <EZbqfiKpgQpULbkiKxCRLSbsJr7tXKMQp6B-Fy06hPs=.f8f10356-110c-48dc-be17-65b25acf97f9@github.com>
Message-ID: <QOG38ORcLu3CG8XxFwBW8GpzKO2omz5_HTCySNC9730=.fc42712a-eb0a-4543-ae3b-99c5b8c40afd@github.com>

On Fri, 14 Oct 2022 16:07:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce number of included ModuleDescriptors
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 705:
> 
>> 703:             // Here the method is "manually split" based on the heuristics that 99 ModuleDescriptors are smaller than 64kb
>> 704:             // The other implementation possibility is to use msplit (https://github.com/cretz/msplit). However, this seemed too much effort.
>> 705:             for (int index = 0; index < moduleInfos.size(); index++) {
> 
> This comment will need to be cleaned up a bit to remove the reference to the "msplit" project and changed to be more consistent with the existing comments.

I found the existing comments in the code pretty short. I am belonging to the "architectural decisions group" strengthening the need of listing "options" one choose from. See https://adr.github.io/madr/ for more information.

I will delete the comment.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From rriggs at openjdk.org  Fri Oct 14 23:48:20 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Oct 2022 23:48:20 GMT
Subject: Integrated: 8295370: Update java.io.ObjectStreamField to use
 Class.descriptorString
In-Reply-To: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
References: <Fw7j9C6xMON-K9vVmF86fpZNGgkJPFniRpwnNn1Stig=.40b0e877-a6f9-4305-afde-d434538f2ead@github.com>
Message-ID: <USlUPurrkM8Tidsk2datbCuSFtniPM3AtxF2EK9Za20=.f5929ba4-2e4a-42c7-b5ad-23dd995dee90@github.com>

On Fri, 14 Oct 2022 18:23:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The code in ObjectStreamField for constructing type signatures should be replaced by Class.descriptorString(). 
> The corresponding change is made in ObjectStreamClass.
> There is no change to the contents of the type strings and the existing tests will cover it.

This pull request has now been integrated.

Changeset: 20874247
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2087424736f15a5a80a0492993a6cd74da87188a
Stats:     59 lines in 2 files changed: 0 ins; 53 del; 6 mod

8295370: Update java.io.ObjectStreamField to use Class.descriptorString

Reviewed-by: bpb, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/10714

From jpai at openjdk.org  Sat Oct 15 04:56:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Oct 2022 04:56:26 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v3]
In-Reply-To: <sFnmPA7BE8YtR8gegvlv_bmhqL6NTDp3Q6VNu1WbMpA=.a80d42c8-65a0-435e-af89-e0c73b2da44f@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <OdnZLHZl-X7ag5CXdcjshsfy1t9wJTURs6N1ueCL15M=.10214b6e-fd5e-43a0-bb13-2ef425684d49@github.com>
 <q9JkXzcA7dfVWBN26RN-etlmKQGO6cOTSFJvufMDPXo=.bbc6194a-252e-4ebf-ae68-74d50571e5cd@github.com>
 <sFnmPA7BE8YtR8gegvlv_bmhqL6NTDp3Q6VNu1WbMpA=.a80d42c8-65a0-435e-af89-e0c73b2da44f@github.com>
Message-ID: <j66dCEOlqsAey1w0UDDhpM-C359IEb7T7VHQbCpV3jQ=.c9e93313-3a56-4917-9014-987f242c95c3@github.com>

On Thu, 13 Oct 2022 19:34:52 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 1423:
>> 
>>> 1421: #
>>> 1422: # The default pattern value allows any object factory class defined in the java.naming module
>>> 1423: # to be specified by the reference instance, but rejects any other.
>> 
>> Should this instead say:
>>> The default pattern value allows any object factory class belonging to the `com.sun.jndi.ldap` and its sub-packages of the `java.naming` module to be specified by the reference instance...?
>
> I would prefer to keep a filter default value explanation sentences simpler since exact default values are listed just one line after.

What you have here is OK with me then.

>> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java line 59:
>> 
>>> 57:      * @return true - if the factory is allowed to be instantiated; false - otherwise
>>> 58:      */
>>> 59:     public static boolean checkGlobalFilter(Class<?> serialClass) {
>> 
>> I think the `serialClass` param should be renamed to `factoryClass` or something like that, since I think the `serialClass` reference comes from serialization/deserialization usage.
>
> The name comes from `ObjectInputFilter.FilterInfo` - it's been renamed from `factoryClass`to make it clear that the supplied lambda fills-in the non-default `ObjectInputFilter.FilterInfo.serialClass()` method.

Thank you for that clarification, Aleksei. This sounds fine to me then.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From alanb at openjdk.org  Sat Oct 15 06:15:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Oct 2022 06:15:04 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
Message-ID: <gQhkTzVrFJN4zQJYcLQ0HJ4qoZ5-wLp_EChYNyWjOJ0=.0991f6aa-35ec-42b6-80ec-66a52c58d200@github.com>

On Fri, 14 Oct 2022 19:25:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - new approach: print warning in StaticProperty.java
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - add the change for nio and update the code according to the comments
>  - new approach
>  - change based on the review
>  - updating according to the comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
>  - update error message
>  - error message for non-existing directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc

The changes in the latest patch don't make sense, maybe there is a merge error? From what I can see, I don't think you should be changing initPhase1 or changing StaticProperty.<clint> to print the warning. A possible starting point for this PR would be to focus on the case that java.io.tmpdir is configured on the command line. If it is, then it would be fair game to eagerly check that it is a directory. One candidate place to emit the warning is initPhase3 where you'll see several other warnings. The other case is the user hasn't configured java.io.tmpdir, in which case it will default to /var/tmp (or whatever) is not a directory. Do you really want the JDK to be checking this every time? What happened to the exploration into extending the security property jdk.includeInExceptions?

-------------

PR: https://git.openjdk.org/jdk/pull/9989

From tvaleev at openjdk.org  Sat Oct 15 07:32:59 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sat, 15 Oct 2022 07:32:59 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <SkCt4Rq9h5SHMoClLu-hk8ZDEMRs4hhLEAyHiNFiqRU=.38b44f51-8dad-4763-b754-ae7dc38572b4@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
 <SkCt4Rq9h5SHMoClLu-hk8ZDEMRs4hhLEAyHiNFiqRU=.38b44f51-8dad-4763-b754-ae7dc38572b4@github.com>
Message-ID: <x-vqMXoDYU-d36Ky7YNeeJ0LgAVOt6P5K3mV5UJhkhE=.c623d0b5-68f1-4914-9f39-1ec6b9c6d1bc@github.com>

On Fri, 14 Oct 2022 02:20:43 GMT, jmehrens <duke at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes according to review
>>   
>>   1. Reduce duplication in tests
>>   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>>   3. Simplify documentation for shuffle(List, Random) to avoid duplication.
>
> Should this PR be held back by JEP: 431: Sequenced Collections?
> 
> Depending on the final API for SequencedCollection I would think it would be possible to shuffle the contents of a sequenced collection (accessed order set) if replaceAll(java.util.function.UnaryOperator) was added from List.  Shuffle could be implemented like the current non-random access branch today but replace the ListIterator logic with replaceAll.
> 
> Waiting for that API to settle might save us from having to add another shuffle overload to Collections.  Currently there is a workaround to shuffle with a RandomGenerator by using the wrapper which should remove some of the pressure to get this into a release quickly.

@jmehrens I don't think that `replaceAll` would work nicely with `SequencedCollection`. It will be definitely unsupported for sorted sets. For unsorted sets like `LinkedHashSet`, it's unclear how to behave if `replaceAll` returns identical elements. Throw an exception? Shrink the set size via deduplication? Also, there's no way to optimize the implementation better than clearing the set and inserting the results back, so you need to compute hash codes, distribute items to buckets, probably create tree nodes in case of collisions, etc. It would be simpler if `replaceAll` function was forced to return a permutation (like shuffle does), but it would also limit the usefulness severely.

I don't think that shuffling anything but List has a big value. Usually it's ok to copy into a fresh `ArrayList` and shuffle it instead. You won't get significant performance improvement if LinkedHashSet would be able to shuffle itself in-place. Some improvement for `ArrayDeque` would be possible but again, dumping it into a new `ArrayList` would solve the problem. Note also the proposal to provide a list view from ArrayDeque: https://bugs.openjdk.org/browse/JDK-8143850

To summarize, I have big doubts that generalizing shuffling to `SequencedCollection` interface would be useful.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From coffeys at openjdk.org  Sat Oct 15 09:50:11 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Sat, 15 Oct 2022 09:50:11 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
Message-ID: <GGNvqCrYrRWY841cZ4_U8qaRq6VT8XaUBooG1M44s1w=.f1e4cb9e-fa28-4a6a-8e42-82e091a8f8f6@github.com>

On Fri, 14 Oct 2022 19:25:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - new approach: print warning in StaticProperty.java
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - add the change for nio and update the code according to the comments
>  - new approach
>  - change based on the review
>  - updating according to the comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
>  - update error message
>  - error message for non-existing directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc

Seems like there's a difference of opinion on when such a configuration issue should be reported. Reporting at start up will cost cycles (esp since there's an IO stat call) Maybe we can revert the patch to the original style which is to report the issue at time of tmpFile creation failure. 

The original intent of the bug is to improve the exception message reported to end user for the extremely rare case of when java.io.tmpdir contains a bad value. The current exception is something like:


java.io.IOException: No such file or directory
        at java.io.UnixFileSystem.createFileExclusively(Native Method)

The exception message needs to suggest that the java.io.tmpdir property is a bad one. (no need to even print the directory value IMO)

-------------

PR: https://git.openjdk.org/jdk/pull/9989

From duke at openjdk.org  Sat Oct 15 13:21:01 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 15 Oct 2022 13:21:01 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <4gDW0g0bxn3A0gxS87gr4pbVIirKBTW9pAF9wQYnIEg=.1545cceb-e887-47d1-b337-57ed05742dc0@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

> > Isn't a test needed here which fails without but passes with the proposed change?
> I do not see such a _need_, as this is solely a performance improvement, not a fixed bug or added functionality. If the majority of this team wants to have such a test, then please clearly instruct me to write one. Thanks.

@AlanBateman WDYT? Is such a test mandatory to include this rather simple PR?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From alanb at openjdk.org  Sat Oct 15 14:10:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Oct 2022 14:10:51 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <GGNvqCrYrRWY841cZ4_U8qaRq6VT8XaUBooG1M44s1w=.f1e4cb9e-fa28-4a6a-8e42-82e091a8f8f6@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
 <GGNvqCrYrRWY841cZ4_U8qaRq6VT8XaUBooG1M44s1w=.f1e4cb9e-fa28-4a6a-8e42-82e091a8f8f6@github.com>
Message-ID: <9qI-fqwJ93h7GlSuUcurlmjt13x_PfQtUW8etbLOPz0=.1ae01378-88aa-48fd-9238-feb2bd8c6ed2@github.com>

On Sat, 15 Oct 2022 09:47:52 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Seems like there's a difference of opinion on when such a configuration issue should be reported. Reporting at start up will cost cycles (esp since there's an IO stat call) Maybe we can revert the patch to the original style which is to report the issue at time of tmpFile creation failure.
> 
> The original intent of the bug is to improve the exception message reported to end user for the extremely rare case of when java.io.tmpdir contains a bad value.

I don't think we have any data on how common it change java.io.tmpdir to use a different location but if it rare then it should be okay to check the value eagerly. I think the issue we've had with all iterations of this PR to date is that it doesn't distinguish the case where the configuration is overridden, e.g. the current patch checks the location even when java.io.tmpdir is not changed; I guess this is what Roger is pointing out.

Yes, improving the exception and maybe use of jdk.includeInExceptions was listed as an option in JBS.

-------------

PR: https://git.openjdk.org/jdk/pull/9989

From alanb at openjdk.org  Sat Oct 15 14:44:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Oct 2022 14:44:51 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set
In-Reply-To: <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>
 <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>
Message-ID: <pVFLFEWcUQJSiRZOtV3ogGQrs0ywIRD8_PVwLzemT5Q=.69cd5866-5289-47d1-9d18-3de9fce9e2c9@github.com>

On Mon, 3 Oct 2022 05:50:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think the leak is actually not a problem. `ByteArrayInputStream::transferTo` does the same BTW, see https://github.com/openjdk/jdk/blob/68da02c7b536799ccca49e889c22f3e9a2691fb7/src/java.base/share/classes/java/io/ByteArrayInputStream.java#L206-L211
>> In case the wrapped stream would write into the leaked buffer, that "injected" data would be lost, as no replay can happen due to the `mark == -1`  safety check. So unless we remove that check (which is not planned), such "injected" data is never read.
>> 
>> Regarding the `-1` check: This is fixed in 0aee81f1f3269fa05b9c04ea42343953ad758100. I proposed that change to align it with *all other* checks of `markpos` in the existing source code of BIS. I can undo that change, but following your warning, shouldn't we fix *all other* checks (independent of this PR) from `markpos < 0` to `markpos == -1` then?
>
>> I think the leak is actually not a problem. 
> 
> BAIS is a fixed size. This is different to BIS where it wraps an input stream that may be changing, e.g. create an input stream to a file that is growing and call transferTo several times then you'll see what I mean. We need to mark sure we look at this very closely, that is all I'm saying.
> 
>> Regarding the `-1` check: I did that to align it with _all other_ checks of `markpos` in the existing source code of BIS. I can undo that change, but following your warning, shouldn't we fix _all other_ checks (independent of this PR) from `markpos < 0` to `markpos == -1` then?
> 
> Probably yes.

> @AlanBateman WDYT? Is such a test mandatory to include this rather simple PR?

I think it means checking that test/jdk/java/io/BufferedInputStream/TransferTo.java exercises this code path, I expect it should.

It might seem a "rather simple PR" but it leaks a reference to the internal buffer to the target and we need to get comfortable with that. It only does then when there is no mark (good) so this should mostly limit the concern to sources where EOF may be encountered more than once.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Sat Oct 15 14:44:52 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 15 Oct 2022 14:44:52 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <yVIqDcqOemMLphittaOT0-rRmYY3Q6omSqPBN4KZ3bE=.6751a189-3825-4baf-85df-5e501c81683a@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

So how to go on?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From stuart.marks at oracle.com  Sat Oct 15 22:25:18 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sat, 15 Oct 2022 15:25:18 -0700
Subject: [External] : Re: New candidate JEP: 431: Sequenced Collections
In-Reply-To: <1020834747.25340915.1665735651688.JavaMail.zimbra@u-pem.fr>
References: <20221011231719.86821547E2D@eggemoggin.niobe.net>
 <1020834747.25340915.1665735651688.JavaMail.zimbra@u-pem.fr>
Message-ID: <65da58eb-6d9b-1d3b-50c4-6a5ea9e6aafc@oracle.com>

Hi R?mi,

On 10/14/22 1:20 AM, Remi Forax wrote:
> People will again think that i'm the grumpy guy but i prefer to voice my concerns.
> 
> - nobody cares, i'm back from Devoxx and nobody cares about Sequenced Collections, i've tried to ask several friends what they think about it and the answer was "meh".
>    The bar to introduce new interfaces in the collection API is really really high given how the Java ecosystem works.
>    Once a library starts to use those interfaces as method parameter, it pressures the other library authors to write methods that provides object typed as those interfaces.
>    Not enough people care and the cost for the community (not only Oracle) is high, it looks like a recipe for failure.

Fortunately, we don't make decisions in OpenJDK via opinion polls. :-)

I'm obviously not in a position to address the concerns of your interlocutors. 
However, the history in the bug database and the recurring discussions on 
core-libs-dev (some of which are linked in the JEP) show the need for this.

Introduction of new types always poses a dilemma for library maintainers. They can 
move forward aggressively and embrace new features, or they can remain on older 
releases in order to reach a broader audience. That's not a reason to avoid 
introducing new types.

> - LinkedHashMap can be tweaked in two ways, by passing an access order as 3rd parameter of the constructor or by overriding removeEldesEntry(), in both cases the resulting LinkedHashMap is at odds with the contract of SequencedMap but the compiler will happily allow to see those LinkedHashMap as SequencedMap.

SequencedMap specifies that entries have an encounter order but it doesn't make any 
requirements on how that order is established. LinkedHashMap's access-order mode is 
unusual in that it specifies that specific methods additionally have the side effect 
of reordering the relevant entry. The removeEldestEntry() method modifies the 
behavior of mapping-insertion methods to optionally remove the first ("eldest") 
entry. Neither of these behaviors conflicts with anything in SequencedMap.

> - LinkedHashMap/LinkedHashSet are dinosaurs, there are more efficient implementations of the concepts of ordered set / ordered map both in term of memory footprint and runtime execution, so adding new interfaces without exploring new implementations using Valhalla value class and in relation with the Collection Literal JEP seems premature to me.

LinkedHashMap and LinkedHashSet are in fact used fairly frequently. They're not used 
as much as HashMap, but they're used more than ArrayDeque or TreeMap. Presumably 
this is because people find LinkedHashMap/Set useful and that the overhead compared 
to their non-linked counterparts is acceptable for the additional services they provide.

The performance and footprint of LinkedHashMap/Set are not impacted either way by 
the JEP, nor are any potential future performance improvements (including those that 
might arise because of Valhalla) precluded by the JEP.

s'marks


From alanb at openjdk.org  Sun Oct 16 06:51:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Oct 2022 06:51:59 GMT
Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException
 when a process on Windows returns an exit code of 259
In-Reply-To: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
References: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
Message-ID: <z2l6Uw2uav7Hm_Qofsb9FMWiLaebKXj3FUJgOxujTqU=.d2c8e402-07de-47db-9b68-84cc1ab2e027@github.com>

On Wed, 12 Oct 2022 16:30:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259.
> As described in the bug report, `waitFor()` should not be sensitive to the exit value.
> Previously, it erroneously threw IllegalStateException.
> Added a test to verify.

Marked as reviewed by alanb (Reviewer).

test/jdk/java/lang/ProcessBuilder/WindowsExitValue.java line 46:

> 44:             assertEquals(exitValue, 259);
> 45:         } catch (InterruptedException ie) {
> 46:             org.junit.Assert.fail("InterruptedException not expected");

Not important but I assume you can use fail("...") here, or just drop the try-finally so that the test fails if waitFor throws.

-------------

PR: https://git.openjdk.org/jdk/pull/10680

From jwaters at openjdk.org  Sun Oct 16 08:45:54 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 16 Oct 2022 08:45:54 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
Message-ID: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>

Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

-------------

Commit messages:
 - Commit remaining libraries
 - Merge branch 'openjdk:master' into patch-2
 - Comment change, force link failures to determine libraries to include in make
 - Update WinSysInfo.cpp
 - Update WinFileUtils.cpp
 - Update WinApp.cpp
 - Update MsiUtils.cpp
 - Update MsiDb.cpp
 - Update MsiCA.cpp
 - Update Guid.cpp
 - ... and 12 more: https://git.openjdk.org/jdk/compare/0043d58c...cfa80528

Changes: https://git.openjdk.org/jdk/pull/10633/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295231
  Stats: 35 lines in 14 files changed: 3 ins; 22 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From duke at openjdk.org  Sun Oct 16 09:48:47 2022
From: duke at openjdk.org (ExE Boss)
Date: Sun, 16 Oct 2022 09:48:47 GMT
Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException
 when a process on Windows returns an exit code of 259
In-Reply-To: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
References: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
Message-ID: <z1E99BeoQSvmjalsZf76KQLBYxS42kBdya04hp6Pm48=.a09c9037-d69d-48ea-b64d-8ded7dc68c09@github.com>

On Wed, 12 Oct 2022 16:30:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259.
> As described in the bug report, `waitFor()` should not be sensitive to the exit value.
> Previously, it erroneously threw IllegalStateException.
> Added a test to verify.

test/jdk/java/lang/ProcessBuilder/WindowsExitValue.java line 43:

> 41:         try {
> 42:             Process process = new ProcessBuilder("cmd", "/c", "exit /b 259").start();
> 43:             long exitValue = process.waitFor();

`Process.waitFor()` returns?an?`int`:
Suggestion:

            int exitValue = process.waitFor();

-------------

PR: https://git.openjdk.org/jdk/pull/10680

From jpai at openjdk.org  Sun Oct 16 13:20:14 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Oct 2022 13:20:14 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v4]
In-Reply-To: <SLv11AzpJpVp3Ad3y3KJPzkkxZl8KG0U3MXfw0Ds-Pc=.a407245e-f545-4d90-9f75-173431c8c57f@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <SLv11AzpJpVp3Ad3y3KJPzkkxZl8KG0U3MXfw0Ds-Pc=.a407245e-f545-4d90-9f75-173431c8c57f@github.com>
Message-ID: <25byLAPXRp_zh-gxQH9kerYbCaDunZlcS0ehVJ93nHE=.ed88e83f-8eed-40e3-9ff2-e5b0b252ad00@github.com>

On Fri, 14 Oct 2022 23:12:38 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>
> Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Begin to craft test
>  - Reduce comment text

Hello Oliver,

> However, it is still very hard to me to figure out which tool to call how (because I am used to "gradle" build magic).

Do you mean you are looking for inputs on how to run these tests locally? If so, then the testing guide https://github.com/openjdk/jdk/blob/master/doc/testing.md as well as the jtreg project documentation https://openjdk.org/jtreg/ might help.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From alanb at openjdk.org  Sun Oct 16 13:21:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Oct 2022 13:21:53 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 38:

> 36: 
> 37: #include <Mswsock.h>
> 38: #pragma comment(lib, "Mswsock.lib")

I think this came about with one of the early Microsoft contributions to have transferTo optionally use TransmitFile on Windows. This create the dependency on Mswsock.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jpai at openjdk.org  Sun Oct 16 13:25:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Oct 2022 13:25:01 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v4]
In-Reply-To: <aPNNK94Vi7YNvHRZvUWVnJSmfq0RBnygUEKsOmDk9FA=.3fa2208c-04cd-4da4-919f-36e124f50ca2@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
 <aPNNK94Vi7YNvHRZvUWVnJSmfq0RBnygUEKsOmDk9FA=.3fa2208c-04cd-4da4-919f-36e124f50ca2@github.com>
Message-ID: <MwLwzkDRkqEHXJP5kOcFkupTUKt6n3mA3d5hiXWs4SI=.3f5629f7-6d50-4e34-aa28-1948ef88e158@github.com>

On Wed, 5 Oct 2022 15:24:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Anyone to sponsor, or should I get more approves?

I see that both Alan and Daniel have approved these changes and there hasn't been a commit in this PR, after the approval (which is a good thing). I'll run some internal tests and if all goes well will go ahead and sponsor this change.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From alanb at openjdk.org  Sun Oct 16 16:24:58 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Oct 2022 16:24:58 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image
In-Reply-To: <GOnGa913EJP5z4E7wVAu1kIGoFidP-hKqnrD7tQv_Dc=.695e46ef-617a-4406-a76c-629f18d52cc8@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <GOnGa913EJP5z4E7wVAu1kIGoFidP-hKqnrD7tQv_Dc=.695e46ef-617a-4406-a76c-629f18d52cc8@github.com>
Message-ID: <NxXmUUagk50u3nsp_b3WG9aWHRfZ3ePtxz5khEI_jho=.bd6df532-7f4f-4566-ba1f-ca09a704ad40@github.com>

On Fri, 14 Oct 2022 06:10:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Oliver, the GitHub actions job failures appear related to this change. For example:
> 
> ```
> Error occurred during initialization of boot layer
> java.lang.VerifyError: Method does not expect a return value

I think there are still issues. As a quick test, set the maximum number of descriptors to generate per method to less than 70, so that you get Sub0, Sub1, ... generated. Then try `java -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` to see if the verify is okay with it.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From tvaleev at openjdk.org  Sun Oct 16 19:45:57 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 16 Oct 2022 19:45:57 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v3]
In-Reply-To: <BFu8_BHci1RjqZIPZ1vKD7e0TeVxQutLMQlTUSTJs_4=.5e8e87c0-5b34-464b-a73c-8a09eae11394@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <BFu8_BHci1RjqZIPZ1vKD7e0TeVxQutLMQlTUSTJs_4=.5e8e87c0-5b34-464b-a73c-8a09eae11394@github.com>
Message-ID: <KvkRBnUkErtMZSyJcyDVHyqlHaXIZYc27qebTWS_zu8=.f27acbba-2c7b-433c-b23b-866b5a7160be@github.com>

On Fri, 14 Oct 2022 19:03:11 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
>> 
>> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/TreeMap.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

I saw this code many times and always thought that it exists for performance purposes, to avoid extra indirection via likely megamorphic naturalOrder comparator which will slow down the operations on common path. I think such a simplification could be accepted only if accompanied by a properly written benchmark (which actually emulates megamorphic callsite) which shows no performance regression.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From dholmes at openjdk.org  Mon Oct 17 02:42:48 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Oct 2022 02:42:48 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <bcCMkRFyhoaqWFr-bpraFJLPnv9jB1ozA700K_-JLZ8=.f5a0047d-7674-4b17-8eae-28b72ed4d816@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

I don't agree with the justification here. This seems very windows specific but I like the idea that the source code tracks its own library dependencies. If I am writing some windows code that uses a particular Windows API which in turn requires a specific windows library, then these pragma comments seem an ideal way to express that dependency. This has the advantage that (a) the developer doesn't require detailed knowledge of the build system to make things work; and (b) there is more chance that if the code is later removed then removing the linking of the library will not get overlooked.

YMMV.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jpai at openjdk.org  Mon Oct 17 04:42:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Oct 2022 04:42:02 GMT
Subject: RFR: 8292698: Improve performance of DataInputStream [v4]
In-Reply-To: <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
 <8Rm-eVp7g0Z5PojiU5DwSU2Cuej9zlFtDdKBkUljazo=.0a1c4182-3ade-4da4-b235-f7412bee3140@github.com>
Message-ID: <fExfIov59yL0620CHGBSinVTkfW5ClkyiwSk7p5OrLw=.94988a18-1793-43ff-9fc8-3c8756998244@github.com>

On Mon, 29 Aug 2022 08:46:20 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
>> 
>> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
>> 
>> public final int readInt() throws IOException {
>>     int ch1 = in.read();
>>     int ch2 = in.read();
>>     int ch3 = in.read();
>>     int ch4 = in.read();
>>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>>         throw new EOFException();
>>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
>> }
>> 
>> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
>> 
>> Benchmarking:
>> 
>> baseline:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
>> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
>> 
>> patch:
>> 
>> Benchmark                     Mode  Cnt   Score   Error  Units
>> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
>> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8292698: Reuse existing code
>  - Merge branch 'master' into 8292698
>  - 8292698: Fix copyright year
>  - 8292698: Revert dubious changes
>  - 8292698: Improve performance of reading from DataInputStream

The tier1, tier2, tier3 and the relevant JCK tests completed without any failures.

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From duke at openjdk.org  Mon Oct 17 04:45:02 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 17 Oct 2022 04:45:02 GMT
Subject: Integrated: 8292698: Improve performance of DataInputStream
In-Reply-To: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
References: <MXdBQj8qYqvvImT-MaBpf8mAm3b1tbNiPS93syrjfqg=.3ebdd952-f9d7-4ec9-9655-a63829828c67@github.com>
Message-ID: <ySGb73zQpXPeQOBqzujnW8AFhP13jiIRdpO0jkweQm8=.fa5b695f-49b4-4e85-a403-7501d5baed12@github.com>

On Sun, 21 Aug 2022 06:29:43 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> I found out that reading from `DataInputStream` wrapping `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream` relying on `byte[]`) can be significantly improved by accessing volatile `in` field only once per operation.
> 
> Current implementation does it for each call of `in.read()`, i.e. in `readInt()` method we do it 4 times:
> 
> public final int readInt() throws IOException {
>     int ch1 = in.read();
>     int ch2 = in.read();
>     int ch3 = in.read();
>     int ch4 = in.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>         throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> Apparently accessing volatile reference with underlying `byte[]` prevents runtime from doing some optimizations, so dereferencing local variable should be more efficient.
> 
> Benchmarking:
> 
> baseline:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  22,889 ? 0,648  us/op
> DataInputStreamTest.readInt   avgt   20  21,804 ? 0,197  us/op
> 
> patch:
> 
> Benchmark                     Mode  Cnt   Score   Error  Units
> DataInputStreamTest.readChar  avgt   20  11,018 ? 0,089  us/op
> DataInputStreamTest.readInt   avgt   20   5,608 ? 0,087  us/op

This pull request has now been integrated.

Changeset: 74a51ccc
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74a51ccc86525eb4b1eb2e5cb11e605ca9e9fc5d
Stats:     98 lines in 2 files changed: 71 ins; 14 del; 13 mod

8292698: Improve performance of DataInputStream

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/9956

From jpai at openjdk.org  Mon Oct 17 05:37:58 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Oct 2022 05:37:58 GMT
Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException
 when a process on Windows returns an exit code of 259
In-Reply-To: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
References: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
Message-ID: <0_am-saXObb265WTtDbQv4GmUGWAGSZu9AJjxPcIm8I=.77acc48f-a9e8-4e57-8d96-4895ece122ae@github.com>

On Wed, 12 Oct 2022 16:30:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259.
> As described in the bug report, `waitFor()` should not be sensitive to the exit value.
> Previously, it erroneously threw IllegalStateException.
> Added a test to verify.

Hello Roger,

The `Process.waitFor()` documentation states:
>
>Causes the current thread to wait, if necessary, until the process represented by this {@code Process} object has terminated.

So the implementation is expected to wait until the process has terminated. The Windows implementation of `waitFor` calls the JNI function `waitForInterruptibly`. The JNI implementation of `waitForInterruptibly` is:


HANDLE events[2];
events[0] = (HANDLE) handle;
events[1] = JVM_GetThreadInterruptEvent();

if (WaitForMultipleObjects(sizeof(events)/sizeof(events[0]), events,
                          FALSE,    /* Wait for ANY event */
                          INFINITE)  /* Wait forever */
   == WAIT_FAILED)
   win32Error(env, L"WaitForMultipleObjects");

So it calls a Windows native function called `WaitForMultipleObjects` and passes it 2 handles to wait on - one is the process handle and another for thread interrupt event. `FALSE` is passed as the `bWaitAll` param, which effectively means wait for either the process exit or the thread interrupt event.

The documentation of this Windows native API `WaitForMultipleObjects` states https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects:
>
>If bWaitAll is FALSE, the return value minus WAIT_OBJECT_0 indicates the lpHandles array index of the object that satisfied the wait. If more than one object became signaled during the call, this is the array index of the signaled object with the smallest index value of all the signaled objects.

In our JNI implementation of `waitForInterruptibly` we appear to only check for the `WAIT_FAILED` but don't seem to check which handle satisfied the wait. Do you think it's possible that the process didn't yet terminate and instead the thread interrupt event was signalled? Should this `waitForInterruptibly` do those additional checks?
Does that perhaps explain why a subsequent call to Windows native `GetExitCodeProcess` function returns `STILL_ACTIVE` (the 259 exit code) which as per that functions documentation states https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getexitcodeprocess
>
>If the process has not terminated and the function succeeds, the status returned is STILL_ACTIVE

-------------

PR: https://git.openjdk.org/jdk/pull/10680

From stuefe at openjdk.org  Mon Oct 17 06:08:04 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 06:08:04 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <fqolzndii_HWLbTdOthl88tMEu7oWcPrrze74rHVQlY=.07f4b867-564f-4758-a665-b209b1cfa979@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

I like this change. I am pretty sure not many know about this feature at all, we don't have that many knowledgeable Windows developers. If the methods are equivalent, I prefer linking via make file.

Pinging @magicus, maybe he can chime in.

Cheers, Thomas

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jpai at openjdk.org  Mon Oct 17 06:41:04 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Oct 2022 06:41:04 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v4]
In-Reply-To: <SLv11AzpJpVp3Ad3y3KJPzkkxZl8KG0U3MXfw0Ds-Pc=.a407245e-f545-4d90-9f75-173431c8c57f@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <SLv11AzpJpVp3Ad3y3KJPzkkxZl8KG0U3MXfw0Ds-Pc=.a407245e-f545-4d90-9f75-173431c8c57f@github.com>
Message-ID: <-oEpL9-Qhz8Xwo_k5PToegXaPbHx6CNfv9P-00Lc7kI=.f3b51086-f64f-473a-baa1-090875e4120e@github.com>

On Fri, 14 Oct 2022 23:12:38 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>
> Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Begin to craft test
>  - Reduce comment text

Looking at the existing code (without the proposed changes in this PR), it appears that it's not just the number of `moduleInfos` that could impact the method size but even details like `requires`, `exports`, `opens` and other such details, since we loop over each of these details to construct the method body.

So would it be correct to say that even if this PR proposes to use a limit like 99 to split it into multiple methods, it's still possible that the method size limit could be hit with a much lower number of `moduleInfos` (perhaps even 10?) if any of the other details of any of those `moduleInfo`s is a large number?

Is that something that should be considered/addressed as part of this change?

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From mbaesken at openjdk.org  Mon Oct 17 06:55:14 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Oct 2022 06:55:14 GMT
Subject: RFR: JDK-8295325:
 tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le
In-Reply-To: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
References: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
Message-ID: <zDbYvXBDNZiglUTeuzldZe4HN8kyVxo97PeECAM82fk=.01c418c4-e37f-43a8-91b6-da151d3b9069@github.com>

On Fri, 14 Oct 2022 11:16:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le because it assumes that vm.jvmci is
> available on all platforms but this is currently not the case on Linux ppc64le.
> Error is :
> 
> Error: Module jdk.internal.vm.ci not found
> java.lang.module.FindException: Module jdk.internal.vm.ci not found
> at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
> at java.base/java.lang.module.Resolver.resolve(Resolver.java:129)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:420)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
> at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:551)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:439)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:291)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
> at tests.Helper.generateDefaultImage(Helper.java:257)
> at SaveJlinkArgfilesPluginTest.main(SaveJlinkArgfilesPluginTest.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> at java.base/java.lang.Thread.run(Thread.java:1591)

Hi Mandy, Martin, Alan - thanks for the reviews !

-------------

PR: https://git.openjdk.org/jdk/pull/10713

From alanb at openjdk.org  Mon Oct 17 06:56:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Oct 2022 06:56:05 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v4]
In-Reply-To: <-oEpL9-Qhz8Xwo_k5PToegXaPbHx6CNfv9P-00Lc7kI=.f3b51086-f64f-473a-baa1-090875e4120e@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <SLv11AzpJpVp3Ad3y3KJPzkkxZl8KG0U3MXfw0Ds-Pc=.a407245e-f545-4d90-9f75-173431c8c57f@github.com>
 <-oEpL9-Qhz8Xwo_k5PToegXaPbHx6CNfv9P-00Lc7kI=.f3b51086-f64f-473a-baa1-090875e4120e@github.com>
Message-ID: <aCV7bFDtElc_47KBPVfz4SemTnEXfPe_-uwoZorKoW0=.00cf42fc-76f1-48fc-9273-e1d75caf5589@github.com>

On Mon, 17 Oct 2022 06:37:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Looking at the existing code (without the proposed changes in this PR), it appears that it's not just the number of `moduleInfos` that could impact the method size but even details like `requires`, `exports`, `opens` and other such details, since we loop over each of these details to construct the method body.

That's right and we may have to do further work in the future to avoid generating methods larger than 64k. The approach taken in this PR is okay for now but the current patch needs a bit more work to generate correct code.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From mbaesken at openjdk.org  Mon Oct 17 06:56:44 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Oct 2022 06:56:44 GMT
Subject: Integrated: JDK-8295325:
 tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le
In-Reply-To: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
References: <v5W2OrD-tVHe89r9woVkDHTdStjsGwt7h8WvR_6YXm8=.a37b8146-3b31-4697-a28c-8e7bc8b3a62b@github.com>
Message-ID: <cAyVO7PGr91YLOp396XlMBHQL3C83G0KlfTrtTMF2_Y=.769a40a7-5a8e-4296-9ac6-596c673da64a@github.com>

On Fri, 14 Oct 2022 11:16:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le because it assumes that vm.jvmci is
> available on all platforms but this is currently not the case on Linux ppc64le.
> Error is :
> 
> Error: Module jdk.internal.vm.ci not found
> java.lang.module.FindException: Module jdk.internal.vm.ci not found
> at java.base/java.lang.module.Resolver.findFail(Resolver.java:892)
> at java.base/java.lang.module.Resolver.resolve(Resolver.java:129)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:420)
> at java.base/java.lang.module.Configuration.resolve(Configuration.java:254)
> at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:217)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:551)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:439)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:291)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
> at tests.Helper.generateDefaultImage(Helper.java:257)
> at SaveJlinkArgfilesPluginTest.main(SaveJlinkArgfilesPluginTest.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> at java.base/java.lang.Thread.run(Thread.java:1591)

This pull request has now been integrated.

Changeset: b3bb3e6e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3bb3e6ed89f3abcaae584fcbe75688141e886cb
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8295325: tools/jlink/plugins/SaveJlinkArgfilesPluginTest.java fails on Linux ppc64le

Reviewed-by: alanb, mdoerr, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/10713

From mike at hydraulic.software  Mon Oct 17 08:26:09 2022
From: mike at hydraulic.software (Mike Hearn)
Date: Mon, 17 Oct 2022 10:26:09 +0200
Subject: zlib upgrade due?
Message-ID: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>

For some time now we've been chasing a very rare data corruption bug in
java.util.zip.Inflater that we think must be a bug in the bundled native
zlib. It gets detected by the CRC32 checks and so surfaces as a failure to
inflate. We believe this because:

1. It only seems to happen on ARM Macs (though we haven't tested on ARM
Linux). We have never seen it on Intel.

2. We have seen it with Apache Commons Compress, which has its own gzip
stream code but which still uses the JDK's inflate.

3. It appears to be a thread safety issue, in that to make it show up we
have to inflate data on many threads simultaneously. We reviewed all the
Java code.

4. This year there have been a run of updates to zlib to fix memory safety
errors of various kinds. There was a security fix that showed up in the JDK
very recently (not sure where it came from), but more generally, there was
a new zlib release in March with a bunch of fixes like "Avoid an undefined
behavior of memcpy" and this weekend news broke of several other security
bugs in zlib.

5. NodeJS users have reported a very similar sounding set of bugs again
that seem specific to ARM Mac:
https://stackoverflow.com/questions/69793334/z-data-error-errno-3-zlib-incorrect-data-check-mba-m1

All this points to zlib containing some latent bug that ARM exposes.

We're thinking of building a custom JDK with an upgraded zlib, but it
occurred that this should probably happen upstream anyway for the security
and bugfix issues alone. Is anyone planning to upgrade zlib anytime soon?
I'd rather backport an upstream fix to our local fork of the JDK than do
the upgrade myself.

Alternatively, well, this rash of bugs in relatively old code seems like
the sort of thing Java was intended to fix. Maybe these days with Panama
vectors and Valhalla it'd be possible to make a performance competitive
zlib implementation? I know those features aren't launched yet but maybe
it'd be a good test case for them once merged in.

thanks,
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221017/ceae2204/attachment.htm>

From jai.forums2013 at gmail.com  Mon Oct 17 08:31:33 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 17 Oct 2022 14:01:33 +0530
Subject: zlib upgrade due?
In-Reply-To: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
References: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
Message-ID: <625c79d4-0b3c-a6e1-dd74-5ca1c9fd707f@gmail.com>

Hello Mike,

On 17/10/22 1:56 pm, Mike Hearn wrote:
> For some time now we've been chasing a very rare data corruption bug 
> in java.util.zip.Inflater that we think must be a bug in the bundled 
> native zlib.

When you say "bundled native zlib", do you mean the zlib is bundled 
within the JDK distribution and that reproduces this issue? Or do you 
mean the zlib that is shipped in ARM macos? For the latter, the JDK team 
has noticed this issue too and there's a JBS to track it 
https://bugs.openjdk.org/browse/JDK-8282954 and an Apple bug has been 
filed too (linked in a comment in that JBS issue), although we haven't 
seen a response to that yet.

FWIW, our experiments have reproduced this issue even in a single 
threaded application.

-Jaikiran


From Alan.Bateman at oracle.com  Mon Oct 17 08:48:58 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Oct 2022 09:48:58 +0100
Subject: zlib upgrade due?
In-Reply-To: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
References: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
Message-ID: <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>



On 17/10/2022 10:26, Mike Hearn wrote:
> For some time now we've been chasing a very rare data corruption bug 
> in java.util.zip.Inflater that we think must be a bug in the bundled 
> native zlib. It gets detected by the CRC32 checks and so surfaces as a 
> failure to inflate. We believe this because:
>
> 1. It only seems to happen on ARM Macs (though we haven't tested on 
> ARM Linux). We have never seen it on Intel.
>
It would be useful if you could say which JDK releases you see this. As 
Jai linked to, the JDK is temporarily working around an issue with libz 
on macOS aarch64 since JDK 19 by using bundling a build of in-tree code. 
So it would be interesting to know if these reports include JDK 19 or 
are only older releases.

-Alan

From volker.simonis at gmail.com  Mon Oct 17 08:54:06 2022
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 17 Oct 2022 10:54:06 +0200
Subject: zlib upgrade due?
In-Reply-To: <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>
References: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
 <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>
Message-ID: <CA+3eh11bU6PgqBFuwqtX8=WDnSXv73XETVvjD45vq7qLySivZw@mail.gmail.com>

I can't find a link to the bug that has been filed with Apple in the
issue https://bugs.openjdk.org/browse/JDK-8282954.

Can somebody please post the link to corresponding Apple issue here
and/or update JDK-8282954 with that information?

Thanks,
Volker

On Mon, Oct 17, 2022 at 10:49 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>
>
> On 17/10/2022 10:26, Mike Hearn wrote:
> > For some time now we've been chasing a very rare data corruption bug
> > in java.util.zip.Inflater that we think must be a bug in the bundled
> > native zlib. It gets detected by the CRC32 checks and so surfaces as a
> > failure to inflate. We believe this because:
> >
> > 1. It only seems to happen on ARM Macs (though we haven't tested on
> > ARM Linux). We have never seen it on Intel.
> >
> It would be useful if you could say which JDK releases you see this. As
> Jai linked to, the JDK is temporarily working around an issue with libz
> on macOS aarch64 since JDK 19 by using bundling a build of in-tree code.
> So it would be interesting to know if these reports include JDK 19 or
> are only older releases.
>
> -Alan

From mike at hydraulic.software  Mon Oct 17 08:55:36 2022
From: mike at hydraulic.software (Mike Hearn)
Date: Mon, 17 Oct 2022 10:55:36 +0200
Subject: zlib upgrade due?
In-Reply-To: <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>
References: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
 <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>
Message-ID: <CAGv+2bNr5LDBQF+eD2hB-JyQCn8B4hWswvAmH9MskuT+vu_L_Q@mail.gmail.com>

Yes, sorry about that. This is with JDK17.  I looked at the bundled zlib
before posting and saw it hadn't been upgraded recently, so thought the
issue wasn't known, but wasn't aware that the bundled zlib was dead on
macOS ARM.

Jai's investigation is superb and matches what we see almost exactly (our
test does use threading, but this must be a red herring). So I think we
will consider the immediate issue resolved once we backport the fix to use
the bundled zlib. That said, we'll keep an eye out for a zlib upgrade
anyway for the new security issues that triggered last week's release.


On Mon, 17 Oct 2022 at 10:52, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>
>
> On 17/10/2022 10:26, Mike Hearn wrote:
> > For some time now we've been chasing a very rare data corruption bug
> > in java.util.zip.Inflater that we think must be a bug in the bundled
> > native zlib. It gets detected by the CRC32 checks and so surfaces as a
> > failure to inflate. We believe this because:
> >
> > 1. It only seems to happen on ARM Macs (though we haven't tested on
> > ARM Linux). We have never seen it on Intel.
> >
> It would be useful if you could say which JDK releases you see this. As
> Jai linked to, the JDK is temporarily working around an issue with libz
> on macOS aarch64 since JDK 19 by using bundling a build of in-tree code.
> So it would be interesting to know if these reports include JDK 19 or
> are only older releases.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221017/3724e7cc/attachment.htm>

From jai.forums2013 at gmail.com  Mon Oct 17 09:09:51 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 17 Oct 2022 14:39:51 +0530
Subject: zlib upgrade due?
In-Reply-To: <CA+3eh11bU6PgqBFuwqtX8=WDnSXv73XETVvjD45vq7qLySivZw@mail.gmail.com>
References: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
 <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>
 <CA+3eh11bU6PgqBFuwqtX8=WDnSXv73XETVvjD45vq7qLySivZw@mail.gmail.com>
Message-ID: <b5ecad7f-209d-7ae0-fbf1-ee3258224996@gmail.com>

Hello Volker,

I've now commented on that JBS issue with the Apple bug id - it's FB9997771.

-Jaikiran

On 17/10/22 2:24 pm, Volker Simonis wrote:
> I can't find a link to the bug that has been filed with Apple in the
> issue https://bugs.openjdk.org/browse/JDK-8282954.
>
> Can somebody please post the link to corresponding Apple issue here
> and/or update JDK-8282954 with that information?
>
> Thanks,
> Volker
>
> On Mon, Oct 17, 2022 at 10:49 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>>
>> On 17/10/2022 10:26, Mike Hearn wrote:
>>> For some time now we've been chasing a very rare data corruption bug
>>> in java.util.zip.Inflater that we think must be a bug in the bundled
>>> native zlib. It gets detected by the CRC32 checks and so surfaces as a
>>> failure to inflate. We believe this because:
>>>
>>> 1. It only seems to happen on ARM Macs (though we haven't tested on
>>> ARM Linux). We have never seen it on Intel.
>>>
>> It would be useful if you could say which JDK releases you see this. As
>> Jai linked to, the JDK is temporarily working around an issue with libz
>> on macOS aarch64 since JDK 19 by using bundling a build of in-tree code.
>> So it would be interesting to know if these reports include JDK 19 or
>> are only older releases.
>>
>> -Alan

From ihse at openjdk.org  Mon Oct 17 09:27:10 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 17 Oct 2022 09:27:10 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Marked as reviewed by ihse (Reviewer).

Wow. I did not even know this was possible. Thank you for fixing this! I would have been mighty surprised if I were to learn that a library has more dependencies than the one in the makefile.

@dholmes-ora The point is that we need to be consistent. If we would go that route, then *all* libraries should be loaded by pragmas. That could of course be an alternative, but I really see no upside to it. To do it like we currently do, load 99% of the libraries via make files, and then have few scattered pragmas, that's just bad.

@TheShermanTanker Question: is this a Windows-specific thing, or are there pragma-loaded libraries for other compilers as well?

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From duke at openjdk.org  Mon Oct 17 09:40:03 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 17 Oct 2022 09:40:03 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v3]
In-Reply-To: <KvkRBnUkErtMZSyJcyDVHyqlHaXIZYc27qebTWS_zu8=.f27acbba-2c7b-433c-b23b-866b5a7160be@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <BFu8_BHci1RjqZIPZ1vKD7e0TeVxQutLMQlTUSTJs_4=.5e8e87c0-5b34-464b-a73c-8a09eae11394@github.com>
 <KvkRBnUkErtMZSyJcyDVHyqlHaXIZYc27qebTWS_zu8=.f27acbba-2c7b-433c-b23b-866b5a7160be@github.com>
Message-ID: <Yk7v-FgZQn1ugOg8NTvrolE0MEJ8WloQp1mhzrp5YYE=.daba7f97-4308-4ca8-81af-8303006cb38f@github.com>

On Sun, 16 Oct 2022 19:43:54 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/util/TreeMap.java
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> I saw this code many times and always thought that it exists for performance purposes, to avoid extra indirection via likely megamorphic naturalOrder comparator which will slow down the operations on common path. I think such a simplification could be accepted only if accompanied by a properly written benchmark (which actually emulates megamorphic callsite) which shows no performance regression.

@amaembo you mean we should have a benchmark measuring a `TreeMap.get()` with lots of implementations of Comparators or Comparables?

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From duke at openjdk.org  Mon Oct 17 10:19:26 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 17 Oct 2022 10:19:26 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v4]
In-Reply-To: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
Message-ID: <IBXajKeImw6Gp47glepoN4QfDgV3hj3FQepZWCin0rI=.df4e490c-d87f-46a0-9343-7ebfb6da2708@github.com>

> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
> 
> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8293630: Inline natural()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9901/files
  - new: https://git.openjdk.org/jdk/pull/9901/files/a55957e9..ae6e2320

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9901&range=02-03

  Stats: 8 lines in 1 file changed: 2 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9901/head:pull/9901

PR: https://git.openjdk.org/jdk/pull/9901

From rkennke at openjdk.org  Mon Oct 17 10:51:02 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 17 Oct 2022 10:51:02 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <4gDW0g0bxn3A0gxS87gr4pbVIirKBTW9pAF9wQYnIEg=.1545cceb-e887-47d1-b337-57ed05742dc0@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <4gDW0g0bxn3A0gxS87gr4pbVIirKBTW9pAF9wQYnIEg=.1545cceb-e887-47d1-b337-57ed05742dc0@github.com>
Message-ID: <Z8zSoNXDNAYdACTAE6rthrnyIwmNR_UXpsWmzJYKxg8=.0eceea7f-6800-40ef-a064-97da4a29b00e@github.com>

On Sat, 15 Oct 2022 13:17:27 GMT, Markus KARG <duke at openjdk.org> wrote:

> Isn't a test needed here which fails without but passes with the proposed change?

If you are saying, that a test should verify that, e.g. the wrapped OS receives the buffer upon calling BIS.transferTo() under certain circumstances, then no, I don't think such a test is useful, because that is an implementation detail. What should be tested is if BIS.transferTo() works correctly according to its contract, under all conceivable/possible/interesting conditions. If such a test already exists and exercises the changed code and verifies that it is still correct, then it should be ok IMO (and maybe mention in the PR which tests that would be), otherwise it would be useful to write and add such tests (either to this PR or to a preceding PR).

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From volker.simonis at gmail.com  Mon Oct 17 11:02:25 2022
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 17 Oct 2022 13:02:25 +0200
Subject: zlib upgrade due?
In-Reply-To: <b5ecad7f-209d-7ae0-fbf1-ee3258224996@gmail.com>
References: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
 <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>
 <CA+3eh11bU6PgqBFuwqtX8=WDnSXv73XETVvjD45vq7qLySivZw@mail.gmail.com>
 <b5ecad7f-209d-7ae0-fbf1-ee3258224996@gmail.com>
Message-ID: <CA+3eh13JtMdiN0aH0CegVvNcKk5LL04owLX3BxgMpcp+9iJM4A@mail.gmail.com>

Hi Jaikiran,

Thanks for the quick response. Unfortunately I can't find it online.
Is this a private issue or does Apple not provide public access to
submitted bugs at all?

Regards,
Volker

On Mon, Oct 17, 2022 at 11:09 AM Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>
> Hello Volker,
>
> I've now commented on that JBS issue with the Apple bug id - it's FB9997771.
>
> -Jaikiran
>
> On 17/10/22 2:24 pm, Volker Simonis wrote:
> > I can't find a link to the bug that has been filed with Apple in the
> > issue https://bugs.openjdk.org/browse/JDK-8282954.
> >
> > Can somebody please post the link to corresponding Apple issue here
> > and/or update JDK-8282954 with that information?
> >
> > Thanks,
> > Volker
> >
> > On Mon, Oct 17, 2022 at 10:49 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> >>
> >>
> >> On 17/10/2022 10:26, Mike Hearn wrote:
> >>> For some time now we've been chasing a very rare data corruption bug
> >>> in java.util.zip.Inflater that we think must be a bug in the bundled
> >>> native zlib. It gets detected by the CRC32 checks and so surfaces as a
> >>> failure to inflate. We believe this because:
> >>>
> >>> 1. It only seems to happen on ARM Macs (though we haven't tested on
> >>> ARM Linux). We have never seen it on Intel.
> >>>
> >> It would be useful if you could say which JDK releases you see this. As
> >> Jai linked to, the JDK is temporarily working around an issue with libz
> >> on macOS aarch64 since JDK 19 by using bundling a build of in-tree code.
> >> So it would be interesting to know if these reports include JDK 19 or
> >> are only older releases.
> >>
> >> -Alan

From rkennke at openjdk.org  Mon Oct 17 11:02:58 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 17 Oct 2022 11:02:58 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set
In-Reply-To: <pVFLFEWcUQJSiRZOtV3ogGQrs0ywIRD8_PVwLzemT5Q=.69cd5866-5289-47d1-9d18-3de9fce9e2c9@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>
 <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>
 <pVFLFEWcUQJSiRZOtV3ogGQrs0ywIRD8_PVwLzemT5Q=.69cd5866-5289-47d1-9d18-3de9fce9e2c9@github.com>
Message-ID: <RGvFgNbrNnnhOTiU4LOMB1W2P9vPVqeOYAo1Lsz61NM=.b5af66a2-0865-43c3-9967-9489dbd46568@github.com>

On Sat, 15 Oct 2022 14:38:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman WDYT? Is such a test mandatory to include this rather simple PR?
> 
> I think it means checking that test/jdk/java/io/BufferedInputStream/TransferTo.java exercises this code path, I expect it should.
> 
> It might seem a "rather simple PR" but it leaks a reference to the internal buffer to the target and we need to get comfortable with that. It only does then when there is no mark (good) so this should mostly limit the concern to sources where EOF may be encountered more than once.

Which kind of sources would do that, and is there a way to check it and prevent it?

The whole issue points to an insufficiency in the API: it is lacking a way to transfer buffers in a read-only fashion (like NIO could do). I don't suppose we would want to change that, though, right?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From jai.forums2013 at gmail.com  Mon Oct 17 11:08:29 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 17 Oct 2022 16:38:29 +0530
Subject: zlib upgrade due?
In-Reply-To: <CA+3eh13JtMdiN0aH0CegVvNcKk5LL04owLX3BxgMpcp+9iJM4A@mail.gmail.com>
References: <CAGv+2bNYR1wEpiYgEHpNfVvdr391tvW0KncQSxGLBAQ-4P4cLw@mail.gmail.com>
 <6a345207-96b5-3f4d-3d9c-fd16ab1e4c96@oracle.com>
 <CA+3eh11bU6PgqBFuwqtX8=WDnSXv73XETVvjD45vq7qLySivZw@mail.gmail.com>
 <b5ecad7f-209d-7ae0-fbf1-ee3258224996@gmail.com>
 <CA+3eh13JtMdiN0aH0CegVvNcKk5LL04owLX3BxgMpcp+9iJM4A@mail.gmail.com>
Message-ID: <526f53c3-32f5-aaaf-a220-27fc228af90a@gmail.com>

Hello Volker,

On 17/10/22 4:32 pm, Volker Simonis wrote:
> Hi Jaikiran,
>
> Thanks for the quick response. Unfortunately I can't find it online.
> Is this a private issue or does Apple not provide public access to
> submitted bugs at all?

As far as I know, Apple doesn't provide public access to these issues. 
Only the reporters seem to have access to those. I have seen some text 
in their docs which suggests that there might be a way to share issues 
with your team, but I don't know what the process is or what a "team" 
means.

Anyway, you aren't missing anything on that issue - there's hasn't been 
any replies to it. I am the only one who is commenting there asking for 
their team to help us understand what the issue is and what/when the fix 
could come in. Through other channels, I have been assured that the 
issue has landed up with the right team and they will look into it.

-Jaikiran

From alanb at openjdk.org  Mon Oct 17 11:16:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Oct 2022 11:16:40 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set
In-Reply-To: <RGvFgNbrNnnhOTiU4LOMB1W2P9vPVqeOYAo1Lsz61NM=.b5af66a2-0865-43c3-9967-9489dbd46568@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>
 <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>
 <pVFLFEWcUQJSiRZOtV3ogGQrs0ywIRD8_PVwLzemT5Q=.69cd5866-5289-47d1-9d18-3de9fce9e2c9@github.com>
 <RGvFgNbrNnnhOTiU4LOMB1W2P9vPVqeOYAo1Lsz61NM=.b5af66a2-0865-43c3-9967-9489dbd46568@github.com>
Message-ID: <ta_WoM2zhSAPAfwl8q-yV5QStN4dKRGwOzjuMMUZSbM=.0cb5aea2-f122-4199-a56d-37c2ffafa26e@github.com>

On Mon, 17 Oct 2022 10:59:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Which kind of sources would do that, and is there a way to check it and prevent it?
> 
> The whole issue points to an insufficiency in the API: it is lacking a way to transfer buffers in a read-only fashion (like NIO could do). I don't suppose we would want to change that, though, right?

It can arise with many sources. One example is a program writing to a file and another reading from the same file and doing the equivalent of "tail -f". So yes, it is possible for transferTo to transfer >0 bytes after it a previous innovation has returned 0.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From dsamersoff at openjdk.org  Mon Oct 17 12:28:45 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 17 Oct 2022 12:28:45 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <kfZsCRtve4_RB2DKhwA09oKGUNWhODifKi_A1FbVrCc=.b5385e3d-755d-4d08-8cbe-af5a7de307f4@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

```JNIEXPORT void JNICALL
JLI_InitArgProcessing(jboolean hasJavaArgs, jboolean disableArgFile) {
    // No expansion for relaunch
    if (argsCount != 1) {
        relaunch = JNI_TRUE;
        stopExpansion = JNI_TRUE;
        argsCount = 1;
    } else {

The code, that set relaunch variable (see above) doesn't really work.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From rgiulietti at openjdk.org  Mon Oct 17 13:34:55 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 17 Oct 2022 13:34:55 GMT
Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow
In-Reply-To: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
References: <XpbHjLD13akVXWMOh0CVfH3ZjWeWLzMenrJ0UxjMO5I=.03ec2741-0762-459d-b27a-3cc022a48a19@github.com>
Message-ID: <PhAIglbltxnHryk-kJd92BG3tC7fMdbhTowQPFLfTKA=.64ae558b-be7e-4fbf-8e5f-b5edc9d56a4c@github.com>

On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path.

waiting for review

-------------

PR: https://git.openjdk.org/jdk/pull/9410

From jpai at openjdk.org  Mon Oct 17 14:03:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Oct 2022 14:03:50 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <kV_rKhrYtDEsLIFsCJ8fJqyLWt-nbjt-MlimSSn8ujY=.58e94369-7166-4bc8-a2f6-84b3d4fd92b4@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Please keep open. Waiting for reviews on this one.

Mark and me ran some experiments related to this issue and we did conclude that this change will help the issue at hand. @msheppar, please correct me if that's not an accurate summary.

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From jwaters at openjdk.org  Mon Oct 17 14:21:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:21:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make
In-Reply-To: <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <F1p3brXZg3gn7JGfj3lajFmsQIxJ4Cvu6l1Xnd5mSyE=.6543a51c-bf60-45a2-9ad0-be7e2d87a074@github.com>
Message-ID: <yQkQ2fv6xhYKVjxQcawlr6dCgrA2Ic4GM1JgBnS7-QA=.0e6d20f9-8857-49c6-9cae-1ea5681a28fe@github.com>

On Mon, 17 Oct 2022 09:24:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @TheShermanTanker Question: is this a Windows-specific thing, or are there pragma-loaded libraries for other compilers as well?

To my knowledge only Visual C++ has the ability to perform linking through pragmas, the comment pragma works by leaving a linker comment in the object file (hence the name), meaning this only works with the Visual C++ linker, so while clang does support this pragma with clang-cl, for the use cases in the JDK it wouldn't matter. gcc does not have an equivalent pragma (or provide support for linking from inside source files at all, for that matter)

> If the methods are equivalent, I prefer linking via make file.

There isn't any difference between the 2 unless the library is tampered with by `-nodefaultlib`, but I can only find that specified in https://github.com/openjdk/jdk/blob/a033aa5a3d9c63d72d11af218b9896b037fbd8de/make/autoconf/flags-other.m4#L38 and https://github.com/openjdk/jdk/blob/392f35df4be1a9a8d7a67a25ae01230c7dd060ac/make/autoconf/lib-hsdis.m4#L45, neither of which have an effect on the libraries in this changeset

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:25:08 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:25:08 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v2]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <3fTguMGwo3QBguzYDzhuTVTiqTzn8ZVPiGM5xYuqZbw=.96637af9-ed38-49aa-aa99-71c656a11320@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - user32
 - Mswsock.lib requirement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/cfa80528..54e6ec10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:27:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:27:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v3]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <2ETlbmDLPJuS-GkWsIceJISmHts7aROCmrbPKS3lsag=.1fbf54ad-a174-4865-87b1-66c20004cb12@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update Guid.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/54e6ec10..fe15f907

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:27:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:27:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v3]
In-Reply-To: <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <hKcmTXbzhLs2BLZ0U1CK9-buNYwtqqgbj23R5dRFHxQ=.d67542a4-fe38-4c4a-8d1e-f58e2264f175@github.com>
Message-ID: <Sdp31g_wPD_84xtCvZxXWZziMxRFoBtCKGaTuAYkJEE=.44879988-0df8-4555-af8f-96fd82870594@github.com>

On Sun, 16 Oct 2022 13:18:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Guid.cpp
>
> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 38:
> 
>> 36: 
>> 37: #include <Mswsock.h>
>> 38: #pragma comment(lib, "Mswsock.lib")
> 
> I think this came about with one of the early Microsoft contributions to have transferTo optionally use TransmitFile on Windows. This created the dependency on Mswsock. It's not clear why a pragma was used though.

I believe it may have had to do with explicitly showing the dependency as David suggests, I added a comment explaining this just in case

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From duke at openjdk.org  Mon Oct 17 14:29:11 2022
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 17 Oct 2022 14:29:11 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
Message-ID: <CZYnWDbljhLM0OqrFDz4GmOquKst0acmyHQeL_jiCLw=.78ac4072-44ef-456c-9641-f45d975d800c@github.com>

On Fri, 14 Oct 2022 19:25:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - new approach: print warning in StaticProperty.java
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - add the change for nio and update the code according to the comments
>  - new approach
>  - change based on the review
>  - updating according to the comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
>  - update error message
>  - error message for non-existing directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc

StaticProperty is using System.err to print out a warning message. PrintStream err needs to be initialized before being used by StaticPropery.

Going to revise the change according to the comments

-------------

PR: https://git.openjdk.org/jdk/pull/9989

From jwaters at openjdk.org  Mon Oct 17 14:31:46 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:31:46 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v4]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with five additional commits since the last revision:

 - Update WinSysInfo.cpp
 - Update WinApp.cpp
 - Update MsiUtils.cpp
 - Update MsiDb.cpp
 - Update MsiCA.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/fe15f907..8afaf85d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=02-03

  Stats: 12 lines in 5 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:35:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:35:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v5]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <1FdeByT381QCHgVhV7RfaietWwt_xj2jmQuZBFklSJM=.0cfa6d5d-3ccd-45cf-84c4-66d3e8b595e4@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Update WindowsRegistry.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/8afaf85d..0779d1fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:35:32 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:35:32 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v4]
In-Reply-To: <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <ri6EV_458kAizhAbMhhxjl61sZnt8A5hJLODyolkuHk=.b0ee311b-a516-4430-9ca6-3198d05fe584@github.com>
Message-ID: <q0n5fVZ_fV97Q5JdJI9Ck9Oype80Zuy0mVLJq4MkbVc=.6788d427-8f9c-46f9-9529-87e71be67803@github.com>

On Mon, 17 Oct 2022 14:31:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Update WinSysInfo.cpp
>  - Update WinApp.cpp
>  - Update MsiUtils.cpp
>  - Update MsiDb.cpp
>  - Update MsiCA.cpp

Thanks all for the reviews, I placed comments where the pragmas used to be detailing the library required by the source file to address David's concerns

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From jwaters at openjdk.org  Mon Oct 17 14:41:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 14:41:06 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10633/files
  - new: https://git.openjdk.org/jdk/pull/10633/files/0779d1fa..4eb2eb7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10633&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10633.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10633/head:pull/10633

PR: https://git.openjdk.org/jdk/pull/10633

From aefimov at openjdk.org  Mon Oct 17 15:32:55 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 17 Oct 2022 15:32:55 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v6]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Update filter docs to match implementation.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/b3849168..4449dda1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=04-05

  Stats: 10 lines in 3 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From aefimov at openjdk.org  Mon Oct 17 15:45:47 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 17 Oct 2022 15:45:47 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v5]
In-Reply-To: <QS-ou-X1c4It5-vKse8h6YSFZqoYVqwh7I6EdfuRN-0=.b649ffbb-8288-4484-8032-e1c0c627caef@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <BK96lLqcnsAlZGnd_ZYMKp04wfXs6ipUreLXy8sYbgM=.25d618f5-7d36-41dd-91f0-b820bd40f4fa@github.com>
 <KY-eG8T78K3kkjlSIc4l4DHjwcJDWp4R9TLVJz6oA9c=.47b9f44d-a2ed-4e46-9731-e45130bd225c@github.com>
 <OxwzM2iheZBQllz4vLIXe9G42Rj8IQEyX3_P5DkoC10=.c8df2f77-b924-4d97-a52a-4efac36c49d4@github.com>
 <QS-ou-X1c4It5-vKse8h6YSFZqoYVqwh7I6EdfuRN-0=.b649ffbb-8288-4484-8032-e1c0c627caef@github.com>
Message-ID: <2OYgybrPaDz6IGDPeJuztwySKWAn6YJjCnnFUqKzR5E=.ab31e70a-b2c8-47da-b443-418840b72c8a@github.com>

On Fri, 14 Oct 2022 17:45:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In the general composition of filters, it is preferable that UNDECIDED is treated as REJECTED.
 > That keeps unintentional holes in a filter from being permissive.

That is a good point Roger. The "java.security" file was updated (4449dda) to match the `ObjectFactoriesFilter` implementation, ie the global filter treats UNDECIDED as REJECTED. Also, the CSR has been updated to highlight that.

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From tvaleev at openjdk.org  Mon Oct 17 15:48:02 2022
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 17 Oct 2022 15:48:02 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v3]
In-Reply-To: <Yk7v-FgZQn1ugOg8NTvrolE0MEJ8WloQp1mhzrp5YYE=.daba7f97-4308-4ca8-81af-8303006cb38f@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <BFu8_BHci1RjqZIPZ1vKD7e0TeVxQutLMQlTUSTJs_4=.5e8e87c0-5b34-464b-a73c-8a09eae11394@github.com>
 <KvkRBnUkErtMZSyJcyDVHyqlHaXIZYc27qebTWS_zu8=.f27acbba-2c7b-433c-b23b-866b5a7160be@github.com>
 <Yk7v-FgZQn1ugOg8NTvrolE0MEJ8WloQp1mhzrp5YYE=.daba7f97-4308-4ca8-81af-8303006cb38f@github.com>
Message-ID: <gigiJP0aphRTnWIyJ_FwNpbmZKzWGw3jSFEuZzgY4D4=.c1f1c60a-4383-47be-98f7-769954a07f23@github.com>

On Mon, 17 Oct 2022 09:38:01 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> I saw this code many times and always thought that it exists for performance purposes, to avoid extra indirection via likely megamorphic naturalOrder comparator which will slow down the operations on common path. I think such a simplification could be accepted only if accompanied by a properly written benchmark (which actually emulates megamorphic callsite) which shows no performance regression.
>
> @amaembo you mean we should have a benchmark measuring a `TreeMap.get()` with lots of implementations of Comparators or Comparables?

@stsypanov all operations involving the code paths touched by your refactorings. Well, get() is the most interesting one. Comparable.naturalOrder() should be actually used in many other contexts (e.g., in setup phase of the benchmark) often enough to pollute the type profile. Well, probably there are some compiler control options to automate this but I'm not aware. I would also check inlining log to ensure whether comparator is devirtualized and inlined or not. If inlined, then it's unlikely that you've polluted the type profile successfully.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From naoto at openjdk.org  Mon Oct 17 16:24:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Oct 2022 16:24:48 GMT
Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir
 directory doesn't exist [v4]
In-Reply-To: <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
References: <rjEWqSaj5cFnFbv-bFsv7Ab1qpwgfoKe9mILyMuXH_M=.b8b570a7-27cf-494a-805b-3e04dd404bc6@github.com>
 <OdKKvU8zAEQzjtHDfPoI3clMv1n4F8zFxpi9KcyQ7ho=.831285ee-8190-4f4d-b57a-e9b257df0b7a@github.com>
Message-ID: <0MYNifnKVaHf4Luet84jkmljt1xmmzbGM12FIAxNQ_g=.33b7690e-c6b8-475a-966f-35225a7cd0b4@github.com>

On Fri, 14 Oct 2022 19:25:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist
>
> Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - new approach: print warning in StaticProperty.java
>  - Merge branch 'master' into improve-directory-not-existing-error-message
>  - add the change for nio and update the code according to the comments
>  - new approach
>  - change based on the review
>  - updating according to the comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message
>  - update error message
>  - error message for non-existing directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 76:

> 74:             System.err.println("WARNING: java.io.tmpdir location does not exist");
> 75:         }
> 76: 

System.out/err relies on encoding properties are initialized, so I don't think this would work.

-------------

PR: https://git.openjdk.org/jdk/pull/9989

From bhuang at openjdk.org  Mon Oct 17 16:37:36 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 17 Oct 2022 16:37:36 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v2]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <kbn8N4pXF1cO3lk2pvHVM5H1e8xF0fIn3Ypgw8iVil0=.69005d39-cfb7-4a08-ad9b-0d6c72434960@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Refactored to use testng framework for test enviroment setup.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/5a47cacd..4911518e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=00-01

  Stats: 83 lines in 2 files changed: 10 ins; 29 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From bhuang at openjdk.org  Mon Oct 17 16:41:54 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 17 Oct 2022 16:41:54 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v2]
In-Reply-To: <bmQOg7gqjEWiMVTCEnVY1RUqFeOssuxk8veYu0W67kM=.a68b3625-1649-4c58-8a89-12cc0fdf7ba6@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <kna-Olh8iK2suf9cheVTNVW7f0xJt5afUu31DVsg5qs=.7ddb74d6-414c-4272-adae-ff55d9930984@github.com>
 <bmQOg7gqjEWiMVTCEnVY1RUqFeOssuxk8veYu0W67kM=.a68b3625-1649-4c58-8a89-12cc0fdf7ba6@github.com>
Message-ID: <5PtU-LzTnAPk_XYMeilrE_8CNTmplIOmWSIntJSaRcQ=.fae39780-b601-4d9e-87dd-febd47dc1334@github.com>

On Fri, 14 Oct 2022 15:50:30 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/java/security/Policy/Root/Root.java line 48:
>> 
>>> 46:     private static final Path TARGET = Paths.get(ROOT, ".java.policy");
>>> 47:     public static void main(String[] args) throws Exception {
>>> 48:         Files.copy(SOURCE, TARGET, StandardCopyOption.REPLACE_EXISTING);
>> 
>> Could you please use the testng framework for initial setup of test.
>
> This is a @driver test that copies the Root.policy file to the home directory before running the RootTest in a new JVM. The reason is that upon the start of the new JVM it loads the default system-wide policy file and the default user policy file which is the Root.policy we just copied. With the testng framework, there is no way to load the custom user policy file without reinstalling the security manager in the test, that said, it doesn't match what the manual test does.

Discussed with Mahendra offline, testng framework `@BeforeTest` performs test setup in the client JVM before test starts in the other JVM. We can use testng framework in this case to handle the policy file operations.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From lmesnik at openjdk.org  Mon Oct 17 16:43:31 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 17 Oct 2022 16:43:31 GMT
Subject: RFR: 8284614: on macOS "spindump" should be run from failure_handler
 as root
Message-ID: <3DgeklO8yKV5sBiixQbD5piICBaLXz2Zy6GqJrb06Vc=.e78f565e-77c9-47ba-99c0-0a0bc8020b6b@github.com>

The fix is contributed by @plummercj actually.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/10730/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284614
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10730.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10730/head:pull/10730

PR: https://git.openjdk.org/jdk/pull/10730

From darcy at openjdk.org  Mon Oct 17 16:53:41 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Oct 2022 16:53:41 GMT
Subject: RFR: 8294730: Add @throws and @implNote clauses to
 BigInteger::isProblablePrime and BigInteger::nextProblablePrime
In-Reply-To: <eAoP-aMiw7G89Wx41vKW2Kojilr7P1jZjYVnGym61Wc=.e2e2cc0a-58b3-4112-979f-9be473d02317@github.com>
References: <eAoP-aMiw7G89Wx41vKW2Kojilr7P1jZjYVnGym61Wc=.e2e2cc0a-58b3-4112-979f-9be473d02317@github.com>
Message-ID: <oExjFtlbNBXXEU1hNT0LSAC4qT3idglTitsxto4uk5o=.e8cdefef-dbfb-46af-b61c-24938ab8404f@github.com>

On Mon, 3 Oct 2022 18:32:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Completes the spec of [PR 10541](https://github.com/openjdk/jdk/pull/10541)

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10543

From bhuang at openjdk.org  Mon Oct 17 16:57:06 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 17 Oct 2022 16:57:06 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  AssertThrows an exception in InconsistentEntries test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/4911518e..cfb9f74d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=01-02

  Stats: 9 lines in 1 file changed: 1 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From bpb at openjdk.org  Mon Oct 17 17:02:52 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Oct 2022 17:02:52 GMT
Subject: RFR: 8294730: Add @throws and @implNote clauses to
 BigInteger::isProblablePrime and BigInteger::nextProblablePrime
In-Reply-To: <eAoP-aMiw7G89Wx41vKW2Kojilr7P1jZjYVnGym61Wc=.e2e2cc0a-58b3-4112-979f-9be473d02317@github.com>
References: <eAoP-aMiw7G89Wx41vKW2Kojilr7P1jZjYVnGym61Wc=.e2e2cc0a-58b3-4112-979f-9be473d02317@github.com>
Message-ID: <7ClrMuOsjtxN3LkDm6l9o0QyAeJM_SUBZNNcbjpBc_M=.94a9b36d-e5fe-4e8e-930d-38126a4680f7@github.com>

On Mon, 3 Oct 2022 18:32:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Completes the spec of [PR 10541](https://github.com/openjdk/jdk/pull/10541)

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10543

From asemenyuk at openjdk.org  Mon Oct 17 17:19:59 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 17 Oct 2022 17:19:59 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
Message-ID: <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>

On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

The change looks harmless. Howevere I don't understand how searching for the standard Windows libs can then become frustrating.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From erikj at openjdk.org  Mon Oct 17 17:35:59 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Oct 2022 17:35:59 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
Message-ID: <r0umuBwCmFWWe9qkQRYTFlfbkyddQ7m8s13CN2geicM=.5af8a5c4-74b1-4a13-b54a-f596a67d7e6c@github.com>

On Mon, 17 Oct 2022 14:41:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From erikj at openjdk.org  Mon Oct 17 17:41:07 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Oct 2022 17:41:07 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
 <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
Message-ID: <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>

On Mon, 17 Oct 2022 17:16:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The change looks harmless. Howevere I don't understand how searching for the standard Windows libs can then become frustrating.

I believe this is part of the effort for https://bugs.openjdk.org/browse/JDK-8288293.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From asemenyuk at openjdk.org  Mon Oct 17 17:46:04 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 17 Oct 2022 17:46:04 GMT
Subject: RFR: 8295231: Move all linking of native libraries to make [v6]
In-Reply-To: <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
 <XPviQLGDwrC6qQ-y7NXybMk2S6vUDS9QrqZ6oXI2tBU=.7832f416-03a0-43fd-a271-23727ef28033@github.com>
 <DXV4QjDHeuDBU7-RvbGkriTesUom6izi4S3bzg3RmYg=.9f496acd-e29b-436a-ad21-465752a4a56b@github.com>
 <t0BhQQWaUJzEKpnh6J_6Du5tu_T_8yiZwDiYteIGMDA=.e10b48bb-b804-40c4-8fa3-28e1e045c4fe@github.com>
Message-ID: <bVlrub4RmKlF4OQ1B7hhwVOSL6wysDgQjLBqKqSfTIU=.89091be9-b6c4-4071-91c9-2e85b268bd68@github.com>

On Mon, 17 Oct 2022 17:37:11 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I believe this is part of the effort for https://bugs.openjdk.org/browse/JDK-8288293.

Agree. I'd prefer to have a different description of the bug though to make it clear that this is necessary for decoupling a compiler and an OS.

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From redestad at openjdk.org  Mon Oct 17 19:32:04 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 17 Oct 2022 19:32:04 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
Message-ID: <i1e7H4BkoN24WU_frKwqbZTW5hlxiKODQcUw-wwSulU=.a48ea043-ad03-44a7-9cc6-d29c35423431@github.com>

On Fri, 14 Oct 2022 04:37:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iwanowww comments

Looks good, assuming there are tests calling in with no class data to check that `defineClass` is fine with `null` inputs?

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10706

From duke at openjdk.org  Mon Oct 17 19:46:04 2022
From: duke at openjdk.org (liach)
Date: Mon, 17 Oct 2022 19:46:04 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v4]
In-Reply-To: <IBXajKeImw6Gp47glepoN4QfDgV3hj3FQepZWCin0rI=.df4e490c-d87f-46a0-9343-7ebfb6da2708@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <IBXajKeImw6Gp47glepoN4QfDgV3hj3FQepZWCin0rI=.df4e490c-d87f-46a0-9343-7ebfb6da2708@github.com>
Message-ID: <TmYiIVEScVEzhsWZPJ5KKDucoaJIy9EGGSKUUReS9Lg=.9fa366e7-3891-4f3d-9b03-4ed4cbb89430@github.com>

On Mon, 17 Oct 2022 10:19:26 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one.
>> 
>> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it?
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293630: Inline natural()

src/java.base/share/classes/java/util/TreeMap.java line 3329:

> 3327:             }
> 3328:             else {
> 3329:                 return (Comparator<Map.Entry<K, V>> & Serializable) (e1, e2) -> {

I think this cast hints compiler to bootstrap lambda meta factory with extra Serializable marker interface. Meanwhile, Comparator.naturalOrder does not implement Serializable.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From jwaters at openjdk.org  Mon Oct 17 21:00:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 17 Oct 2022 21:00:10 GMT
Subject: Integrated: 8295231: Move all linking of native libraries to make
In-Reply-To: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
References: <e2c4x6b1oEU0kHMhuLGF-kbVwD_L_ACxIMAJSyRj8iw=.414786bd-0ac0-41d8-ae52-ddbe8ca7ffe3@github.com>
Message-ID: <LJqNsfDg8OzA5tusYcYOBxXZnvR0HQH1dmryNmNTJnM=.c6e7c7fa-efd1-4f09-a3cf-02689ce58e20@github.com>

On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Some external libraries required by native code are linked via linker comments embedded in pragmas. Searching for which libraries are linked can then become frustrating and confusing since they may be included in an obscure place, and for all relevant compilers there is no difference between specifying them from make and in a source file. The easiest solution is to just always link them from make and remove any source level linkage.

This pull request has now been integrated.

Changeset: 8d751de3
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d751de3198675b22704cdccafaff2fc0fdd3f59
Stats:     26 lines in 14 files changed: 3 ins; 6 del; 17 mod

8295231: Move all linking of native libraries to make

Reviewed-by: ihse, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/10633

From iklam at openjdk.org  Mon Oct 17 21:14:01 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Oct 2022 21:14:01 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <i1e7H4BkoN24WU_frKwqbZTW5hlxiKODQcUw-wwSulU=.a48ea043-ad03-44a7-9cc6-d29c35423431@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
 <i1e7H4BkoN24WU_frKwqbZTW5hlxiKODQcUw-wwSulU=.a48ea043-ad03-44a7-9cc6-d29c35423431@github.com>
Message-ID: <M-1niyyFphzgCbzZsVJDdhD4Gfmxi8lLxwp3aO6Ondo=.d1b9e9f3-466d-4c64-bb81-331dbe7ef5af@github.com>

On Mon, 17 Oct 2022 19:28:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Looks good, assuming there are tests calling in with no class data to check that `defineClass` is fine with `null` inputs?

Yes, we have two existing test cases that has no class data:

- java/lang/invoke/CompileThresholdBootstrapTest
- java/lang/invoke/LoopCombinatorLongSignatureTest

I found them by adding this to `InvokerBytecodeGenerator::classDataValues()`


    private Object classDataValues() {
        final List<ClassData> cd = classData;
        if (cd.size() == 0) {
            throw new RuntimeException("huh");
        }


If I remove the above hack but keep my patch, the tests passed. So I think this case is covered.

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From iklam at openjdk.org  Mon Oct 17 21:48:42 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Oct 2022 21:48:42 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v3]
In-Reply-To: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
Message-ID: <GQEJ8MGflaAV-b8_JpE19SN9a9gZxy6Dt-ljbMSxf_w=.8e2fff78-2df9-4254-9a4d-71ccca3d508f@github.com>

> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into 8295302-no-arraylist-for-single-classdata-for-lambdaform
 - @mlchung comments
 - @iwanowww comments
 - 8295302: Do not use ArrayList when LambdaForm has a single ClassData

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10706/files
  - new: https://git.openjdk.org/jdk/pull/10706/files/5a800f0d..eb05b9ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10706&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10706&range=01-02

  Stats: 4613 lines in 133 files changed: 2969 ins; 1034 del; 610 mod
  Patch: https://git.openjdk.org/jdk/pull/10706.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10706/head:pull/10706

PR: https://git.openjdk.org/jdk/pull/10706

From iklam at openjdk.org  Mon Oct 17 22:07:05 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Oct 2022 22:07:05 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <11q66gbNm_Nn9HZzITVxIJ3uVrh8CTzyJWydly9lIIw=.42c91314-8510-430e-9b17-ea59a8368122@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
 <rdxUOdPVaJeXVdYLim6friENrR1kKTStSVe29zlWF3k=.922e5a80-fa4c-4891-a784-160def0da92b@github.com>
 <11q66gbNm_Nn9HZzITVxIJ3uVrh8CTzyJWydly9lIIw=.42c91314-8510-430e-9b17-ea59a8368122@github.com>
Message-ID: <JK6afUST3w6OwO8QuQAtAjdRx-uqFtQ2hHEB5gdYEgE=.d041cb30-6b67-42fe-97c7-c810aaaa6e0b@github.com>

On Fri, 14 Oct 2022 17:12:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 291:
>> 
>>> 289:         final List<ClassData> cd = classData;
>>> 290:         return switch(cd.size()) {
>>> 291:             case 0 -> null;
>> 
>> `List.of()` always returns the same singleton instance and does not cause any object allocation.  I prefer to keep the `classDataValues()` to return `List<Object>`
>
> Ah, I now see why you have to change the signature because of the single element case.  I made my comment too quickly. 
> 
> A couple of suggestions:
> Please add a javadoc for this method to describe what this method returns for different cases.   It's better to move this method close to `clinit` as they are tightly coupled.

I moved the method and added in javadoc. Could you check if the wording is OK?

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From duke at openjdk.org  Mon Oct 17 22:09:42 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 17 Oct 2022 22:09:42 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a Java
 native test launcher
Message-ID: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>

Issue: Formatter unit tests are launched via basic.sh

Fix: Replace basic.sh with a Java test launcher

Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 


Original output on success
<img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">


New output on success
<img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

-------------

Commit messages:
 - Address PR comments (Junit, exceptions)
 - Remove basic.sh, replace with java test launcher

Changes: https://git.openjdk.org/jdk/pull/10715/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295239
  Stats: 165 lines in 3 files changed: 102 ins; 61 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Mon Oct 17 22:09:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Oct 2022 22:09:45 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <C2M8mobydziM2sFOUlh8S5vOR8QZTDA_J3hZeUKHXx4=.e765c9c1-6120-4504-bba3-fc2157e3500a@github.com>

On Fri, 14 Oct 2022 20:38:32 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

test/jdk/java/util/Formatter/Basic.java line 24:

> 22:  */
> 23: 
> 24: import static java.lang.System.out;

It's not your change, but probably this does not seem necessary, as `out` appears only once.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 36:

> 34:  *      8059175 8204229
> 35:  *
> 36:  * @run main/othervm BasicTestLauncher

It does not seem to require `othervm` mode.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 48:

> 46:         runFormatterTests(TZ_UP);
> 47:         runFormatterTests(TZ_AN);
> 48:     }

Could use testng/junit, instead of normal main. This way both timezones are guaranteed to be tested. Currently, if an error occurs with `US/Pacific`, `Asia/Novosibirsk` will not run.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 74:

> 72:             throw new RuntimeException(String.format("$$$ Error(s) found within %s subprocess: " +
> 73:                     "%s%n", timeZone, err.getMessage()));
> 74:         }

I'd prefer not to catch an exception (and turn it into `RuntimeException`) here, as the exception type will be lost.

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Mon Oct 17 22:09:45 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 17 Oct 2022 22:09:45 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <C2M8mobydziM2sFOUlh8S5vOR8QZTDA_J3hZeUKHXx4=.e765c9c1-6120-4504-bba3-fc2157e3500a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <C2M8mobydziM2sFOUlh8S5vOR8QZTDA_J3hZeUKHXx4=.e765c9c1-6120-4504-bba3-fc2157e3500a@github.com>
Message-ID: <56-sprlAOMO7jocaocsNMDpHP64K4XVJ34Bj_O1MGpc=.e4616ffd-7b1f-485d-83e5-62e6cc371a88@github.com>

On Fri, 14 Oct 2022 21:48:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> test/jdk/java/util/Formatter/Basic.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: import static java.lang.System.out;
> 
> It's not your change, but probably this does not seem necessary, as `out` appears only once.

Got rid of it!

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 48:
> 
>> 46:         runFormatterTests(TZ_UP);
>> 47:         runFormatterTests(TZ_AN);
>> 48:     }
> 
> Could use testng/junit, instead of normal main. This way both timezones are guaranteed to be tested. Currently, if an error occurs with `US/Pacific`, `Asia/Novosibirsk` will not run.

Thank you for the catch, replaced with JUnit

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 74:
> 
>> 72:             throw new RuntimeException(String.format("$$$ Error(s) found within %s subprocess: " +
>> 73:                     "%s%n", timeZone, err.getMessage()));
>> 74:         }
> 
> I'd prefer not to catch an exception (and turn it into `RuntimeException`) here, as the exception type will be lost.

Thank you, separated to distinguish the IO and runtime exceptions

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Mon Oct 17 22:28:22 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 17 Oct 2022 22:28:22 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>

On Fri, 14 Oct 2022 20:38:32 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Hi Justin,

A few comments on a quick pass through your changes

test/jdk/java/util/Formatter/Basic.java line 93:

> 91:                                        + fail + " failure(s), first", first);
> 92:         else
> 93:             System.out.println("all " + (fail + pass) + " tests passed");

Perhaps use System.out.printf vs println and "fail" should not be needed as all tests passed

test/jdk/java/util/Formatter/BasicTestLauncher.java line 52:

> 50: 
> 51:     @Test
> 52:     public void testUsPac() throws IOException{

You could use a DataProvider

test/jdk/java/util/Formatter/BasicTestLauncher.java line 99:

> 97:         }catch(RuntimeException err){
> 98:             throw new RuntimeException(String.format("$$$ %s: Test(s) failed or TestJVM did not build correctly." +
> 99:                     " Check stderr output from diagnostics summary above%n",  err.getMessage()));

Do you need to catch the RuntimeException and then throw a new RuntimeException?  I think you might want to consider reworking this

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Mon Oct 17 22:43:03 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 17 Oct 2022 22:43:03 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
Message-ID: <EHnJYJ7PlmwIN4QzgGCeLbJC9izbrabKqvFUi6EF0A0=.08e0a8e6-1b9e-4cbc-8487-4dd77ce3c63d@github.com>

On Mon, 17 Oct 2022 22:20:11 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 52:
> 
>> 50: 
>> 51:     @Test
>> 52:     public void testUsPac() throws IOException{
> 
> You could use a DataProvider

I had the same thought

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Mon Oct 17 23:38:19 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 17 Oct 2022 23:38:19 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
Message-ID: <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>

On Mon, 17 Oct 2022 22:18:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> test/jdk/java/util/Formatter/Basic.java line 93:
> 
>> 91:                                        + fail + " failure(s), first", first);
>> 92:         else
>> 93:             System.out.println("all " + (fail + pass) + " tests passed");
> 
> Perhaps use System.out.printf vs println and "fail" should not be needed as all tests passed

Thank you Lance, will take a look at this and the rest of the comments

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From iris at openjdk.org  Tue Oct 18 00:01:02 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 18 Oct 2022 00:01:02 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
 <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>
Message-ID: <2_hO38mZMubniHflGyz9lEdd46P4O8RtSTCcotUGock=.5e54fceb-8379-4fc0-9bcf-78d79b868b4b@github.com>

On Mon, 17 Oct 2022 23:34:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 93:
>> 
>>> 91:                                        + fail + " failure(s), first", first);
>>> 92:         else
>>> 93:             System.out.println("all " + (fail + pass) + " tests passed");
>> 
>> Perhaps use System.out.printf vs println and "fail" should not be needed as all tests passed
>
> Thank you Lance, will take a look at this and the rest of the comments

Careful.  I suspect that "fail" is the number of tests that are expected to fail.

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 00:08:53 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 00:08:53 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <2_hO38mZMubniHflGyz9lEdd46P4O8RtSTCcotUGock=.5e54fceb-8379-4fc0-9bcf-78d79b868b4b@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
 <krxCXLu3ID3zy4wFdNFKBXcTfv8QrukrSNFJ5E26sgI=.fbaf7752-3815-4dc4-b119-98cb6667df83@github.com>
 <2_hO38mZMubniHflGyz9lEdd46P4O8RtSTCcotUGock=.5e54fceb-8379-4fc0-9bcf-78d79b868b4b@github.com>
Message-ID: <BSe_yN_ZXaR6lxDCOhrymi59AuUfOVbwM6h5olLDkMc=.dea96b57-1ea7-4408-b418-d9beaf1b55a4@github.com>

On Mon, 17 Oct 2022 23:57:11 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Thank you Lance, will take a look at this and the rest of the comments
>
> Careful.  I suspect that "fail" is the number of tests that are expected to fail.

Thanks Iris,
It got hidden in the code snippet, but line 89 is `if (fail != 0)`,
so I do believe fail is redundant in 93.

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From dholmes at openjdk.org  Tue Oct 18 00:57:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Oct 2022 00:57:00 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <xtgCou5OFQ62FUeMpMfIKzACvc2RfMvQVX97xIGcobI=.8d01d998-f5ef-43fa-a78b-8b968bed27e2@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

Then can we fix the use of `relaunch` if it isn't working?

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From xgong at openjdk.org  Tue Oct 18 01:44:21 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 18 Oct 2022 01:44:21 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
 [v2]
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <X9zTQt0OcFrz9cuKYjOdVaQaa-tZCzB8u4wz0Y2WMbU=.5f24f688-414d-4b17-b0bb-c778b68a0059@github.com>

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Add the floating point support for VectorLoadConst and remove the VectorCast
 - Merge branch 'master' into JDK-8293409
 - 8293409: [vectorapi] Intrinsify VectorSupport.indexVector

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10332/files
  - new: https://git.openjdk.org/jdk/pull/10332/files/2ad157b6..53f042d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10332&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10332&range=00-01

  Stats: 50675 lines in 1239 files changed: 30581 ins; 14395 del; 5699 mod
  Patch: https://git.openjdk.org/jdk/pull/10332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10332/head:pull/10332

PR: https://git.openjdk.org/jdk/pull/10332

From xgong at openjdk.org  Tue Oct 18 01:44:21 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 18 Oct 2022 01:44:21 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <0yv4LhxY5GqaiuhoxdB7tmmJlik-m9B_2BYWkdDCSTU=.0c97a482-164d-4d14-8a3e-8a6b2c3a34c6@github.com>

On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

Hi @jatin-bhateja , all your comments have been addressed. Please help to look at the changes again! Thanks in advance!

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From xgong at openjdk.org  Tue Oct 18 01:44:21 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 18 Oct 2022 01:44:21 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
 [v2]
In-Reply-To: <_wyFWAET_qXwwj-9Iq9AsPAGbT3AXIwN6HujmwZVRPw=.9c652886-4255-4c03-89d9-e3c74f9f319a@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
 <_wyFWAET_qXwwj-9Iq9AsPAGbT3AXIwN6HujmwZVRPw=.9c652886-4255-4c03-89d9-e3c74f9f319a@github.com>
Message-ID: <yT_4ry_BskJAOxrsPyFnXGwlyR1THJhzfE5uVOt7zo4=.890b3f32-6bd6-4ea4-9268-ad582516f452@github.com>

On Thu, 13 Oct 2022 07:04:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Add the floating point support for VectorLoadConst and remove the VectorCast
>>  - Merge branch 'master' into JDK-8293409
>>  - 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2949:
> 
>> 2947:   } else if (elem_bt == T_DOUBLE) {
>> 2948:     iota = gvn().transform(new VectorCastL2XNode(iota, vt));
>> 2949:   }
> 
> Since we are loading constants from stub initialized memory locations, defining new stubs for floating point iota indices may eliminate need for costly conversion instructions. Specially on X86 conversion b/w Long and Double is only supported by AVX512DQ targets and intrinsification may fail for legacy targets.

Make sense to me! I'v changed the codes based on the suggestion in the latest commit. Please help to take a review again! Thanks a lot!

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From duke at openjdk.org  Tue Oct 18 02:01:05 2022
From: duke at openjdk.org (jmehrens)
Date: Tue, 18 Oct 2022 02:01:05 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <x-vqMXoDYU-d36Ky7YNeeJ0LgAVOt6P5K3mV5UJhkhE=.c623d0b5-68f1-4914-9f39-1ec6b9c6d1bc@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
 <SkCt4Rq9h5SHMoClLu-hk8ZDEMRs4hhLEAyHiNFiqRU=.38b44f51-8dad-4763-b754-ae7dc38572b4@github.com>
 <x-vqMXoDYU-d36Ky7YNeeJ0LgAVOt6P5K3mV5UJhkhE=.c623d0b5-68f1-4914-9f39-1ec6b9c6d1bc@github.com>
Message-ID: <KYBQB17i29BXZFKIaVHRnr-amZPMcQqqNk7iMW5lIQI=.fa4eeb5b-cf31-42f9-9feb-8803cb51b058@github.com>

On Sat, 15 Oct 2022 07:30:54 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> For unsorted sets like LinkedHashSet, it's unclear how to behave if replaceAll returns identical elements. Throw an exception? Shrink the set size via deduplication?

I would assume the spec for replaceAll would be borrowed from Map.html#replaceAll(java.util.function.BiFunction).  Shrinking size is not an option because that is a ConcurrentModificationException.  Adding elements to the set would a ConcurrentModificationException.  Therefore, LinkedHashSet::replaceAll would have to be swapping the order of the linked entries already contained in the set.  So in your example of returning identical elements the answer is CCE (or IAE) if the element is not contained in the set.  Otherwise, the element is eventually moved to the last entry in the set.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From mchung at openjdk.org  Tue Oct 18 02:06:26 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Oct 2022 02:06:26 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v3]
In-Reply-To: <GQEJ8MGflaAV-b8_JpE19SN9a9gZxy6Dt-ljbMSxf_w=.8e2fff78-2df9-4254-9a4d-71ccca3d508f@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <GQEJ8MGflaAV-b8_JpE19SN9a9gZxy6Dt-ljbMSxf_w=.8e2fff78-2df9-4254-9a4d-71ccca3d508f@github.com>
Message-ID: <3PBih6hbS-YlVOWr8fx0CPrVyPXqdy9k7oXI5rbfs1c=.f9f5d1d2-dd4c-4390-ae42-c6ba0120933a@github.com>

On Mon, 17 Oct 2022 21:48:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8295302-no-arraylist-for-single-classdata-for-lambdaform
>  - @mlchung comments
>  - @iwanowww comments
>  - 8295302: Do not use ArrayList when LambdaForm has a single ClassData

Thanks for the update.    I made the suggested wording.   You can push once it's updated.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 346:

> 344: 
> 345:     /**
> 346:      * Returns an object to pass this.classData to the <clinit> method of the

What about:

Suggestion:

     * Returns the class data object that will be passed to `Lookup.defineHiddenClass`.
     * The classData is loaded in the <clinit> method of the generated class.
     * If the class data contains only one single object, this method returns  that single object.
     * If the class data contains more than one objects, this method returns a List.
     *
     * This method returns null if no class data.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10706

From iklam at openjdk.org  Tue Oct 18 05:24:00 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Oct 2022 05:24:00 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v3]
In-Reply-To: <3PBih6hbS-YlVOWr8fx0CPrVyPXqdy9k7oXI5rbfs1c=.f9f5d1d2-dd4c-4390-ae42-c6ba0120933a@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <GQEJ8MGflaAV-b8_JpE19SN9a9gZxy6Dt-ljbMSxf_w=.8e2fff78-2df9-4254-9a4d-71ccca3d508f@github.com>
 <3PBih6hbS-YlVOWr8fx0CPrVyPXqdy9k7oXI5rbfs1c=.f9f5d1d2-dd4c-4390-ae42-c6ba0120933a@github.com>
Message-ID: <a4WPM0Bsi0ZpIAExtUlffGRMre3p7tCoVKNcUrP_WGY=.e1582873-72d8-4e99-93f0-f4446f9817e3@github.com>

On Tue, 18 Oct 2022 02:03:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8295302-no-arraylist-for-single-classdata-for-lambdaform
>>  - @mlchung comments
>>  - @iwanowww comments
>>  - 8295302: Do not use ArrayList when LambdaForm has a single ClassData
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 346:
> 
>> 344: 
>> 345:     /**
>> 346:      * Returns an object to pass this.classData to the <clinit> method of the
> 
> What about:
> 
> Suggestion:
> 
>      * Returns the class data object that will be passed to `Lookup.defineHiddenClass`.
>      * The classData is loaded in the <clinit> method of the generated class.
>      * If the class data contains only one single object, this method returns  that single object.
>      * If the class data contains more than one objects, this method returns a List.
>      *
>      * This method returns null if no class data.

Actually, the classData is passed here:


    private MemberName loadMethod(byte[] classFile) {
        Class<?> invokerClass = LOOKUP.makeHiddenClassDefiner(className, classFile, Set.of())
                                      .defineClass(true, classDataValues());
        return resolveInvokerMember(invokerClass, invokerName, invokerType);
    }


So it doesn't go through `Lookup.defineHiddenClass`.

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From duke at openjdk.org  Tue Oct 18 07:31:07 2022
From: duke at openjdk.org (Strahinja Stanojevic)
Date: Tue, 18 Oct 2022 07:31:07 GMT
Subject: RFR: 8292914: Introduce a system property that enables stable
 names for lambda proxy classes [v3]
In-Reply-To: <iFFHsX25viGS5ReNPWevzElqy8ArqnHJfaz_qMf8mc0=.50faef18-ca1c-4c58-8a20-bfab7a5b190a@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
 <iFFHsX25viGS5ReNPWevzElqy8ArqnHJfaz_qMf8mc0=.50faef18-ca1c-4c58-8a20-bfab7a5b190a@github.com>
Message-ID: <1HRzo-tKL4lSwAuWnGaKwVHlYbAxER0XTLMHka642Ho=.05aff4fd-5622-421c-afe7-6104e261083d@github.com>

On Thu, 15 Sep 2022 11:50:57 GMT, Strahinja Stanojevic <duke at openjdk.org> wrote:

>> This PR introduces a system property that creates stable names for the lambda classes in the JDK. Instead of using an atomic counter in the lambda name, we can use a 32-bit hash after `$$Lambda$`. Thus, the name becomes `lambdaCapturingClass$$Lambda$hashValue`.
>> Parameters used to create a stable part of the name (hash value) are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During the stable name creation process,
>> all the common parameters are in the same form as in the low-level implementation (C part of the code) of the archiving process.
>> We concatenate all of those parameters in one string `hashData`. We calculate the long hash value for `hashData` in the same manner as the `java.lang.StringUTF16#hashCode` does, and then we hash that value using `Long.toString(longHashValue, Character.MAX_RADIX)`. The desired length for this hash is equal to the length of the `Long.toString(Long.MAX_VALUE, Character.MAX_RADIX)`.
>> Sometimes, the calculated hash value is shorter than the desired length, so we pad it with the character `#` to hit it. Appending `#` only affects the hash length, but not its stability.
>> 
>> Link to the related issue: https://bugs.openjdk.org/browse/JDK-8292914
>
> Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional parameter to hashCode, because in Scala, lambda can be serializable without implementing Serializable interface

Hello, any news regarding this PR? Is there anything else I should do on my side?

-------------

PR: https://git.openjdk.org/jdk/pull/10024

From duke at openjdk.org  Tue Oct 18 07:31:39 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 18 Oct 2022 07:31:39 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set
In-Reply-To: <ta_WoM2zhSAPAfwl8q-yV5QStN4dKRGwOzjuMMUZSbM=.0cb5aea2-f122-4199-a56d-37c2ffafa26e@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <9hMelZ_liGXfImiQMmOpGXHYFOUucPXdkEKUfgWjEco=.97179336-acc8-4ab1-a79b-ee89c7f9f1cf@github.com>
 <mJvZI6lbzGDW1zpHeFLJLrNZW2wxrxGwozeA1tcTUAk=.83a6bc0e-4ee0-4358-8f03-656be3e154f2@github.com>
 <pVFLFEWcUQJSiRZOtV3ogGQrs0ywIRD8_PVwLzemT5Q=.69cd5866-5289-47d1-9d18-3de9fce9e2c9@github.com>
 <RGvFgNbrNnnhOTiU4LOMB1W2P9vPVqeOYAo1Lsz61NM=.b5af66a2-0865-43c3-9967-9489dbd46568@github.com>
 <ta_WoM2zhSAPAfwl8q-yV5QStN4dKRGwOzjuMMUZSbM=.0cb5aea2-f122-4199-a56d-37c2ffafa26e@github.com>
Message-ID: <oGFurlyraivjPH0Vgtr-Vlm1HIgQzdGJcmCb2LWhCAA=.1c476951-400f-4326-8411-9a35d2958b03@github.com>

On Mon, 17 Oct 2022 11:14:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > @AlanBateman WDYT? Is such a test mandatory to include this rather simple PR?
>>> 
>>> I think it means checking that test/jdk/java/io/BufferedInputStream/TransferTo.java exercises this code path, I expect it should.
>>> 
>>> It might seem a "rather simple PR" but it leaks a reference to the internal buffer to the target and we need to get comfortable with that. It only does then when there is no mark (good) so this should mostly limit the concern to sources where EOF may be encountered more than once.
>> 
>> Which kind of sources would do that, and is there a way to check it and prevent it?
>> 
>> The whole issue points to an insufficiency in the API: it is lacking a way to transfer buffers in a read-only fashion (like NIO could do). I don't suppose we would want to change that, though, right?
>
>> Which kind of sources would do that, and is there a way to check it and prevent it?
>> 
>> The whole issue points to an insufficiency in the API: it is lacking a way to transfer buffers in a read-only fashion (like NIO could do). I don't suppose we would want to change that, though, right?
> 
> It can arise with many sources. One example is a program writing to a file and another reading from the same file and doing the equivalent of "tail -f". So yes, it is possible for transferTo to transfer >0 bytes after it a previous innovation has returned 0.

@AlanBateman To progress with this PR, what do you expect me to do? Do you want me to provide a test that proofs that this particular example will work fine? Or do you like me to simply copy the buffer instead of leaking it?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Tue Oct 18 07:48:04 2022
From: duke at openjdk.org (Strahinja Stanojevic)
Date: Tue, 18 Oct 2022 07:48:04 GMT
Subject: RFR: 8292914: Introduce a system property that enables stable
 names for lambda proxy classes
In-Reply-To: <yHc2sx--3vLcANEym5JWSCfHvsiLG1QyPgOoUmMhCgU=.940f943f-adb0-4568-9bde-74faec9c1703@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
 <yHc2sx--3vLcANEym5JWSCfHvsiLG1QyPgOoUmMhCgU=.940f943f-adb0-4568-9bde-74faec9c1703@github.com>
Message-ID: <QNaG9xOXVV0rglDWdEyDaZKcv4GXaN2ezyRhNri-qrU=.ef2fbd40-05a3-4e6b-9abe-34466fee94c4@github.com>

On Tue, 6 Sep 2022 16:47:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR introduces a system property that creates stable names for the lambda classes in the JDK. Instead of using an atomic counter in the lambda name, we can use a 32-bit hash after `$$Lambda$`. Thus, the name becomes `lambdaCapturingClass$$Lambda$hashValue`.
>> Parameters used to create a stable part of the name (hash value) are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During the stable name creation process,
>> all the common parameters are in the same form as in the low-level implementation (C part of the code) of the archiving process.
>> We concatenate all of those parameters in one string `hashData`. We calculate the long hash value for `hashData` in the same manner as the `java.lang.StringUTF16#hashCode` does, and then we hash that value using `Long.toString(longHashValue, Character.MAX_RADIX)`. The desired length for this hash is equal to the length of the `Long.toString(Long.MAX_VALUE, Character.MAX_RADIX)`.
>> Sometimes, the calculated hash value is shorter than the desired length, so we pad it with the character `#` to hit it. Appending `#` only affects the hash length, but not its stability.
>> 
>> Link to the related issue: https://bugs.openjdk.org/browse/JDK-8292914
>
> Have you tested with method references? Two references to the same method will result in a single `JVM_CONSTANT_InvokeDynamic` constant pool entry in the classfile, but it's invoked by two callsites. As a result, two different lambda proxy classes will be generated, as the JVMS requires the invokedynamic resolution to be per callsite, not per constantpool entry.
> 
> 
> public class ShareBSM {
>   public static void main(String args[]) {
>     doit1(ShareBSM::func);
>     doit2(ShareBSM::func);
>   }
>   static void func() {  Thread.dumpStack();  }
>   static void doit1(Runnable r) {  r.run();  }
>   static void doit2(Runnable r) {  r.run();  }
> }
> 
> 
> Here's the output:
> 
> 
> $ java -cp . -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames ShareBSM
> java.lang.Exception: Stack trace
> 	at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
> 	at ShareBSM.func(ShareBSM.java:8)
> 	at ShareBSM$$Lambda$1/0x0000000800c009f0.run(Unknown Source)
> 	at ShareBSM.doit1(ShareBSM.java:12)
> 	at ShareBSM.main(ShareBSM.java:3)
> java.lang.Exception: Stack trace
> 	at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
> 	at ShareBSM.func(ShareBSM.java:8)
> 	at ShareBSM$$Lambda$2/0x0000000800c00bf8.run(Unknown Source)
> 	at ShareBSM.doit2(ShareBSM.java:15)
> 	at ShareBSM.main(ShareBSM.java:4)
> 
> 
> Will you patch generate the same name for both callsites? Does this matter for your use case?

Hi @iklam, is there any additional work I can do on this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/10024

From alanb at openjdk.org  Tue Oct 18 08:23:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Oct 2022 08:23:59 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <6LT4v2rxH7XbvyIRezUx6WmcNEQ9oXRwwtF6so6Be0w=.6c90278f-ddd8-41e3-b3e5-aa50baa89ac9@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

The test is not the issue, it's that the proposal will require a security review. Yes, copying the bytes would remove that concern.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Tue Oct 18 08:24:00 2022
From: duke at openjdk.org (Markus KARG)
Date: Tue, 18 Oct 2022 08:24:00 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <6LT4v2rxH7XbvyIRezUx6WmcNEQ9oXRwwtF6so6Be0w=.6c90278f-ddd8-41e3-b3e5-aa50baa89ac9@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <6LT4v2rxH7XbvyIRezUx6WmcNEQ9oXRwwtF6so6Be0w=.6c90278f-ddd8-41e3-b3e5-aa50baa89ac9@github.com>
Message-ID: <QgTkcNwFp2-7XfG4lzw3NoMJAcOL8m5excx1sHZqYQc=.1caedeb8-ed2a-4dc7-8e18-024820383c94@github.com>

On Tue, 18 Oct 2022 08:17:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The test is not the issue, it's that the proposal will require a security review. Yes, copying the bytes would remove that concern.

Does "security review" mean, that I shall proof the absence of the problem, or does that term mean a formal process in the OpenJDK organization (and how do I trigger it)?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From jpai at openjdk.org  Tue Oct 18 09:34:47 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 18 Oct 2022 09:34:47 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v6]
In-Reply-To: <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
Message-ID: <PKuaybhxN84oCkg5JuIFQuVDD5JBA41ceDqQoY5z2To=.de1b3a51-9407-4435-990c-4da7e127a23b@github.com>

On Mon, 17 Oct 2022 15:32:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update filter docs to match implementation.

The latest state of this PR in `4449dda` looks good to me. Thank you Aleksei.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10578

From rgiulietti at openjdk.org  Tue Oct 18 10:00:12 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 18 Oct 2022 10:00:12 GMT
Subject: Integrated: 8294730: Add @throws and @implNote clauses to
 BigInteger::isProblablePrime and BigInteger::nextProblablePrime
In-Reply-To: <eAoP-aMiw7G89Wx41vKW2Kojilr7P1jZjYVnGym61Wc=.e2e2cc0a-58b3-4112-979f-9be473d02317@github.com>
References: <eAoP-aMiw7G89Wx41vKW2Kojilr7P1jZjYVnGym61Wc=.e2e2cc0a-58b3-4112-979f-9be473d02317@github.com>
Message-ID: <eFwreFqFsReqgcj-G_xB1TggK6a7Ko2OMuTLGCkreBc=.018ea30a-e4ae-48c6-bca6-d65046516811@github.com>

On Mon, 3 Oct 2022 18:32:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Completes the spec of [PR 10541](https://github.com/openjdk/jdk/pull/10541)

This pull request has now been integrated.

Changeset: 0b7d811c
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b7d811c98cb45a822b7ef56e5ee99d1b5483e78
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8294730: Add @throws and @implNote clauses to BigInteger::isProblablePrime and BigInteger::nextProblablePrime

Reviewed-by: darcy, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/10543

From coffeys at openjdk.org  Tue Oct 18 11:45:02 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 18 Oct 2022 11:45:02 GMT
Subject: Integrated: 8292177: InitialSecurityProperty JFR event
In-Reply-To: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
References: <QcSZl13oOGtQ7tNcjcmdQIDRe5ABJVR1SmlaAObLHSw=.27994f84-1003-4254-94f5-563ac65c820b@github.com>
Message-ID: <Rl862xTOhIUsE-DDxA6obudF2yZPG6fd4xXvCQSDH7Y=.dda72aad-6737-4246-9494-a1f4300aa2d4@github.com>

On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New JFR event to record state of initial security properties.
>  
> Debug output is also now added for these properties via -Djava.security.debug=properties

This pull request has now been integrated.

Changeset: 8c40b7dc
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c40b7dc8cd7b6a6d0c9349b991e0e01b69349c3
Stats:     393 lines in 12 files changed: 248 ins; 0 del; 145 mod

8292177: InitialSecurityProperty JFR event

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/10394

From dfuchs at openjdk.org  Tue Oct 18 13:03:31 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Oct 2022 13:03:31 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v6]
In-Reply-To: <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
 <yLAVqxuFjZ_CeQnSWbyTDhiltrxXYfPxNLySvNVUzU0=.f7d6d2ea-044d-44cf-b81c-b099995a0b5c@github.com>
Message-ID: <MNkZSXSe3DMkXbyWcyTvF8XQmw75WJ3nk4TTbpjjE_c=.10f4d62b-d612-4613-a338-734a082aec71@github.com>

On Mon, 17 Oct 2022 15:32:55 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> ### Summary of the change
>> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
>> 
>> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
>> 
>> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
>> 
>> Links:
>> 
>> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
>> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
>> 
>> ### List of code changes
>> 
>> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
>> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
>> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
>> 
>> #### NamingManagerHelper changes
>> Changes performed to construct the `NamingManagerHelper` class:
>> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
>> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
>> 
>> 
>> ### Test changes
>> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
>> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
>> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
>> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
>> 
>> ### Testing
>> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
>> No failures observed for the modified regression tests.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update filter docs to match implementation.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From abimpoudis at openjdk.org  Tue Oct 18 14:39:07 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 18 Oct 2022 14:39:07 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v5]
In-Reply-To: <BNOkejO3lWWtVdQ-F2zluGQD99tg6QH1T9N0qTipBww=.505b336d-977f-4335-bd59-98b0422be0a3@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <BNOkejO3lWWtVdQ-F2zluGQD99tg6QH1T9N0qTipBww=.505b336d-977f-4335-bd59-98b0422be0a3@github.com>
Message-ID: <WBRGY6VcdMFKesdDAF0u6n3vWVOASqKkmdxNCk4P4T0=.0f813b6e-d215-492c-bb9e-8afdb5985604@github.com>

On Tue, 4 Oct 2022 19:56:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While the floating-point == operation is *not* an equivalence relation, there are useful equivalence relations that can be defined over floating-point values. Text is added to java.lang.Double to discuss and name those relations.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck; reflow paragraphs.

src/java.base/share/classes/java/lang/Double.java line 172:

> 170:  *
> 171:  * <dt><i><a id=repEquivalence>representation equivalence</a></i>:</dt>
> 172:  * <dd>The two floating-point values represent the the same IEEE 754

~the~ the

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From dsamersoff at openjdk.org  Tue Oct 18 15:01:58 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 18 Oct 2022 15:01:58 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <bJLWHZ39M5EIkgSv6LA7kcbj44eXf9ZTpwHKwEV1Ouc=.d1188838-7aca-4d95-9627-6ba44a5e2f33@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

It's exactly what I'm trying to do - fix the broken logic around relaunch variable. 

We have couple of options here:

1. Decide re-launch/not-relaunch before processing arguments.
      - it's (IMHO) the best solution, but it requires significant refactor of the launcher.
      
2. Pass initial argv to the secondary launcher, which is re-launched and repeat argument processing. 
    -  it's what was implemented in this patch.
    
4. Let the secondary launcher know that the arguments was already processed.
    - to do this we need to use some kind of IPC: another environment variable; additional command-line option, which we will then remove etc.    
      @dholmes-ora if you think that this is the way, please advice - which method of such communication you prefer.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From forax at univ-mlv.fr  Tue Oct 18 15:04:56 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 18 Oct 2022 17:04:56 +0200 (CEST)
Subject: [External] : Re: New candidate JEP: 431: Sequenced Collections
In-Reply-To: <65da58eb-6d9b-1d3b-50c4-6a5ea9e6aafc@oracle.com>
References: <20221011231719.86821547E2D@eggemoggin.niobe.net>
 <1020834747.25340915.1665735651688.JavaMail.zimbra@u-pem.fr>
 <65da58eb-6d9b-1d3b-50c4-6a5ea9e6aafc@oracle.com>
Message-ID: <1390728427.28765698.1666105496447.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Stuart Marks" <stuart.marks at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, October 16, 2022 12:25:18 AM
> Subject: Re: [External] : Re: New candidate JEP: 431: Sequenced Collections

> Hi R?mi,
> 
> On 10/14/22 1:20 AM, Remi Forax wrote:
>> People will again think that i'm the grumpy guy but i prefer to voice my
>> concerns.
>> 
>> - nobody cares, i'm back from Devoxx and nobody cares about Sequenced
>> Collections, i've tried to ask several friends what they think about it and the
>> answer was "meh".
>>    The bar to introduce new interfaces in the collection API is really really high
>>    given how the Java ecosystem works.
>>    Once a library starts to use those interfaces as method parameter, it pressures
>>    the other library authors to write methods that provides object typed as those
>>    interfaces.
>>    Not enough people care and the cost for the community (not only Oracle) is high,
>>    it looks like a recipe for failure.
> 
> Fortunately, we don't make decisions in OpenJDK via opinion polls. :-)

We still have users tho.

> 
> I'm obviously not in a position to address the concerns of your interlocutors.
> However, the history in the bug database and the recurring discussions on
> core-libs-dev (some of which are linked in the JEP) show the need for this.

There are several feature requests that can be bundled into this JEP, but that not the only ways to implement those requests.

> 
> Introduction of new types always poses a dilemma for library maintainers. They
> can
> move forward aggressively and embrace new features, or they can remain on older
> releases in order to reach a broader audience. That's not a reason to avoid
> introducing new types.

I agree in absolute, but in this specific case you want to introduce interfaces deep into the existing hierarchy of interfaces, not on the top.
The introduction of CharSequence has been painful and very slow, that interface was added in 1.4 but we had to wait 9 more than 10 years later to have parseInt() that takes a CharSequence.
As an application developer, a decade is the kind of time i will have to wait before i can use a sequenced collection.

Adding default methods is far faster in term of adoption, computeIfAbsent or removeIf were available at the time of the release of 1.8.
Default methods have issues too, it only works if a good default implementation exists.

> 
>> - LinkedHashMap can be tweaked in two ways, by passing an access order as 3rd
>> parameter of the constructor or by overriding removeEldesEntry(), in both cases
>> the resulting LinkedHashMap is at odds with the contract of SequencedMap but
>> the compiler will happily allow to see those LinkedHashMap as SequencedMap.
> 
> SequencedMap specifies that entries have an encounter order but it doesn't make
> any
> requirements on how that order is established. LinkedHashMap's access-order mode
> is
> unusual in that it specifies that specific methods additionally have the side
> effect
> of reordering the relevant entry. The removeEldestEntry() method modifies the
> behavior of mapping-insertion methods to optionally remove the first ("eldest")
> entry. Neither of these behaviors conflicts with anything in SequencedMap.

It conflicts with the idea of the first element (or last element)
  SequencedSet set = ...
  var first = set.getFirst();
  assertNotNull(first);
  set.add("foo");
  var first2 = set.getFirst();
  assertEquals(first, first2);   // should always be true, right ?


> 
>> - LinkedHashMap/LinkedHashSet are dinosaurs, there are more efficient
>> implementations of the concepts of ordered set / ordered map both in term of
>> memory footprint and runtime execution, so adding new interfaces without
>> exploring new implementations using Valhalla value class and in relation with
>> the Collection Literal JEP seems premature to me.
> 
> LinkedHashMap and LinkedHashSet are in fact used fairly frequently. They're not
> used
> as much as HashMap, but they're used more than ArrayDeque or TreeMap. Presumably
> this is because people find LinkedHashMap/Set useful and that the overhead
> compared
> to their non-linked counterparts is acceptable for the additional services they
> provide.
> 
> The performance and footprint of LinkedHashMap/Set are not impacted either way
> by
> the JEP, nor are any potential future performance improvements (including those
> that
> might arise because of Valhalla) precluded by the JEP.

I don't disagree with all you say above, i'm saying that with Valhalla, we need to explore implementations of HashMap based on open addressing to get better cache performance.
So adding addFirst() to LinkedHashMap now, is a risk.

Also, addFirst on a sequenced collection is a dangerous method, exactly like List.get() is, depending on the implementation the worst case complexity can be either O(1) or O(n).
I believe we will all live in a better place if we do not add new methods with such "complexity range".

> 
> s'marks

regards,
R?mi

From ihse at openjdk.org  Tue Oct 18 15:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 15:45:01 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test code
Message-ID: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>

This is a continuation of the effort to update all our URLs to the new top-level domain.

This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.

I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

-------------

Commit messages:
 - 8295470: Update openjdk.java.net => openjdk.org URLs in test code

Changes: https://git.openjdk.org/jdk/pull/10744/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295470
  Stats: 138 lines in 45 files changed: 46 ins; 0 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/10744.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10744/head:pull/10744

PR: https://git.openjdk.org/jdk/pull/10744

From ihse at openjdk.org  Tue Oct 18 15:45:02 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Oct 2022 15:45:02 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <v3W5NeJ07ZOb3Q9438eICJZDJYgnGRzSmOSQ_YixhIM=.61781355-3c3b-4a8c-b18f-a64d71771dee@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

I noticed that a couple of files where missing copyright headers, when I tried to update those. I did some code archaeology and found out which year they were created, and added a copyright header.

Just to be reasonably sure that I did not affect any tests, I have let this go through the GHA and our internal CI testing tier1-3. The failed GHA test is `SuperWaitTest`, which I did not modify.

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From michaelm at openjdk.org  Tue Oct 18 16:03:57 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 18 Oct 2022 16:03:57 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <CfPkyYI0R_caEpiCxoTNMXatXKfS_8jk6xM0IzrMlFc=.881f4da4-2de8-4044-a51f-dfdd87ed360f@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

net changes look fine

-------------

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10744

From prr at openjdk.org  Tue Oct 18 16:51:10 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 18 Oct 2022 16:51:10 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <m0t2ZmdJ-yCzmpDu8zgql3thiOR8ea2bRlp9F1X6_ZM=.b720bff5-afdd-41e1-984a-be2b0bf95067@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From duke at openjdk.org  Tue Oct 18 17:05:08 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 17:05:08 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use data provider, drop exception

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/f750adb6..1cbca6eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=00-01

  Stats: 26 lines in 2 files changed: 5 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 17:05:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 17:05:09 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <EHnJYJ7PlmwIN4QzgGCeLbJC9izbrabKqvFUi6EF0A0=.08e0a8e6-1b9e-4cbc-8487-4dd77ce3c63d@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
 <EHnJYJ7PlmwIN4QzgGCeLbJC9izbrabKqvFUi6EF0A0=.08e0a8e6-1b9e-4cbc-8487-4dd77ce3c63d@github.com>
Message-ID: <DnK0vOBZI5AuZ8EQgWcY3TdyVi-IVqH2BOPPwEgzSyY=.90c07423-80a8-411b-a572-3ed04881208e@github.com>

On Mon, 17 Oct 2022 22:39:22 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicTestLauncher.java line 52:
>> 
>>> 50: 
>>> 51:     @Test
>>> 52:     public void testUsPac() throws IOException{
>> 
>> You could use a DataProvider
>
> I had the same thought

Thanks Lance and Brent, replaced it with a JUnit parametrized test (DataProvider equivalent)

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 17:05:11 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 17:05:11 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <1_0zYQdtVLNy6YOQIuFl8T-8n7i6FpRZmmMNL1GIrBg=.70d24a43-f0f0-46b3-a18e-8cb258b1ab23@github.com>
Message-ID: <iQHxcRZcIRnygmSKygD95ESkGGH8m4DdDeLYeHFpIiY=.8559724e-fd4e-4a46-bfb6-3381e3f51388@github.com>

On Mon, 17 Oct 2022 22:22:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 99:
> 
>> 97:         }catch(RuntimeException err){
>> 98:             throw new RuntimeException(String.format("$$$ %s: Test(s) failed or TestJVM did not build correctly." +
>> 99:                     " Check stderr output from diagnostics summary above%n",  err.getMessage()));
> 
> Do you need to catch the RuntimeException and then throw a new RuntimeException?  I think you might want to consider reworking this

Thank you Lance, I dropped the catch altogether as there is already enough info in the test log output

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From alanb at openjdk.org  Tue Oct 18 17:06:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Oct 2022 17:06:00 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <QgTkcNwFp2-7XfG4lzw3NoMJAcOL8m5excx1sHZqYQc=.1caedeb8-ed2a-4dc7-8e18-024820383c94@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <6LT4v2rxH7XbvyIRezUx6WmcNEQ9oXRwwtF6so6Be0w=.6c90278f-ddd8-41e3-b3e5-aa50baa89ac9@github.com>
 <QgTkcNwFp2-7XfG4lzw3NoMJAcOL8m5excx1sHZqYQc=.1caedeb8-ed2a-4dc7-8e18-024820383c94@github.com>
Message-ID: <k1088iY8oaczSdYv1LZne5QtmXqpOrFQLh093cm2qq4=.8df3cafc-e6e5-42ac-8ca2-b2410342a622@github.com>

On Tue, 18 Oct 2022 08:19:41 GMT, Markus KARG <duke at openjdk.org> wrote:

> Does "security review" mean, that I shall proof the absence of the problem, or does that term mean a formal process in the OpenJDK organization (and how do I trigger it)?

I sent a link to this PR to one of the security engineers and they share the concern. Have you done any performance testing with an implementation that makes a defensive copy?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From darcy at openjdk.org  Tue Oct 18 17:24:02 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Oct 2022 17:24:02 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <h2_NlmWAUfCsO8WRXBZKPYWb4jBgLGigcLgk15s97S4=.a0d0812b-0952-4bb0-828c-508a4304f048@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From bchristi at openjdk.org  Tue Oct 18 17:39:21 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 17:39:21 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
Message-ID: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>

On Tue, 18 Oct 2022 17:05:08 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use data provider, drop exception

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 93:

> 91:                                        + fail + " failure(s), first", first);
> 92:         else
> 93:             System.out.printf("all " + pass + " tests passed");

This line is missing a newline; add a \n, or use println().

test/jdk/java/util/Formatter/BasicTestLauncher.java line 35:

> 33:  * @summary Unit tests for formatter
> 34:  * @library /test/lib
> 35:  * @compile Basic.java

For the record, I've not deduced how/why the rest of the .java files in the test get compiled to .class files...

test/jdk/java/util/Formatter/BasicTestLauncher.java line 47:

> 45:     private static final String TZ_UP = "US/Pacific";
> 46:     // Asia/Novosibirsk time zone
> 47:     private static final String TZ_AN = "Asia/Novosibirsk";

IMO it's not necessary to create constants if they'll only be used as a ValueSource

test/jdk/java/util/Formatter/BasicTestLauncher.java line 49:

> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
> 48:     // Locale flag for testJVM
> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";

A name like "JAVA_OPTS" would better express how this value is used.

test/jdk/java/util/Formatter/BasicTestLauncher.java line 51:

> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";
> 50:     // Test class
> 51:     private static final String SOURCE_CLASS = "Basic";

This is the name of a compiled class to be run, not a source file, so perhaps, "TEST_CLASS"?

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From mchung at openjdk.org  Tue Oct 18 17:49:08 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 18 Oct 2022 17:49:08 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v3]
In-Reply-To: <a4WPM0Bsi0ZpIAExtUlffGRMre3p7tCoVKNcUrP_WGY=.e1582873-72d8-4e99-93f0-f4446f9817e3@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <GQEJ8MGflaAV-b8_JpE19SN9a9gZxy6Dt-ljbMSxf_w=.8e2fff78-2df9-4254-9a4d-71ccca3d508f@github.com>
 <3PBih6hbS-YlVOWr8fx0CPrVyPXqdy9k7oXI5rbfs1c=.f9f5d1d2-dd4c-4390-ae42-c6ba0120933a@github.com>
 <a4WPM0Bsi0ZpIAExtUlffGRMre3p7tCoVKNcUrP_WGY=.e1582873-72d8-4e99-93f0-f4446f9817e3@github.com>
Message-ID: <cjBzW5g7S8zLwA56juhGgBnqesUQtE1tjQda-WuYaJM=.c0350a87-7458-4cd2-a63e-2bd986568a65@github.com>

On Tue, 18 Oct 2022 05:21:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 346:
>> 
>>> 344: 
>>> 345:     /**
>>> 346:      * Returns an object to pass this.classData to the <clinit> method of the
>> 
>> What about:
>> 
>> Suggestion:
>> 
>>      * Returns the class data object that will be passed to `Lookup.defineHiddenClass`.
>>      * The classData is loaded in the <clinit> method of the generated class.
>>      * If the class data contains only one single object, this method returns  that single object.
>>      * If the class data contains more than one objects, this method returns a List.
>>      *
>>      * This method returns null if no class data.
>
> Actually, the classData is passed here:
> 
> 
>     private MemberName loadMethod(byte[] classFile) {
>         Class<?> invokerClass = LOOKUP.makeHiddenClassDefiner(className, classFile, Set.of())
>                                       .defineClass(true, classDataValues());
>         return resolveInvokerMember(invokerClass, invokerName, invokerType);
>     }
> 
> 
> So it doesn't go through `Lookup.defineHiddenClass`.

yes, it's an internal version that defines a hidden class, equivalent to calling `Lookup::defineHiddenClassWithClassData` (typo in my suggested wording), but it will bypass the security permission check and also returns the Class instead of Lookup (saving not to allocate a Lookup object).

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From naoto at openjdk.org  Tue Oct 18 17:52:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Oct 2022 17:52:06 GMT
Subject: RFR: 8295372: CompactNumberFormat handling of number one with decimal
 part
Message-ID: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>

Plurals were determined only by looking at the integer part of the compact number. Changed to consider the fraction digits as well.

-------------

Commit messages:
 - 8295372: CompactNumberFormat handling of number one with decimal part

Changes: https://git.openjdk.org/jdk/pull/10748/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10748&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295372
  Stats: 80 lines in 2 files changed: 35 ins; 2 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10748.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10748/head:pull/10748

PR: https://git.openjdk.org/jdk/pull/10748

From lancea at openjdk.org  Tue Oct 18 18:02:12 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:02:12 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
Message-ID: <Fa9Ns8kiIdrCq9QtyKEZqtq6t-FL7gFOMQMjtBoozQ0=.6bf20414-f30b-4f02-8254-bffd225e43a7@github.com>

On Tue, 18 Oct 2022 17:05:08 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use data provider, drop exception

Hi Justin,

We are getting close ;-) 

Please see below

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Tue Oct 18 18:02:13 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:02:13 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
Message-ID: <zQaCQeA5m8yDIg86oC_ggJHswNYPpN0Y0eu_ZpE6NSo=.7fdd7ec3-9178-4a6e-acf9-ae970f29a8d9@github.com>

On Tue, 18 Oct 2022 17:26:52 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/Basic.java line 93:
> 
>> 91:                                        + fail + " failure(s), first", first);
>> 92:         else
>> 93:             System.out.printf("all " + pass + " tests passed");
> 
> This line is missing a newline; add a \n, or use println().

I would suggest rewriting as System.out.printf("all %s tests passed%n", pass);

You could make a similar change to line 90 using String.format as done in the line 98 which was deleted

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 51:
> 
>> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";
>> 50:     // Test class
>> 51:     private static final String SOURCE_CLASS = "Basic";
> 
> This is the name of a compiled class to be run, not a source file, so perhaps, "TEST_CLASS"?

agree

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:09:18 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:09:18 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v3]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <H3jOjZm6D6XFrFadzkmwFln25NuyYWbfSkgQMsg-m88=.b5990ab5-41d9-4bc7-a787-7dd559aa8ea5@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Adjust constant names
 - Remove time zone constants (using ValueSource)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/1cbca6eb..bb01f86d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=01-02

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:09:19 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:09:19 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <zQaCQeA5m8yDIg86oC_ggJHswNYPpN0Y0eu_ZpE6NSo=.7fdd7ec3-9178-4a6e-acf9-ae970f29a8d9@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
 <zQaCQeA5m8yDIg86oC_ggJHswNYPpN0Y0eu_ZpE6NSo=.7fdd7ec3-9178-4a6e-acf9-ae970f29a8d9@github.com>
Message-ID: <XT0pOqfnmvL8SuNZNR5HATC1E3l08773JYX8WO8z4SM=.62c2a94e-a9e6-4be9-8274-1ebd9e99c300@github.com>

On Tue, 18 Oct 2022 17:49:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 93:
>> 
>>> 91:                                        + fail + " failure(s), first", first);
>>> 92:         else
>>> 93:             System.out.printf("all " + pass + " tests passed");
>> 
>> This line is missing a newline; add a \n, or use println().
>
> I would suggest rewriting as System.out.printf("all %s tests passed%n", pass);
> 
> You could make a similar change to line 90 using String.format as done in the line 98 which was deleted

I dropped the new line since when the output comes out of the sub process log

Without the newline it looks like 
[ ... ] 

vs

[...
]

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Tue Oct 18 18:09:20 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:09:20 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
Message-ID: <mCb3lV37VzGZjtbc2zn1IUPUgq5u6RWompBQtmofEAA=.1c0ae535-234a-4f4f-a8f9-0c562740793c@github.com>

On Tue, 18 Oct 2022 17:28:49 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 47:
> 
>> 45:     private static final String TZ_UP = "US/Pacific";
>> 46:     // Asia/Novosibirsk time zone
>> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
> 
> IMO it's not necessary to create constants if they'll only be used as a ValueSource

True, but really a personal choice as it makes the ValueSource less wordy ;-)

> test/jdk/java/util/Formatter/BasicTestLauncher.java line 49:
> 
>> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
>> 48:     // Locale flag for testJVM
>> 49:     private static final String LOCALE_PROV = "-Djava.locale.providers=CLDR";
> 
> A name like "JAVA_OPTS" would better express how this value is used.

agree

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:24:56 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:24:56 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v4]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust output formating in Basic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/bb01f86d..fe67e050

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Tue Oct 18 18:24:58 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 18:24:58 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
Message-ID: <j5QqnaWB9HgNP7REkX8kHB0dKJh1lGsF3MF8X0Fl__0=.b1922438-88e4-4bcc-934a-deb2eb94d3d8@github.com>

On Tue, 18 Oct 2022 17:36:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider, drop exception
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 35:
> 
>> 33:  * @summary Unit tests for formatter
>> 34:  * @library /test/lib
>> 35:  * @compile Basic.java
> 
> For the record, I've not deduced how/why the rest of the .java files in the test get compiled to .class files...

I suspect because the other classes are in the test.src directory they are being compiled which can be verified by Justin looking at the jtr log for the test

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 18:29:32 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 18:29:32 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v2]
In-Reply-To: <mCb3lV37VzGZjtbc2zn1IUPUgq5u6RWompBQtmofEAA=.1c0ae535-234a-4f4f-a8f9-0c562740793c@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <XYjc0Z2qhLdKCWPuEtZn11IWzSLw2Q1K1wJfUkasTI8=.b0506a0e-1697-4073-8011-2c950004fbcb@github.com>
 <x4vSO54bqYZH2RU2LchZaYRSrUNsO9Qc5TnYP516Uhg=.1fa24952-29f3-4982-82b6-80f97d63f786@github.com>
 <mCb3lV37VzGZjtbc2zn1IUPUgq5u6RWompBQtmofEAA=.1c0ae535-234a-4f4f-a8f9-0c562740793c@github.com>
Message-ID: <ODHnFhRHM-zY2NrPHQ1luXFCxOqGsG3uTiX8mdLICxw=.9563b312-0472-4ef3-b24e-1ea701d95b2c@github.com>

On Tue, 18 Oct 2022 18:03:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicTestLauncher.java line 47:
>> 
>>> 45:     private static final String TZ_UP = "US/Pacific";
>>> 46:     // Asia/Novosibirsk time zone
>>> 47:     private static final String TZ_AN = "Asia/Novosibirsk";
>> 
>> IMO it's not necessary to create constants if they'll only be used as a ValueSource
>
> True, but really a personal choice as it makes the ValueSource less wordy ;-)

Also, when reading through a ValueSource / DataProvider, it's nice to see the actual values (vs variable/constant names) when practical/possible.

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 18:52:04 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 18:52:04 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v4]
In-Reply-To: <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
Message-ID: <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>

On Tue, 18 Oct 2022 18:24:56 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output formating in Basic

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 93:

> 91:                     ", first" , fail+pass, fail), first);
> 92:         else
> 93:             System.out.printf("All %s tests passed", pass);

%d, yes?

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:54:58 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:54:58 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v5]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <xmij-VRlk_6LiEbmponaHufTxW1xnCpG2t889DCqViU=.1315a7a5-5dc9-4177-a700-023243f4499f@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Add curly braces to Basic if else

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/fe67e050..5b9225c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=03-04

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 18:56:31 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 18:56:31 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v4]
In-Reply-To: <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
 <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>
Message-ID: <YM3u5g-fkHasZC94xv5F-OEzmwlTc0WwNLc3MIdMfpw=.a157e5e2-d260-44c7-b1c6-2f6a5bc7e841@github.com>

On Tue, 18 Oct 2022 18:46:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust output formating in Basic
>
> test/jdk/java/util/Formatter/Basic.java line 93:
> 
>> 91:                     ", first" , fail+pass, fail), first);
>> 92:         else
>> 93:             System.out.printf("All %s tests passed", pass);
> 
> %d, yes?

Right, will change that

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 19:04:29 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 19:04:29 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v6]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Remove testing change
 - Fix formatter in Basic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/5b9225c9..9483f16c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:04:30 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:04:30 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v4]
In-Reply-To: <YM3u5g-fkHasZC94xv5F-OEzmwlTc0WwNLc3MIdMfpw=.a157e5e2-d260-44c7-b1c6-2f6a5bc7e841@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ba8hin2ibyC2zyw_EdAsar8SQNc9GRaDswv5HZaHzAQ=.2ed024ba-7e63-4871-a544-856b5304301f@github.com>
 <A_qrSB_ft6hCQ0mqau-_JPLgGJYFOQUJyvbXSqvFrRc=.1154e396-40ed-413d-a0c6-3e69d4e7f1c1@github.com>
 <YM3u5g-fkHasZC94xv5F-OEzmwlTc0WwNLc3MIdMfpw=.a157e5e2-d260-44c7-b1c6-2f6a5bc7e841@github.com>
Message-ID: <o7sVHNzkm9DCDXtA3g9YEOsjTNHggOcDDEudR-mkkfQ=.221db7bf-9242-4234-ae71-f7503ec4433c@github.com>

On Tue, 18 Oct 2022 18:54:03 GMT, Justin Lu <duke at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 93:
>> 
>>> 91:                     ", first" , fail+pass, fail), first);
>>> 92:         else
>>> 93:             System.out.printf("All %s tests passed", pass);
>> 
>> %d, yes?
>
> Right, will change that

And one on the previous line

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:04:29 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:04:29 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v5]
In-Reply-To: <xmij-VRlk_6LiEbmponaHufTxW1xnCpG2t889DCqViU=.1315a7a5-5dc9-4177-a700-023243f4499f@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <xmij-VRlk_6LiEbmponaHufTxW1xnCpG2t889DCqViU=.1315a7a5-5dc9-4177-a700-023243f4499f@github.com>
Message-ID: <mYhmreOPyZGrb8pwOu7AS8fYit6nOj4_PQsSHFaw1Dg=.688d0af8-ad6d-4da8-a5e4-16b16d57688e@github.com>

On Tue, 18 Oct 2022 18:54:58 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add curly braces to Basic if else

Changes requested by bchristi (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:14:16 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:14:16 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <DyBtVRxm3XlzIgDXAVuvezh8TO3eIFRfWf7sEBruqw8=.c3a2b31a-576e-4aea-a322-6b236ccf77c3@github.com>

On Thu, 13 Oct 2022 01:02:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

Changes requested by bchristi (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From bchristi at openjdk.org  Tue Oct 18 19:14:17 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:14:17 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
Message-ID: <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>

On Fri, 14 Oct 2022 00:37:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> test/jdk/java/util/Formatter/BasicByteObject.java line 232:
> 
>> 230: 
>> 231:     private static Byte negate(Byte v) {
>> 232:         return (byte) -v.byteValue();
> 
> We want to be returning a `Byte`, so casting to `(byte)` doesn't seem right to me.
> 
> `Byte.valueOf()` takes a `byte` and returns a `Byte`, so using that as the replacement for `new Byte`, we get:
> `return Byte.valueOf(-v.byteValue());`
> Is there a way to get the template to do that?

So, the above suggestion gives explicit auto-boxing, though some might find it wordier than necessary.

Since `v.byteValue()` already returns a `byte`, the `(byte)` cast doesn't seem necessary. I see that L242 does:
> `return -v.intValue();`

which is a pretty clean look. So `return -v.byteValue();` would be an option, too.

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From bchristi at openjdk.org  Tue Oct 18 19:24:45 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:24:45 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v6]
In-Reply-To: <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
Message-ID: <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>

On Tue, 18 Oct 2022 19:04:29 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove testing change
>  - Fix formatter in Basic

Changes requested by bchristi (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 90:

> 88: 
> 89:         if (fail != 0) {
> 90:             throw new RuntimeException(String.format("%d tests: %d failure(s)" +

You might consider including `", first"` with the rest of the message string, instead of concatenating it. That line might end up slightly long, but it may be worth it.

Also, use `%s` for`first`, as it's a `Throwable` ;)
(You could also perhaps change `first` -> `first.toString()` in the final argument to format, to clarify.)

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 19:28:52 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 19:28:52 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v6]
In-Reply-To: <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
 <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
Message-ID: <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>

On Tue, 18 Oct 2022 19:20:58 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove testing change
>>  - Fix formatter in Basic
>
> test/jdk/java/util/Formatter/Basic.java line 90:
> 
>> 88: 
>> 89:         if (fail != 0) {
>> 90:             throw new RuntimeException(String.format("%d tests: %d failure(s)" +
> 
> You might consider including `", first"` with the rest of the message string, instead of concatenating it. That line might end up slightly long, but it may be worth it.
> 
> Also, use `%s` for`first`, as it's a `Throwable` ;)
> (You could also perhaps change `first` -> `first.toString()` in the final argument to format, to clarify.)

Good point, will reassign it to one line.

"Also, use %s forfirst, as it's a Throwable", 
I believe I am assigning %d to pass+fail and fail. I pass first as a Throwable to the runtime exception constructor.

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From bchristi at openjdk.org  Tue Oct 18 19:41:05 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:41:05 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v6]
In-Reply-To: <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
 <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
 <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>
Message-ID: <C4YrbILqOwzVtX3g0B5g9Q7BVFCNpBG3eLFLhMPjGT8=.32540bb8-f33e-4d14-901b-c397f306b114@github.com>

On Tue, 18 Oct 2022 19:25:01 GMT, Justin Lu <duke at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/Basic.java line 90:
>> 
>>> 88: 
>>> 89:         if (fail != 0) {
>>> 90:             throw new RuntimeException(String.format("%d tests: %d failure(s)" +
>> 
>> You might consider including `", first"` with the rest of the message string, instead of concatenating it. That line might end up slightly long, but it may be worth it.
>> 
>> Also, use `%s` for`first`, as it's a `Throwable` ;)
>> (You could also perhaps change `first` -> `first.toString()` in the final argument to format, to clarify.)
>
> Good point, will reassign it to one line.
> 
> "Also, use %s forfirst, as it's a Throwable", 
> I believe I am assigning %d to pass+fail and fail. I pass first as a Throwable to the runtime exception constructor.

Oh, right. Carry on.

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Tue Oct 18 19:52:01 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 19:52:01 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
 <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>
Message-ID: <jwZy6LBJu3MbIM4rk6W3w1lMzsVE95Avv8NXOsG08yI=.83c3f2c6-17dd-43b5-9c42-169775ed3a91@github.com>

On Tue, 18 Oct 2022 19:10:00 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicByteObject.java line 232:
>> 
>>> 230: 
>>> 231:     private static Byte negate(Byte v) {
>>> 232:         return (byte) -v.byteValue();
>> 
>> We want to be returning a `Byte`, so casting to `(byte)` doesn't seem right to me.
>> 
>> `Byte.valueOf()` takes a `byte` and returns a `Byte`, so using that as the replacement for `new Byte`, we get:
>> `return Byte.valueOf(-v.byteValue());`
>> Is there a way to get the template to do that?
>
> So, the above suggestion gives explicit auto-boxing, though some might find it wordier than necessary.
> 
> Since `v.byteValue()` already returns a `byte`, the `(byte)` cast doesn't seem necessary. I see that L242 does:
>> `return -v.intValue();`
> 
> which is a pretty clean look. So `return -v.byteValue();` would be an option, too.

Negating v.byteValue() promotes it into an int. So then casting to byte would be necessary.

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From mchhipa at openjdk.org  Tue Oct 18 19:56:22 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 18 Oct 2022 19:56:22 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
Message-ID: <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>

On Mon, 17 Oct 2022 16:57:06 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertThrows an exception in InconsistentEntries test.

test/jdk/javax/crypto/CryptoPermissions/default_local.policy line 4:

> 2:     permission javax.crypto.CryptoAllPermission;
> 3:     permission javax.crypto.CryptoPermission "DES", 64;
> 4: }

please remove extra line.

test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 46:

> 44:  * @summary standard extensions path is hard-coded in default
> 45:  *      system policy file
> 46:  *

No need to repeat these statement again.

test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 54:

> 52:  * @bug 4993819
> 53:  * @summary standard extensions path is hard-coded in default
> 54:  *      system policy file

No need to repeat these statement.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From bchristi at openjdk.org  Tue Oct 18 19:59:08 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 18 Oct 2022 19:59:08 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <jwZy6LBJu3MbIM4rk6W3w1lMzsVE95Avv8NXOsG08yI=.83c3f2c6-17dd-43b5-9c42-169775ed3a91@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <SixYTZS5KOlQJmtq9VacmWvRn80O4x76VvjZn5X8yII=.578843f4-06b9-4ffc-aef2-5b3570eb1263@github.com>
 <3u_74MLLkI-yUgNgR5JnSEhmezKCVaw16T_BZuNX9dA=.7b0049e2-6cec-4080-a37e-5398851221a6@github.com>
 <jwZy6LBJu3MbIM4rk6W3w1lMzsVE95Avv8NXOsG08yI=.83c3f2c6-17dd-43b5-9c42-169775ed3a91@github.com>
Message-ID: <9_CUfgZm7LqpDpuhaArfmVRjgzdl7eIjaDvNFV-sVv0=.bbf823eb-6f31-4be5-b003-e929434150bd@github.com>

On Tue, 18 Oct 2022 19:48:15 GMT, Justin Lu <duke at openjdk.org> wrote:

>> So, the above suggestion gives explicit auto-boxing, though some might find it wordier than necessary.
>> 
>> Since `v.byteValue()` already returns a `byte`, the `(byte)` cast doesn't seem necessary. I see that L242 does:
>>> `return -v.intValue();`
>> 
>> which is a pretty clean look. So `return -v.byteValue();` would be an option, too.
>
> Negating v.byteValue() promotes it into an int. So then casting to byte would be necessary.

Oh yeah...oops.

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From mchhipa at openjdk.org  Tue Oct 18 19:59:22 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 18 Oct 2022 19:59:22 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
Message-ID: <dQ470QgtAwC38FFw4ER0Pe6HVlVU6l2qNRcxHKN8u_A=.10932b33-291e-43e7-8f8f-befd740facf7@github.com>

On Mon, 17 Oct 2022 16:57:06 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertThrows an exception in InconsistentEntries test.

Looks good to me. Please update few formatting related comments.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From aturbanov at openjdk.org  Tue Oct 18 20:17:04 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 18 Oct 2022 20:17:04 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v3]
In-Reply-To: <GQEJ8MGflaAV-b8_JpE19SN9a9gZxy6Dt-ljbMSxf_w=.8e2fff78-2df9-4254-9a4d-71ccca3d508f@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <GQEJ8MGflaAV-b8_JpE19SN9a9gZxy6Dt-ljbMSxf_w=.8e2fff78-2df9-4254-9a4d-71ccca3d508f@github.com>
Message-ID: <lxYjQ3Y0cPPgVOyAmzh-ZZKEjSGpMWpZUqIy0R09x9Y=.3c0e79b1-2c75-440f-aa98-40d470f8ac02@github.com>

On Mon, 17 Oct 2022 21:48:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8295302-no-arraylist-for-single-classdata-for-lambdaform
>  - @mlchung comments
>  - @iwanowww comments
>  - 8295302: Do not use ArrayList when LambdaForm has a single ClassData

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 352:

> 350:     private Object classDataValues() {
> 351:         final List<ClassData> cd = classData;
> 352:         return switch(cd.size()) {

Suggestion:

        return switch (cd.size()) {

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From duke at openjdk.org  Tue Oct 18 20:26:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 20:26:09 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v7]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <arbJeJtZZMwY15VAB6FBA0Ua_b4wbD0ww5CMIENhRiM=.53079b27-4f6d-4667-9bfb-eeebdaad6204@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove @compile
  
  Everything under test.src compiled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/9483f16c..81fc6a31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From darcy at openjdk.org  Tue Oct 18 20:27:06 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Oct 2022 20:27:06 GMT
Subject: RFR: JDK-8294539: Augment discussion of equivalence relations on
 floating-point values [v5]
In-Reply-To: <WBRGY6VcdMFKesdDAF0u6n3vWVOASqKkmdxNCk4P4T0=.0f813b6e-d215-492c-bb9e-8afdb5985604@github.com>
References: <IFvazBhQBWfMUqr0aTvIJ-P4XyhGx4c93vSUsTjh4bU=.8b32592f-ccbf-437e-ab90-1e0902fd437c@github.com>
 <BNOkejO3lWWtVdQ-F2zluGQD99tg6QH1T9N0qTipBww=.505b336d-977f-4335-bd59-98b0422be0a3@github.com>
 <WBRGY6VcdMFKesdDAF0u6n3vWVOASqKkmdxNCk4P4T0=.0f813b6e-d215-492c-bb9e-8afdb5985604@github.com>
Message-ID: <DwxW89WSqW2l-JZug_rTzhtiyyPtBbpxs-S2pSkGHe4=.5d41a58b-5592-45bd-9498-102e3f9234ac@github.com>

On Tue, 18 Oct 2022 14:35:14 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Appease jcheck; reflow paragraphs.
>
> src/java.base/share/classes/java/lang/Double.java line 172:
> 
>> 170:  *
>> 171:  * <dt><i><a id=repEquivalence>representation equivalence</a></i>:</dt>
>> 172:  * <dd>The two floating-point values represent the the same IEEE 754
> 
> ~the~ the

Thanks; filed JDK-8295517.

-------------

PR: https://git.openjdk.org/jdk/pull/10498

From joehw at openjdk.org  Tue Oct 18 20:29:04 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 18 Oct 2022 20:29:04 GMT
Subject: RFR: 8295372: CompactNumberFormat handling of number one with
 decimal part
In-Reply-To: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
References: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
Message-ID: <5csrI7j110kB1pY6AKViyN9833k_XuAy8yOAkqnKLX0=.72100841-a977-4a5b-94a0-5e39bdf982ca@github.com>

On Tue, 18 Oct 2022 17:44:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Plurals were determined only by looking at the integer part of the compact number. Changed to consider the fraction digits as well.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10748

From darcy at openjdk.org  Tue Oct 18 20:36:42 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Oct 2022 20:36:42 GMT
Subject: RFR: JDK-8295517: Fix stutter typo in JDK-8294539
Message-ID: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>

"the the" -> "the"

I'll reflow the paragraph before pushing.

-------------

Commit messages:
 - JDK-8295517: Fix stutter typo in JDK-8294539

Changes: https://git.openjdk.org/jdk/pull/10750/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10750&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295517
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10750.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10750/head:pull/10750

PR: https://git.openjdk.org/jdk/pull/10750

From naoto at openjdk.org  Tue Oct 18 20:47:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Oct 2022 20:47:10 GMT
Subject: RFR: JDK-8295517: Fix stutter typo in JDK-8294539
In-Reply-To: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
References: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
Message-ID: <Or5nALEk3PRzyZJkhkxjiYoC-BXw25OMXRYdq3CIAdg=.c5c1300f-146e-4afd-a631-f3cd80cfa447@github.com>

On Tue, 18 Oct 2022 20:27:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> "the the" -> "the"
> 
> I'll reflow the paragraph before pushing.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10750

From bpb at openjdk.org  Tue Oct 18 20:56:49 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Oct 2022 20:56:49 GMT
Subject: RFR: JDK-8295517: Fix stutter typo in JDK-8294539
In-Reply-To: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
References: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
Message-ID: <8jUFFwvRZ1ThvU9Xsa47EWLUC5hzeUfgXGJVu5HCB_c=.58683ac1-ebc0-4671-906b-e684174da36b@github.com>

On Tue, 18 Oct 2022 20:27:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> "the the" -> "the"
> 
> I'll reflow the paragraph before pushing.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10750

From naoto at openjdk.org  Tue Oct 18 21:02:09 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Oct 2022 21:02:09 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v6]
In-Reply-To: <C4YrbILqOwzVtX3g0B5g9Q7BVFCNpBG3eLFLhMPjGT8=.32540bb8-f33e-4d14-901b-c397f306b114@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Upv8p-hGpmW9nA8Nphlxdj4srZt91skT0_ZO1kg85f0=.8f0ab380-1694-4449-9a05-2189ceb3b736@github.com>
 <bFhaOSfNVyDnmHMAfTu2f_uj_Rs7l-YmryyoJDzlt0s=.6f7f1f79-a768-4e41-ba63-eaba4804e981@github.com>
 <nfbc6yKQD6JvZG45WtW9fU5LHw9NUAw5yeNiu9nA2YA=.58823605-49e5-4c00-ab90-06ddcba2a6c5@github.com>
 <C4YrbILqOwzVtX3g0B5g9Q7BVFCNpBG3eLFLhMPjGT8=.32540bb8-f33e-4d14-901b-c397f306b114@github.com>
Message-ID: <9KAHQ-aN7Jj_Yg7l-MEWpvQszQV6me8wf3_zPNyIWUU=.5992304c-a786-4177-88b9-926a4cb25d8e@github.com>

On Tue, 18 Oct 2022 19:37:17 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Good point, will reassign it to one line.
>> 
>> "Also, use %s forfirst, as it's a Throwable", 
>> I believe I am assigning %d to pass+fail and fail. I pass first as a Throwable to the runtime exception constructor.
>
> Oh, right. Carry on.

Instead of using String.format() static method, using "...".formatted() is slightly shorter/concise.

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From darcy at openjdk.org  Tue Oct 18 21:03:22 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Oct 2022 21:03:22 GMT
Subject: RFR: JDK-8295517: Fix stutter typo in JDK-8294539 [v2]
In-Reply-To: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
References: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
Message-ID: <1C_YjfTMM2gdzRGNn-_DfLGw_7c4gmEg9IeO7Mpf2wc=.c50a0e48-e26d-4f6f-9704-9a1454d63256@github.com>

> "the the" -> "the"
> 
> I'll reflow the paragraph before pushing.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Reflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10750/files
  - new: https://git.openjdk.org/jdk/pull/10750/files/da960757..6fb1aa2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10750&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10750&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10750.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10750/head:pull/10750

PR: https://git.openjdk.org/jdk/pull/10750

From lancea at openjdk.org  Tue Oct 18 21:03:22 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Oct 2022 21:03:22 GMT
Subject: RFR: JDK-8295517: Fix stutter typo in JDK-8294539 [v2]
In-Reply-To: <1C_YjfTMM2gdzRGNn-_DfLGw_7c4gmEg9IeO7Mpf2wc=.c50a0e48-e26d-4f6f-9704-9a1454d63256@github.com>
References: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
 <1C_YjfTMM2gdzRGNn-_DfLGw_7c4gmEg9IeO7Mpf2wc=.c50a0e48-e26d-4f6f-9704-9a1454d63256@github.com>
Message-ID: <cxJRrBapwv3WazU4COKL7A6K9esqZeQh-1OpOU3FKzk=.6079e7a2-380b-41fd-8f76-7e484b6728d5@github.com>

On Tue, 18 Oct 2022 20:59:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> "the the" -> "the"
>> 
>> I'll reflow the paragraph before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflow

looks looks good good ;-)

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10750

From darcy at openjdk.org  Tue Oct 18 21:05:06 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Oct 2022 21:05:06 GMT
Subject: Integrated: JDK-8295517: Fix stutter typo in JDK-8294539
In-Reply-To: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
References: <jaC2uiu_dNmHAgdhirLHHoRohgAGiPpQnNRaqGDwwno=.3fbe3857-1b58-4be6-b6d6-d6a99fb71c06@github.com>
Message-ID: <unKRa0lORYtGPWj8FxsViKXbkwcRMii3NugbCu7MEzw=.67f5904d-6d5b-4c2a-bae0-e8be5884ea9d@github.com>

On Tue, 18 Oct 2022 20:27:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> "the the" -> "the"
> 
> I'll reflow the paragraph before pushing.

This pull request has now been integrated.

Changeset: 95baf83d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95baf83dd60cc50d30b6b240618f17d296780548
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8295517: Fix stutter typo in JDK-8294539

Reviewed-by: naoto, bpb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/10750

From duke at openjdk.org  Tue Oct 18 21:26:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 21:26:09 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v8]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <D-3bUqCk6VJu-Jp5ZyKaARQNfWZ1gFHH0d4tHX5Xbw8=.b9be98ce-85aa-47d6-9054-7f2b399e87f0@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Add all BasicXXX files to @compile for clarity

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/81fc6a31..00c32ee2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=06-07

  Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From bhuang at openjdk.org  Tue Oct 18 22:16:47 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 18 Oct 2022 22:16:47 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
 <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
Message-ID: <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>

On Tue, 18 Oct 2022 19:53:50 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AssertThrows an exception in InconsistentEntries test.
>
> test/jdk/javax/crypto/CryptoPermissions/default_local.policy line 4:
> 
>> 2:     permission javax.crypto.CryptoAllPermission;
>> 3:     permission javax.crypto.CryptoPermission "DES", 64;
>> 4: }
> 
> please remove extra line.

I double-checked, there is no extra line at the end of this file.

> test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 46:
> 
>> 44:  * @summary standard extensions path is hard-coded in default
>> 45:  *      system policy file
>> 46:  *
> 
> No need to repeat these statement again.

Are you saying that we don't need to run the ExtDir2.policy and ExtDir3.policy?

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From duke at openjdk.org  Tue Oct 18 23:03:16 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 18 Oct 2022 23:03:16 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v9]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Additional cleanup and string formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/00c32ee2..56eae09a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=07-08

  Stats: 19 lines in 2 files changed: 5 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From kamil at sevecek.net  Tue Oct 18 08:35:22 2022
From: kamil at sevecek.net (=?UTF-8?B?S2FtaWwgxaBldmXEjWVr?=)
Date: Tue, 18 Oct 2022 10:35:22 +0200
Subject: JEP400 vs new Scanner(System.in)
In-Reply-To: <AF424E7E-5B47-4E27-AB3E-BBE54DCB410E@oracle.com>
References: <CAK6PxWOtEndtbecUdr1Pgw=O4_9iq_kupCPzFgA5t+aFSrVV5g@mail.gmail.com>
 <AF424E7E-5B47-4E27-AB3E-BBE54DCB410E@oracle.com>
Message-ID: <CALMVAEq_oZdW0XtMfQHcnaUYP7ybEt4RwHe=RE5QSszn1v6cHA@mail.gmail.com>

Hi!

Perhaps core-libs-dev is the more appropriate mailing list, but there are
hundreds of posts a month there. I'm not sure whether the severity of the
problem would require a more fundamental solution. So I will reply here as
well, because I see that Brian Goetz reviewed and endorsed the JEP-400 and
I would like to see him endorsing a rescue action as well to keep my trust
in the Java platform.
If there is a higher priority than CRITICAL, then this is the case.
If left as it is, this JEP will completely ruin Java as a starting language
because no simple beginner's example from the web will work anymore and any
new will look extremely complicated. Reinier described it very
realistically.

Just a side note for the java.io.Console: This class does not work in IDEs.
System.console() returns null in IDEs. It only works when Java is invoked
from the native OS console. Therefore it is very much useless.

? Kamil Sevecek

On Thu, 13 Oct 2022 at 19:07, Ron Pressler <ron.pressler at oracle.com> wrote:

> Hi.
>
> The appropriate list is core-libs-dev, where this discussion should
> continue.
>
> System.in is the standard input, which may or may not be the keyboard. For
> keyboard input, take a look at the java.io.Console class [1], in particular
> its charset and reader methods.
>
> [1]:
> https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/io/Console.html
>
> ? Ron
>
> On 13 Oct 2022, at 16:20, Reinier Zwitserloot <reinier at zwitserloot.com>
> wrote:
>
> PREAMBLE: I?m not entirely certain amber-dev is the appropriate venue. If
> not, where should this be discussed? It?s not quite a bug but nearly so,
> and not quite a simple feature request either.
>
> JDK18 brought JEP400 which changes the default charset encoding to UTF-8.
> This, probably out of necessity, goes quite far, in that
> Charset.defaultCharset() is now more or less a constant - always returns
> UTF_8. It?s now quite difficult to retrieve the OS-configured encoding (the
> ?native? encoding).
>
> However, that does mean one of the most common lines in all of java?s
> history, is now necessarily buggy: new Scanner(System.in) is now broken.
> Always, unless your docs specifically state that you must feed the app
> UTF_8 data. Linting tools ought to flag it down as incorrect. It?s
> incorrect In a nasty way too: Initially it seems to work fine, but if
> you?re on an OS whose native encoding isn?t UTF-8, this is subtly broken;
> enter non-ASCII characters on the command line and the app doesn?t handle
> them appropriately. A bug that is literally utterly undiscoverable on macs
> and most linux computers, even. How can you figure out your code is broken
> if all the machines you test it on use UTF-8 as an OS default?
>
> This affects beginning java programmers particularly (who tend to be
> writing some command line-interactive apps at first). In light of Brian
> Goetz?s post ?Paving the Onramp? (
> https://openjdk.org/projects/amber/design-notes/on-ramp) - the experience
> for new users is evidently of some importance to the OpenJDK team. In light
> of that, the current state of writing command line interactive java apps is
> inconsistent with that goal.
>
> The right way to read system input in a way that works in both pre- and
> post-JEP400 JVM editions appears to be, as far as I can tell:
>
> Charset nativeCharset = Charset.forName(System.getProperty("native.encoding", Charset.defaultEncoding().name());
> Scanner sc = new Scanner(System.in, nativeCharset);
>
>
> I?ll risk the hyperbole: That?s.. atrocious. Hopefully I?m missing
> something!
>
> Breaking _thousands_ of blogs, tutorials, stack overflow answers, and
> books in the process, everything that contains new Scanner(System.in).
> Even sysin interaction that doesn?t use scanner is likely broken; the
> general strategy then becomes:
>
> new InputStreamReader(System.in);
>
>
> which suffers from the same problem.
>
> I see a few directions for trying to address this; I?m not quite sure
> which way would be most appropriate:
>
>
>    - Completely re-work keyboard input, in light of *Paving the on-ramp*.
>    Scanner has always been a problematic API if used for keyboard input, in
>    that the default delimiter isn?t convenient. I think the single most common
>    beginner java stackoverflow question is the bizarre interaction between
>    scanner?s nextLine() and scanner?s next(), and to make matters
>    considerably worse, the proper fix (which is to call
>    .useDelimiter(?\\R?) on the scanner first) is said in less than 1% of
>    answers; the vast majority of tutorials and answers tell you to call
>    .nextLine() after every .nextX() call. A suboptimal suggestion (it now
>    means using space to delimit your input is broken). Scanner is now also
>    quite inconsistent: The constructor goes for ?internet standard?, using
>    UTF-8 as a default even if the OS does not, but the locale *does* go
>    by platform default, which affects double parsing amongst other things:
>    scanner.nextDouble() will require you to use commas as fractions
>    separator if your OS is configured to use the Dutch locale, for example.
>    It?s weird that scanner neither fully follows common platform-independent
>    expectations (english locale, UTF-8), nor local-platform expectation
>    (OS-configured locale and OS-configured charset). One way out is to make a
>    new API for ?command line apps? and take into account Paving the on-ramp?s
>    plans when designing it.
>    - Rewrite specifically the new Scanner(InputStream) constructor as
>    defaulting to native encoding even when everything else in java defaults to
>    UTF-8 now, because that constructor is 99% used for System.in. Scanner
>    has its own File-based constructor, so new
>    Scanner(Files.newInputStream(..)) is quite rare.
>    - Define that constructor to act as follows: the charset used is the
>    platform default (i.e., from JDK18 and up, UTF-8), *unless* arg ==
>    System.in is true, in which case the scanner uses native encoding.
>    This is a bit bizarre to write in the spec but does the right thing in the
>    most circumstances and unbreaks thousands of tutorials, blogs, and answer
>    sites, and is most convenient to code against. That?s usually the case with
>    voodoo magic (because this surely risks being ?too magical?): It?s
>    convenient and does the right thing almost always, at the risk of being
>    hard to fathom and producing convoluted spec documentation.
>    - Attach the problem that what?s really broken isn?t so much scanner,
>    it?s System.in itself: byte based, of course, but now that all java
>    methods default to UTF-8, almost all interactions with it (given that most
>    System.in interaction is char-based, not byte-based) are now also
>    broken. Create a second field or method in System that gives you a
>    Reader instead of an InputStream, with the OS-native encoding applied
>    to make it. This still leaves those thousands of tutorials broken, but at
>    least the proper code is now simply new Scanner(System.charIn()) or
>    whatnot, instead of the atrocious snippet above.
>    - Even less impactful, make a new method in Charset to get the native
>    encoding without having to delve into System.getProperty().
>    Charset.nativeEncoding() seems like a method that should exist.
>    Unfortunately this would be of no help to create code that works pre- and
>    post-JEP400, but in time, having code that only works post-JEP400 is fine,
>    I assume.
>    - Create a new concept ?represents a stream that would use platform
>    native encoding if characters are read/written to it?, have System.in
>     return true for this, and have filterstreams like BufferedInputStream just
>    pass the call through, then redefine relevant APIs such as Scanner and
>    PrintStream (e.g. anything that internalises conversion from bytes to
>    characters) to pick charset encoding (native vs UTF8) based on that
>    property. This is a more robust take on ?new Scanner(System.in) should
>    do the right thing'. Possibly the in/out/err streams that Process gives
>    you should also have this flag set.
>
>
>
> If it was up to me, I think a multitude of steps are warranted, each
> relatively simple.
>
>
>    - Create Charset.nativeEncoding(). Which simply returns
>    Charset.forName(System.getProperty(?native.encoding?). But with the
>    advantage that its shorter, doesn?t require knowing a magic string, and
>    will fail at compile time if compiled against versions that predate the
>    existence of the native.encoding property, instead of NPEs at runtime.
>    - Create System.charIn(). Which just returns an InputStreamReader
>    wrapped around System.in, but with native encoding applied.
>    - Put the job of how java apps do basic command line stuff on the
>    agenda as a thing that should probably be addressed in the next 5 years or
>    so, maybe after the steps laid out in Paving the on-ramp are more fleshed
>    out.
>    - In order to avoid problems, *before* the next LTS goes out, re-spec new
>    Scanner(System.in) to default to native encoding, specifically when
>    the passed inputstream is identical to System.in. Don?t bother with
>    trying to introduce an abstracted ?prefers native encoding? flag system.
>
>
>  --Reinier Zwitserloot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221018/2919372c/attachment-0001.htm>

From iklam at openjdk.org  Wed Oct 19 05:16:47 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Oct 2022 05:16:47 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v4]
In-Reply-To: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
Message-ID: <dJ7P3hlTshRKYvs3u-kM7eu3mBQLL_7FgfGko-Dksy0=.830b9188-178d-499e-a1a3-2560769ddcab@github.com>

> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into 8295302-no-arraylist-for-single-classdata-for-lambdaform
 - javadoc from @mlchung; fix code format per @turbanoff
 - Merge branch 'master' into 8295302-no-arraylist-for-single-classdata-for-lambdaform
 - @mlchung comments
 - @iwanowww comments
 - 8295302: Do not use ArrayList when LambdaForm has a single ClassData

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10706/files
  - new: https://git.openjdk.org/jdk/pull/10706/files/eb05b9ef..51f18357

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10706&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10706&range=02-03

  Stats: 5201 lines in 617 files changed: 2471 ins; 1039 del; 1691 mod
  Patch: https://git.openjdk.org/jdk/pull/10706.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10706/head:pull/10706

PR: https://git.openjdk.org/jdk/pull/10706

From duke at openjdk.org  Wed Oct 19 06:28:15 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 19 Oct 2022 06:28:15 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <k1088iY8oaczSdYv1LZne5QtmXqpOrFQLh093cm2qq4=.8df3cafc-e6e5-42ac-8ca2-b2410342a622@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <6LT4v2rxH7XbvyIRezUx6WmcNEQ9oXRwwtF6so6Be0w=.6c90278f-ddd8-41e3-b3e5-aa50baa89ac9@github.com>
 <QgTkcNwFp2-7XfG4lzw3NoMJAcOL8m5excx1sHZqYQc=.1caedeb8-ed2a-4dc7-8e18-024820383c94@github.com>
 <k1088iY8oaczSdYv1LZne5QtmXqpOrFQLh093cm2qq4=.8df3cafc-e6e5-42ac-8ca2-b2410342a622@github.com>
Message-ID: <7Oy57oavw1Tn6vL2KisvLfqV4lqExyAmkK_fIGP28xc=.43d1bdb0-fafa-45fb-8afb-8857e8a3c4f4@github.com>

On Tue, 18 Oct 2022 17:02:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I sent a link to this PR to one of the security engineers and they share the concern. Have you done any performance testing with an implementation that makes a defensive copy?

Thank you. So far I have not measured the actual performance drop, as I thought it would be common sense to not drop performance *at all*, unless actually *needed*. Given the fact that the buffer could be huge depending on the caller's settings, it is hard to give a single number. For small buffers (like some KB) it is obviously neglectible, but for huge buffers (like GB) it might be drastic, and might lead to OOME in some border cases. That is why I would prefer to abstain from a defensive copy unless *needed*. :-)

Roman, your are right, the fact that the Java language misses a read-only flag (like `const` in C++) is a performance showstopper. ;-)

@AlanBateman Can you please clarify: Does your answer mean that I shall provide a proof that the actual code actually does not run into the security concern, or does it mean that I *must* do defensive copy?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From alanb at openjdk.org  Wed Oct 19 07:42:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Oct 2022 07:42:59 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <FpYJDN3ZtRum7UXHK_ihxKcjAMUDj5P6-Sn_ReIb48Q=.e020f5ae-88c9-4934-bfab-3f87f5be06ea@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

> Thank you. So far I have not measured the actual performance drop, as I thought it would be common sense to not drop performance _at all_, unless actually _needed_. Given the fact that the buffer could be huge depending on the caller's settings, it is hard to give a single number. For small buffers (like some KB) it is obviously neglectible, but for huge buffers (like GB) it might be drastic, and might lead to OOME in some border cases. That is why I would prefer to abstain from a defensive copy unless _needed_. :-)

I assume you can do some experiments to see if there is a useful threshold to use. If the number of buffered bytes is larger then just delegate to the super's transferTo as before. If there isn't profitable then we may have to think about closing the PR, it's okay to have tried.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From jbhateja at openjdk.org  Wed Oct 19 07:46:01 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 19 Oct 2022 07:46:01 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
 [v2]
In-Reply-To: <X9zTQt0OcFrz9cuKYjOdVaQaa-tZCzB8u4wz0Y2WMbU=.5f24f688-414d-4b17-b0bb-c778b68a0059@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
 <X9zTQt0OcFrz9cuKYjOdVaQaa-tZCzB8u4wz0Y2WMbU=.5f24f688-414d-4b17-b0bb-c778b68a0059@github.com>
Message-ID: <2QQplnsxNj7THlLJteQ3EfmBcqNnSqH4he4vso9PjLk=.2be4a7e8-3165-479b-8dce-57a312e54ae1@github.com>

On Tue, 18 Oct 2022 01:44:21 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
>> 
>> This patch adds the vector intrinsic implementation of it. The steps are:
>> 
>>   1) Load the const "iota" vector.
>> 
>>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
>> 
>>   2) Compute indexes with "`vec + iota * scale`"
>> 
>> Here is the performance result to the new added micro benchmark on ARM NEON:
>> 
>> Benchmark                              Gain
>> IndexVectorBenchmark.byteIndexVector   1.477
>> IndexVectorBenchmark.doubleIndexVector 5.031
>> IndexVectorBenchmark.floatIndexVector  5.342
>> IndexVectorBenchmark.intIndexVector    5.529
>> IndexVectorBenchmark.longIndexVector   3.177
>> IndexVectorBenchmark.shortIndexVector  5.841
>> 
>> 
>> Please help to review and share the feedback! Thanks in advance!
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add the floating point support for VectorLoadConst and remove the VectorCast
>  - Merge branch 'master' into JDK-8293409
>  - 8293409: [vectorapi] Intrinsify VectorSupport.indexVector

Hi @XiaohongGong , patch now shows significant gains on both AVX512 and legacy X86 targets. 

X86 and common IR changes LGTM,  thanks!

-------------

Marked as reviewed by jbhateja (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10332

From xgong at openjdk.org  Wed Oct 19 07:50:13 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 19 Oct 2022 07:50:13 GMT
Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
 [v2]
In-Reply-To: <2QQplnsxNj7THlLJteQ3EfmBcqNnSqH4he4vso9PjLk=.2be4a7e8-3165-479b-8dce-57a312e54ae1@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
 <X9zTQt0OcFrz9cuKYjOdVaQaa-tZCzB8u4wz0Y2WMbU=.5f24f688-414d-4b17-b0bb-c778b68a0059@github.com>
 <2QQplnsxNj7THlLJteQ3EfmBcqNnSqH4he4vso9PjLk=.2be4a7e8-3165-479b-8dce-57a312e54ae1@github.com>
Message-ID: <5DXiOa_G0UGgdQwT3hY3SJtrV48jKRtjtXdjO7nLNL8=.d9497a92-ae5d-43da-bf39-1c53106e74f1@github.com>

On Wed, 19 Oct 2022 07:43:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Add the floating point support for VectorLoadConst and remove the VectorCast
>>  - Merge branch 'master' into JDK-8293409
>>  - 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
>
> Hi @XiaohongGong , patch now shows significant gains on both AVX512 and legacy X86 targets. 
> 
> X86 and common IR changes LGTM,  thanks!

Thanks for the review @jatin-bhateja @theRealELiu !

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From dholmes at openjdk.org  Wed Oct 19 08:01:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Oct 2022 08:01:00 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <D3wHu5JV0TpC2UrILY9CCc6zaHwkfGtazF8RaMW4A-k=.fb897b7b-4958-4f77-927b-cd035ae79ce7@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

I don't think solution #2 is desirable whilst the broken re-launch logic remains in place - but I might be swayed to defer that code removal to a separate RFE.

That said solution #1 is certainly preferable as there was obviously an intent that relaunch was handled correctly.

Happy to hear other opinions.

-------------

PR: https://git.openjdk.org/jdk/pull/10430

From duke at openjdk.org  Wed Oct 19 08:16:02 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 19 Oct 2022 08:16:02 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <n-VR6ghR-g55D3dqFB6x_uuiGL9lD9MvBbRi-zVUxTE=.6a6befae-7115-4fc0-8d04-2256c8e43996@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

I think before we give up, we should consider the alternatives, as the performance benefit of this PR is just too big to give up!

* Alternative A: I check the existing code to proof that we do not need any safety means if that is OK for everybody (is it?).

* Alternative B: Instead of double-buffering I drop the original buffer and use a same-size replacement each time the buffer was drained inside of `transferTo`. This is a rather cheap solution and rather perfectly prevents OOME, as I drop *first* before reallocating.

* Alternative C: Instead of double-buffering I zero-out (using `Arrays.fill()`) the original buffer after draining it. This would be a super-cheap alternative if somebody knows a hardware-accelerated array cleanup (do you?), but unfortunately the current code seems to be a simple Java-loop, actually.

I do not agree to close this PR unless we have a proof that the security problem really exists (I still can check that) *and* we didn't find a well-performing workaround.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From alanb at openjdk.org  Wed Oct 19 08:35:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Oct 2022 08:35:04 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
Message-ID: <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>

On Mon, 3 Oct 2022 05:54:31 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking explicitly -1 instead of < 0

> * Alternative B: Instead of double-buffering I drop the original buffer and use a same-size replacement each time the buffer was drained inside of `transferTo`. This is a rather cheap solution and rather perfectly prevents OOME, as I drop _first_ before reallocating.

That is a good idea to try. It wouldn't work when BIS is extended but transferTo already checks this.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Wed Oct 19 08:38:00 2022
From: duke at openjdk.org (Markus KARG)
Date: Wed, 19 Oct 2022 08:38:00 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
Message-ID: <wBAZGbHRzbix9ElwAeIAFayfRjUBqgids1IwXkDC2Tk=.1c6cf31a-1663-4ec0-9e6e-1bff1b44739c@github.com>

On Wed, 19 Oct 2022 08:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > * Alternative B: Instead of double-buffering I drop the original buffer and use a same-size replacement each time the buffer was drained inside of `transferTo`. This is a rather cheap solution and rather perfectly prevents OOME, as I drop _first_ before reallocating.
> 
> That is a good idea to try. It wouldn't work when BIS is extended but transferTo already checks this.

Correct, so I will give this one a try. Stay tuned. :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From xgong at openjdk.org  Wed Oct 19 09:28:04 2022
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 19 Oct 2022 09:28:04 GMT
Subject: Integrated: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector
In-Reply-To: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
References: <CES8kmi34gT8zSdoc2iBcgAGeOMDvOnZJrCsjU-9xaA=.091a5ad1-55a4-41c4-9e8c-192a0bca47e4@github.com>
Message-ID: <n0EURbOxVdy0K6YN1iSbhYCmoBpQZO14wtFA6sQH_zY=.5944ed03-836a-4bcb-96a6-be6dcac604c9@github.com>

On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions.
> 
> This patch adds the vector intrinsic implementation of it. The steps are:
> 
>   1) Load the const "iota" vector.
> 
>   We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values.
> 
>   2) Compute indexes with "`vec + iota * scale`"
> 
> Here is the performance result to the new added micro benchmark on ARM NEON:
> 
> Benchmark                              Gain
> IndexVectorBenchmark.byteIndexVector   1.477
> IndexVectorBenchmark.doubleIndexVector 5.031
> IndexVectorBenchmark.floatIndexVector  5.342
> IndexVectorBenchmark.intIndexVector    5.529
> IndexVectorBenchmark.longIndexVector   3.177
> IndexVectorBenchmark.shortIndexVector  5.841
> 
> 
> Please help to review and share the feedback! Thanks in advance!

This pull request has now been integrated.

Changeset: 857b0f9b
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/857b0f9b05bc711f3282a0da85fcff131fffab91
Stats:     391 lines in 14 files changed: 361 ins; 9 del; 21 mod

8293409: [vectorapi] Intrinsify VectorSupport.indexVector

Reviewed-by: eliu, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/10332

From aefimov at openjdk.org  Wed Oct 19 11:34:35 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 19 Oct 2022 11:34:35 GMT
Subject: RFR: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation [v7]
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <D_ksOPRyLbfskloPWPfJdbmZEZ-375vDyp6LYg1MlOo=.42ab57e6-afd7-479e-9ff2-285f0a949cb3@github.com>

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Update filter docs to match implementation.
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Remove factory builder synchronization from NamingManager. Update comments/docs.
 - Change checkInput to be the global filter centric
 - Refactor checkInput, better reporting for invalid filter patterns
 - Merge branch 'master' into JDK-8290368_protocol_specific_factory_filters
 - Additional comments/formatting cleanup.
 - More tests clean-up. Code/doc comments cleanup.
 - Cleanup test comments. Add tests to check that LDAP/RMI filters do not intersect.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/91faca3a...fbc4d577

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10578/files
  - new: https://git.openjdk.org/jdk/pull/10578/files/4449dda1..fbc4d577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10578&range=05-06

  Stats: 8758 lines in 746 files changed: 5155 ins; 1434 del; 2169 mod
  Patch: https://git.openjdk.org/jdk/pull/10578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10578/head:pull/10578

PR: https://git.openjdk.org/jdk/pull/10578

From alanb at openjdk.org  Wed Oct 19 13:41:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Oct 2022 13:41:46 GMT
Subject: RFR: 8295470: Update openjdk.java.net => openjdk.org URLs in test
 code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <oEDAuhIBqZqqS3y_9Q7BuQkndrxJSU-ozVrKMhAUr3g=.875d970e-8dc9-4240-97bb-19623b89a247@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

This updates several tests that are also in Doug Lea's CVS for j.u.concurrent. That should be okay, just need to get them in sync at some point.

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From aefimov at openjdk.org  Wed Oct 19 14:46:07 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 19 Oct 2022 14:46:07 GMT
Subject: Integrated: 8290368: Introduce LDAP and RMI protocol-specific object
 factory filters to JNDI implementation
In-Reply-To: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
References: <gZo4SR7r6IRzE-1lfaiFBlWPth4hxRVnTvyCTQa4Hcg=.2ffff859-8001-4a02-897a-b38bb6b3868d@github.com>
Message-ID: <tFEqEi8ZsbIS6DW5ZzZQKPD_fb8on-ke45_fz4IGEmk=.f7e9a1ba-f640-41e1-9664-0ed0817c1597@github.com>

On Wed, 5 Oct 2022 15:23:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> ### Summary of the change
> This change introduces new system and security properties for specifying factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider implementations. 
> 
> These new properties allow more granular control over the set of object factories allowed to reconstruct Java objects from LDAP and RMI contexts.
> 
> The new factory filters are supplementing the existing `jdk.jndi.object.factoriesFilter` global factories filter to determine if a specific object factory is permitted to instantiate objects for the given protocol.
> 
> Links:
> 
> - [CSR with details](https://bugs.openjdk.org/browse/JDK-8291556)
> - [JBS issue](https://bugs.openjdk.org/browse/JDK-8290368)
> 
> ### List of code changes
> 
> - Implementation for two new system and security properties have been added to the `com.sun.naming.internal.ObjectFactoriesFilter` class
> - `java.security` and `module-info.java` files have been updated with a documentation for the new properties
> - To keep API of `javax.naming.spi.NamingManager` and `javax.naming.spi.DirectoryManager` classes unmodified a new internal `com.sun.naming.internal.NamingManagerHelper` class has been introduced. All  `getObjectInstance` calls have been updated to use the new helper class.
> 
> #### NamingManagerHelper changes
> Changes performed to construct the `NamingManagerHelper` class:
> - `DirectoryManager.getObjectInstance` -> `NamingManagerHelper.getDirObjectInstance`. Dependant methods were also moved to the `NamingManagerHelper` class
> - `NamingManager.getObjectInstance` -> `NamingManagerHelper.getObjectInstance`. Methods responsible for setting/getting object factory builder were moved to the `NamingManagerHelper` class too.
> 
> 
> ### Test changes
> New tests have been added for checking that new factory filters can be used to restrict reconstruction of Java objects from LDAP and RMI contexts:
> - LDAP protocol specific test: test/jdk/com/sun/jndi/ldap/objects/factory/LdapFactoriesFilterTest.java
> - RMI protocol specific test: test/jdk/com/sun/jndi/rmi/registry/objects/RmiFactoriesFilterTest.java
> Existing `test/jdk/javax/naming/module/RunBasic.java` test has been updated to allow test-specific factories filter used to reconstruct objects from the test LDAP server. 
> 
> ### Testing
> tier1-tier3 and JNDI regression/JCK tests not showing any failures related to this change.
> No failures observed for the modified regression tests.

This pull request has now been integrated.

Changeset: d37ce4cd
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d37ce4cdd18afc4facf996598f79e72aae68f4ff
Stats:     1566 lines in 22 files changed: 1211 ins; 303 del; 52 mod

8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

Reviewed-by: dfuchs, rriggs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10578

From naoto at openjdk.org  Wed Oct 19 16:27:29 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Oct 2022 16:27:29 GMT
Subject: Integrated: 8295372: CompactNumberFormat handling of number one with
 decimal part
In-Reply-To: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
References: <XgAGHCC83XCR_0p4v81NcqRuoACZ0WOG67LTGN68jzo=.fae03874-ec30-43d9-9c65-4e401d41454b@github.com>
Message-ID: <0yaW1P0RkTh7l3CbwuvYC8gu_DA3PJkxmubNn66AmuY=.4b08d6ea-ee18-46d0-add3-d1022cc6276a@github.com>

On Tue, 18 Oct 2022 17:44:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Plurals were determined only by looking at the integer part of the compact number. Changed to consider the fraction digits as well.

This pull request has now been integrated.

Changeset: e238920b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e238920bb69836e982138cb7e1fed2a39182df8f
Stats:     80 lines in 2 files changed: 35 ins; 2 del; 43 mod

8295372: CompactNumberFormat handling of number one with decimal part

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10748

From mchhipa at openjdk.org  Wed Oct 19 16:53:03 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 19 Oct 2022 16:53:03 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
Message-ID: <kuEEZwYSUrURbOW6cTEwb3xDo3NeAJbnbuW-CWF_ZF0=.c54775d1-4a01-4618-b9d0-ea9cdfef0940@github.com>

On Mon, 17 Oct 2022 16:57:06 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task converts 5 manual tests to automated tests.
>> 
>> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
>> sun/security/provider/PolicyParser/ExtDirsChange.java 
>> sun/security/provider/PolicyParser/ExtDirs.java 
>> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
>> javax/crypto/CryptoPermissions/InconsistentEntries.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AssertThrows an exception in InconsistentEntries test.

Looks good to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From mchhipa at openjdk.org  Wed Oct 19 16:53:05 2022
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 19 Oct 2022 16:53:05 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v3]
In-Reply-To: <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
 <_gtGeGQGY5V3HLRua2ryf6n4hkVg9gZ4y9wl0GPmTtw=.43cd512a-930c-4e44-94b8-25dedfe386b9@github.com>
 <3cpKUXzxJQ5c1sYqlZWiusWlVvS494Ya8u_x-RfdGXk=.cd3fbb26-cfc2-495c-a565-547c828f549d@github.com>
 <pA_X_gCTNuB9O0p9q-OczKmxNkD6y-Wcs1_JG00VpHk=.6219516c-1d4c-4f4d-b090-e28c2992ee96@github.com>
Message-ID: <aCzEuNkifbMrbyl3CJkWfNqtBK45oFLV0gbVfPQ8kQw=.c82f097b-b74f-4266-98d8-0b6db933098e@github.com>

On Tue, 18 Oct 2022 22:11:57 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> test/jdk/javax/crypto/CryptoPermissions/default_local.policy line 4:
>> 
>>> 2:     permission javax.crypto.CryptoAllPermission;
>>> 3:     permission javax.crypto.CryptoPermission "DES", 64;
>>> 4: }
>> 
>> please remove extra line.
>
> I double-checked, there is no extra line at the end of this file.

Ok

>> test/jdk/sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java line 46:
>> 
>>> 44:  * @summary standard extensions path is hard-coded in default
>>> 45:  *      system policy file
>>> 46:  *
>> 
>> No need to repeat these statement again.
>
> Are you saying that we don't need to run the ExtDir2.policy and ExtDir3.policy?

Its fine, ignore my previous comment.

-------------

PR: https://git.openjdk.org/jdk/pull/10637

From lancea at openjdk.org  Wed Oct 19 16:53:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 19 Oct 2022 16:53:40 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version 1.2.13
Message-ID: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>

Hi all,

Please review this PR which will update the Zlib Data Compression Library from 1.2.11 to 1.2.13.

- I have run all of the Mach5 tiers which did not show any issues related to the upgrade.
- The JCK zip/jar tests also continue to pass.
- Jai ran his macOS aarch64 test(for [JDK-8282954](https://bugs.openjdk.org/browse/JDK-8282954)) with the zlib 1.2.13 port and has not seen the failure as seen with the MacOS aarch64 native zlib port


Best,
Lance

-------------

Commit messages:
 - Update Zlib Data Compression Library to Version 1.2.13

Changes: https://git.openjdk.org/jdk/pull/10773/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295530
  Stats: 11197 lines in 24 files changed: 9975 ins; 274 del; 948 mod
  Patch: https://git.openjdk.org/jdk/pull/10773.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10773/head:pull/10773

PR: https://git.openjdk.org/jdk/pull/10773

From alanb at openjdk.org  Wed Oct 19 18:04:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Oct 2022 18:04:59 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
Message-ID: <4ZTm9EEMALFoch8U5Dl9B7Xbhc-UjSvziU-yBWgY7FM=.dbe393d3-a815-46c2-b28a-ef8135e8c3a6@github.com>

On Wed, 19 Oct 2022 16:45:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which will update the Zlib Data Compression Library from 1.2.11 to 1.2.13.
> 
> - I have run all of the Mach5 tiers which did not show any issues related to the upgrade.
> - The JCK zip/jar tests also continue to pass.
> - Jai ran his macOS aarch64 test(for [JDK-8282954](https://bugs.openjdk.org/browse/JDK-8282954)) with the zlib 1.2.13 port and has not seen the failure as seen with the MacOS aarch64 native zlib port
> 
> 
> Best,
> Lance

Can you confirm that this is exactly the 1.2.13 code, no patches/changes, right?

-------------

PR: https://git.openjdk.org/jdk/pull/10773

From lancea at openjdk.org  Wed Oct 19 18:34:00 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 19 Oct 2022 18:34:00 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <4ZTm9EEMALFoch8U5Dl9B7Xbhc-UjSvziU-yBWgY7FM=.dbe393d3-a815-46c2-b28a-ef8135e8c3a6@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
 <4ZTm9EEMALFoch8U5Dl9B7Xbhc-UjSvziU-yBWgY7FM=.dbe393d3-a815-46c2-b28a-ef8135e8c3a6@github.com>
Message-ID: <4q_1yhvw9a5Fzl_x0SbF9J0PnO_NfQgxUmJcsa3gmn8=.35bcedd9-dbee-4f2d-a443-e46617c1558b@github.com>

On Wed, 19 Oct 2022 18:02:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you confirm that this is exactly the 1.2.13 code, no patches/changes, right?

That is correct,  there are no patches on top of the 1.2.13

-------------

PR: https://git.openjdk.org/jdk/pull/10773

From alanb at openjdk.org  Wed Oct 19 18:49:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Oct 2022 18:49:03 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
Message-ID: <Dp0b7kOjz4H_6Lf88xR0bjpzAdYiJ94yyHn0UsoXp8s=.53ddae4f-5e24-4626-9130-dff9e1dbfc32@github.com>

On Wed, 19 Oct 2022 16:45:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which will update the Zlib Data Compression Library from 1.2.11 to 1.2.13.
> 
> - I have run all of the Mach5 tiers which did not show any issues related to the upgrade.
> - The JCK zip/jar tests also continue to pass.
> - Jai ran his macOS aarch64 test(for [JDK-8282954](https://bugs.openjdk.org/browse/JDK-8282954)) with the zlib 1.2.13 port and has not seen the failure as seen with the MacOS aarch64 native zlib port
> 
> 
> Best,
> Lance

I didn't go through every file, instead I just sampled and compared to what is the zlib project. I think it's good to get this upgrade done.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10773

From naoto at openjdk.org  Wed Oct 19 19:14:04 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Oct 2022 19:14:04 GMT
Subject: RFR: 8295564: Norwegian Nynorsk Locale is missing formatting
Message-ID: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>

This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
It's amazing to see this bug has been lurking unnoticed till now.

-------------

Commit messages:
 - 8295564: Norwegian Nynorsk Locale is missing formatting

Changes: https://git.openjdk.org/jdk/pull/10774/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295564
  Stats: 12 lines in 3 files changed: 8 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10774.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10774/head:pull/10774

PR: https://git.openjdk.org/jdk/pull/10774

From bhuang at openjdk.org  Wed Oct 19 20:06:21 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 19 Oct 2022 20:06:21 GMT
Subject: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v4]
In-Reply-To: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
References: <eZYtfMrEiHGALInKZwbcNlmTZAUn50C4-VmHMYgxy-A=.15bfd2f6-ad72-4596-a4ef-3bf6339d0614@github.com>
Message-ID: <lx1wq-j0m7IGx9eMqwGKdFoQNNElmcWWPVYIxd4TWWw=.adfcaeed-788e-4b90-9257-1bb1565e128b@github.com>

> This task converts 5 manual tests to automated tests.
> 
> sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java 
> sun/security/provider/PolicyParser/ExtDirsChange.java 
> sun/security/provider/PolicyParser/ExtDirs.java 
> java/security/Policy/Root/Root.javajava/security/Policy/Root/Root.java 
> javax/crypto/CryptoPermissions/InconsistentEntries.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Added an extra line to the end of the policy file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10637/files
  - new: https://git.openjdk.org/jdk/pull/10637/files/cfb9f74d..8b45f39f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10637&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10637/head:pull/10637

PR: https://git.openjdk.org/jdk/pull/10637

From iris at openjdk.org  Wed Oct 19 20:52:00 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 19 Oct 2022 20:52:00 GMT
Subject: RFR: 8295564: Norwegian Nynorsk Locale is missing formatting
In-Reply-To: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
References: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
Message-ID: <UHMoeLlIKng7twRJv8JjR7viJyt_rpfewmVMYuR8NOc=.c0bd9c7b-55b9-45e4-9613-9352660d139d@github.com>

On Wed, 19 Oct 2022 19:04:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
> It's amazing to see this bug has been lurking unnoticed till now.

I like changes that reduce code while resulting in more correct behaviour.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10774

From iklam at openjdk.org  Wed Oct 19 21:12:59 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Oct 2022 21:12:59 GMT
Subject: RFR: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData [v2]
In-Reply-To: <i1e7H4BkoN24WU_frKwqbZTW5hlxiKODQcUw-wwSulU=.a48ea043-ad03-44a7-9cc6-d29c35423431@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
 <qnKRStKnsnqXaeOBAbGmFLvKR_cytzhNRHpTlMXrUhM=.1985f1ba-8536-44ee-942a-120e7e9cfda9@github.com>
 <i1e7H4BkoN24WU_frKwqbZTW5hlxiKODQcUw-wwSulU=.a48ea043-ad03-44a7-9cc6-d29c35423431@github.com>
Message-ID: <xngJEPbDqs7-yZFBKru1ct_UT-7MFe8ApEOSG_HnySo=.119f17eb-55b7-4bc4-8531-5ab80b26f965@github.com>

On Mon, 17 Oct 2022 19:28:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iwanowww comments
>
> Looks good, assuming there are tests calling in with no class data to check that `defineClass` is fine with `null` inputs?

Thanks @cl4es @iwanowww @mlchung for the review, and @turbanoff for the suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From iklam at openjdk.org  Wed Oct 19 21:14:23 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Oct 2022 21:14:23 GMT
Subject: Integrated: 8295302: Do not use ArrayList when LambdaForm has a single
 ClassData
In-Reply-To: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
References: <1T08g8aCIz2npijUsv9zvoIky2uIlC0RoJ41q-ut1iM=.ea6d4b82-811e-4e77-9d89-ef83d3f5bd42@github.com>
Message-ID: <AObHdN9tM57SCgpWq_vY_90hFmJ2kWgjX37Cp8F-rEM=.a0cf4283-2530-464e-acc2-c87a1b990fa9@github.com>

On Thu, 13 Oct 2022 21:53:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small optimization. As shown in the JBS issue, most of the generated LambdaForm classes have a single ClassData, so we can get a small footprint/speed improvement.

This pull request has now been integrated.

Changeset: 8d4c0772
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d4c077218748d37617fc1bdb537a165706a5849
Stats:     68 lines in 1 file changed: 39 ins; 26 del; 3 mod

8295302: Do not use ArrayList when LambdaForm has a single ClassData

Reviewed-by: vlivanov, redestad, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/10706

From duke at openjdk.org  Wed Oct 19 21:37:19 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 19 Oct 2022 21:37:19 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java
Message-ID: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>

Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html#getBundle-java.lang.String-java.util.Locale-) for base name parameter

Fix: Modified bundle name to be a fully qualified class and added regression tests.

-------------

Commit messages:
 - Finalize test changes
 - Add regression test for bundle name change
 - Fix bundle name

Changes: https://git.openjdk.org/jdk/pull/10612/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294989
  Stats: 138 lines in 3 files changed: 137 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From joehw at openjdk.org  Wed Oct 19 21:45:59 2022
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Oct 2022 21:45:59 GMT
Subject: RFR: 8295564: Norwegian Nynorsk Locale is missing formatting
In-Reply-To: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
References: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
Message-ID: <9bM7bM3GrBUSL5B94rawrPMULXe74THCViIEe2f5QQo=.9aaa8a0e-4745-4b86-a542-6207d5a81a8c@github.com>

On Wed, 19 Oct 2022 19:04:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
> It's amazing to see this bug has been lurking unnoticed till now.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10774

From bchristi at openjdk.org  Wed Oct 19 22:25:07 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 19 Oct 2022 22:25:07 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v9]
In-Reply-To: <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>
Message-ID: <ZEULntdAZ-UaQjJ89sYJN1KVocbGZazoWgBc_mbBMgg=.3aaf35bb-5164-40bd-841d-fa9a07c3da52@github.com>

On Tue, 18 Oct 2022 23:03:16 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional cleanup and string formatting

test/jdk/java/util/Formatter/BasicTestLauncher.java line 90:

> 88:             ProcessBuilder pb = ProcessTools.createTestJvm(JAVA_OPTS, TEST_CLASS);
> 89:             pb.environment().put("TZ", timeZone);
> 90:             Process process = pb.start();

Nit: indentation

test/jdk/java/util/Formatter/BasicTestLauncher.java line 102:

> 100:     private static void CheckTest(OutputAnalyzer output){
> 101:             output.shouldHaveExitValue(0)
> 102:                     .reportDiagnosticSummary();

Nit: indentation

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Wed Oct 19 22:30:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Oct 2022 22:30:49 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <3gznEQtJ7-iKamPcW8KIrpram7j-JKnE3nzY5QPC9ac=.188c26d1-402f-4ce4-b129-7dc0592f792a@github.com>

On Fri, 7 Oct 2022 18:24:02 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html#getBundle-java.lang.String-java.util.Locale-) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 45:

> 43:     private static final String PATH_TO_BUNDLE = "com/sun/rowset/RowSetResourceBundle";
> 44:     // Default Locale
> 45:     private static final Locale DEFAULT_LOCALE = Locale.getDefault();

Is using the default locale OK? What if the test is run under some locale where JDBC does not provide the localized bundle?

test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 62:

> 60:     private static void testResourceBundleAccess(String bundleName, boolean expectBundle) {
> 61:         try {
> 62:             var bundle = (PropertyResourceBundle) ResourceBundle.getBundle(

Is casting to `PropertyResourceBundle` needed? If you intend to check the bundle type, I'd explicitly check the type.

test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 64:

> 62:             var bundle = (PropertyResourceBundle) ResourceBundle.getBundle(
> 63:                     bundleName, DEFAULT_LOCALE, JdbcRowSetResourceBundle.class.getModule());
> 64:             System.out.printf("$$$ %s found as expected!%n", bundleName);

I think `expectBundle` needs to be examined here. If it is `false`, it should throw an exception.

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 42:

> 40:     private static final String invalidState = "Invalid state";
> 41:     // Expected JDBCResourceBundle message, crsreader.connecterr
> 42:     private static final String rsReaderError = "Internal Error in RowSetReader: no connection or command";

Should be tested in English environment, if the test is going to compare the result with English text.

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 53:

> 51:         // is found from the resource bundle
> 52:         try {
> 53:             jrs.getMetaData();

The test should fail if the execution of `getMetaData()` succeeds.

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 59:

> 57:         // Now tests via CachedRowSet
> 58:         try {
> 59:             crs.execute();

Ditto, as above.

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Wed Oct 19 22:36:07 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 19 Oct 2022 22:36:07 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v10]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <HMF74-B4H_V6RfMfZn3J-Ju5-cCg7uVjg_aPzkIjYlk=.983b5e05-9aa2-437d-b1db-4fc8ee71ee67@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/56eae09a..5a0ee74f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=08-09

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Wed Oct 19 22:47:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Oct 2022 22:47:07 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <1uHr_gDRbLQ4zNmUcBnWW4b2Zztm1dc9IxMHuWc-Iok=.83eaba38-1e27-4741-a7ee-1af85481529d@github.com>

On Fri, 7 Oct 2022 18:24:02 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html#getBundle-java.lang.String-java.util.Locale-) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

btw, the link to getBundle javadoc points to JDK8's, where the module has not yet been introduced. I was scratching my head why I couldn't find the overload that takes a Module ?

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Wed Oct 19 22:56:09 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 19 Oct 2022 22:56:09 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java
In-Reply-To: <1uHr_gDRbLQ4zNmUcBnWW4b2Zztm1dc9IxMHuWc-Iok=.83eaba38-1e27-4741-a7ee-1af85481529d@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <1uHr_gDRbLQ4zNmUcBnWW4b2Zztm1dc9IxMHuWc-Iok=.83eaba38-1e27-4741-a7ee-1af85481529d@github.com>
Message-ID: <6QiWmqIoGj9GK084H1fcS4qu1cukXhsq1zIbH7jBVvY=.56520241-510c-40e1-87fc-f31baa948309@github.com>

On Wed, 19 Oct 2022 22:44:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> btw, the link to getBundle javadoc points to JDK8's, where the module has not yet been introduced. I was scratching my head why I couldn't find the overload that takes a Module ?

I intended to focus on "baseName - the base name of the resource bundle, a fully qualified class name" but you're right, will replace with a doc that is up to date with the code, thank you.

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Wed Oct 19 23:01:00 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 19 Oct 2022 23:01:00 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java
In-Reply-To: <3gznEQtJ7-iKamPcW8KIrpram7j-JKnE3nzY5QPC9ac=.188c26d1-402f-4ce4-b129-7dc0592f792a@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <3gznEQtJ7-iKamPcW8KIrpram7j-JKnE3nzY5QPC9ac=.188c26d1-402f-4ce4-b129-7dc0592f792a@github.com>
Message-ID: <94boROWmFGGENpxWb8_eRJ7LSFBKRQJ9WYBPRNv332A=.ae7c0eba-eae0-4dfe-b777-58f9eefec52c@github.com>

On Wed, 19 Oct 2022 22:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html#getBundle-java.lang.String-java.util.Locale-) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 53:
> 
>> 51:         // is found from the resource bundle
>> 52:         try {
>> 53:             jrs.getMetaData();
> 
> The test should fail if the execution of `getMetaData()` succeeds.

Good point, will make that change

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From reinier at zwitserloot.com  Wed Oct 19 23:05:04 2022
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Wed, 19 Oct 2022 16:05:04 -0700
Subject: JEP 400 vs new Scanner(System.in)
Message-ID: <CAK6PxWNw+Q_6Q=SJxQRNg+DcVPUvkCYwu1mHahrUYbbfF2G8RA@mail.gmail.com>

PREAMBLE: Due to not being sure where to post it, this was posted to
amber-dev before. I have updated it to take into account Ron Pressler?s
notes on System.console, and Brian Goetz?s notes on steering clear of
shoving deadlines in debate posts like this one.
?


JDK18 brought JEP400 which changes the default charset encoding to UTF-8.
This, probably out of necessity, goes quite far, in that
Charset.defaultCharset() is now more or less a constant - always returns
UTF_8. It?s now quite difficult to retrieve the OS-configured encoding (the
?native? encoding).

However, that does mean one of the most common lines in all of java?s
history, is now necessarily buggy: new Scanner(System.in) is now broken.
Always, unless your docs specifically state that you must feed the app
UTF_8 data. Linting tools ought to flag it down as incorrect. It?s
incorrect In a nasty way too: Initially it seems to work fine, but if
you?re on an OS whose native encoding isn?t UTF-8, this is subtly broken;
enter non-ASCII characters on the command line and the app doesn?t handle
them appropriately. A bug that is literally utterly undiscoverable on macs
and most linux computers, even. How can you figure out your code is broken
if all the machines you test it on use UTF-8 as an OS default?

This affects beginning java programmers particularly (who tend to be
writing some command line-interactive apps at first). In light of Brian
Goetz?s post ?Paving the Onramp? (
https://openjdk.org/projects/amber/design-notes/on-ramp) - the experience
for new users is evidently of some importance to the OpenJDK team. In light
of that, the current state of writing command line interactive java apps is
inconsistent with that goal.

The right way to read system input in a way that works in both pre- and
post-JEP400 JVM editions appears to be, as far as I can tell:

Charset nativeCharset =
Charset.forName(System.getProperty("native.encoding",
Charset.defaultEncoding().name());
Scanner sc = new Scanner(System.in <https://system.in/>, nativeCharset);


I?ll risk the hyperbole: That?s.. atrocious. Hopefully I?m missing
something!

Breaking _thousands_ of blogs, tutorials, stack overflow answers, and books
in the process, everything that contains new Scanner(System.in). Even sysin
interaction that doesn?t use scanner is likely broken; the general strategy
then becomes:

new InputStreamReader(System.in <https://system.in/>);


which suffers from the same problem.

I see a few directions for trying to address this; I?m not quite sure which
way would be most appropriate:


   - Completely re-work keyboard input, in light of *Paving the on-ramp*.
   Scanner has always been a problematic API if used for keyboard input, in
   that the default delimiter isn?t convenient. I think the single most common
   beginner java stackoverflow question is the bizarre interaction between
   scanner?s nextLine() and scanner?s next(), and to make matters
   considerably worse, the proper fix (which is to call .useDelimiter(?\\R?) on
   the scanner first) is said in less than 1% of answers; the vast majority of
   tutorials and answers tell you to call .nextLine() after every
.nextX() call.
   A suboptimal suggestion (it now means using space to delimit your input is
   broken). Scanner is now also quite inconsistent: The constructor goes for
   ?internet standard?, using UTF-8 as a default even if the OS does not, but
   the locale *does* go by platform default, which affects double parsing
   amongst other things: scanner.nextDouble() will require you to use
   commas as fractions separator if your OS is configured to use the Dutch
   locale, for example. It?s weird that scanner neither fully follows common
   platform-independent expectations (english locale, UTF-8), nor
   local-platform expectation (OS-configured locale and OS-configured
   charset). One way out is to make a new API for ?command line apps? and take
   into account Paving the on-ramp?s plans when designing it.
   - Rewrite specifically the new Scanner(InputStream) constructor as
   defaulting to native encoding even when everything else in java defaults to
   UTF-8 now, because that constructor is 99% used for System.in. Scanner
   has its own File-based constructor, so new
   Scanner(Files.newInputStream(..)) is quite rare.
   - Define that constructor to act as follows: the charset used is the
   platform default (i.e., from JDK18 and up, UTF-8), *unless* arg ==
   System.in is true, in which case the scanner uses native encoding. This
   is a bit bizarre to write in the spec but does the right thing in the most
   circumstances and unbreaks thousands of tutorials, blogs, and answer sites,
   and is most convenient to code against. That?s usually the case with voodoo
   magic (because this surely risks being ?too magical?): It?s convenient and
   does the right thing almost always, at the risk of being hard to fathom and
   producing convoluted spec documentation.
   - Attach the problem that what?s really broken isn?t so much scanner,
   it?s System.in itself: byte based, of course, but now that all java
   methods default to UTF-8, almost all interactions with it (given that most
   System.in interaction is char-based, not byte-based) are now also
   broken. Create a second field or method in System that gives you a
Reader instead
   of an InputStream, with the OS-native encoding applied to make it. This
   still leaves those thousands of tutorials broken, but at least the proper
   code is now simply new Scanner(System.charIn()) or whatnot, instead of
   the atrocious snippet above.
   - Even less impactful, make a new method in Charset to get the native
   encoding without having to delve into System.getProperty().
   Charset.nativeEncoding() seems like a method that should exist.
   Unfortunately this would be of no help to create code that works pre- and
   post-JEP400, but in time, having code that only works post-JEP400 is fine,
   I assume.
   - Create a new concept ?represents a stream that would use platform
   native encoding if characters are read/written to it?, have System.in
    return true for this, and have filterstreams like BufferedInputStream just
   pass the call through, then redefine relevant APIs such as Scanner and
   PrintStream (e.g. anything that internalises conversion from bytes to
   characters) to pick charset encoding (native vs UTF8) based on that
   property. This is a more robust take on ?new Scanner(System.in) should
   do the right thing'. Possibly the in/out/err streams that Process gives
   you should also have this flag set.
   - (based on feedback from Ron Pressler in amber-dev) Try to move the
   community away from treating System.in and System.out as the streams to
   be used for ?command line apps?, and towards using System.console() instead,
   which is already char based, and is better positioned to take care of
   picking the right charset for you. However, this is quite a big job, given
   that virtually all tutorials, books, q&a sites like Stack Overflow talk
   about System.in/out and not about Console. Even if somehow the message
    gets out and these start using Console instead, the experience for java
   developers would be deplorable, given that *no IDE supports Console!* -
   possibly because it is maybe difficult for them to set it up properly? At
   any rate, just like the JDBC group works together with DB vendors to ensure
   JDBC actually is fit for purpose, there would have to be something set up
   to ensure tool developers like the eclipse team or IntelliJ update their
   templates and support Console for their run/debug-inside-IDE features. An
   open question then comes up: How does the OpenJDK team move the community
   in the direction that the OpenJDK wants them to move? ?Build it and they
   will come?? I highly doubt that would work here; System.in works well
   enough for the base case at first glance. At the very least a statement by
   the OpenJDK that new Scanner(System.in) is a bad idea would help to
   start the decades-long work of trying to break down established Stack
   Overflow answers, mark tutorials as obsolete, etc. I have no idea if the
   OpenJDK even wants to meddle with community interaction like this, but if
   it does not, then ?it?s fine, Console exists, it?s not our problem the
   community doesn?t use it? seems a bit hollow.



If it was up to me, I think a multitude of steps are warranted, each
relatively simple.


   - Create Charset.nativeEncoding(). Which simply returns
   Charset.forName(System.getProperty(?native.encoding?). But with the
   advantage that its shorter, doesn?t require knowing a magic string, and
   will fail at compile time if compiled against versions that predate the
   existence of the native.encoding property, instead of NPEs at runtime.
   - Create System.charIn(). Which just returns an InputStreamReader
   wrapped around System.in, but with native encoding applied.
   - Put the job of how java apps do basic command line stuff on the agenda
   as a thing that should probably be addressed in the next 5 years or so,
   maybe after the steps laid out in Paving the on-ramp are more fleshed out.
   - In order to avoid problems, re-spec new Scanner(System.in) to default
   to native encoding, specifically when the passed inputstream is identical
   to System.in. Don?t bother with trying to introduce an abstracted
   ?prefers native encoding? flag system.
   - Contact IntelliJ, eclipse, and possibly maven/gradle (insofar that
   Console doesn?t work when using mvn run and the like) and ask them what
   they need to add console support, keeping in mind encoding is important,
   and possibly, to rewire their syso (eclipse) and sysout (intellij)
   template shortcuts away from System.out.println and towards
   System.console().printf instead.


 --Reinier Zwitserloot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221019/628a3ce7/attachment-0001.htm>

From bpb at openjdk.org  Thu Oct 20 00:23:14 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Oct 2022 00:23:14 GMT
Subject: RFR: 8294705: Disable an assertion in
 test/jdk/java/util/DoubleStreamSums/CompensatedSums.java
In-Reply-To: <c7HjXcVRhWCTAZ1Tf7AM5YDvdyjdieIC2o9LPnZdYfU=.aeb7977f-2d7e-4775-afdf-46b87fa8eed5@github.com>
References: <c7HjXcVRhWCTAZ1Tf7AM5YDvdyjdieIC2o9LPnZdYfU=.aeb7977f-2d7e-4775-afdf-46b87fa8eed5@github.com>
Message-ID: <lDcgvoPeuFj4QOfddceJlX6gPmT7VgjYegOC9lrTWHE=.577d9ba8-a6b5-4c51-990f-01521f5f30fd@github.com>

On Mon, 3 Oct 2022 08:23:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Disables a specific assertion that causes intermittent failures.

Approved whether or not any comment is added.

test/jdk/java/util/DoubleStreamSums/CompensatedSums.java line 94:

> 92: 
> 93:         Assert.assertTrue(jdkParallelStreamError <= goodParallelStreamError);
> 94: //        Assert.assertTrue(badParallelStreamError >= jdkParallelStreamError);

Maybe a comment here, something like in the issue description?

// Due to floating-point addition being inherently non-associative, and due to the unpredictable scheduling of the threads used in parallel streams, this assertion can fail intermittently hence is suppressed for now.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10529

From sspitsyn at openjdk.org  Thu Oct 20 00:33:57 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Oct 2022 00:33:57 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <BvE4r9TdgOEe8r7urVd4j0IvzhukESe4E1zdu7daCcA=.db72b11a-4658-4e3d-b0cb-32cde0e983b8@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

This looks okay to me.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10322

From jpai at openjdk.org  Thu Oct 20 02:18:18 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 02:18:18 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
Message-ID: <cs5_hQVuC3hZRUJMDGOV9Fgm0xSIv3pmjB8I8L6N4AQ=.2a0a5bbb-e174-4015-9d86-516d0aa38b57@github.com>

On Wed, 19 Oct 2022 16:45:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which will update the Zlib Data Compression Library from 1.2.11 to 1.2.13.
> 
> - I have run all of the Mach5 tiers which did not show any issues related to the upgrade.
> - The JCK zip/jar tests also continue to pass.
> - Jai ran his macOS aarch64 test(for [JDK-8282954](https://bugs.openjdk.org/browse/JDK-8282954)) with the zlib 1.2.13 port and has not seen the failure as seen with the MacOS aarch64 native zlib port
> 
> 
> Best,
> Lance

src/java.base/share/native/libzip/zlib/README line 6:

> 4: thread safe.  The data format used by the zlib library is described by RFCs
> 5: (Request for Comments) 1950 to 1952 in the files
> 6: http://tools.ietf.org/html/rfc1950 (zlib format), rfc1951 (deflate format) and

Hello Lance, it appears that we had done this change to this file in the JDK as part of https://bugs.openjdk.org/browse/JDK-8283525. As Sean notes in that issue, the `http` link is back to working but `https` was still prefered during that change. Should we stick with `https`?

-------------

PR: https://git.openjdk.org/jdk/pull/10773

From jpai at openjdk.org  Thu Oct 20 02:30:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 02:30:01 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
Message-ID: <N4a9QEnyDLdBVd4V8eOxcAnRMiYQ6bDtwQwtn5IKu9A=.f53def1b-1297-4c30-a321-bb1a88c5bcb3@github.com>

On Wed, 19 Oct 2022 16:45:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which will update the Zlib Data Compression Library from 1.2.11 to 1.2.13.
> 
> - I have run all of the Mach5 tiers which did not show any issues related to the upgrade.
> - The JCK zip/jar tests also continue to pass.
> - Jai ran his macOS aarch64 test(for [JDK-8282954](https://bugs.openjdk.org/browse/JDK-8282954)) with the zlib 1.2.13 port and has not seen the failure as seen with the MacOS aarch64 native zlib port
> 
> 
> Best,
> Lance

Marked as reviewed by jpai (Reviewer).

I checked out Mark Adler's upstream 1.2.13 tag https://github.com/madler/zlib/tree/v1.2.13 locally and then ran `diff src/java.base/share/native/libzip/zlib <root-of-1.2.13-of-madler-repo>`. The diff shows that for the (common) files that we have in this PR, there's no difference other than additional copyright headers.

Additionally against Mark's upstream git repo, I ran:


git diff --name-only --diff-filter=A v1.2.11 v1.2.13 

to find any newly added files (that might be relevant to us) between these 2 versions. The output is:

.github/workflows/cmake.yml
.github/workflows/configure.yml
.github/workflows/fuzz.yml
LICENSE
doc/crc-doc.1.0.pdf
examples/gznorm.c
examples/zran.h

None of which is relevant to JDK.

I also ran:

git diff --name-only --diff-filter=D v1.2.11 v1.2.13

to find any deleted files between these 2 versions and the output is:

contrib/amd64/amd64-match.S
contrib/asm686/README.686
contrib/asm686/match.S
contrib/inflate86/inffas86.c
contrib/inflate86/inffast.S
contrib/masmx64/bld_ml64.bat
contrib/masmx64/gvmat64.asm
contrib/masmx64/inffas8664.c
contrib/masmx64/inffasx64.asm
contrib/masmx64/readme.txt
contrib/masmx86/bld_ml32.bat
contrib/masmx86/inffas32.asm
contrib/masmx86/match686.asm
contrib/masmx86/readme.txt

none of which appear relevant to us.

Finally, I ran:

git diff --name-only --diff-filter=R v1.2.11 v1.2.13 

to find any renamed files. This returns no output (since nothing was renamed).

So overall, the change in this PR looks good to me and appears to be same as what's there in 1.2.13 of upstream.

-------------

PR: https://git.openjdk.org/jdk/pull/10773

From Alan.Bateman at oracle.com  Thu Oct 20 06:43:57 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 Oct 2022 07:43:57 +0100
Subject: JEP 400 vs new Scanner(System.in)
In-Reply-To: <CAK6PxWNw+Q_6Q=SJxQRNg+DcVPUvkCYwu1mHahrUYbbfF2G8RA@mail.gmail.com>
References: <CAK6PxWNw+Q_6Q=SJxQRNg+DcVPUvkCYwu1mHahrUYbbfF2G8RA@mail.gmail.com>
Message-ID: <4a40e852-e477-e93b-0aef-48cb8c44bf0d@oracle.com>

On 20/10/2022 01:05, Reinier Zwitserloot wrote:
> :
>
>
> JDK18 brought JEP400 which changes the default charset encoding to 
> UTF-8. This, probably out of necessity, goes quite far, in that 
> |Charset.defaultCharset()|?is now more or less a constant - always 
> returns UTF_8. It?s now quite difficult to retrieve the OS-configured 
> encoding (the ?native? encoding).
>
> However, that does mean one of the most common lines in all of java?s 
> history, is now necessarily buggy: |new Scanner(System.in)|?is now broken.

System.in has always been problematic, including new Scanner(System.in), 
as it could be connected to anything.

As Ron noted, Console (since Java 6) provides readLine, reader, and 
printf so it's not bad for reading and writing lines of text, something 
that will be typical when starting out. Yes, Console is problematic for 
tooling that takes ownership of the console. We've been mulling over 
introducing a SPI for that - if you back through the archives then 
you'll see some early discussion on that. If the JDK has a SPI then it 
would mean that jshell and IDEs would be able to provide an 
implementation that works in respective environments and so provide a 
better experience for code that uses System.console.

You are right that further work is required to move away from using 
System.in directly.? JDK-8295672 [1] is tracking some of the ideas for 
possible APIs. The focus is a bit different to your list as we don't 
want to expose the notion of Charsets to new users nor provide APIs like 
System.charIn that wouldn't support reading lines or work with 
redirection. Prototypes and experimentation will required to find the 
right API to propose.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8295672
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221020/778fba67/attachment.htm>

From rgiulietti at openjdk.org  Thu Oct 20 09:02:20 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 20 Oct 2022 09:02:20 GMT
Subject: RFR: 8294705: Disable an assertion in
 test/jdk/java/util/DoubleStreamSums/CompensatedSums.java [v2]
In-Reply-To: <c7HjXcVRhWCTAZ1Tf7AM5YDvdyjdieIC2o9LPnZdYfU=.aeb7977f-2d7e-4775-afdf-46b87fa8eed5@github.com>
References: <c7HjXcVRhWCTAZ1Tf7AM5YDvdyjdieIC2o9LPnZdYfU=.aeb7977f-2d7e-4775-afdf-46b87fa8eed5@github.com>
Message-ID: <TNp6_TWkx4JIVgagen2W4zeajoMGOwYLGEYvA7TS6xY=.f1944792-5d31-4bdd-ad3c-e60baa945949@github.com>

> Disables a specific assertion that causes intermittent failures.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8294705: Disable an assertion in test/jdk/java/util/DoubleStreamSums/CompensatedSums.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10529/files
  - new: https://git.openjdk.org/jdk/pull/10529/files/9b7b33fb..593e7bea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10529&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10529&range=00-01

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10529.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10529/head:pull/10529

PR: https://git.openjdk.org/jdk/pull/10529

From jpai at openjdk.org  Thu Oct 20 10:01:19 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 10:01:19 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge latest from master branch
 - remove unintentionally committed file
 - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10322/files
  - new: https://git.openjdk.org/jdk/pull/10322/files/ddfb8c95..01267c65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10322&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10322&range=00-01

  Stats: 66155 lines in 2020 files changed: 37805 ins; 19685 del; 8665 mod
  Patch: https://git.openjdk.org/jdk/pull/10322.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10322/head:pull/10322

PR: https://git.openjdk.org/jdk/pull/10322

From jpai at openjdk.org  Thu Oct 20 10:01:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 10:01:20 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <u_HgyeNwDcLAoB2YG-VY9NX1dMnHThl3iSH9OcwNaK8=.220c5237-a512-4f4f-9c82-50a97ba9fa25@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Hello Serguei,

Thank you for your review. I was about to integrate this when I just noticed that I had unintentionally included a new empty file in this commit. 

I've now updated this PR to remove that stray file (and no other changes). Could you please review the current state of this PR once more?

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From lancea at openjdk.org  Thu Oct 20 10:17:50 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 20 Oct 2022 10:17:50 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <cs5_hQVuC3hZRUJMDGOV9Fgm0xSIv3pmjB8I8L6N4AQ=.2a0a5bbb-e174-4015-9d86-516d0aa38b57@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
 <cs5_hQVuC3hZRUJMDGOV9Fgm0xSIv3pmjB8I8L6N4AQ=.2a0a5bbb-e174-4015-9d86-516d0aa38b57@github.com>
Message-ID: <5CrW0G8-8ADGqladZ0zQkRkFyHIZ7OHjpm_2eaZYvP4=.d8958a63-1e66-424d-8c93-bfed859b6db4@github.com>

On Thu, 20 Oct 2022 02:02:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this PR which will update the Zlib Data Compression Library from 1.2.11 to 1.2.13.
>> 
>> - I have run all of the Mach5 tiers which did not show any issues related to the upgrade.
>> - The JCK zip/jar tests also continue to pass.
>> - Jai ran his macOS aarch64 test(for [JDK-8282954](https://bugs.openjdk.org/browse/JDK-8282954)) with the zlib 1.2.13 port and has not seen the failure as seen with the MacOS aarch64 native zlib port
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/native/libzip/zlib/README line 6:
> 
>> 4: thread safe.  The data format used by the zlib library is described by RFCs
>> 5: (Request for Comments) 1950 to 1952 in the files
>> 6: http://tools.ietf.org/html/rfc1950 (zlib format), rfc1951 (deflate format) and
> 
> Hello Lance, it appears that we had done this change to this file in the JDK as part of https://bugs.openjdk.org/browse/JDK-8283525. As Sean notes in that issue, the `http` link is back to working but `https` was still prefered during that change. Should we stick with `https`?

Hi Jai,

Given this is how it is in the README in the upstream repository and it is accessible, I would prefer not to change it and when/if we do, we should have the change made upstream

-------------

PR: https://git.openjdk.org/jdk/pull/10773

From jpai at openjdk.org  Thu Oct 20 10:22:49 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 10:22:49 GMT
Subject: RFR: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <5CrW0G8-8ADGqladZ0zQkRkFyHIZ7OHjpm_2eaZYvP4=.d8958a63-1e66-424d-8c93-bfed859b6db4@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
 <cs5_hQVuC3hZRUJMDGOV9Fgm0xSIv3pmjB8I8L6N4AQ=.2a0a5bbb-e174-4015-9d86-516d0aa38b57@github.com>
 <5CrW0G8-8ADGqladZ0zQkRkFyHIZ7OHjpm_2eaZYvP4=.d8958a63-1e66-424d-8c93-bfed859b6db4@github.com>
Message-ID: <8CgWYe2Kh-1rAbje_R1B2b9BS7r6v10iYclgtg7oMag=.7b97627b-05d1-4755-83d6-044cb75394ff@github.com>

On Thu, 20 Oct 2022 10:15:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/native/libzip/zlib/README line 6:
>> 
>>> 4: thread safe.  The data format used by the zlib library is described by RFCs
>>> 5: (Request for Comments) 1950 to 1952 in the files
>>> 6: http://tools.ietf.org/html/rfc1950 (zlib format), rfc1951 (deflate format) and
>> 
>> Hello Lance, it appears that we had done this change to this file in the JDK as part of https://bugs.openjdk.org/browse/JDK-8283525. As Sean notes in that issue, the `http` link is back to working but `https` was still prefered during that change. Should we stick with `https`?
>
> Hi Jai,
> 
> Given this is how it is in the README in the upstream repository and it is accessible, I would prefer not to change it and when/if we do, we should have the change made upstream

Thank you Lance, that sounds fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10773

From ihse at openjdk.org  Thu Oct 20 10:36:03 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 10:36:03 GMT
Subject: Integrated: 8295470: Update openjdk.java.net => openjdk.org URLs in
 test code
In-Reply-To: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
References: <dXAa-oTGp9N46ClVC2y7aNLFyaZmWnnDaiqfrfPodTU=.35e261ec-2012-40f8-81e7-303a93a49505@github.com>
Message-ID: <ikUR8BWcMaOfzg0XpZjCi7OeWhugVYhHsAcXp2KZV1k=.0baf7f30-4033-44f8-b6ea-19442a984b97@github.com>

On Tue, 18 Oct 2022 11:55:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a continuation of the effort to update all our URLs to the new top-level domain.
> 
> This patch updates (most) URLs in testing code. There still exists references to openjdk.java.net, but that are not strictly used as normal URLs, which I deemed need special care, so I left them out of this one, which is more of a straight-forward search and replace.
> 
> I have manually verified that the links work (or points to bugs.openjdk.org and looks sane; I did not click on all those). I have replaced `http` with `https`. I have replaced links to specific commits on the mercurial server with links to the corresponding commits in the new git repos.

This pull request has now been integrated.

Changeset: d5a1521f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5a1521fde3f6ff7e810e8257a4722a09c9ef60b
Stats:     138 lines in 45 files changed: 46 ins; 0 del; 92 mod

8295470: Update openjdk.java.net => openjdk.org URLs in test code

Reviewed-by: michaelm, prr, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/10744

From rgiulietti at openjdk.org  Thu Oct 20 10:50:25 2022
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 20 Oct 2022 10:50:25 GMT
Subject: Integrated: 8294705: Disable an assertion in
 test/jdk/java/util/DoubleStreamSums/CompensatedSums.java
In-Reply-To: <c7HjXcVRhWCTAZ1Tf7AM5YDvdyjdieIC2o9LPnZdYfU=.aeb7977f-2d7e-4775-afdf-46b87fa8eed5@github.com>
References: <c7HjXcVRhWCTAZ1Tf7AM5YDvdyjdieIC2o9LPnZdYfU=.aeb7977f-2d7e-4775-afdf-46b87fa8eed5@github.com>
Message-ID: <hC0HnPNWA4nLrs5i45hqYB54kXUX5PeWXJXYA6fv3EA=.65278472-6351-4035-961e-c9cac8bd97b2@github.com>

On Mon, 3 Oct 2022 08:23:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Disables a specific assertion that causes intermittent failures.

This pull request has now been integrated.

Changeset: c08ff2c7
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c08ff2c7b88e94885f6b4701654a9e47e49567b0
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8294705: Disable an assertion in test/jdk/java/util/DoubleStreamSums/CompensatedSums.java

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/10529

From ihse at openjdk.org  Thu Oct 20 12:06:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 12:06:27 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
Message-ID: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>

Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).

The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

-------------

Commit messages:
 - 8295729: Add jcheck whitespace checking for properties files

Changes: https://git.openjdk.org/jdk/pull/10792/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295729
  Stats: 1105 lines in 368 files changed: 0 ins; 0 del; 1105 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From sspitsyn at openjdk.org  Thu Oct 20 14:34:19 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Oct 2022 14:34:19 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <EGTFUUFqShqr3vjtYisj2s0-fA1y5nrwC5QYj3gMPyM=.194e98d2-0c98-4899-a7e8-e02f36646315@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Marked as reviewed by sspitsyn (Reviewer).

Two reviews are required in the Serviceability area.
So, please, wait for one more.

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From jpai at openjdk.org  Thu Oct 20 14:47:53 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 14:47:53 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <-jTKvVALRloZ4SS6xWVZYOtfN6IDo4dVDRNhH4OnY_0=.2b6327a2-c5af-491b-9963-65fb9128d22b@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Thank you again Serguei for the review.

> Two reviews are required in the Serviceability area.
So, please, wait for one more.

I wasn't aware of that. Will certainly wait. I have triggered some tests in our internal CI system too to make sure the latest runs too are clean.

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From naoto at openjdk.org  Thu Oct 20 16:03:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 16:03:56 GMT
Subject: Integrated: 8295564: Norwegian Nynorsk Locale is missing formatting
In-Reply-To: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
References: <5P5vg_h-kV7U7EmM2L8Jhv5uycJdjoO-vaa_5hq9yWQ=.41e47f03-82a2-4679-b5d3-3890bc492a3c@github.com>
Message-ID: <zvahMEJvmX67hhnk43uXXN9O7ceKqoH7FNo0iTNog7w=.61b56729-44bd-41f0-bf37-8171d8787e9a@github.com>

On Wed, 19 Oct 2022 19:04:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by upgrading CLDR to version 39 (JDK-8258794), in which CLDR changed the locale inheritance for Norwegian. Some locale data (including number elements) that were in `nn` locale was moved to `no`. There was a code in CLDRConverter that specially handles `no` locale not to copy its data as parent locale data. That special handling is no longer needed after v39.
> It's amazing to see this bug has been lurking unnoticed till now.

This pull request has now been integrated.

Changeset: b37421e7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b37421e7578c108df87c24c93dcbc1f358f6c257
Stats:     12 lines in 3 files changed: 8 ins; 2 del; 2 mod

8295564: Norwegian Nynorsk Locale is missing formatting

Reviewed-by: iris, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10774

From msheppar at openjdk.org  Thu Oct 20 16:16:53 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 20 Oct 2022 16:16:53 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <eqttcOVozBKxZWZwhgARUS_nMXI3U-dc-vG7RSzKb9A=.d2dac29b-87cd-49e2-9be7-8e792113dcde@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

yes, I think we found the change will be benefial

-------------

Marked as reviewed by msheppar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10322

From duke at openjdk.org  Thu Oct 20 17:12:54 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 17:12:54 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v9]
In-Reply-To: <ZEULntdAZ-UaQjJ89sYJN1KVocbGZazoWgBc_mbBMgg=.3aaf35bb-5164-40bd-841d-fa9a07c3da52@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <ytOn2N-rvAPIxOthSW6qhIzzeeo686MLQHnaTucZea4=.a1c10d17-8f55-473a-8d57-a3b8ba3c9e06@github.com>
 <ZEULntdAZ-UaQjJ89sYJN1KVocbGZazoWgBc_mbBMgg=.3aaf35bb-5164-40bd-841d-fa9a07c3da52@github.com>
Message-ID: <Efqtg7DKHtIrsxMM5trF7CZRrp72h9-eP9HKwMwYleI=.8c36ab5b-6656-40ae-837c-f8840d2a0a84@github.com>

On Wed, 19 Oct 2022 22:20:56 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Additional cleanup and string formatting
>
> test/jdk/java/util/Formatter/BasicTestLauncher.java line 90:
> 
>> 88:             ProcessBuilder pb = ProcessTools.createTestJvm(JAVA_OPTS, TEST_CLASS);
>> 89:             pb.environment().put("TZ", timeZone);
>> 90:             Process process = pb.start();
> 
> Nit: indentation

Fixed, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From erikj at openjdk.org  Thu Oct 20 18:26:46 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:26:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <NObZDn88VUQ8fHaLhcrqe0wkth0EfVAwjWA7K4eAY2k=.0c70399e-f307-4ca4-a637-e2f1ebedf960@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Nice job!

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 18:33:47 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 18:33:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

LGTM. Haven't looked at all the l10n files.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Thu Oct 20 18:40:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:40:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I would vote against this change.  Per java properties spec
https://github.com/openjdk/jdk/pull/10792


White space following the property value is not ignored, and is treated as part of the property value.


This change might break localization or messages where trailing whitespace is important (example: "Label: ")

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Thu Oct 20 18:48:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:48:17 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> I would vote against this change.  Per java properties spec
> https://github.com/openjdk/jdk/pull/10792
> 
> 
> White space following the property value is not ignored, and is treated as part of the property value.
> 
> 
> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
> 
> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
> 
> 
> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;

@andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From erikj at openjdk.org  Thu Oct 20 18:53:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:53:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <qf8daMUSgSlaXN3bROLfbFbpzrDJh5wSJdnTYQdol64=.df762075-9646-4aab-ab95-ead96e45936a@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Given that trailing whitespace may be part of a property value, then I take back my review.

-------------

Changes requested by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From cjplummer at openjdk.org  Thu Oct 20 18:53:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 18:53:50 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <uNs096Y7_C0U9CTifzO1PL71uAgKv0RwAxTfOuL5LGw=.e8e725f6-3fac-4b54-b406-111628923ae8@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> `White space following the property value is not ignored, and is treated as part of the property value.`

Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Thu Oct 20 18:53:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:53:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
 <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
Message-ID: <HJm4YG5tr3dJ4SeXPS58BEpkBqzUEk7QwX6Cmf5x8JA=.7076b0a9-6fe2-4e0a-99f9-d3ca8a828a5a@github.com>

On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I would vote against this change.  Per java properties spec
>> https://github.com/openjdk/jdk/pull/10792
>> 
>> 
>> White space following the property value is not ignored, and is treated as part of the property value.
>> 
>> 
>> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
>> 
>> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
>> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
>> 
>> 
>> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;
>
> @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

@magicus  : 
no, this is how Properties were working from day one.


package goryachev.research;

import java.io.IOException;
import java.io.StringReader;
import java.util.Properties;

public class TestProperties {
    public static void main(String[] args) throws IOException {
        String text = "key= value ";
        Properties p = new Properties();
        p.load(new StringReader(text));
        System.out.println("value=["  +p.getProperty("key") + "]");
    }
}


outputs:

value=[value ]

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Thu Oct 20 19:07:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:07:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <vN85_fh3ocln38nEOKYh1GBwW5xzb3nIo_jYOQYqiLY=.6e65e099-3d3c-40fe-8cfa-1acf25fdd0a7@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Okay. That definitely rules out adding .properties to the whitespace jcheck verification.

However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language.

I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes.

For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct.

Does that sound reasonable?

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Thu Oct 20 19:29:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:29:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <iu-qPLbaWYYTSq2jVgsGXDGt8Weqq2RVuoaHyuI0YRg=.f4131b5a-9685-4246-bbac-85b776fee6e3@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Retracting my approval too. Thanks for the catch, Andy!
That sounds reasonable > Magnus

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From bchristi at openjdk.org  Thu Oct 20 19:38:51 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 20 Oct 2022 19:38:51 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v10]
In-Reply-To: <HMF74-B4H_V6RfMfZn3J-Ju5-cCg7uVjg_aPzkIjYlk=.983b5e05-9aa2-437d-b1db-4fc8ee71ee67@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <HMF74-B4H_V6RfMfZn3J-Ju5-cCg7uVjg_aPzkIjYlk=.983b5e05-9aa2-437d-b1db-4fc8ee71ee67@github.com>
Message-ID: <ZKQGr4LnCQZ67AwQ3ZW42SG_ZdjHr51MSOTsY6UqQM4=.ca93e2e5-3af6-4d19-bc3f-d4fa2450078f@github.com>

On Wed, 19 Oct 2022 22:36:07 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Thu Oct 20 19:40:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:40:55 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <eJ0YaIIkCYOV7stEG2AEVx05evyYix9H9Zp2eAlJsjA=.2e14e322-75f6-4651-bb96-c24cf2f10391@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

(retracting approval)

-------------

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Thu Oct 20 19:56:04 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 19:56:04 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v11]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <6HfArHy7s1R2gdxJfHWbyTgnfqNsZhhgGkVjF1Kp1ZY=.ec84bdd8-a449-4ec7-96c6-d9063f18f7a7@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Spacing conventions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/5a0ee74f..676a1025

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From lancea at openjdk.org  Thu Oct 20 20:14:58 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 20 Oct 2022 20:14:58 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v11]
In-Reply-To: <6HfArHy7s1R2gdxJfHWbyTgnfqNsZhhgGkVjF1Kp1ZY=.ec84bdd8-a449-4ec7-96c6-d9063f18f7a7@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <6HfArHy7s1R2gdxJfHWbyTgnfqNsZhhgGkVjF1Kp1ZY=.ec84bdd8-a449-4ec7-96c6-d9063f18f7a7@github.com>
Message-ID: <Yj6SsiV8p-lfIk2J9aIrBFQNo6qLMDqIh67WfYU9Ops=.dcfdc4cf-eaf1-46f2-8d7b-e2a456ecf317@github.com>

On Thu, 20 Oct 2022 19:56:04 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spacing conventions

Marked as reviewed by lancea (Reviewer).

test/jdk/java/util/Formatter/Basic.java line 94:

> 92:             var tests_message = "%d tests: %d failure(s)%n".formatted(fail + pass, fail);
> 93:             var trace_message = "Traceback of the first error located";
> 94:             String message = "%s %s".formatted(tests_message, trace_message);

could use "var" as the previous statements ;-)

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Thu Oct 20 20:17:59 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 20:17:59 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v12]
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Format with var

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10715/files
  - new: https://git.openjdk.org/jdk/pull/10715/files/676a1025..781b352d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10715&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10715.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10715/head:pull/10715

PR: https://git.openjdk.org/jdk/pull/10715

From naoto at openjdk.org  Thu Oct 20 20:19:37 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 20:19:37 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v12]
In-Reply-To: <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
Message-ID: <y6OSTdxkbn6QGtCeEruqrthA-heF8NrmuXHKyujRKC4=.6ed49649-d319-4ae0-8ec2-7961ed834713@github.com>

On Thu, 20 Oct 2022 20:17:59 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format with var

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Thu Oct 20 20:30:47 2022
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 20 Oct 2022 20:30:47 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image
In-Reply-To: <NxXmUUagk50u3nsp_b3WG9aWHRfZ3ePtxz5khEI_jho=.bd6df532-7f4f-4566-ba1f-ca09a704ad40@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
 <GOnGa913EJP5z4E7wVAu1kIGoFidP-hKqnrD7tQv_Dc=.695e46ef-617a-4406-a76c-629f18d52cc8@github.com>
 <NxXmUUagk50u3nsp_b3WG9aWHRfZ3ePtxz5khEI_jho=.bd6df532-7f4f-4566-ba1f-ca09a704ad40@github.com>
Message-ID: <N3DjL7HSkttc4k3lOt6DJ3tl_ajNzgNCBjmKWKYfteU=.9b2d810e-8328-4e51-abd4-a470103be1e7@github.com>

On Sun, 16 Oct 2022 16:22:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think there are still issues. As a quick test, set the maximum number of descriptors to generate per method to less than 70, so that you get Sub0, Sub1, ... generated. Then try `java -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal -version` to see if the verify is okay with it.

Thank you for the hint - this is the output. -- Now, I have more food-for-thought. ^^


$ build/windows-x86_64-server-release/images/jdk/bin/java --add-modules ALL-MODULE-PATH -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions  -XX:+BytecodeVerificationLocal -version
Error occurred during initialization of boot layer
java.lang.VerifyError: Bad local variable type
Exception Details:
  Location:
    jdk/internal/module/SystemModules$all.moduleDescriptorsSub1([Ljava/lang/module/ModuleDescriptor;)V @19: aload
  Reason:
    Type top (current frame, locals[15]) is not assignable to reference type
  Current Frame:
    bci: @19
    flags: { }
    locals: { 'jdk/internal/module/Builder', '[Ljava/lang/module/ModuleDescriptor;' }
    stack: { 'jdk/internal/module/Builder', 'jdk/internal/module/Builder', '[Ljava/lang/module/ModuleDescriptor$Requires;', '[Ljava/lang/module/ModuleDescriptor$Requires;', integer }
  Bytecode:
    0000000: bb00 1159 1309 ddb7 0016 4b2a 2a05 bd00
    0000010: 1859 0319 0f12 13b8 0288 5359 0419 1213
    0000020: 02a4 b802 8853 b600 1c2a 07bd 001e 5903
    0000030: 1904 1309 dfb8 0038 5359 0419 0413 09e1
    0000040: b800 3853 5905 1904 1309 e3b8 0038 5359
    0000050: 0619 0413 09e5 b800 3853 b601 8d2a 03bd
    0000060: 018f b601 932a 1917 b601 dd57 2a03 bd01
    0000070: dfb6 01f4 1309 df13 09e1 1309 e313 09e5
    0000080: b801 004d 2a2c b602 7357 2a13 0275 b602
    0000090: 7957 2b10 462a 1309 e6b6 027e 53b1

        at java.base/jdk.internal.module.SystemModulesMap.allSystemModules(Unknown Source)
        at java.base/jdk.internal.module.SystemModuleFinders.allSystemModules(SystemModuleFinders.java:102)
        at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:236)
        at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
        at java.base/java.lang.System.initPhase2(System.java:2214)

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From bchristi at openjdk.org  Thu Oct 20 21:11:53 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 20 Oct 2022 21:11:53 GMT
Subject: RFR: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher [v12]
In-Reply-To: <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
 <Ye3DzfuRR6gYEhTgrX-k84aA4tB26NO7oQIcTvFRJHM=.181bf100-c6a0-4dd8-bee2-a3579e1e49f6@github.com>
Message-ID: <xB6wr-uSyKTl-VmVlWAUn2N3Iu5R-Z8JrFqEiq5f8Xs=.c5ee450f-3eb3-483e-ab08-a71eeac9c4c0@github.com>

On Thu, 20 Oct 2022 20:17:59 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Formatter unit tests are launched via basic.sh
>> 
>> Fix: Replace basic.sh with a Java test launcher
>> 
>> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
>> 
>> 
>> Original output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
>> 
>> 
>> New output on success
>> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Format with var

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From duke at openjdk.org  Thu Oct 20 22:40:59 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 22:40:59 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v2]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <jsl7CK0mHLtnnpMf3FgBOcRnAaJHt2bImZrMakt7Cao=.931b12a7-edd6-4dd8-8eba-9bba91769f54@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Make fixes to validateGetBundle
  
  US locale, new case check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/609a6d07..646ee97a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=00-01

  Stats: 11 lines in 1 file changed: 4 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Thu Oct 20 23:00:00 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 23:00:00 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v3]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <81auAxAyb1AJm8iscN5qgWAazksik-785pZLv69XAls=.98c45d68-28ba-4b79-aeb1-66090093fe9c@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Run against US locale, fail test if exp not caught

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/646ee97a..1ce2671c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=01-02

  Stats: 13 lines in 3 files changed: 10 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Thu Oct 20 23:34:05 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 23:34:05 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v4]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <raywlUCJeQQ9oCgTAd7iY1PXCUNvyEdkQOUiOlSPvU0=.eff5d673-5b3c-4545-9bf5-3e4b336ba4d3@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Run Validate_.java in othervm mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/1ce2671c..3e49163b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Thu Oct 20 23:50:55 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 20 Oct 2022 23:50:55 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v4]
In-Reply-To: <3gznEQtJ7-iKamPcW8KIrpram7j-JKnE3nzY5QPC9ac=.188c26d1-402f-4ce4-b129-7dc0592f792a@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <3gznEQtJ7-iKamPcW8KIrpram7j-JKnE3nzY5QPC9ac=.188c26d1-402f-4ce4-b129-7dc0592f792a@github.com>
Message-ID: <Hx7aP9LoKx3hyqzlgo6WAlwuB_eWbBE9A3uZYq_MLzM=.11850702-2b6a-4755-97f3-da9e629a9bee@github.com>

On Wed, 19 Oct 2022 22:21:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Run Validate_.java in othervm mode
>
> test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 45:
> 
>> 43:     private static final String PATH_TO_BUNDLE = "com/sun/rowset/RowSetResourceBundle";
>> 44:     // Default Locale
>> 45:     private static final Locale DEFAULT_LOCALE = Locale.getDefault();
> 
> Is using the default locale OK? What if the test is run under some locale where JDBC does not provide the localized bundle?

Switched default to constant US locale

> test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 62:
> 
>> 60:     private static void testResourceBundleAccess(String bundleName, boolean expectBundle) {
>> 61:         try {
>> 62:             var bundle = (PropertyResourceBundle) ResourceBundle.getBundle(
> 
> Is casting to `PropertyResourceBundle` needed? If you intend to check the bundle type, I'd explicitly check the type.

Thank you. Not needed, removed

> test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 64:
> 
>> 62:             var bundle = (PropertyResourceBundle) ResourceBundle.getBundle(
>> 63:                     bundleName, DEFAULT_LOCALE, JdbcRowSetResourceBundle.class.getModule());
>> 64:             System.out.printf("$$$ %s found as expected!%n", bundleName);
> 
> I think `expectBundle` needs to be examined here. If it is `false`, it should throw an exception.

Added a check there for case when expectBundle is false

> test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 42:
> 
>> 40:     private static final String invalidState = "Invalid state";
>> 41:     // Expected JDBCResourceBundle message, crsreader.connecterr
>> 42:     private static final String rsReaderError = "Internal Error in RowSetReader: no connection or command";
> 
> Should be tested in English environment, if the test is going to compare the result with English text.

Set default locale as US, running in othervm mode now as well

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From naoto at openjdk.org  Fri Oct 21 01:23:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 01:23:55 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v4]
In-Reply-To: <raywlUCJeQQ9oCgTAd7iY1PXCUNvyEdkQOUiOlSPvU0=.eff5d673-5b3c-4545-9bf5-3e4b336ba4d3@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <raywlUCJeQQ9oCgTAd7iY1PXCUNvyEdkQOUiOlSPvU0=.eff5d673-5b3c-4545-9bf5-3e4b336ba4d3@github.com>
Message-ID: <hIOSjmRjvHPZU_rQxE2YOVEMpxm1M7DAjVZR7xWPUxY=.7dbd78c1-c6e0-498d-b3ac-d95cc6423aa3@github.com>

On Thu, 20 Oct 2022 23:34:05 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run Validate_.java in othervm mode

Much better now. BTW, there seems to be a stray `.class` binary file included in this PR. Please remove it.

test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 61:

> 59:                     Locale.US, JdbcRowSetResourceBundle.class.getModule());
> 60:             if (!expectBundle) {
> 61:                 String message = "$$$ '%s' shouldn't have loaded!%n";

variable `message` is not needed

test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 67:

> 65:         } catch (MissingResourceException mr) {
> 66:             if (expectBundle) {
> 67:                 throw new RuntimeException(String.format("Error:%s%n", mr.getMessage()));

Probably the message could be more descriptive than a simple "Error". Also, instead of `mr.getMessage()`, use the 2-arg constructor that takes `mr` as the "cause". That would be straightforward.

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 49:

> 47:     public void testResourceBundleAccess() throws SQLException {
> 48:         // Checking against English messages, set to US Locale
> 49:         Locale.setDefault(Locale.US);

Could be placed in a separate static method with `@BeforeAll` annotation.

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 60:

> 58:             jrs.getMetaData();
> 59:             // Unexpected case where exception is not forced
> 60:             var msg = "$$$ Error: SQLException was not caught!%n";

The literal can directly be used as the argument to the constructor.

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 69:

> 67:             crs.execute();
> 68:             // Unexpected case where exception is not forced
> 69:             var msg = "$$$ Error: SQLException was not caught!%n";

Same as above

-------------

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10612

From jpai at openjdk.org  Fri Oct 21 06:06:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Oct 2022 06:06:51 GMT
Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException
 when a process on Windows returns an exit code of 259
In-Reply-To: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
References: <jtFpL_qJEWM33lK31hfIe6mKzuR0bSK2ti9l1qPMFdw=.664d3c7f-6179-4f21-9ecd-c6e13e5446fd@github.com>
Message-ID: <u647-qYJK1MsuVmrc3s_U41E-Sf54HrSucHE7_2sWh0=.d5354d65-2504-4510-a235-2b097ba4f279@github.com>

On Wed, 12 Oct 2022 16:30:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259.
> As described in the bug report, `waitFor()` should not be sensitive to the exit value.
> Previously, it erroneously threw IllegalStateException.
> Added a test to verify.

The reporter of the issue provided additional details that it was their own application/program which was returning that exit value:

> I encountered it while prototyping an idea involving a Java application spawning a process running a C++ application that returned an exit value indicating the number of items it processed.

So this appears like the case where this change would help. I haven't found any conclusive/official Windows documentation which forbids user applications from returning this exit value (which represents `STILL_ACTIVE`).

-------------

PR: https://git.openjdk.org/jdk/pull/10680

From ihse at openjdk.org  Fri Oct 21 08:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:17:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove check for .properties from jcheck
 - Restore trailing whitespace for property values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=00-01

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From jpai at openjdk.org  Fri Oct 21 08:29:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Oct 2022 08:29:51 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <7zx8mBlRbPNKN4gNtAtiD3Ha1P5iaw4j4VeUsy0LfPA=.ed01337f-83bf-496a-803e-ff79aef67b4e@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Thank you Mark for the review.

The CI tests for this came back fine.

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From ihse at openjdk.org  Fri Oct 21 08:31:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:31:59 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines.

I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From jpai at openjdk.org  Fri Oct 21 08:32:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Oct 2022 08:32:01 GMT
Subject: Integrated: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with
 cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <_IC9ikiTepKTv7KU3fGXyC6i8hh3GKUJAg9xCVjgzfc=.6184ddb6-7bd2-4059-a7cc-1d9028d7a86d@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

This pull request has now been integrated.

Changeset: 8b010e01
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b010e014c44ffb728b7a8343d3298466f5252fa
Stats:     7 lines in 2 files changed: 5 ins; 0 del; 2 mod

8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Reviewed-by: sspitsyn, msheppar

-------------

PR: https://git.openjdk.org/jdk/pull/10322

From lancea at openjdk.org  Fri Oct 21 10:49:18 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 21 Oct 2022 10:49:18 GMT
Subject: Integrated: 8295530: Update Zlib Data Compression Library to Version
 1.2.13
In-Reply-To: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
References: <Syqq2g-XttxYLY8Qtid3mttXkVvPeTZG5VuEqcJHdec=.9201b4c6-f5c3-4088-86c0-d5bf3977afe5@github.com>
Message-ID: <BmfqK49XLp95_WCy93olp6IjWH1QHlkMsCu0LPeRDrY=.24301f45-bcea-417b-b0aa-9ac9f1d9a49c@github.com>

On Wed, 19 Oct 2022 16:45:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which will update the Zlib Data Compression Library from 1.2.11 to 1.2.13.
> 
> - I have run all of the Mach5 tiers which did not show any issues related to the upgrade.
> - The JCK zip/jar tests also continue to pass.
> - Jai ran his macOS aarch64 test(for [JDK-8282954](https://bugs.openjdk.org/browse/JDK-8282954)) with the zlib 1.2.13 port and has not seen the failure as seen with the MacOS aarch64 native zlib port
> 
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: 0c13d666
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c13d66622a8c2be654bb867aa8c17421d1557ca
Stats:     11197 lines in 24 files changed: 9975 ins; 274 del; 948 mod

8295530: Update Zlib Data Compression Library to Version 1.2.13

Reviewed-by: alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/10773

From duke at openjdk.org  Fri Oct 21 12:00:53 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 21 Oct 2022 12:00:53 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v4]
In-Reply-To: <TmYiIVEScVEzhsWZPJ5KKDucoaJIy9EGGSKUUReS9Lg=.9fa366e7-3891-4f3d-9b03-4ed4cbb89430@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <IBXajKeImw6Gp47glepoN4QfDgV3hj3FQepZWCin0rI=.df4e490c-d87f-46a0-9343-7ebfb6da2708@github.com>
 <TmYiIVEScVEzhsWZPJ5KKDucoaJIy9EGGSKUUReS9Lg=.9fa366e7-3891-4f3d-9b03-4ed4cbb89430@github.com>
Message-ID: <zFpCTImkqNLMieYBPLoUtZnqJa3_t0ms5ZWxAaEx1Ek=.d0e0f14e-35da-48b0-95de-41a511dde163@github.com>

On Mon, 17 Oct 2022 19:42:14 GMT, liach <duke at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293630: Inline natural()
>
> src/java.base/share/classes/java/util/TreeMap.java line 3329:
> 
>> 3327:             }
>> 3328:             else {
>> 3329:                 return (Comparator<Map.Entry<K, V>> & Serializable) (e1, e2) -> {
> 
> I think this cast hints compiler to bootstrap lambda meta factory with extra Serializable marker interface. Meanwhile, Comparator.naturalOrder does not implement Serializable.

>From one point this is obviously a change in behaviour, from another the spec of `Spliterator.getComparator()` says nothing about serializability of returned comparator and the actual value is hardly ever going to be serialized.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From duke at openjdk.org  Fri Oct 21 12:13:56 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 21 Oct 2022 12:13:56 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v4]
In-Reply-To: <zFpCTImkqNLMieYBPLoUtZnqJa3_t0ms5ZWxAaEx1Ek=.d0e0f14e-35da-48b0-95de-41a511dde163@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <IBXajKeImw6Gp47glepoN4QfDgV3hj3FQepZWCin0rI=.df4e490c-d87f-46a0-9343-7ebfb6da2708@github.com>
 <TmYiIVEScVEzhsWZPJ5KKDucoaJIy9EGGSKUUReS9Lg=.9fa366e7-3891-4f3d-9b03-4ed4cbb89430@github.com>
 <zFpCTImkqNLMieYBPLoUtZnqJa3_t0ms5ZWxAaEx1Ek=.d0e0f14e-35da-48b0-95de-41a511dde163@github.com>
Message-ID: <jt4ncHkOR6ylMd48Pq3-5Fhgzv_mqLjjINnlZM85zxc=.e7891cb3-8382-4d3d-a998-91d78ae591d0@github.com>

On Fri, 21 Oct 2022 11:56:57 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TreeMap.java line 3329:
>> 
>>> 3327:             }
>>> 3328:             else {
>>> 3329:                 return (Comparator<Map.Entry<K, V>> & Serializable) (e1, e2) -> {
>> 
>> I think this cast hints compiler to bootstrap lambda meta factory with extra Serializable marker interface. Meanwhile, Comparator.naturalOrder does not implement Serializable.
>
> From one point this is obviously a change in behaviour, from another the spec of `Spliterator.getComparator()` says nothing about serializability of returned comparator and the actual value is hardly ever going to be serialized.

The?only new?comparator?that is?returned?here is?the?one?returned by?`Map.Entry.comparingByKey()`, which?is?also?`Serializable`.

The?only?place `Comparator.naturalOrder()` is?newly?used in?this?PR are?the?`final` `package?private`?`getEntry` and?`getEntryUsingComparator`?methods.

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From duke at openjdk.org  Fri Oct 21 12:20:54 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 21 Oct 2022 12:20:54 GMT
Subject: RFR: 8293630: Simplify TreeMap.get() with
 Comparator.naturalOrder() [v4]
In-Reply-To: <jt4ncHkOR6ylMd48Pq3-5Fhgzv_mqLjjINnlZM85zxc=.e7891cb3-8382-4d3d-a998-91d78ae591d0@github.com>
References: <gV_EahOUQIDq-71mp4aC8bFtrZyw_oKe9m9RuFP-0Uo=.f6bfbdc1-cc7d-43b6-8595-82f26be793ee@github.com>
 <IBXajKeImw6Gp47glepoN4QfDgV3hj3FQepZWCin0rI=.df4e490c-d87f-46a0-9343-7ebfb6da2708@github.com>
 <TmYiIVEScVEzhsWZPJ5KKDucoaJIy9EGGSKUUReS9Lg=.9fa366e7-3891-4f3d-9b03-4ed4cbb89430@github.com>
 <zFpCTImkqNLMieYBPLoUtZnqJa3_t0ms5ZWxAaEx1Ek=.d0e0f14e-35da-48b0-95de-41a511dde163@github.com>
 <jt4ncHkOR6ylMd48Pq3-5Fhgzv_mqLjjINnlZM85zxc=.e7891cb3-8382-4d3d-a998-91d78ae591d0@github.com>
Message-ID: <OxeMzfeoke0OdOjF5PyjDay-1hPAKJnRbYDtM6ZyzZs=.4f197c34-41f1-41a7-ac41-a13c2f8004fe@github.com>

On Fri, 21 Oct 2022 12:11:28 GMT, ExE Boss <duke at openjdk.org> wrote:

>> From one point this is obviously a change in behaviour, from another the spec of `Spliterator.getComparator()` says nothing about serializability of returned comparator and the actual value is hardly ever going to be serialized.
>
> The?only new?comparator?that is?returned?here is?the?one?returned by?`Map.Entry.comparingByKey()`, which?is?also?`Serializable`.
> 
> The?only?place `Comparator.naturalOrder()` is?newly?used in?this?PR are?the?`final` `package?private`?`getEntry` and?`getEntryUsingComparator`?methods.

Also, `Comparator.naturalOrder()` is?implemented using?an?`enum`, which?is?naturally?`Serializable`:
https://github.com/openjdk/jdk/blob/0c13d66622a8c2be654bb867aa8c17421d1557ca/src/java.base/share/classes/java/util/Comparators.java#L42-L59

-------------

PR: https://git.openjdk.org/jdk/pull/9901

From duke at openjdk.org  Fri Oct 21 12:45:51 2022
From: duke at openjdk.org (iaroslavski)
Date: Fri, 21 Oct 2022 12:45:51 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v16]
In-Reply-To: <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <vwMSsoJrQeIWTRaQfzAkWzYwpw5kGuLZkHKatFFL8pQ=.6a42b6eb-49c9-44a9-8f22-8bb305933403@github.com>
Message-ID: <6rmhQV0ELptS74Z9Y6bL-Zvrs7hgqhE05odKJkNxq-c=.2c472c92-b1ed-4bb3-a8b8-57b73b098b90@github.com>

On Tue, 2 Aug 2022 13:57:03 GMT, iaroslavski <duke at openjdk.org> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Optimized and unified buffer allocation
>   * Minor comment changes

Counting sort is in progress

-------------

PR: https://git.openjdk.org/jdk/pull/3938

From erikj at openjdk.org  Fri Oct 21 12:59:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 12:59:48 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <AoFGXlCHPgwZa3u0Kwp6W-h5k-I_Malb2gWa3tSxSbw=.500a110c-0c73-4205-9a2e-e281bfb3a730@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From djelinski at openjdk.org  Fri Oct 21 16:00:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Oct 2022 16:00:07 GMT
Subject: RFR: 8295792: Clean up old async close code
Message-ID: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>

Please review this PR that removes the remains of old fdTable-based socket close synchronization.

Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.

Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.

-------------

Commit messages:
 - Clean up after old async close

Changes: https://git.openjdk.org/jdk/pull/10816/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10816&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295792
  Stats: 1159 lines in 12 files changed: 0 ins; 1155 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10816.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10816/head:pull/10816

PR: https://git.openjdk.org/jdk/pull/10816

From alanb at openjdk.org  Fri Oct 21 16:06:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Oct 2022 16:06:49 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
Message-ID: <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>

On Fri, 21 Oct 2022 14:28:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes the remains of old fdTable-based socket close synchronization.
> 
> Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.
> 
> Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.

src/java.base/unix/native/libnet/net_util_md.c line 703:

> 701: 
> 702:         errno = 0;
> 703:         read_rv = poll(&pfd, 1, nanoTimeout / NET_NSEC_PER_MSEC);

I suspect this one will need to handle EINTR like the original code.

-------------

PR: https://git.openjdk.org/jdk/pull/10816

From naoto at openjdk.org  Fri Oct 21 16:09:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 16:09:28 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020".  This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Fri Oct 21 16:09:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Oct 2022 16:09:29 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
Message-ID: <khuIARsEyKMyIfUxBD69kijyjnwDFCzAra51YwctMyY=.71b00eb7-1312-4db9-a6a5-ff85f7635132@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> replace those dangling white spaces with explicit Unicode escapes

this is a *very good* idea.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Fri Oct 21 16:10:29 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 16:10:29 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v5]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <M7howggsQ1_QX5UNxnjO3vObK_AkK1CoOb7dLuev_LU=.d64bcd6f-ca15-4d51-a055-b9b5b3452b37@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove stray binary file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/3e49163b..c86950b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=03-04

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From naoto at openjdk.org  Fri Oct 21 17:03:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 17:03:15 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
Message-ID: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>

This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:

https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)

Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

-------------

Commit messages:
 - Merge branch 'master' into cldr+
 - 8284840: Update CLDR to Version 42.0
 - CLDR v42 release
 - v42 beta5
 - v42 beta3
 - v42 beta1
 - v42 alpha
 - alpha1b
 - v42 alpha1b
 - cldr v42 alpha1
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9612cf99...2d86b3c8

Changes: https://git.openjdk.org/jdk/pull/10820/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10820&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284840
  Stats: 99164 lines in 377 files changed: 68223 ins; 2820 del; 28121 mod
  Patch: https://git.openjdk.org/jdk/pull/10820.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10820/head:pull/10820

PR: https://git.openjdk.org/jdk/pull/10820

From djelinski at openjdk.org  Fri Oct 21 17:11:48 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Oct 2022 17:11:48 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
 <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>
Message-ID: <r9O6qyte-NOlWMdrg_PvYoqpcKmqne4tvwjQ32embg8=.0b1ec05a-83aa-432b-92a1-13d632464c61@github.com>

On Fri, 21 Oct 2022 16:04:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this PR that removes the remains of old fdTable-based socket close synchronization.
>> 
>> Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.
>> 
>> Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.
>
> src/java.base/unix/native/libnet/net_util_md.c line 703:
> 
>> 701: 
>> 702:         errno = 0;
>> 703:         read_rv = poll(&pfd, 1, nanoTimeout / NET_NSEC_PER_MSEC);
> 
> I suspect this one will need to handle EINTR like the original code.

as far as I can tell, this method retries all poll failures regardless of errno until timeout expires; NET_Poll retried EINTR, so I think we're good here. Or am I missing something?

-------------

PR: https://git.openjdk.org/jdk/pull/10816

From alanb at openjdk.org  Fri Oct 21 17:15:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Oct 2022 17:15:50 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <r9O6qyte-NOlWMdrg_PvYoqpcKmqne4tvwjQ32embg8=.0b1ec05a-83aa-432b-92a1-13d632464c61@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
 <-3jZJ7yBwycOAg2aL8V_M1ToNmcYCl10p_oNztnhgis=.223f5af1-d205-4f5a-8b1d-15a3c07ebb5c@github.com>
 <r9O6qyte-NOlWMdrg_PvYoqpcKmqne4tvwjQ32embg8=.0b1ec05a-83aa-432b-92a1-13d632464c61@github.com>
Message-ID: <-SFkot3YayLpzKRC4ia-jE30CpWkpTiqxLNAU9TaNN8=.c33c78d0-ea07-427c-9d93-36aef21216f4@github.com>

On Fri, 21 Oct 2022 17:08:07 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/unix/native/libnet/net_util_md.c line 703:
>> 
>>> 701: 
>>> 702:         errno = 0;
>>> 703:         read_rv = poll(&pfd, 1, nanoTimeout / NET_NSEC_PER_MSEC);
>> 
>> I suspect this one will need to handle EINTR like the original code.
>
> as far as I can tell, this method retries all poll failures regardless of errno until timeout expires; NET_Poll retried EINTR, so I think we're good here. Or am I missing something?

I think you are right, it's ignoring all errors so will continue to loop if interrupted.

-------------

PR: https://git.openjdk.org/jdk/pull/10816

From duke at openjdk.org  Fri Oct 21 17:21:26 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 17:21:26 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v6]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <nxTHoWAqjlBGoY1hJPm45qyWFbC-RX8oC8ZoVb_UZNE=.4d3cf516-d85f-4c05-8233-ad75a43423a3@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use @before, cleanup strings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/c86950b1..c67d789c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=04-05

  Stats: 12 lines in 1 file changed: 3 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 17:21:31 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 17:21:31 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v4]
In-Reply-To: <hIOSjmRjvHPZU_rQxE2YOVEMpxm1M7DAjVZR7xWPUxY=.7dbd78c1-c6e0-498d-b3ac-d95cc6423aa3@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <raywlUCJeQQ9oCgTAd7iY1PXCUNvyEdkQOUiOlSPvU0=.eff5d673-5b3c-4545-9bf5-3e4b336ba4d3@github.com>
 <hIOSjmRjvHPZU_rQxE2YOVEMpxm1M7DAjVZR7xWPUxY=.7dbd78c1-c6e0-498d-b3ac-d95cc6423aa3@github.com>
Message-ID: <2pAi9kI8KeX8PCrTQry-2B86N-tUoBT_zXDSEGKT8es=.f933dc99-ba34-40da-8740-ba42f49ba70d@github.com>

On Fri, 21 Oct 2022 01:17:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Run Validate_.java in othervm mode
>
> test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 49:
> 
>> 47:     public void testResourceBundleAccess() throws SQLException {
>> 48:         // Checking against English messages, set to US Locale
>> 49:         Locale.setDefault(Locale.US);
> 
> Could be placed in a separate static method with `@BeforeAll` annotation.

Good point, used TestNg's @BeforeClass

> test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 60:
> 
>> 58:             jrs.getMetaData();
>> 59:             // Unexpected case where exception is not forced
>> 60:             var msg = "$$$ Error: SQLException was not caught!%n";
> 
> The literal can directly be used as the argument to the constructor.

Right, made the change

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 17:24:20 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 17:24:20 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v7]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <7YZxUhbkbotsWfr18_6IUaErKRZAijg461y10Gy5Djc=.d851d552-5c5b-4255-8732-67924c58cb59@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary local String var

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/c67d789c..0aa978cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 17:24:23 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 17:24:23 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v4]
In-Reply-To: <hIOSjmRjvHPZU_rQxE2YOVEMpxm1M7DAjVZR7xWPUxY=.7dbd78c1-c6e0-498d-b3ac-d95cc6423aa3@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <raywlUCJeQQ9oCgTAd7iY1PXCUNvyEdkQOUiOlSPvU0=.eff5d673-5b3c-4545-9bf5-3e4b336ba4d3@github.com>
 <hIOSjmRjvHPZU_rQxE2YOVEMpxm1M7DAjVZR7xWPUxY=.7dbd78c1-c6e0-498d-b3ac-d95cc6423aa3@github.com>
Message-ID: <Yt-7nikyNRDgJGeWDKTBPnlqx39MXgZ5FSzRq6wfs5Q=.6d9cb2a4-44d7-41fb-abfb-19a2c7c6a502@github.com>

On Fri, 21 Oct 2022 01:08:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Run Validate_.java in othervm mode
>
> test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 61:
> 
>> 59:                     Locale.US, JdbcRowSetResourceBundle.class.getModule());
>> 60:             if (!expectBundle) {
>> 61:                 String message = "$$$ '%s' shouldn't have loaded!%n";
> 
> variable `message` is not needed

Got rid of it ?

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 17:35:22 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 17:35:22 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v8]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <tlz6UMek5SYHlTxhGTNVmfrX0KWsown0GSUTVpuioEw=.5c3951c5-1eaf-410f-b436-80cfd3469c30@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Pass exception to constuctor directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/0aa978cb..1aa881bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=06-07

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 17:35:26 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 17:35:26 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v4]
In-Reply-To: <hIOSjmRjvHPZU_rQxE2YOVEMpxm1M7DAjVZR7xWPUxY=.7dbd78c1-c6e0-498d-b3ac-d95cc6423aa3@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <raywlUCJeQQ9oCgTAd7iY1PXCUNvyEdkQOUiOlSPvU0=.eff5d673-5b3c-4545-9bf5-3e4b336ba4d3@github.com>
 <hIOSjmRjvHPZU_rQxE2YOVEMpxm1M7DAjVZR7xWPUxY=.7dbd78c1-c6e0-498d-b3ac-d95cc6423aa3@github.com>
Message-ID: <0ZtJ-HXfgD4Fru2do_1-4Binl-njvpqXYNHk19UwNuU=.f599745f-eec3-473e-ab84-e47dc541024a@github.com>

On Fri, 21 Oct 2022 01:13:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Run Validate_.java in othervm mode
>
> test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 67:
> 
>> 65:         } catch (MissingResourceException mr) {
>> 66:             if (expectBundle) {
>> 67:                 throw new RuntimeException(String.format("Error:%s%n", mr.getMessage()));
> 
> Probably the message could be more descriptive than a simple "Error". Also, instead of `mr.getMessage()`, use the 2-arg constructor that takes `mr` as the "cause". That would be straightforward.

Made the change and passed exception directly to constructor

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From erikj at openjdk.org  Fri Oct 21 17:36:26 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 17:36:26 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <zBQjCxYhczKsyNq1Pxy9QWV5FHvqUUWc4jl8-lpHOpI=.9c78ed55-cff6-412c-a765-fccef81e4282@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Fri Oct 21 18:13:34 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 18:13:34 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v9]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <af8TbhYtrs-DEm12kp_5nc0CwXoCHi1o63JcecokNQY=.2da8ee76-b4b9-4d6f-b975-c63be055ec8f@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Clean up jtreg tags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/1aa881bc..2ea3e423

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From lancea at openjdk.org  Fri Oct 21 18:13:37 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 21 Oct 2022 18:13:37 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v8]
In-Reply-To: <tlz6UMek5SYHlTxhGTNVmfrX0KWsown0GSUTVpuioEw=.5c3951c5-1eaf-410f-b436-80cfd3469c30@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <tlz6UMek5SYHlTxhGTNVmfrX0KWsown0GSUTVpuioEw=.5c3951c5-1eaf-410f-b436-80cfd3469c30@github.com>
Message-ID: <KU0EpvTaO_47O_SjkePK4Hwa2aLeV90wrTflPurBYus=.ea896d1b-2c14-4e41-98f3-c1d6e206436d@github.com>

On Fri, 21 Oct 2022 17:35:22 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass exception to constuctor directly

Hi Justin,

A few minor change requests.

Thank you for tackling this

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 41:

> 39: public class ValidateResourceBundleAccess{
> 40:     // Expected JDBCResourceBundle message, jdbcrowsetimpl.invalstate
> 41:     private static final String invalidState = "Invalid state";

Please make the constant names upper case

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 63:

> 61:             // Unexpected case where exception is not forced
> 62:             throw new RuntimeException(
> 63:                     String.format("$$$ Error: SQLException was not caught!%n"));

As you are not passing any parameters, this can just be a String omitting the "%n"

Also, it would tweak the String to be "Expected SQLException.... thrown"

test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 72:

> 70:             // Unexpected case where exception is not forced
> 71:             throw new RuntimeException(
> 72:                     String.format("$$$ Error: SQLException was not caught!%n"));

Same comment about not needing to use String.format.

Also, it would tweak the String to be "Expected SQLException.... thrown"

-------------

Changes requested by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 18:56:51 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 18:56:51 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v8]
In-Reply-To: <KU0EpvTaO_47O_SjkePK4Hwa2aLeV90wrTflPurBYus=.ea896d1b-2c14-4e41-98f3-c1d6e206436d@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <tlz6UMek5SYHlTxhGTNVmfrX0KWsown0GSUTVpuioEw=.5c3951c5-1eaf-410f-b436-80cfd3469c30@github.com>
 <KU0EpvTaO_47O_SjkePK4Hwa2aLeV90wrTflPurBYus=.ea896d1b-2c14-4e41-98f3-c1d6e206436d@github.com>
Message-ID: <DwsPMKjJVcLYD-tQpcm9L6kiIcFXtnIIN-T4zHHtFAU=.fc4df15e-4156-46dc-b353-8e27900ddb44@github.com>

On Fri, 21 Oct 2022 18:03:27 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass exception to constuctor directly
>
> test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 41:
> 
>> 39: public class ValidateResourceBundleAccess{
>> 40:     // Expected JDBCResourceBundle message, jdbcrowsetimpl.invalstate
>> 41:     private static final String invalidState = "Invalid state";
> 
> Please make the constant names upper case

Missed that, made the fix, thank you

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 19:00:12 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 19:00:12 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v8]
In-Reply-To: <KU0EpvTaO_47O_SjkePK4Hwa2aLeV90wrTflPurBYus=.ea896d1b-2c14-4e41-98f3-c1d6e206436d@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <tlz6UMek5SYHlTxhGTNVmfrX0KWsown0GSUTVpuioEw=.5c3951c5-1eaf-410f-b436-80cfd3469c30@github.com>
 <KU0EpvTaO_47O_SjkePK4Hwa2aLeV90wrTflPurBYus=.ea896d1b-2c14-4e41-98f3-c1d6e206436d@github.com>
Message-ID: <ZlsWEgVXfweYlZXBSBk4FFe9aDHpKkIqlwc72Z0feBQ=.03f88260-855b-4e61-af76-d18f6f978c30@github.com>

On Fri, 21 Oct 2022 18:04:29 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass exception to constuctor directly
>
> test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 63:
> 
>> 61:             // Unexpected case where exception is not forced
>> 62:             throw new RuntimeException(
>> 63:                     String.format("$$$ Error: SQLException was not caught!%n"));
> 
> As you are not passing any parameters, this can just be a String omitting the "%n"
> 
> Also, it would tweak the String to be "Expected SQLException.... thrown"

Will adjust the exception message

> test/jdk/javax/sql/testng/test/rowset/ValidateResourceBundleAccess.java line 72:
> 
>> 70:             // Unexpected case where exception is not forced
>> 71:             throw new RuntimeException(
>> 72:                     String.format("$$$ Error: SQLException was not caught!%n"));
> 
> Same comment about not needing to use String.format.
> 
> Also, it would tweak the String to be "Expected SQLException.... thrown"

Good point, Naoto actually recommended the same with the .format(), but I thought that I should preserve the newline.

Like you said %n should not be needed, will make the fix.

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From iris at openjdk.org  Fri Oct 21 19:02:53 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 21 Oct 2022 19:02:53 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <OwWUFy4vsIhZhu3c10e5ICNeQn8m3gDld0Hq9hni5z8=.a5f4a70b-b501-4a86-ade8-6c907fe9a777@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Fri Oct 21 19:04:31 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 19:04:31 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v10]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <K-3DlM2ZtESTR2ITi-92qYhlLwgyFDJ2to5URC4E1RY=.935d8ed4-f4d2-4ca8-8663-382f1f6c6e03@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  constant fix, better exception msg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/2ea3e423..2e39c411

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=08-09

  Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From joehw at openjdk.org  Fri Oct 21 19:20:52 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 21 Oct 2022 19:20:52 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Are the first two items (CLDR-14032, CLDR-14831) considered a behavior change (e.g. the format string will be different) that could use a CSR or the release notes to document it? I see the later points to the CLDR release notes, but maybe a statement in our release notes could be clearer?

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From naoto at openjdk.org  Fri Oct 21 19:48:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 19:48:48 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
Message-ID: <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>

On Fri, 21 Oct 2022 19:16:57 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Are the first two items (CLDR-14032, CLDR-14831) considered a behavior change (e.g. the format string will be different) that could use a CSR or the release notes to document it? I see the later points to the CLDR release notes, but maybe a statement in our release notes could be clearer?

Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Fri Oct 21 19:55:55 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 19:55:55 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v11]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <bvWQIovb_SKpdakNpbxEqUsBLC1xD_m7ziPsDtDIW1M=.5dad9cdb-c97d-43a2-8f9c-f2ce4ffcd8bd@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  white space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/2e39c411..8f0b6ac6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From naoto at openjdk.org  Fri Oct 21 20:25:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 20:25:51 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <I2D8h7jYM6Ui_dIwrG18ubpDbgCbuWK7z6TMrdzzXM4=.a418362e-8486-406c-941e-915a373d426a@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Draft release notes: https://bugs.openjdk.org/browse/JDK-8284841

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From joehw at openjdk.org  Fri Oct 21 21:20:45 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 21 Oct 2022 21:20:45 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <ouIQerKy4eztpVMUk81sgJ3S5Pl0dWzZ1YmHBKAWIv4=.17d18acf-61d2-41cc-bbec-e0c3e11621d9@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

Release notes look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Fri Oct 21 21:25:49 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Fri, 21 Oct 2022 21:25:49 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <5wDxwNmRqMrWUBsDY7cqbSpQkBzEObD77phocsEsZSI=.d6461367-1ae8-4506-8cfb-98755c35adaf@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

hi folks ? looking good??congats on the quick update!

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From bhuang at openjdk.org  Fri Oct 21 21:52:48 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Fri, 21 Oct 2022 21:52:48 GMT
Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process
Message-ID: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>

The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 

Tests include: 
java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

-------------

Commit messages:
 - Updated TEST.groups
 - JDK-8295756 Improve NonLocalRegistry Manual Test Process

Changes: https://git.openjdk.org/jdk/pull/10825/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295756
  Stats: 270 lines in 6 files changed: 235 ins; 2 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/10825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825

PR: https://git.openjdk.org/jdk/pull/10825

From bchristi at openjdk.org  Fri Oct 21 22:14:52 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 21 Oct 2022 22:14:52 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v11]
In-Reply-To: <bvWQIovb_SKpdakNpbxEqUsBLC1xD_m7ziPsDtDIW1M=.5dad9cdb-c97d-43a2-8f9c-f2ce4ffcd8bd@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <bvWQIovb_SKpdakNpbxEqUsBLC1xD_m7ziPsDtDIW1M=.5dad9cdb-c97d-43a2-8f9c-f2ce4ffcd8bd@github.com>
Message-ID: <mOKTvUQOkQe756fpn316BU4OJzVzezIuysKP05kTML0=.891f767c-c91f-4a56-9000-ba35ac226a8d@github.com>

On Fri, 21 Oct 2022 19:55:55 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   white space

test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 49:

> 47:         // The resource bundle will not be found when the path is specified
> 48:         testResourceBundleAccess(PATH_TO_BUNDLE, false);
> 49:     }

It seems to me this could be reworked into a `DataProvider` for `testResourceBundleAccess()`.

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 22:25:55 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 22:25:55 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v11]
In-Reply-To: <mOKTvUQOkQe756fpn316BU4OJzVzezIuysKP05kTML0=.891f767c-c91f-4a56-9000-ba35ac226a8d@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <bvWQIovb_SKpdakNpbxEqUsBLC1xD_m7ziPsDtDIW1M=.5dad9cdb-c97d-43a2-8f9c-f2ce4ffcd8bd@github.com>
 <mOKTvUQOkQe756fpn316BU4OJzVzezIuysKP05kTML0=.891f767c-c91f-4a56-9000-ba35ac226a8d@github.com>
Message-ID: <ENWwaToAcRI8EUtmBTg1b7R8Yv_9ytg6yqLg1SukjF4=.44c8d0ed-2a55-4f97-8e4d-1f76b41c1093@github.com>

On Fri, 21 Oct 2022 22:10:45 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   white space
>
> test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 49:
> 
>> 47:         // The resource bundle will not be found when the path is specified
>> 48:         testResourceBundleAccess(PATH_TO_BUNDLE, false);
>> 49:     }
> 
> It seems to me this could be reworked into a `DataProvider` for `testResourceBundleAccess()`.

Agreed, will make the change

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From duke at openjdk.org  Fri Oct 21 23:02:01 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 21 Oct 2022 23:02:01 GMT
Subject: Integrated: 8295239: Refactor java/util/Formatter/Basic script into a
 Java native test launcher
In-Reply-To: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
References: <wuFvnJs3euhGI5s2EcqVZNlXzbHzkKXn_YJu3FKuMcQ=.fa99d709-a28e-4909-8ef8-ab35d591296a@github.com>
Message-ID: <sc6EDb3g0FIYkYiCUKOCEEfEsyS-kwz4KvkNNffMVvI=.d788e5ad-ce30-4c9a-b53c-4dfb5d423c18@github.com>

On Fri, 14 Oct 2022 20:38:32 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Formatter unit tests are launched via basic.sh
> 
> Fix: Replace basic.sh with a Java test launcher
> 
> Note: Java.internal.math was included in the original configuration of Basic, but I removed it as it was not used within the Basic unit tests 
> 
> 
> Original output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936541-bc90db50-8d03-47be-9c4f-95176b19a6a7.png" width="350" height="350">
> 
> 
> New output on success
> <img src="https://user-images.githubusercontent.com/67398801/195936558-f85f4d48-dae2-4c38-aa50-46ef47db3d89.png" width="350" height="450">

This pull request has now been integrated.

Changeset: 902162ca
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/902162ca9f0fc589b888e73862275554691697f4
Stats:     185 lines in 3 files changed: 106 ins; 63 del; 16 mod

8295239: Refactor java/util/Formatter/Basic script into a Java native test launcher

Reviewed-by: lancea, bchristi, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/10715

From alanb at openjdk.org  Sat Oct 22 06:55:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Oct 2022 06:55:56 GMT
Subject: RFR: 8295792: Clean up old async close code
In-Reply-To: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
References: <5-CnyJPjJxGM6oDpCDRSxfxmFsrmy8o5LefMsCy7KWc=.bb5043ed-518d-47bc-87c1-9e9d0a9bc564@github.com>
Message-ID: <_oAfJnKqgI3kxl6OH8JRAucyEsrCKSdmbeVnbhe0miQ=.c143333b-409e-4e53-87f5-f8c363a740ee@github.com>

On Fri, 21 Oct 2022 14:28:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes the remains of old fdTable-based socket close synchronization.
> 
> Verified that tier1-3 tests continue to pass on Linux, MacOS and Windows. Did not verify AIX.
> 
> Also removed one slow test for an issue in fdtable implementation; as far as I could tell, it is no longer relevant.

Good cleanup. At some point I think we should put error handling into NET_Wait but not here.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10816

From alanb at openjdk.org  Sat Oct 22 08:17:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Oct 2022 08:17:34 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
 <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
Message-ID: <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>

On Fri, 21 Oct 2022 19:46:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.

Indeed and periodically CLDR upgrades do cause breakage somewhere, often it will be a library or application tests that compare some result that is outdated due to changes that impact the formatting.

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Sat Oct 22 17:05:05 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 22 Oct 2022 17:05:05 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v3]
In-Reply-To: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
Message-ID: <LN3RG6Pj4KcNvsecifb9vjJ-bszvyNxjH9S-5z1u0as=.b564814e-1e2e-4938-b48e-6a1662cdeab1@github.com>

> This PR implements JDK-8294696.

Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Alternative B: Cleanup old buffer to allow GC, then set new same-size buffer to handle buffer poisoning
 - Checking explicitly -1 instead of < 0
 - draining buffer instead of falling back to super.transferTo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10525/files
  - new: https://git.openjdk.org/jdk/pull/10525/files/26d4f53f..edd9da50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=01-02

  Stats: 54995 lines in 1573 files changed: 35683 ins; 12140 del; 7172 mod
  Patch: https://git.openjdk.org/jdk/pull/10525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10525/head:pull/10525

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Sat Oct 22 17:10:20 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 22 Oct 2022 17:10:20 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
Message-ID: <nUqi5VCnGUiz_uz9A7fQ3gL6Q-zED0D2ezsF60qCvNw=.8109e7f2-e204-48c4-a95d-e979e91276ba@github.com>

On Wed, 19 Oct 2022 08:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Checking explicitly -1 instead of < 0
>
>> * Alternative B: Instead of double-buffering I drop the original buffer and use a same-size replacement each time the buffer was drained inside of `transferTo`. This is a rather cheap solution and rather perfectly prevents OOME, as I drop _first_ before reallocating.
> 
> That is a good idea to try. It wouldn't work when BIS is extended but transferTo already checks this.
> 
> Note that you will need to zero the elements from 0 to pos, and count to buf.length, but I think you know that.

@AlanBateman I have implemented Alternative B as proposed with one single change: I do not zero-out anything as in our particular case (count == pos and markpos == -1) it is cheaper to simply set count and pos both to 0 (fill() did the same trick already). Due to that any subsequent read() invocation will in turn fill(), which in turn writes valid bytes into the new buffer. So this solution should safe us from possible OOME *and* poisoned buffers. WDYT?

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Sat Oct 22 17:59:48 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Sat, 22 Oct 2022 17:59:48 GMT
Subject: RFR: 8284840: Update CLDR to Version 42.0
In-Reply-To: <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
 <mFFAfK2xvTNWv4yeXZOOQCreE9XK57JO0V6yktINOP0=.3a6cc963-94b9-4f8d-8d6b-fb945bef0c0a@github.com>
 <FBXs_pNgtpx4EJw32V5_ZKKvG3lFimSlzFNjYCFtGjw=.cebdc098-ab36-44e4-be6d-65a45c314ca1@github.com>
 <vc7i1nf5msiFXtg0UqmvoEe0naETrkY5nIwBwZAwqwI=.1d728264-425d-4873-a69f-b0648c5eb47c@github.com>
Message-ID: <3h39a2Y21Xh4WUIRBcmMXobOLrhe98C49Enk7kgsNeQ=.7a052b5b-f434-44cf-ae96-729a2993597a@github.com>

On Sat, 22 Oct 2022 08:14:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Yes. These translation changes affect formatting. We don't usually file a CSR for such changes, but cover them in our release notes.
> 
> Indeed and periodically CLDR upgrades do cause breakage somewhere, often it will be a library or application tests that compare some result that is outdated due to changes that impact the formatting.

Yes, although libraries and tests shouldn't be testing against cultural formatting whose goal is to produce the updated best result, not the same result.  For example we had an internal corporate client which needed to use fixed formatting, instead of culturally sensitive formatting, because they really wanted exactly the same output every time, because the output data was going to be consumed by machine and not just by humans.

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From alanb at openjdk.org  Sun Oct 23 06:24:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 23 Oct 2022 06:24:40 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
Message-ID: <2D00jTeITBJHTxS6bpYqVAD0md2fSu2TlCfNXAVBLqQ=.7e395c48-eed4-4c52-8d2c-d273e9c8384f@github.com>

On Wed, 19 Oct 2022 08:31:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Checking explicitly -1 instead of < 0
>
>> * Alternative B: Instead of double-buffering I drop the original buffer and use a same-size replacement each time the buffer was drained inside of `transferTo`. This is a rather cheap solution and rather perfectly prevents OOME, as I drop _first_ before reallocating.
> 
> That is a good idea to try. It wouldn't work when BIS is extended but transferTo already checks this.
> 
> Note that you will need to zero the elements from 0 to pos, and count to buf.length, but I think you know that.

> @AlanBateman I have implemented Alternative B as proposed with one single change: I do not zero-out anything as in our particular case (count == pos and markpos == -1) it is cheaper to simply set count and pos both to 0 (fill() did the same trick already). Due to that any subsequent read() invocation will in turn fill(), which in turn writes valid bytes into the new buffer. So this solution should safe us from possible OOME _and_ poisoned buffers. WDYT?

It helps a bit but it still leaks the bytes in 0 to pos, and count buf.length. I think we have to assume that Dr. Evil's output stream will throw an exception so the code to replace the buffer won't run. This means replaces buf before handing out the original buffer. The transferTo method transfers all bytes to EOF so you may be able to get away with just allocating a 0 or tiny buffer, it can grow if needed with subsequent reads or transfers.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Sun Oct 23 08:45:13 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 23 Oct 2022 08:45:13 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v4]
In-Reply-To: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
Message-ID: <3YSeuXXHOZAsWCunD0_MM_UVC89WjrVbVSUwaYxU9_k=.3e81b7e7-a2b7-41ee-8df2-c6267a210384@github.com>

> This PR implements JDK-8294696.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Prevent leaking and poisoning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10525/files
  - new: https://git.openjdk.org/jdk/pull/10525/files/edd9da50..7350a533

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=02-03

  Stats: 16 lines in 1 file changed: 12 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10525/head:pull/10525

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Sun Oct 23 08:46:46 2022
From: duke at openjdk.org (Markus KARG)
Date: Sun, 23 Oct 2022 08:46:46 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <2D00jTeITBJHTxS6bpYqVAD0md2fSu2TlCfNXAVBLqQ=.7e395c48-eed4-4c52-8d2c-d273e9c8384f@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
 <2D00jTeITBJHTxS6bpYqVAD0md2fSu2TlCfNXAVBLqQ=.7e395c48-eed4-4c52-8d2c-d273e9c8384f@github.com>
Message-ID: <4mP7fZpQH-G3crTV1mAn_HhQC3fxrdHAWmsJAacwrQg=.6050f895-98fa-4cfe-af42-4c5ec6ee473b@github.com>

On Sun, 23 Oct 2022 06:21:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It helps a bit but it still leaks the bytes in 0 to pos, and count buf.length. I think we have to assume that Dr. Evil's output stream will throw an exception so the code to replace the buffer won't run. This means replaces buf before handing out the original buffer. The transferTo method transfers all bytes to EOF so you may be able to get away with just allocating a 0 or tiny buffer, it can grow if needed with subsequent reads or transfers.

Silly me, you are certainly right! I have modified the code as you proposed, so now we should be safe, finally. :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From prr at openjdk.org  Mon Oct 24 03:55:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:55:56 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From aturbanov at openjdk.org  Mon Oct 24 07:25:35 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 24 Oct 2022 07:25:35 GMT
Subject: RFR: 8295823: Use enhanced-for cycle instead of Enumeration in
 java.naming
Message-ID: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>

`java.util.Enumeration` is a legacy interface from java 1.0.
There are couple of cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

-------------

Commit messages:
 - [PATCH] Use enhanced-for cycle instead of Enumeration in java.naming

Changes: https://git.openjdk.org/jdk/pull/10804/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295823
  Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10804.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10804/head:pull/10804

PR: https://git.openjdk.org/jdk/pull/10804

From aefimov at openjdk.org  Mon Oct 24 11:32:55 2022
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 24 Oct 2022 11:32:55 GMT
Subject: RFR: 8295823: Use enhanced-for cycle instead of Enumeration in
 java.naming
In-Reply-To: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
References: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
Message-ID: <U6Hu42LF2Efnqt3o7-1zWuJEGN1gXo0x6eMsaJDSjZY=.e33fee94-8136-42d0-9597-d3469f768384@github.com>

On Thu, 20 Oct 2022 20:28:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `java.util.Enumeration` is a legacy interface from java 1.0.
> There are couple of cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

Hi Andrey,

The changes look reasonable to me.
The JNDI tests (JCK/regression) are also happy with it.

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.org/jdk/pull/10804

From dfuchs at openjdk.org  Mon Oct 24 11:48:58 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Oct 2022 11:48:58 GMT
Subject: RFR: 8295823: Use enhanced-for cycle instead of Enumeration in
 java.naming
In-Reply-To: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
References: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
Message-ID: <NaieYiMWT0wREsk7C-x1yMZGv9d0SynW8agu67BL9iQ=.c4d568ce-08f8-4b0b-b0e5-899bfd656e78@github.com>

On Thu, 20 Oct 2022 20:28:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `java.util.Enumeration` is a legacy interface from java 1.0.
> There are couple of cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10804

From naoto at openjdk.org  Mon Oct 24 15:52:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 15:52:38 GMT
Subject: Integrated: 8284840: Update CLDR to Version 42.0
In-Reply-To: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
References: <ankbpA7pQAXAB6YXkJN6TZp6xaVK1Zg_a4zh4xkXxb8=.79472190-df2f-44a1-beba-bfc03c6ffb54@github.com>
Message-ID: <8rhViPJXiQ9dJKOsX7pQaNU4YbABVGT0vUFbU38vI3o=.a26bd3d6-51d7-4960-bdf0-aaffef5ff474@github.com>

On Fri, 21 Oct 2022 16:55:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to update the CLDR data from version 41 to version 42. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments to those upstream changes:
> 
> https://unicode-org.atlassian.net/browse/CLDR-14032 (" at " is no longer used for standard date/time format)
> https://unicode-org.atlassian.net/browse/CLDR-14831 (NBSP prefixed to `a`, instead of a normal space )
> https://unicode-org.atlassian.net/browse/CLDR-11510 (Fix first day of week info for China (CN))
> https://unicode-org.atlassian.net/browse/CLDR-15966 (Japanese: Support numbers up to 9999?)
> 
> Here is the link to CLDR v42's release notes: https://cldr.unicode.org/index/downloads/cldr-42

This pull request has now been integrated.

Changeset: 5b3de6e1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b3de6e143e370272c36383adac3e31f359bc686
Stats:     99164 lines in 377 files changed: 68223 ins; 2820 del; 28121 mod

8284840: Update CLDR to Version 42.0

Reviewed-by: erikj, iris, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10820

From duke at openjdk.org  Mon Oct 24 16:37:56 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 24 Oct 2022 16:37:56 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v12]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use data provider for getBundle test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/8f0b6ac6..0f503392

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=10-11

  Stats: 25 lines in 1 file changed: 16 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From bchristi at openjdk.org  Mon Oct 24 17:57:02 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 24 Oct 2022 17:57:02 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v12]
In-Reply-To: <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>
Message-ID: <WeFmjjTMXomjabpHlU7h-KMBiYQVNQ5jJShLCcH11Qg=.0c60d938-bbcf-46fd-81d5-c6d2480719bf@github.com>

On Mon, 24 Oct 2022 16:37:56 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use data provider for getBundle test

Changes requested by bchristi (Reviewer).

test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 81:

> 79:                 Arguments.of(PATH_TO_BUNDLE, false)
> 80:         );
> 81:     }

I think the literals can be used in `bundleProvider` - no need to define constants.
Also, `@DataProvider`s are typically located towards the beginning of the file.

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From lancea at openjdk.org  Mon Oct 24 18:32:44 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 24 Oct 2022 18:32:44 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v12]
In-Reply-To: <WeFmjjTMXomjabpHlU7h-KMBiYQVNQ5jJShLCcH11Qg=.0c60d938-bbcf-46fd-81d5-c6d2480719bf@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>
 <WeFmjjTMXomjabpHlU7h-KMBiYQVNQ5jJShLCcH11Qg=.0c60d938-bbcf-46fd-81d5-c6d2480719bf@github.com>
Message-ID: <bPx7unQfwi4PWmdbeuwqEvU59KCSPdw5UOS5GM905jU=.92badbbb-d1c4-48ca-b652-0a72754fa91d@github.com>

On Mon, 24 Oct 2022 17:54:20 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use data provider for getBundle test
>
> test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java line 81:
> 
>> 79:                 Arguments.of(PATH_TO_BUNDLE, false)
>> 80:         );
>> 81:     }
> 
> I think the literals can be used in `bundleProvider` - no need to define constants.
> Also, `@DataProvider`s are typically located towards the beginning of the file.

I am fine with the constants as I find it easier to see/modify/document than within the DataProvider.

This is really a style choice so your milage may vary :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From lancea at openjdk.org  Mon Oct 24 18:36:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 24 Oct 2022 18:36:32 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v12]
In-Reply-To: <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>
Message-ID: <j5tqe7CjRKE6PRiDaYXH-bcet_4NSmKLYn3Z-6W6OBo=.4df229d8-4f54-48a7-a803-fbaba830b5cb@github.com>

On Mon, 24 Oct 2022 16:37:56 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use data provider for getBundle test

Hi Justin,

I think you are in good shape regardless of what you decide/prefer to do with the DataProvider with or without constants.

thank you for your efforts here

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10612

From naoto at openjdk.org  Mon Oct 24 18:44:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 18:44:48 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v12]
In-Reply-To: <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <UGWkDx_35VLuxjSw_DLZ5CDfmXCoFrqNsmIAz74SteA=.1f314742-56f0-40ba-bcb5-63c5b2909c16@github.com>
Message-ID: <C_cfip0PlVIOQJMENwEswaE-pNOcp5GT2Mf2Q5YdvzY=.c8b47030-3892-4bef-a0fc-aa706ba45686@github.com>

On Mon, 24 Oct 2022 16:37:56 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use data provider for getBundle test

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From naoto at openjdk.org  Mon Oct 24 19:09:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 19:09:44 GMT
Subject: RFR: 8284842: Update Unicode Data Files to Version 15.0.0
Message-ID: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>

Updates the JDK to use the latest Unicode 15, which also updates the ICU4J along with it (8284844: Update ICU4J to Version 72.1). The corresponding CSR has already been approved.

-------------

Commit messages:
 - 8284842: Update Unicode Data Files to Version 15.0.0

Changes: https://git.openjdk.org/jdk/pull/10839/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284842
  Stats: 1125 lines in 29 files changed: 821 ins; 33 del; 271 mod
  Patch: https://git.openjdk.org/jdk/pull/10839.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10839/head:pull/10839

PR: https://git.openjdk.org/jdk/pull/10839

From ihse at openjdk.org  Mon Oct 24 19:21:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:21:07 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v3]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Remove check for .properties from jcheck"
   
   This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
 - Change trailing space and tab in values to unicode encoding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10792&range=01-02

  Stats: 412 lines in 131 files changed: 0 ins; 0 del; 412 mod
  Patch: https://git.openjdk.org/jdk/pull/10792.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10792/head:pull/10792

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:22:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:22:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:25:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:25:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <yZpwsDUeKIrGQT3tvyGfGHFjIOuQTOBfRyvV7b-uArA=.077497ab-51b8-4346-b67d-9838e3419964@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.)

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:31:26 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
Message-ID: <HmB2uBGv-fQnz3Kn7yEA0yIR4akDfM4tmso3sgA4-aQ=.d84de722-5d04-4aad-8ba3-572eea3cacc1@github.com>

On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove check for .properties from jcheck
>>  - Restore trailing whitespace for property values
>
> 368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

@andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2

This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial.

The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21

This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:

> 185: ### Button Demo ###
> 186: 
> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020

trailing whitespace looks unnecessary (accessible description?)

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner
> 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta
> 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier
> 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella
> 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC
> 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp
> 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1}
> 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1}
> 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0}\u0020
> 127: crswriter.params2 = Value of params2 : {0}\u0020
> 128: crswriter.conflictsno =  conflicts while synchronizing\u0020

this is tricky.  if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong.  it's hard to tell without looking further into the code.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73:

> 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe
> 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen
> 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020

prob. unnecessary

-------------

Marked as reviewed by angorya (no project role).

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 19:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons:

1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems.

2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed.

And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs.


src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties
test/jdk/javax/net/ssl/Stapling/TEST.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties
test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From jjg at openjdk.org  Mon Oct 24 19:45:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
Message-ID: <cuJYgquzi3I4fULUZZz_G_ZjmEd_wDsUPw2mzCceM_w=.ad366bc4-db7f-48ad-9d3f-a8d0ba9e1820@github.com>

On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed.

probably not needed - if nobody noticed anything until now we have no problem.  the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues.

good job!

(and we can ignore my "prob. unnecessary" comments)

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 19:45:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <cRpIep8vLpUKvRQH3e_vwTIqVChg5uSLhFH4sSCbmOQ=.9c8e6492-c665-4666-bba9-4947cd6059b1@github.com>

On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:
> 
>> 185: ### Button Demo ###
>> 186: 
>> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020
> 
> trailing whitespace looks unnecessary (accessible description?)

although this is in demo...

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Mon Oct 24 20:02:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:02:54 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Mon Oct 24 20:12:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 20:12:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
Message-ID: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>

On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

Good idea! I wonder if this should be done as a unit test.  go through all the bundles and check leading/trailing whitespace.

in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code.  I assume the JDK has been exhaustively tested and we have no such problems.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Mon Oct 24 20:16:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:16:56 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
 <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
Message-ID: <go6bwGp8ro_LeVwOJyBes4PXwMBEGNyPvq43vxGmmLU=.ed6bfa15-4664-41ab-87a9-51609382b9cf@github.com>

On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace.

Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Mon Oct 24 20:39:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:39:57 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
Message-ID: <HMdFi0RZ9_Jhobfq_DLpJY4wycMf6qXcIHo90U8sq80=.4a035bff-b633-400b-bbf4-c3e7111385f3@github.com>

On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning).

Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs.

And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address.

> Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Mon Oct 24 21:19:21 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 24 Oct 2022 21:19:21 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v13]
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <0oSkfkMR-njmF1I2c9ri0UqHfy-LPq6lnsjHjGSs3BU=.61de982a-2235-4a92-9637-ff2bdc8e3be2@github.com>

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Move provider to top

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10612/files
  - new: https://git.openjdk.org/jdk/pull/10612/files/0f503392..da3aeacd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10612&range=11-12

  Stats: 19 lines in 1 file changed: 5 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10612.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10612/head:pull/10612

PR: https://git.openjdk.org/jdk/pull/10612

From iklam at openjdk.org  Mon Oct 24 22:29:33 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 24 Oct 2022 22:29:33 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
Message-ID: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>

I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.

For example:


public class StrConcat {
    static String hello = "Hello";
    static String world = "World";
    public static void main(String args[]) {
        System.out.println(hello + world);
        System.out.println(hello + "World");
    }
}

$ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
======== CallSite: StrConcat.main(StrConcat.java:5)
BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
target class = java.lang.invoke.BoundMethodHandle$Species_L
target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
    t3:L=Species_L.argL0(a0:L);
    t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
& BMH=[
  0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
        t3:L=DirectMethodHandle.internalMemberName(a0:L);
        t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
    & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
  }
]
HelloWorld
======== CallSite: StrConcat.main(StrConcat.java:6)
BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
target class = java.lang.invoke.BoundMethodHandle$Species_LL
target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
    t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
    t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
    t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
& BMH=[
  0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
        t3:L=DirectMethodHandle.internalMemberName(a0:L);
        t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
    & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
  }
  1: ( World )
]
HelloWorld


More complex examples are in the JBS bug report
- https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
- https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
- https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
- https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt

-------------

Commit messages:
 - also print the BSM
 - cleaned up code; added comments; avoid using indy inside TRACE_CALLSITE; avoid interleaving output
 - 8295537: Debug tracing for resolved dynamic call sites

Changes: https://git.openjdk.org/jdk/pull/10842/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10842&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295537
  Stats: 127 lines in 6 files changed: 114 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/10842.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10842/head:pull/10842

PR: https://git.openjdk.org/jdk/pull/10842

From bchristi at openjdk.org  Tue Oct 25 00:28:56 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 25 Oct 2022 00:28:56 GMT
Subject: RFR: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java [v13]
In-Reply-To: <0oSkfkMR-njmF1I2c9ri0UqHfy-LPq6lnsjHjGSs3BU=.61de982a-2235-4a92-9637-ff2bdc8e3be2@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
 <0oSkfkMR-njmF1I2c9ri0UqHfy-LPq6lnsjHjGSs3BU=.61de982a-2235-4a92-9637-ff2bdc8e3be2@github.com>
Message-ID: <IYbpM88msgwJHZuLISdcdRHepX1N2wdSwFiYDu77lIo=.6317cbef-9a02-4411-b1a8-9ede21c0f258@github.com>

On Mon, 24 Oct 2022 21:19:21 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
>> 
>> Fix: Modified bundle name to be a fully qualified class and added regression tests.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move provider to top

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From cjplummer at openjdk.org  Tue Oct 25 03:16:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Oct 2022 03:16:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <qb_ryMLGem495x0rBbOxd4vVGYPmnRiOkynx6AmvZVE=.5c5d3ee8-8498-4d6d-bfec-04a075ab085c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Changes requested by cjplummer (Reviewer).

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From vtewari at openjdk.org  Tue Oct 25 03:41:49 2022
From: vtewari at openjdk.org (Vyom Tewari)
Date: Tue, 25 Oct 2022 03:41:49 GMT
Subject: RFR: 8295823: Use enhanced-for cycle instead of Enumeration in
 java.naming
In-Reply-To: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
References: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
Message-ID: <Xsix_RDqmM7kyuK6EajQK6MXrGHnzpoXzNPBq2oFUXI=.94410495-5694-4785-a756-3779face2023@github.com>

On Thu, 20 Oct 2022 20:28:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `java.util.Enumeration` is a legacy interface from java 1.0.
> There are couple of cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

Looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.org/jdk/pull/10804

From duke at openjdk.org  Tue Oct 25 06:27:52 2022
From: duke at openjdk.org (duke)
Date: Tue, 25 Oct 2022 06:27:52 GMT
Subject: Withdrawn: 8293017: Improve hash calculation parallelism in jmod/jlink
In-Reply-To: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
References: <a_Jvg34HyAL-kvoXOkg3mDiIS8Drhhtj_aGfweY12V0=.922d3de1-9713-4e49-9d35-8c65db9b756b@github.com>
Message-ID: <mOU0RdE13Yw8GtFRFD35z00cmO1EIFPvTXyt6kYJA0M=.2e1cbee9-2ba8-4fed-af29-e2ce8e163fe8@github.com>

On Mon, 29 Aug 2022 08:55:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `jmod`/`jlink` are executed during build time to produce the `jmod` and the base modules image. On slow hardware (Raspberry Pi -class, for example) and/or slow VMs (debug, interpreter-only, for example) this takes a while. Profiling shows the considerable time is spent on hashing modules either for writing out the ModuleHash attribute or for verifying the hashes are good.
> 
> Those paths can be parallelized to make them quite faster.
> 
> The major contributors to module hashing are `java.base`, `jdk.desktop` and `jdk.localedata`, so we have a significant opportunity for parallelism here. 
> 
> Motivational improvements on `make clean-images images`:
> 
> 
> # x86_64 Server, release
> 
> # Baseline
> real	0m11.895s
> user	1m4.526s
> sys	0m10.715s
> 
> # Patched
> real	0m10.701s   ; <--- 1.1x improvement
> user	1m5.097s
> sys	0m11.260s
> 
> # x86_64 Zero, release
> 
> # Baseline
> real	5m20.335s
> user	7m7.791s
> sys	0m7.258s
> 
> # Patched
> real	2m23.551s  ; <--- 2.23x improvement
> user	7m14.442s
> sys	0m7.856s
> 
> 
> Additional testing: 
>   - [x] Linux x86_64 fastdebug, `java/util/jar`
>   - [x] Linux x86_64 fastdebug, `tools/jmod`
>   - [x] Linux x86_64 fastdebug, `tools/jlink`
>   - [x] Linux x86_64 fastdebug `tier1`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10060

From jvernee at openjdk.org  Tue Oct 25 13:26:57 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Oct 2022 13:26:57 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
In-Reply-To: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
Message-ID: <AwGML7wbMEIjaeK_xd1ktpT0VxAZ-3m8w7lmn9mIt_Y=.ceb2f90d-e324-4cfd-beb3-d270b2886f26@github.com>

On Mon, 24 Oct 2022 22:15:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
> 
> For example:
> 
> 
> public class StrConcat {
>     static String hello = "Hello";
>     static String world = "World";
>     public static void main(String args[]) {
>         System.out.println(hello + world);
>         System.out.println(hello + "World");
>     }
> }
> 
> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
> ======== CallSite: StrConcat.main(StrConcat.java:5)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_L
> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>     t3:L=Species_L.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
> ]
> HelloWorld
> ======== CallSite: StrConcat.main(StrConcat.java:6)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_LL
> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
>   1: ( World )
> ]
> HelloWorld
> 
> 
> More complex examples are in the JBS bug report
> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt

src/java.base/share/classes/java/lang/invoke/CallSite.java line 179:

> 177:         target.type();  // null check
> 178:         this.target = target;
> 179:         if (MethodHandleStatics.TRACE_CALLSITE) {

This doesn't seem like the right place to put this. Anyone can indirectly extend CallSite, by extending e.g. MutableCallSite, but this code seems to assume that the call is going through `MethodHandleNatives.linkCallSite`? I suggest putting any tracing around that area. Both the target method handle, and the BSM seem to be available at that point in the code as well.

I also note that there's already a `TRACE_METHOD_LINKAGE` flag as well, which does some tracing of call site linking. Maybe that option could be enhanced instead of adding a new one?

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1814:

> 1812:             return "";
> 1813:         }
> 1814:         return new String(new char[indentLevel*4]).replace('\0', ' ');

I guess this could be:
Suggestion:

        return "    ".repeat(indentLevel);

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From jvernee at openjdk.org  Tue Oct 25 13:26:57 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Oct 2022 13:26:57 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
In-Reply-To: <AwGML7wbMEIjaeK_xd1ktpT0VxAZ-3m8w7lmn9mIt_Y=.ceb2f90d-e324-4cfd-beb3-d270b2886f26@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <AwGML7wbMEIjaeK_xd1ktpT0VxAZ-3m8w7lmn9mIt_Y=.ceb2f90d-e324-4cfd-beb3-d270b2886f26@github.com>
Message-ID: <XtOwqZaowuGgBUXjkTu021BR_Wc7nB791SeTOQrJ2b0=.d8b893c8-0daf-4183-8f4e-e83a7127f34b@github.com>

On Tue, 25 Oct 2022 12:50:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
>> 
>> For example:
>> 
>> 
>> public class StrConcat {
>>     static String hello = "Hello";
>>     static String world = "World";
>>     public static void main(String args[]) {
>>         System.out.println(hello + world);
>>         System.out.println(hello + "World");
>>     }
>> }
>> 
>> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
>> ======== CallSite: StrConcat.main(StrConcat.java:5)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_L
>> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>>     t3:L=Species_L.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>> ]
>> HelloWorld
>> ======== CallSite: StrConcat.main(StrConcat.java:6)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_LL
>> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>>   1: ( World )
>> ]
>> HelloWorld
>> 
>> 
>> More complex examples are in the JBS bug report
>> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
>> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
>> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
>> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt
>
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1814:
> 
>> 1812:             return "";
>> 1813:         }
>> 1814:         return new String(new char[indentLevel*4]).replace('\0', ' ');
> 
> I guess this could be:
> Suggestion:
> 
>         return "    ".repeat(indentLevel);

Alternatively, I was gonna suggest not having a prefix/indentLevel and instead calling `String::indent` at the use site. But, that method uses streams/lambdas, so there might be boostrap cycle issues.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From weijun at openjdk.org  Tue Oct 25 13:30:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:30:53 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <c28cQxkcVp8YCkAe0wDP4b7cUvb424JsH9ls5bR3m48=.31cad672-bef6-4d55-983d-2cb32a0cafea@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

I'm quite sure this space can be safely removed.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From weijun at openjdk.org  Tue Oct 25 13:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:47:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

I suggest we focus on the English files this time and file a bug to the translation tool.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From james.laskey at oracle.com  Tue Oct 25 16:41:05 2022
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 25 Oct 2022 16:41:05 +0000
Subject: RFR -  Implementation of JEP-430 String Templates (Preview) CSR
Message-ID: <6E63DC57-0518-45DE-8BEB-0800BDC635C6@oracle.com>

Request for a broader review of the String Template APIs for JEP 430.

Summary:

Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a preview language feature and API.

CSR: https://bugs.openjdk.org/browse/JDK-8286021
JEP: https://openjdk.org/jeps/430


Thank you.

? Jim


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221025/40c4b50f/attachment.htm>

From naoto at openjdk.org  Tue Oct 25 17:31:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Oct 2022 17:31:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
Message-ID: <CWhtHdVfwiBt9m16ZvVgfFbu-h9bRwVLYmwORiLTSVA=.210b4cf3-7f67-4f32-9983-b9fe54bd1571@github.com>

On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

Good catch, Max. Yes, that should be dealt with in the translation process.

> I suggest we focus on the English files this time and file a bug to the translation tool.

Agree.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From iklam at openjdk.org  Tue Oct 25 17:34:15 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 25 Oct 2022 17:34:15 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
Message-ID: <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>

> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
> 
> For example:
> 
> 
> public class StrConcat {
>     static String hello = "Hello";
>     static String world = "World";
>     public static void main(String args[]) {
>         System.out.println(hello + world);
>         System.out.println(hello + "World");
>     }
> }
> 
> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
> ======== CallSite: StrConcat.main(StrConcat.java:5)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_L
> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>     t3:L=Species_L.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
> ]
> HelloWorld
> ======== CallSite: StrConcat.main(StrConcat.java:6)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_LL
> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
>   1: ( World )
> ]
> HelloWorld
> 
> 
> More complex examples are in the JBS bug report
> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @JornVernee comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10842/files
  - new: https://git.openjdk.org/jdk/pull/10842/files/b09baf43..94d7a900

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10842&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10842&range=00-01

  Stats: 106 lines in 4 files changed: 29 ins; 73 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10842.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10842/head:pull/10842

PR: https://git.openjdk.org/jdk/pull/10842

From iklam at openjdk.org  Tue Oct 25 17:40:48 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 25 Oct 2022 17:40:48 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <AwGML7wbMEIjaeK_xd1ktpT0VxAZ-3m8w7lmn9mIt_Y=.ceb2f90d-e324-4cfd-beb3-d270b2886f26@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <AwGML7wbMEIjaeK_xd1ktpT0VxAZ-3m8w7lmn9mIt_Y=.ceb2f90d-e324-4cfd-beb3-d270b2886f26@github.com>
Message-ID: <N6zWiSmEt4ZleR--8dxOnkKes84IXBNgZQVVKyCQRYg=.a8de1643-9aa5-426d-8ca8-363811ced9b1@github.com>

On Tue, 25 Oct 2022 13:16:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @JornVernee comments
>
> src/java.base/share/classes/java/lang/invoke/CallSite.java line 179:
> 
>> 177:         target.type();  // null check
>> 178:         this.target = target;
>> 179:         if (MethodHandleStatics.TRACE_CALLSITE) {
> 
> This doesn't seem like the right place to put this. Anyone can indirectly extend CallSite, by extending e.g. MutableCallSite, but this code seems to assume that the call is going through `MethodHandleNatives.linkCallSite`? I suggest putting any tracing around that area. Both the target method handle, and the BSM are available at that point in the code as well.
> 
> I also note that there's already a `TRACE_METHOD_LINKAGE` flag as well, which does some tracing of call site linking. Maybe that option could be enhanced instead of adding a new one?

Thanks for the suggestion! I removed the new property and just piggyback on `TRACE_METHOD_LINKAGE`. I also moved the tracing code into `MethodHandleNatives.linkCallSiteXXX`, and improved the existing code a bit to print out the line number of the call site.

Here's what it looks like now:


$ java -Djava.lang.invoke.MethodHandle.TRACE_METHOD_LINKAGE=true -cp . StrConcat
[...]
linkCallSite StrConcat.main(StrConcat.java:6) java.lang.invoke.StringConcatFactory.makeConcatWithConstants(Lookup,String,MethodType,String,Object[])CallSite/invokeStatic makeConcatWithConstants(String)String/BSA1=World
linkCallSite target class => java.lang.invoke.BoundMethodHandle$Species_LL
linkCallSite target => (String)String : invoke001_LL_L=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
    t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
    t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
    t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
& BMH=[
  0: MethodHandle = {(Object,Object)String : DMH.invokeStatic000_LLL_L=Lambda(a0:L,a1:L,a2:L)=>{
        t3:L=DirectMethodHandle.internalMemberName(a0:L);
        t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
    & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
  }
  1: ( World )
]
linkCallSite linkage => java.lang.invoke.Invokers$Holder.linkToTargetMethod(Object,Object)Object/invokeStatic + MethodHandle(String)String
HelloWorld

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From jvernee at openjdk.org  Tue Oct 25 19:13:53 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Oct 2022 19:13:53 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
Message-ID: <E7mXJfvbnsjiBDX-UIKFP1v3W_Nbnp-KMZ3OU5AZMYI=.58b498e5-971c-432f-ac18-5c5314f66b69@github.com>

On Tue, 25 Oct 2022 17:34:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
>> 
>> For example:
>> 
>> 
>> public class StrConcat {
>>     static String hello = "Hello";
>>     static String world = "World";
>>     public static void main(String args[]) {
>>         System.out.println(hello + world);
>>         System.out.println(hello + "World");
>>     }
>> }
>> 
>> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
>> ======== CallSite: StrConcat.main(StrConcat.java:5)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_L
>> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>>     t3:L=Species_L.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>> ]
>> HelloWorld
>> ======== CallSite: StrConcat.main(StrConcat.java:6)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_LL
>> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>>   1: ( World )
>> ]
>> HelloWorld
>> 
>> 
>> More complex examples are in the JBS bug report
>> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
>> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
>> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
>> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @JornVernee comments

The changes look good, but I have some more comments.

src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 329:

> 327:                 return null;
> 328:             }
> 329:         });

Not sure about this condition. It seems like `callerInfo[0] == callerName` will always be true at first, and then it gets overwritten by the stack trace element toString, so in effect it only picks up the first non-MethodHandleNatives caller? I think it could be clearer to use `filter` + `findFirst` to get the caller's `StackFrame` (that has the additional benefit of short-circuiting), and then convert to a String from there.

Also, please move the code that gets the caller info out-of-line to a helper method, since it's quite wordy.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From jvernee at openjdk.org  Tue Oct 25 19:13:54 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Oct 2022 19:13:54 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <E7mXJfvbnsjiBDX-UIKFP1v3W_Nbnp-KMZ3OU5AZMYI=.58b498e5-971c-432f-ac18-5c5314f66b69@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
 <E7mXJfvbnsjiBDX-UIKFP1v3W_Nbnp-KMZ3OU5AZMYI=.58b498e5-971c-432f-ac18-5c5314f66b69@github.com>
Message-ID: <VmB4n-4TC8aBD_7NLQwXPJfXvZkMCNUzSKcHKQ5ysH8=.060a82ad-b4c2-4327-9664-b59d6cf29537@github.com>

On Tue, 25 Oct 2022 18:54:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @JornVernee comments
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 329:
> 
>> 327:                 return null;
>> 328:             }
>> 329:         });
> 
> Not sure about this condition. It seems like `callerInfo[0] == callerName` will always be true at first, and then it gets overwritten by the stack trace element toString, so in effect it only picks up the first non-MethodHandleNatives caller? I think it could be clearer to use `filter` + `findFirst` to get the caller's `StackFrame` (that has the additional benefit of short-circuiting), and then convert to a String from there.
> 
> Also, please move the code that gets the caller info out-of-line to a helper method, since it's quite wordy.

Alternatively, maybe you could just dump the whole stack trace here (e.g. with Thread.dumpStack()), since it might be useful to see which code path triggers resolution of a call site as well. That would also include the line number of the caller.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From duke at openjdk.org  Tue Oct 25 19:26:00 2022
From: duke at openjdk.org (Justin Lu)
Date: Tue, 25 Oct 2022 19:26:00 GMT
Subject: Integrated: 8294989: ResourceBundle naming convention issue in
 JdbcRowSetResourceBundle.java
In-Reply-To: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
References: <8oLdxviX7SG1se4QuZIl6X6sWAQ_byRzc-yIvcTXF8o=.5913e04f-1cbb-4ad1-bf74-a1e4f2f41ed4@github.com>
Message-ID: <tD4OaTsOc8Myv4ha6q839TK3wArv7rAq8C-jsOgm448=.8ff6fd99-f294-4533-addf-1902300c31df@github.com>

On Fri, 7 Oct 2022 18:24:02 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Resource bundle name does not follow proper naming conventions according to [getBundle method](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)) for base name parameter
> 
> Fix: Modified bundle name to be a fully qualified class and added regression tests.

This pull request has now been integrated.

Changeset: d393e051
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d393e051e660d05b645a2d148c6cdfc21b1d347e
Stats:     150 lines in 3 files changed: 149 ins; 0 del; 1 mod

8294989: ResourceBundle naming convention issue in JdbcRowSetResourceBundle.java

Reviewed-by: naoto, lancea, bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/10612

From iklam at openjdk.org  Tue Oct 25 19:40:45 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 25 Oct 2022 19:40:45 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <VmB4n-4TC8aBD_7NLQwXPJfXvZkMCNUzSKcHKQ5ysH8=.060a82ad-b4c2-4327-9664-b59d6cf29537@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
 <E7mXJfvbnsjiBDX-UIKFP1v3W_Nbnp-KMZ3OU5AZMYI=.58b498e5-971c-432f-ac18-5c5314f66b69@github.com>
 <VmB4n-4TC8aBD_7NLQwXPJfXvZkMCNUzSKcHKQ5ysH8=.060a82ad-b4c2-4327-9664-b59d6cf29537@github.com>
Message-ID: <l5wYzMlNtwQJs7wGvPT5QlUlfXpFPIRoLU1-sFQev90=.8a348d9b-03ff-4c60-8980-abf478cf597a@github.com>

On Tue, 25 Oct 2022 18:54:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 329:
>> 
>>> 327:                 return null;
>>> 328:             }
>>> 329:         });
>> 
>> Not sure about this condition. It seems like `callerInfo[0] == callerName` will always be true at first, and then it gets overwritten by the stack trace element toString, so in effect it only picks up the first non-MethodHandleNatives caller? I think it could be clearer to use `filter` + `findFirst` to get the caller's `StackFrame` (that has the additional benefit of short-circuiting), and then convert to a String from there.
>> 
>> Also, please move the code that gets the caller info out-of-line to a helper method, since it's quite wordy.
>
> Alternatively, maybe you could just dump the whole stack trace here (e.g. with Thread.dumpStack()), since it might be useful to see which code path triggers resolution of a call site as well. That would also include the line number of the caller.

Is it possible to use filter/findfirst without using lambdas? I want to avoid recursion inside the tracing code.

I am not sure about dumping the call stack. It seems an overkill and not useful in most cases. It?s easier to rebuild the JDK and add Thread.dumpStack() in the rare occasion that you need to do this.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From mchung at openjdk.org  Tue Oct 25 19:46:15 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 25 Oct 2022 19:46:15 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
Message-ID: <6YERD6tFMJ6YAF7zA7DmOz00Fvu2i5o8Xm22HPiTyYI=.f4acf871-c4a0-4427-93b0-4e0ef192fa09@github.com>

On Tue, 25 Oct 2022 17:34:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
>> 
>> For example:
>> 
>> 
>> public class StrConcat {
>>     static String hello = "Hello";
>>     static String world = "World";
>>     public static void main(String args[]) {
>>         System.out.println(hello + world);
>>         System.out.println(hello + "World");
>>     }
>> }
>> 
>> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
>> ======== CallSite: StrConcat.main(StrConcat.java:5)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_L
>> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>>     t3:L=Species_L.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>> ]
>> HelloWorld
>> ======== CallSite: StrConcat.main(StrConcat.java:6)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_LL
>> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>>   1: ( World )
>> ]
>> HelloWorld
>> 
>> 
>> More complex examples are in the JBS bug report
>> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
>> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
>> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
>> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @JornVernee comments

src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 312:

> 310:         String callerName = caller.getName();
> 311:         String[] callerInfo = new String[] {callerName};
> 312:         StackWalker.getInstance().walk(new Function<Stream<StackWalker.StackFrame>, Object>() {

You can call `StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE)` to retain `Class` instance in `StackFrame` such that you can compare `Class` instance rather than class name.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From jvernee at openjdk.org  Tue Oct 25 19:46:15 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Oct 2022 19:46:15 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <l5wYzMlNtwQJs7wGvPT5QlUlfXpFPIRoLU1-sFQev90=.8a348d9b-03ff-4c60-8980-abf478cf597a@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
 <E7mXJfvbnsjiBDX-UIKFP1v3W_Nbnp-KMZ3OU5AZMYI=.58b498e5-971c-432f-ac18-5c5314f66b69@github.com>
 <VmB4n-4TC8aBD_7NLQwXPJfXvZkMCNUzSKcHKQ5ysH8=.060a82ad-b4c2-4327-9664-b59d6cf29537@github.com>
 <l5wYzMlNtwQJs7wGvPT5QlUlfXpFPIRoLU1-sFQev90=.8a348d9b-03ff-4c60-8980-abf478cf597a@github.com>
Message-ID: <j_UIeEBMNvwIRlmlgiLRxc4O-eqOXOz4vPfcfU6vwx4=.c6b27644-c9e7-474f-aefc-ff083a1eed98@github.com>

On Tue, 25 Oct 2022 19:37:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Is it possible to use filter/findfirst without using lambdas? I want to avoid recursion inside the tracing code.

You could do this I believe (if I've eye-balled that correctly :)):
Suggestion:

        String callerName = caller.getName();
        String callerInfo = StackWalker.getInstance().walk(new Function<Stream<StackWalker.StackFrame>, String>() {
            // We use inner classes (instead of stream/lambda) to avoid triggering
            // further invokedynamic resolution, which would cause infinite recursion.
            // It's OK to use + for string concat, because java.base is compiled without
            // the use of indy string concat.
            @Override
            public String apply(Stream<StackWalker.StackFrame> s) {
                return s.filter(new Predicate<StackWalker.StackFrame>() {
                    @Override
                    public boolean test(StackWalker.StackFrame f) {
                        return callerName.equals(f.getClassName());
                    }
                }).findFirst().get().toStackTraceElement().toString();
            }
        });


> I am not sure about dumping the call stack. It seems an overkill and not useful in most cases. It?s easier to rebuild the JDK and add Thread.dumpStack() in the rare occasion that you need to do this.

Fair enough.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From jvernee at openjdk.org  Tue Oct 25 19:49:28 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 25 Oct 2022 19:49:28 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <j_UIeEBMNvwIRlmlgiLRxc4O-eqOXOz4vPfcfU6vwx4=.c6b27644-c9e7-474f-aefc-ff083a1eed98@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
 <E7mXJfvbnsjiBDX-UIKFP1v3W_Nbnp-KMZ3OU5AZMYI=.58b498e5-971c-432f-ac18-5c5314f66b69@github.com>
 <VmB4n-4TC8aBD_7NLQwXPJfXvZkMCNUzSKcHKQ5ysH8=.060a82ad-b4c2-4327-9664-b59d6cf29537@github.com>
 <l5wYzMlNtwQJs7wGvPT5QlUlfXpFPIRoLU1-sFQev90=.8a348d9b-03ff-4c60-8980-abf478cf597a@github.com>
 <j_UIeEBMNvwIRlmlgiLRxc4O-eqOXOz4vPfcfU6vwx4=.c6b27644-c9e7-474f-aefc-ff083a1eed98@github.com>
Message-ID: <55gpzKdAdgNUJm6b2Z0UpEIYpeRVPN_ladt4xyePKUs=.3480d2d4-6779-4f24-8b63-bf40b9bd24bb@github.com>

On Tue, 25 Oct 2022 19:43:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Is it possible to use filter/findfirst without using lambdas? I want to avoid recursion inside the tracing code.
>> 
>> I am not sure about dumping the call stack. It seems an overkill and not useful in most cases. It?s easier to rebuild the JDK and add Thread.dumpStack() in the rare occasion that you need to do this.
>
>> Is it possible to use filter/findfirst without using lambdas? I want to avoid recursion inside the tracing code.
> 
> You could do this I believe (if I've eye-balled that correctly :)):
> Suggestion:
> 
>         String callerName = caller.getName();
>         String callerInfo = StackWalker.getInstance().walk(new Function<Stream<StackWalker.StackFrame>, String>() {
>             // We use inner classes (instead of stream/lambda) to avoid triggering
>             // further invokedynamic resolution, which would cause infinite recursion.
>             // It's OK to use + for string concat, because java.base is compiled without
>             // the use of indy string concat.
>             @Override
>             public String apply(Stream<StackWalker.StackFrame> s) {
>                 return s.filter(new Predicate<StackWalker.StackFrame>() {
>                     @Override
>                     public boolean test(StackWalker.StackFrame f) {
>                         return callerName.equals(f.getClassName());
>                     }
>                 }).findFirst().get().toStackTraceElement().toString();
>             }
>         });
> 
> 
>> I am not sure about dumping the call stack. It seems an overkill and not useful in most cases. It?s easier to rebuild the JDK and add Thread.dumpStack() in the rare occasion that you need to do this.
> 
> Fair enough.

Or, maybe it's easier to use `Thread.currentThread().getStackTrace()` and avoid messing around with streams altogether.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From bhuang at openjdk.org  Tue Oct 25 23:16:54 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 25 Oct 2022 23:16:54 GMT
Subject: RFR: JDK-8295859: Update Manual Test Groups
Message-ID: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>

This task is created to add manual tests to the manual test groups.

In addition, fix is provided for TestMatrix.java#Downcall-F and TestMatrix.java#Downcall-T which are failing due to missing TestDowncall.java ([JDK-8287158](https://bugs.openjdk.org/browse/JDK-8287158)).

-------------

Commit messages:
 - Updated Manual Test Groups

Changes: https://git.openjdk.org/jdk/pull/10864/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10864&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295859
  Stats: 42 lines in 2 files changed: 35 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10864.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10864/head:pull/10864

PR: https://git.openjdk.org/jdk/pull/10864

From iklam at openjdk.org  Wed Oct 26 05:18:45 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 26 Oct 2022 05:18:45 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v3]
In-Reply-To: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
Message-ID: <87SDsz2XWVqe_lUlvGOA2lHCiwVKPicjVfapkP2pobA=.036c54e4-c575-4731-86ce-df1ca35dbe3b@github.com>

> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
> 
> For example:
> 
> 
> public class StrConcat {
>     static String hello = "Hello";
>     static String world = "World";
>     public static void main(String args[]) {
>         System.out.println(hello + world);
>         System.out.println(hello + "World");
>     }
> }
> 
> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
> ======== CallSite: StrConcat.main(StrConcat.java:5)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_L
> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>     t3:L=Species_L.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
> ]
> HelloWorld
> ======== CallSite: StrConcat.main(StrConcat.java:6)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_LL
> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
>   1: ( World )
> ]
> HelloWorld
> 
> 
> More complex examples are in the JBS bug report
> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Use Thread::getStackTrace() to find the caller's line number, etc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10842/files
  - new: https://git.openjdk.org/jdk/pull/10842/files/94d7a900..c26cbd7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10842&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10842&range=01-02

  Stats: 38 lines in 1 file changed: 14 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10842.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10842/head:pull/10842

PR: https://git.openjdk.org/jdk/pull/10842

From iklam at openjdk.org  Wed Oct 26 05:18:46 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 26 Oct 2022 05:18:46 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <55gpzKdAdgNUJm6b2Z0UpEIYpeRVPN_ladt4xyePKUs=.3480d2d4-6779-4f24-8b63-bf40b9bd24bb@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
 <E7mXJfvbnsjiBDX-UIKFP1v3W_Nbnp-KMZ3OU5AZMYI=.58b498e5-971c-432f-ac18-5c5314f66b69@github.com>
 <VmB4n-4TC8aBD_7NLQwXPJfXvZkMCNUzSKcHKQ5ysH8=.060a82ad-b4c2-4327-9664-b59d6cf29537@github.com>
 <l5wYzMlNtwQJs7wGvPT5QlUlfXpFPIRoLU1-sFQev90=.8a348d9b-03ff-4c60-8980-abf478cf597a@github.com>
 <j_UIeEBMNvwIRlmlgiLRxc4O-eqOXOz4vPfcfU6vwx4=.c6b27644-c9e7-474f-aefc-ff083a1eed98@github.com>
 <55gpzKdAdgNUJm6b2Z0UpEIYpeRVPN_ladt4xyePKUs=.3480d2d4-6779-4f24-8b63-bf40b9bd24bb@github.com>
Message-ID: <IANocgH4Pp_3E1VQfI5fDaeHWypYi9f3Xm3XN5yZqVc=.edda14dc-7a88-4988-9c03-366a8f407813@github.com>

On Tue, 25 Oct 2022 19:46:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> Is it possible to use filter/findfirst without using lambdas? I want to avoid recursion inside the tracing code.
>> 
>> You could do this I believe (if I've eye-balled that correctly :)):
>> Suggestion:
>> 
>>         String callerName = caller.getName();
>>         String callerInfo = StackWalker.getInstance().walk(new Function<Stream<StackWalker.StackFrame>, String>() {
>>             // We use inner classes (instead of stream/lambda) to avoid triggering
>>             // further invokedynamic resolution, which would cause infinite recursion.
>>             // It's OK to use + for string concat, because java.base is compiled without
>>             // the use of indy string concat.
>>             @Override
>>             public String apply(Stream<StackWalker.StackFrame> s) {
>>                 return s.filter(new Predicate<StackWalker.StackFrame>() {
>>                     @Override
>>                     public boolean test(StackWalker.StackFrame f) {
>>                         return callerName.equals(f.getClassName());
>>                     }
>>                 }).findFirst().get().toStackTraceElement().toString();
>>             }
>>         });
>> 
>> 
>>> I am not sure about dumping the call stack. It seems an overkill and not useful in most cases. It?s easier to rebuild the JDK and add Thread.dumpStack() in the rare occasion that you need to do this.
>> 
>> Fair enough.
>
> Or, maybe it's easier to use `Thread.currentThread().getStackTrace()` and avoid messing around with streams altogether.

I ended up using `Thread.currentThread().getStackTrace()` and the code is much cleaner. Performance isn't important anyway. `Stream.filter()` doesn't work because it uses a Lambda in `<clinit>`:


java.lang.NullPointerException: Cannot invoke "java.util.stream.TerminalOp.getOpFlags()" because "terminalOp" is null
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:647)
        at java.base/java.lang.invoke.MethodHandleNatives$1.apply(MethodHandleNatives.java:328)
        at java.base/java.lang.invoke.MethodHandleNatives$1.apply(MethodHandleNatives.java:315)
        at java.base/java.lang.StackStreamFactory$StackFrameTraverser.consumeFrames(StackStreamFactory.java:586)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(StackStreamFactory.java:324)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(Native Method)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(StackStreamFactory.java:410)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walkHelper(StackStreamFactory.java:261)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walk(StackStreamFactory.java:253)
        at java.base/java.lang.StackWalker.walk(StackWalker.java:589)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteTracing(MethodHandleNatives.java:315)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:275)
        at java.base/java.util.stream.FindOps$FindSink$OfRef.<clinit>(FindOps.java:198)
        at java.base/java.util.stream.FindOps.makeRef(FindOps.java:60)
        at java.base/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:647)
        at java.base/java.lang.invoke.MethodHandleNatives$1.apply(MethodHandleNatives.java:328)
        at java.base/java.lang.invoke.MethodHandleNatives$1.apply(MethodHandleNatives.java:315)
        at java.base/java.lang.StackStreamFactory$StackFrameTraverser.consumeFrames(StackStreamFactory.java:586)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(StackStreamFactory.java:324)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(Native Method)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(StackStreamFactory.java:410)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walkHelper(StackStreamFactory.java:261)
        at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walk(StackStreamFactory.java:253)
        at java.base/java.lang.StackWalker.walk(StackWalker.java:589)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteTracing(MethodHandleNatives.java:315)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:275)
        at java.base/jdk.internal.module.SystemModuleFinders$1.find(SystemModuleFinders.java:216)
        at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:260)
        at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:174)
        at java.base/java.lang.System.initPhase2(System.java:2214)

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From iklam at openjdk.org  Wed Oct 26 05:31:24 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 26 Oct 2022 05:31:24 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v2]
In-Reply-To: <6YERD6tFMJ6YAF7zA7DmOz00Fvu2i5o8Xm22HPiTyYI=.f4acf871-c4a0-4427-93b0-4e0ef192fa09@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <9Nr8Y_p3cBsZVxMu-MskhLcpIr3OdwqhDZ1Ay1waHeY=.e61e0534-d203-468f-b524-93d925be3cd0@github.com>
 <6YERD6tFMJ6YAF7zA7DmOz00Fvu2i5o8Xm22HPiTyYI=.f4acf871-c4a0-4427-93b0-4e0ef192fa09@github.com>
Message-ID: <ZCegsrXu_oxvPFeGDWQwWI0Tr5pnXXzNtfCRnq6_Yj8=.7ea0dfc7-8f82-4d5f-9463-2b1abff5cf0f@github.com>

On Tue, 25 Oct 2022 19:33:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @JornVernee comments
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 312:
> 
>> 310:         String callerName = caller.getName();
>> 311:         String[] callerInfo = new String[] {callerName};
>> 312:         StackWalker.getInstance().walk(new Function<Stream<StackWalker.StackFrame>, Object>() {
> 
> You can call `StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE)` to retain `Class` instance in `StackFrame` such that you can compare `Class` instance rather than class name.

The `StackWalker` API depends on Streams, which is likely to have lambdas in its implementation. To avoid the possibility of bootstrap problems, I have changed the code to use `Thread.currentThread().getStackTrace()`, which is used by `Throwable.printStackTrace()`. Since `printStackTrace()` is supposed to be useable at very early bootstrap stages, we are sure no lambdas will be used.

Unfortunately `getStackTrace()` doesn't return the `Class` object, so I have to use the class's name.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From dnsimon at openjdk.org  Wed Oct 26 07:43:33 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 26 Oct 2022 07:43:33 GMT
Subject: Withdrawn: 8294394: running jlink in GraalVM must copy libgraal into
 the output image
In-Reply-To: <S3wMCKeiTrZJKxEPgpO2wy35kIipmSYnHeXYMzIIm7Q=.081f00f8-6c29-43d6-a685-e3fd048dfd55@github.com>
References: <S3wMCKeiTrZJKxEPgpO2wy35kIipmSYnHeXYMzIIm7Q=.081f00f8-6c29-43d6-a685-e3fd048dfd55@github.com>
Message-ID: <fUuhf2UvseRplOZjWN5eMIZJQ-eo03gz9bfXaD5l53g=.2c093c64-0510-4e54-92c0-5e6a7d96e797@github.com>

On Tue, 27 Sep 2022 11:30:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR adds a new jlink plugin (`--copy-files=<filenames>`) that copies specified files from the current image into the output image.
> This is useful in the context of GraalVM where libgraal (e.g. `lib/libjvmcicompiler.so`) is produced after the final jlink step in the GraalVM JDK build process. The plugin makes it possible for jlink in a GraalVM JDK to propagate libgraal.
> 
> The advantages of this solution over packaging libgraal as a module are:
> * No need to complicate and slow down the GraalVM JDK build process with an extra jlink step.
> * No need to pay the footprint of libgraal twice in a GraalVM JDK (i.e., once in,`lib/libjvmcicompiler.so` and again in a jmod file).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10448

From alanb at openjdk.org  Wed Oct 26 08:20:21 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Oct 2022 08:20:21 GMT
Subject: RFR: JDK-8295859: Update Manual Test Groups
In-Reply-To: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
References: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
Message-ID: <kvKs7g5kup83SKcBEpD1J_MLhCIjlx3jki4_MnqtLXw=.931130fe-600f-486f-a2ec-098fd7e76cca@github.com>

On Tue, 25 Oct 2022 23:10:53 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task is created to add manual tests to the manual test groups.
> 
> In addition, fix is provided for TestMatrix.java#Downcall-F and TestMatrix.java#Downcall-T which are failing due to missing TestDowncall.java ([JDK-8287158](https://bugs.openjdk.org/browse/JDK-8287158)).

No objection to this but it seems a maintenance burden and I'm curious why these runs aren't run with the jtreg -manual option that will select the manual tests, e.g. `-listtests -manual open/test/jdk/:jdk_core` will list the tests in jdk_core that are configured to run /manual.

-------------

PR: https://git.openjdk.org/jdk/pull/10864

From forax at univ-mlv.fr  Wed Oct 26 09:25:58 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 26 Oct 2022 11:25:58 +0200 (CEST)
Subject: RFR -  Implementation of JEP-430 String Templates (Preview) CSR
In-Reply-To: <6E63DC57-0518-45DE-8BEB-0800BDC635C6@oracle.com>
References: <6E63DC57-0518-45DE-8BEB-0800BDC635C6@oracle.com>
Message-ID: <570660084.34318648.1666776358106.JavaMail.zimbra@u-pem.fr>

Each time i re-read this JEP, i'm more and more sorry about its state. 
- we are breaking how Strings worked, now everything in between "..." is not a String anymore. 
As an example, given a String s, only one of the following lines compiles 
System.out.println("s = \{s}".toUpperCase()); 
System.out.println("s = {\s}".toUpperCase()); 
- conceptually we have something like 
instance -> template -> arguments 

but instead of grouping it like this 
Class.apply(template).invoke(instance, arguments) 

the JEP groups them like this 
instance.apply(new TemplatedString(template, arguments)) 

which is far less efficient because both the class and the template are constants while the instance and the arguments are not. 

R?mi 

> From: "Jim Laskey" <james.laskey at oracle.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Tuesday, October 25, 2022 6:41:05 PM
> Subject: RFR - Implementation of JEP-430 String Templates (Preview) CSR

> Request for a broader review of the String Template APIs for JEP 430.

> Summary:

> Enhance the Java programming language with string templates, which are similar
> to string literals but contain embedded expressions. A string template is
> interpreted at run time by replacing each expression with the result of
> evaluating that expression, possibly after further validation and
> transformation. This is a preview language feature and API.

> CSR: [ https://bugs.openjdk.org/browse/JDK-8286021 |
> https://bugs.openjdk.org/browse/JDK-8286021 ]
> JEP: [ https://openjdk.org/jeps/430 | https://openjdk.org/jeps/430 ]

> Thank you.

> ? Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221026/432bc147/attachment-0001.htm>

From duke at openjdk.org  Wed Oct 26 12:03:38 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 26 Oct 2022 12:03:38 GMT
Subject: RFR: 8292937: Improve performance of some read operations of
 RandomAccessFile [v6]
In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com>
Message-ID: <qEndy3tzMQXHzZWHtE8haI9ne3uAyCmH3Ps4xEWcjGU=.e68455aa-7048-4c61-8239-a8357b9213b5@github.com>

> Currently some operations of RandomAccessFile are implemented with multiple read() invocations:
> 
> public final int readInt() throws IOException {
>     int ch1 = this.read();
>     int ch2 = this.read();
>     int ch3 = this.read();
>     int ch4 = this.read();
>     if ((ch1 | ch2 | ch3 | ch4) < 0)
>       throw new EOFException();
>     return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
> }
> 
> This can be improved by using bulk reads:
> 
> public final int readInt() throws IOException {
>   readFully(readBuffer, 0, 4);
>   return Bits.getInt(readBuffer, 0);
> }
> 
> Benchmarking:
> 
> baselile
> Benchmark                                (kiloBytes)  Mode  Cnt     Score      Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10  1060,526 ?   62,036  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  5745,671 ? 1374,277  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10  1399,494 ?  378,072  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10  4864,425 ?  329,282  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10  1111,163 ?   70,883  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  4933,058 ?  339,273  us/op
> 
> patch
> Benchmark                                (kiloBytes)  Mode  Cnt     Score    Error  Units
> RandomAccessFileReadBenchmark.readInt              1  avgt   10   311,404 ? 17,337  us/op
> RandomAccessFileReadBenchmark.readInt              5  avgt   10  1210,381 ? 22,742  us/op
> RandomAccessFileReadBenchmark.readLong             1  avgt   10   201,726 ?  8,885  us/op
> RandomAccessFileReadBenchmark.readLong             5  avgt   10   667,117 ?  6,779  us/op
> RandomAccessFileReadBenchmark.readShort            1  avgt   10   560,259 ? 16,783  us/op
> RandomAccessFileReadBenchmark.readShort            5  avgt   10  2251,975 ? 54,533  us/op

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8292937: Get back to Java solution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10031/files
  - new: https://git.openjdk.org/jdk/pull/10031/files/9a9a0b04..42f6e862

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10031&range=04-05

  Stats: 84 lines in 5 files changed: 9 ins; 62 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/10031.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10031/head:pull/10031

PR: https://git.openjdk.org/jdk/pull/10031

From jvernee at openjdk.org  Wed Oct 26 13:00:18 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Oct 2022 13:00:18 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v3]
In-Reply-To: <87SDsz2XWVqe_lUlvGOA2lHCiwVKPicjVfapkP2pobA=.036c54e4-c575-4731-86ce-df1ca35dbe3b@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <87SDsz2XWVqe_lUlvGOA2lHCiwVKPicjVfapkP2pobA=.036c54e4-c575-4731-86ce-df1ca35dbe3b@github.com>
Message-ID: <bXQruYMTVoIpw-1yauT6ckVZtX3mlV39SM98GsRJGQY=.224399e5-1e77-4dee-84f5-5c0336ccd602@github.com>

On Wed, 26 Oct 2022 05:18:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
>> 
>> For example:
>> 
>> 
>> public class StrConcat {
>>     static String hello = "Hello";
>>     static String world = "World";
>>     public static void main(String args[]) {
>>         System.out.println(hello + world);
>>         System.out.println(hello + "World");
>>     }
>> }
>> 
>> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
>> ======== CallSite: StrConcat.main(StrConcat.java:5)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_L
>> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>>     t3:L=Species_L.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>> ]
>> HelloWorld
>> ======== CallSite: StrConcat.main(StrConcat.java:6)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_LL
>> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>>   1: ( World )
>> ]
>> HelloWorld
>> 
>> 
>> More complex examples are in the JBS bug report
>> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
>> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
>> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
>> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Thread::getStackTrace() to find the caller's line number, etc

Very nice, Thanks!

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10842

From dfuchs at openjdk.org  Wed Oct 26 16:11:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 16:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
Message-ID: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>

Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.

The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 

This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.

In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.

In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.

Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.

The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

-------------

Commit messages:
 - Fix whitespace issues
 - 8294241

Changes: https://git.openjdk.org/jdk/pull/10874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294241
  Stats: 849 lines in 82 files changed: 701 ins; 2 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

PR: https://git.openjdk.org/jdk/pull/10874

From michaelm at openjdk.org  Wed Oct 26 16:45:22 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 26 Oct 2022 16:45:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/JarURLConnection.java line 177:

> 175:         @SuppressWarnings("deprecation")
> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
> 177: 

I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From weijun at openjdk.org  Wed Oct 26 16:48:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Oct 2022 16:48:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <6CBNoueQtp5P8wa0FuOCHQtmw9610BdOrP7pvhg1g70=.6cc91f26-df33-4722-9c49-f390ed6387aa@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

The change to security-related code looks fine to me.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From aturbanov at openjdk.org  Wed Oct 26 16:54:28 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 26 Oct 2022 16:54:28 GMT
Subject: Integrated: 8295823: Use enhanced-for cycle instead of Enumeration in
 java.naming
In-Reply-To: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
References: <0VOs8vFXj_SEEwknpAk-sHmAghal_qzzxbFDIPfeakU=.7f907f84-a87e-4623-9d8a-64ab3ce3a635@github.com>
Message-ID: <glQAv4PvUPHtD3wP50decc2VpXXtBo4JGoQllgVC-yk=.9c226ae9-b3e7-481e-859a-3aa927ef41af@github.com>

On Thu, 20 Oct 2022 20:28:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `java.util.Enumeration` is a legacy interface from java 1.0.
> There are couple of cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read.

This pull request has now been integrated.

Changeset: 46e6aee0
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46e6aee0d0b868c4c45b7c25cd3fd951d199b1ed
Stats:     5 lines in 2 files changed: 0 ins; 1 del; 4 mod

8295823: Use enhanced-for cycle instead of Enumeration in java.naming

Reviewed-by: aefimov, dfuchs, vtewari

-------------

PR: https://git.openjdk.org/jdk/pull/10804

From xuelei at openjdk.org  Wed Oct 26 17:11:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)

What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Wed Oct 26 17:29:01 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:29:01 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
Message-ID: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>

On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/URL.java line 852:
> 
>> 850:      * @since 20
>> 851:      */
>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
> 
> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

`URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From xuelei at openjdk.org  Wed Oct 26 17:42:31 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:42:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
Message-ID: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>

On Wed, 26 Oct 2022 17:24:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URL.java line 852:
>> 
>>> 850:      * @since 20
>>> 851:      */
>>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
>> 
>> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?
>
> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.

I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.

Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Wed Oct 26 17:57:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:57:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
Message-ID: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>

On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.
>
> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
> 
> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
> 
> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From bhuang at openjdk.org  Wed Oct 26 20:35:08 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 26 Oct 2022 20:35:08 GMT
Subject: RFR: JDK-8295859: Update Manual Test Groups
In-Reply-To: <kvKs7g5kup83SKcBEpD1J_MLhCIjlx3jki4_MnqtLXw=.931130fe-600f-486f-a2ec-098fd7e76cca@github.com>
References: <bUsd4joncS3tnsUtEw4mGU-vaE0SArUNLvO86VaxALo=.abfd97fc-ce01-45d7-bcca-b929c1232f13@github.com>
 <kvKs7g5kup83SKcBEpD1J_MLhCIjlx3jki4_MnqtLXw=.931130fe-600f-486f-a2ec-098fd7e76cca@github.com>
Message-ID: <VYsQmKhfU36iTNiWh_Vm3UJQmOPsiccKfF39rvy4iuU=.55302cbf-91d2-4211-98a7-c64db91d7c9f@github.com>

On Wed, 26 Oct 2022 08:16:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This task is created to add manual tests to the manual test groups.
>> 
>> In addition, fix is provided for TestMatrix.java#Downcall-F and TestMatrix.java#Downcall-T which are failing due to missing TestDowncall.java ([JDK-8287158](https://bugs.openjdk.org/browse/JDK-8287158)).
>
> No objection to this but it seems a maintenance burden and I'm curious why these runs aren't run with the jtreg -manual option that will select the manual tests, e.g. `-listtests -manual open/test/jdk/:jdk_core` will list the tests in jdk_core that are configured to run /manual.

Hi @AlanBateman, the manual group was created for ATR purposes because the manual tests are outsourced, it is easier to organize and analyze the results. Also, it is consolidated with manual tests in jdk_core, jdk_nio, jdk_foreign and other categories.

-------------

PR: https://git.openjdk.org/jdk/pull/10864

From duke at openjdk.org  Wed Oct 26 21:00:43 2022
From: duke at openjdk.org (Justin Lu)
Date: Wed, 26 Oct 2022 21:00:43 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup [v2]
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge master
 - Adjust template to reduce whitespace
 - Re-add modified BasicDateTime test contents removed by generated template
 - Adjust template to cleanup errors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10684/files
  - new: https://git.openjdk.org/jdk/pull/10684/files/026ca4c1..88ef21cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10684&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10684&range=00-01

  Stats: 170665 lines in 2048 files changed: 98332 ins; 37356 del; 34977 mod
  Patch: https://git.openjdk.org/jdk/pull/10684.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10684/head:pull/10684

PR: https://git.openjdk.org/jdk/pull/10684

From mik3hall at gmail.com  Wed Oct 26 21:31:04 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Oct 2022 16:31:04 -0500
Subject: Jpackage OS/X DMG install Application folder alias name incorrectly
 shows as path with /
Message-ID: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>

At jpackage 19, I filed a bug on this but don?t have a number yet.

I did do a little looking at the DMGSetup.scpt AppleScript on my own. 

I was thinking this?

	-- Create alias for install location
	make new alias file at POSIX file "DEPLOY_VOLUME_PATH" to POSIX file "DEPLOY_INSTALL_LOCATION" with properties {name:"DEPLOY_INSTALL_LOCATION?}

Could be replaced with simply?

	-- Create alias for install location
	make new alias file at POSIX file DEPLOY_VOLUME_URL to POSIX file DEPLOY_INSTALL_LOCATION with properties {name:?Applications?}

Assuming the folder is always ?Applications?. Then it occurred to me you might be doing some localization for this folder name. 

I then found this which could possibly be used?

	-- Create alias for install location
	set DEPLOY_APPLICATION_NAME to displayed name of (path to applications folder) -- i18n name
	make new alias file at POSIX file DEPLOY_VOLUME_URL to POSIX file DEPLOY_INSTALL_LOCATION with properties {name:DEPLOY_APPLICATION_NAME}

Which appeared to provide the localization?

Determining the folder name in the AppleScript could eliminate some of the other parameterization in use. If it isn?t possible you might have to add a new parameter for the folder name without the leading / or parse it out in the script somehow.

Possibly localization, if the AppleScript does support it, could be an option the developer may or may not want. 





From bchristi at openjdk.org  Wed Oct 26 21:57:29 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 26 Oct 2022 21:57:29 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup [v2]
In-Reply-To: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
Message-ID: <RAqv1g1uMXNlqJSTOq9zZb3W-Ea98ioM9xowZFIWO_M=.ccf28b42-5e87-4e06-bdb8-2afa6ccbecc5@github.com>

On Wed, 26 Oct 2022 21:00:43 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge master
>  - Adjust template to reduce whitespace
>  - Re-add modified BasicDateTime test contents removed by generated template
>  - Adjust template to cleanup errors

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From redestad at openjdk.org  Wed Oct 26 21:59:31 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 26 Oct 2022 21:59:31 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v3]
In-Reply-To: <87SDsz2XWVqe_lUlvGOA2lHCiwVKPicjVfapkP2pobA=.036c54e4-c575-4731-86ce-df1ca35dbe3b@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <87SDsz2XWVqe_lUlvGOA2lHCiwVKPicjVfapkP2pobA=.036c54e4-c575-4731-86ce-df1ca35dbe3b@github.com>
Message-ID: <zB52__HTl2TzYOCgToYrL5-JqMY18XFSX7pJwe_AEuk=.915abe9b-d80c-4682-a535-3330a29b57d4@github.com>

On Wed, 26 Oct 2022 05:18:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
>> 
>> For example:
>> 
>> 
>> public class StrConcat {
>>     static String hello = "Hello";
>>     static String world = "World";
>>     public static void main(String args[]) {
>>         System.out.println(hello + world);
>>         System.out.println(hello + "World");
>>     }
>> }
>> 
>> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
>> ======== CallSite: StrConcat.main(StrConcat.java:5)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_L
>> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>>     t3:L=Species_L.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>> ]
>> HelloWorld
>> ======== CallSite: StrConcat.main(StrConcat.java:6)
>> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
>> target class = java.lang.invoke.BoundMethodHandle$Species_LL
>> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>>   1: ( World )
>> ]
>> HelloWorld
>> 
>> 
>> More complex examples are in the JBS bug report
>> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
>> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
>> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
>> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Thread::getStackTrace() to find the caller's line number, etc

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From naoto at openjdk.org  Wed Oct 26 22:53:41 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Oct 2022 22:53:41 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup [v2]
In-Reply-To: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
Message-ID: <7jIGMsIS71nsvInjYUbGu8O-3N72pDRJvMcocvaTtNU=.7aaaacc8-b715-45d4-908d-2ae4a1fd347c@github.com>

On Wed, 26 Oct 2022 21:00:43 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge master
>  - Adjust template to reduce whitespace
>  - Re-add modified BasicDateTime test contents removed by generated template
>  - Adjust template to cleanup errors

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From peter.firmstone at zeus.net.au  Wed Oct 26 22:53:52 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 08:53:52 +1000
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
Message-ID: <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>

Interesting.? Is this RFR a done deal?

While I like the concept and and understand the reasoning of URL not 
having a public constructor, I think this may have been thought of in 
isolation, I'm not sure how a custom URI, that strictly complies with 
RFC 3986 will behave, if it must also be parsed by java.net.URI, which 
is loosely compliant with RFC 2396 and RFC 2732.? Has anyone done any 
investigation?? We stopped using java.net.URI some years ago as it's 
obsolete.? The change will have some performance impact, by requiring 
redundant parsing.

Just thought I'd mention it, in case it hasn't been thought of. If you 
do an internet search there are other implementations of RFC3986 in java 
also.

https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966

We have a strict URI 3986 implementation, which we use to create all URL 
instances from.

This is how we avoid unnecessarily incurring accesses to file systems 
and DNS, this implementation had a massive performance and scalability 
improvement for us.

/**
 ?* This class represents an immutable instance of a URI as defined by 
RFC 3986.
 ?* <p>
 ?* This class replaces java.net.URI functionality.
 ?* <p>
 ?* Unlike java.net.URI this class is not Serializable and hashCode and
 ?* equality is governed by strict RFC3986 normalisation. In addition 
"other"
 ?* characters allowed in java.net.URI as specified by javadoc, not 
specifically
 ?* allowed by RFC3986 are illegal and must be escaped.? This strict 
adherence
 ?* is essential to eliminate false negative or positive matches.
 ?* <p>
 ?* In addition to RFC3896 normalisation, on OS platforms with a \ file 
separator
 ?* the path is converted to UPPER CASE for comparison for file: schema, 
during
 ?* equals and hashCode calls.
 ?* <p>
 ?* IPv6 and IPvFuture host addresses must be enclosed in square 
brackets as per
 ?* RFC3986.? A zone delimiter %, if present, must be represented in 
escaped %25
 ?* form.
 ?* <p>
 ?* In addition to RFC3896 normalization, IPv6 host addresses will be 
normalized
 ?* to comply with RFC 5952 A Recommendation for IPv6 Address Text 
Representation.
 ?* This is to ensure consistent equality between identical IPv6 addresses.
 ?*
 ?* @since 3.0.0
 ?*/


Regards,
Peter.

On 27/10/2022 3:57 am, Daniel Fuchs wrote:
> On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:
>
>>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.
>> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
>>
>> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
>>
>> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.
> One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/10874


From mik3hall at gmail.com  Thu Oct 27 00:55:44 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Oct 2022 19:55:44 -0500
Subject: Jpackage OS/X DMG install Application folder alias name
 incorrectly shows as path with /
In-Reply-To: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
Message-ID: <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>



> On Oct 26, 2022, at 4:31 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> At jpackage 19, I filed a bug on this but don?t have a number yet.

I seem to remember this as a regression it happened before. Strange since every occurrence of DMGSetup.scpt I can find looks like it handles the Application folder alias the same way.

I think maybe Andy Herrick came up with some sort of fix?  I may not be remembering that right.

I was looking at the script for how it handles additional files added to the dmg. This was I think an enhancement request of mine and it works fine but I think it could maybe look a bit better.
I was looking to see what any other dmg?s I have do to handle this. Not many do. But those usually seem to use a smaller background image and icons. 
I may look at that to see if I can manage something like that.

In doing that I noticed that a couple of the JavaFX SceneBuilder dmg?s I have show the same /Application. So they demonstrate it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221026/e81936db/attachment.htm>

From duke at openjdk.org  Thu Oct 27 05:16:38 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 05:16:38 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
Message-ID: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>

On Wed, 26 Oct 2022 16:41:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
> 
>> 175:         @SuppressWarnings("deprecation")
>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>> 177: 
> 
> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

Having?unnamed local?variables[^1] would?probably be?best for?this.

[^1]: https://openjdk.org/jeps/8294349

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From iklam at openjdk.org  Thu Oct 27 05:24:33 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Oct 2022 05:24:33 GMT
Subject: RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite
 [v4]
In-Reply-To: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
Message-ID: <hFeR8jAT6SxA8LKlqKlLV9UImlR0AXWZ2sY8_-kjop4=.f1cd69a6-aae0-4054-87f6-27201a2a5630@github.com>

> I've added a `java.lang.invoke.MethodHandle.TRACE_CALLSITE` property to show how invokedynamic call sites are resolved.
> 
> For example:
> 
> 
> public class StrConcat {
>     static String hello = "Hello";
>     static String world = "World";
>     public static void main(String args[]) {
>         System.out.println(hello + world);
>         System.out.println(hello + "World");
>     }
> }
> 
> $ java -Djava.lang.invoke.MethodHandle.TRACE_CALLSITE=true -cp . StrConcat
> ======== CallSite: StrConcat.main(StrConcat.java:5)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_L
> target = (String,String)String : BMH.reinvoke=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>     t3:L=Species_L.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
> ]
> HelloWorld
> ======== CallSite: StrConcat.main(StrConcat.java:6)
> BSM = java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:354)
> target class = java.lang.invoke.BoundMethodHandle$Species_LL
> target = (String)String : invoke=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
>   1: ( World )
> ]
> HelloWorld
> 
> 
> More complex examples are in the JBS bug report
> - https://bugs.openjdk.org/secure/attachment/101170/eclipse-ide-log.txt
> - https://bugs.openjdk.org/secure/attachment/101168/lambda-expression.txt
> - https://bugs.openjdk.org/secure/attachment/101174/pattern-matching-switch.txt
> - https://bugs.openjdk.org/secure/attachment/101169/str-concat.txt

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into 8295537-trace-jli-dynamic-call-sites
 - Use Thread::getStackTrace() to find the caller's line number, etc
 - @JornVernee comments
 - also print the BSM
 - cleaned up code; added comments; avoid using indy inside TRACE_CALLSITE; avoid interleaving output
 - 8295537: Debug tracing for resolved dynamic call sites

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10842/files
  - new: https://git.openjdk.org/jdk/pull/10842/files/c26cbd7c..5d2ac5a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10842&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10842&range=02-03

  Stats: 154080 lines in 1740 files changed: 87176 ins; 33940 del; 32964 mod
  Patch: https://git.openjdk.org/jdk/pull/10842.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10842/head:pull/10842

PR: https://git.openjdk.org/jdk/pull/10842

From Alan.Bateman at oracle.com  Thu Oct 27 06:26:46 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Oct 2022 07:26:46 +0100
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
Message-ID: <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>

On 26/10/2022 23:53, Peter Firmstone wrote:
> The change will have some performance impact, by requiring redundant 
> parsing.
>
> Just thought I'd mention it, in case it hasn't been thought of. If you 
> do an internet search there are other implementations of RFC3986 in 
> java also.
>
> https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966 
>
>
> We have a strict URI 3986 implementation, which we use to create all 
> URL instances from.

If your parser is using the one-arg URL constructor to create the URL 
then it will be parsed again, so you may already have duplicate 
parsing.? That said, there may be an argument that libraries should be 
able to do their own parsing and continue to construct a URL from its 
components with the non-validating constructors.

As I'm sure you know, changing URI to strictly implement RFC 3986 is not 
a compatible move. It was attempted in JDK 6 but had to backed out 
quickly as it caused widespread breakage. Hierarchical URIs using 
registry based authority components was one of significant issues. There 
has been exploration and prototypes since then to try to find a 
direction but there isn't a proposal right now.

-Alan

From peter.firmstone at zeus.net.au  Thu Oct 27 08:54:47 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 18:54:47 +1000
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
 <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
Message-ID: <2cedb39c-462e-5913-6f4c-c1149f72f468@zeus.net.au>


On 27/10/2022 4:26 pm, Alan Bateman wrote:
> On 26/10/2022 23:53, Peter Firmstone wrote:
>> The change will have some performance impact, by requiring redundant 
>> parsing.
>>
>> Just thought I'd mention it, in case it hasn't been thought of. If 
>> you do an internet search there are other implementations of RFC3986 
>> in java also.
>>
>> https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L1966 
>>
>>
>> We have a strict URI 3986 implementation, which we use to create all 
>> URL instances from.
>
> If your parser is using the one-arg URL constructor to create the URL 
> then it will be parsed again, so you may already have duplicate 
> parsing.? That said, there may be an argument that libraries should be 
> able to do their own parsing and continue to construct a URL from its 
> components with the non-validating constructors.

You are right, it was over 10 years ago when I originally wrote it, I'm 
a little rusty on the reason why I chose the single argument 
constructor, it's possible I would do it differently if implementing it 
today.? I might have been worried about what might break at the time.? 
We did have a developer in a downstream project who used a URN and a 
custom URLHandler, made possible by the change to RFC3986.

I think today we could safely change it to a non parsing constructor.

>
> As I'm sure you know, changing URI to strictly implement RFC 3986 is 
> not a compatible move. It was attempted in JDK 6 but had to backed out 
> quickly as it caused widespread breakage. Hierarchical URIs using 
> registry based authority components was one of significant issues. 
> There has been exploration and prototypes since then to try to find a 
> direction but there isn't a proposal right now.

The performance cost of retaining compatibility was a problem as we had 
to rely on DNS and file system access to determine equality as 
java.net.URI wasn't suitable, we wanted a normalized form, with 
guaranteed equality without network or file system access, so we decided 
to break compatibility, as the tradeoff was significantly in 
performance's favour.

It's used throughout our software, there's a URI3986ClassLoader, which 
extends SecureClassLoader, it's also used in unicast discovery of 
services (over network) and it's also used for Policy decisions...

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/RFC3986URLClassLoader.java

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/discovery/LookupLocator.java

In Policy to replace CodeSource#implies functionality:

https://github.com/pfirmstone/JGDMS/blob/e4a5012e71fd9a61b6e1e505f07e6c5358a4ccbc/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/URIGrant.java#L132

Historically our software was horribly impacted by URL#equals and 
URL#hashCode and we went to a great deal of trouble to eliminate all 
such calls and replace them with Uri.?? Which is why Uri is immutable, 
normalized and not Serializable.

We utilised bitshift operations for case conversion, after String 
methods became hotspots.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/URIEncoderDecoder.java

I suspect the best solution might be to leave java.net.URI alone and 
write a new implementation that isn't compatible, then eventually 
deprecate and remove java.net.URI.?? Tip: Don't make it Serializable, 
let people Serialize the string form instead.

Regards,

Peter.


From michaelm at openjdk.org  Thu Oct 27 09:21:35 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 27 Oct 2022 09:21:35 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
Message-ID: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>

On Thu, 27 Oct 2022 05:14:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
>> 
>>> 175:         @SuppressWarnings("deprecation")
>>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>>> 177: 
>> 
>> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?
>
> Having?unnamed local?variables[^1] would?probably be?best for?this.
> 
> [^1]: https://openjdk.org/jeps/8294349

How about `_unused` or `_unused1`, `_unused2` then in the meantime?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Thu Oct 27 11:28:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 11:28:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
Message-ID: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>

On Thu, 27 Oct 2022 09:17:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Having?unnamed local?variables[^1] would?probably be?best for?this.
>> 
>> [^1]: https://openjdk.org/jeps/8294349
>
> How about `_unused` or `_unused1`, `_unused2` then in the meantime?

I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From daniel.fuchs at oracle.com  Thu Oct 27 11:29:45 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 27 Oct 2022 12:29:45 +0100
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
 <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
Message-ID: <a341387b-e932-02fe-be32-b5ceaaaeb6c7@oracle.com>

On 27/10/2022 07:26, Alan Bateman wrote:
>> We have a strict URI 3986 implementation, which we use to create all 
>> URL instances from.

Note also that though this change proposes to deprecate these
constructors in order to provide a stronger warning against their
potential misuse, it does not deprecate them for removal.

If you are confident in your parsing/validation you can of course
still provide a `URL toURL(org.apache.river.api.net.URI)` method that
calls a constructor, and annotate that one place with 
`@SuppressWarnings("deprecation")`.

best regards,

-- dabniel


From peter.firmstone at zeus.net.au  Thu Oct 27 11:48:34 2022
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 27 Oct 2022 21:48:34 +1000
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <a341387b-e932-02fe-be32-b5ceaaaeb6c7@oracle.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
 <521dafd5-5e43-6f0d-dae2-5e4daa0fd55d@zeus.net.au>
 <77f8e08f-3571-ba86-af27-93d4cdfd3196@oracle.com>
 <a341387b-e932-02fe-be32-b5ceaaaeb6c7@oracle.com>
Message-ID: <0448a3f6-2dbb-f809-ba1f-2503999dbb18@zeus.net.au>

I'm considering using one of the non parsing constructors, as Alan 
points out we're currently double parsing.? By the time the constructor 
is removed, I'm guessing there will be a RFC3986 URI implementation in 
the JDK, so we'll change to that when it happens.?? Or if you decide to 
not deprecate one of the non parsing constructors, I'm good with that also.

Regards,

Peter.

On 27/10/2022 9:29 pm, Daniel Fuchs wrote:
> On 27/10/2022 07:26, Alan Bateman wrote:
>>> We have a strict URI 3986 implementation, which we use to create all 
>>> URL instances from.
>
> Note also that though this change proposes to deprecate these
> constructors in order to provide a stronger warning against their
> potential misuse, it does not deprecate them for removal.
>
> If you are confident in your parsing/validation you can of course
> still provide a `URL toURL(org.apache.river.api.net.URI)` method that
> calls a constructor, and annotate that one place with 
> `@SuppressWarnings("deprecation")`.
>
> best regards,
>
> -- dabniel
>

From turbanoff at gmail.com  Thu Oct 27 11:53:07 2022
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Thu, 27 Oct 2022 14:53:07 +0300
Subject: Unused class java.net.InetAddressContainer
Message-ID: <CAF+DQ5fs-XHNgh8YeYyK4gD411+DdZgFky3hwrBvNV4osWc98A@mail.gmail.com>

Hello.
As I can see, the class 'java.net.InetAddressContainer' is
unused in JDK java code.

Is it somehow used by VM, or is it just leftovers from some refactorings?
I wonder if we can drop it.

Andrey Turbanov

From michael.x.mcmahon at oracle.com  Thu Oct 27 14:53:48 2022
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 27 Oct 2022 15:53:48 +0100
Subject: Unused class java.net.InetAddressContainer
In-Reply-To: <CAF+DQ5fs-XHNgh8YeYyK4gD411+DdZgFky3hwrBvNV4osWc98A@mail.gmail.com>
References: <CAF+DQ5fs-XHNgh8YeYyK4gD411+DdZgFky3hwrBvNV4osWc98A@mail.gmail.com>
Message-ID: <436b961d-dd23-64cd-90a5-b774b1812819@oracle.com>

Hi,

That class was used in the old PlainSocketImpl socket implementation and 
was left over when we removed it.

I'll file an issue to delete it.

Thanks,

Michael.

On 27/10/2022 12:53, Andrey Turbanov wrote:
> Hello.
> As I can see, the class 'java.net.InetAddressContainer' is
> unused in JDK java code.
>
> Is it somehow used by VM, or is it just leftovers from some refactorings?
> I wonder if we can drop it.
>
> Andrey Turbanov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221027/04a8d705/attachment.htm>

From mchung at openjdk.org  Thu Oct 27 16:24:26 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 27 Oct 2022 16:24:26 GMT
Subject: RFR: 8295537: Enhance TRACE_METHOD_LINKAGE to show the target
 MethodHandle [v4]
In-Reply-To: <hFeR8jAT6SxA8LKlqKlLV9UImlR0AXWZ2sY8_-kjop4=.f1cd69a6-aae0-4054-87f6-27201a2a5630@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <hFeR8jAT6SxA8LKlqKlLV9UImlR0AXWZ2sY8_-kjop4=.f1cd69a6-aae0-4054-87f6-27201a2a5630@github.com>
Message-ID: <67Xq6M6v6azQhKCDjSTahvjBIg1jLlYvLAqY-r5XYxI=.6be1638e-2f24-4126-928e-7f4fdd6c5635@github.com>

On Thu, 27 Oct 2022 05:24:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Improve the handling of the `java.lang.invoke.MethodHandle.TRACE_METHOD_LINKAGE` property to print out the full graph of MethodHandles that are used at a CallSite. This helps us understand how invokedynamic call sites are resolved. For example:
>> 
>> 
>> public class StrConcat {
>>     static String hello = "Hello";
>>     static String world = "World";
>>     public static void main(String args[]) {
>>         System.out.println(hello + world);
>>         System.out.println(hello + "World");
>>     }
>> }
>> 
>> $ java -Djava.lang.invoke.MethodHandle.TRACE_METHOD_LINKAGE=true -cp . StrConcat
>> linkCallSite StrConcat.main(StrConcat.java:5) java.lang.invoke.StringConcatFactory.makeConcatWithConstants(Lookup,String,MethodType,String,Object[])CallSite/invokeStatic makeConcatWithConstants(String,String)String/BSA1=
>> linkMethod java.lang.invoke.MethodHandle.invokeExact(Lookup,String,MethodType,String,Object[])CallSite/5
>> linkMethod => java.lang.invoke.Invokers$Holder.invokeExact_MT(Object,Object,Object,Object,Object,Object,Object)Object/invokeStatic + (Lookup,String,MethodType,String,Object[])CallSite
>> linkCallSite target class => java.lang.invoke.BoundMethodHandle$Species_L
>> linkCallSite target => (String,String)String : BMH.reinvoke000_LLL_L=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>>     t3:L=Species_L.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic000_LLL_L=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>> ]
>> linkCallSite linkage => java.lang.invoke.Invokers$Holder.linkToTargetMethod(Object,Object,Object)Object/invokeStatic + MethodHandle(String,String)String
>> HelloWorld
>> linkCallSite StrConcat.main(StrConcat.java:6) java.lang.invoke.StringConcatFactory.makeConcatWithConstants(Lookup,String,MethodType,String,Object[])CallSite/invokeStatic makeConcatWithConstants(String)String/BSA1=World
>> linkCallSite target class => java.lang.invoke.BoundMethodHandle$Species_LL
>> linkCallSite target => (String)String : invoke000_LL_L=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
>> & BMH=[
>>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic000_LLL_L=Lambda(a0:L,a1:L,a2:L)=>{
>>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>>   }
>>   1: ( World )
>> ]
>> linkCallSite linkage => java.lang.invoke.Invokers$Holder.linkToTargetMethod(Object,Object)Object/invokeStatic + MethodHandle(String)String
>> HelloWorld
>> 
>> 
>> More complex examples are in the JBS bug report
>> - https://bugs.openjdk.org/secure/attachment/101202/eclipse-ide-log.txt
>> - https://bugs.openjdk.org/secure/attachment/101203/lambda-expression.txt
>> - https://bugs.openjdk.org/secure/attachment/101205/pattern-matching-switch.txt
>> - https://bugs.openjdk.org/secure/attachment/101204/str-concat.txt
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into 8295537-trace-jli-dynamic-call-sites
>  - Use Thread::getStackTrace() to find the caller's line number, etc
>  - @JornVernee comments
>  - also print the BSM
>  - cleaned up code; added comments; avoid using indy inside TRACE_CALLSITE; avoid interleaving output
>  - 8295537: Debug tracing for resolved dynamic call sites

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From lancea at openjdk.org  Thu Oct 27 17:15:32 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 27 Oct 2022 17:15:32 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup [v2]
In-Reply-To: <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
Message-ID: <HmFoCJYYpvEH6zr0hW1BUdEV8wFhhHJAgtEP7erIAcU=.7273dbbd-fb60-41cd-ab42-ab59c1f927c2@github.com>

On Wed, 26 Oct 2022 21:00:43 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
>> 
>> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
>> 
>> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge master
>  - Adjust template to reduce whitespace
>  - Re-add modified BasicDateTime test contents removed by generated template
>  - Adjust template to cleanup errors

Hi Justin

I think this looks oK overall.  There is some additional cleanup that can be done at a later time as we discussed but should be separate from this issue

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10684

From joehw at openjdk.org  Thu Oct 27 17:22:26 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Oct 2022 17:22:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Thu Oct 27 17:38:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 17:38:24 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
Message-ID: <9IeUomzE_jMjeWk2jrzY5-1W8n2JhijVyCPO2mQJrtI=.82a69e23-ccae-43a4-988c-5de54e4aad07@github.com>

On Thu, 27 Oct 2022 17:20:04 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

No problem - I will make this change when we have settled on a name for the variable `tmp` vs `_unused` (proposed by Michael).

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From duke at openjdk.org  Thu Oct 27 17:43:39 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 27 Oct 2022 17:43:39 GMT
Subject: RFR: 8295000: java/util/Formatter/Basic test cleanup [v2]
In-Reply-To: <HmFoCJYYpvEH6zr0hW1BUdEV8wFhhHJAgtEP7erIAcU=.7273dbbd-fb60-41cd-ab42-ab59c1f927c2@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
 <OvWQgL2hdRBY1vEirYS_phVIioU-XpFsvCcF51GAbcY=.66f396b2-e34f-462a-ba51-edfbcc833c16@github.com>
 <HmFoCJYYpvEH6zr0hW1BUdEV8wFhhHJAgtEP7erIAcU=.7273dbbd-fb60-41cd-ab42-ab59c1f927c2@github.com>
Message-ID: <pLlBumLVLrG8sXoB_KlR7cdf11ZqR4HRknAFilvID7U=.3cdda749-a0ae-4cf4-bd97-955cf80d4f8d@github.com>

On Thu, 27 Oct 2022 17:13:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge master
>>  - Adjust template to reduce whitespace
>>  - Re-add modified BasicDateTime test contents removed by generated template
>>  - Adjust template to cleanup errors
>
> Hi Justin
> 
> I think this looks oK overall.  There is some additional cleanup that can be done at a later time as we discussed but should be separate from this issue

@LanceAndersen Thank you Lance, 

I made the other changes we discussed, it is currently in a separate draft PR

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From aturbanov at openjdk.org  Thu Oct 27 17:54:31 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Oct 2022 17:54:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

test/jdk/java/net/URL/URLFromURITest.java line 268:

> 266:             // - URL authority is null or empty depending on the protocol
> 267:             //   and on whether the URL is hierarchical or not.
> 268:             if (isFileBased  && authority == null) {

Suggestion:

            if (isFileBased && authority == null) {

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From dfuchs at openjdk.org  Thu Oct 27 18:08:34 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 18:08:34 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
Message-ID: <VjAEpSLjpUPyUQcaxoONq7Y6zCqP7glgi8QikqXkakI=.689b7ff2-596a-4a87-ba02-b9c1f1c15c64@github.com>

On Thu, 27 Oct 2022 17:50:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> test/jdk/java/net/URL/URLFromURITest.java line 268:
> 
>> 266:             // - URL authority is null or empty depending on the protocol
>> 267:             //   and on whether the URL is hierarchical or not.
>> 268:             if (isFileBased  && authority == null) {
> 
> Suggestion:
> 
>             if (isFileBased && authority == null) {

Thanks - I will apply this suggestion.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From bhuang at openjdk.org  Thu Oct 27 18:39:39 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 27 Oct 2022 18:39:39 GMT
Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v2]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <HU0lqGw2Ksf32DEpq68x3HpXtMtDhe9Y5IOq03Dr_e0=.fa5df9b8-13cc-46fd-b242-7ca2b1762a29@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Updated test instruction messages.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/a190fc71..a61d56e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=00-01

  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825

PR: https://git.openjdk.org/jdk/pull/10825

From alanb at openjdk.org  Thu Oct 27 19:02:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Oct 2022 19:02:25 GMT
Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v2]
In-Reply-To: <HU0lqGw2Ksf32DEpq68x3HpXtMtDhe9Y5IOq03Dr_e0=.fa5df9b8-13cc-46fd-b242-7ca2b1762a29@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
 <HU0lqGw2Ksf32DEpq68x3HpXtMtDhe9Y5IOq03Dr_e0=.fa5df9b8-13cc-46fd-b242-7ca2b1762a29@github.com>
Message-ID: <tjrKnSX2X6O_JpaOsQZP5uGRdn4_y-ZykCg-jzByBZ0=.126290d3-6c45-4890-8ab3-8644903b75f5@github.com>

On Thu, 27 Oct 2022 18:39:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
>> 
>> Tests include: 
>> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
>> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
>> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test instruction messages.

test/jdk/TEST.groups line 204:

> 202:     java/rmi \
> 203:     -java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java \
> 204:     -java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java \

RunTests.gmk runs jtreg with -automatic so I don't think you need to exclude the manual tests from these test groups.

-------------

PR: https://git.openjdk.org/jdk/pull/10825

From bhuang at openjdk.org  Thu Oct 27 19:08:06 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Thu, 27 Oct 2022 19:08:06 GMT
Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v3]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <qWE-amaTygY7zpnTiw-Posy9H4JLslqXLGkb86rqg3o=.d95dd7d5-0022-4a93-bc22-85fc7861bcb6@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Reverted exclusion of nonlocal registry tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/a61d56e4..5ee556aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825

PR: https://git.openjdk.org/jdk/pull/10825

From bpb at openjdk.org  Thu Oct 27 20:43:39 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Oct 2022 20:43:39 GMT
Subject: RFR: 8156593: DataOutput.write(byte[], int,
 int) and its implementations do not specify index out bounds
Message-ID: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>

Add `@throws IndexOutOfBoundsException {@inheritDoc}` to some `write(byte[],int,int)` and `read(byte[],int,int)` methods of some classes in the `java.io` package to make things a bit clearer.

-------------

Commit messages:
 - 8156593: DataOutput.write(byte[],int,int) and its implementations do not specify index out bounds

Changes: https://git.openjdk.org/jdk/pull/10890/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10890&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8156593
  Stats: 18 lines in 11 files changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10890.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10890/head:pull/10890

PR: https://git.openjdk.org/jdk/pull/10890

From duke at openjdk.org  Thu Oct 27 20:58:46 2022
From: duke at openjdk.org (Justin Lu)
Date: Thu, 27 Oct 2022 20:58:46 GMT
Subject: Integrated: 8295000: java/util/Formatter/Basic test cleanup
In-Reply-To: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
References: <AaxzsKUzkPlOwZIE9OkdEo0zMmcuiz5tmFroCJXhwxs=.85f618d9-ef21-4181-9ec4-d513b3c1d401@github.com>
Message-ID: <6-Ljay6kMcBh3BNzzNY0MOLCXFYkyEYG2GlnU0GTtQU=.9a72b171-a371-40fe-86e8-ef7e00017b3f@github.com>

On Thu, 13 Oct 2022 01:02:43 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: java/util/Formatter/Basic regression test emits lots of warning messages (~60). 
> 
> Fix: Made adjustments to Basic-X.java.template as the BasicXXX.java files where the errors originate from are generated from the template. 
> 
> Note: The reason why there is white space added (and already existing in the BasicXXX files) is due to how the template is generated.

This pull request has now been integrated.

Changeset: 78763fc8
Author:    Justin Lu <justin.lu at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78763fc8e0d6940f1c85ff8705733b8e6ae8e945
Stats:     312 lines in 20 files changed: 205 ins; 6 del; 101 mod

8295000: java/util/Formatter/Basic test cleanup

Reviewed-by: bchristi, naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/10684

From mcimadamore at openjdk.org  Thu Oct 27 21:00:07 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Oct 2022 21:00:07 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview)
Message-ID: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>

This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.

[1] - https://openjdk.org/jeps/434

-------------

Commit messages:
 - Merge branch 'master' into PR_20
 - Merge pull request #14 from minborg/small-javadoc
 - Update some javadocs
 - Revert some javadoc changes
 - Merge branch 'master' into PR_20
 - Fix benchmark and test failure
 - Merge pull request #13 from minborg/revert-factories
 - Update javadocs after comments
 - Revert MemorySegment factories
 - Merge pull request #12 from minborg/fix-lookup-find
 - ... and 6 more: https://git.openjdk.org/jdk/compare/78454b69...ac7733da

Changes: https://git.openjdk.org/jdk/pull/10872/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295044
  Stats: 10527 lines in 200 files changed: 4754 ins; 3539 del; 2234 mod
  Patch: https://git.openjdk.org/jdk/pull/10872.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872

PR: https://git.openjdk.org/jdk/pull/10872

From mcimadamore at openjdk.org  Thu Oct 27 21:00:07 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 27 Oct 2022 21:00:07 GMT
Subject: RFR: 8295044: Implementation of Foreign Function and Memory API
 (Second Preview)
In-Reply-To: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
References: <x7ygjJqN-6Fpr3TqWadsqGflzDvYhi2QscqJJ1VM7KY=.f815a2ae-1bba-4c02-8faf-e5132fa974b5@github.com>
Message-ID: <rDhx7aLwHsyZdbzh_3bnwiu1QXHQm7LHh9nB2YYNXko=.6665a243-3366-471c-ad0b-244271db4241@github.com>

On Wed, 26 Oct 2022 13:11:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.org/jeps/434

Here are the main API changes introduced in this round (there are also some JVM changes which will be integrated separately):

* The main change is the removal of `MemoryAddress` and `Addressable`. Instead, *zero-length memory segments* are used whenever the API needs to model "raw" addresses coming from native code. This simplifies the API, removing an ambiguous abstraction as well as some duplication in the API (see accessor methods in `MemoryAddress`);

* To allow for "unsafe" access of zero-length memory segments, a new method has been added to `ValueLayout.OfAddress`, namely `asUnbounded`. This new restricted method takes an address layout and creates a new unbounded address layout. When using an unbounded layout to dereference memory, or construct downcall method handles, the API will create memory segments with maximal length (i.e. `Long.MAX_VALUE`, rather than zero-length memory segments, which can therefore be accessed;

* The `MemoryLayout` hierarchy has been improved in several ways. First, the hierarchy is now defined in terms of sealed interfaces (intermediate abstract classes have been moved into the implementation package). The hierarchy is also exhaustive now, and works much better to pattern matching. More specifically, three new types have been added: `PaddingLayout`, `StructLayout` and `UnionLayout`, the latter two are a subtype of `GroupLayout`. Thanks to this move, several predicate methods (`isPadding`, `isStruct`, `isUnion`) have been dropped from the API;

* The `SymbolLookup::lookup` method has been renamed to `SymbolLookup::find` - to avoid using the same word `lookup` in both noun and verb form, which leads to confusion;

* A new method, on `ModuleLayer.Controller` has been added to enable native access on a module in a custom layer;

* The new interface `Linker.Option` has been introduced. This is a tag interface accepted in `Linker::downcallHandle`. At the moment, only a single option is provided, to specify variadic function calls (because of this, the `FunctionDescriptor` interface has been simplified, and is now a simple carrier of arguments/return layouts). More linker options will follow.

Javadoc: http://cr.openjdk.java.net/~mcimadamore/jdk/8295044/v1/javadoc/java.base/java/lang/foreign/package-summary.html

-------------

PR: https://git.openjdk.org/jdk/pull/10872

From forax at univ-mlv.fr  Thu Oct 27 21:20:08 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 27 Oct 2022 23:20:08 +0200 (CEST)
Subject: RFR -  Implementation of JEP-430 String Templates (Preview) CSR
In-Reply-To: <570660084.34318648.1666776358106.JavaMail.zimbra@u-pem.fr>
References: <6E63DC57-0518-45DE-8BEB-0800BDC635C6@oracle.com>
 <570660084.34318648.1666776358106.JavaMail.zimbra@u-pem.fr>
Message-ID: <174985434.35476395.1666905608758.JavaMail.zimbra@u-pem.fr>

I would like to retract the comments i've made below, 
because the first point is now moot and for the second one, after some more thinking, it may be not that bad and at least the API is very simple to use. 

R?mi 

> From: "Remi Forax" <forax at univ-mlv.fr>
> To: "Jim Laskey" <james.laskey at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Wednesday, October 26, 2022 11:25:58 AM
> Subject: Re: RFR - Implementation of JEP-430 String Templates (Preview) CSR

> Each time i re-read this JEP, i'm more and more sorry about its state.
> - we are breaking how Strings worked, now everything in between "..." is not a
> String anymore.
> As an example, given a String s, only one of the following lines compiles
> System.out.println("s = \{s}".toUpperCase());
> System.out.println("s = {\s}".toUpperCase());
> - conceptually we have something like
> instance -> template -> arguments

> but instead of grouping it like this
> Class.apply(template).invoke(instance, arguments)

> the JEP groups them like this
> instance.apply(new TemplatedString(template, arguments))

> which is far less efficient because both the class and the template are
> constants while the instance and the arguments are not.

> R?mi

>> From: "Jim Laskey" <james.laskey at oracle.com>
>> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Sent: Tuesday, October 25, 2022 6:41:05 PM
>> Subject: RFR - Implementation of JEP-430 String Templates (Preview) CSR

>> Request for a broader review of the String Template APIs for JEP 430.

>> Summary:

>> Enhance the Java programming language with string templates, which are similar
>> to string literals but contain embedded expressions. A string template is
>> interpreted at run time by replacing each expression with the result of
>> evaluating that expression, possibly after further validation and
>> transformation. This is a preview language feature and API.

>> CSR: [ https://bugs.openjdk.org/browse/JDK-8286021 |
>> https://bugs.openjdk.org/browse/JDK-8286021 ]
>> JEP: [ https://openjdk.org/jeps/430 | https://openjdk.org/jeps/430 ]

>> Thank you.

>> ? Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221027/fa8ec6e7/attachment.htm>

From james.laskey at oracle.com  Thu Oct 27 22:07:39 2022
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 27 Oct 2022 22:07:39 +0000
Subject: [External] : Re: RFR -  Implementation of JEP-430 String
 Templates (Preview) CSR
In-Reply-To: <174985434.35476395.1666905608758.JavaMail.zimbra@u-pem.fr>
References: <6E63DC57-0518-45DE-8BEB-0800BDC635C6@oracle.com>
 <570660084.34318648.1666776358106.JavaMail.zimbra@u-pem.fr>
 <174985434.35476395.1666905608758.JavaMail.zimbra@u-pem.fr>
Message-ID: <810EA98E-A8FE-4B55-8F80-FEAA0F36C68F@oracle.com>

Try it out. The code has been sitting in the amber repo on the templated-strings branch all along.

Cheers,

? Jim


?

On Oct 27, 2022, at 6:20 PM, Remi Forax <forax at univ-mlv.fr> wrote:

?
I would like to retract the comments i've made below,
because the first point is now moot and for the second one, after some more thinking, it may be not that bad and at least the API is very simple to use.

R?mi

________________________________
From: "Remi Forax" <forax at univ-mlv.fr>
To: "Jim Laskey" <james.laskey at oracle.com>
Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Wednesday, October 26, 2022 11:25:58 AM
Subject: Re: RFR -  Implementation of JEP-430 String Templates (Preview) CSR
Each time i re-read this JEP, i'm more and more sorry about its state.
- we are breaking how Strings worked, now everything in between "..." is not a String anymore.
  As an example, given a String s, only one of the following lines compiles
     System.out.println("s = \{s}".toUpperCase());
     System.out.println("s = {\s}".toUpperCase());

- conceptually we have something like
     instance -> template -> arguments

  but instead of grouping it like this
     Class.apply(template).invoke(instance, arguments)

  the JEP groups them like this
     instance.apply(new TemplatedString(template, arguments))

  which is far less efficient because both the class and the template are constants while the instance and the arguments are not.

R?mi

________________________________
From: "Jim Laskey" <james.laskey at oracle.com>
To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
Sent: Tuesday, October 25, 2022 6:41:05 PM
Subject: RFR -  Implementation of JEP-430 String Templates (Preview) CSR
Request for a broader review of the String Template APIs for JEP 430.

Summary:

Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a preview language feature and API.

CSR: https://bugs.openjdk.org/browse/JDK-8286021
JEP: https://openjdk.org/jeps/430


Thank you.

? Jim



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221027/23ad6d17/attachment-0001.htm>

From iklam at openjdk.org  Thu Oct 27 22:08:27 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Oct 2022 22:08:27 GMT
Subject: RFR: 8295537: Enhance TRACE_METHOD_LINKAGE to show the target
 MethodHandle [v3]
In-Reply-To: <zB52__HTl2TzYOCgToYrL5-JqMY18XFSX7pJwe_AEuk=.915abe9b-d80c-4682-a535-3330a29b57d4@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
 <87SDsz2XWVqe_lUlvGOA2lHCiwVKPicjVfapkP2pobA=.036c54e4-c575-4731-86ce-df1ca35dbe3b@github.com>
 <zB52__HTl2TzYOCgToYrL5-JqMY18XFSX7pJwe_AEuk=.915abe9b-d80c-4682-a535-3330a29b57d4@github.com>
Message-ID: <LXbpPSWL3bbeSp6uwxboK-lRf0ycNEFtO3lHoFuJW0s=.434095ea-c850-451f-b4b8-eed06c51b349@github.com>

On Wed, 26 Oct 2022 21:55:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Thread::getStackTrace() to find the caller's line number, etc
>
> Marked as reviewed by redestad (Reviewer).

Thanks @cl4es @JornVernee @mlchung for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From iklam at openjdk.org  Thu Oct 27 22:10:28 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Oct 2022 22:10:28 GMT
Subject: Integrated: 8295537: Enhance TRACE_METHOD_LINKAGE to show the target
 MethodHandle
In-Reply-To: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
References: <KiCPbz1LAtTkd28-dYF0dxq1HNnAwsr6_zRgt1sWxjg=.d0bd3b38-f490-43ef-b9f2-6c33364246f9@github.com>
Message-ID: <b059otWZMaaLIYzdAZNW4J-f6MfctF6jglQcAdnDe9M=.2b8c7906-82e3-4dc8-a9c2-7dd6c53fe9d0@github.com>

On Mon, 24 Oct 2022 22:15:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Improve the handling of the `java.lang.invoke.MethodHandle.TRACE_METHOD_LINKAGE` property to print out the full graph of MethodHandles that are used at a CallSite. This helps us understand how invokedynamic call sites are resolved. For example:
> 
> 
> public class StrConcat {
>     static String hello = "Hello";
>     static String world = "World";
>     public static void main(String args[]) {
>         System.out.println(hello + world);
>         System.out.println(hello + "World");
>     }
> }
> 
> $ java -Djava.lang.invoke.MethodHandle.TRACE_METHOD_LINKAGE=true -cp . StrConcat
> linkCallSite StrConcat.main(StrConcat.java:5) java.lang.invoke.StringConcatFactory.makeConcatWithConstants(Lookup,String,MethodType,String,Object[])CallSite/invokeStatic makeConcatWithConstants(String,String)String/BSA1=
> linkMethod java.lang.invoke.MethodHandle.invokeExact(Lookup,String,MethodType,String,Object[])CallSite/5
> linkMethod => java.lang.invoke.Invokers$Holder.invokeExact_MT(Object,Object,Object,Object,Object,Object,Object)Object/invokeStatic + (Lookup,String,MethodType,String,Object[])CallSite
> linkCallSite target class => java.lang.invoke.BoundMethodHandle$Species_L
> linkCallSite target => (String,String)String : BMH.reinvoke000_LLL_L=Lambda(a0:L/SpeciesData[L => Species_L],a1:L,a2:L)=>{
>     t3:L=Species_L.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,a2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic000_LLL_L=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
> ]
> linkCallSite linkage => java.lang.invoke.Invokers$Holder.linkToTargetMethod(Object,Object,Object)Object/invokeStatic + MethodHandle(String,String)String
> HelloWorld
> linkCallSite StrConcat.main(StrConcat.java:6) java.lang.invoke.StringConcatFactory.makeConcatWithConstants(Lookup,String,MethodType,String,Object[])CallSite/invokeStatic makeConcatWithConstants(String)String/BSA1=World
> linkCallSite target class => java.lang.invoke.BoundMethodHandle$Species_LL
> linkCallSite target => (String)String : invoke000_LL_L=Lambda(a0:L/SpeciesData[LL => BoundMethodHandle$Species_LL],a1:L)=>{
>     t2:L=BoundMethodHandle$Species_LL.argL1(a0:L);
>     t3:L=BoundMethodHandle$Species_LL.argL0(a0:L);
>     t4:L=MethodHandle.invokeBasic(t3:L,a1:L,t2:L);t4:L}
> & BMH=[
>   0: MethodHandle = {(Object,Object)String : DMH.invokeStatic000_LLL_L=Lambda(a0:L,a1:L,a2:L)=>{
>         t3:L=DirectMethodHandle.internalMemberName(a0:L);
>         t4:L=MethodHandle.linkToStatic(a1:L,a2:L,t3:L);t4:L}
>     & DMH.MN=java.lang.StringConcatHelper.simpleConcat(Object,Object)String/invokeStatic
>   }
>   1: ( World )
> ]
> linkCallSite linkage => java.lang.invoke.Invokers$Holder.linkToTargetMethod(Object,Object)Object/invokeStatic + MethodHandle(String)String
> HelloWorld
> 
> 
> More complex examples are in the JBS bug report
> - https://bugs.openjdk.org/secure/attachment/101202/eclipse-ide-log.txt
> - https://bugs.openjdk.org/secure/attachment/101203/lambda-expression.txt
> - https://bugs.openjdk.org/secure/attachment/101205/pattern-matching-switch.txt
> - https://bugs.openjdk.org/secure/attachment/101204/str-concat.txt

This pull request has now been integrated.

Changeset: fd668dc4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd668dc44f54274518d2bb46c5e22318a872c02e
Stats:     75 lines in 5 files changed: 61 ins; 0 del; 14 mod

8295537: Enhance TRACE_METHOD_LINKAGE to show the target MethodHandle

Reviewed-by: jvernee, redestad, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/10842

From duke at openjdk.org  Thu Oct 27 22:19:26 2022
From: duke at openjdk.org (Rob Leland)
Date: Thu, 27 Oct 2022 22:19:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <RaFx3blIdoBXwF7RjK7TFIuqHSxTNk9-C94QaPKmEeg=.118063ff-f956-427a-a2f6-a87fc85dc601@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Why not go ahead and replace all the usages with fromURI(} to start  with.where possible ?

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From jlaskey at openjdk.org  Thu Oct 27 22:27:47 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Oct 2022 22:27:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview)
Message-ID: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>

Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

-------------

Commit messages:
 - Tabs to spaces
 - Force processor before template string expression
 - Correct implNote
 - Add valueGetters method
 - Added RAW template processor
 - Merge branch 'master' into 8285932
 - Rename to ValidatingProcessor
 - Javadoc mistakes
 - Rename TemplateProcessor
 - Clean up tests
 - ... and 4 more: https://git.openjdk.org/jdk/compare/0c13d666...7b2011ac

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285932
  Stats: 7452 lines in 74 files changed: 7263 ins; 45 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Thu Oct 27 22:47:26 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 22:47:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:

> 113:      * we do not use all those slots, to let the strategies with MethodHandle
> 114:      * combinators to use some arguments.
> 115:      */

Suggestion:

     *
     * @since 20
     */

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:

> 1056:          * @throws Throwable if fails to prepend value (unusual).
> 1057:          */
> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;

This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.

--------------------------------------------------------------------------------

The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From cjplummer at openjdk.org  Fri Oct 28 00:55:44 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Oct 2022 00:55:44 GMT
Subject: RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <-0yo8KceENmJ48YPNoHCUkx_iEWpIE0mPJn_-BkjbWY=.76a8dcb8-f43a-4c8b-8912-43c7225c183d@github.com>
Message-ID: <DIScQIcbKFsercPkoaABYXSmJznKrSSnJwhL-kJDSDU=.5be8456a-ce87-4b56-83f9-b397e2785402@github.com>

On Fri, 7 Oct 2022 12:51:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reinstate typos in Apache code that is copied into the JDK
>>  - Merge ../jdk-openjdk into typos-typos
>>  - Remove file that was removed upstream
>>  - Fix inconsistency in capitalization
>>  - Undo change in zlip
>>  - Fix typos
>
> src/java.se/share/data/jdwp/jdwp.spec line 101:
> 
>> 99:         "<a href=../../api/java.base/java/lang/Thread.html#platform-threads>platform thread</a> "
>> 100:         "in the target VM. This includes platform threads created with the Thread "
>> 101:         "API and all native threads attached to the target VM with JNI code."
> 
> The spec for the JDWP AllThreads command was significantly reworded in Java 19 so this is where this typo crept in. We have JDK-8294672 tracking it to fix for Java 20, maybe you should take it?

Since this PR has gone stale, I'll be fixing this typo in jdwp.spec via [JDK-8294672](https://bugs.openjdk.org/browse/JDK-8294672).

-------------

PR: https://git.openjdk.org/jdk/pull/10029

From cjplummer at openjdk.org  Fri Oct 28 01:12:59 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Oct 2022 01:12:59 GMT
Subject: RFR: 8294672: Typo in description of JDWP VirtualMachine/AllThreads
 command
Message-ID: <YRdJPGlyZrqn3vFtRLu_PoSLrPjancjo0xz9zhYEblQ=.0b104ffb-71fb-4d4e-8536-b95e97df31ef@github.com>

Fix typo: "and and" => "and"

-------------

Commit messages:
 - fix typo in VirtualMachine.AllThreads

Changes: https://git.openjdk.org/jdk/pull/10895/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10895&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294672
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10895.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10895/head:pull/10895

PR: https://git.openjdk.org/jdk/pull/10895

From jpai at openjdk.org  Fri Oct 28 01:30:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Oct 2022 01:30:26 GMT
Subject: RFR: 8294672: Typo in description of JDWP
 VirtualMachine/AllThreads command
In-Reply-To: <YRdJPGlyZrqn3vFtRLu_PoSLrPjancjo0xz9zhYEblQ=.0b104ffb-71fb-4d4e-8536-b95e97df31ef@github.com>
References: <YRdJPGlyZrqn3vFtRLu_PoSLrPjancjo0xz9zhYEblQ=.0b104ffb-71fb-4d4e-8536-b95e97df31ef@github.com>
Message-ID: <lbJf-4DfUE_LPPVPxE7uchJZfsFef6h7c7O-uN4b7_8=.bde94569-8bd2-4210-b7a7-2b4a297cf6e9@github.com>

On Fri, 28 Oct 2022 01:04:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix typo: "and and" => "and"

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10895

From duke at openjdk.org  Fri Oct 28 05:22:26 2022
From: duke at openjdk.org (duke)
Date: Fri, 28 Oct 2022 05:22:26 GMT
Subject: Withdrawn: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <8ubk-K2kOn6qk_cXv9_VYFDa3NMm2-JEwMEV-R-bNP4=.817c77c9-bcac-4177-bcdc-de94bcf77671@github.com>

On Fri, 5 Aug 2022 16:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The pattern matching switches are using a bootstrap method `SwitchBootstrap.typeSwitch` to implement the jumps in the switch. Basically, for a switch like:
> 
> switch (obj) {
>     case String s when s.isEmpty() -> {}
>     case String s -> {}
>     case CharSequence cs -> {}
>     ...
> }
> 
> 
> this method will produce a MethodHandle that will be analyze the provided selector value (`obj` in the example), and will return the case index to which the switch should jump. This method also accepts a (re)start index for the search, which is used to handle guards. For example, if the `s.isEmpty()` guard in the above sample returns false, the matching is restarted on the next case.
> 
> The current implementation is fairly slow, it basically goes through the labels in a loop. The proposal here is to replace that with a MethodHandle structure like this:
> 
> obj == null ? -1
>                   : switch (restartIndex) {
>                         case 0 -> obj instanceof String ? 0 : obj instanceof CharSequence ? 2 : ... ;
>                         case 1 -> obj instanceof String ? 1 : obj instanceof CharSequence ? 2 : ... ;
>                         case 2 -> obj instanceof CharSequence ? 2 : ... ;
>                         ...
>                         default -> <labels-count>;
>                     }
> 
> 
> This appear to run faster than the current implementation, using testcase similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these are the results
> 
> PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25   1515989.562 ? 32047.918  ops/s
> PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25   2630707.585 ? 37202.210  ops/s
> 
> PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25   6789310.900 ? 61921.636  ops/s
> PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  10771729.464 ? 69607.467  ops/s
> 
> 
> The "LegacyIndy" is the current implementation, "HandleIndy" is the one proposed here. The translation in javac used is the one from #9746 in all cases.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9779

From duke at openjdk.org  Fri Oct 28 05:57:27 2022
From: duke at openjdk.org (duke)
Date: Fri, 28 Oct 2022 05:57:27 GMT
Subject: Withdrawn: 8289711: Add container configuration data to mbeans
In-Reply-To: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <QwtAq8xl0kqiKt_uhWlC_-lo6z2ljSNaJvBWT52cIQI=.cdbee17a-e850-41d4-9273-b6b2d3771327@github.com>

On Tue, 5 Jul 2022 04:21:55 GMT, xpbob <duke at openjdk.org> wrote:

> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios.
> Results the following
> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9372

From aturbanov at openjdk.org  Fri Oct 28 06:13:26 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 28 Oct 2022 06:13:26 GMT
Subject: RFR: 8156593: DataOutput.write(byte[],int,int) and its
 implementations do not specify index out bounds
In-Reply-To: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
References: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
Message-ID: <j_N3GIb-8X4KHmdoWsjP6nbYWqfWvmjgDzB3-6vITJQ=.4f9ca6a7-3957-48d3-b6d6-e5a68b63bcde@github.com>

On Thu, 27 Oct 2022 20:35:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `@throws IndexOutOfBoundsException {@inheritDoc}` to some `write(byte[],int,int)` and `read(byte[],int,int)` methods of some classes in the `java.io` package to make things a bit clearer.

src/java.base/share/classes/java/io/FileOutputStream.java line 346:

> 344:      * @param      b   {@inheritDoc}
> 345:      * @throws     IOException  {@inheritDoc}
> 346:      * @throws     IndexOutOfBoundsException {@inheritDoc}

When this IOOB can happen in `void write(byte[] b)` ?

-------------

PR: https://git.openjdk.org/jdk/pull/10890

From jiefu at openjdk.org  Fri Oct 28 13:57:36 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 28 Oct 2022 13:57:36 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <v87rbwRSX4_39wqbvRXaWhg0Vwol0Z1Yw6w73UiAzLo=.bf225c55-8873-4bbf-9b17-0890c9b0f7d4@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
 <v87rbwRSX4_39wqbvRXaWhg0Vwol0Z1Yw6w73UiAzLo=.bf225c55-8873-4bbf-9b17-0890c9b0f7d4@github.com>
Message-ID: <Okdrw9P0k-bavhqMSxNjbQHK_kS9NXm4DsMtsMOKZIY=.e75806a0-2cf6-4dc3-8a8f-1289bac02a31@github.com>

On Fri, 28 Oct 2022 13:41:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think you need to add at least one other label than `build` to this now to make sure the right people can have a say in the change.

Done.
Thanks @erikj79 .

-------------

PR: https://git.openjdk.org/jdk/pull/10879

From dfuchs at openjdk.org  Fri Oct 28 14:54:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Oct 2022 14:54:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/25a0188c..fd4ca287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00-01

  Stats: 25761 lines in 392 files changed: 1581 ins; 23649 del; 531 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

PR: https://git.openjdk.org/jdk/pull/10874

From jlaskey at openjdk.org  Fri Oct 28 14:55:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Move StringConcatItem to FormatConcatItem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/7b2011ac..26485968

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00-01

  Stats: 239 lines in 6 files changed: 93 ins; 109 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 14:55:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
Message-ID: <8KVfwqrbnCSF-80frLIKExvp7jih3Ltp-UY3eaHuTco=.2f87479c-39d9-4eda-87f4-832b6ac8b9cb@github.com>

On Thu, 27 Oct 2022 21:21:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:
> 
>> 113:      * we do not use all those slots, to let the strategies with MethodHandle
>> 114:      * combinators to use some arguments.
>> 115:      */
> 
> Suggestion:
> 
>      *
>      * @since 20
>      */

Updated along with a couple @since 19

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:
> 
>> 1056:          * @throws Throwable if fails to prepend value (unusual).
>> 1057:          */
>> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;
> 
> This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.
> 
> --------------------------------------------------------------------------------
> 
> The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

Went the sealed class route. Unfortunately, the permitted classes are all package private otherwise I would have moved to an internal package.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From bpb at openjdk.org  Fri Oct 28 15:18:06 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 28 Oct 2022 15:18:06 GMT
Subject: RFR: 8156593: DataOutput.write(byte[],int,int) and its
 implementations do not specify index out bounds [v2]
In-Reply-To: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
References: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
Message-ID: <lpI1SJm-xLRpChTU4PcIpJZ6-cR5FZPBiNn7LWPojUk=.7e103f3d-cfba-4e1d-8de1-4a1aad60ec51@github.com>

> Add `@throws IndexOutOfBoundsException {@inheritDoc}` to some `write(byte[],int,int)` and `read(byte[],int,int)` methods of some classes in the `java.io` package to make things a bit clearer.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8156593: Fix accidental edit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10890/files
  - new: https://git.openjdk.org/jdk/pull/10890/files/e24b291b..c3ee766e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10890&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10890&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10890.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10890/head:pull/10890

PR: https://git.openjdk.org/jdk/pull/10890

From bpb at openjdk.org  Fri Oct 28 15:18:08 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 28 Oct 2022 15:18:08 GMT
Subject: RFR: 8156593: DataOutput.write(byte[],int,int) and its
 implementations do not specify index out bounds [v2]
In-Reply-To: <j_N3GIb-8X4KHmdoWsjP6nbYWqfWvmjgDzB3-6vITJQ=.4f9ca6a7-3957-48d3-b6d6-e5a68b63bcde@github.com>
References: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
 <j_N3GIb-8X4KHmdoWsjP6nbYWqfWvmjgDzB3-6vITJQ=.4f9ca6a7-3957-48d3-b6d6-e5a68b63bcde@github.com>
Message-ID: <yGc8hQCcrlD5wR7JdUMJkbMD5CuxXWgzz5LVfE2hDU8=.b58264b9-e2c0-4e19-a2e8-8434208e45e5@github.com>

On Fri, 28 Oct 2022 06:09:49 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8156593: Fix accidental edit
>
> src/java.base/share/classes/java/io/FileOutputStream.java line 346:
> 
>> 344:      * @param      b   {@inheritDoc}
>> 345:      * @throws     IOException  {@inheritDoc}
>> 346:      * @throws     IndexOutOfBoundsException {@inheritDoc}
> 
> When this IOOB can happen in `void write(byte[] b)` ?

It can't. Thanks for catching this accident. Fixed in c3ee766e2a0e1bc4cc49c81a0eb3221b05c411b7.

-------------

PR: https://git.openjdk.org/jdk/pull/10890

From alanb at openjdk.org  Fri Oct 28 15:26:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Oct 2022 15:26:30 GMT
Subject: RFR: 8156593: DataOutput.write(byte[],int,int) and its
 implementations do not specify index out bounds [v2]
In-Reply-To: <lpI1SJm-xLRpChTU4PcIpJZ6-cR5FZPBiNn7LWPojUk=.7e103f3d-cfba-4e1d-8de1-4a1aad60ec51@github.com>
References: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
 <lpI1SJm-xLRpChTU4PcIpJZ6-cR5FZPBiNn7LWPojUk=.7e103f3d-cfba-4e1d-8de1-4a1aad60ec51@github.com>
Message-ID: <f-uh6Mdd_kzCMg1e71nPO_MgaaaRvYYQ5O8VvBq3Qds=.946a0a50-8813-4e17-8725-5c0d0fff3db8@github.com>

On Fri, 28 Oct 2022 15:18:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `@throws IndexOutOfBoundsException {@inheritDoc}` to some `write(byte[],int,int)` and `read(byte[],int,int)` methods of some classes in the `java.io` package to make things a bit clearer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8156593: Fix accidental edit

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10890

From aturbanov at openjdk.org  Fri Oct 28 15:56:27 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 28 Oct 2022 15:56:27 GMT
Subject: RFR: 8156593: DataOutput.write(byte[],int,int) and its
 implementations do not specify index out bounds [v2]
In-Reply-To: <lpI1SJm-xLRpChTU4PcIpJZ6-cR5FZPBiNn7LWPojUk=.7e103f3d-cfba-4e1d-8de1-4a1aad60ec51@github.com>
References: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
 <lpI1SJm-xLRpChTU4PcIpJZ6-cR5FZPBiNn7LWPojUk=.7e103f3d-cfba-4e1d-8de1-4a1aad60ec51@github.com>
Message-ID: <N2qv5Hjiru0mxqLJzb_05cWF4tywtvrNggnv3ZJkNh4=.932430d1-8da1-4126-9534-aab3ca945ad6@github.com>

On Fri, 28 Oct 2022 15:18:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `@throws IndexOutOfBoundsException {@inheritDoc}` to some `write(byte[],int,int)` and `read(byte[],int,int)` methods of some classes in the `java.io` package to make things a bit clearer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8156593: Fix accidental edit

Marked as reviewed by aturbanov (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/10890

From duke at openjdk.org  Fri Oct 28 16:12:50 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 16:12:50 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:

> 363:         Objects.requireNonNull(sts, "sts must not be null");
> 364:         if (sts.length == 0) {
> 365:             StringTemplate.of("");

Missing return?

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:

> 365:             StringTemplate.of("");
> 366:         } else if (sts.length == 1) {
> 367:             return sts[0];

Check for null?

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From joehw at openjdk.org  Fri Oct 28 16:43:23 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Oct 2022 16:43:23 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <4ThJRTvihtvhX_xBjaCTHOL4w-VHDJuXTUkvtfRVPvY=.ad69332e-e7a2-43fc-9893-3a27f7ca4d5c@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Thanks Daniel. The java.xml part looks good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10874

From bchristi at openjdk.org  Fri Oct 28 16:52:30 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 28 Oct 2022 16:52:30 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
Message-ID: <guhONdnfTR_IikR3hOj64XANc-qpCUu_LGLHCkgAyTU=.98275191-aca4-4467-84cf-97f1246b31ad@github.com>

On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

Not today, PullrequestCloserBot

-------------

PR: https://git.openjdk.org/jdk/pull/8311

From jlaskey at openjdk.org  Fri Oct 28 17:57:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 17:57:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update TemplateRuntime::combine

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/26485968..20f54dec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 18:01:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 18:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
Message-ID: <HhGc5V1_nIfnkwUhoR0KXdaqK12XDy4UdCwfQpYIHoM=.07435759-8a04-4f58-b244-30d81576cc56@github.com>

On Fri, 28 Oct 2022 16:09:51 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:
> 
>> 363:         Objects.requireNonNull(sts, "sts must not be null");
>> 364:         if (sts.length == 0) {
>> 365:             StringTemplate.of("");
> 
> Missing return?

Yep - updated

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:
> 
>> 365:             StringTemplate.of("");
>> 366:         } else if (sts.length == 1) {
>> 367:             return sts[0];
> 
> Check for null?

Added null checks

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:20 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <qXjmvDvCAAHmElOuzn4nEUEG3d9bBXRHzmJJZHpGt1o=.9d9eb47e-e661-468b-b1ef-658b3d62cf25@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

Added some comments - will probably have some more at a later point

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:26 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:

> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");

Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:

> 104:     private final Attr attr;
> 105:     private final Symtab syms;
> 106:     private final Types types;

Why this change?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:

> 4972:         if (processor != null) {
> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);

It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:

> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
> 4138: 
> 4139:             if (typeArguments.size() == 2) {

Is this code correct? TemplateProcessor seems to have just one type argument.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1:

> 1: /*

This file shouldn't be here

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:

> 346:                 try {
> 347:                     chk.disablePreviewCheck = true;
> 348:                     String autoImports = """

I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.

What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.

As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mcimadamore at openjdk.org  Fri Oct 28 18:38:27 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>

On Fri, 28 Oct 2022 16:09:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
> 
>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>> 4138: 
>> 4139:             if (typeArguments.size() == 2) {
> 
> Is this code correct? TemplateProcessor seems to have just one type argument.

Ah - `templateProcessorType` is not what it seems :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 18:50:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 18:50:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:

> 30: 
> 31: import java.io.IOException;
> 32: import java.util.*;

Please do not use import *.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:

> 34: import java.lang.invoke.MethodHandles.Lookup;
> 35: import java.lang.template.StringTemplate;
> 36: import java.util.*;

Another import * here

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:

> 116:      * @since 20
> 117:      */
> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;

I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:

> 997:      * Promote integral types to int.
> 998:      */
> 999:     private static Class<?> promoteIntType(Class<?> t) {

promoteToIntType ?

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:02:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:02:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:

> 1040:      * The number of fragments must be one more that the number of ptypes.
> 1041:      * The total number of slots used by the ptypes must be less than or equal
> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.

see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:

> 1058:             throws StringConcatException
> 1059:     {
> 1060:         Objects.requireNonNull(fragments, "fragments is null");

I think you need to do some defensive copy here

  ptypes = List.copyOf(pTypes);

to avoid the types and fragments to be changed at the same time they are checked.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:

> 1175:      */
> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(

I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:

> 49:     /**
> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
> 51:      * bootstrap method information.

This comment is quite obscure if you have no idea how it works.
And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:

> 36: record SimpleStringTemplate(List<String> fragments,
> 37:                              List<Object> values
> 38: ) implements StringTemplate {}

A compact constructor doing defensive copies is missing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:11:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:11:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:

> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 44: @FunctionalInterface
> 45: public interface StringProcessor extends TemplateProcessor<String> {}

The name should be `StringTemplateProcessor`.
And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:

> 27: 
> 28: import java.lang.invoke.MethodHandle;
> 29: import java.util.*;

Please fix.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:

> 147:      * {@return the interpolation of the StringTemplate}
> 148:      */
> 149:     default String interpolate() {

I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:

> 173:      * method {@code processor.process(this)}.
> 174:      */
> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {

signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:

> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
> 203:      */
> 204:     default public List<MethodHandle> valueGetters() {

I think i prefer the term accessors instead of getters

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:31:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:31:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:

> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
> 306:         }
> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));

I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().

src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:

> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 322:      */
> 323:     public static String interpolate(List<String> fragments, List<Object> values) {

This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:

> 352:      * @implNote The result of interpolation is not interned.
> 353:      */
> 354:     public static final StringProcessor STR = st -> st.interpolate();

Should be `StringTemplate::interpolate`.

src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:

> 36:  * that do not throw checked exceptions. For example:
> 37:  * {@snippet :
> 38:  * TemplateProcessor<String> processor = st -> {

This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:

> 43:  */
> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 45: public final class TemplateRuntime {

Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:

> 63:      * @throws Throwable            if linkage fails
> 64:      */
> 65:     public static CallSite stringTemplateBSM(

I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:

> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();

`ValidatingProcessor<?, ?>` should be enough ? No ?
Not using a "? extends Throwable" here make the type unchecked.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:

> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
> 87:      */
> 88:     private static class TemplateBootstrap {

This class should be `final`

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:

> 115:          * Static final processor.
> 116:          */
> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;

Use `ValidatingProcessor<?, ?>` here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:

> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
> 144:                                   List<String> fragments,
> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {

Use ValidatingProcessor<?, ?> here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:

> 209:     @SuppressWarnings("unchecked")
> 210:     public static <E> List<E> toList(E... elements) {
> 211:         return Collections.unmodifiableList(Arrays.asList(elements));

This is List.of(), please use List.of() instead

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:31:37 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@github.com>

On Fri, 28 Oct 2022 16:33:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:
> 
>> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
>> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
>> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");
> 
> Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

Renaming.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:
> 
>> 104:     private final Attr attr;
>> 105:     private final Symtab syms;
>> 106:     private final Types types;
> 
> Why this change?

Renaming. Was residual to some context based typing (StringTemplate vs String) Jan and I experimented with.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:
> 
>> 4972:         if (processor != null) {
>> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
>> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);
> 
> It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

Not sure where you get `StringTemplate`.  If you specify `TemplateProcessor<String>` the `resultType` will be `String`.  For example:


public class Processor implements TemplateProcessor<String> {
    @Override
    public String process(StringTemplate st) {
        return st.interpolate();
    }
}

and

public class Main {
    public static void main(String... args) throws Throwable {
        Processor processor = new Processor();
        System.out.println(processor."1234");
    }
}

works with "1234" as a result.

If you later change to


public class Processor implements TemplateProcessor<Integer> {
    @Override
    public Integer process(StringTemplate st) {
        return Integer.valueOf(st.interpolate());
    }
}


Then you get a `java.lang.ClassCastException` as you would expect.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1:
> 
>> 1: /*
> 
> This file shouldn't be here

oops - We should change the `.gitignore` to include `.orig` and `.rej`

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:
> 
>> 346:                 try {
>> 347:                     chk.disablePreviewCheck = true;
>> 348:                     String autoImports = """
> 
> I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.
> 
> What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.
> 
> As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

This was recommended by Jan and the procedure used in other parts of the code.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:31:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
 <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
Message-ID: <Bk1GNLr8K1rN6d6Puz8wVQKeOEUaWvVeK7jiM7wICTY=.fb15a02b-82ec-4c08-9e17-233dfa4fee79@github.com>

On Fri, 28 Oct 2022 16:33:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
>> 
>>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>>> 4138: 
>>> 4139:             if (typeArguments.size() == 2) {
>> 
>> Is this code correct? TemplateProcessor seems to have just one type argument.
>
> Ah - `templateProcessorType` is not what it seems :-)

Renaming. I held off assuming that bike shedding would change it once again.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:41:33 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:41:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
Message-ID: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>

On Fri, 28 Oct 2022 18:45:05 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:
> 
>> 30: 
>> 31: import java.io.IOException;
>> 32: import java.util.*;
> 
> Please do not use import *.

Changing.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:
> 
>> 34: import java.lang.invoke.MethodHandles.Lookup;
>> 35: import java.lang.template.StringTemplate;
>> 36: import java.util.*;
> 
> Another import * here

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
> 
>> 116:      * @since 20
>> 117:      */
>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
> 
> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:
> 
>> 997:      * Promote integral types to int.
>> 998:      */
>> 999:     private static Class<?> promoteIntType(Class<?> t) {
> 
> promoteToIntType ?

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:
> 
>> 1058:             throws StringConcatException
>> 1059:     {
>> 1060:         Objects.requireNonNull(fragments, "fragments is null");
> 
> I think you need to do some defensive copy here
> 
>   ptypes = List.copyOf(pTypes);
> 
> to avoid the types and fragments to be changed at the same time they are checked.

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:41:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:41:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:

> 287:         try {
> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",

This should be a constant (using the class holder idiom or not)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:

> 300: 
> 301:     /**
> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}

Private "method"

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:

> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 324:      */
> 325:     static String interpolate(List<String> fragments, List<Object> values) {

I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:

> 387:             }
> 388:         }
> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));

It seems that IntelliJ was lot when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 19:51:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove .orig file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/20f54dec..347df715

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=02-03

  Stats: 4223 lines in 1 file changed: 0 ins; 4223 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:51:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/util/FormatProcessor.java line 198:

> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
> 197:      */
> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);

`Locale.US` or `Locale.ROOT` ??
see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 19:55:07 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:55:07 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
Message-ID: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>

On Fri, 28 Oct 2022 19:34:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
>> 
>>> 116:      * @since 20
>>> 117:      */
>>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
>> 
>> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.
>
> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Fri Oct 28 20:01:29 2022
From: duke at openjdk.org (Franz =?UTF-8?B?V2lsaGVsbXN0w7Z0dGVy?=)
Date: Fri, 28 Oct 2022 20:01:29 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>

On Fri, 28 Oct 2022 19:21:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
> 
>> 209:     @SuppressWarnings("unchecked")
>> 210:     public static <E> List<E> toList(E... elements) {
>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
> 
> This is List.of(), please use List.of() instead

`List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:

public static <E> List<E> toList(E... elements) {
	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
}

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:01:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
Message-ID: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>

On Fri, 28 Oct 2022 19:51:21 GMT, Franz Wilhelmst?tter <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
>> 
>>> 209:     @SuppressWarnings("unchecked")
>>> 210:     public static <E> List<E> toList(E... elements) {
>>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
>> 
>> This is List.of(), please use List.of() instead
>
> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
> 
> public static <E> List<E> toList(E... elements) {
> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
> }

Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
Using that implementation will avoid a bunch of indirection

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:25:35 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
 <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
Message-ID: <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>

On Fri, 28 Oct 2022 19:52:14 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.
>
> But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

Anyway, i think you are right, this can be public

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Fri Oct 28 20:25:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
Message-ID: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>

On Fri, 28 Oct 2022 18:52:28 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
> 
>> 1040:      * The number of fragments must be one more that the number of ptypes.
>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
> 
> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

Disagree.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
> 
>> 1175:      */
>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
> 
> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:
> 
>> 49:     /**
>> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
>> 51:      * bootstrap method information.
> 
> This comment is quite obscure if you have no idea how it works.
> And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

Deliberate obscure for preview. Once we sort out the functional space you have been looking for, this will likely go away. ProcessorFactory and ProcessorBuilder are a couple of the possibilities.

> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
> 
>> 36: record SimpleStringTemplate(List<String> fragments,
>> 37:                              List<Object> values
>> 38: ) implements StringTemplate {}
> 
> A compact constructor doing defensive copies is missing

The defensive copies are done by the callers.

> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
> 
>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 44: @FunctionalInterface
>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
> 
> The name should be `StringTemplateProcessor`.
> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
> 
> see TemplateProcessor

Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Fri Oct 28 20:25:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
Message-ID: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>

On Fri, 28 Oct 2022 20:01:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
>> 
>>> 1040:      * The number of fragments must be one more that the number of ptypes.
>>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
>> 
>> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public
>
> Disagree.

As i said above, i consider this thread as resolved

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
>> 
>>> 1175:      */
>>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
>> 
>> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not
>
> Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

yes, sorry for the noise.

>> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
>> 
>>> 36: record SimpleStringTemplate(List<String> fragments,
>>> 37:                              List<Object> values
>>> 38: ) implements StringTemplate {}
>> 
>> A compact constructor doing defensive copies is missing
>
> The defensive copies are done by the callers.

In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

>> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
>> 
>>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 44: @FunctionalInterface
>>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
>> 
>> The name should be `StringTemplateProcessor`.
>> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
>> 
>> see TemplateProcessor
>
> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?

People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From redestad at openjdk.org  Fri Oct 28 20:48:10 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Oct 2022 20:48:10 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial
 hash loops
Message-ID: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>

Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.

I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.

Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.

The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.

With the most recent fixes the x64 intrinsic results on my workstation look like this:

Benchmark                               (size)  Mode  Cnt     Score    Error  Units
StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op

Baseline:

Benchmark                               (size)  Mode  Cnt     Score    Error  Units
StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op

I.e. no measurable overhead compared to baseline even for `size == 1`.

The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.

Benchmark for `Arrays.hashCode`:

Benchmark              (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op

Baseline:

Benchmark              (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op


As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

-------------

Commit messages:
 - ws
 - Add ArraysHashCode microbenchmarks
 - Fixed vector loops for int and char arrays
 - Split up Arrays/HashCode tests
 - Fixes, optimized short inputs, temporarily disabled vector loop for Arrays.hashCode cases, added and improved tests
 - typo
 - Add Arrays.hashCode tests, enable intrinsic by default on x86
 - Correct start values for array hashCode methods
 - Merge branch 'master' into 8282664-polyhash
 - Fold identical ops; only add coef expansion for Arrays cases
 - ... and 28 more: https://git.openjdk.org/jdk/compare/303548ba...22fec5f0

Changes: https://git.openjdk.org/jdk/pull/10847/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282664
  Stats: 1129 lines in 32 files changed: 1071 ins; 32 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From luhenry at openjdk.org  Fri Oct 28 20:48:10 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 28 Oct 2022 20:48:10 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <tUUED_AhQ-59DfLrgFc1EijmNCuhz4uF-v15WZGwwQ8=.4e8e62f5-5f27-4a47-a8f0-ebf6adb41e20@github.com>

On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

I did a quick write up explaining the approach at https://gist.github.com/luhenry/2fc408be6f906ef79aaf4115525b9d0c. Also, you can find details in @richardstartin's [blog post](https://richardstartin.github.io/posts/vectorised-polynomial-hash-codes)

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Fri Oct 28 20:48:12 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 28 Oct 2022 20:48:12 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <2URA7qiWBkx-l9U0FfNIBNOVyDeToiv8x0fmhHKhGOs=.edad5b57-0986-41ca-83f1-256021f5ec11@github.com>

On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

While there are some incompleteness (no vectorization of byte and short arrays) I think this is ready to begin reviewing now. Implementing vectorization properly for byte and short arrays can be done as a follow-up, or someone might now a way to sign-extend subword integers properly that fits easily into the intrinsic implementation here. 

Porting to aarch64 and other platforms can be done as follow-ups and shouldn't block integration.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Fri Oct 28 21:59:53 2022
From: duke at openjdk.org (Justin Lu)
Date: Fri, 28 Oct 2022 21:59:53 GMT
Subject: RFR: 8295670: Remove duplication in java/util/Formatter/Basic*.java
Message-ID: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>

Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh

Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.

Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

-------------

Commit messages:
 - Add previous hard coded change into template
 - Remove duplicated methods, put into Basic
 - Toggle -nel for gen script

Changes: https://git.openjdk.org/jdk/pull/10910/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10910&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295670
  Stats: 29666 lines in 22 files changed: 1531 ins; 27888 del; 247 mod
  Patch: https://git.openjdk.org/jdk/pull/10910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10910/head:pull/10910

PR: https://git.openjdk.org/jdk/pull/10910

From bchristi at openjdk.org  Fri Oct 28 22:11:27 2022
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 28 Oct 2022 22:11:27 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <KwHWlT4wYd9Z0nTPLOG_GMVv6iUdRmivM6ENIP3W9hw=.36e4de60-9c43-4d4c-9246-b41fd26b31bf@github.com>

On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

Looks good. That sure was a lot of extra newlines!

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10910

From naoto at openjdk.org  Fri Oct 28 22:46:49 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Oct 2022 22:46:49 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <3nb6Mh7G9rTwkyxe9aF4mZCS9td26kHx_XkwMpksl98=.12751398-6095-44a9-a24b-da877874338d@github.com>

On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

test/jdk/java/util/Formatter/Basic-X.java.template line 1612:

> 1610:         list.remove("America/WhiteHorse");
> 1611:         list.remove("Canada/Yukon");
> 1612:         ids = list.toArray(new String[list.size()]);

It's not your change but I just noticed this. Since we specifically test only for `CLDR` provider (as in `BasicTestLauncher`), I wonder we could remove this portion. Even if we do need this piece, it could be simplified as:

ids = Arrays.stream(ids).filter(tz -> !tz.equals(...)).toArray(String[]::new)

-------------

PR: https://git.openjdk.org/jdk/pull/10910

From smarks at openjdk.org  Fri Oct 28 23:20:09 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Oct 2022 23:20:09 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
Message-ID: <OaXRh5uLiYqRtZH1QiJfxGdESxp05fYRmJzvFqAH7C4=.aa2da655-11e4-4433-a05f-6ecbea3f7a80@github.com>

On Wed, 12 Oct 2022 13:26:29 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes according to review
>   
>   1. Reduce duplication in tests
>   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>   3. Simplify documentation for shuffle(List, Random) to avoid duplication.

I'm having difficulty imagining how `SequencedCollection::replaceAll` could work or be useful. Obviously it's on List already. It could be added to Deque, because like List, its elements are explicitly positioned (positioning via the API, not by value) and more importantly, the elements are unconstrained. That is, an element could be replaced by any other value and not affect or be affected by any other elements in the collection.

However, `LinkedHashSet` is a `Set` and so has a unique-elements constraint. What should `replaceAll` do if the replacement element already exists in the set? (For a shuffle operation, the first swap operation by definition replaces an element with another element that's somewhere else in the set, so this issue arises immediately.) Maybe the unique-elements constraint is suspended for the duration of the call, and it's only enforced at the end of the call. Conceptually that might work, but I have trouble envisioning an implementation that can do that.

A `replaceAll` operation on a `NavigableSet` seems right out. The elements are positioned according to their sort order, so there's no notion of updating an element "in-place" at all.

The comparison to `Map::replaceAll` doesn't seem to help; that method replaces only the values of the map entries, which are unconstrained. All of the constraints of maps (uniqueness, sort order) are on the keys.

For these reasons I don't think it makes sense to couple this PR to JEP 431.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From duke at openjdk.org  Fri Oct 28 23:54:22 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 23:54:22 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
Message-ID: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>

On Fri, 28 Oct 2022 19:51:49 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove .orig file

src/java.base/share/classes/java/util/FormatterBuilder.java line 470:

> 468:      */
> 469:     MethodHandle build() {
> 470:         Formatter.parse(format);

`Formatter.parse` is called here, and then again a few lines down.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jjg at openjdk.org  Sat Oct 29 00:05:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 29 Oct 2022 00:05:32 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <r_58JHoKmjUmSoO1PboxKdQoV8yJ3nwjDn_KIIr5o7k=.13c13918-f42e-4f5b-9557-6894e2b301fb@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

The changes in `jdk.compiler` and `jdk.javadoc` seem innocuous enough.  Because of the bootstrap issue/latency, we'll have to wait before we can update to non-deprecated code.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From stuart.marks at oracle.com  Sat Oct 29 00:16:06 2022
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 28 Oct 2022 17:16:06 -0700
Subject: [External] : Re: New candidate JEP: 431: Sequenced Collections
In-Reply-To: <1390728427.28765698.1666105496447.JavaMail.zimbra@u-pem.fr>
References: <20221011231719.86821547E2D@eggemoggin.niobe.net>
 <1020834747.25340915.1665735651688.JavaMail.zimbra@u-pem.fr>
 <65da58eb-6d9b-1d3b-50c4-6a5ea9e6aafc@oracle.com>
 <1390728427.28765698.1666105496447.JavaMail.zimbra@u-pem.fr>
Message-ID: <fb5c9727-9509-7588-afe3-e19876faa0e3@oracle.com>



On 10/18/22 8:04 AM, forax at univ-mlv.fr wrote:
>> Introduction of new types always poses a dilemma for library maintainers. They
>> can
>> move forward aggressively and embrace new features, or they can remain on older
>> releases in order to reach a broader audience. That's not a reason to avoid
>> introducing new types.
> 
> I agree in absolute, but in this specific case you want to introduce interfaces deep into the existing hierarchy of interfaces, not on the top.
> The introduction of CharSequence has been painful and very slow, that interface was added in 1.4 but we had to wait 9 more than 10 years later to have parseInt() that takes a CharSequence.
> As an application developer, a decade is the kind of time i will have to wait before i can use a sequenced collection.
> 
> Adding default methods is far faster in term of adoption, computeIfAbsent or removeIf were available at the time of the release of 1.8.
> Default methods have issues too, it only works if a good default implementation exists.

You seem to be talking about introduction of new types in opposition to introduction 
of default methods. This proposal does both. Clearly if you're using an old library, 
you can't use new types with it. But if the old library consumes or produces say, a 
List, new applications can definitely use all the default methods added to List by 
this proposal.

We've previously discussed adding new default methods (getFirst, reversed) to some 
existing type (like Collection) instead of on a new type. The problem is that they 
appear on all collections, even those that have no encounter order. Their 
specifications would thus be so weak as to be meaningless. That's the justification 
for adding a new type: to give these methods meaning.

>>> - LinkedHashMap can be tweaked in two ways, by passing an access order as 3rd
>>> parameter of the constructor or by overriding removeEldesEntry(), in both cases
>>> the resulting LinkedHashMap is at odds with the contract of SequencedMap but
>>> the compiler will happily allow to see those LinkedHashMap as SequencedMap.
>>
>> SequencedMap specifies that entries have an encounter order but it doesn't make
>> any
>> requirements on how that order is established. LinkedHashMap's access-order mode
>> is
>> unusual in that it specifies that specific methods additionally have the side
>> effect
>> of reordering the relevant entry. The removeEldestEntry() method modifies the
>> behavior of mapping-insertion methods to optionally remove the first ("eldest")
>> entry. Neither of these behaviors conflicts with anything in SequencedMap.
> 
> It conflicts with the idea of the first element (or last element)
>    SequencedSet set = ...
>    var first = set.getFirst();
>    assertNotNull(first);
>    set.add("foo");
>    var first2 = set.getFirst();
>    assertEquals(first, first2);   // should always be true, right ?

(LinkedHashSet doesn't have a removeEldestEntry() method; that's only on 
LinkedHashMap. But let's consider the example to be rewritten as if it were about 
LinkedHashMap, or a SequencedSet built from the keySet of a LinkedHashMap.)

See draft specification here:

https://github.com/openjdk/jdk/pull/7387/files#diff-be823ac1fb09a9858a40bdd29359911e534f5d9d3079e69ed31a34e37f72c7a0

There is a definition of encounter order, but there is no specification of how the 
encounter order is established or how it's modified. That's left to implementations 
and subtypes.

This example 1) gets the first element, 2) adds another element, and 3) gets the 
first element again. Step 2 is a modification to the collection, so there's no basis 
for asserting that the element obtained in step 1 always equals the element obtained 
in step 3.

In particular, LinkedHashMap's "removeEldestEntry" feature says that add() 
potentially has additional side effects beyond adding the argument element, 
including of course removing the first element.

Also, in the example, if SequencedSet is a TreeSet<String> containing "x", then 
adding "foo" quite sensibly changes the first element between steps 1 and 3.

>>> - LinkedHashMap/LinkedHashSet are dinosaurs, there are more efficient
>>> implementations of the concepts of ordered set / ordered map both in term of
>>> memory footprint and runtime execution, so adding new interfaces without
>>> exploring new implementations using Valhalla value class and in relation with
>>> the Collection Literal JEP seems premature to me.
>>
>> LinkedHashMap and LinkedHashSet are in fact used fairly frequently. They're not
>> used
>> as much as HashMap, but they're used more than ArrayDeque or TreeMap. Presumably
>> this is because people find LinkedHashMap/Set useful and that the overhead
>> compared
>> to their non-linked counterparts is acceptable for the additional services they
>> provide.
>>
>> The performance and footprint of LinkedHashMap/Set are not impacted either way
>> by
>> the JEP, nor are any potential future performance improvements (including those
>> that
>> might arise because of Valhalla) precluded by the JEP.
> 
> I don't disagree with all you say above, i'm saying that with Valhalla, we need to explore implementations of HashMap based on open addressing to get better cache performance.
> So adding addFirst() to LinkedHashMap now, is a risk.

As the LinkedHashMap implementation stands today (prior to JEP 431) it needs to 
perform a variety of operations that affect the order of the elements. The 
addFirst() method is a new operation, but it's only a small amount of additional 
work, given that there are already other operations that operate on both ends.

In a hypothetical future open-addressed Map, there would need to be some additional 
data structure (likely an array?) that maintains the encounter order. This structure 
would need to support various element shifting and copying operations to maintain 
the ordering; consider what would need to happen with a get() operation on an 
access-ordered map. I don't see any problem with implementing an addFirst() 
operation on this structure.

> Also, addFirst on a sequenced collection is a dangerous method, exactly like List.get() is, depending on the implementation the worst case complexity can be either O(1) or O(n).
> I believe we will all live in a better place if we do not add new methods with such "complexity range".

Not the same at all. The problem with LinkedList.get(i) is that people put it in a 
for-loop over int indexes, which seems like it should be O(n), but as we know it's 
O(n^2). That occurs a lot more frequently than indexed add() or remove().

s'marks


From bpb at openjdk.org  Sat Oct 29 00:54:25 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 29 Oct 2022 00:54:25 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
Message-ID: <il5ztjDrYbky49NlUBZpZquAiVO-XGt28caT-ZEBklE=.f9858114-0dcd-45ac-a432-9f9ed78ac936@github.com>

On Wed, 12 Oct 2022 13:26:29 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Java 17 added RandomGenerator interface. However, existing method Collections.shuffle accepts old java.util.Random class. While since Java 19, it's possible to use Random.from(RandomGenerator) wrapper, it would be more convenient to provide direct overload shuffle(List<?> list, RandomGenerator rnd).
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes according to review
>   
>   1. Reduce duplication in tests
>   2. Use JumpableGenerator#copy() instead of create(1) in tests, as according to the spec, seed can be ignored
>   3. Simplify documentation for shuffle(List, Random) to avoid duplication.

`jdk.test.lib.RandomFactory` can be used to generate a reproducible sequence of random numbers. An example of its use may be seen for example in `java/nio/file/Files/CopyAndMove.java`

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From duke at openjdk.org  Sat Oct 29 01:03:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Sat, 29 Oct 2022 01:03:23 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>

On Fri, 28 Oct 2022 19:13:54 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
> 
>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 322:      */
>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
> 
> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.

The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mpowers at openjdk.org  Sat Oct 29 02:11:06 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 29 Oct 2022 02:11:06 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
Message-ID: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>

https://bugs.openjdk.org/browse/JDK-8293412

-------------

Commit messages:
 - Merge
 - second iteration
 - Merge
 - first iteration

Changes: https://git.openjdk.org/jdk/pull/10716/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10716&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293412
  Stats: 31 lines in 10 files changed: 2 ins; 17 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10716.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10716/head:pull/10716

PR: https://git.openjdk.org/jdk/pull/10716

From mpowers at openjdk.org  Sat Oct 29 02:11:06 2022
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 29 Oct 2022 02:11:06 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <fbj4q2Tf-m4Bzf6D1BebNCUonpzi3m34-C12ytaKakQ=.5c2d10dd-2b65-4434-b4a5-0529228b629b@github.com>

On Fri, 14 Oct 2022 21:49:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293412

No failures were noticed during mach5 and jtreg testing.

-------------

PR: https://git.openjdk.org/jdk/pull/10716

From xuelei at openjdk.org  Sat Oct 29 04:22:15 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 29 Oct 2022 04:22:15 GMT
Subject: RFR: JDK-8293412 Remove unnecessary java.security.egd overrides
In-Reply-To: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
References: <SFLNrBsaLSK5N6WUlYMLRAthEAwQUjdPb3Rsw-krGBM=.8341aa49-e48f-49c4-828d-73c185ce332f@github.com>
Message-ID: <iUYqoCVP_PXYF6BLYtwpaYIqOSgxRbSOXkJvv75fhgE=.4dd85e6b-a439-463e-bb7a-f915749fa58b@github.com>

On Fri, 14 Oct 2022 21:49:07 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8293412

I think it is a good clean up so that the default one get used in testing.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10716

From duke at openjdk.org  Sat Oct 29 05:25:27 2022
From: duke at openjdk.org (duke)
Date: Sat, 29 Oct 2022 05:25:27 GMT
Subject: Withdrawn: 8291915: jpackage: use multiple Features in MSI installer
In-Reply-To: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
References: <-4YIBqE_eqivCDLzL-1iwmZ0iDusC1qP1EA9iX2ZMnE=.38379074-0205-4ca2-9c1f-119e43b71ad6@github.com>
Message-ID: <DM0c8uyEPidQz-PZzqUiQNWJTJcyqVfezoj0PWljJWs=.161b2733-08a4-4ed2-90a6-806a0e7f176e@github.com>

On Thu, 4 Aug 2022 17:00:38 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> This change splits existing single Feature `DefaultFeature` into 3 different feautures:
> 
>  - `DefaultFeature_Files`: application and runtime files
>  - `DefaultFeature_Shortcuts`: application Desktop and Start Menu shortcuts
>  - `DefaultFeature_FileAssociations`: File Association components
> 
> These 3 Features are nested under the existing top-level Feature.
> 
> Currently the use of File references in Shortcuts and FileAssociations causes ICE69 MSI warnings like this one:
> 
> 
> warning LGHT1076 : ICE69: Mismatched component reference. Entry 'reg12F3244EB2A37CCDB282E815ADFD174A' of the Registry table belongs to component 'cprogid9f99d1ff794e3df6bee07ba710a5501a'. However, the formatted string in column 'Value' references file 'file9846f81ce394345095918903022c1072' which belongs to component 'cfile9846f81ce394345095918903022c1072'. Components are in the same feature.
> 
> 
> This warning seems to be completely harmless when the File, referenced from the Shortcut or Verb elements, belongs to the same Feature. Though, this warning becomes and error when the File belongs to other Feature.
> 
> To solve this problem for Shortcut and Verb - install-time `ARPMAINLAUNCHERLOCATION` is introduced, that points to the main application launcher in a form: `[INSTALLDIR]launcher.exe`. With such property no `ICE69` warnings are raised.
> 
> It appeared that such solution is not possible for the Shortcut Icon reference, that points to the icon file. Instead this icon file is additionally included into Shortcuts ComponentGroup. This way `ICE69` warning is raised (as before) instead of an error.
> 
> Added test uses `ADDLOCAL` options to test the installation of Features separately. To pass this option to installation handlers I've added it to `JPackageCommand`, this seemed to be the easiest way to pass it  without changing handler signatures.
> 
> It appeared, that default checks in `PackageTest` assume "all-or-nothing" installation scenario and contain non-trivial logic to determine which checks (files, desktop, FA) to run. I've iterated multiple times on this logic adding more flags (that can be controllable from the test itself) and ended up with helper methods in `WindowsHelper` that checks install arguments on `JPackageCommand` assuming `ADDLOCAL` and known Feature names there. This solution, while being the simplest of all attempts, is quite clunky, it may be better to introduce more fine-grained control over these checks from the test itself (such change is potentially disruptive to the test-suite).
> 
> It was also discovered, that `ADDLOCAL` option is not supported with `unpack` mode, and separate Features are not currently checked in this mode.
> 
> Testing:
> 
>  - `WinFeaturesTest` that installs and checks Features one by one
>  - `FileAssociationsTest` and `WinShortcutTest` test runs with `install` enabled

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9751

From duke at openjdk.org  Sat Oct 29 06:31:32 2022
From: duke at openjdk.org (duke)
Date: Sat, 29 Oct 2022 06:31:32 GMT
Subject: Withdrawn: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <a56dLeCncxGNpc5R7tl1V2_8vAfns5MfmJnq-vT-dTU=.24511af2-9118-4cd0-b930-f1d91e5311ac@github.com>

On Sun, 30 May 2021 17:30:56 GMT, Markus KARG <duke at openjdk.org> wrote:

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/4263

From alanb at openjdk.org  Sat Oct 29 07:41:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Oct 2022 07:41:16 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v2]
In-Reply-To: <4mP7fZpQH-G3crTV1mAn_HhQC3fxrdHAWmsJAacwrQg=.6050f895-98fa-4cfe-af42-4c5ec6ee473b@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <7z5iMCLrtInfVGtXPeZdOsOtjUGMcMnxGoZZBFu6PTw=.ded73d3b-b3a6-4613-af6a-42a9a5a9f62a@github.com>
 <SHtOK11pJqLUuVEcuZvZFz1WPXWPkRTCiQRH4jr9wXo=.f4c673db-6e60-40bc-90c8-8752cc504ed1@github.com>
 <2D00jTeITBJHTxS6bpYqVAD0md2fSu2TlCfNXAVBLqQ=.7e395c48-eed4-4c52-8d2c-d273e9c8384f@github.com>
 <4mP7fZpQH-G3crTV1mAn_HhQC3fxrdHAWmsJAacwrQg=.6050f895-98fa-4cfe-af42-4c5ec6ee473b@github.com>
Message-ID: <DM-Oxg2PKvGMVD9dO9Q7tviVPY7ZLtJ54iTnISRdKYs=.8175996f-134a-404c-92c6-0a27ed0baec3@github.com>

On Sun, 23 Oct 2022 08:40:35 GMT, Markus KARG <duke at openjdk.org> wrote:

> Silly me, you are certainly right! I have modified the code as you proposed, so now we should be safe, finally. :-)

The updated version (7350a533) looks safe but it makes for a more complicated transferTo so it would be good to see updated performance results. One thing to look at is dropping the allocation of the new buffer after the writing of the buffered bytes. The transferTo method will read to EOF and should be rare to continue reading after EOF - if there is reading after EOF then this should cause the internal buffer to resize. The optimization is limited to the case where BIS is not extended so there are no subclasses that can observe that the internal buf has shrunk.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From alanb at openjdk.org  Sat Oct 29 08:02:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Oct 2022 08:02:20 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <qii389Hknfxf1NLNTj4D7Tqef0WC_tens2e8UrJWxu0=.34de9779-e874-4e53-bc89-6391101652b3@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <cDsvdrqT0X5dXPyOyQ6j21MmSZzOx9I2Y2NCn9DfZ2Q=.0aee78af-1541-49af-9bd6-35145a3afc95@github.com>
 <qii389Hknfxf1NLNTj4D7Tqef0WC_tens2e8UrJWxu0=.34de9779-e874-4e53-bc89-6391101652b3@github.com>
Message-ID: <-48VMcPym9w9jDnxkf2UTy7qFEDZwCR4PWgwtlroIiI=.bb3f67f1-e912-4e59-aaa5-25b32c062763@github.com>

On Fri, 28 Oct 2022 07:21:05 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Good suggestion!
> And the `jdk_vector_sanity` test group had been added.

In general, running a few fast sanity tests from several areas in tier1 seems a good idea. Having test lists in the TEST.group files isn't very appealing as they easily get out of the sync with the tests in the tree. I realise there are already some test lists in both the hotspot and jdk TEST.groups but it feels like it needs something better so that RunTests.gmk/jtreg can select the sanity tests to run. This is not an objection to this change proposed here, just a comment that this type of configuration is annoying to maintain.

-------------

PR: https://git.openjdk.org/jdk/pull/10879

From duke at openjdk.org  Sat Oct 29 09:28:25 2022
From: duke at openjdk.org (Piotr Tarsa)
Date: Sat, 29 Oct 2022 09:28:25 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <2URA7qiWBkx-l9U0FfNIBNOVyDeToiv8x0fmhHKhGOs=.edad5b57-0986-41ca-83f1-256021f5ec11@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <2URA7qiWBkx-l9U0FfNIBNOVyDeToiv8x0fmhHKhGOs=.edad5b57-0986-41ca-83f1-256021f5ec11@github.com>
Message-ID: <Ce10BnzY_aCp7BNVY8VHOKJX8YgiYCQAGRR5G_bZcUw=.622d68ec-9453-4948-b043-ad5f392f7e6e@github.com>

On Fri, 28 Oct 2022 20:43:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Porting to aarch64 and other platforms can be done as follow-ups and shouldn't block integration.

I'm not an expert in JVM internals, but there's an already seemingly working String.hashCode intrinsification that's ISA independent: https://github.com/openjdk/jdk/pull/6658 It operates on higher level than direct assembly instructions, i.e. it operates on the ISA-independent vector nodes, so that all hardware platforms that support vectorization would get speedup (i.e. x86-64, x86-32, arm32, arm64, etc), therefore reducing manual work to get all of them working. I wonder why that pull request got no visible interest?

Forgive me if I got something wrong :)

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Sat Oct 29 10:38:08 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 29 Oct 2022 10:38:08 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <VFGgK3aQQYBr5ADxe8Eq6RmVVg4TVtbCuju6-ZtJd04=.ad4614ef-f500-44df-8309-e47188bcf60c@github.com>

On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

> > Porting to aarch64 and other platforms can be done as follow-ups and shouldn't block integration.
> 
> I'm not an expert in JVM internals, but there's an already seemingly working String.hashCode intrinsification that's ISA independent: #6658 It operates on higher level than direct assembly instructions, i.e. it operates on the ISA-independent vector nodes, so that all hardware platforms that support vectorization would get speedup (i.e. x86-64, x86-32, arm32, arm64, etc), therefore reducing manual work to get all of them working. I wonder why that pull request got no visible interest?
> 
> Forgive me if I got something wrong :)

I'll have to ask @merykitty why that patch was stalled. Never appeared on my radar until now -- thanks!

The approach to use the library call kit API is promising since it avoids the need to port.  And with similar results. I'll see if we can merge the approach here of having a shared intrinsic for `Arrays` and `String`, and bring in an ISA-independent backend implementation as in #6658

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From jpai at openjdk.org  Sat Oct 29 11:58:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 11:58:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
 <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
Message-ID: <FfQ1_F-GP2tNy3JiwtPN-BLBK6E8b636tX8T1Vfl_5U=.a3f9410a-72fd-4dc2-87d8-35bf91897af9@github.com>

On Thu, 27 Oct 2022 11:24:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> How about `_unused` or `_unused1`, `_unused2` then in the meantime?
>
> I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

Hello Daniel, I think calling it `unused` is fine. I did a quick search in the JDK code and we already have places where we use such a variable name for similar usecase. I don't see the need for using an underscore as a prefix, but it is OK with me if you and others prefer to use it.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From jpai at openjdk.org  Sat Oct 29 12:05:07 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 12:05:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
Message-ID: <zzbb3oae_BJ3Xn5x5xJB3tfugG41Om9Mv6LhbXOKH1c=.9ac9052a-8d9f-4450-95df-599ebabc6476@github.com>

On Wed, 26 Oct 2022 17:51:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
>> 
>> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
>> 
>> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.
>
> One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

I think `URL.of(URI, URLStreamHandler)` is fine.

As for `URL.of(URI)`, whose implementation I suspect will just do `uri.toURL()` on the passed `URI`, I don't think we need it. It might add to unnecesary confusion on whether/when to use `URL.of(URI)` and when to use `URI.toURL()`

In the case of `URL.of(URI, URLStreamHandler)` it's pretty clear that you use it (only) when you have a specific `URLStreamHandler` to use for the constructed `URL`.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From aivanov at openjdk.org  Sat Oct 29 12:14:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 12:14:25 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <rzIw7fkMmSiQ4HJygtWh3SxVIIZg4QY0nvByxOYUyGs=.b878366e-a60f-410f-94ae-47b486f4e7b5@github.com>

On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:
> 
>> 132: 
>> 133: #SyncResolverImpl exceptions
>> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020
> 
> prob. unnecessary

This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough.

-------------

PR: https://git.openjdk.org/jdk/pull/10792

From duke at openjdk.org  Sat Oct 29 12:31:41 2022
From: duke at openjdk.org (Markus KARG)
Date: Sat, 29 Oct 2022 12:31:41 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v5]
In-Reply-To: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
Message-ID: <DTaMaHL73PaZ5AnW9pT9fmx2_xPobPPMuneftJ1VoDY=.ed03db04-2fa3-4b7a-8969-2b3751d1a8ab@github.com>

> This PR implements JDK-8294696.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  No immediate buffer resize; in the rare case of read-past-EOF automatic buffer grow will happen anyways

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10525/files
  - new: https://git.openjdk.org/jdk/pull/10525/files/7350a533..9c2f502c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=03-04

  Stats: 16 lines in 1 file changed: 0 ins; 15 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10525/head:pull/10525

PR: https://git.openjdk.org/jdk/pull/10525

From aivanov at openjdk.org  Sat Oct 29 13:22:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 13:22:09 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Trailing spaces in `LocaleNames_*` are only in two files:

- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties`
- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties`

It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one.

src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238:

> 236: cpp=Kreolisch-Portugiesische Sprache
> 237: crh=Krimtatarisch
> 238: crp=Kreolische Sprache\u0020

I'm pretty sure locale names shouldn't contain trailing spaces.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10792

From alanb at openjdk.org  Sat Oct 29 14:28:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Oct 2022 14:28:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

src/java.base/share/classes/java/net/URL.java line 133:

> 131:  * specified. The optional fragment is not inherited.
> 132:  *
> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>

Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?

src/java.base/share/classes/java/net/URL.java line 157:

> 155:  * The URL constructors are specified to throw
> 156:  * {@link MalformedURLException} but the actual parsing/validation
> 157:  * that are performed is implementation dependent. Some parsing/validation

"the ... are performed" -> "the ... is performed".

src/java.base/share/classes/java/net/URL.java line 166:

> 164:  * The {@code java.net.URL} constructors are deprecated.
> 165:  * Developers are encouraged to use {@link URI java.net.URI} to parse
> 166:  * or construct any {@code URL}. In cases where an instance of {@code

"any URL" -> "a URL" or "all URLs".

src/java.base/share/classes/java/net/URL.java line 168:

> 166:  * or construct any {@code URL}. In cases where an instance of {@code
> 167:  * java.net.URL} is needed to open a connection, {@link URI} can be used
> 168:  * to construct or parse the URL string, possibly calling {@link

I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString.

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL of(URI uri, URLStreamHandler streamHandler)

The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion.

src/java.base/share/classes/java/net/URL.java line 885:

> 883: 
> 884:             @SuppressWarnings("deprecation")
> 885:             var result = new URL("jrt", host, port, file, null);

The URL scheme for jrt does have a port so we should look at that some time.

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From qamai at openjdk.org  Sat Oct 29 15:16:34 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 29 Oct 2022 15:16:34 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <Jbi24BW3LHK4ruNJBOtoKZ-aT3Ougvzumod3v8zP5nA=.dcde376e-36f7-43ec-b2fc-421e1a181012@github.com>

On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

I am planning to submit that patch after finishing with the current under-reviewed PRs. That patch was stalled because there was no node for vectorised unsigned cast and constant values. The first one has been added and the second one may be worked around as in the PR. I also thought of using masked loads for tail processing instead of falling back to scalar implementation.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Sat Oct 29 18:09:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 29 Oct 2022 18:09:25 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <fAtOoLlIqFr9KvcEARECu9ZoEIvOY_TWjEgz3VIP_6U=.d7121113-1ead-47a3-a447-41cea95878a1@github.com>

On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu <duke at openjdk.org> wrote:

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

test/jdk/java/util/Formatter/Basic-X.java.template line 1608:

> 1606:         // time zone ID. See JDK-8254865.
> 1607:         final List<String> list =  new ArrayList<String>();
> 1608:         Collections.addAll(list, ids);

I think

final List<String> list =  new ArrayList<>(Arrays.asList(ids));

is going to be faster than

final List<String> list =  new ArrayList<String>();
Collections.addAll(list, ids);

Alternatively you can contruct presized ArrayList.

test/jdk/java/util/Formatter/Basic-X.java.template line 1612:

> 1610:         list.remove("America/WhiteHorse");
> 1611:         list.remove("Canada/Yukon");
> 1612:         ids = list.toArray(new String[list.size()]);

ids = list.toArray(new String[0]);

is likely to be faster, see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

-------------

PR: https://git.openjdk.org/jdk/pull/10910

From serb at openjdk.org  Sat Oct 29 23:12:25 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 29 Oct 2022 23:12:25 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
Message-ID: <1INzCtXMkzWk2GmbTkXaoP1CAeCgNLdvsWtfwBdcES0=.3b35c7d1-32c0-4422-82a9-e38790b3db3a@github.com>

On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Add jdk_vector_sanity test group
>  - Merge branch 'master' into JDK-8295970
>  - Revert changes in test.yml
>  - 8295970: Add jdk_vector tests in GHA

What about possibility to run additional group of the test by passing somehow the name of group to the GA, via label or via /test cmd, or via parameter to the specific task in GA?

-------------

PR: https://git.openjdk.org/jdk/pull/10879

From jiefu at openjdk.org  Sun Oct 30 12:07:25 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 30 Oct 2022 12:07:25 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA
In-Reply-To: <-48VMcPym9w9jDnxkf2UTy7qFEDZwCR4PWgwtlroIiI=.bb3f67f1-e912-4e59-aaa5-25b32c062763@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <cDsvdrqT0X5dXPyOyQ6j21MmSZzOx9I2Y2NCn9DfZ2Q=.0aee78af-1541-49af-9bd6-35145a3afc95@github.com>
 <qii389Hknfxf1NLNTj4D7Tqef0WC_tens2e8UrJWxu0=.34de9779-e874-4e53-bc89-6391101652b3@github.com>
 <-48VMcPym9w9jDnxkf2UTy7qFEDZwCR4PWgwtlroIiI=.bb3f67f1-e912-4e59-aaa5-25b32c062763@github.com>
Message-ID: <oNKudcYJnA7jZYGUe1jBNtwsfkOIdw3aNjBSda-FmEc=.c7511871-a2dc-4da7-ae3c-5c82c46a843c@github.com>

On Sat, 29 Oct 2022 07:58:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I realise there are already some test lists in both the hotspot and jdk TEST.groups but it feels like it needs something better so that RunTests.gmk/jtreg can select the sanity tests to run.

Thanks @AlanBateman for this comment.
Is there an existing example to follow?
Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10879

From jiefu at openjdk.org  Sun Oct 30 12:19:34 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 30 Oct 2022 12:19:34 GMT
Subject: RFR: 8295970: Add jdk_vector tests in GHA [v2]
In-Reply-To: <1INzCtXMkzWk2GmbTkXaoP1CAeCgNLdvsWtfwBdcES0=.3b35c7d1-32c0-4422-82a9-e38790b3db3a@github.com>
References: <d4UcH352Dt15hcfRCSPsqBMqpbZEBU7cnxzmKU-hnNg=.a9b8f64a-83f5-47a0-a7bb-51ce094c0275@github.com>
 <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com>
 <1INzCtXMkzWk2GmbTkXaoP1CAeCgNLdvsWtfwBdcES0=.3b35c7d1-32c0-4422-82a9-e38790b3db3a@github.com>
Message-ID: <yv2VWqHf32GaRecTlMUZ5PFuoFs8bdrysCQkt78hROI=.5035e8e6-59a8-4ec0-a745-e068d59628d3@github.com>

On Sat, 29 Oct 2022 23:08:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> What about possibility to run additional group of the test by passing somehow the name of group to the GA, via label or via /test cmd, or via parameter to the specific task in GA?

Well, it sounds good to run specific tests via label or /test cmd.
However, if the vector api tests are OK to be added in tier1 I think it's fine to run them in GHA directly.

Maybe, we can implement this feature in the future not only for vector api tests but also for other tests too.

-------------

PR: https://git.openjdk.org/jdk/pull/10879

From redestad at openjdk.org  Sun Oct 30 19:21:28 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 30 Oct 2022 19:21:28 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <Jbi24BW3LHK4ruNJBOtoKZ-aT3Ougvzumod3v8zP5nA=.dcde376e-36f7-43ec-b2fc-421e1a181012@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <Jbi24BW3LHK4ruNJBOtoKZ-aT3Ougvzumod3v8zP5nA=.dcde376e-36f7-43ec-b2fc-421e1a181012@github.com>
Message-ID: <pzydCgQE-XPK_4e5czzPm0Vk6EGcJ8TdDTIaIWSVt6o=.7874752f-be8c-42bb-af16-de78b928b975@github.com>

On Sat, 29 Oct 2022 15:11:56 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I am planning to submit that patch after finishing with the current under-reviewed PRs. That patch was stalled because there was no node for vectorised unsigned cast and constant values. The first one has been added and the second one may be worked around as in the PR. I also thought of using masked loads for tail processing instead of falling back to scalar implementation.

Ok, then I think we might as well move forward with this enhancement first. It'd establish some new tests, microbenchmarks as well as unifying the polynomial hash loops into a single intrinsic endpoint - while also putting back something that would be straightforward to backport (less dependencies on other recent enhancements). Then once the vector IR nodes have matured we can easily rip out the `VectorizedHashCodeNode` and replace it with such an implementation. WDYT?

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From mik3hall at gmail.com  Sun Oct 30 21:42:03 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 30 Oct 2022 16:42:03 -0500
Subject: Jpackage OS/X DMG install Application folder alias name
 incorrectly shows as path with /
In-Reply-To: <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>
References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
 <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>
Message-ID: <CD11A95E-41FF-4E92-888E-F31610259F38@gmail.com>



> On Oct 26, 2022, at 7:55 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> I was looking to see what any other dmg?s I have do to handle this. Not many do. But those usually seem to use a smaller background image and icons. 
> I may look at that to see if I can manage something like that.

I made some changes that I think might address this. I tried to make the changes as trivial as possible.

The only change to java is in MacDmgBundler.java, the prepareDMGSetupScript method. I added?

        List <String> dmgContent = DMG_CONTENT.fetchFrom(params);
        if (dmgContent.size() > 0) {
        	data.put("DEPLOY_ICON_SIZE", "64");
        }
        else {
        	data.put("DEPLOY_ICON_SIZE", "128");        
        }

I tried counting files in volumePath first but got a FileNotFoundException. Possibly actually a privilege access error?

I obviously added DEPLOY_ICON_SIZE to the AppleScript and changed some spacing and sizing. I wanted to be able to comfortably show up to four additional files without scrolling.

I also put in something for /Applications. I simply hard coded it to ?Applications?. This seemed the most straight forward trivial way to do this. Unless someone indicates where it is or might be something other than Applications.

I put screenshots of the before and after DMG windows at http://mikehall.pairserver.com/DMG_windows.dmg <http://mikehall.pairserver.com/DMG_windows.dmg>
The only after appearance drawback is extra white space at the bottom of the application only window. This could be fairly easy to correct but isn?t really that bad looking.

I appreciate the jpackage people implementing this feature and would appreciate it if they consider this, essentially, cosmetic change.

Thanks.

I mentioned this on the javafx list indicating I had discovered you could use a custom background image for the windows. I noticed in the verbose output today that jpackage indicates it currently supports this feature with a correctly named file in the resource directory. So doing anything external would be unncecessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221030/018ec262/attachment.htm>

From qamai at openjdk.org  Mon Oct 31 02:49:24 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 31 Oct 2022 02:49:24 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>

On Tue, 25 Oct 2022 10:37:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

I agree, please go ahead, I leave some comments for the x86 implementation. Thanks.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3358:

> 3356:   movl(result, is_string_hashcode ? 0 : 1);
> 3357: 
> 3358:   // if (cnt1 == 0) {

You may want to reorder the execution of the loops, a short array suffers more from processing than a big array, so you should have minimum extra hops for those. For example, I think this could be:

    if (cnt1 >= 4) {
        if (cnt1 >= 16) {
            UNROLLED VECTOR LOOP
            SINGLE VECTOR LOOP
        }
        UNROLLED SCALAR LOOP
    }
    SINGLE SCALAR LOOP

The thresholds are arbitrary and need to be measured carefully.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3374:

> 3372: 
> 3373:   // int i = 0;
> 3374:   movl(index, 0);

`xorl(index, index)`

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3387:

> 3385:   for (int idx = 0; idx < 4; idx++) {
> 3386:     // h = (31 * h) or (h << 5 - h);
> 3387:     movl(tmp, result);

If you are unrolling this, maybe break the dependency chain, `h = h * 31**4 + x[i] * 31**3 + x[i + 1] * 31**2 + x[i + 2] * 31 + x[i + 3]`

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3418:

> 3416:   // } else { // cnt1 >= 32
> 3417:   address power_of_31_backwards = pc();
> 3418:   emit_int32( 2111290369);

Can this giant table be shared among compilations instead?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3484:

> 3482:   decrementl(index);
> 3483:   jmpb(LONG_SCALAR_LOOP_BEGIN);
> 3484:   bind(LONG_SCALAR_LOOP_END);

You can share this loop with the scalar ones above.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3493:

> 3491:   // vnext = IntVector.broadcast(I256, power_of_31_backwards[0]);
> 3492:   movdl(vnext, InternalAddress(power_of_31_backwards + (0 * sizeof(jint))));
> 3493:   vpbroadcastd(vnext, vnext, Assembler::AVX_256bit);

`vpbroadcastd` can take an `Address` argument instead.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3523:

> 3521:   subl(index, 32);
> 3522:   // i >= 0;
> 3523:   cmpl(index, 0);

You don't need this since `subl` sets flags according to the result.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3528:

> 3526:     vpmulld(vcoef[idx], vcoef[idx], vnext, Assembler::AVX_256bit);
> 3527:   }
> 3528:   jmp(LONG_VECTOR_LOOP_BEGIN);

Calculating backward forces you to do calculating the coefficients on each iteration, I think doing this normally would be better.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From qamai at openjdk.org  Mon Oct 31 02:49:25 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 31 Oct 2022 02:49:25 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops
In-Reply-To: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
Message-ID: <bY2edrSuEuFjz7qUItE30wUqrJEQZHKUNHhgfcEu_cU=.5bb8f7f6-f156-4f8f-b2bc-7ba47ce0ba4b@github.com>

On Mon, 31 Oct 2022 02:12:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3387:
> 
>> 3385:   for (int idx = 0; idx < 4; idx++) {
>> 3386:     // h = (31 * h) or (h << 5 - h);
>> 3387:     movl(tmp, result);
> 
> If you are unrolling this, maybe break the dependency chain, `h = h * 31**4 + x[i] * 31**3 + x[i + 1] * 31**2 + x[i + 2] * 31 + x[i + 3]`

A 256-bit vector is only 8 ints so this loop seems redundant, maybe running with the stride of 2 instead, in which case the single scalar calculation does also not need a loop.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From forax at openjdk.org  Mon Oct 31 07:17:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 07:17:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
Message-ID: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>

On Sat, 29 Oct 2022 00:56:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
>> 
>>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>>> 322:      */
>>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
>> 
>> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.
>
> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
> 
> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

Ok, get it.
I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.

The less methods in the API, the better.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Mon Oct 31 08:30:23 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 31 Oct 2022 08:30:23 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v5]
In-Reply-To: <DTaMaHL73PaZ5AnW9pT9fmx2_xPobPPMuneftJ1VoDY=.ed03db04-2fa3-4b7a-8969-2b3751d1a8ab@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <DTaMaHL73PaZ5AnW9pT9fmx2_xPobPPMuneftJ1VoDY=.ed03db04-2fa3-4b7a-8969-2b3751d1a8ab@github.com>
Message-ID: <3DSgJdolotqpONVrELRWSUEzzKTIRpG_lgOv3eGAOQI=.31f4fa0a-2623-46cb-b2b1-fed8af0449d3@github.com>

On Sat, 29 Oct 2022 12:31:41 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR implements JDK-8294696.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No immediate buffer resize; in the rare case of read-past-EOF automatic buffer grow will happen anyways

**TL;DR:** Your optimization is now contained in this PR and outperforms the previous code. Nevertheless I plead for Alternative C (double buffering) instead, which is even faster but much simpler.

**Justification**

I took some time and did intensive JMH testing (with two buffer sizes and with four percental start positions within the buffer to simulate non-pre-read, slightly-pre-read, mostly-pre-read and fully-pre-read buffer situations) with three variants: The current code with early buffer resize (which you say is not necessary), the current code without early buffer resize (which you propose instead), and the so-called Alternative C (which uses double-buffering instead of buffer-replacing).

* Alternative B: Optimization outperforms unoptimized code
The results are shown below, and as you can see, early buffer resize is only a problem in *some*, but not all, cases. Nevertheless I agree that should be avoided, so I already pushed it as commit https://github.com/openjdk/jdk/pull/10525/commits/9c2f502c06083694deefe6a9d4c8ee4b77a92c68 and hope that you are fine with this latest piece of code.

* Alternative C: Outperforms Alternative B (optimized *and* unoptimized code) unless buffer is huge
Interesting to see BTW is that Alternative C (double-buffering instead of buffer-replacing) even outperforms that optimized code for the default buffer size (8K), and is only slightly slower in the case of large (1M) buffers (apparently `System.arraycopy` is faster than `Arrays.fill` unless the array is huge, which I did not expect originally). As the code is super-simple compared to the current code, and as the originally assumed risk of OOME does not exists (if it would, the `fill()` method would fail already, as it uses double-buffering, too, and is called by the `read` happening *before* `transferTo`) I would propose that we go with this code instead of the optimized Alternative B:

private long implTransferTo(OutputStream out) throws IOException {
    if (getClass() == BufferedInputStream.class && markpos == -1) {
        int avail = count - pos;
        if (avail > 0) {
            byte[] buffer = new byte[avail]; // Double buffering prevents poisoning and leaking
            System.arraycopy(getBufIfOpen(), pos, buffer, 0, avail);
            out.write(buffer);
            pos = count;
        }
        return avail + getInIfOpen().transferTo(out);
    } else {
        return super.transferTo(out);
    }
}


Here are the numbers in full length for your reference:

Alternative B optimized (no early buffer resize)

Benchmark                                            (bufSize)  (posPercent)   Mode  Cnt        Score       Error  Units
BufferedInputStreamTransferToPerformance.transferTo       8192             0  thrpt   25     4289,949 ??   217,452  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            10  thrpt   25     3823,443 ??   314,171  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            90  thrpt   25     4122,949 ??    52,131  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192           100  thrpt   25     4675,491 ??    46,194  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576             0  thrpt   25     3477,497 ??   111,229  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            10  thrpt   25     4767,220 ??    18,274  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            90  thrpt   25    43900,923 ??   799,471  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576           100  thrpt   25  1680163,414 ?? 29823,617  ops/s

Alternative B original (with early buffer resize)

Benchmark                                            (bufSize)  (posPercent)   Mode  Cnt        Score       Error  Units
BufferedInputStreamTransferToPerformance.transferTo       8192             0  thrpt   25     4346,835 ??   273,140  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            10  thrpt   25     3816,744 ??   220,669  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            90  thrpt   25     3624,021 ??   340,279  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192           100  thrpt   25     4484,060 ??    95,201  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576             0  thrpt   25     3507,334 ??   140,604  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            10  thrpt   25     4800,050 ??    44,987  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            90  thrpt   25    44327,841 ??   256,322  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576           100  thrpt   25  1699685,163 ?? 44257,421  ops/s

Alternative C: Double buffering

Benchmark                                            (bufSize)  (posPercent)   Mode  Cnt        Score       Error  Units
BufferedInputStreamTransferToPerformance.transferTo       8192             0  thrpt   25     4555,523 ??    83,370  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            10  thrpt   25     3972,562 ??   489,380  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            90  thrpt   25     4181,716 ??    49,527  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192           100  thrpt   25     4602,409 ??   125,641  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576             0  thrpt   25     3373,734 ??   161,989  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            10  thrpt   25     4684,583 ??    87,257  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            90  thrpt   25    44082,232 ??   364,210  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576           100  thrpt   25  1690855,778 ?? 53885,439  ops/s

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Mon Oct 31 08:46:31 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 31 Oct 2022 08:46:31 GMT
Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream
 should override transferTo [v13]
In-Reply-To: <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
Message-ID: <ESRlaLfN3o76-9eFoaSs3ZiIQXvoZfyY8sg3JlFv-1A=.ec091973-86a5-428d-9b08-012a4b77210f@github.com>

On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Draft: Eliminated duplicate code using lambda expressions
>  - Draft: Use blocking mode also for target channel

@laeubi The performance was optimized by several PRs (works well for file based streams now), but there are still cases that could (possibly should) get optimized. These cases are still on my agenda. But before I continue with those cases, I focus on *enabling* that optimization (BufferedInputStream prevents the benefit in *most* cases, but https://github.com/openjdk/jdk/pull/10525 will fix that, so I can step on soon).

-------------

PR: https://git.openjdk.org/jdk/pull/4263

From alanb at openjdk.org  Mon Oct 31 09:54:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 31 Oct 2022 09:54:12 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v5]
In-Reply-To: <3DSgJdolotqpONVrELRWSUEzzKTIRpG_lgOv3eGAOQI=.31f4fa0a-2623-46cb-b2b1-fed8af0449d3@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <DTaMaHL73PaZ5AnW9pT9fmx2_xPobPPMuneftJ1VoDY=.ed03db04-2fa3-4b7a-8969-2b3751d1a8ab@github.com>
 <3DSgJdolotqpONVrELRWSUEzzKTIRpG_lgOv3eGAOQI=.31f4fa0a-2623-46cb-b2b1-fed8af0449d3@github.com>
Message-ID: <IDNqd2a_gb6vUepG6OwZ1VtCb39M1SVYn-reDMajQS4=.072b690e-f8e0-4725-b87c-b7d673e4323b@github.com>

On Mon, 31 Oct 2022 08:28:07 GMT, Markus KARG <duke at openjdk.org> wrote:

> **TL;DR:** Your optimization is now contained in this PR and outperforms the previous code. Nevertheless I plead for Alternative C (double buffering) instead, which is even faster but much simpler.

You had dismissed this previously so it's useful to have results now to compare. I agree it's much simpler, it can probably use Arrays.copyOfRange too.

For the results, can you say what the underlying input stream is and what the target output stream is? Also it would be useful to get a baseline. I suspect you have that, it's just not pasted in the table above.

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From redestad at openjdk.org  Mon Oct 31 12:07:43 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 12:07:43 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v2]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <Q1VfYoJ-qTwz4zrTc7n1-OXIQ_D220iphI12riU4Tlo=.d5e17de4-b263-461c-ab65-6b10d681a5e1@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Reorder loops and some other suggestions from @merykitty

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/22fec5f0..6aed1c1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=00-01

  Stats: 110 lines in 1 file changed: 59 ins; 45 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Mon Oct 31 12:28:10 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 12:28:10 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v2]
In-Reply-To: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
Message-ID: <QmiDww20tXO8mk6NYBQCoh4KzZgsygyqgZ-xi9bXSIE=.07957333-e9ce-4031-a858-bcf131071d0c@github.com>

On Mon, 31 Oct 2022 02:34:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorder loops and some other suggestions from @merykitty
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3484:
> 
>> 3482:   decrementl(index);
>> 3483:   jmpb(LONG_SCALAR_LOOP_BEGIN);
>> 3484:   bind(LONG_SCALAR_LOOP_END);
> 
> You can share this loop with the scalar ones above.

This might be messier than it first looks, since the two different loops use different temp registers based (long scalar can scratch cnt1, short scalar scratches the coef register). I'll have to think about this for a bit.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3523:
> 
>> 3521:   subl(index, 32);
>> 3522:   // i >= 0;
>> 3523:   cmpl(index, 0);
> 
> You don't need this since `subl` sets flags according to the result.

Fixed

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Mon Oct 31 12:32:34 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 12:32:34 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v2]
In-Reply-To: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
Message-ID: <FELBiB8-y90_u8JO0QM_sWqAbx64GMjE_8CHF6b08P0=.77dfc42f-e037-4872-afbf-af5a989edad7@github.com>

On Mon, 31 Oct 2022 02:21:44 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorder loops and some other suggestions from @merykitty
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3358:
> 
>> 3356:   movl(result, is_string_hashcode ? 0 : 1);
>> 3357: 
>> 3358:   // if (cnt1 == 0) {
> 
> You may want to reorder the execution of the loops, a short array suffers more from processing than a big array, so you should have minimum extra hops for those. For example, I think this could be:
> 
>     if (cnt1 >= 4) {
>         if (cnt1 >= 16) {
>             UNROLLED VECTOR LOOP
>             SINGLE VECTOR LOOP
>         }
>         UNROLLED SCALAR LOOP
>     }
>     SINGLE SCALAR LOOP
> 
> The thresholds are arbitrary and need to be measured carefully.

Fixed

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3374:
> 
>> 3372: 
>> 3373:   // int i = 0;
>> 3374:   movl(index, 0);
> 
> `xorl(index, index)`

Fixed

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3418:
> 
>> 3416:   // } else { // cnt1 >= 32
>> 3417:   address power_of_31_backwards = pc();
>> 3418:   emit_int32( 2111290369);
> 
> Can this giant table be shared among compilations instead?

Probably, though I'm not entirely sure on how. Maybe the "long" cases should be factored out into a set of stub routines so that it's not inlined in numerous places anyway.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Mon Oct 31 12:32:34 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 12:32:34 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v2]
In-Reply-To: <bY2edrSuEuFjz7qUItE30wUqrJEQZHKUNHhgfcEu_cU=.5bb8f7f6-f156-4f8f-b2bc-7ba47ce0ba4b@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
 <bY2edrSuEuFjz7qUItE30wUqrJEQZHKUNHhgfcEu_cU=.5bb8f7f6-f156-4f8f-b2bc-7ba47ce0ba4b@github.com>
Message-ID: <Ic_0XiWAcnZ0NAnjoVeFMk2hD7nIdvwV32jgiDcHD1U=.5070c13d-9acd-42b9-8114-6c943c97bf22@github.com>

On Mon, 31 Oct 2022 02:15:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3387:
>> 
>>> 3385:   for (int idx = 0; idx < 4; idx++) {
>>> 3386:     // h = (31 * h) or (h << 5 - h);
>>> 3387:     movl(tmp, result);
>> 
>> If you are unrolling this, maybe break the dependency chain, `h = h * 31**4 + x[i] * 31**3 + x[i + 1] * 31**2 + x[i + 2] * 31 + x[i + 3]`
>
> A 256-bit vector is only 8 ints so this loop seems redundant, maybe running with the stride of 2 instead, in which case the single scalar calculation does also not need a loop.

Working on this..

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Mon Oct 31 12:35:26 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 12:35:26 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v3]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <LtwjI6qrADFe_rOmbTzEf3pjeeXBjL8zuWdN5kPXIhY=.73201421-aff0-42ed-9ddb-23e12e048260@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Require UseSSE >= 3 due transitive use of sse3 instructions from ReduceI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/6aed1c1e..7e8a3e9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From jlaskey at openjdk.org  Mon Oct 31 12:39:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:39:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <EQVJmKVbtnwEXTfgghVb4mU5BE4xtbqoLDTOgwCmqDU=.73928cc8-ed53-4da1-81dd-a5b847aa9595@github.com>

On Fri, 28 Oct 2022 20:23:26 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`
>
> Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?
> 
> People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

Noted

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:53:29 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:29 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <OIUDXCNftOdGHiKS44vTdCuDosKklkect9B3NrfkNNk=.2a399201-95dd-4f7c-a768-14da71da6c41@github.com>

On Fri, 28 Oct 2022 20:07:35 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> The defensive copies are done by the callers.
>
> In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

Moving to TemplateRuntime

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:53:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <hEQTvtQgMLQMCZHJWaVzJzCGo_H7PAYWpR_X8Vs3Hcw=.c9102791-3f62-4222-afea-3aba32323325@github.com>

On Fri, 28 Oct 2022 19:05:10 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:
> 
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
>> 29: import java.util.*;
> 
> Please fix.

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 12:59:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:59:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <ZE2vcmQWISh2duTMkVFwVLUj4JfRFSR5ZQ9gz8AWhgk=.e9946cbe-e5a4-4a9c-a2c6-f309bd536142@github.com>

On Fri, 28 Oct 2022 19:06:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:
> 
>> 173:      * method {@code processor.process(this)}.
>> 174:      */
>> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {
> 
> signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:
> 
>> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
>> 203:      */
>> 204:     default public List<MethodHandle> valueGetters() {
> 
> I think i prefer the term accessors instead of getters

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Mon Oct 31 13:01:24 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 31 Oct 2022 13:01:24 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v5]
In-Reply-To: <IDNqd2a_gb6vUepG6OwZ1VtCb39M1SVYn-reDMajQS4=.072b690e-f8e0-4725-b87c-b7d673e4323b@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <DTaMaHL73PaZ5AnW9pT9fmx2_xPobPPMuneftJ1VoDY=.ed03db04-2fa3-4b7a-8969-2b3751d1a8ab@github.com>
 <3DSgJdolotqpONVrELRWSUEzzKTIRpG_lgOv3eGAOQI=.31f4fa0a-2623-46cb-b2b1-fed8af0449d3@github.com>
 <IDNqd2a_gb6vUepG6OwZ1VtCb39M1SVYn-reDMajQS4=.072b690e-f8e0-4725-b87c-b7d673e4323b@github.com>
Message-ID: <URhhMN1f_7ywvIzGaR2xSNIBWcBexMECim79B_XxLJo=.a94a2ad7-2951-41b6-8f17-b99c8115673e@github.com>

On Mon, 31 Oct 2022 09:52:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > **TL;DR:** Your optimization is now contained in this PR and outperforms the previous code. Nevertheless I plead for Alternative C (double buffering) instead, which is even faster but much simpler.

> You had dismissed this previously so it's useful to have results now to compare. I agree it's much simpler, it can probably use Arrays.copyOfRange too.

Sorry for that. Unless I actually tested, I was unaware how slow Alternative B actually is (in fact it was quite surprising that `Arrays.fill` apparently is implemented in pure Java while `System.arraycopy` is native). So let's go on with Alternative C + `Arrays.copyOfRange`! :-)

> For the results, can you say what the underlying input stream is and what the target output stream is? Also it would be useful to get a baseline. I suspect you have that, it's just not pasted in the table above.

The underlying input stream is `ByteArrayInputStream` wrapping 1 MB byte array, the output stream is `ByteArrayOutputStream`. So the test is not I/O-bound, hence it is clearly focusing on the actual difference Alternatives B/C. Yes, I do have a baseline. It is the original code without *any* safety against poisoning and leaking and the numbers are shown below. I have not published it before, because they are not perfectly comparable: A Windows Update happened after the above runs, and before this run, and my laptop feels to behave somewhat different since then. Sorry for that, but I had no time to repeat the full four hours test suite, and I think the numbers are good enough for our decision pro Alternative C. 

Benchmark                                            (bufSize)  (posPercent)   Mode  Cnt        Score       Error  Units
BufferedInputStreamTransferToPerformance.transferTo       8192             0  thrpt   25     4197,126 ??   627,973  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            10  thrpt   25     2615,802 ??   251,678  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192            90  thrpt   25     3140,941 ??   575,787  ops/s
BufferedInputStreamTransferToPerformance.transferTo       8192           100  thrpt   25     4603,691 ??    12,127  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576             0  thrpt   25     3539,737 ??    59,913  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            10  thrpt   25     4790,750 ??    63,090  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576            90  thrpt   25    43273,624 ??  1784,369  ops/s
BufferedInputStreamTransferToPerformance.transferTo    1048576           100  thrpt   25  1693553,210 ?? 21249,108  ops/s

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From jlaskey at openjdk.org  Mon Oct 31 13:04:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:04:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>

On Fri, 28 Oct 2022 19:08:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
> 
>> 147:      * {@return the interpolation of the StringTemplate}
>> 148:      */
>> 149:     default String interpolate() {
> 
> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From luhenry at openjdk.org  Mon Oct 31 13:22:32 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 31 Oct 2022 13:22:32 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v3]
In-Reply-To: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
Message-ID: <ItgEUpQqe5_lJReITrZWgr5SbqUS1kAanJsyqzhzNuE=.2b5b0e1e-1dc4-4cf3-8d0e-a61d8a4c439c@github.com>

On Mon, 31 Oct 2022 02:35:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Require UseSSE >= 3 due transitive use of sse3 instructions from ReduceI
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3493:
> 
>> 3491:   // vnext = IntVector.broadcast(I256, power_of_31_backwards[0]);
>> 3492:   movdl(vnext, InternalAddress(power_of_31_backwards + (0 * sizeof(jint))));
>> 3493:   vpbroadcastd(vnext, vnext, Assembler::AVX_256bit);
> 
> `vpbroadcastd` can take an `Address` argument instead.

An `InternalAddress` isn't an `Address` but an `AddressLiteral`. You can however do `as_Address(InternalAddress(power_of_31_backwards + (0 * sizeof(jint))))`

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3528:
> 
>> 3526:     vpmulld(vcoef[idx], vcoef[idx], vnext, Assembler::AVX_256bit);
>> 3527:   }
>> 3528:   jmp(LONG_VECTOR_LOOP_BEGIN);
> 
> Calculating backward forces you to do calculating the coefficients on each iteration, I think doing this normally would be better.

But doing it forward requires a `reduceLane` on each iteration. It's faster to do it backward.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From duke at openjdk.org  Mon Oct 31 13:30:13 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 31 Oct 2022 13:30:13 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v6]
In-Reply-To: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
Message-ID: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com>

> This PR implements JDK-8294696.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Alternative C + Arrays.copyOfRange()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10525/files
  - new: https://git.openjdk.org/jdk/pull/10525/files/9c2f502c..92ed32cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10525&range=04-05

  Stats: 20 lines in 1 file changed: 0 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10525/head:pull/10525

PR: https://git.openjdk.org/jdk/pull/10525

From duke at openjdk.org  Mon Oct 31 13:30:14 2022
From: duke at openjdk.org (Markus KARG)
Date: Mon, 31 Oct 2022 13:30:14 GMT
Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer
 when mark set [v5]
In-Reply-To: <IDNqd2a_gb6vUepG6OwZ1VtCb39M1SVYn-reDMajQS4=.072b690e-f8e0-4725-b87c-b7d673e4323b@github.com>
References: <Hjta5QnU3A2DPnEftDtms6ggEirgKw5h0Y1CqoBifv4=.23290aca-5c79-4caa-ad07-f0ba9c010403@github.com>
 <DTaMaHL73PaZ5AnW9pT9fmx2_xPobPPMuneftJ1VoDY=.ed03db04-2fa3-4b7a-8969-2b3751d1a8ab@github.com>
 <3DSgJdolotqpONVrELRWSUEzzKTIRpG_lgOv3eGAOQI=.31f4fa0a-2623-46cb-b2b1-fed8af0449d3@github.com>
 <IDNqd2a_gb6vUepG6OwZ1VtCb39M1SVYn-reDMajQS4=.072b690e-f8e0-4725-b87c-b7d673e4323b@github.com>
Message-ID: <w5bJj6PzGbNmJWcOFgjCMZW4KgTeSiBbwoCfI3Hdk4Q=.bef5fe07-4ab9-450a-9c65-4f5ca66a9a53@github.com>

On Mon, 31 Oct 2022 09:52:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> **TL;DR:** Your optimization is now contained in this PR and outperforms the previous code. Nevertheless I plead for Alternative C (double buffering) instead, which is even faster but much simpler.
>> 
>> **Justification**
>> 
>> I took some time and did intensive JMH testing (with two buffer sizes and with four percental start positions within the buffer to simulate non-pre-read, slightly-pre-read, mostly-pre-read and fully-pre-read buffer situations) with three variants: The current code with early buffer resize (which you say is not necessary), the current code without early buffer resize (which you propose instead), and the so-called Alternative C (which uses double-buffering instead of buffer-replacing).
>> 
>> * Alternative B: Optimization outperforms unoptimized code
>> The results are shown below, and as you can see, early buffer resize is only a problem in *some*, but not all, cases. Nevertheless I agree that should be avoided, so I already pushed it as commit https://github.com/openjdk/jdk/pull/10525/commits/9c2f502c06083694deefe6a9d4c8ee4b77a92c68 and hope that you are fine with this latest piece of code.
>> 
>> * Alternative C: Outperforms Alternative B (optimized *and* unoptimized code) unless buffer is huge
>> Interesting to see BTW is that Alternative C (double-buffering instead of buffer-replacing) even outperforms that optimized code for the default buffer size (8K), and is only slightly slower in the case of large (1M) buffers (apparently `System.arraycopy` is faster than `Arrays.fill` unless the array is huge, which I did not expect originally). As the code is super-simple compared to the current code, and as the originally assumed risk of OOME does not exists (if it would, the `fill()` method would fail already, as it uses double-buffering, too, and is called by the `read` happening *before* `transferTo`) I would propose that we go with this code instead of the optimized Alternative B:
>> 
>> private long implTransferTo(OutputStream out) throws IOException {
>>     if (getClass() == BufferedInputStream.class && markpos == -1) {
>>         int avail = count - pos;
>>         if (avail > 0) {
>>             byte[] buffer = new byte[avail]; // Double buffering prevents poisoning and leaking
>>             System.arraycopy(getBufIfOpen(), pos, buffer, 0, avail);
>>             out.write(buffer);
>>             pos = count;
>>         }
>>         return avail + getInIfOpen().transferTo(out);
>>     } else {
>>         return super.transferTo(out);
>>     }
>> }
>> 
>> 
>> Here are the numbers in full length for your reference:
>> 
>> Alternative B optimized (no early buffer resize)
>> 
>> Benchmark                                            (bufSize)  (posPercent)   Mode  Cnt        Score       Error  Units
>> BufferedInputStreamTransferToPerformance.transferTo       8192             0  thrpt   25     4289,949 ??   217,452  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192            10  thrpt   25     3823,443 ??   314,171  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192            90  thrpt   25     4122,949 ??    52,131  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192           100  thrpt   25     4675,491 ??    46,194  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576             0  thrpt   25     3477,497 ??   111,229  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576            10  thrpt   25     4767,220 ??    18,274  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576            90  thrpt   25    43900,923 ??   799,471  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576           100  thrpt   25  1680163,414 ?? 29823,617  ops/s
>> 
>> Alternative B original (with early buffer resize)
>> 
>> Benchmark                                            (bufSize)  (posPercent)   Mode  Cnt        Score       Error  Units
>> BufferedInputStreamTransferToPerformance.transferTo       8192             0  thrpt   25     4346,835 ??   273,140  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192            10  thrpt   25     3816,744 ??   220,669  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192            90  thrpt   25     3624,021 ??   340,279  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192           100  thrpt   25     4484,060 ??    95,201  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576             0  thrpt   25     3507,334 ??   140,604  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576            10  thrpt   25     4800,050 ??    44,987  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576            90  thrpt   25    44327,841 ??   256,322  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576           100  thrpt   25  1699685,163 ?? 44257,421  ops/s
>> 
>> Alternative C: Double buffering
>> 
>> Benchmark                                            (bufSize)  (posPercent)   Mode  Cnt        Score       Error  Units
>> BufferedInputStreamTransferToPerformance.transferTo       8192             0  thrpt   25     4555,523 ??    83,370  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192            10  thrpt   25     3972,562 ??   489,380  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192            90  thrpt   25     4181,716 ??    49,527  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo       8192           100  thrpt   25     4602,409 ??   125,641  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576             0  thrpt   25     3373,734 ??   161,989  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576            10  thrpt   25     4684,583 ??    87,257  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576            90  thrpt   25    44082,232 ??   364,210  ops/s
>> BufferedInputStreamTransferToPerformance.transferTo    1048576           100  thrpt   25  1690855,778 ?? 53885,439  ops/s
>> 
>> (N.B.: Huge buffers appear to have better numbers than small buffers simply because the test always transported 1 MB of data, so with a huge buffer this happens in few steps, while with small buffers this happens in many steps.)
>
>> **TL;DR:** Your optimization is now contained in this PR and outperforms the previous code. Nevertheless I plead for Alternative C (double buffering) instead, which is even faster but much simpler.
> 
> You had dismissed this previously so it's useful to have results now to compare. I agree it's much simpler, it can probably use Arrays.copyOfRange too.
> 
> For the results, can you say what the underlying input stream is and what the target output stream is? Also it would be useful to get a baseline. I suspect you have that, it's just not pasted in the table above.

@AlanBateman Alternative C+ Arrays.copyOfRange() is implemented in https://github.com/openjdk/jdk/pull/10525/commits/92ed32cd28dab1ef5a03c6a8b1e13fef04a52753. So I think we finally got it? :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10525

From qamai at openjdk.org  Mon Oct 31 13:38:47 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 31 Oct 2022 13:38:47 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v3]
In-Reply-To: <ItgEUpQqe5_lJReITrZWgr5SbqUS1kAanJsyqzhzNuE=.2b5b0e1e-1dc4-4cf3-8d0e-a61d8a4c439c@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
 <ItgEUpQqe5_lJReITrZWgr5SbqUS1kAanJsyqzhzNuE=.2b5b0e1e-1dc4-4cf3-8d0e-a61d8a4c439c@github.com>
Message-ID: <L2WAjZaNyLgTJp85sijndF0GLYMMAPObB3ncl3u-U6w=.b2d6a5e6-8aa0-4328-b11e-b258d78e9f4b@github.com>

On Mon, 31 Oct 2022 13:18:35 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3528:
>> 
>>> 3526:     vpmulld(vcoef[idx], vcoef[idx], vnext, Assembler::AVX_256bit);
>>> 3527:   }
>>> 3528:   jmp(LONG_VECTOR_LOOP_BEGIN);
>> 
>> Calculating backward forces you to do calculating the coefficients on each iteration, I think doing this normally would be better.
>
> But doing it forward requires a `reduceLane` on each iteration. It's faster to do it backward.

No you don't need to, the vector loop can be calculated as:

    IntVector accumulation = IntVector.zero(INT_SPECIES);
    for (int i = 0; i < bound; i += INT_SPECIES.length()) {
        IntVector current = IntVector.load(INT_SPECIES, array, i);
        accumulation = accumulation.mul(31**(INT_SPECIES.length())).add(current);
    }
    return accumulation.mul(IntVector.of(31**INT_SPECIES.length() - 1, ..., 31**2, 31, 1).reduce(ADD);

Each iteration only requires a multiplication and an addition. The weight of lanes can be calculated just before the reduction operation.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <n5D2AKUK150bLdl1X1PAp8RZQ9Oo4EOJh863F8tMSMQ=.078b48c3-59bb-40c1-a3df-660242f8ae74@github.com>

On Fri, 28 Oct 2022 19:12:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:
> 
>> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
>> 306:         }
>> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));
> 
> I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().
> 
> Edit:
> fragments should use List.copyOf() but i suppose that a value inside values can be null, so you can not use List.copyOf() for the values.
> 
> There a little secret, the ImmutableList  has a special flag to represent an unmodifiable list that can access null, this implementation is used by `stream.toList()`, i think you should use a shared secret access to have have access to this implementation instead of relying on `Collections.unmodifiableList(new ArrayList<>(...))`.
> 
> @stuart-marks, do you think it's a good idea to use the null allowed ImmutableList here ?

Changing as recommended

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:
> 
>> 352:      * @implNote The result of interpolation is not interned.
>> 353:      */
>> 354:     public static final StringProcessor STR = st -> st.interpolate();
> 
> Should be `StringTemplate::interpolate`.

Yep

> src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:
> 
>> 36:  * that do not throw checked exceptions. For example:
>> 37:  * {@snippet :
>> 38:  * TemplateProcessor<String> processor = st -> {
> 
> This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

Noted

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
 <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
Message-ID: <IQ1cw48hyO6eHZumI9fehaIEPEFhx4GHZaRtexHoW7k=.b9cb907b-f4f7-4bbb-ace7-32c86b86fdfe@github.com>

On Mon, 31 Oct 2022 07:14:45 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
>> 
>> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.
>
> Ok, get it.
> I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.
> 
> The less methods in the API, the better.

Noted

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:49:18 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com>

On Fri, 28 Oct 2022 19:20:40 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:
> 
>> 43:  */
>> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 45: public final class TemplateRuntime {
> 
> Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

Purely because of the BSM and BSMs access to internals of `java.lang.template`. I'll work on moving the BSM to `jdk.internal`. and access through `SharedSecrets`.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:
> 
>> 63:      * @throws Throwable            if linkage fails
>> 64:      */
>> 65:     public static CallSite stringTemplateBSM(
> 
> I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

Will work on it.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:49:20 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
 <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
Message-ID: <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@github.com>

On Fri, 28 Oct 2022 19:57:41 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
>> 
>> public static <E> List<E> toList(E... elements) {
>> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
>> }
>
> Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
> Using that implementation will avoid a bunch of indirection

Changing to use `JUCA`.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 13:54:44 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:54:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <Z7QI2E1zswpmzuoUkBJzlEYAh1l9iOcTYwe82y4X2Uw=.0056169c-283a-4012-a943-c7223b67485e@github.com>

On Fri, 28 Oct 2022 19:26:20 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:
> 
>> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
>> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
>> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();
> 
> `ValidatingProcessor<?, ?>` should be enough ? No ?
> Using a "? extends Throwable" here make the type unchecked.

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:
> 
>> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
>> 87:      */
>> 88:     private static class TemplateBootstrap {
> 
> This class should be `final`

Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:
> 
>> 115:          * Static final processor.
>> 116:          */
>> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;
> 
> Use `ValidatingProcessor<?, ?>` here

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:
> 
>> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
>> 144:                                   List<String> fragments,
>> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {
> 
> Use ValidatingProcessor&lt;?, ?&gt; here

That works. Changing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:30:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:30:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <K46-FD72Mtz3zFIhWwj9_0QI100Sy4_XE2q34hxNyMU=.9e66b1d0-5031-4564-8404-e1b545f2fafa@github.com>

On Fri, 28 Oct 2022 19:33:38 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:
> 
>> 287:         try {
>> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
>> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",
> 
> This should be a constant (using the class holder idiom or not)

Changing

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:
> 
>> 300: 
>> 301:     /**
>> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}
> 
> Private "method"

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:39:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:39:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <EprEHey_-RlxTSqSiEgb7upgHtblKqAQO6mM_Exgqjs=.eaf0be7b-85d2-4179-847c-da5d07c80eb7@github.com>

On Fri, 28 Oct 2022 19:39:01 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:
> 
>> 387:             }
>> 388:         }
>> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));
> 
> It seems that IntelliJ was lost when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 14:49:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:49:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <hJKj6jjb0I6mnmYZW8CO7T_AfPDBzbz1B4xuG8mZ9Gc=.b156b047-8839-4447-b21f-fbe7b3b4eb8f@github.com>

On Fri, 28 Oct 2022 19:36:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:
> 
>> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 324:      */
>> 325:     static String interpolate(List<String> fragments, List<Object> values) {
> 
> I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Mon Oct 31 14:57:04 2022
From: duke at openjdk.org (jmehrens)
Date: Mon, 31 Oct 2022 14:57:04 GMT
Subject: RFR: 8294693: Add Collections.shuffle overload that accepts
 RandomGenerator interface [v3]
In-Reply-To: <OaXRh5uLiYqRtZH1QiJfxGdESxp05fYRmJzvFqAH7C4=.aa2da655-11e4-4433-a05f-6ecbea3f7a80@github.com>
References: <TJsEqsCoMbK73PRL09YmLrlXpWu4uRvHGpYoS41M2yg=.42a2d13e-684e-4074-b9fe-31568c09787d@github.com>
 <JEYob79-sNyvaqpuxuzIJQHNBuqRolzWf6V3WYJGt90=.424a1878-b393-4d1c-8613-d485303c5a67@github.com>
 <OaXRh5uLiYqRtZH1QiJfxGdESxp05fYRmJzvFqAH7C4=.aa2da655-11e4-4433-a05f-6ecbea3f7a80@github.com>
Message-ID: <LACk-lBdZv4-P0PfBQv2A-ccW9lXTsIwraDEhZtv6y0=.24f981e1-eeb2-463e-b770-37a53540ae8c@github.com>

On Fri, 28 Oct 2022 23:18:00 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I'm having difficulty imagining how SequencedCollection::replaceAll could work or be useful. Obviously it's on List already.
In Collections.java, it seems that the cases of AbstractSequentialList are handled like so:

1. Call toArray
2. Perform some permutation on the array copy.
3. Write results back to using a loop ListIterator::set.

Step three can always be rewritten with List::replaceAll (new RFE).  SequencedCollection is somewhat like AbstractSequentialList because calls to get are not used.  Therefore, if AbstractSequentialList has positional read access but it is not used and SequencedCollection doesn't have positional access either then the two types could be substituted if we had some sort of way to write the permutation back to the SequencedCollection.  One way to do that is replaceAll as it is a sequenced (non-random) write operation.

> However, LinkedHashSet is a Set and so has a unique-elements constraint. What should replaceAll do if the replacement element already exists in the set? (For a shuffle operation, the first swap operation by definition replaces an element with another element that's somewhere else in the set, so this issue arises immediately.) 

On an SequencedSet it is effectively a swap operation.  Ejecting the existing element would be a CCE and adding a new element would be a CCE so the only way to implement is with position swap.  It just would mean the UnaryOperator could encounter the same element for the whole iteration if it was constantly swapped with (i + 1).  Perhaps that is violation where this all falls apart?

> A replaceAll operation on a NavigableSet seems right out. The elements are positioned according to their sort order, so there's no notion of updating an element "in-place" at all.

My understand is that addFirst/addLast would be present on NavigableSet per retrofitting section of the JEP.  The replaceAll would have API wiggle words the same way addFirst/addLast would.

At any rate I don't want to derail this PR and I appreciate your response.  It just seems odd to me that SequencedCollection has a sequence but we can't sort or shuffle that sequence via Collections.java as we do for AbstractSequentialList.

-------------

PR: https://git.openjdk.org/jdk/pull/10520

From jlaskey at openjdk.org  Mon Oct 31 15:01:31 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
Message-ID: <YUiKJ6MKELuPwEDxpmhH3AEsMk8mG7vLANniLjwaGuM=.d88e51b7-a807-4892-8dd0-977ab9fa8037@github.com>

On Fri, 28 Oct 2022 19:45:55 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 198:
> 
>> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
>> 197:      */
>> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);
> 
> `Locale.US` or `Locale.ROOT` ??
> see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

There was a bug in DecimalFormatSymbols when I started this work and Locale.ROOT was problematic. I didn't circle around to check later. Changing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 15:01:35 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
 <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
Message-ID: <HhniXeb1FMUt_2zLv1ioKD232wB4uGp6wNf06Lym3KI=.977dc53f-abe0-47dc-b06b-9475f919308c@github.com>

On Fri, 28 Oct 2022 23:50:11 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove .orig file
>
> src/java.base/share/classes/java/util/FormatterBuilder.java line 470:
> 
>> 468:      */
>> 469:     MethodHandle build() {
>> 470:         Formatter.parse(format);
> 
> `Formatter.parse` is called here, and then again a few lines down.

Residue cruft. Thanks. Changing.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Oct 31 15:38:42 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:38:42 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v5]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <UEq7NU7NgwbZA9fmIW88hdE8TtJfMV1xgTUoyT9UUGQ=.9fa69424-0a2f-4909-8f77-8b1109f407d0@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Requested changes #2
 - Requested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/347df715..d30e6eff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=03-04

  Stats: 168 lines in 15 files changed: 60 ins; 60 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Mon Oct 31 15:55:28 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 15:55:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
 <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
Message-ID: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com>

On Mon, 31 Oct 2022 13:02:18 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
>> 
>>> 147:      * {@return the interpolation of the StringTemplate}
>>> 148:      */
>>> 149:     default String interpolate() {
>> 
>> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy
>
> Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

Interesting !
I believe the javadoc should mention that.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From aturbanov at openjdk.org  Mon Oct 31 17:35:16 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 31 Oct 2022 17:35:16 GMT
Subject: RFR: 8296140: Drop unused field java.util.Calendar.DATE_MASK
Message-ID: <P7Lc7JlcC90i-4Chm5eEV2Kd7etfqQdY_5QLq_RHHME=.5f2d6083-b7f8-4065-9d2b-0ceb11c9e75a@github.com>

There is no usages for this field. As it has the same value as `DAY_OF_MONTH_MASK` we can drop it.

-------------

Commit messages:
 - [PATCH] Drop unused field java.util.Calendar.DATE_MASK

Changes: https://git.openjdk.org/jdk/pull/10888/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10888&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296140
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10888.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10888/head:pull/10888

PR: https://git.openjdk.org/jdk/pull/10888

From joehw at openjdk.org  Mon Oct 31 17:37:27 2022
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 31 Oct 2022 17:37:27 GMT
Subject: RFR: 8284842: Update Unicode Data Files to Version 15.0.0
In-Reply-To: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
References: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
Message-ID: <A4Bs5Hqr5NbcJTyTVCx9XQ7pLAbdmfijavFbFdsZlDo=.3abb5f64-e34b-431d-badf-03730779b744@github.com>

On Mon, 24 Oct 2022 18:50:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updates the JDK to use the latest Unicode 15, which also updates the ICU4J along with it (8284844: Update ICU4J to Version 72.1). The corresponding CSR has already been approved.

LGTM. Sorry for the delay.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10839

From jlaskey at openjdk.org  Mon Oct 31 17:39:58 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 17:39:58 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v6]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <DJB8X-GwBxtqwAX0Rv_zRn_GhLXHyCF2-1RszcbcVtc=.532ca016-1d04-40f1-8523-399e24d59d75@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Move template bootstrap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/d30e6eff..75fcc49a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=04-05

  Stats: 364 lines in 4 files changed: 210 ins; 147 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Mon Oct 31 17:50:47 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 31 Oct 2022 17:50:47 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
Message-ID: <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>

> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
> 
> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
> 
> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove old ids hack, has no usage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10910/files
  - new: https://git.openjdk.org/jdk/pull/10910/files/8611e5b9..1bb22a2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10910&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10910&range=00-01

  Stats: 20 lines in 2 files changed: 0 ins; 20 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10910.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10910/head:pull/10910

PR: https://git.openjdk.org/jdk/pull/10910

From duke at openjdk.org  Mon Oct 31 17:50:48 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 31 Oct 2022 17:50:48 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <3nb6Mh7G9rTwkyxe9aF4mZCS9td26kHx_XkwMpksl98=.12751398-6095-44a9-a24b-da877874338d@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <3nb6Mh7G9rTwkyxe9aF4mZCS9td26kHx_XkwMpksl98=.12751398-6095-44a9-a24b-da877874338d@github.com>
Message-ID: <CUYHVpNUV6_Pj2-QvmzCP19AINGTZ4Credxnmc2k138=.a22d3ced-a7ae-45c1-8783-06d61ee998b6@github.com>

On Fri, 28 Oct 2022 22:43:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove old ids hack, has no usage
>
> test/jdk/java/util/Formatter/Basic-X.java.template line 1612:
> 
>> 1610:         list.remove("America/WhiteHorse");
>> 1611:         list.remove("Canada/Yukon");
>> 1612:         ids = list.toArray(new String[list.size()]);
> 
> It's not your change but I just noticed this. Since we specifically test only for `CLDR` provider (as in `BasicTestLauncher`), I wonder we could remove this portion. Even if we do need this piece, it could be simplified as:
> 
> ids = Arrays.stream(ids).filter(tz -> !tz.equals(...)).toArray(String[]::new)

Removing portion since it is no longer used/needed. Tests passing without.

-------------

PR: https://git.openjdk.org/jdk/pull/10910

From duke at openjdk.org  Mon Oct 31 17:50:47 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 31 Oct 2022 17:50:47 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <fAtOoLlIqFr9KvcEARECu9ZoEIvOY_TWjEgz3VIP_6U=.d7121113-1ead-47a3-a447-41cea95878a1@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <fAtOoLlIqFr9KvcEARECu9ZoEIvOY_TWjEgz3VIP_6U=.d7121113-1ead-47a3-a447-41cea95878a1@github.com>
Message-ID: <Zv1qEnKYZpgj7C3A5gF9j4U2RO1flTPHt-n3O8xNiFk=.4eb9b3c1-8209-4e79-a31d-106ada734c74@github.com>

On Sat, 29 Oct 2022 18:05:50 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove old ids hack, has no usage
>
> test/jdk/java/util/Formatter/Basic-X.java.template line 1608:
> 
>> 1606:         // time zone ID. See JDK-8254865.
>> 1607:         final List<String> list =  new ArrayList<String>();
>> 1608:         Collections.addAll(list, ids);
> 
> I think
> 
> final List<String> list =  new ArrayList<>(Arrays.asList(ids));
> 
> is going to be faster than
> 
> final List<String> list =  new ArrayList<String>();
> Collections.addAll(list, ids);
> 
> Alternatively you can contruct presized ArrayList.

Thank you,

I will be removing this portion since it is outdated. But I will consider this and your other comment for future uses of List and ArrayList :-)

-------------

PR: https://git.openjdk.org/jdk/pull/10910

From naoto at openjdk.org  Mon Oct 31 18:01:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Oct 2022 18:01:10 GMT
Subject: Integrated: 8284842: Update Unicode Data Files to Version 15.0.0
In-Reply-To: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
References: <cx88X1gWn5LtjlTD5KyNPNo445BbTJFWT4sTK2VjbsU=.651a7a3a-89cf-4a73-adc5-ed782adc5258@github.com>
Message-ID: <CuarPvKm5xRbyAkIjuqKbyz3aKVfANERl2SWeFUMMck=.9b197e06-9ee8-4361-9ac3-6e7eee64c756@github.com>

On Mon, 24 Oct 2022 18:50:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updates the JDK to use the latest Unicode 15, which also updates the ICU4J along with it (8284844: Update ICU4J to Version 72.1). The corresponding CSR has already been approved.

This pull request has now been integrated.

Changeset: 590de37b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/590de37bd703bdae56e8b41c84f5fca5e5a00811
Stats:     1125 lines in 29 files changed: 821 ins; 33 del; 271 mod

8284842: Update Unicode Data Files to Version 15.0.0
8284844: Update ICU4J to Version 72.1

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/10839

From lancea at openjdk.org  Mon Oct 31 18:09:21 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 31 Oct 2022 18:09:21 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
Message-ID: <6sOHsa7Xcm9Xos-1zkf6pWrUqZ_8cUFOqfwXBrF66Ec=.cb1f49ca-4af6-4ef9-a89e-76d30aff8620@github.com>

On Mon, 31 Oct 2022 17:50:47 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
>> 
>> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
>> 
>> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove old ids hack, has no usage

thank you for the clean up Justin.  I think this looks much better and more maintainable

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10910

From naoto at openjdk.org  Mon Oct 31 18:40:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Oct 2022 18:40:10 GMT
Subject: RFR: 8295670: Remove duplication in
 java/util/Formatter/Basic*.java [v2]
In-Reply-To: <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
References: <mTkTIYNphB6Cfy91ep5u5hAxuZHqiblwT-SOJM-GVC0=.08525102-8395-4270-bb00-cd27a7082b71@github.com>
 <xZvcsc5w6YQfmWfir9MGFvZXzEKetYGv4kOHhH98hDM=.9789af33-1159-4979-84a7-0e99651e9bd5@github.com>
Message-ID: <Xw5SQ8vCJisA_RbS5BF6J01ra2XsdSu-R0bpwdjSTGI=.3c2f899c-6491-4f93-9f5a-27bee0138d6d@github.com>

On Mon, 31 Oct 2022 17:50:47 GMT, Justin Lu <duke at openjdk.org> wrote:

>> Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh
>> 
>> Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template.
>> 
>> Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove old ids hack, has no usage

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10910

From jlaskey at openjdk.org  Mon Oct 31 20:11:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 20:11:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add @SafeVarargs declarations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/75fcc49a..6d1d902e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=05-06

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Mon Oct 31 20:49:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:49:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <ZMO73T5DijZRuY1syZG_RLF5MAYKZP6ExGtpTxCeToo=.a9194cfa-96f0-4a5d-af04-040b692f4842@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 132:

> 130:             return result;
> 131:         }
> 132:         for (Object value : st.values()) {

I think that valueTypes() should return the types of the values not the dynamic classes of the values.
Here there is no type information so it should be Object for all values.

It has also the nice property that the return type of the accessors returned by valueAccessors are the same as valueTypes() which is i believe more coherent.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From forax at openjdk.org  Mon Oct 31 20:54:33 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:54:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 119:

> 117:         Class<?> tsClass = st.getClass();
> 118:         if (tsClass.isSynthetic()) {
> 119:             try {

I do not know if this code is worth of optimizing but the way to avoid to recompute the List<Class<?>> each time is to use a java.lang.ClassValue and store the classes inside an unmodifiable List. (Field[] -> Class<?>[] -> List<Class<?>>) The last leg can be done just by calling List.of(), there is no need for an ArrayList here

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From alexander.matveev at oracle.com  Mon Oct 31 21:17:30 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 31 Oct 2022 21:17:30 +0000
Subject: Jpackage OS/X DMG install Application folder alias name
 incorrectly shows as path with /
In-Reply-To: <CD11A95E-41FF-4E92-888E-F31610259F38@gmail.com>
References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
 <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>
 <CD11A95E-41FF-4E92-888E-F31610259F38@gmail.com>
Message-ID: <C93772E9-E624-4F68-9F68-190D8F7B9B44@oracle.com>

Hi Michael,

If I understood correctly you asking for several things:

1) Change ?/Applications? to ?Applications?. I agree and we should fix it if possible. Did you file a bug for it? If not I can file.

2) Resize DMG window to show additional content which was added via --mac-dmg-content, so user does not have to scroll or manually resize window? I think we can investigate this, but I think we still need to limit by how many additional files we want to display in case if user adds for example 100 files (very unlikely). Do you want to file enhancement for this? Or I can do it.

3) From your email "SceneBuilder OS/X DMG?s? do you mean provide ability to localize ?Applications? folder name? I think we can do this, but user will need to produce separate localized DMG for each language.

Thanks,
Alexander

On Oct 30, 2022, at 2:42 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Oct 26, 2022, at 7:55 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

I was looking to see what any other dmg?s I have do to handle this. Not many do. But those usually seem to use a smaller background image and icons.
I may look at that to see if I can manage something like that.

I made some changes that I think might address this. I tried to make the changes as trivial as possible.

The only change to java is in MacDmgBundler.java, the prepareDMGSetupScript method. I added?

        List <String> dmgContent = DMG_CONTENT.fetchFrom(params);
        if (dmgContent.size() > 0) {
         data.put("DEPLOY_ICON_SIZE", "64");
        }
        else {
         data.put("DEPLOY_ICON_SIZE", "128");
        }

I tried counting files in volumePath first but got a FileNotFoundException. Possibly actually a privilege access error?

I obviously added DEPLOY_ICON_SIZE to the AppleScript and changed some spacing and sizing. I wanted to be able to comfortably show up to four additional files without scrolling.

I also put in something for /Applications. I simply hard coded it to ?Applications?. This seemed the most straight forward trivial way to do this. Unless someone indicates where it is or might be something other than Applications.

I put screenshots of the before and after DMG windows at http://mikehall.pairserver.com/DMG_windows.dmg
The only after appearance drawback is extra white space at the bottom of the application only window. This could be fairly easy to correct but isn?t really that bad looking.

I appreciate the jpackage people implementing this feature and would appreciate it if they consider this, essentially, cosmetic change.

Thanks.

I mentioned this on the javafx list indicating I had discovered you could use a custom background image for the windows. I noticed in the verbose output today that jpackage indicates it currently supports this feature with a correctly named file in the resource directory. So doing anything external would be unncecessary.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221031/464004a0/attachment-0001.htm>

From smarks at openjdk.org  Mon Oct 31 21:25:41 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 31 Oct 2022 21:25:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 99:

> 97:     private static <E> List<E> toList(E... elements) {
> 98:         return JUCA.listFromTrustedArrayNullsAllowed(elements);
> 99:     }

I'm ok with using JUCA to create an unmodifiable list that can contain nulls.

However, it "trusts" the argument array, meaning that the array is assumed to be referenced exclusively and so the array reference is used directly in the resulting List object. That implies that one needs to be very careful about the array that gets passed in, otherwise, the resulting List might not actually be unmodifiable.

In particular, the call site in StringTemplate.of()

https://github.com/openjdk/jdk/pull/10889/files#diff-d4e02e5ead5ad4f2cfe509c58d1145f599285cd6736bbf37e4116045b2fd50bcR309

passes the array obtained from a List parameter that comes directly from a public call, meaning that malicious code could keep a reference to the array returned by `toArray` and modify it later. You could clone the array, or just revert back to the slow path.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From mik3hall at gmail.com  Mon Oct 31 21:40:18 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 31 Oct 2022 16:40:18 -0500
Subject: Jpackage OS/X DMG install Application folder alias name
 incorrectly shows as path with /
In-Reply-To: <C93772E9-E624-4F68-9F68-190D8F7B9B44@oracle.com>
References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
 <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>
 <CD11A95E-41FF-4E92-888E-F31610259F38@gmail.com>
 <C93772E9-E624-4F68-9F68-190D8F7B9B44@oracle.com>
Message-ID: <1D65AE81-8DF0-4849-A702-C2624085BF3A@gmail.com>



> On Oct 31, 2022, at 4:17 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,

Hello Alexander,

> 
> If I understood correctly you asking for several things:
> 
> 1) Change ?/Applications? to ?Applications?. I agree and we should fix it if possible. Did you file a bug for it? If not I can file.

I thought I did but haven?t received a number yet.

> 
> 2) Resize DMG window to show additional content which was added via --mac-dmg-content, so user does not have to scroll or manually resize window? I think we can investigate this, but I think we still need to limit by how many additional files we want to display in case if user adds for example 100 files (very unlikely). Do you want to file enhancement for this? Or I can do it.

Not only resize the window but also the icons. It gives you a better appearance than the current. I?m not sure you want to police the number of files, that would be up the user. Usually I don?t think anyone is going to include anywhere near that. I saw a few dmg?s on my machine that had two or three extra files.

> 
> 3) From your email "SceneBuilder OS/X DMG?s? do you mean provide ability to localize ?Applications? folder name? I think we can do this, but user will need to produce separate localized DMG for each language.

I don?t know that I had any responses indicating anyone is doing this or wants it. I wasn?t sure if you already were doing any localizing. If not, I don?t think its a current concern.

I already implemented changes for this. I signed the OCA so thought I might attempt the update. No clue right now what that really involves. So with the OCA signed you could probably just go ahead with my changes if you want?

I posted the change to MacDmgBundler in my prior. My changed DMGsetup.scpt is?

tell application "Finder"
  set theDisk to a reference to (disks whose URL = "DEPLOY_VOLUME_URL")
  open theDisk

  set theWindow to a reference to (container window of disks whose URL = "DEPLOY_VOLUME_URL")

  set current view of theWindow to icon view
  set toolbar visible of theWindow to false
  set statusbar visible of theWindow to false

  -- size of window should fit the size of background
  set the bounds of theWindow to {400, 100, 920, 480}

  set theViewOptions to a reference to the icon view options of theWindow
  set arrangement of theViewOptions to not arranged
  set icon size of theViewOptions to "DEPLOY_ICON_SIZE"
  set background picture of theViewOptions to POSIX file "DEPLOY_BG_FILE"

  -- Create alias for install location
  make new alias file at POSIX file "DEPLOY_VOLUME_PATH" to POSIX file "DEPLOY_INSTALL_LOCATION" with properties {name:"Applications"}

  set allTheFiles to the name of every item of theWindow
  set xpos to 120
  repeat with theFile in allTheFiles
    set theFilePath to POSIX path of theFile
    set appFilePath to POSIX path of "/DEPLOY_TARGET"
    if theFilePath is "DEPLOY_INSTALL_LOCATION" then
      -- Position install location
      set position of item theFile of theWindow to {390, 130}
    else if theFilePath ends with appFilePath then
      -- Position application or runtime
      set position of item theFile of theWindow to {120, 130}
    else
      -- Position all other items in a second row.
      set position of item theFile of theWindow to {xpos, 290}
      set xpos to xpos + 95
    end if
  end repeat


  update theDisk without registering applications
  delay 5
  close (get window of theDisk)
end tell

If you want to use that. 


From redestad at openjdk.org  Mon Oct 31 21:48:37 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 21:48:37 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v4]
In-Reply-To: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
Message-ID: <NHt3xI9zUo99V9_Nrkj-9TjfcH1gst2u5IW1PmRDITc=.01fddc15-efdd-4269-a8d5-4b6439eae16a@github.com>

> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
> 
> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
> 
> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
> 
> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
> 
> With the most recent fixes the x64 intrinsic results on my workstation look like this:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
> 
> Baseline:
> 
> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
> 
> I.e. no measurable overhead compared to baseline even for `size == 1`.
> 
> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
> 
> Benchmark for `Arrays.hashCode`:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
> 
> Baseline:
> 
> Benchmark              (size)  Mode  Cnt     Score    Error  Units
> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
> 
> 
> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Change scalar unroll to 2 element stride, minding dependency chain

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10847/files
  - new: https://git.openjdk.org/jdk/pull/10847/files/7e8a3e9c..a473c200

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=02-03

  Stats: 64 lines in 1 file changed: 28 ins; 20 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/10847.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847

PR: https://git.openjdk.org/jdk/pull/10847

From prr at openjdk.org  Mon Oct 31 22:02:15 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 31 Oct 2022 22:02:15 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Deprecate URL constructors.
Developers are encouraged to use java.net.URI to parse or construct any URL.
...
To construct a URL, using URI::toURL should be preferred.

You have jumped through some refactoring hoops to be able to apply the deprecation suppression
to as little code as possible .. having made such changes, then why didn't you just make the
recommended change instead ?

Should I presume that the recommended route will have some nasty little incompatibilities
we will need to be careful of first ?

And what about Peter Firmstone's comment
"We stopped using java.net.URI some years ago as it's obsolete.?"

I can't reconcile that with the recommendation to use it ..

-------------

PR: https://git.openjdk.org/jdk/pull/10874

From redestad at openjdk.org  Mon Oct 31 22:10:30 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 22:10:30 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v4]
In-Reply-To: <NHt3xI9zUo99V9_Nrkj-9TjfcH1gst2u5IW1PmRDITc=.01fddc15-efdd-4269-a8d5-4b6439eae16a@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <NHt3xI9zUo99V9_Nrkj-9TjfcH1gst2u5IW1PmRDITc=.01fddc15-efdd-4269-a8d5-4b6439eae16a@github.com>
Message-ID: <3ADHhMibv2q23PC2uQp57gFynSbqH6K4s0jCutZuogM=.b62084b3-bfab-4150-9b2a-e06813099ce8@github.com>

On Mon, 31 Oct 2022 21:48:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops.
>> 
>> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases.
>> 
>> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front.
>> 
>> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads.
>> 
>> With the most recent fixes the x64 intrinsic results on my workstation look like this:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.199 ?  0.017  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     6.933 ?  0.049  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    29.935 ?  0.221  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  1596.982 ?  7.020  ns/op
>> 
>> Baseline:
>> 
>> Benchmark                               (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.defaultLatin1       1  avgt    5     2.200 ?  0.013  ns/op
>> StringHashCode.Algorithm.defaultLatin1      10  avgt    5     9.424 ?  0.122  ns/op
>> StringHashCode.Algorithm.defaultLatin1     100  avgt    5    90.541 ?  0.512  ns/op
>> StringHashCode.Algorithm.defaultLatin1   10000  avgt    5  9425.321 ? 67.630  ns/op
>> 
>> I.e. no measurable overhead compared to baseline even for `size == 1`.
>> 
>> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good.
>> 
>> Benchmark for `Arrays.hashCode`:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     1.884 ?  0.013  ns/op
>> ArraysHashCode.bytes       10  avgt    5     6.955 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    87.218 ?  0.595  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9419.591 ? 38.308  ns/op
>> ArraysHashCode.chars        1  avgt    5     2.200 ?  0.010  ns/op
>> ArraysHashCode.chars       10  avgt    5     6.935 ?  0.034  ns/op
>> ArraysHashCode.chars      100  avgt    5    30.216 ?  0.134  ns/op
>> ArraysHashCode.chars    10000  avgt    5  1601.629 ?  6.418  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.200 ?  0.007  ns/op
>> ArraysHashCode.ints        10  avgt    5     6.936 ?  0.034  ns/op
>> ArraysHashCode.ints       100  avgt    5    29.412 ?  0.268  ns/op
>> ArraysHashCode.ints     10000  avgt    5  1610.578 ?  7.785  ns/op
>> ArraysHashCode.shorts       1  avgt    5     1.885 ?  0.012  ns/op
>> ArraysHashCode.shorts      10  avgt    5     6.961 ?  0.034  ns/op
>> ArraysHashCode.shorts     100  avgt    5    87.095 ?  0.417  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.617 ? 50.089  ns/op
>> 
>> Baseline:
>> 
>> Benchmark              (size)  Mode  Cnt     Score    Error  Units
>> ArraysHashCode.bytes        1  avgt    5     3.213 ?  0.207  ns/op
>> ArraysHashCode.bytes       10  avgt    5     8.483 ?  0.040  ns/op
>> ArraysHashCode.bytes      100  avgt    5    90.315 ?  0.655  ns/op
>> ArraysHashCode.bytes    10000  avgt    5  9422.094 ? 62.402  ns/op
>> ArraysHashCode.chars        1  avgt    5     3.040 ?  0.066  ns/op
>> ArraysHashCode.chars       10  avgt    5     8.497 ?  0.074  ns/op
>> ArraysHashCode.chars      100  avgt    5    90.074 ?  0.387  ns/op
>> ArraysHashCode.chars    10000  avgt    5  9420.474 ? 41.619  ns/op
>> ArraysHashCode.ints         1  avgt    5     2.827 ?  0.019  ns/op
>> ArraysHashCode.ints        10  avgt    5     7.727 ?  0.043  ns/op
>> ArraysHashCode.ints       100  avgt    5    89.405 ?  0.593  ns/op
>> ArraysHashCode.ints     10000  avgt    5  9426.539 ? 51.308  ns/op
>> ArraysHashCode.shorts       1  avgt    5     3.071 ?  0.062  ns/op
>> ArraysHashCode.shorts      10  avgt    5     8.168 ?  0.049  ns/op
>> ArraysHashCode.shorts     100  avgt    5    90.399 ?  0.292  ns/op
>> ArraysHashCode.shorts   10000  avgt    5  9420.171 ? 44.474  ns/op
>> 
>> 
>> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change scalar unroll to 2 element stride, minding dependency chain

A stride of 2 allows small element cases to perform a bit better, while also performing better than before on longer arrays for the `byte` and `short` cases that don't get any benefit from vectorization:


Benchmark              (size)  Mode  Cnt     Score     Error  Units
ArraysHashCode.bytes        1  avgt    5     1.414 ?   0.005  ns/op
ArraysHashCode.bytes       10  avgt    5     6.908 ?   0.020  ns/op
ArraysHashCode.bytes      100  avgt    5    73.666 ?   0.390  ns/op
ArraysHashCode.bytes    10000  avgt    5  7846.994 ?  53.628  ns/op
ArraysHashCode.chars        1  avgt    5     1.414 ?   0.007  ns/op
ArraysHashCode.chars       10  avgt    5     7.229 ?   0.044  ns/op
ArraysHashCode.chars      100  avgt    5    30.718 ?   0.229  ns/op
ArraysHashCode.chars    10000  avgt    5  1621.463 ? 116.286  ns/op
ArraysHashCode.ints         1  avgt    5     1.414 ?   0.008  ns/op
ArraysHashCode.ints        10  avgt    5     7.540 ?   0.042  ns/op
ArraysHashCode.ints       100  avgt    5    29.429 ?   0.121  ns/op
ArraysHashCode.ints     10000  avgt    5  1600.855 ?   9.274  ns/op
ArraysHashCode.shorts       1  avgt    5     1.414 ?   0.010  ns/op
ArraysHashCode.shorts      10  avgt    5     6.914 ?   0.045  ns/op
ArraysHashCode.shorts     100  avgt    5    73.684 ?   0.501  ns/op
ArraysHashCode.shorts   10000  avgt    5  7846.829 ?  49.984  ns/op


I've also made some changes to improve the String cases, which can avoid the first coeff*h multiplication on first pass. This gets the size 1 latin1 case down to 1.1ns/op without penalizing the empty case. We're now improving over the baseline on almost all* tested sizes:


Benchmark                               (size)  Mode  Cnt   Score   Error  Units
StringHashCode.Algorithm.defaultLatin1       0  avgt    5   0.946 ? 0.005  ns/op
StringHashCode.Algorithm.defaultLatin1       1  avgt    5   1.108 ? 0.003  ns/op
StringHashCode.Algorithm.defaultLatin1       2  avgt    5   2.042 ? 0.005  ns/op
StringHashCode.Algorithm.defaultLatin1      31  avgt    5  18.636 ? 0.286  ns/op
StringHashCode.Algorithm.defaultLatin1      32  avgt    5  15.938 ? 1.086  ns/op
StringHashCode.Algorithm.defaultUTF16        0  avgt    5   1.257 ? 0.004  ns/op
StringHashCode.Algorithm.defaultUTF16        1  avgt    5   2.198 ? 0.005  ns/op
StringHashCode.Algorithm.defaultUTF16        2  avgt    5   2.559 ? 0.011  ns/op
StringHashCode.Algorithm.defaultUTF16       31  avgt    5  15.754 ? 0.036  ns/op
StringHashCode.Algorithm.defaultUTF16       32  avgt    5  16.616 ? 0.042  ns/op


Baseline:

Benchmark                               (size)  Mode  Cnt   Score   Error  Units
StringHashCode.Algorithm.defaultLatin1       0  avgt    5   0.942 ? 0.005  ns/op
StringHashCode.Algorithm.defaultLatin1       1  avgt    5   1.991 ? 0.013  ns/op
StringHashCode.Algorithm.defaultLatin1       2  avgt    5   2.831 ? 0.021  ns/op
StringHashCode.Algorithm.defaultLatin1      31  avgt    5  25.042 ? 0.112  ns/op
StringHashCode.Algorithm.defaultLatin1      32  avgt    5  25.857 ? 0.133  ns/op
StringHashCode.Algorithm.defaultUTF16        0  avgt    5   0.789 ? 0.006  ns/op
StringHashCode.Algorithm.defaultUTF16        1  avgt    5   3.459 ? 0.007  ns/op
StringHashCode.Algorithm.defaultUTF16        2  avgt    5   4.400 ? 0.010  ns/op
StringHashCode.Algorithm.defaultUTF16       31  avgt    5  25.721 ? 0.067  ns/op
StringHashCode.Algorithm.defaultUTF16       32  avgt    5  27.162 ? 0.093  ns/op


There's a negligible regression on `defaultUTF16` for size = 0 due moving the length shift up earlier. This can only happen when running with CompactStrings disabled. And even if you were the change significantly helps improve size 1-31, which should more than make up for a small cost increase hashing empty strings.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From redestad at openjdk.org  Mon Oct 31 22:10:31 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 31 Oct 2022 22:10:31 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v4]
In-Reply-To: <L2WAjZaNyLgTJp85sijndF0GLYMMAPObB3ncl3u-U6w=.b2d6a5e6-8aa0-4328-b11e-b258d78e9f4b@github.com>
References: <dVSdMEOd_hypt89L5-2Hcx56M11WYpGwsHh33lHgxbY=.0a3e0288-8498-4166-b40b-e9851222ad64@github.com>
 <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com>
 <ItgEUpQqe5_lJReITrZWgr5SbqUS1kAanJsyqzhzNuE=.2b5b0e1e-1dc4-4cf3-8d0e-a61d8a4c439c@github.com>
 <L2WAjZaNyLgTJp85sijndF0GLYMMAPObB3ncl3u-U6w=.b2d6a5e6-8aa0-4328-b11e-b258d78e9f4b@github.com>
Message-ID: <yyuuqDrwV-WVFKe6dUzIp_Eo_z4m_GKQoYx-pJna3CM=.6ef3d30c-4b2a-4e8d-ba1d-3776e9eb8147@github.com>

On Mon, 31 Oct 2022 13:35:36 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> But doing it forward requires a `reduceLane` on each iteration. It's faster to do it backward.
>
> No you don't need to, the vector loop can be calculated as:
> 
>     IntVector accumulation = IntVector.zero(INT_SPECIES);
>     for (int i = 0; i < bound; i += INT_SPECIES.length()) {
>         IntVector current = IntVector.load(INT_SPECIES, array, i);
>         accumulation = accumulation.mul(31**(INT_SPECIES.length())).add(current);
>     }
>     return accumulation.mul(IntVector.of(31**INT_SPECIES.length() - 1, ..., 31**2, 31, 1).reduce(ADD);
> 
> Each iteration only requires a multiplication and an addition. The weight of lanes can be calculated just before the reduction operation.

Ok, I can try rewriting as @merykitty suggests and compare. I'm running out of time to spend on this right now, though, so I sort of hope we can do this experiment as a follow-up RFE.

-------------

PR: https://git.openjdk.org/jdk/pull/10847

From bpb at openjdk.org  Mon Oct 31 22:21:54 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 31 Oct 2022 22:21:54 GMT
Subject: Integrated: 8156593: DataOutput.write(byte[],int,int) and its
 implementations do not specify index out bounds
In-Reply-To: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
References: <A_AARM_NPWwykpNtn9AHfM2TXcE88NRgct3i0fX56ww=.25b6e526-6615-4938-a7ac-12651667f6f7@github.com>
Message-ID: <dCg6VSFbyiZ73kyK4EmXX82dbLUYJUo1mEbGNLghvZ0=.2fd45b91-5528-42f4-aa76-904bb5f4c6ef@github.com>

On Thu, 27 Oct 2022 20:35:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `@throws IndexOutOfBoundsException {@inheritDoc}` to some `write(byte[],int,int)` and `read(byte[],int,int)` methods of some classes in the `java.io` package to make things a bit clearer.

This pull request has now been integrated.

Changeset: 4999f2cb
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4999f2cb164743ebf4badd3848a862609528dde3
Stats:     17 lines in 11 files changed: 15 ins; 0 del; 2 mod

8156593: DataOutput.write(byte[],int,int) and its implementations do not specify index out bounds

Reviewed-by: alanb, aturbanov

-------------

PR: https://git.openjdk.org/jdk/pull/10890

From duke at openjdk.org  Mon Oct 31 22:30:30 2022
From: duke at openjdk.org (iaroslavski)
Date: Mon, 31 Oct 2022 22:30:30 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v17]
In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
Message-ID: <Wc6GiqLqSYG8dZPmPtTqqzOcKDoHCCRqsNKAhtLlzIE=.98d709aa-d6d7-446d-828f-1b9a041b8879@github.com>

> Sorting:
> 
> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single element
> - minor javadoc and comment changes
> 
> Testing:
> - add new data inputs in tests for sorting
> - add min/max/infinity values to float/double testing
> - add tests for radix sort

iaroslavski has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
  
  * Optimized mixed insertion sort
  * Optimized insertion sort
  * Optimized Radix sort
  * Updated microbenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/3938/files
  - new: https://git.openjdk.org/jdk/pull/3938/files/fcda2aa8..4772617d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=15-16

  Stats: 7181 lines in 4 files changed: 33 ins; 366 del; 6782 mod
  Patch: https://git.openjdk.org/jdk/pull/3938.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/3938/head:pull/3938

PR: https://git.openjdk.org/jdk/pull/3938

From alexander.matveev at oracle.com  Mon Oct 31 22:56:39 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 31 Oct 2022 22:56:39 +0000
Subject: [External] : Re: Jpackage OS/X DMG install Application folder
 alias name incorrectly shows as path with /
In-Reply-To: <1D65AE81-8DF0-4849-A702-C2624085BF3A@gmail.com>
References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
 <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>
 <CD11A95E-41FF-4E92-888E-F31610259F38@gmail.com>
 <C93772E9-E624-4F68-9F68-190D8F7B9B44@oracle.com>
 <1D65AE81-8DF0-4849-A702-C2624085BF3A@gmail.com>
Message-ID: <8A239F65-F7A4-44D1-963C-9754FBDF321E@oracle.com>

Hi Michael,

On Oct 31, 2022, at 2:40 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Oct 31, 2022, at 4:17 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Michael,

Hello Alexander,


If I understood correctly you asking for several things:

1) Change ?/Applications? to ?Applications?. I agree and we should fix it if possible. Did you file a bug for it? If not I can file.

I thought I did but haven?t received a number yet.
I did not able to find a bug you filed, so filed a new one:
https://bugs.openjdk.org/browse/JDK-8296154



2) Resize DMG window to show additional content which was added via --mac-dmg-content, so user does not have to scroll or manually resize window? I think we can investigate this, but I think we still need to limit by how many additional files we want to display in case if user adds for example 100 files (very unlikely). Do you want to file enhancement for this? Or I can do it.

Not only resize the window but also the icons. It gives you a better appearance than the current. I?m not sure you want to police the number of files, that would be up the user. Usually I don?t think anyone is going to include anywhere near that. I saw a few dmg?s on my machine that had two or three extra files.
I filed https://bugs.openjdk.org/browse/JDK-8296156 for this.

Thanks,
Alexander



3) From your email "SceneBuilder OS/X DMG?s? do you mean provide ability to localize ?Applications? folder name? I think we can do this, but user will need to produce separate localized DMG for each language.

I don?t know that I had any responses indicating anyone is doing this or wants it. I wasn?t sure if you already were doing any localizing. If not, I don?t think its a current concern.

I already implemented changes for this. I signed the OCA so thought I might attempt the update. No clue right now what that really involves. So with the OCA signed you could probably just go ahead with my changes if you want?

I posted the change to MacDmgBundler in my prior. My changed DMGsetup.scpt is?

tell application "Finder"
 set theDisk to a reference to (disks whose URL = "DEPLOY_VOLUME_URL")
 open theDisk

 set theWindow to a reference to (container window of disks whose URL = "DEPLOY_VOLUME_URL")

 set current view of theWindow to icon view
 set toolbar visible of theWindow to false
 set statusbar visible of theWindow to false

 -- size of window should fit the size of background
 set the bounds of theWindow to {400, 100, 920, 480}

 set theViewOptions to a reference to the icon view options of theWindow
 set arrangement of theViewOptions to not arranged
 set icon size of theViewOptions to "DEPLOY_ICON_SIZE"
 set background picture of theViewOptions to POSIX file "DEPLOY_BG_FILE"

 -- Create alias for install location
 make new alias file at POSIX file "DEPLOY_VOLUME_PATH" to POSIX file "DEPLOY_INSTALL_LOCATION" with properties {name:"Applications"}

 set allTheFiles to the name of every item of theWindow
 set xpos to 120
 repeat with theFile in allTheFiles
   set theFilePath to POSIX path of theFile
   set appFilePath to POSIX path of "/DEPLOY_TARGET"
   if theFilePath is "DEPLOY_INSTALL_LOCATION" then
     -- Position install location
     set position of item theFile of theWindow to {390, 130}
   else if theFilePath ends with appFilePath then
     -- Position application or runtime
     set position of item theFile of theWindow to {120, 130}
   else
     -- Position all other items in a second row.
     set position of item theFile of theWindow to {xpos, 290}
     set xpos to xpos + 95
   end if
 end repeat


 update theDisk without registering applications
 delay 5
 close (get window of theDisk)
end tell

If you want to use that.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221031/2170c509/attachment-0001.htm>

From mik3hall at gmail.com  Mon Oct 31 23:21:18 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 31 Oct 2022 18:21:18 -0500
Subject: [External] : Re: Jpackage OS/X DMG install Application folder
 alias name incorrectly shows as path with /
In-Reply-To: <8A239F65-F7A4-44D1-963C-9754FBDF321E@oracle.com>
References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
 <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>
 <CD11A95E-41FF-4E92-888E-F31610259F38@gmail.com>
 <C93772E9-E624-4F68-9F68-190D8F7B9B44@oracle.com>
 <1D65AE81-8DF0-4849-A702-C2624085BF3A@gmail.com>
 <8A239F65-F7A4-44D1-963C-9754FBDF321E@oracle.com>
Message-ID: <4FDC3A61-63E7-43FD-BA5D-C4675D5A9B18@gmail.com>



> On Oct 31, 2022, at 5:56 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
>> On Oct 31, 2022, at 2:40 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>> 
>>> On Oct 31, 2022, at 4:17 PM, Alexander Matveev <alexander.matveev at oracle.com <mailto:alexander.matveev at oracle.com>> wrote:
>>> 
>>> Hi Michael,
>> 
>> Hello Alexander,
>> 
>>> 
>>> If I understood correctly you asking for several things:
>>> 
>>> 1) Change ?/Applications? to ?Applications?. I agree and we should fix it if possible. Did you file a bug for it? If not I can file.
>> 
>> I thought I did but haven?t received a number yet.
> I did not able to find a bug you filed, so filed a new one:
> https://bugs.openjdk.org/browse/JDK-8296154 <https://bugs.openjdk.org/browse/JDK-8296154>
> 

Alexander,

OK thanks.
If you happen to look at the dmg with images I provided an URL for I think my changes lay the added files out pretty well.
I think you definitely want to go with smaller icons. Apache OpenOffice has a DMG I just found with a couple additional files that uses smaller icons.
I think this is a pretty normal thing to do.
Even with smaller icons I had to increase the window bottom parameter to get them not to get chopped off.

set the bounds of theWindow to {400, 100, 920, 480}

That the last 480 in the above. 
Given the smaller icons I also decreased to x coordinate increment. Made fitting more files a little easier.

You can do this yourself but I think you will find doing similar works best.

Thanks,
Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221031/9a31b725/attachment.htm>

From alexander.matveev at oracle.com  Mon Oct 31 23:57:00 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 31 Oct 2022 23:57:00 +0000
Subject: [External] : Re: Jpackage OS/X DMG install Application folder
 alias name incorrectly shows as path with /
In-Reply-To: <4FDC3A61-63E7-43FD-BA5D-C4675D5A9B18@gmail.com>
References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com>
 <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com>
 <CD11A95E-41FF-4E92-888E-F31610259F38@gmail.com>
 <C93772E9-E624-4F68-9F68-190D8F7B9B44@oracle.com>
 <1D65AE81-8DF0-4849-A702-C2624085BF3A@gmail.com>
 <8A239F65-F7A4-44D1-963C-9754FBDF321E@oracle.com>
 <4FDC3A61-63E7-43FD-BA5D-C4675D5A9B18@gmail.com>
Message-ID: <5F5D63E8-06F9-4928-AD08-61958E1B9C7D@oracle.com>

Hi Michael.

If you mean http://mikehall.pairserver.com/DMG_windows.dmg, then I cannot open this link. It says file not found.

Thanks,
Alexander

On Oct 31, 2022, at 4:21 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Oct 31, 2022, at 5:56 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Michael,

On Oct 31, 2022, at 2:40 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Oct 31, 2022, at 4:17 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Michael,

Hello Alexander,


If I understood correctly you asking for several things:

1) Change ?/Applications? to ?Applications?. I agree and we should fix it if possible. Did you file a bug for it? If not I can file.

I thought I did but haven?t received a number yet.
I did not able to find a bug you filed, so filed a new one:
https://bugs.openjdk.org/browse/JDK-8296154


Alexander,

OK thanks.
If you happen to look at the dmg with images I provided an URL for I think my changes lay the added files out pretty well.
I think you definitely want to go with smaller icons. Apache OpenOffice has a DMG I just found with a couple additional files that uses smaller icons.
I think this is a pretty normal thing to do.
Even with smaller icons I had to increase the window bottom parameter to get them not to get chopped off.

set the bounds of theWindow to {400, 100, 920, 480}

That the last 480 in the above.
Given the smaller icons I also decreased to x coordinate increment. Made fitting more files a little easier.

You can do this yourself but I think you will find doing similar works best.

Thanks,
Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221031/6019b2e8/attachment-0001.htm>