Unfortunately a long standing annoyance, which doesn't seem to have a definitive reproducible cause, or we know whether it's definitely NetBeans or the JDK at fault. Have a read of https://lists.apache.org/thread/xqkwy4wxylmzprxl1wko301hlqz59r7d and some of the flags, logging settings, etc. Be great to get to the bottom of this one!

This is very annoying problem. I teach coding. Usually I code in a Google doc because it is live and students can follow along easily. When I want to compile my code I paste it into NetBeans. It fails and only pastes the last thing I copied from within Netbeans. Apparently the copy and paste works only within Netbeans. THIS IS A PROBLEM. Please fix!

The work around is to open the source file concurrently in a text editor and copy and paste there which updates the source file in Netbeans.

@Montanajim if you have a reliable reproducer, then please share as much information as you can about environment, JDK, Windows version, browser you're pasting from, etc. Does it reproduce immediately, or after a time? Is it after a particular type of content has been added to the clipboard (from anywhere)? Do any of the suggestions in the linked thread above help? Is it NetBeans specific, or can you reproduce with other Java (Swing) applications?

It's well known that this is a problem, just not what the fix should actually be!

I can reproduce the bug through these steps:

1. Copy a piece of text in Netbeans
2. Paste the text in an applicaiton
3. In From this application copy some other text
4. Paste the text into netbeans
5. Paste it somewhere
6. Copy text again
7. Every new copy from netbeans from now on will not work anymore. If I do not copy in an outside application the clipboard will now be empty (and not the text from step 6 anymore)

I tested these steps with Notpad++, Firefox and the windows file explorer and have the same result exactly after these steps. Also if I mix applications in between.
I checked the logs but no error was reported.
I am running Netbeans 13 on Windows 10.0 on amd64 with Oracle JDK 17 (17+35-LTS-2724) but had the same issue on older JDKs.

If I can send you any log files or if I can help somehow please write me.

This happens also in Windows 11 with AdoptOpenJDK 11 and Netbean zip distribution

I have the same Problem. It occurs with any Apache Netbeans version (ranging from NB9 to NB15) and with every JDK Build on Windows that I have tested. This includes Java 8, 11 and 17 via Eclipse Temurin JDK, Azul Zulu JDK and some other JDK builds.

The bug occurs seemingly random.

Edit: Please see @epliskin's workaround as it also works consistently and does not require the extra plug-in from NB 7.1

I have found a workaround that works consistently:

Setup

• Goto Tools -> Plugins (Tab: Settings)
• Add the following Mirror: http://plugins.archive.librebeans.org/catalogue/7.1/catalog.xml and give it a name
• Switch to Available Plugins and install the Plugin Copy and Paste History (Version 3.2.0 by Michel Graciano)
• Restart Netbeans
• Goto Tools -> Options -> Miscellaneous -> Copy and Paste History and check the box Replace Clipboard Content when pasting from history

Workaround

When the bug occurs, then press Alt+V in NB editor to open the clipboard history and insert any item from the menu that should have been opened by the plugin. Press Ctrl+Z to revert the insertion. The clipboard should work normally now.

Performing the Workaround before the bug occurs does not stop the bug from happening. Only performing the workaround after the bug occurs fixes the problem until the bug occurs again.

Same issue with NB 13 and JDK 17. Doing a Control + c in netbeans and then control + v in netbeans works but control + v in another application doesn't work. In the other application stuff that was copied earlier is pasted (not the stuff that was copied most recently from NB). Reverse doesn't work either.

Doing empty Control+C (i.e. cntrl c without selecting any text) seems to reset this behavior. So, if ctrl v is not pasting the right stuff, do an empty ctrl c in netbeans and then select stuff and cntrl c to copy it. Now do ctrl v on another application to paste. It works.

Once it is pasted, then the problem resurfaces. So you have to do an empty cntrl c again to reset. Crazy.

Same issue with NB12 and NB13 platform applications using JDK 11, 16, 17.

I have the same problem.
Windows OpenJdk 16.0.2.

the workaround by @duoduobingbing did not work the Copy and Paste History. The link is dead.

anyone have a workaround too ?

A naive attempt to fix: #4572

Also you may add the following command line option to netbeans.exe (or put it into netbeans.conf):

-J-Dnetbeans.slow.system.clipboard.hack=false

That'd switch off NetBeans Clipboard handling hacks which is enabled by default on all platforms save Mac.

