Re: RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException
On Thu, 4 Jul 2024 10:34:24 GMT, Prasanta Sadhukhan wrote: > When a printjob is cancelled midway, `PrinterAbortException `was not thrown > in macos. because > firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as > parameter causing it to fail with NPE and > secondly PrinterAbortException was consumed silently when `printLoop` throws > any exception > which is rectified to throw the PrinterAbortException when encountered.. I did verified in MacOS and the fix is working fine. The issue is in windows too, getting the same error. Is there a separate bug for windows? - PR Review: https://git.openjdk.org/jdk/pull/20027#pullrequestreview-2160066073
Re: RFR: 8155030: The Menu Mnemonics are always displayed for GTK LAF [v14]
> In GTK LAF, the menu mnemonics are always displayed which is different from > the native behavior. In native application **(tested with gedit for normal > buttons and tested with libreoffice for menu**), the menu mnemonics toggle on > press of `ALT` key. Menu mnemonics are hidden initially and then toggles > between show/hide on `ALT` press. > Proposed fix is to handle the `ALT` key press for GTK LAF and mimic the > native behavior. Fix is similar to the `ALT` key processing in Windows LAF. > Automated test case is added to verify the fix and tested in Ubuntu and > Oracle linux. > > CI testing is green and link attached in JBS. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: wild imports expand, imports sorting - Changes: - all: https://git.openjdk.org/jdk/pull/18992/files - new: https://git.openjdk.org/jdk/pull/18992/files/6596dc9c..4aa6db65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18992&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18992&range=12-13 Stats: 58 lines in 6 files changed: 33 ins; 17 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/18992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18992/head:pull/18992 PR: https://git.openjdk.org/jdk/pull/18992
Re: RFR: 8155030: The Menu Mnemonics are always displayed for GTK LAF [v13]
On Thu, 4 Jul 2024 17:22:01 GMT, Alexey Ivanov wrote: > This changeset enables hiding / showing mnemonics on `JMenuBar` only. Do you > plan to update `ButtonUI` and `LabelUI` for GTK Look-and-Feel too? Not as a part of this PR. It can be taken up as other bug. @aivanov-jdk Imports are expanded and sorted as per recent review comments. I guess everything is fine now. - PR Comment: https://git.openjdk.org/jdk/pull/18992#issuecomment-2209447994 PR Comment: https://git.openjdk.org/jdk/pull/18992#issuecomment-2209448963
Re: RFR: 8155030: The Menu Mnemonics are always displayed for GTK LAF [v11]
On Wed, 3 Jul 2024 04:16:53 GMT, Abhishek Kumar wrote: > Updated the wild imports. My IDE doesn't indicate if imports are sorted or > not or if any imports are unused. Does it require to do some settings in IDE? Perhaps, it depends on how you configured your IDE and the project for JDK. I just use **Code** > **Optimize Imports** command (or rather Ctrl+Alt+O shortcut), and I expect to see no changes. - PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665931601
Re: RFR: 8155030: The Menu Mnemonics are always displayed for GTK LAF [v13]
On Wed, 3 Jul 2024 11:17:56 GMT, Abhishek Kumar wrote:
>> In GTK LAF, the menu mnemonics are always displayed which is different from
>> the native behavior. In native application **(tested with gedit for normal
>> buttons and tested with libreoffice for menu**), the menu mnemonics toggle
>> on press of `ALT` key. Menu mnemonics are hidden initially and then toggles
>> between show/hide on `ALT` press.
>> Proposed fix is to handle the `ALT` key press for GTK LAF and mimic the
>> native behavior. Fix is similar to the `ALT` key processing in Windows LAF.
>> Automated test case is added to verify the fix and tested in Ubuntu and
>> Oracle linux.
>>
>> CI testing is green and link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Test update to refer MnemonicHandler class
This changeset enables hiding / showing mnemonics on `JMenuBar` only. Do you
plan to update `ButtonUI` and `LabelUI` for GTK Look-and-Feel too?
src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java line 37:
> 35: import javax.swing.plaf.UIResource;
> 36:
> 37: import javax.swing.plaf.basic.BasicLabelUI;
I would prefer not to add blank lines between these imports.
Having a blank line between `java.*` and `javax.*` above is fine.
src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java line 43:
> 41:
> 42: import com.apple.laf.AquaUtils.RecyclableSingleton;
> 43: import com.apple.laf.AquaUtils.RecyclableSingletonFromDefaultConstructor;
I'd sort them alphabetically too: `sun.swing` follows `com.apple.laf`. I'd not
add a blank line between these imports.
src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java line 58:
> 56: import apple.laf.JRSUIControl;
> 57: import apple.laf.JRSUIUtils;
> 58:
Remove the blank line?
src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 37:
> 35: import java.awt.Rectangle;
> 36:
> 37: import java.awt.event.InputEvent;
No blank line here.
src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 52:
> 50: import javax.swing.UIManager;
> 51:
> 52: import javax.swing.border.Border;
No blank line here.
src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 62:
> 60: import apple.laf.JRSUIConstants.Widget;
> 61:
> 62: import com.apple.laf.AquaIcon.InvertableIcon;
Maybe preserve the blank lines in this section, yet it could be better to
remove these too.
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
line 46:
> 44: import java.util.Map;
> 45: import sun.awt.SunToolkit;
> 46: import sun.awt.UNIXToolkit;
Optimize imports in this file too, to expand the wildcard imports.
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
line 43:
> 41: import javax.swing.JMenu;
> 42: import javax.swing.JMenuItem;
> 43: import javax.swing.UIManager;
Suggestion:
import javax.swing.AbstractButton;
import javax.swing.ButtonModel;
import javax.swing.JButton;
import javax.swing.JCheckBox;
import javax.swing.JMenu;
import javax.swing.JMenuItem;
import javax.swing.JRadioButton;
import javax.swing.JToggleButton;
import javax.swing.UIManager;
Keep the imports sorted.
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
line 49:
> 47: import sun.swing.SwingUtilities2;
> 48:
> 49: import com.sun.java.swing.plaf.windows.WindowsButtonUI;
The `WindowsButtonUI` import is unused.
test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 63:
> 61: System.out.println("Testing: "+laf.getName());
> 62: UIManager.setLookAndFeel(laf.getClassName());
> 63: }
Suggestion:
if (laf.getName().contains("GTK") ||
laf.getName().contains("Aqua")) {
System.out.println("Testing: " + laf.getName());
UIManager.setLookAndFeel(laf.getClassName());
break;
}
Since we expect one and only one L&F, break from the loop as soon as you found
a match.
-
Changes requested by aivanov (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/18992#pullrequestreview-2159270954
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665920495
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665921960
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665923019
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665924234
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665924574
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665925751
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665926565
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665928024
PR Review Comment: https://git.openjdk.org/jdk/pull/18992#discussion_r1665927518
PR Review Comment: https://g
Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]
On Wed, 11 Oct 2023 11:32:37 GMT, Alexey Ushakov wrote: >> Hello! Actually, I don't like the fix: >> 1. It was the first time I touched Objective-C code, so the code itself is >> very poor. >> 2. I didn't add any tests because I am not familiar with the test framework. >> 3. At some point we received a number of exception reports related to my >> changes (most-likely), and I have no clue what was the reason. We did some >> investigation with @avu but unsuccessfully. >> >> So, my hope was that someone more experienced will handle the problem >> properly, but passed three years... >> >> @avu Can you help to handle submitting the PR from our side? > > @anstarovoyt thanks for the update. Yes, we'll handle it. @avu up - PR Comment: https://git.openjdk.org/jdk/pull/15980#issuecomment-2209229408
Re: RFR: 8334599: Improve code from JDK-8302671 [v2]
On Thu, 4 Jul 2024 13:15:28 GMT, Thomas Stuefe wrote: > Using memmove is so uncommon that it is usually a clear indication for a > deliberate choice. It may still be an accidental choice. I didn't find any code review for [JDK-6680988](https://bugs.openjdk.org/browse/JDK-6680988) where this line had been added. - PR Comment: https://git.openjdk.org/jdk/pull/19798#issuecomment-2209220729
Re: RFR: 8334599: Improve code from JDK-8302671 [v2]
On Wed, 3 Jul 2024 13:34:38 GMT, Julian Waters wrote:
>> In [JDK-8302671](https://bugs.openjdk.org/browse/JDK-8302671) I fixed a
>> memmove decay bug by rewriting a sizeof on an array to an explicit size of
>> 256, but this is a bit of a band aid fix. It's come to my attention that in
>> C++, one can pass an array by reference, which causes sizeof to work
>> correctly on an array and has the added bonus of enforcing an array of that
>> size on the arguments passed to that method. I've reverted my change from
>> 8302671 and instead explicitly made kstate an array reference so that sizeof
>> works on the array as expected, and that the array size can be explicitly
>> set in the array brackets
>>
>> Verification: https://godbolt.org/z/Ezj76eWWY and GitHub Actions
>
> 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:
>
> - Formatting sizeof awt_Component.cpp
> - Formatting awt_Component.cpp
> - Merge branch 'openjdk:master' into patch-10
> - Update src/java.desktop/windows/native/libawt/windows/awt_Component.cpp
>
>Co-authored-by: Alexey Ivanov
> - 8334599
Still looks good, except for the minor formatting comments.
src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 3365:
> 3363: }
> 3364: static void
> 3365: resetKbdState(BYTE (&kstate) [AwtToolkit::KB_STATE_SIZE]) {
I don't know what is most used syntax for this type. I'd rather keep them
together without a space between `()` and `[]`.
src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 3368:
> 3366: BYTE tmpState[AwtToolkit::KB_STATE_SIZE];
> 3367: WCHAR wc[2];
> 3368: memmove(tmpState, kstate, sizeof (kstate));
Suggestion:
memmove(tmpState, kstate, sizeof(kstate));
There's usually no space after `sizeof`.
-
Marked as reviewed by aivanov (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19798#pullrequestreview-2158844075
PR Review Comment: https://git.openjdk.org/jdk/pull/19798#discussion_r1665680146
PR Review Comment: https://git.openjdk.org/jdk/pull/19798#discussion_r1665657251
Re: RFR: 8332103: since-checker - Add missing @ since tags to java.desktop [v4]
On Wed, 26 Jun 2024 09:52:38 GMT, Nizar Benalla wrote: >> If you're currently reviewing this PR, thank you! >> Most fixes here are according to the reports by the since checker tool in >> #18934 and are pretty simple. >> >> To make reviewing easier >> - `BasicSliderUI` has the constructor `public BasicSliderUI(JSlider b)` for >> a long time so the default constructor (without parameters) didn't exist >> until JDK 16 >> >> For the `package-info` files, it is pretty hard to find source code of JDK >> 1-5 so I used the `grep` command to find the oldest instance of an `@since` >> in those packages. >> >> I found instances of `@since 1.1` in the other packages but >> `javax/swing/plaf/synth/package-info.java` might be worth checking as most >> classes there had no `@since`. > > Nizar Benalla has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains four commits: > > - Merge remote-tracking branch 'upstream/master' into JDK-8332103 > ># Conflicts: ># src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java > - See if an empty commit removes sponsor label > - Swing was added in JDK 1.2 > - Add `@since` tags to `java.desktop` @nizarbenalla Your change (at version 5e4e908975da353a5b3cd245af5ccf1f16401f38) is now ready to be sponsored by a Committer. - PR Comment: https://git.openjdk.org/jdk/pull/19192#issuecomment-2191444573
Re: RFR: 8332103: since-checker - Add missing @ since tags to java.desktop [v2]
On Wed, 15 May 2024 03:38:29 GMT, Nizar Benalla wrote: >> If you're currently reviewing this PR, thank you! >> Most fixes here are according to the reports by the since checker tool in >> #18934 and are pretty simple. >> >> To make reviewing easier >> - `BasicSliderUI` has the constructor `public BasicSliderUI(JSlider b)` for >> a long time so the default constructor (without parameters) didn't exist >> until JDK 16 >> >> For the `package-info` files, it is pretty hard to find source code of JDK >> 1-5 so I used the `grep` command to find the oldest instance of an `@since` >> in those packages. >> >> I found instances of `@since 1.1` in the other packages but >> `javax/swing/plaf/synth/package-info.java` might be worth checking as most >> classes there had no `@since`. > > Nizar Benalla has updated the pull request incrementally with one additional > commit since the last revision: > > Swing was added in JDK 1.2 @nizarbenalla Your change (at version 7e8244db63f54a7ffc9778b7ddb8947f7f21c4f5) is now ready to be sponsored by a Committer. - PR Comment: https://git.openjdk.org/jdk/pull/19192#issuecomment-2186645804
Re: RFR: 8334599: Improve code from JDK-8302671 [v2]
On Wed, 3 Jul 2024 13:34:38 GMT, Julian Waters wrote: >> In [JDK-8302671](https://bugs.openjdk.org/browse/JDK-8302671) I fixed a >> memmove decay bug by rewriting a sizeof on an array to an explicit size of >> 256, but this is a bit of a band aid fix. It's come to my attention that in >> C++, one can pass an array by reference, which causes sizeof to work >> correctly on an array and has the added bonus of enforcing an array of that >> size on the arguments passed to that method. I've reverted my change from >> 8302671 and instead explicitly made kstate an array reference so that sizeof >> works on the array as expected, and that the array size can be explicitly >> set in the array brackets >> >> Verification: https://godbolt.org/z/Ezj76eWWY and GitHub Actions > > 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: > > - Formatting sizeof awt_Component.cpp > - Formatting awt_Component.cpp > - Merge branch 'openjdk:master' into patch-10 > - Update src/java.desktop/windows/native/libawt/windows/awt_Component.cpp > >Co-authored-by: Alexey Ivanov > - 8334599 Weird syntax to someone like me, but I can see the benefit. Using memmove is so uncommon that it is usually a clear indication for a deliberate choice. - Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19798#pullrequestreview-2158913616
Re: RFR: 8334599: Improve code from JDK-8302671 [v2]
On Wed, 3 Jul 2024 13:25:27 GMT, Julian Waters wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 3368: >> >>> 3366: BYTE tmpState[256]; >>> 3367: WCHAR wc[2]; >>> 3368: memmove(tmpState, kstate, sizeof(kstate)); >> >> Using `memcpy` could be more performant, we know for sure that `tmpState` >> and `kstate` do not overlap. > > I can't quite comment on that since I don't really know what the purpose of > the memmove is. What does @prrace think? Both `memcpy` and `memmove` do the same thing, namely each function copies bytes from one location into another location. The difference between these two functions is in whether buffers are allowed to overlap or not: * [`memcpy`](https://en.cppreference.com/w/c/string/byte/memcpy): https://en.cppreference.com/w/c/string/byte/memcpy";>If the objects overlap […], the behavior is undefined.https://en.cppreference.com/w/c/string/byte/memcpy#Notes";>`memcpy` is the fastest library routine for memory-to-memory copy. It is usually more efficient than `strcpy`, which must scan the data it copies or `memmove`, which must take precautions to handle overlapping inputs. * [`memmove`](https://en.cppreference.com/w/c/string/byte/memmove): https://en.cppreference.com/w/c/string/byte/memmove";>The objects may overlap: copying takes place as if the characters were copied to a temporary character array and then the characters were copied from the array to `dest`. > we know for sure that `tmpState` and `kstate` do not overlap. For this reason, `memcpy` is safe to use, and it is more efficient than `memmove`. To be clear, I'm not proposing to incorporate this change under this bug. I just pointed out a possible optimisation. - PR Review Comment: https://git.openjdk.org/jdk/pull/19798#discussion_r1665654705
RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException
When a printjob is cancelled midway, `PrinterAbortException `was not thrown in macos. because firstly,` cancelCheck` invokes` LWCToolkit.invokeLater` with null as parameter causing it to fail with NPE and secondly PrinterAbortException was consumed silently when `printLoop` throws any exception which is rectified to throw the PrinterAbortException when encountered.. - Commit messages: - Test - 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException Changes: https://git.openjdk.org/jdk/pull/20027/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20027&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335231 Stats: 13 lines in 2 files changed: 2 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20027/head:pull/20027 PR: https://git.openjdk.org/jdk/pull/20027
Re: RFR: 8333403: Write a test to check various components events are triggered properly [v4]
On Tue, 2 Jul 2024 22:12:45 GMT, Alisen Chung wrote:
>> Ravi Gupta has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8333403: Review comments fixed
>
> test/jdk/java/awt/event/ComponentEvent/ComponentEventTest.java line 171:
>
>> 169: EventQueue.invokeAndWait(() -> {
>> 170: frame.dispose();
>> 171: frame.setVisible(true);
>
> I'm not really understanding this part. Why do you dispose the frame then
> setVisible here?
Thanks to providing the review comments here I want to revalidate the screen
resources by dispose and setVisible the frame before the frame ICONIFIED test.
These lines are not required , After removing these lines test also works fine.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19521#discussion_r1665496123
Re: RFR: 8333403: Write a test to check various components events are triggered properly [v5]
> This testcase checks for the following assertions for Component events: > > 1. When components are resized, moved, hidden and shown the respective events > are triggered. > 2. When the components are hidden/disabled also,the component events like > resized/moved are triggered. > 3. When a hidden component is hidden again, or a visible component is shown > again, the events should not be fired. > 4. When a window is minimized/restored then hidden and shown component events > should be triggered. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got > all pass. Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: 8333403: Review comments fixed - Changes: - all: https://git.openjdk.org/jdk/pull/19521/files - new: https://git.openjdk.org/jdk/pull/19521/files/9a3e95f1..6fc17f93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19521&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19521&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19521.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19521/head:pull/19521 PR: https://git.openjdk.org/jdk/pull/19521
Re: RFR: 8314498: [macos] Transferring File objects to Finder fails [v2]
On Fri, 29 Sep 2023 19:35:33 GMT, Arik Hadas wrote:
>> Credit goes to JetBrain that fixed it in JetBrainsRuntime (commit 24819d9).
>> This fix was also cherry-picked to muCommander and was verified on macOS
>> 12.6.8 and macOs 13, on X86_64 and on M1.
>>
>> Reproducer/steps-to-verify:
>> 1. Compile the following class:
>>
>> import java.awt.Toolkit;
>> import java.awt.datatransfer.DataFlavor;
>> import java.awt.datatransfer.Transferable;
>> import java.awt.datatransfer.UnsupportedFlavorException;
>> import java.io.IOException;
>> import java.nio.file.Files;
>> import java.nio.file.Path;
>> import java.util.Arrays;
>>
>> public class Arik {
>>
>> public static void main(String[] args) throws IOException,
>> UnsupportedFlavorException {
>> System.out.println("copying a file to the clipboard2");
>> var path = Files.createTempFile(null, null);
>> Files.writeString(path.toAbsolutePath(), "test");
>> Toolkit.getDefaultToolkit().getSystemClipboard().setContents(new
>> MyTransferable(path), null);
>> try {
>> Thread.sleep(Long.MAX_VALUE);
>> } catch (InterruptedException e) {
>> }
>> }
>>
>> public static class MyTransferable implements Transferable {
>> private Path path;
>>
>> MyTransferable(Path path) {
>> this.path = path;
>> }
>>
>> @Override
>> public DataFlavor[] getTransferDataFlavors() {
>> return new DataFlavor[] { DataFlavor.javaFileListFlavor };
>> }
>>
>> @Override
>> public boolean isDataFlavorSupported(DataFlavor flavor) {
>> return flavor.equals(DataFlavor.javaFileListFlavor);
>> }
>>
>> @Override
>> public Object getTransferData(DataFlavor flavor) throws
>> UnsupportedFlavorException, IOException {
>> return Arrays.asList(path.toFile());
>> }
>>
>> }
>> }
>>
>> 2. Run the compiled class using current JRE (`java Arik`)
>> 3. Switch to Finder and check the content of the clipboard (`Edit -> Show
>> Clipboard`)
>> 4. Verify you see "Cliboard contents: unknown" as in the following
>> screenshot:
>> > src="https://github.com/openjdk/jdk/assets/6020068/71d29b2e-209f-4445-a1e0-ecb3fc3e388b";>
>>
>> 5. Verify you cannot paste the content of the clipboard to Finder (`Edit ->
>> Paste` is disabled)
>> 6. Run the compiled class using JRE that includes this change (`java Arik`)
>> 7. 3. Switch to Finder and check the content of the clipboard (`Edit -> Show
>> Clipboard`)
>> 8. Verify you see "Cliboard contents: file ...
>
> Arik Hadas 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:
>
> 8314498: [macos] Transferring File objects to Finder fails
>
> Credit goes to JetBrain that fixed it in JetBrainsRuntime (commit 24819d9).
> This fix was also cherry-picked to muCommander and was verified on macOS
> 12.6.8 and macOs 13, on X86_64 and on M1.
Is there still some open issue/bug connected to this in the OpenJDK bug
database? Or some bug that has actually been fixed in some recent OpenJDK
version?
-
PR Comment: https://git.openjdk.org/jdk/pull/15980#issuecomment-2208501946
