8279614: The left line of the TitledBorder is not painted on 150 scale factor #7449

alisenchung · 2022-02-11T23:44:22Z

Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8279614: The left line of the TitledBorder is not painted on 150 scale factor

Reviewers

Alexander Zuev (@azuev-java - Reviewer) ⚠️ Review applies to 7b7732f8
Alexey Ivanov (@aivanov-jdk - Reviewer)
Phil Race (@prrace - Reviewer) ⚠️ Review applies to 325d09b4

Contributors

Alexey Ivanov <[email protected]>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/7449/head:pull/7449
$ git checkout pull/7449

Update a local copy of the PR:
$ git checkout pull/7449
$ git pull https://git.openjdk.org/jdk pull/7449/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 7449

View PR using the GUI difftool:
$ git pr show -t 7449

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/7449.diff

…e factor

bridgekeeper · 2022-02-11T23:44:43Z

👋 Welcome back achung! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-02-11T23:47:10Z

@alisenchung The following label will be automatically applied to this pull request:

client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mrserb · 2022-02-12T01:08:30Z

test/jdk/java/awt/TitledBorder/TitledBorderTest.java

+      System.out.println("Color " + buff.getRGB(21, 80));
+      saveImage(buff, "test.png");
+      throw new RuntimeException("Border was clipped or overdrawn.");
+    }


Can we draw directly to the buffered image using the scaled graphics to reproduce the bug?

Yea, the test fails before the fix, and when inspecting the saved image it looks identical to the actual frame.

mrserb · 2022-02-12T01:09:24Z

test/jdk/java/awt/TitledBorder/TitledBorderTest.java

@@ -0,0 +1,97 @@
+import java.awt.BorderLayout;


To prevent all this jcheck issue you can install the jcheck hook locally.

mrserb · 2022-02-12T01:10:49Z

src/java.desktop/share/classes/javax/swing/border/TitledBorder.java

-                        path.append(new Rectangle(borderX, labelY, labelX - borderX - TEXT_SPACING, labelH), false);
-                        path.append(new Rectangle(labelX + labelW + TEXT_SPACING, labelY, borderX - labelX + borderW - labelW - TEXT_SPACING, labelH), false);
-                        path.append(new Rectangle(borderX, labelY + labelH, borderW, borderY - labelY + borderH - labelH), false);
+                        path.append(new Rectangle2D.Float((float) borderX, borderY, borderW, labelY - borderY), false);


Why the current coordinates do not work, is it because we calculate them in the wrong way or probably the insets are wrong?

I think there's a rounding error when doing x.5 scalings causing the drawing area to be one pixel too small on the left side

Can you please check how it will work for the undecorated frame, if it will be fine then the problem is somehow related to the size of the insets.

The undecorated frame has no problems

@mrserb I've been trying to manually adjust the insets/variables to see what could be causing the issue, but only decreasing borderX by 1 seems to fix the issue. Could you clarify what you can gather from the undecorated frame working?

mlbridge · 2022-02-14T17:13:31Z

Webrevs

alisenchung · 2022-03-04T00:45:33Z

I've updated the fix to stop overdrawing, please review @mrserb @prrace @prsadhuk

prrace · 2022-03-04T21:31:55Z

Can you explain (walk through) why the old code was wrong and the new code is correct ?
There's a lot of things that aren't obvious to me.
The old code would use the same coords and just toggle which parts were in highlight/shadow
Now you've spilit is so that lowered does things in a different order and so forth and I find it
impossible without an explanation of your reasoning to say if that reasoning is correct ...

Also the bug report deserves an evaluation.

alisenchung · 2022-03-05T01:56:04Z

Can you explain (walk through) why the old code was wrong and the new code is correct ? There's a lot of things that aren't obvious to me. The old code would use the same coords and just toggle which parts were in highlight/shadow Now you've spilit is so that lowered does things in a different order and so forth and I find it impossible without an explanation of your reasoning to say if that reasoning is correct ...

Also the bug report deserves an evaluation.

I think currently the problem is the lighter color is overdrawing the darker color, so I swapped the drawing order so that the darker color is always drawn second. I think the reason the rect and lines are drawn at the same x value probably has to do with the affine transform in the graphics object, but I'm not sure why it happens.

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

alisenchung · 2022-03-14T16:11:08Z

I just added the functions Phil suggested, @azuev-java could you also review?

azuev-java

Latest version looks Ok to me.

openjdk · 2022-03-14T17:37:57Z

@alisenchung This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8279614: The left line of the TitledBorder is not painted on 150 scale factor