Those hacks were introduced as a workaround for an AWT System clipboard issue around Java 5. They might be obsolete and causing issues now.

Please report back your experience either you are trying a build with the PR or testing the app with the provided flag!

Testing the command line option with Netbeans 14 on Windows 11 and Java 11
The issue persists

Thanks @NicolaIsotta Could you also try with -J-DTopSecurityManager.disable=true.

When you say it persists, is it immediate, or does it happen after some time? If after a time, is there anything you're doing that seems to be a common trigger? Is there anything that seems relevant in View / IDE Log around the time the problem starts occurring?

Are you able to get a log of when it goes south. There discussion of this in

https://lists.apache.org/thread/nsg2pdzrs3go9f4zlhy0gjs2hfxmbdbn

But basically

Edit the netbeans.conf file in netbeans/etc/ to add:
 -J-Dorg.netbeans.NbClipboard.level=FINEST

Also check with Java 17. This issue is on how Native Clipboard communicate with the JVM, so the JVM can count as well.

Same issue with NetBeans 15, JDK 17, Windows. Based on duoduobingbing advice above the workaround is simply to open the built-in NetBeans clipboard history dialog with (Ctrl+Shift+D), select an item from history to paste into NetBeans editor and revert insertion with (Ctrl+Z). This magic revitalizes the NetBeans clipboard.

It is so strange that we do not get feedback from the Windows folk running the IDE with -J-DTopSecurityManager.disable=true or -J-Dnetbeans.slow.system.clipboard.hack=false...

-J-DTopSecurityManager.disable=true does not work for me at all, when I am using this option I cannot use the clipoard anywhere outside netbeans. -J-Dnetbeans.slow.system.clipboard.hack=false does work for me, if not combined with -J-DTopSecurityManager.disable=true. Still, I have to recopy text in netbeans to paste it somewhere else.

Besides, using the clipboard history, as mentioned by @epliskin , also works for me.
(I am using Netbeans 14 on Oracle JDK 17)

An hour ago I configured netbeans.conf with (-J-DTopSecurityManager.disable=true -J-Dorg.netbeans.NbClipboard.level=FINEST) and started NetBeans 15 with JDK 17. Clipboard works as yet fine between NetBeans and other Windows programs. At this time I do not edit any code eagerly but will report here in coming days or weeks if and when NetBeans clipboard freezes again...

I wanted to thoroughly test before writing that this and that option definetely works or does not work; but here are my results after running with some options for a longer time:

• -J-Dnetbeans.slow.system.clipboard.hack=false: The bug seemed to occur less frequently but it still occured.
• -J-Dnetbeans.slow.system.clipboard.hack=false and -J-Dorg.netbeans.NbClipboard.level=FINEST: Seems to fix the issue. The bug did not occur once during using these.
• -J-Dorg.netbeans.NbClipboard.level=FINEST: Seems to suffice. Have not used it as long as the others (less than one month) but the bug did not occur. Hopefully this is not tied to a race condition where org.netbeans.NbClipboard.level=FINEST fixes it for most people but not all.
• -J-DTopSecurityManager.disable=true: Did not change anything. The bug still occured.
• -J-DTopSecurityManager.disable=true and -J-Dorg.netbeans.NbClipboard.level=FINEST: The bug did not occur.

See attached NetBeans log for this bug. I was editing some code when it happened. Could not paste from other Windows app, could not copy from NetBeans to another Windows app, but still could copy and paste text inside NetBeans editor.

netbeans_default_options = ... -J-DTopSecurityManager.disable=true -J-Dorg.netbeans.NbClipboard.level=FINEST

messages.zip

And again some time after NetBeans restart...

messages2.zip

I have the same problem with Netbeans 16, JDK 18. I have experienced the problem only in Java files so far, when I copy a text from pom.xml, for example, it works fine. Adding -J-Dorg.netbeans.NbClipboard.level=FINEST to netbeans.conf seems to fix the problem.

I have the same problem with Netbeans 16, JDK 18. I have experienced the problem only in Java files so far, when I copy a text from pom.xml, for example, it works fine. Adding -J-Dorg.netbeans.NbClipboard.level=FINEST to netbeans.conf seems to fix the problem.

Yes. i confirm. it works.

