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

@jzu-guru thanks! Have you tried the code at #3962 (comment) ? Perhaps increase the maxTries value. Can you reproduce with that?

No, I haven't. Wasn't aware of this code until now. I gave it a quick shot with my official NB 22 installation (I'm currently not at the machine with the dev build)) and increased the maxTries to 15.
As a result, in my Netbeans all sometext1 to sometext123456789101112131415 lines were present in the code file. On Notepad, all lines are present, but lines 2, 5, 14 and 16 were empty, so the content in Notepad looked like:

sometext

sometext12
sometext123

sometext12345
sometext123456
sometext1234567
sometext12345678
sometext123456789
sometext12345678910
sometext1234567891011
sometext123456789101112

sometext1234567891011121314

I'm not sure if this demonstrates the issue or if it just is some sync/timing problem. Because it always failed for one line only and worked again for the next line.

If it helps, my current workspace:
Product Version: Apache NetBeans IDE 22
Java: 21.0.3; Java HotSpot(TM) 64-Bit Server VM 21.0.3+7-LTS-152
Runtime: Java(TM) SE Runtime Environment 21.0.3+7-LTS-152
System: Windows 10 version 10.0 running on amd64; UTF-8; de_DE (nb)

@jzu-guru that is exactly the issue, so it seems you are also affected

Ok, then I'll try to do some System.out log messages in the dev build to see if there are any differences between the working and failing lines. Could take two or three days until I find the time for it, but will respond with the results.
Any hints to where and what I should log would be welcome. I have zero knowledge of Netbeans code ;-)

So, some results so far. The issue is pretty random. To more or less reliably get at least 2 or more missing copy/paste in the notepad win, I had to raise the maxtries to about 50. This extends the duration of each test run. But at least with a native NbClipboard.java from Tag 22 this way I can reliably reproduce two or more copy/paste errors per run.

But now the funny thing is coming. I've filled up the NbClipboard.java with several System.out.println(...). More or less half of the methods had one directly on entry, so was the first line in each affected method. Wasn't in all of the methods, but around every second one. Because I don't know where to look closer I've done some random choosing of some methods. I've changed nothing else in the source code, just added these println(). But this version now runs through the test without any loss of any copy&paste cycle. I've done three tests with 50 tries each. During that span the normal NbClipboard.java would have had at least 6 or more losses.

So my guess is, that this issue (or to be more precise: the issue which will be shown by the test case) is some timing/sync/context change problem. Unfortunately I'm not able to tell you, which method should be slowed down or be "interrupted" by a println() to show this effect. This would need some more of these long running tests, and currently I'm out of time, at least for the rest of this week.

This feels like a data race or cache sync problem. In Java today, class level member fields should really be marked final or volatile because of non-volatile optimizations that remove code paths.

@jzu-guru You could do a "research" on what is the effect of a "dummy/empty copy", in your logs, that could possibly point to a direction. The mysterious thing is why the hidden copied content is being revealed by this magic operation.

@jzu-guru

So my guess is, that this issue (or to be more precise: the issue which will be shown by the test case) is some timing/sync/context change problem. Unfortunately I'm not able to tell you, which method should be slowed down or be "interrupted" by a println() to show this effect. This would need some more of these long running tests, and currently I'm out of time, at least for the rest of this week.

My recollection is that logging/tracking/observing changes the behavior and has always made it more difficult to pin this down (damn you heisenberg). Maybe something like

PrintWriter myOut = new PrintWriter(new BufferedWriter(
                    new FileWriter("foo.out"), HUGE_SIZE_IF_NEEDED));

where myOut should be a drop in replacement for System.out, would be help to minimize the perturbation. At least it's buffered and there won't be any locking involved.

(Care must be taken for flushing myOut.)