Co-authored-by: Alexey Ivanov <[email protected]>
Reviewed-by: kizune, aivanov, prr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 2031 new commits pushed to the master branch:

53a0ace: 8286101: Support formatting in @value tag
8f400b9: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true'
e0baf01: 8287007: [cgroups] Consistently use stringStream throughout parsing code
1769596: 8285263: Minor cleanup could be done in java.security
b97a4f6: 8288114: Update JIRA link in vcs.xml
2adef6a: 8267860: Off-by-one bug when searching arrays in AlpnGreaseTest
4aede33: 8288282: Zero-release build is broken after JDK-8279047 due to UseHeavyMonitors is read-only
0207d76: 8287926: AArch64: intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long
33ed036: 8283775: better dump: VM support for graph querying in debugger with BFS traversal and node filtering
ac28be7: 8283612: IGV: Remove Graal module
... and 2021 more: https://git.openjdk.org/jdk/compare/ab490534a1d14ad48ceb532ec1673ca9636f552d...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@azuev-java, @aivanov-jdk, @prrace) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

aivanov-jdk

The test uses 2 spaces for indentation. It should use 4 spaces for each level of indentation.

aivanov-jdk · 2022-03-14T19:28:32Z

src/java.desktop/share/classes/javax/swing/border/TitledBorder.java

 import java.awt.Insets;
 import java.awt.Rectangle;
 import java.awt.geom.Path2D;
+import java.awt.geom.Rectangle2D;


This import isn't used. There are no other changes to this file but this added import.

In addition to it, you can also remove java.beans.PropertyChangeEvent from imports which is unused as well.

Either revert the changes to TitledBorder or remove the two unused imports: java.awt.geom.Rectangle2D and java.beans.PropertyChangeEvent.

aivanov-jdk · 2022-03-14T19:30:47Z

test/jdk/java/awt/TitledBorder/TitledBorderTest.java