Adding -J-Dorg.netbeans.NbClipboard.level=FINEST isn't a fix, and judging from @epliskin comments doesn't always mask the issue either. Enabling all the additional logging might be helping with a race condition, or maybe eagerly acquiring the transfer data in logFlavors() is helping - https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java#L288

added Contribution welcome An issue or feature not currently being worked on, but a contribution would be welcomed! label in case someone on windows wants to look into it.

I whipped this together quickly. It reproduces the issue every time for me on a vanilla netbeans 18 install with JDK17.
All it does it copy/paste between netbeans and notepad.

Here's an example/screen recording. It works on the first copy/paste attempt, and the subsequent 4 fail:
https://capture.dropbox.com/aL3a0aLjMzAGqbz0

Not sure exactly how you want me to contribute this, so just putting it here for now

package copypastetest;

import java.awt.Robot;
import java.awt.event.KeyEvent;

public class CopyPasteTest {

    int maxTries = 5;

    public static void main(String[] args) {
        /*
            Put cursor inside this comment block before running.
            
         */
        try {
            new CopyPasteTest();
        } catch (Exception x) {
            x.printStackTrace();
        }
    }

    private final Robot robot;

    public CopyPasteTest() throws Exception {
        robot = new java.awt.Robot();

        //open notepad, give it some time to get focus, and write our starting text
        Runtime.getRuntime().exec("notepad");
        Thread.sleep(1500);
        writeText("sometext");

        for (int tryNum = 1; tryNum <= maxTries; tryNum++) {
            copyLine();//copy from notepad
            enter();//go to next line in notepad (to prep for next paste)
            altTab();//go to netbeans
            paste();//paste into netbeans
            writeText(String.valueOf(tryNum));//add try num to the text in netbeans
            copyLine();//copy from netbeans
            enter();//go to next line in netbeans (to prep for next paste)
            altTab();//go to notepad
            paste();//paste into notepad
        }

    }

    private void writeText(String text) {
        for (char c : text.toCharArray()) {
            int keyCode = KeyEvent.getExtendedKeyCodeForChar(c);
            _press(keyCode);
            _release(keyCode);
        }
    }

    private void copyLine() {
        //highlight this line
        _press(KeyEvent.VK_END);
        _release(KeyEvent.VK_END);
        _press(KeyEvent.VK_SHIFT);
        _press(KeyEvent.VK_HOME);
        _release(KeyEvent.VK_HOME);
        _release(KeyEvent.VK_SHIFT);

        //copy highlighted text
        _press(KeyEvent.VK_CONTROL);
        _press(KeyEvent.VK_C);
        _release(KeyEvent.VK_C);
        _release(KeyEvent.VK_CONTROL);

        //remove highlight, put cursor at end of line
        _press(KeyEvent.VK_END);
        _release(KeyEvent.VK_END);

    }

    private void paste() {
        _press(KeyEvent.VK_CONTROL);
        _press(KeyEvent.VK_V);
        _release(KeyEvent.VK_CONTROL);
        _release(KeyEvent.VK_V);
    }

    private void enter() {
        _press(KeyEvent.VK_ENTER);
        _release(KeyEvent.VK_ENTER);
    }