Below is a patch that I used to fix a different, and most likely unrelated, problem in NbClipboard. (It was discussed at #7668 but ultimately left out of that PR since calling addFlavorListener/removeFlavorListener outside the Event Dispatch Thread makes code harder to reason about.)

On the off chance that the patch affects the bug discussed in this thread, because of timing interactions or such, feel free to try the patch on Windows and see if the bug still appears. (I am unable to reproduce the bug myself and so cannot be of more help here.)

After applying the patch (manually or with "patch -p1 < file_with_the_patch.txt" on WSL), do "cd platform/o.n.bootstrap" and then "ant" to recompile before "cd ../.." and "ant tryme". Thanks for any help!

diff --git a/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java b/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java
index ac2a3065d3..415f80ffe2 100644
--- a/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java
+++ b/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java
@@ -37,6 +37,7 @@ import java.lang.ref.WeakReference;
 import java.util.Collection;
 import java.util.logging.Level;
 import java.util.logging.Logger;
+import javax.swing.SwingUtilities;
 import org.openide.util.Exceptions;
 import org.openide.util.Lookup;
 import org.openide.util.LookupEvent;
@@ -337,16 +338,27 @@ implements LookupListener, FlavorListener, AWTEventListener
         if (ev.getID() == WindowEvent.WINDOW_DEACTIVATED) {
             anyWindowIsActivated = false;
             if( Utilities.isWindows() ) {
-                //#247585 - even listening to clipboard changes when the window isn't active
-                //may throw a MS Windows error as the 'clipboard copy' action doesn't have enough time to finish
-                systemClipboard.removeFlavorListener(this);
+                /* Avoid calling add/removeFlavorListener from the Event Dispatch Thread, as these
+                methods are synchronized and may block while the expensive
+                systemClipboard.getContents() method is being called. I once saw the EDT blocked on
+                removeFlavorListener this way for several seconds. */
+                RP.post(() -> {
+                    //#247585 - even listening to clipboard changes when the window isn't active
+                    //may throw a MS Windows error as the 'clipboard copy' action doesn't have enough time to finish
+                    systemClipboard.removeFlavorListener(this);
+                });
             }
         }
         if (ev.getID() == WindowEvent.WINDOW_ACTIVATED) {
             if( Utilities.isWindows() ) {
-                systemClipboard.addFlavorListener(this);
-                // Catch up on any events missed while we were away.
-                fireChange();
+                // Avoid calling addFlavorListener from the Event Dispatch Thread; see earlier comment.
+                RP.post(() -> {
+                    systemClipboard.addFlavorListener(NbClipboard.this);
+                    SwingUtilities.invokeLater(() -> {
+                        // Catch up on any events missed while we were away.
+                        fireChange();
+                    });
+                });
             }
             anyWindowIsActivated = true;
             if (log.isLoggable (Level.FINE)) {

Bad news: This issue if even more random than I thought. I've done some more runs, always with 50 tries (copy and paste events), which means one test runs for about 10 minutes. Some runs with println some with an unchanged .java file. Absolutely every run went without any copy/paste loss. This makes it really hard to impossible to tell if a change solves anything. :-(
It seems to also depend on other things, maybe the alternative load of the compuer? Which applications run besides Netbeans? How the other appliactions treat the system clipboard? The pattern of how and when someone switches between the appliactions? Or maybe just completely by accident/by chance?

From my point I'm not sure of how I should proceed now. The essential thing is, we neeed a procedure which can tell if a change has at least a great chance to solve this issue. Maybe I should extend the test to run for an hour or so? But then it can take a long time to check any changes, because this then can only be done in spare times when I don't need my computer otherwise. Means one max. two test runs per day?

Or is here someone who has a better repoducible rate with the test application?

The randomness is already known and currently there is no way to predict or replicate it as the mechanism is unknown. Only the FINEST setting has an effect reducing the frequency of appearance. What about the empty copy workaround? Does the eirikbakke patch has an effect?

That is exactly the point: I can't tell you if anything has any effect, because all of my recent tests (about 20-30, don't know exactly, but has tried over three hours) worked without any issue, regardless of what I've done or which code I've used

it is like chasing a ghost, so one of the apparent ways is to trace the only known reveal operation, witch is the "empty copy". (without using FINEST). I use the jLogMan plugin for switch of log settings

I summarize my findings.
The copy and paste from/to Netbeans works 1 or few times and after it is unusable anymore until I use CTRL+SHIFT+D and I choose to paste one of the cache strings available in the popup list.
The other way is to use DRAG and DROP, under this case the copy and paste works always to/from Netbeans.
This provides the evidence that the use of the clipboard is correct along with the drag and drop feature... so I expect the bugged cut/paste can be revised by inspecting the D&D code to see how the clipboard is used the right way.
This could also promote the reuse of the good code to solve this forever.

I have seen some users noting that control-X can solve the issue for them. I have tested this with the test code. The conclusion is that indeed this plays a significant role in the appearance frequency, acting similarly as if "the FINEST" log setting was active. Of course tests have been run without it.
control-C: 5 errors / 10 iterations
control-X: 2 errors / 64 iterations

So I assume that using FINEST and control-X can indeed improve the frequency of appearance further. For what is worth.
We cannot then be sure about the DRAG and DROP as it needs a test code that supports it. But a guess is that it could act as control-X, but nothing is for sure.

A slightly modified version of the test code with console messages: https://gist.github.com/istinnstudio/8f8f94a675a77cedb3ca3e5b6f558945

For those who are new to the background of this issue, the very first bug report I am aware of is here: 88161. It is not exactly the same issue but similar and includes the way optional clipboard hack created as to be some kind a solution, but at the end was not. You have to be patient to follow this old thread, but could reveal hidden gems, after comment 88 there are interesting posts that could have some value.

The comment 88 beginning phrases say that: "One of the biggest reason why we need fast query to clipboard was explorer. Whenever people selected new node, we needed to update state of paste action."

These words resonate with my experience with PHP-based "pgAdmin" application. While everyday having issues with NetBeans clipboard never have I noticed any issues between NetBeans and pgAdmin. So the external window (copy source, paste target) matters. Now pgAdmin is PHP-based and therefore is presumably slower integrated into Windows than native applications. Which hints on the possible problem in the code in NetBeans which detects and reacts on external Windows events like changing active window.

NB version 23, OS win 11 now have problems with copy in side NB

This happens consistently on a daily basis for me. It's almost to the point where I'll have to switch away from NetBeans.

Windows 11 Pro 23H2

Product Version: Apache NetBeans IDE 22
Java: 17.0.12; OpenJDK 64-Bit Server VM 17.0.12+7
Runtime: OpenJDK Runtime Environment 17.0.12+7
System: Windows 11 version 10.0 running on amd64; UTF-8; en_CA (nb)

@stodge Give a quick try to "FINEST" log setting -J-Dorg.netbeans.NbClipboard.level=FINEST, use the jLogMan plugin for a quick test. It might decrease considerably the appearance frequency of the bug in the sense you will probably tolerate it, at least you can work as expected for longer time

I am able to reproduce the problem very consistently in about three tries of copy pasting from/to Notepad++ and Netbeans (v 20 running on JDK 17) on windows 11. I have tried -J-Dorg.netbeans.NbClipboard.level=FINEST and other suggestions mentioned in this thread as well. No luck.

@pryshrm Make sure FINEST is actually enabled using jlogman plugin. If indeed this is the case, there are OS cases with higher degree of affection. It has been mentioned before from the author of test code. I am not sure if it has to do with win11 as I am still on 10.

This really has to be an issue with a non volitile variable being used to pass state between threads. Most likely, there is occasional locking that causes the correct CPU cache flush to occur, or the write to the non-volatile variable to become visible due to some other action. @pryshrm can you put into words, the exact steps you are taking to recreate it here? Can you then try to figure out a different way to accomplish what you found to recreate the problem, to see if you can do something in netbeans between copy and paste that causes the paste to always work?

For Java engineers, someone needs to create an altered version of the compiler that supports default declaration of all class variables as volatile, instead of non-volatile. Then we need to try compiling netbeans with that compiler, or at least the classes associated with this problem, and then see if the problem still occurs.

Finally, for all of us, can someone finally propose a language change such that volatile is the default, and that the syntax !volatile can be used to let developers who know what they are doing, decide that non-volatile is how they really want their declaration to work?

Literally, there is next to zero class level variables that are accessed so often and set so often on a single thread, that a non-volatile declaration would be helpful. Let the programmer decide on that optimization!

the problem with long threads is that few will read the whole thread before posting, which creates loops and a lot of notifications - which risks that some will start unsubscribing. Github is also not helping here, since issues do not support pagination like 90s forums did, gh collapses most of the thread.

And since we are now discussing java language spec changes, it already reached the off topic phase ;)

as mentioned in #3962 (comment), i will do the following:

• i will lock this issue, this will only allow committers and collaborators to post
• for more discussion please use the prepared Windows clipboard issues discussion #7051
  • "github discussions" should be hopefully better suited for this since they have sub-threads
  • committers can still bring additional info gained from the discussion back to this issue whenever it makes sense
• someone might go through this issue and collapse duplicate/offtopic posts if necessary but it is probably too late for this at this point

updates:

• it could be reproduced outside of NetBeans which confirmed that it is a JDK bug https://bugs.openjdk.org/browse/JDK-8353950
• JDK patches are available, after discussing various options, it was decided to apply the patch via JVM agent until fixed in the JDK itself
• NetBeans 26 RC 1 contains the fix, see Apache NetBeans 26 release candidates #8431 for release candidate testing

see the discussion #7051 for the full story.

I tested NetBeans 26 RC 1 with @bradvido's clipboard bug testing code, on Java 21.0.4 for Windows. The bug did not reproduce. As a control, I then reverted to an older NetBeans 22 install I had on the same machine, and the bug reappeared. Switching back to 26-rc1 again, the bug disappears.

The bug indeed appears fixed in 26-rc1. Fantastic work everyone!