+  public static JPanel childPanel;
+
+  public static void main(String[] args) throws Exception {
+    LookAndFeelInfo laf = UIManager.getInstalledLookAndFeels()[3];


Is the test needs to be run in a specific LookAndFeel? If so, you have to set explicitly rather than rely on the order of LAFs.

aivanov-jdk · 2022-03-14T20:47:38Z

test/jdk/java/awt/TitledBorder/TitledBorderTest.java

+    BufferedImage buff = new BufferedImage(frame.getWidth()*2, frame.getHeight()*2,
+            BufferedImage.TYPE_INT_ARGB);
+    Graphics2D graph = buff.createGraphics();
+    graph.scale(1.5, 1.5);
+    frame.paint(graph);
+    graph.dispose();


If we paint to BufferedImage, it makes sense to bypass creating and showing the frame, a panel with TitledBorder will be enough. In this case, the test can be headless.

Shall we run the test with a set of scales: 1.00, 1.25, 1.50, 1.75, 2.00?

Without the fix, the left line looks clipped at 2.0 scale too: the shadow is 1-pixel wide on the left whereas the highlight is 2-pixel wide on the four edges.

aivanov-jdk · 2022-03-14T20:48:11Z

test/jdk/java/awt/TitledBorder/TitledBorderTest.java

+    boolean testFail = true;
+    for (int i = 15; i < 25 && testFail == true; i++) {
+      for (int j = 80; j < 100; j++) {
+        if (buff.getRGB(i, j) == -6250336) {


Using hex for colors is better.

Getting the highlight or shadow color from the border would make the test more generic. If the color used by border changes, the test will fail but it shouldn't.

aivanov-jdk · 2022-03-14T20:51:38Z

test/jdk/java/awt/TitledBorder/TitledBorderTest.java

+    try {
+      ImageIO.write(image, "png", new File(filename));
+    } catch (IOException e) {
+      // Don’t propagate the exception


I recommend using a regular apostrophe (') instead of typographic one (’). It shouldn't cause issues with compiling because it's in the comment, yet the character may be displayed incorrectly if the default system encoding doesn't match the encoding of the file.

aivanov-jdk · 2022-03-14T20:57:26Z

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

+        // 8279614: The dark line was being overdrawn by the light line. The fix was to
+        // make sure that the dark line is always drawn second.


Suggested change

// 8279614: The dark line was being overdrawn by the light line. The fix was to

// make sure that the dark line is always drawn second.

// 8279614: The dark line was overdrawn by the light line.

// The fix makes sure that the dark line is always drawn second.

Does the opposite never happen? That the shadow overdraws the highlight.

This is a comment on the actual comment rather than whether the intent is correct.
I'm not in favour of putting bug ids into the comments. Our code will end up utterly cluttered with them
Also it is phrased to describe a fix.
So IF it were to stand as is, I would have phrased it as "what we are doing now and why", ie
// Make sure the shadow line always is drawn second because it needs to over draw the border.

I should've posted my question separately rather than as a comment to the comment.

aivanov-jdk · 2022-03-14T22:59:14Z

Can you explain (walk through) why the old code was wrong and the new code is correct ? There's a lot of things that aren't obvious to me. The old code would use the same coords and just toggle which parts were in highlight/shadow Now you've spilit is so that lowered does things in a different order and so forth and I find it impossible without an explanation of your reasoning to say if that reasoning is correct ...
Also the bug report deserves an evaluation.

I think currently the problem is the lighter color is overdrawing the darker color, so I swapped the drawing order so that the darker color is always drawn second. I think the reason the rect and lines are drawn at the same x value probably has to do with the affine transform in the graphics object, but I'm not sure why it happens.

Is it possible that in the new order the darker colour is drawn over the lighter one?

alisenchung · 2022-03-14T23:03:59Z

I think you're right that now the darker colour is drawing over the lighter one. I'm currently changing the drawing of the border to take into account the scaling to prevent either color from overdrawing.

aivanov-jdk · 2022-03-14T23:27:06Z

I believe the issue is broader. I modified the test to display four panels, each panel is moved pixel to the left. The screenshots below are taken with the current JDK code without Alisen's fix.

125%

150%

When uiScale=1.25, you can see there's background color between the shadow and highlight on the second panel. The same problem is seen for the upper border. When uiScale=1.5, you can see that some lines are 2-pixel wide and some are 1-pixel wide.

I believe it's because of rounding. I don't know how we can make sure the lines are always drawn next to each other and always have the same thickness.

lukeu · 2022-03-15T16:51:56Z

Good catch. I'm not in a position to build this patch right now, but I suspect that if you put such a border in the right-hand-side of a splitter pane, then as you drag the splitter's divider, the light lines would still be jumping in and out from underneath the dark ones and/or 'jiggling' in width. (When tested at 125%, 175% etc)

I believe it's because of rounding. I don't know how we can make sure the lines are always drawn next to each other and always have the same thickness.

I believe the only way to get pixel-perfect (& balanced weight) rendering of 2 lines next to each other at non-integer scale factors, when using integer based APIs like drawLine, will be to undo the affine transformation upon the pre-scaled Graphics2D object, and render it at 1x scaling. Then you'd need to decide how to compute the desired line thickness (like: should it jump 1px > 2px at 150% scaling or 175% scaling?)

(IMHO, the JDK-9+ approach of passing in a pre-scaled Graphics object is a bit of a coarse approximation - useful for components that haven't natively considered HiDPI yet. I'm happy to see the built-in L&F code being improved in cases like this; while noting that there are many more.)

lukeu · 2022-03-16T01:09:06Z

OK after many hours of "bash"ing, I've convinced the JDK, cygwin and VS-2017 to play nicely again :-)

My suspicions were close: the lines jump apart, rather than overlap at 125%, and jiggle between 1 & 2px at 175%. The following screenshot is with the patched code at 125% display scaling on Windows, then zoomed in 3x:

Each subsequent titled border is offset 1 extra pixel (as given in the code) to the right, and you can see only the 3rd lets the background between the lines on the left side, at this particular splitter position. If it might be of use, here's my interactive test harness:

import java.awt.*;
import javax.swing.*;

public class Test {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Test()::run);
    }

    private void run() {
        try {
            UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
        } catch (Exception e) {
            e.printStackTrace();
        }
        var frame = new JFrame();
        frame.getContentPane().add(createSplitters());
        frame.setSize(new Dimension(800, 600));
        frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
        frame.setVisible(true);
    }

    private JSplitPane createSplitters() {
        return createSplit(
                JSplitPane.HORIZONTAL_SPLIT,
                new JPanel(),
                createSplit(
                        JSplitPane.VERTICAL_SPLIT,
                        new JPanel(),
                        createTestArea()));
    }

    private JSplitPane createSplit(int dir, JComponent left, JComponent right) {
        var split = new JSplitPane(dir, true, left, right);
        split.setDividerLocation(200);
        return split;
    }

    private Box createTestArea() {
        Box box = Box.createVerticalBox();
        box.add(createBorderedCheckbox(1));
        box.add(createBorderedCheckbox(2));
        box.add(createBorderedCheckbox(3));
        return box;
    }

    private JComponent createBorderedCheckbox(int i) {
        JPanel childPanel = new JPanel(new BorderLayout());
        childPanel.setBorder(BorderFactory.createCompoundBorder(
                BorderFactory.createEmptyBorder(0, i, 0, 0),
                BorderFactory.createTitledBorder("Title " + i)));
        childPanel.add(new JCheckBox(), BorderLayout.CENTER);
        childPanel.setBackground(new Color(190, 190 + 20 * i , 190));
        return childPanel;
    }
}

aivanov-jdk · 2022-06-08T21:16:44Z

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

+            RenderingHints rend =
+                    new RenderingHints(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE);


If using VALUE_STROKE_PURE changes nothing, should it be removed then?

Moreover, the hints aren't applied to anything.

aivanov-jdk · 2022-06-08T21:22:05Z

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java


-        g.translate(-x, -y);
+        // Set the transform we removed earlier
+        if (g instanceof Graphics2D) {


The condition should be

Suggested change

if (g instanceof Graphics2D) {

if (resetTransform) {

If resetTransform is true, then g is an instance of Graphics2D.

If resetTransform is false, there's nothing to restore anyway.

aivanov-jdk · 2022-06-08T21:30:28Z

test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java

+ * @test
+ * @bug 8279614
+ * @summary The left line of the TitledBorder is not painted on 150 scale factor
+ * @requires (os.family == "windows")


It's still unclear to me whether we leave the requirement for Windows only or remove it. It came up a few times but no clear decision has been taken.

The change is not Windows-specific, the test is not Windows-specific, it can be run on other platforms. However, fractional UI scales aren't supported on other platforms but Windows; at the same time, applying fractional scales to Graphics when painting to a BufferedImage is supported.

I think it sufficient to make it Windows-specific at this time.
The BufferedImage case is extremely uncommon.
Mac is integer only and we don't have any timeline for supporting fractional scaling on Linux

Sounds reasonable. Let's leave it Windows-specific.

aivanov-jdk

Looks good to me.

The question about limiting the test to Windows only is still open.

aivanov-jdk · 2022-06-08T22:41:55Z

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

+        AffineTransform at = new AffineTransform();
+        Stroke oldStk = new BasicStroke();
+        int stkWidth = 1;


Now the usage of these variables is restricted to the case where resetTransform is set to true. Therefore, they can be left uninitialised here; a value is assigned before it's used in all the code paths as far as I can see.

It's just a small (premature) optimisation, it avoids creating two objects. I don't insist though.

I'd be inclined to remove the initialisation.

I see, the static analyser is not smart enough to notice that the variables get initialised before they're used.

To resolve the error, initialise at and oldStk with null.

stkWidth needs to be initialised by 1 as it's currently done, its value is used even if resetTransform remains false.

Yes, seems the code logic is too much for the compiler
intuitively I'd have expected that it should be, but you'd need to restructure to fix it ..

aivanov-jdk · 2022-06-10T19:53:57Z

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

-import java.awt.Rectangle;
 import java.awt.Color;
 import java.awt.Component;
+import java.awt.RenderingHints;


RenderingHints aren't used, to be removed.

aivanov-jdk

Please remove import java.awt.RenderingHints; from EtchedBorder.java.

alisenchung · 2022-06-13T18:18:05Z

/integrate

openjdk · 2022-06-13T18:19:51Z

@alisenchung
Your change (at version d4ad493) is now ready to be sponsored by a Committer.

aivanov-jdk · 2022-06-13T20:02:36Z

/sponsor

openjdk · 2022-06-13T20:05:24Z

Going to push as commit b42c1ad.
Since your change was applied there have been 2032 commits pushed to the master branch:

9b6d0a7: 8285838: DST not applying properly with zone id offset set with TZ env variable
53a0ace: 8286101: Support formatting in @value tag
8f400b9: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true'
e0baf01: 8287007: [cgroups] Consistently use stringStream throughout parsing code
1769596: 8285263: Minor cleanup could be done in java.security
b97a4f6: 8288114: Update JIRA link in vcs.xml
2adef6a: 8267860: Off-by-one bug when searching arrays in AlpnGreaseTest
4aede33: 8288282: Zero-release build is broken after JDK-8279047 due to UseHeavyMonitors is read-only
0207d76: 8287926: AArch64: intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long
33ed036: 8283775: better dump: VM support for graph querying in debugger with BFS traversal and node filtering
... and 2022 more: https://git.openjdk.org/jdk/compare/ab490534a1d14ad48ceb532ec1673ca9636f552d...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-06-13T20:05:49Z

@aivanov-jdk @alisenchung Pushed as commit b42c1ad.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

…systems This fix is based on a similar approach as described here openjdk#7449 (comment). We rescale the line border to render the textfield border correctly, so that all sides of the textfield border are of same thickness.

alichung added 3 commits February 8, 2022 12:12

initial commit

c368173

finished test

6e24762

8279614: The left line of the TitledBorder is not painted on 150 scal…

b2e9240

…e factor

openjdk bot added the client [email protected] label Feb 11, 2022

mrserb reviewed Feb 12, 2022

View reviewed changes

alichung added 3 commits February 14, 2022 09:00

changed carriage return

4c8d5bf

changed carriage return

f314462

trailing whitespace, add extra newline at eof

c0b3189

openjdk bot added the rfr Pull request is ready for review label Feb 14, 2022

alichung added 3 commits March 3, 2022 12:11

reverted old change, swapped order of painting to prevent overdrawing

47437d9

typo

88c1b1a

adjusted pixels to check for border

6056faf

prrace reviewed Mar 11, 2022

View reviewed changes

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java Outdated Show resolved Hide resolved

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java Outdated Show resolved Hide resolved

added functions for drawing border, fixed translate

7b7732f

azuev-java approved these changes Mar 14, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Mar 14, 2022

aivanov-jdk suggested changes Mar 14, 2022

View reviewed changes

fixed declarations

325d09b

prrace approved these changes Jun 8, 2022

View reviewed changes

aivanov-jdk suggested changes Jun 8, 2022

View reviewed changes

removed rendering hints, changed condition to reapply old transform

35e7d5a

aivanov-jdk approved these changes Jun 8, 2022

View reviewed changes

aivanov-jdk reviewed Jun 8, 2022

View reviewed changes

removed initialization

317fe35

aivanov-jdk reviewed Jun 10, 2022

View reviewed changes

alisenchung added 2 commits June 10, 2022 15:09

changed initializations to null

93f0b73

fix typo

610d8f8

aivanov-jdk approved these changes Jun 13, 2022

View reviewed changes

aivanov-jdk suggested changes Jun 13, 2022

View reviewed changes

removed unused import

d4ad493

aivanov-jdk approved these changes Jun 13, 2022

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Jun 13, 2022

openjdk bot added the integrated Pull request has been integrated label Jun 13, 2022

openjdk bot closed this Jun 13, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Jun 13, 2022

honkar-jdk mentioned this pull request Sep 14, 2022

JDK-8015739: Background of JInternalFrame is located out of JInternalFrame #10274

Closed

3 tasks

rajamah mentioned this pull request Oct 12, 2022

8282958: Rendering issues of borders, TextFields on Windows High-DPI systems #10681

Closed

3 tasks

honkar-jdk mentioned this pull request Dec 7, 2022

JDK-8294680: Refactor scaled border rendering #11571

Closed

3 tasks

aivanov-jdk mentioned this pull request Jun 28, 2025

8349188: LineBorder does not scale correctly #26025

Closed

3 tasks

		// 8279614: The dark line was being overdrawn by the light line. The fix was to
		// make sure that the dark line is always drawn second.

		RenderingHints rend =
		new RenderingHints(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE);

8279614: The left line of the TitledBorder is not painted on 150 scale factor #7449

8279614: The left line of the TitledBorder is not painted on 150 scale factor #7449

Uh oh!

Conversation

alisenchung commented Feb 11, 2022 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Contributors

Reviewing

Uh oh!

bridgekeeper bot commented Feb 11, 2022

Uh oh!

openjdk bot commented Feb 11, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alisenchung Feb 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mlbridge bot commented Feb 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

alisenchung commented Mar 4, 2022

Uh oh!

prrace commented Mar 4, 2022

Uh oh!

alisenchung commented Mar 5, 2022

Uh oh!

Uh oh!

Uh oh!

alisenchung commented Mar 14, 2022

Uh oh!

azuev-java left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Mar 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aivanov-jdk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aivanov-jdk Mar 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aivanov-jdk commented Mar 14, 2022

Uh oh!

alisenchung commented Mar 14, 2022

alisenchung commented Feb 11, 2022 •

edited by openjdk bot

Loading

alisenchung Feb 14, 2022 •

edited

Loading

mlbridge bot commented Feb 14, 2022 •

edited

Loading

openjdk bot commented Mar 14, 2022 •

edited

Loading

aivanov-jdk Mar 14, 2022 •

edited

Loading

aivanov-jdk commented Mar 14, 2022 •

edited

Loading

lukeu commented Mar 15, 2022 •

edited by bridgekeeper bot

Loading

aivanov-jdk Jun 10, 2022 •

edited

Loading