    private void altTab() {
        _press(KeyEvent.VK_ALT);
        _press(KeyEvent.VK_TAB);
        _release(KeyEvent.VK_ALT);
        _release(KeyEvent.VK_TAB);
        try {
            Thread.sleep(1000);//breathing room for windows
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
    }

    private void _press(int e) {
        robot.keyPress(e);
        try {
            Thread.sleep(200);
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
    }

    private void _release(int e) {
        robot.keyRelease(e);
        try {
            Thread.sleep(200);
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
    }
}

@bradvido Super. Now we getting somewhere.

@bradvido Brad, thanks for all the time you invested digging into this. This bug is a real PITA. Hopefully this really helps drilling down to the root cause.

Thanks @bradvido for taking the time to write that code and share that video. Really useful to have.

The negative is that I still cannot reproduce on my Windows 11 system. Tried increasing the maxTries value to 25. Still completed fine.

I was using the community installer from https://www.codelerity.com/netbeans/ Can you replicate with that? That uses a bundled Azul JDK 20. Let's take JDK differences out of the equation.

Secondly, could you share the output of Help / About? In particular the Java, Runtime and System lines for comparison.

Of course, my experience could be system dependent - the fact that having logging enabled fixes it for some people suggests that it could be a side effect of the code in the logging or a race condition somewhere.

just a simple "run" of @bradvido 's code releases the freak from the first run here, jdk17, NetBeans 17, windows 10. It copies and pastes in editor from notepad and vice versa, every run produces different results, so it is not consistent for 5 iterations plus one run after the other.

@istinnstudio thanks for confirming you are able to reproduce this with the code

@neilcsmith-net , I've downloaded the installer from the codelerity link, and have tested that.
Here's the output of my runtime environment:

java.version: 20.0.1
os.name: Windows 11
os.version: 10.0
os.arch: amd64

Any my netbeans "about"

And still get the same results. Copy/Paste fails after one or two attempts. Interestingly, it's not consistent as to what attempt it start to fail on, but it always fails.

Since we are on identical netbeans runtimes and JDKs, and you are saying that it's working consistently for you through 25 iterations, I'm at a loss. We are also both running Windows 11,

Have you set and of these properties in your netbeans? Mine is completely vanilla.

-J-Dnetbeans.slow.system.clipboard.hack=false
-J-DTopSecurityManager.disable=true
-J--add-opens=java.desktop/sun.awt=ALL-UNNAMED
-J-Dorg.netbeans.NbClipboard.level=FINEST 

@bradvido thanks for the info. Yes, vanilla settings. Only difference I can see is the locale en_GB vs en_US - unlikely, but tried changing - 25 repetitions again without issue.

I wouldn't think there would be, but is there a difference between using the zipped version of NetBeans vs the Windows installer? Is this a Windows only issue? Could the installer be setting up a different configuration?

I download straight from Apache: https://netbeans.apache.org/download/nb18
I have always downloaded the zipped version.

Within the netbeans.conf file:

• I prepend -J-Dorg.netbeans.NbClipboard.level=FINEST -J-Dnetbeans.slow.system.clipboard.hack=false to the netbeans_default_options
• Define my netbeans_jdkhome (currently set to jdk-17.0.6+10).

I've been doing that since probably NetBeans 15 and haven't had the copy/paste issue since.

Now I do have another copy/paste issue in which NetBeans doesn't grab the correct text within the output dialog. I'm unsure if it is related. When I attempt to copy say "FGH" from "ABCDEFGHI" I may get "DEF" instead. This only happens in the output dialog though. I usually have the output dialog window text wrapped too.

I wouldn't think there would be, but is there a difference between using the zipped version of NetBeans vs the Windows installer? Is this a Windows only issue? Could the installer be setting up a different configuration?

There are two possible installers, that set things up in slightly different ways. That was the other reason for asking for verification with the community installer, which uses NBPackage. The ASF installer hasn't moved to that yet. If it affected one and not the other it could have helped narrow things down.

When you use the zip, which launcher do you use? That's unlikely to be the reason, though - the logging has side effects which I think may be helping some people.

Now I do have another copy/paste issue in which NetBeans doesn't grab the correct text within the output dialog. I'm unsure if it is related. When I attempt to copy say "FGH" from "ABCDEFGHI" I may get "DEF" instead. This only happens in the output dialog though. I usually have the output dialog window text wrapped too.

This is #5293 by the sound of it.

When you use the zip, which launcher do you use?

netbeans64.exe

Can't reproduce it with the CopyPasteTest code but the bug does happens from time to time in my environment.
Installed with Apache-NetBeans-18-bin-windows-x64.exe

Product Version: Apache NetBeans IDE 18
Java: 20.0.2; OpenJDK 64-Bit Server VM 20.0.2+9
Runtime: OpenJDK Runtime Environment 20.0.2+9 
System: Windows 10 version 10.0 running on amd64; UTF-8; en_US (nb

I've done some A/B testing with and without having these properties set:
-J-Dorg.netbeans.NbClipboard.level=FINEST -J-Dnetbeans.slow.system.clipboard.hack=false to the netbeans_default_options

With both set: fails on average at the 9th attempt.
With only -J-Dorg.netbeans.NbClipboard.level=FINEST set: fails on average at the 9th attempt.
With only -J-Dnetbeans.slow.system.clipboard.hack=false: fails on avergage at the 2nd attempt
With none set: fails on avergage at the 2nd attempt

Based on this, it's the introduction of FINEST level logging that helps, but doesn't fix the issue. I have no idea why. One theory I have is that the extra logging introduces just enough of a slowdown in netbeans clipboard that allows {some other asynchronous process} to do its thing.

Based on testing results, I don't think -J-Dnetbeans.slow.system.clipboard.hack=false has anything to do with this issue.

I'm willing to dig in further but need some direction.

@bradvido for my first tests I made a basic platform application via maven and debuged it. I got the feeling that in this app the error occured much less frequently. So I guess it is somewhere in additional flavours code, maybe in copy Java flavour since some of the hacks to resolve it using copy class stuff.

just a short video to show how easy is to reproduce with @bradvido 's code, just place the cursor in an empty line position and run...
video file

and the screenshot of the second run:

Based on this, it's the introduction of FINEST level logging that helps, but doesn't fix the issue. I have no idea why. One theory I have is that the extra logging introduces just enough of a slowdown in netbeans clipboard that allows {some other asynchronous process} to do its thing.

@bradvido It could be that, but it could also be that the logging introduces a bunch of potential side effects - or at least eagerly initializes some things. See eg. https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java#L216 and logFlavors().

As it still fails for you with logging enabled could you share anything relevant / different in the log output when you have a working vs non-working copy-paste?

@istinnstudio yes, it's great to have something that easily reproduces on an affected system, but also more clearly shows that not all systems are affected.

can someone post a netbeans.conf file of an unaffected system? just to be sure the default is identical. is there a way to enable logging in the release version or it is possible only in code while compiling?

can someone post a netbeans.conf file of an unaffected system? just to be sure the default is identical.

Well, mine is unaffected, with the default. I'm not sure how many people who are neither affected nor NetBeans developers are going to be tracking this issue!

is there a way to enable logging in the release version or it is possible only in code while compiling?

Yes, adding -J-Dorg.netbeans.NbClipboard.level=FINEST to either netbeans.conf or the command line in the shortcut properties should do it.

If you want to dynamically adjust the logging, without restarting NetBeans, there's jLogMan https://plugins.netbeans.apache.org/catalogue/?id=40; this should be available in Tools > Plugins.

I've wondered if turning the logging on/off without restarting NetBeans, might have different results.

Here is the log output of a successful paste from netbeans to notepad and a failed paste from netbeans to notepad (with -J-Dorg.netbeans.NbClipboard.level=FINEST set)
successful.log
failed.log

Today I could observe that a copy paste from a Java editor of an complete expr did fail and an incomplete expression worked again. Multiple times. Did anybody test this while java ide features are switched off? Maybe that is the reason my platform application did not have this problem anymore after including this logging fix.

there is progress, at least for me! I do not know what exactly happened but having the "-J-Dorg.netbeans.NbClipboard.level=FINEST" at the end of netbeans.conf options (at the netbeans_default_options="... ") did nothing at all, Then I removed it. After reading last comments I have installed jLogMan and modified the shortcut in windows to point at --> "C:\Program Files\NetBeans-17\netbeans\bin\netbeans64.exe" -J-Dorg.netbeans.NbClipboard.level=FINEST, and then revelation, tested for 25 iterations with @bradvido 's code. Tested also real copy/paste sessions, fine, creasy stuff... so I do not know if the order of the argument plays a role (I guess it does) or the plugin has participated in this.

flag order shouldn't matter unless you configure logging twice. One thing to watch out for is that the config contains by default -XX:+IgnoreUnrecognizedVMOptions which will let the JVM ignore all typos quietly in case there are any.

@mbien you are probably right. Maybe other arguments proposed here can "kill" the FINEST argument. At least it works as a shortcut or if used "standalone" after IgnoreUnrecognizedVMOptions. My new tests with many iterations revealed only one missed hit per try, but now it is rare maybe once per a big number like 256. So it does not resolve the issue completely, but changes the frequency it appears. I encourage users to use also the shortcut version and keep config to default. On tests with 256 iterations (reducing the sleep timings), if argument activated ok (checking the log), the FINEST reduces the frequency of the bug appearance. I got a missed hit at a random iteration, one at 14th on first try and one at 26th on the second. At least I can work now without much trouble. Hopefully this will work for others also till the final solution. Thanks everyone for their contribution,

there is progress, at least for me!

I tried this setup, but found no difference in specifying the option directly as an argument vs. adding it to the .conf file. Both enabled the extra logging in the log file. Both fail at the same rate (usually around the 7th copy/paste attempt).

I also added the jLogMan plugin, hoping it may actually be causing your successes, but there was no change with it either. I was able to use it to confirm that the log level was set to FINEST for NbClipboard, but we already knew that.

@istinnstudio , I will be interested to hear if this fix works for you long term, or if you just happened to get lucky. Keep us posted!

it could also be that the logging introduces a bunch of potential side effects - or at least eagerly initializes some things. See eg. https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java#L216 and logFlavors().

@neilcsmith-net this seems plausible, but I haven't found any smoking guns from just looking at the code. Also FYI, I did post logs of success vs failure here: #3962 (comment)

jLogMan plugin, hoping it may actually be causing your successes, but there was no change with it either. I was able to use it to confirm that the log level was set to FINEST for NbClipboard

When the log level is FINEST and it's working better (which is mostly what people see), if you change it to inherit (which I'm assuming is default) without restarting, does it get worse?

I'm assuming it will get worse; based on the current theory that code when FINEST changes something and makes things better.

@errael I confirm that without restarting, using LogMan with inherit fails immediately with 5 fails / 12 iterations, FINEST is 1 or 2 fails per hundred's of iterations, now I got 2 fails/128 iterations, random positions at 97 and 124.

in any case I paste the clean config and commented out the relevant arguments (not to be uncommented there, just for reference):

netbeans_default_options="-J-XX:+UseStringDeduplication -J-Xss2m  -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.dpiaware=true -J-Dsun.zip.disableMemoryMapping=true -J-Dplugin.manager.check.updates=false -J-Dnetbeans.extbrowser.manual_chrome_plugin_install=yes  -J--add-opens=java.base/java.net=ALL-UNNAMED -J--add-opens=java.base/java.lang.ref=ALL-UNNAMED -J--add-opens=java.base/java.lang=ALL-UNNAMED -J--add-opens=java.base/java.security=ALL-UNNAMED -J--add-opens=java.base/java.util=ALL-UNNAMED -J--add-opens=java.base/java.nio=ALL-UNNAMED -J--add-exports=java.base/sun.reflect.annotation=ALL-UNNAMED -J--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED -J--add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED -J--add-opens=java.desktop/javax.swing.text=ALL-UNNAMED -J--add-opens=java.desktop/javax.swing=ALL-UNNAMED -J--add-opens=java.desktop/java.awt=ALL-UNNAMED -J--add-opens=java.desktop/java.awt.event=ALL-UNNAMED -J--add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED -J--add-opens=java.desktop/javax.swing.plaf.synth=ALL-UNNAMED -J--add-opens=java.desktop/com.sun.java.swing.plaf.gtk=ALL-UNNAMED -J--add-opens=java.desktop/sun.awt.shell=ALL-UNNAMED -J--add-opens=java.desktop/sun.awt.im=ALL-UNNAMED -J--add-exports=java.desktop/sun.awt=ALL-UNNAMED -J--add-exports=java.desktop/java.awt.peer=ALL-UNNAMED -J--add-exports=java.desktop/com.sun.beans.editors=ALL-UNNAMED -J--add-exports=java.desktop/sun.swing=ALL-UNNAMED -J--add-exports=java.desktop/sun.awt.im=ALL-UNNAMED -J--add-exports=java.desktop/com.sun.java.swing.plaf.motif=ALL-UNNAMED -J--add-exports=java.desktop/com.apple.eio=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED -J--add-opens=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED -J--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED -J--add-modules=jdk.jshell -J--add-opens=jdk.jshell/jdk.jshell=ALL-UNNAMED -J--add-exports=jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED -J--add-exports=jdk.jdeps/com.sun.tools.javap=ALL-UNNAMED -J--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED -J--add-exports=java.management/sun.management=ALL-UNNAMED -J-XX:+IgnoreUnrecognizedVMOptions"
#BUG https://github.com/apache/netbeans/issues/3962
#-J-Dorg.netbeans.NbClipboard.level=FINEST
#-J-Dnetbeans.slow.system.clipboard.hack=false
#-J-DTopSecurityManager.disable=true
#-J--add-opens=java.desktop/sun.awt=ALL-UNNAMED

Is it possible to reproduce the problem using a normal logging level and then using LogMan to increase the clipboard logging to FINNEST and setting what NetBeans thinks it is copying and pasting? I am not running NetBeans anymore but it stands to reason you could add enough logs to track the flow on success vs failure and diff the two. If you don't see ac difference, it means you need to add more logs until you catch the difference.