Withdrawn: 8309460: JScrollBar leaves behind clutter for non-integer UI scales
On Thu, 18 Jan 2024 11:09:12 GMT, Prasanta Sadhukhan wrote: > Lines are left behind when moving the scrollbar in the positive direction. > but are cleaned up on mouse release. > Additonally, with right arrow clicks too, the lines are left behind. > Seems like for mouseDragged and scrollByUnit, the dirty region of the > scrollbar is not repainted leading to artifacts > which is being done in this fix.. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/17484
Withdrawn: 8325858: Replace Unsafe usage in XEmbeddingContainer with FFM API
On Wed, 14 Feb 2024 13:27:45 GMT, Per Minborg wrote: > This PR proposes to remove the use of `Unsafe` in the class > `XEmbeddingContainer ` and replace it with the supported FFM API. > > I tried to make this PR as small as possible while opening up for migration > of other classes later on (such as `XEmbedServer` which can be modified > similarly under a separate PR). > > There are also three drive-by fixes in this PR: > * Moved JavaDocs for `XAtom` to its proper location and fixed two typos in > the text > * Declared a field in `XEmbeddingContainer` as `private final` > * In `XAtom`, use a utility method `assertAtomInitialized()` instead of the > current duplicated code > > Tested and passed tier1-5 This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/17846
Withdrawn: 8319598: SMFParser misinterprets interrupted running status
On Tue, 7 Nov 2023 19:18:28 GMT, Jan Trukenmüller wrote: > The MIDI file parser misinterprets events without status byte when they > appear directly after a Meta of SysEx event. > > For my bugfix I had to decide between two possible solutions: > - Strict solution: Throw an InvalidMidiDataException > - Tolerant solution: Use the status of the last channel event as running > status > > I used the tolerant solution. > I will send an email to the list client-libs-dev with my reasons. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/16546
Withdrawn: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea
On Thu, 16 Mar 2023 06:06:50 GMT, 柳鲲鹏 wrote: > Candidat box can moving with caret on windows version. Someone must wrote > codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. > Why it doesn't work, is the key problem. > > 1, I wrote a example for linux: > https://github.com/quantum6/X11InputMethod > > I tried all parameters to test and as my research: > If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. > If you use XIMPreeditNothing, it works. > All examples use XIMPreeditCallbacks to initiate input method and candidate > box can't moving. So I understand why he didn't commit the codes. > > 2, I traced the route of transfering caret coordites on windows version, then > add codes for linux. > 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested > for a long time, it works OK. > 4, I am not sure for AIX( no environment). > > > JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret > of JTextArea > Type: Bug > Component: client-libs > Sub-Component: java.awt:i18n > Affected Version: 8,9,15,16 > Priority: P3 > Status: Open > Resolution: Unresolved > OS: linux > CPU: x86_64 This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13055
Withdrawn: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to > have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see > LoadedLibraries::reload() , see also > https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and > sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/15264
Withdrawn: 8221452: Window.setMinimumSize does not respect DPI scaling
On Mon, 8 May 2023 00:49:58 GMT, babblebubble wrote: > Hi, I'm not sure if I did the formatting of this pull request right, new to > this, but the bug was bothering me so I fixed it (took three attempts). > All I had to do was add ScaleUpX and ScaleUpY and it fixed it. > Sorry for being new to GitHub, I only made an account to fix this. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13857
Withdrawn: 6681958: Maximization state of JInternalFrames is corrupted by WindowsDesktopManager
On Mon, 9 Oct 2023 05:17:58 GMT, Prasanta Sadhukhan wrote: > Issue is if one internal frame is open and maximized and another internal > frame is created which is initialized with setMaximum(true) then after > opening the second internal frame both internal frames are non-maximized > It can also be seen with SwingSet2 JInternalFrameDemo in WIndowsLookAndFeel > i.e. when Frame 0 is maximised, and then Frame1 is maximised and then > minimised, Frame0 should remain maximised but it is now unmaximised > > Issues seen with JInternalFrame in WindowsLookAndFeel are > - Frame 0 maximised > - Frame 4 maximised, when minimised, Frame0 is seen to be restored to normal > size with Frame4 minimised > - Frame 0 is again maximised > - Frame 4 maximised from minimised, instead of maximising, it restores both > Frame0 and Frame4 > > The fix makes sure the maximised internal frame remains maximised when the > 2nd internal frame is maximised > This code seems to be added for > [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects > `When a frame is maximized and then minimized, the next frame should NOT be > maximized.` > > It still honours that fix as the test mentioned in JDK-5036083 works as > expected as mentioned above > > Also it is mentioned > https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L69-L70 > > It can be seen it is still honored. In SwingSet2 JInternalFrameDemo in > WindowsL, if Frame0 is maximised and then Frame1 is activated/selected, it > becomes maximised > Also, it doesn't cause any regression with our existing closed/open tests. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/16097
Withdrawn: JDK-8302618: [macOS] Problem typing uppercase letters with java.awt.Robot when moving mouse
On Fri, 30 Jun 2023 22:29:05 GMT, Harshitha Onkar wrote: > **Problem:** > > On macOS, Robot erroneously produces lowercase letter when mouse is moved > (manually) in unison with Robot's keyEvents. This issue was originally logged > by a developer of an on-screen accessibility keyboard - TouchBoard. > Originally reported at https://github.com/adoptium/adoptium-support/issues/710 > > This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. > (details below) > > This issue is not restricted to the Shift modifier key and causes problems > with other modifier keys as well and in some scenarios without any external > mouse movement. > > - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs > (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later > on it was changed to CGEvents. > > - With the present code, the issue occurs at > [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.) > The flags gets reset or cleared when mouse is moved physically in unison > with Robot's key events. > > - The physical mouse movement causes the event flags to be reset. > > **Impact:** > > Modifier keys don't work as expected when using Robot with any simultaneous > physical mouse movement and in case of TouchBoard, this behavior breaks the > usability of the on-screen a11y keyboard. There is no known workaround for > this particular use case except for reverting to JDK-8. More details on this > use case > [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280) > > **Proposed Fix:** > > - In order to avoid resetting of the CGEventFlags here > [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), > the CGEvent flag state is obtained in `initRobot` (stored in initFlags) > which is later used within `CRobot_keyEvent`. > > - The incoming keyCode is used to determine whether it is a modifier key and > the corresponding modifierFlagMask is either added or cleared from the > initFlags based on whether the modifier key was pressed or released. > > - Finally, only the required and known flag bits from initFlag are copied > over to local flag which is used in `CGEventSetFlags()`. > > **Testing:** > > The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, > Control, Option and Command keys. > The test runs in 2 modes - as automated and manual test. > > CASE 1 : As automated test. No user interaction needed. > CASE 2 : When r... This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/14744
Withdrawn: 8269806: Emoji rendering on Linux
On Thu, 15 Jul 2021 17:29:01 GMT, Nikita Gubarkov wrote: > It was implemented in JetBrains Runtime a year ago and was ported & > refactored for this PR > It includes: > - Bitmap glyph loading via Freetype > - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or > bilinear-mipmap style algorithms depending on the text antialiasing hint > - Storing BGRA glyphs in glyph cache & rendering them as plain images, as > currently used XRender text drawing functions doesn't support colored glyphs > - Small fixes in related code like null-checks which could cause NPE & > comment typos This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/4798
Withdrawn: 8315584 : java/awt/print/Dialog/DialogType.java fails with option not supported: yesno
On Sun, 3 Sep 2023 22:12:49 GMT, lawrence.andrews wrote: > Test was failing with "test result: Error. Parse Exception: Arguments to > `manual' option not supported: yesno" > Following are fixed > 1) Removed yesno > 2) Used PassFailJFrame manual test framework to show the test instruction & > allow the user to decide test execution result. > 3) Added SkippedException in case Printer is not configured on the test host. > 4) Updated the instruction how to close the print dialog that test is showing > to the user. > 5) Added an extra line to the file that was missing. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/15554
Withdrawn: 8302687 Implement interfaces and shared code for announcement feature
On Mon, 13 Mar 2023 16:46:10 GMT, Artem Semenov wrote: > This enhancement covers basic API and shared code that should be implemented > for the Accessibility Announcement feature. > > CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 > "bugs.openjdk.org") > > @mrserb @prrace @azuev-java please review This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13001
Withdrawn: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
On Wed, 7 Jun 2023 17:15:50 GMT, Jeremy wrote: > # Problem Summary > > For non-opaque windows, Window#paint calls `gg.fillRect(0, 0, getWidth(), > getHeight())` before `super.paint(g)`. > > This can cause flickering on Mac, and the flickering seems to have gotten > much worse in recent JVMs. (See movie attachments to original ticket.) > > # Discussion > > This is my 2nd PR for this ticket. The original is > [here](https://github.com/openjdk/jdk/pull/12993); that proposed change was > IMO more invasive/scarier. It was auto-closed after 8 weeks of inactivity, > and I'd rather offer this PR instead. > > In that previous discussion Alan Snyder framed the core problem as a "lack of > synchronization" (see [comment > here](https://github.com/openjdk/jdk/pull/12993#issuecomment-1467528061)). If > the monitor refreshes/flushes after we've called `fillRect` *but before we > finish `super.paint`*: it makes sense that we'd see a flicker. > > I agree with Alan, but I think the problem can also be framed as a > mixing-Swing-with-AWT issue. (Which IMO will involve an easier fix.) > > This PR is a low-risk change (relative to the previous PR) that intercepts > calls to repaint a Window that is also RootPaneContainer. Now we'll redirect > those calls to paint the JRootPane instead. This means we'll exclusively > paint within Swing's/RepaintManager's double-buffered architecture, so we > bypass the risky call to `fillRect` on the screen's Graphics2D. (And this > change occurs within RepaintManager, so we're clearly already in Swing's > architecture.) > > So with this change: we paint everything to the double-buffer, and the *only > time* we paint to the Window's Graphics2D is when have set up a > AlphaComposite.Src and replace its contents with our buffer's contents. > > # Tests > > This PR includes a new test for 8303950 itself. This is pretty > self-explanatory: we repaint a trivial animation for a few seconds and use > the Robot to see if a pixel is the expected color. > > This PR also includes a test called `bug8303950_legacyWindowPaintBehavior` > that creates a grid of 4 windows with varying opacity/backgrounds: > > src="https://github.com/openjdk/jdk/assets/7669569/497c21a0-ed18-413f-a5c7-3ea146644fd6;> > > I was surprised by how these windows rendered, but I don't think that's worth > debating here. This test simply makes sure that we preserve this preexisting > behavior. The broad "rules" appear to be: > 1. If a JComponent identifies as opaque (see `JComponent.isOpaque`) then the > JComponent's background is used. (In this case: that's the opaque green top > two windows.) T... This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/14363
Withdrawn: 8305427: Write a test Check whether focus changes as expected when requestFocus is used to traverse randomly around the window
On Mon, 3 Apr 2023 10:00:21 GMT, Ravi Gupta wrote: > This testcase Checking whether the Component becoming the Focus Owner and > FocusEvent.FOCUS_GAINED will be received by the Component when the focus is > requested on the component using requestFocus. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got > all pass. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13293
Withdrawn: 8307325: Verify the focus owner when non focused windows requesting focus
On Thu, 4 May 2023 05:41:43 GMT, Ravi Gupta wrote: > Write a test Check, when the top level Window is not the focused Window > requesting for focus and becoming the Focus Owner for any Component in that > Window checking the following > > 1.The Component is the Focus Owner and the Window becomes the focused Window > If the platform supports cross requesting focus > across Windows. > 2.The request is remembered and be granted when the Window is later focused > If the platform does not support requesting focus > across Windows. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got > all pass. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13790
Withdrawn: JDK-8292276 : Add named colors from CSS Color Module Level 4
On Wed, 10 Aug 2022 20:00:29 GMT, ScientificWare wrote: > This is referenced in Java Bug Database as > - [JDK-8292276 : Add named colors from CSS Color Module Level > 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) > > This is tracked in JBS as > - [JDK-8292276 : Add named colors from CSS Color Module Level > 4](https://bugs.openjdk.java.net/browse/JDK-8292276) > > Adds missing color names, defined by CSS Level 4, in CSS.java : > CSS Color Module Level 4 > W3C Candidate Recommendation Snapshot, 5 July 2022 > [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color) > > Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color > Module Level 4](https://github.com/scientificware/jdk/issues/12) This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/9825
Withdrawn: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color
On Fri, 16 Sep 2022 23:16:19 GMT, ScientificWare wrote: > This is referenced in Java Bug Database as > - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded > Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776) > > This is tracked in JBS as > - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded > Color](https://bugs.openjdk.java.net/browse/JDK-8293776) > > Adds the 4 and 8 digits color hex notations to CSS.java, as described in : > CSS Color Module Level 4 > W3C Candidate Recommendation Snapshot, 5 July 2022 > [6.2 The RGB Hexadecimal Notations: > `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation) > > Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex > coded Color](https://github.com/scientificware/jdk/issues/13) This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10317
Withdrawn: 8301991: Convert l10n properties resource bundles to UTF-8 native
On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu wrote: > This PR converts Unicode sequences to UTF-8 native in .properties file. > (Excluding the Unicode space and tab sequence). The conversion was done using > native2ascii. > > In addition, the build logic is adjusted to support reading in the > .properties files as UTF-8 during the conversion from .properties file to > .java ListResourceBundle file. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/12726
Withdrawn: JDK-8302281 - ImageReader and ImageWrite should implement Closable
On Thu, 19 Jan 2023 18:41:08 GMT, Markus KARG wrote: > The fact that there is a `dispose()` method to be called is easily missed, as > people tend to look for a method called `close()`, or assume that resources > only need to get closed when they support try-with-resource. As a result, > there is a risk of keeping resources opened longer than needed (or even run > into a resource leak with long running processes) as the user cannot use > try-with-resources currently. > > This is not a big change, but it is useful for those working with ImageIO. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/12098
Withdrawn: JDK-8303950: [macos]Translucent Windows Flicker on Repaint
On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy wrote: > I'm confident about the new test case for this ticket, but the resolution is > more invasive than I'd like. (It works, though.) > > In short: > This introduces a new RenderingHint (in SunHints) to bypass the call in > Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());` > > I left more detailed notes here about the proposed resolution: > https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c > > I'm open to suggestions if anyone has a more elegant proposal to prevent the > monitor from refreshing too soon? This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/12993
Withdrawn: 8303904: Transparent Windows Paint Wrong (Opaque) w/o Volatile Buffering
On Mon, 27 Mar 2023 21:45:08 GMT, Jeremy wrote: > The original write-up contains two complaints: > 1. The window is opaque, so pixels that should be transparent are black. > 2. The window is the wrong resolution. On a 200% resolution monitor it > renders as if it were 100% (so it looks pixelated). > > I recommend splitting this up into separate tickets. > > This PR addresses the first (probably most offensive) issue: the window is > now transparent. > > I experimented with a change that resolves the second issue (image > resolution) here: > https://github.com/openjdk/jdk/commit/90735b7c01c66268776998c1b6aedc3250427002 > > ... that works, but IMO that looks riskier and should be part of a separate > discussion. > > I only have a Mac configured right now to test against, so I've confirmed the > MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig > changes are identical, but I haven't confirmed that this new test passes in > those environments. (I did confirm that those GraphicsConfig files appear to > support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be > OK. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13196
Withdrawn: 8305321: Remove unused exports in java.desktop
On Fri, 31 Mar 2023 07:34:50 GMT, Daniel Jeliński wrote: > Please review this patch that removes a number of unused exports from > java.desktop native libraries. > > In most cases I removed JNIEXPORT from methods and variables that are only > used within a single shared library. Other than that: > - removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I > could tell, rasterizer project is dead now, but if that's incorrect I can > restore that export. > - removed `colorValueID` in X11Color; that field was not used. > - removed `J2dTraceInit` from header file. That method is only used > internally by `J2dTraceImpl`. > > The methods `Transform_GetInfo` and `Transform_transform` are declared in > GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I > should move them to where they are used. > > The method `img_makePalette`, currently located in > `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by > `unix/native/common/awt/X11Color.c`; it could be moved to the same directory > to avoid exporting the method from libawt. The files `img_colors.[ch]` do not > have any references to other files in `cvutils`. > > Manually verified that the exports are no longer present after these changes. > Tier1-3 and client libs tests still pass. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13261
Withdrawn: 8304947: Unnecessary Vector usage in java.awt.MenuBar.shortcuts
On Wed, 22 Mar 2023 19:12:34 GMT, Andrey Turbanov wrote: > Method `'java.awt.MenuBar#shortcuts` creates a 'Vector', fills > it and then returns its 'Enumeration elements()' as return value. > Instead of usage of legacy synchronized Vector here we can use ArrayList > instead. Wrap it in Collections.enumeration to adapt to 'Enumeration' result > type. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13149
Withdrawn: JDK-8299052: ViewportOverlapping test fails intermittently on Win10 & Win11
On Tue, 20 Dec 2022 23:25:30 GMT, Harshitha Onkar wrote: > ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added > robot.setAutoWaitForIdle() to ViewportOverlapping and its base class > (OverlappingTestBase) to stabilize the test. > > Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11747
Withdrawn: JDK-8266245: AWT Test FullScreenInsets.java fails due to incorrect pixel color and wrong window bounds
On Thu, 1 Dec 2022 18:03:42 GMT, Harshitha Onkar wrote: > The above test was failing due to incorrect pixel color and wrong window > bounds on Mac-ARM, Windows and Linux platforms. > > The following changes have been made: > - Correct window bounds are obtained using the current ScreenDevice's > DefaultConfig bounds (this test checks FullScreen functionality on multiple > screen devices). > - Color tolerance has been added for color check > - Instead of scanning the full screen to check pixel color, vertical and > horizontal scans are done at the far right and bottom end to ensure that > window is in full screen mode w.r.t to screen device and the window bounds > are as expected. > > CI testing passes on all platforms (tested 50 times per platform). This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11462
Withdrawn: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5 only on linux-aarch64
On Mon, 27 Feb 2023 11:49:27 GMT, Jayathirth D V wrote: > Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of > gcc optimizations from -O1 level for libawt build. This improved our J2DBench > performance numbers in some options considerably. > > Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes > difference in generated code by gcc and this is resulting in performance > regression for bimg_misc-* J2DBench options in our performance servers. Under > https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused > variables and it is a cleanup task. > > We can force gcc to generate position independent code by using -fpic > option.Also i have removed -fgcse-after-reload option for gcc, because this > is by default covered under -O3 level of optimization introduced under > https://bugs.openjdk.org/browse/JDK-8264846. > > With this change bimg_misc-* J2DBench option performance regression is > resolved and there are no regression in other options of J2DBench or > SwingMark and it is verified in our performance servers. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/12761
Withdrawn: 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled
On Tue, 4 Oct 2022 22:52:30 GMT, SWinxy wrote: > Many `installDefaults` methods set the font, foreground, and background on > objects but their inverse methods `uninstallDefaults` do not remove them. > I've added an inverse method to remove the colors and font to call for the > `uninstallDefaults` methods that install defaults. > > `AquaButtonUI` can call its super since it would otherwise be repeated code. > `BasicComboBoxUI` (weirdly) installs the properties again when it should be > uninstalling them, so I changed. > > I noticed that, in a few subclasses, only one of calls to the super of > `installDefaults` and `uninstallDefaults` are made. That is, an overridden > `installDefaults` may call its super while the overridden `uninstallDefaults` > does not call its super (or vise versa). These classes are: > `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and > `XTextAreaPeer`. > > Sorry I couldn't write a test; I wasn't sure how I should have accessed the > protected variable aside from creating extending classes for each class that > changed. > > See also #6603, where this issue was discovered. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10565
Withdrawn: 8299333: Unify exceptions used by all variants of ICC_Profile.getInstance(null)
On Fri, 23 Dec 2022 23:32:45 GMT, Sergey Bylokhov wrote: > I tried to clean up the documentation in the `java.awt.color` package and > specify how the `null` parameters are handled here and there. But it looks > like the `ICC_profile` class is too specific so I would like to discuss it > separately. > > The ICC_Profile has these methods: > * `getInstance(int)` - always throws specified > `IllegalArgumentException` on the wrong constant > * `getInstance(byte[])` - always throws specified `IllegalArgumentException` > on `null` > * `getInstance(String fileName)` - always throws unspecified > `NullPointerException` on `null` > * `getInstance(InputStream)` - thrown unspecified > `NullPointerException` before > [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) > and now throws specified but misleading `IOException: Stream closed` > exception on `null` > > So we have 3 methods that can get null as a parameter and each throw a > different exception. > > Note that all of the specs for the methods above have this part: > >> @throws IllegalArgumentException If the stream does not contain valid ICC >> Profile data > > So I have an idea to change `getInstance(String)` and > `getInstance(InputStream)` to throw `IllegalArgumentException` even if I > personally prefer NPE to be thrown. > > From another point of view the `ICC_Profile` profile has other methods: > * `write(String fileName)` - always throws unspecified > `NullPointerException` on `null` > * `write(OutputStream) ` - always throws unspecified `NullPointerException` > on `null` > > I am not sure we can throw `IllegalArgumentException` from the `write` > methods, so the specification for `getInstance(String)` and > `getInstance(InputStream)` could be updated to throw NPE on null same as > related `write`. > > Thoughts? This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11784
Withdrawn: 8282217: Key events (key char and key code) changed for Swiss keyboard
On Fri, 6 Jan 2023 22:07:33 GMT, Alisen Chung wrote: > Removed check for MapVirtualKeyEx return value causing some keys to become > undefined This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11887
Withdrawn: 7131166: SynthListUI / SynthInternalFrameTitlePane updateStyle() ignores method argument
On Fri, 6 Jan 2023 04:42:37 GMT, Prasanta Sadhukhan wrote: > It seems Synth has two cases of updateStyle() where its argument is not > passed to the getContext() call. It seems to be an oversight as in other > Synth classes, the component argument passed to updateStyle is being passed > to getContext(). > > CI tests are ok with this change and there is no new regeression with CI > tests run in NimbusL by default.. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11875
Withdrawn: 4365952: Cannot disable JFileChooser
On Wed, 7 Dec 2022 05:48:57 GMT, Tejesh R wrote: > Disable functionality not working for JFileChooser. `public void > setEnabled(boolean enabled)` functionality is overridden in JFileChooser > class which enable/disable each sub-component of FileChooser. > The added functionality is tested in mach5 and no regression found. The fix > includes automated test which clicks _home_ directory and then compares which > default selectedDirectory to check if JFileChooser is disabled. This is > tested in mach5 for all platforms with multiple test runs. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11553
Withdrawn: 8297191: [macos] printing page range "page 2 to 2" or "page 2 to 4" on macOS leads to not print
On Mon, 21 Nov 2022 14:32:50 GMT, Christian Heilmann wrote: > 8297191: [macos] printing page range "page 2 to 2" or "page 2 to 4" on macOS > leads to not print This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11266
Withdrawn: 8294807: Fix typos and clarify javadoc for SunToolKit.realsSync
On Tue, 4 Oct 2022 20:21:10 GMT, Alexey Ivanov wrote:
> I fixed the typo “serie” → "series" which was highlighted by a spellchecker.
>
> I also simplified the description, fixed the grammar, added `{@code}` around
> types, added link to `requestFocus` in the example.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/10563
Withdrawn: 8295707: Create a regression test for JDK-7184401
On Thu, 20 Oct 2022 08:59:20 GMT, Srinivas Mandalika wrote: > 8295707: Create a regression test for JDK-7184401 > > JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144 > Above bug got introduced due to a fix for > [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). > The issue was observed on the netbeans UI. > The test below recreates a standalone test to mimic the failure reported in > Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) > and verifies that it is working as expected after it got fixed via > [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350)) > > The Test attempts to reproduce specific behavior of NetBeans at the certain > toolbar creation stage. Widgets are created on EDT; Another code posts some > events to them on EDT; From another thread some code calls explicitly > edt.interrupt(). > Before this got fixed, events from a second code got lost. > > This review is for migrating tests from a closed test suite to open. > Testing: > 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on > this build. > 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed. > 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows > x64 - the .results are clean This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10784
Withdrawn: 8298352: apple.laf.JRSUIUtils class creates many indirections
On Sun, 18 Sep 2022 21:23:12 GMT, SWinxy wrote: > `JRSUIUtils.java` structurally does things weirdly. The utility class mostly > passes parameters from functions to other functions. The indirection makes > things harder to understand the eventual purpose. > > Take `AquaInternalFrameBorderMetrics.java`. It has a `static boolean` that > caches a call to `shouldUseLegacyBorderMetrics()`, which returns > `isSnowLeopardOrBelow`, itself a cached call to > `isMacOSXSnowLeopardOrBelow()`, which is what finally calls > `currentMacOSXVersionMatchesGivenVersionRange()`. When looking at the code, > it takes time to unravel the path it takes. Instead of that, a `public static > final boolean` can expose the cached value and, in doing so, exposes the > *meaning* behind the check. > > In `AquaLookAndFeel.java`, the value of `TabbedPaneUI` is calculated using > `JRSUIUtils.TabbedPane.shouldUseTabbedPaneContrastUI()`, but that could mean > any reason for why `"AquaTabbedPaneContrastUI"` may be the value as opposed > to `"AquaTabbedPaneUI"`. Replacing it with `JRSUIUtils.isSnowLeopardOrBelow` > reveals that it actually has to do with the OS version being, well, Snow > Leopard or below. > > These change makes understanding the code easier and quicker. Also more > optimized. > > Changes: > * add JRSUIConstants.ScrollBarPart.ordinal() to return the property's ordinal > value, which is not public > * change 3 access modifiers in JRSUIControl to public allowing for access > outside the package > * JRSUIConstants.NineSliceMetricsProvider changed to a normal Function<> > * cache `isMacOSXBigSurOrAbove` rather than calling it twice > * inline the functions for clarity > * change static initialization to group all version checks together > * document JRSUIUtils This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10326
Withdrawn: 8298006: Build failure by maybe-uninitialized error on Linux s390x GCC8
On Fri, 2 Dec 2022 08:41:18 GMT, Ichiroh Takiguchi wrote: > I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x. > I could see following errors: > > src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In > function 'allocateRasterArray': > src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: > error: 'roff[3]' may be used uninitialized in this function > [-Werror=maybe-uninitialized] > (((*inP>sppsm.maskArray[c]) >> roff[c]) > ^~~ > > > > src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:3129:73: > error: 'roff[3]' may be used uninitialized in this function > [-Werror=maybe-uninitialized] > (((*inP>sppsm.maskArray[c]) >> roff[c]) > ^~~ > > > According to error messages, > roff and loff may not be initialized. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11475
Withdrawn: 8298042: Fix hidden but significant trailing whitespace in properties files for client code
On Fri, 2 Dec 2022 16:38:54 GMT, Magnus Ihse Bursie wrote: > According to [the > specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) > trailing whitespaces in the values of properties files are (somewhat > surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. > For most of this files, this is likely incorrect and due to oversight, but in > a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for > [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was > to replace valid trailing spaces with the corresponding unicode sequence, > `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing > space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn > on the corresponding check in jcheck to keep the properties files, just like > all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or > is a bug, lies with the respective component teams owning these files. Thus I > have split up the set of properties files with trailing spaces in several > groups, to match the JDK teams, and open a JBS issue for each of them. This > issue is for code I believe belong with the client-libs team. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11488
Withdrawn: 8296546: Add @spec tags to API
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc > comments, as appropriate, to leverage the recent new javadoc feature to > generate a new page listing the references to all external specifications > listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan > doc comments looking for HTML links to selected sites, such as `ietf.org`, > `unicode.org`, `w3.org`. These links may be in the main description of a doc > comment, or in `@see` tags. For each link, the URL is examined, and > "normalized", and inserted into the doc comment with a new `@spec` tag, > giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec > site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where > both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined > either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** > new `@spec` tags, based on the links found in each doc comment. There should > be no other changes to the doc comments, or to the implementation of any > classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to > update the links that it finds (e.g. changing to use `https:` etc,) but those > features are _not_ being used here, but could be used in followup PRs if > component teams so desired. I did notice while working on this overall > feature that many of our links do point to "outdated" pages, some with > eye-catching notices declaring that the spec has been superseded. Determining > how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the > underlying links, and the URLs in `@spec` tags, such that if references to > external specifications are updated, this will include updating the `@spec` > tags. > > To see the effect of all these new `@spec` tags, see > http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External > Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) > page, which you can also find via the new link near the top of the > [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) > pages. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/11073
Withdrawn: 8295248: JEditorPane HTML form with multi-selection broke data after resetting
On Thu, 13 Oct 2022 01:48:45 GMT, Toshio Nakamura wrote: > When JEditorPane shown HTML form with multi-selection, the reset operation > broke its data. > > The sample testcase were attached in JBS. The recreate steps are below: > 1. The sample shows a multi-selection form with 5 items. > 2. Select the 4th item. > 3. Press the reset button. > Actual: The 4th item is still selected. > Expect: No item should be selected. Resetting operation may move to the > initial state. The sample doesn't use 'selected' property in each option tag. > 4. Just after the step 3, move the focus to outside of the application and > back. > Actual: The 2nd item is selected. It means inside data indicates so. > Expect: No item is selected. > > There are two issues. The current method > `OptionListModel.removeIndexInterval()` removed the indexed item, and shifted > the rest. Then, selection values were corrupted. > I think the clear selection method `OptionListModel.clearSelection()` is > suitable here. > > Test: jdk_desktop on macOS (x64, Monterey), Linux (x64, RHEL8), and Windows > (x64, 2012R2). > No regression found This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10685
Withdrawn: 8296535: Unnecessary Vector usage in AquaFileSystemModel.FilesLoader
On Wed, 2 Nov 2022 08:19:41 GMT, Andrey Turbanov wrote: > Couple of local variables in > `com.apple.laf.AquaFileSystemModel.FilesLoader#run` are used only within the > method from single thread. So we can avoid usage of legacy synchronized > `Vector` here and use `ArrayList` instead. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10942
Withdrawn: JDK-4305789: BasicToolBarUI: Request conversion of private instance variable
On Fri, 16 Sep 2022 13:47:41 GMT, aLiEnHeAd13 wrote: > Fixed Bug JDK-4305789 to support docking to any instantiated JFrame > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4305789 This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10309
Withdrawn: 5080391: ArrayIndexOutOfBounds during "undo" of Right-to-Left text insert
On Tue, 27 Sep 2022 11:16:36 GMT, Prasanta Sadhukhan wrote: > javax.swing.text.AbstractDocument$BranchElement.replace(...) method throws an > `ArrayIndexOutOfBoundsException: arraycopy: length -1 is negative` when using > an UndoManager on the default document of a JTextArea and you try to undo the > insertion of a LEFT-TO-RIGHT language (e.g. Arabic) that is immediately > followed by setting the component orientation on the JTextArea. > > This is because System.arrayCopy() is called with -ve length because of the > calculation done in AbstractDocment.replace where `src` is of 2bytes because > of unicode text causing `nmove` to become -ve if `nchildren` is 1 (an unicode > character is inserted) > > System.arrayCopy throws `IndexOutOfBoundsException if: > > The srcPos argument is negative. > The destPos argument is negative. > The length argument is negative > > > so the fix is made to make nmove, src, dest +ve > Also, Element.getElement() can return null which is not checked, causing NPE, > if deletion of text is done which results in no element, which is also fixed > in the PR > > All jtreg testsuite tests are run without any regression. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10446
Withdrawn: 7175396: The text on label is not painted red for Nimbus LaF.
On Wed, 17 Aug 2022 10:46:07 GMT, Prasanta Sadhukhan wrote: > Label.foreground UIProperty is not honored by Nimbus L > Added support for setting JLabel foreground color for Nimbus L This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/9900
Withdrawn: 8292588: [macos] Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java: Robot.mouseMove test failed on Screen #0
On Tue, 20 Sep 2022 18:24:26 GMT, Alisen Chung wrote: > Fixed test bug where mouse location was being calculated before robot > mouseMove operation was complete This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10363
Withdrawn: 8289539: The color returned by CheckBox.interiorBackground is incorrect
On Thu, 22 Sep 2022 06:59:59 GMT, Tejesh R wrote: > The color returned for `InteriorBackground` property is the default color > used for only _WindowsClassicLookAndFeel_. For _WindowsLookAndFeel_ the > `InteriorBackground` color is not been used when checkbox paint happens. In > _WindowsLookAndFeel_ the CheckBox check/uncheck is drawn using `ImageCache` > which is totally independent of `InteriorBackground` color in which the user > expects it to be. > The proposed fix is to return null for _WindowsLookAndFeel_ (which is what > happens in other LookAndFeel like Metal/Synth/Motif/Aqua ) and return default > color which is the actual color used in _WindowsClassicLookAndFeel_. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/10385
Withdrawn: 4668290: unclear spec for Polygon.bounds field
On Mon, 26 Sep 2022 02:27:53 GMT, SWinxy wrote:
> New documentation replaces the `This value can be null.`:
>
> When created, {@link #invalidate() invalidated}, or {@link #reset() reset},
> this becomes {@code null}. To get out of the null state,
> {@link #getBounds()} called with {@link #npoints} being greater than
> {@code 0} will transfer into a non-null {@link Rectangle}.
>
>
> I think I've got the reason for why it can be `null` correct, but you never
> know.
>
> In javax.swing.text.html.Map, I've replaced setting the field to null with
> the equivalent #invalidate(). This may mean we can make the field private in
> the future.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/10417
Withdrawn: 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor
On Mon, 26 Sep 2022 02:49:36 GMT, SWinxy wrote:
> Appends: `, copying the array contents of {@code xpoints} and {@code
> ypoints}` to specify that the arrays in the constructor are explicitly copied.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/10418
Withdrawn: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m
On Mon, 5 Sep 2022 23:41:40 GMT, SWinxy wrote:
> The `SDRenderType` enum is often returned using a variable declared at the
> start of functions. These can be inlined in the `return` itself. Using a
> ternary operator condenses what may be 12 lines into one, in the most extreme
> cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more than the
> rest, but are still basically the same.
>
> Example change:
>
> SDRenderType renderType = SD_Nothing;
>
> if (fill == YES)
> {
> renderType = SD_Fill;
> }
> else
> {
> renderType = SD_Stroke;
> }
>
> // draw logic
>
> return renderType;
>
>
>
> // draw logic
>
> return fill ? SD_Fill : SD_Stroke;
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/10174
Withdrawn: 8292271 : Fix java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test
On Fri, 12 Aug 2022 17:00:25 GMT, lawrence.andrews wrote: > 1) This test was failing due to yesno > test result: Error. Parse Exception: Arguments to `manual' option not > supported: yesno > 2) PrintCheckboxManualTest.html file was missing > 3) Added os.family since test instruction says that its a linux and solair > toolkit only test > 4) Removed Sysout & TestDialog class & added a better manual framework to > show the instruction and test frame. > > @shurymury This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/9858
Withdrawn: 8288428: javax/swing/JInternalFrame/Test6505027.java fails frequently in MacOS 12 machines
On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S wrote: > javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS > machines, especially in MacOSX 12 machines and it fails intermittently in CI > causing some noise. > It seems to be a testbug as adding some stability improvements fix the issue. > > Fix: > Some stability improvements have been done and the test has been run 10 times > per platform in mach5 and got full PASS. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/9202
Withdrawn: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines
On Thu, 16 Jun 2022 15:01:12 GMT, Manukumar V S wrote: > java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS > machines, especially in MacOSX 12 machines. It seems to be a testbug as > adding some stability improvements fix the issue. It intermittently fails in > CI causing some noise. This test was already problem listed in windows due to > an umbrella bug JDK-8238720. I have removed the problem listing and tested it > in windows platform also, it works fine there. > > Fix: > Some stability improvements have been done and the test has been run 100 > times per platform in mach5 and got full PASS. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/9187
Withdrawn: 8282578: AIOOBE in javax.sound.sampled.Clip
On Fri, 3 Jun 2022 15:43:39 GMT, Alexander Zuev wrote: > Add try/catch clause to ignore an exception since it is harmless for we > isolated > the massge data before passing it ro processor. > Add test case. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/9016
Withdrawn: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess wrote: > These are the changes that too many to be reviewed in 8186958, thus split > some of them out. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/8301
Withdrawn: 7080150: [TEST_BUG][macosx] No mac os x EmbeddedFrame support in regression regtesthelpers
On Thu, 21 Apr 2022 19:47:32 GMT, Alisen Chung wrote: > added EmbeddedFrame support for macosx in regtesthelpers This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/8348
Withdrawn: 8185261: Font fallback sometimes doesn't work in Swing text components
On Tue, 1 Feb 2022 18:38:39 GMT, Dmitry Batrak wrote: > The proposed fix makes fonts with and without fallback components > distinguishable (in terms of `equals` method), so that > font metrics cache (and other similar code) can handle them separately. This > is achieved by adding a new boolean field > to `Font` class, specifically denoting fonts with fallback components. The > latter ones don't need to pretend to be > 'created' fonts anymore, to preserve their `Font2D` handle. > It's not possible to use the existing `createdFont` field in `equals` > implementation, as JCK requires a 'real' created > font (the one obtained using `Font.createFont` method) to be equal to the > same font after serialization and > deserialization. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/7313
