This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This may be related to issue #218447. I'm also assuming that this is OS X specific but I haven't tested. This has been around for a while. Pasting does not work properly with some file types on OS X (including java files). Specifically, if you copy or cut code from a java file, then try to paste that code to a java file, the paste command doesn't work. Oddly, if you copy/cut code as above, but paste to a text file (or outside of Netbeans), that works. You can also copy text from a text file (or from outside of Netbeans) and paste into a java file. So a workaround is to copy/cut the code from a java file, paste to a text file, reselect and copy the code from the text file, and paste into the java file. Even more oddly, at one point the file types that had the copy/paste problem "switched". That is, I could copy/paste in java files fine but couldn't copy/paste in XML files. Even though there is a workaround, I think this is a P1 because it's very basic functionality.
Selecting Paste from the edit menu also does not work. Product Version: NetBeans IDE Dev (Build 201305202300) Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b30 Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b88 System: Mac OS X version 10.8.4 running on x86_64; UTF-8; en_US (nb) User directory: /Users/alvin/Library/Application Support/NetBeans/dev Cache directory: /Users/alvin/Library/Caches/NetBeans/dev
(In reply to comment #0) > Even though there is a workaround, I think this is a P1 because it's very basic > functionality. Agreed this is serious. Though, this one is on an unreleased JDK8 and a workaround exists. Changing to P2.
This also happens on my machine (MacBook Pro/Retina, using JDK8). Note that although JDK8 is not released, it is the preferred option to running NetBeans in native retina resolution (the other option is using JDK6). Thus, this issue is going to be annoying for a lot of devs.
*** Bug 232021 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Note that although JDK8 is not released, it is the preferred option to running > NetBeans in native retina resolution (the other option is using JDK6). Thus, > this issue is going to be annoying for a lot of devs. For retina you can also use early access builds of 7u40. Available at https://jdk7.java.net/download.html
So to use JDK8 things, we run NetBeans on JDK7 and use JDK8 for the projects? This is not so nice to manage on MacOS X (possible but no very nice). Any chance this will make it into NetBeans 7.4 (or 7.4.1?) - looking at the roadmaps - these seem to be the versions available for the Developer Preview of JDK8 (2013/09/05). Would really be nice if people trying this out, would not be getting hit by this nasty bug.
Note that in the edit menu "Paste from History" works. So the Copy side is working. It is just regular paste that is broken.
(In reply to swpalmer from comment #7) Yup. I've also noticed that paste will work in some sections of some XML documents but not in other sections.
Strange enough it sometimes works for me if I copy a text, restart the IDE and then paste (NB 7.3.1, OSX 10.8 JDK 1.8-ea).
When executing 'copy', I get the following message in the message.log: java.io.IOException: cannot transfer non-text data as Reader at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1213) at sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) at sun.lwawt.macosx.CClipboard.setContentsNative(CClipboard.java:76) at sun.awt.datatransfer.SunClipboard.setContents(SunClipboard.java:110) at org.netbeans.NbClipboard$SetContents.run(NbClipboard.java:462) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1432) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2042)
*** Bug 234521 has been marked as a duplicate of this bug. ***
Paste menu item flashes but the actual paste fails. This has been very irritating for those working on JDK 8. I hope it is fixed in 7.4 soon (still fail in 7.4 beta.)
This still fails on JDK8 b106, the "developer preview" build. Please investigate this and communicate to the JDK folks so that they know what to fix. While there is a workaround, it is so clumsy as to be unworkable. I'm finding NetBeans to be almost unusable with this bug.
(In reply to jag from comment #13) > This still fails on JDK8 b106, the "developer preview" build. Please > investigate this and communicate to the JDK folks so that they know what to > fix. While there is a workaround, it is so clumsy as to be unworkable. I'm > finding NetBeans to be almost unusable with this bug. I understand your frustration, but our priority for 7.4 was focus on bugs on officially realeased JDKs so it means there will be no fix on NB side for 7.4. However, I can spend more time to investigate this bug now and eventually file a JDK bug if needed. In comment #2 there is a justification for this issue to be P2 and it is still valid -> changing back to P2
(In reply to jag from comment #13) > This still fails on JDK8 b106, the "developer preview" build. Please > investigate this and communicate to the JDK folks so that they know what to > fix. While there is a workaround, it is so clumsy as to be unworkable. I'm > finding NetBeans to be almost unusable with this bug. Hi Jag, You can work around this by running NetBeans with JDK 7 while still developing for JDK 8. Here's how: 1. install JDK 7 in addition to JDK 8 on your Mac 2. edit the "netbeans.conf" file to have netbeans run with JDK 7 a. at "/Applications/NetBeans/<version>/Contents/Resources/NetBeans/etc" b. there is a commented section in the file for setting the platform 3. launch NetBeans--it will use the specified JDK 4. add both JDK 8 and JDK 7 under "Tools|Java Platforms" a. i would explicitly add both JDK 7 and 8 here in addition to the default b. the JDKs are located under "/Library/Java/JavaVirtualMachines" - example: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home 5. explicitly specify the JDK you want for each project in project properties a. change "Sources|Source/Binary Format" and "Build|Compile|Java Platform" b. never leave platform as the default JDK since the default can change Ideally, if JDK_HOME is defined in your login environment NetBeans should use that as the JDK it runs with. Currently, Netbeans defaults to simply running with the highest JDK installed. This is not the best choice since the highest JDK installed may be a buggy development build (as in this case). I've been meaning to submit a bug/enhancement for that.
The workaround doesn't work for JavaFX projects.In JavaFX projects you cannot choose JDK 1.8 as a platform, because NetBeans assumes the JDK doesn't support JavaFX when running on JDK 7. Also support for JDK 8 is one of the release themes for 7.4. So both reasons in comment #2 are invalid.
(In reply to maxnitribitt from comment #16) > The workaround doesn't work for JavaFX projects.In JavaFX projects you > cannot choose JDK 1.8 as a platform, because NetBeans assumes the JDK > doesn't support JavaFX when running on JDK 7. > > Also support for JDK 8 is one of the release themes for 7.4. > > So both reasons in comment #2 are invalid. Of course the workaround works for JavaFX apps. Above I assumed you were using new-style Maven projects. In old-style Ant projects the settings are located under "Sources: Source/Binary Format" and "Libraries: Java Platform". Also, NetBeans of course does support JavaFX projects with JDK 7. NetBeans 7.4 supports *developing* JDK 8 code; it obviously cannot support running with an unreleased, buggy JDK that's subject to change at any time. Additionally, the "Paste from History" workaround mentioned in comment #7 doesn't work for you? Finally, you really shouldn't change the priority back if a Netbeans guy sets it--that just appears rude. If you don't agree, tell him so in a comment and give good reasons. I do that all the time.
(In reply to athompson from comment #17) > (In reply to maxnitribitt from comment #16) > > The workaround doesn't work for JavaFX projects.In JavaFX projects you > > cannot choose JDK 1.8 as a platform, because NetBeans assumes the JDK > > doesn't support JavaFX when running on JDK 7. > > > > Also support for JDK 8 is one of the release themes for 7.4. > > > > So both reasons in comment #2 are invalid. > > Of course the workaround works for JavaFX apps. Above I assumed you were > using new-style Maven projects. In old-style Ant projects the settings are > located under "Sources: Source/Binary Format" and "Libraries: Java > Platform". Also, NetBeans of course does support JavaFX projects with JDK 7. I'm using an old style Ant project, and the workaround doesn't work for me. Even though JDK 1.8 is still available under Tools -> Java Platforms, it is not in the list of Java Platforms to choose from in the project (Properties -> Libraries -> Java Platforms). I also tried to add JDK 1.8 a second time under Tools -> Java Platforms. It was not recognized as a platform that supports JavaFX. When I tried to fix the dependency via "resolve problems" it led to another exception documented here: http://statistics.netbeans.org/analytics/exception.do?id=691620 . To me this problem (the one related to the workaround) clearly looks like a bug on NetBeans side, and not on the side of the JDK, since NetBEans is running under the officially supported version JDK 1.7_u40. > > NetBeans 7.4 supports *developing* JDK 8 code; it obviously cannot support > running with an unreleased, buggy JDK that's subject to change at any time. For me NetBeans does not support developing JDK 8 code as described above. I can't use it, and I have to switch to a different IDE for one of my JavaONE presentations. I really would like to avoid that, especially since I'm a member of the NB Dream Team and this is going to be embarassing for me and for the IDE. > > Additionally, the "Paste from History" workaround mentioned in comment #7 > doesn't work for you? I was referring to the workaround in comment #15. "Paste from history" works, but I wouldn't want to show this in a presentation. > > Finally, you really shouldn't change the priority back if a Netbeans guy > sets it--that just appears rude. If you don't agree, tell him so in a > comment and give good reasons. I do that all the time. I changed it back to p1 to indicate that in my opinion both reasons for setting it to p2 were wrong and I gave my explanation. It was not my intention to annoy anyone or to be rude. If my comment and switching the priority were perceived like that, then I'd likr to apologize.
Created attachment 140098 [details] JDK 8 in a JavaFX project As you can see from the screenshot, JDK 8 works fine. If when you try to add it in Tools|Java Platforms it doesn't show JavaFX support then I'd guess something is wrong with your JDK 8 installation. Can you email me relevant screenshots? Try downloading the latest build of the JDK from Oracle's website and reinstalling. Also verify that you used the proper path when adding JDK 8 (see my example above). Make sure you're not accidentally trying to use Apple's JDK 6, which is the one I'm aware of that doesn't support JavaFX. If that doesn't work, try downloading the latest daily build of NetBeans. If all else fails, try deleting/moving your NetBeans cache and settings and starting from scratch. They are located here: cache: /Users/<username>/Library/Caches/NetBeans settings: /Users/<username>/Library/Application Support/NetBeans
*** Bug 230876 has been marked as a duplicate of this bug. ***
I can reproduce in Product Version: NetBeans IDE 7.4 RC1 (Build 201309092300) Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b49 Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b107 System: Mac OS X version 10.8.4 running on x86_64; UTF-8; en_US (nb) User directory: /Users/tomas/Library/Application Support/NetBeans/7.4rc1 Cache directory: /Users/tomas/Library/Caches/NetBeans/7.4rc1 just by creating simple java app, copy & paste does not work in editor.
Created attachment 140206 [details] screenshot-1
Created attachment 140207 [details] screenshot-2
I've uploaded the screenshots for my project. attachment 140206 [details] showing the projects properties with(out) the missing jdk 8 and attachment 140207 [details] where you can see it's available in the Tools- Java Platforms (In reply to athompson from comment #19) > Created attachment 140098 [details] > JDK 8 in a JavaFX project > > As you can see from the screenshot, JDK 8 works fine. If when you try to add > it in Tools|Java Platforms it doesn't show JavaFX support then I'd guess > something is wrong with your JDK 8 installation. Can you email me relevant > screenshots? Try downloading the latest build of the JDK from Oracle's > website and reinstalling. Also verify that you used the proper path when > adding JDK 8 (see my example above). Make sure you're not accidentally > trying to use Apple's JDK 6, which is the one I'm aware of that doesn't > support JavaFX. If that doesn't work, try downloading the latest daily build > of NetBeans. If all else fails, try deleting/moving your NetBeans cache and > settings and starting from scratch. They are located here: > > cache: /Users/<username>/Library/Caches/NetBeans > settings: /Users/<username>/Library/Application Support/NetBeans
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024987
As you can see in previous comment, JDK bug was filed. Unfortunately I don't see any simple hot-fix on Netbeans side so we have to wait for a feedback from JDK team -> WONTFIX
(In reply to Antonin Nebuzelsky from comment #25) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024987 This bug is not visible to me. "This bug is not available." Perhaps some Oracle person could make it so?
(In reply to Jan Peska from comment #26) > As you can see in previous comment, JDK bug was filed. Unfortunately I don't > see any simple hot-fix on Netbeans side so we have to wait for a feedback > from JDK team -> WONTFIX Thanks for the evealuation and reporting the JDK-bug! Let's hope it gets fixed soon.
(In reply to maxnitribitt from comment #24) > I've uploaded the screenshots for my project. attachment 140206 [details] > showing the projects properties with(out) the missing jdk 8 and attachment > 140207 [details] where you can see it's available in the Tools- Java > Platforms Looking at those screenshots, I'd try removing everything from under Java Platforms and just adding JDK 1.7 and 1.8. You'll need to get the latest JDK versions for both from Sun's website. A few notes: - JDK 1.7_u40 has been released, so get the final version and you don't need the previous version anymore - since both JDK 1.7 and 1.8 have JavaFX built in, you don't need that separate JavaFX platform AFAIK - it looks like NetBeans is still running with JDK 1.8 and not 1.7; make sure the "netbeans.conf" file is modified as mentioned above - ensure you're running with at Netbeans 7.4 beta, or a later development build
(In reply to athompson from comment #29) > - since both JDK 1.7 and 1.8 have JavaFX built in, you don't need that > separate > JavaFX platform AFAIK Java 7u40 is no different than previous Java 7 releases in that JavaFX is still not on the classpath. NB 7.4 makes the same incorrect assumption that JavaFX in 7u40 is like JavaFX in Java 8 and that makes it impossible to work with JavaFX on NB 7.4 with 7u40.
(In reply to swpalmer from comment #30) > Java 7u40 is no different than previous Java 7 releases in that JavaFX is > still not on the classpath. NB 7.4 makes the same incorrect assumption that > JavaFX in 7u40 is like JavaFX in Java 8 and that makes it impossible to work > with JavaFX on NB 7.4 with 7u40. Not true! Starting with Java SE 7 Update 10, JavaFX SDK is cobundled with the JDK for Windows, Mac OS X, and Linux x86/x64.
(In reply to athompson from comment #31) > (In reply to swpalmer from comment #30) > > Java 7u40 is no different than previous Java 7 releases in that JavaFX is > > still not on the classpath. NB 7.4 makes the same incorrect assumption that > > JavaFX in 7u40 is like JavaFX in Java 8 and that makes it impossible to work > > with JavaFX on NB 7.4 with 7u40. > > Not true! Starting with Java SE 7 Update 10, JavaFX SDK is cobundled with > the JDK for Windows, Mac OS X, and Linux x86/x64. It is bundled but it is *not* on the classpath and must be added manually. That was the entire point of having the NB extra step to configure a JavaFX platform. It is still not on the classpath in 7u40. It will be on the classpath by default only with java 8 and beyond.
> It is bundled but it is *not* on the classpath and must be added manually. > That was the entire point of having the NB extra step to configure a JavaFX > platform. > > It is still not on the classpath in 7u40. It will be on the classpath by > default only with java 8 and beyond. You sound quite sure of yourself, but perhaps you should actually try it...
(In reply to athompson from comment #33) > > It is bundled but it is *not* on the classpath and must be added manually. > > That was the entire point of having the NB extra step to configure a JavaFX > > platform. > > > > It is still not on the classpath in 7u40. It will be on the classpath by > > default only with java 8 and beyond. > > You sound quite sure of yourself, but perhaps you should actually try it... I have. I'm right.
(In reply to athompson from comment #33) > > It is bundled but it is *not* on the classpath and must be added manually. > > That was the entire point of having the NB extra step to configure a JavaFX > > platform. > > > > It is still not on the classpath in 7u40. It will be on the classpath by > > default only with java 8 and beyond. > > You sound quite sure of yourself, but perhaps you should actually try it... C:\dev\fxtest>"c:\Program Files (x86)\Java\jdk1.7.0_40\bin\javac.exe" Main.java main.java:1: error: package javafx.application does not exist import javafx.application.Platform; ^ main.java:5: error: cannot find symbol System.out.println("JavaFX Platform thread? "+Platform.isFxApplicationThread()); ^ symbol: variable Platform location: class Main 2 errors C:\dev\fxtest>"c:\Program Files (x86)\Java\jdk1.8.0\bin\javac.exe" Main.java C:\dev\fxtest>
Dude, that is not how NetBeans, Ant, Maven, or any build system works. That command would fail for any class with any dependency. I don't have time to go into the fundamentals of building a project, but to compile on the command line just go into the project folder and type "ant". You will need to first install ant if you don't already have it.
(In reply to athompson from comment #36) > Dude, that is not how NetBeans, Ant, Maven, or any build system works. That > command would fail for any class with any dependency. I don't have time to > go into the fundamentals of building a project, but to compile on the > command line just go into the project folder and type "ant". You will need > to first install ant if you don't already have it. DUDE, that was simply proof that JavaFX is not on the classpath by default in Java 7u40 and that it is on the classpath by default in Java 8. (As shown, the command did NOT fail on Java 8. You are wrong again.) Go look again at comment #30 You need the JavaFX platform because that is how NB provides JavaFX support. Creating the JavaFX Platform is how NB knows to put JavaFX classes on the classpath - it is not treated as a "normal" library, precisely because it is co-bundled with the JDK/JRE and typically uses the javafxpackager instead of the usual tools for deployment.
*** Bug 235724 has been marked as a duplicate of this bug. ***
DUDE, now you're simply pretending that running javac directly was what you were talking about all along to avoid admitting you were mistaken. The problem is (a) that clearly wasn't what you were talking about and (b) even if it were, you're still incorrect. It's obvious that directly running javac wasn't what you were talking about because Max and I were discussing getting JavaFX projects to work in *NetBeans*. Specifically, I was saying that one didn't need to specify a separate JavaFX platform in addition to the JDK. You clearly knew this because you explicitly quoted it in your response. This is what you wrote in comment #30: "Java 7u40 is no different than previous Java 7 releases in that JavaFX is still not on the classpath. NB 7.4 makes the same incorrect assumption that JavaFX in 7u40 is like JavaFX in Java 8 and that makes it impossible to work with JavaFX on NB 7.4 with 7u40." You were clearly talking about NetBeans as well, and *not* talking about directly running javac from the command line. If that were the case, what java platforms were specified in NetBeans would be completely irrelevant and your comment would have been completely irrelevant to what was being discussed. You were clearly wrong in your assertion that "NB 7.4 makes the same incorrect assumption that JavaFX in 7u40 is like JavaFX in Java 8 and that makes it impossible to work with JavaFX on NB 7.4 with 7u40.". This is easily refuted by actually trying it--something you should have done before putting your foot in your mouth. Now this is the part where you claim that you've already proven your point and continuing to argue is pointless--so predictable. Grow up, stop pretending you are infallible, admit your mistakes, and move on.
In Comment 33 I misunderstood what you were talking about. I wrote, "It is still not on the classpath in 7u40. It will be on the classpath by default only with java 8 and beyond.", and you replied right beneath with, "You sound quite sure of yourself, but perhaps you should actually try it..." and yes I was sure of that, proved it to you etc.. but you were still referring to the part above that where I wrote, "...having the NB extra step to configure a JavaFX platform." You are correct, the need for the "JavaFX Platform" was removed at some point during the development of 7.4. Listen, I did try it with NB 7.4 as well. At the time it failed, exactly in the manner I was describing. The concept of creating a "JavaFX Platform" was still in 7.4 then and it failed to build existing JavaFX projects from 7.3.1. (Issue 230521 was probably not as far along at the time.) My mistake was not trying *again*, and I will fully admit that. Your comment got me off on a tangent by mentioning the co-bundling of JavaFX with JDK 7 and 8 as if it was the reason that you didn't need this. Up to a point you *did* need that JavaFX Platform even with the co-bundled JavaFX, *just as you still do for NB 7.3.1.* NB 7.4 had the problem I described and it got fixed, great. Sorry for the misunderstanding. Let's move on.
I think JDK 8-ea-b108 has solved the problem.
My experience is that the problem is NOT resolved with at least the following config: Product Version: NetBeans IDE 7.4 Beta (Build 201307092200) Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b50 Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b108 System: Mac OS X version 10.8.5 running on x86_64; UTF-8; en_US (nb) User directory: /Users/kec/Library/Application Support/NetBeans/7.4beta Cache directory: /Users/kec/Library/Caches/NetBeans/7.4beta
I didn't intend my comment to have any effect on the status... Seems bit odd that a comment would require selecting status, etc.
As you can the JDK bug is still opened so there is no reason to reopen the bug.
I am also encountering this problem with the JDK 8 developers preview with NB 7.4 RC 1. If I try the same thing using NB 7.3.1 against the same file, I do not have the problem. I cannot even copy and paste within the same file with NB 7.4 RC1, yet I can take what I copied and put it into a terminal window I am running OSX 10.8.5 fwiw. Definitely a troublesome issue
Yes, I was a bit quick with my reaction. The bug is still there, for some reason the copy/paste works when using "split window".
Tried with Sep 30 nightly and 1.8.0-ea-b108 and still facing the problem. This is basically making NetBeans unusable, yuck!
*** Bug 236891 has been marked as a duplicate of this bug. ***
Netbeans DEV build from about week ago through 11/2 OSX 10.8.5 MacBook Pro Retina JavaSE 8b113 I know this is for 7.4 but the dev build within the last week or so now does something slightly different. Copy and Paste WITHIN the IDE now works but copy throws an exception (abbreviated below). Also both copy from Netbeans to outside Netbeans and vice versa no longer work. Here's the bug for the exception but it's marked closed and fixed in 110. It hasn't been my experience that it was fixed in 110-113... this is still an issue. https://bugs.openjdk.java.net/browse/JDK-8026262 java.lang.NullPointerException at java.awt.datatransfer.SystemFlavorMap.getAllNativesForType(SystemFlavorMap.java:1327) at java.awt.datatransfer.SystemFlavorMap.getNativesForFlavor(SystemFlavorMap.java:702) ... Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to at org.openide.util.RequestProcessor.post(RequestProcessor.java:435) at org.netbeans.NbClipboard.scheduleSetContents(NbClipboard.java:285)
(In reply to anewhope from comment #49) > JavaSE 8b113 > > Here's the bug for the exception but it's marked closed and fixed in 110. That bug is marked as introduced in b110. It is fixed in "team" repository only so far.
*** Bug 238016 has been marked as a duplicate of this bug. ***
This appears to be fixed in 8b115. I've tested a little bit and so far so good. I can copy and paste inside and outside of Netbeans without error. I'm using yesterday's dev build but it should also apply to the released version. 2f7f6995fa64 8026262 NPE in SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of #JDK-8024987
JDK8 b115 with the fixes is publicly available now. https://jdk8.java.net/download.html All reporters, please test with b115 and report back. Thanks.