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.
Build: NetBeans IDE 6.8 Beta (Build 200910212001) VM: Java HotSpot(TM) 64-Bit Server VM, 14.3-b01, Java(TM) SE Runtime Environment, 1.6.0_17-b04 OS: Windows 7, 6.1, amd64 User Comments: GUEST: Sometimes Netbeans occur any errors while I am coding. For example error which I have been see that is error "Null Point Exeption". This error occur when I am designing GUI or when I add plugin. When that I usually restart or ignore if it's not bring about bad effects for my work. GUEST: doubleclicking on another class to edit it Maximum slowness yet reported was 6709 ms, average is 4852
Created attachment 91742 [details] nps snapshot
Created attachment 93156 [details] nps snapshot
Created attachment 93157 [details] nps snapshot
Created attachment 93159 [details] nps snapshot
*** Bug 186505 has been marked as a duplicate of this bug. ***
This is what happens on slow shares: java.io.WinNTFileSystem.canonicalize0(Native Method) java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:396) java.io.File.getCanonicalPath(File.java:559) java.io.File.getCanonicalFile(File.java:583) org.openide.filesystems.FileUtil.normalizeFileOnWindows(FileUtil.java:1656) org.openide.filesystems.FileUtil.normalizeFile(FileUtil.java:1563) org.openide.loaders.DataFolder$FolderNode.createNodeTransferable(:1365) org.openide.loaders.DataFolder$FolderNode.createPasteTypes(DataFolder.java:1346)
I can change the FolderNode to be much faster by just using the file f: @@ -1419,7 +1419,8 @@ Transferable createNodeTransferable( File f ) { Transferable result = null; - FileObject fo = FileUtil.toFileObject(FileUtil.normalizeFile(f)); + assert (f = FileUtil.normalizeFile(f)) != null; + FileObject fo = FileUtil.toFileObject(f); if( null != fo ) { try { DataObject dob = DataObject.find( fo ); however that may contradict Jesse's f2e72f53aad9. It will prevent the assert, but it may violate some assumptions about normalized files which I don't understand.
You can't just turn off the call to FileUtil.normalizeFile, or the IAEs will reappear that I fixed in f2e72f53aad9. (If assertions are off, the problem will likely make itself felt somewhere further down the line, as you will have a nonnormal DataObject floating around.) Anyway the whole paste type calculation could perhaps be done lazily. It seems silly to be getting the DataNode for a file which happens to be in the clipboard just in case the user might paste it! The flow of control is rather convoluted so I'm not sure how to fix it - some kind of proxy. updatePasteAction should also perhaps call updatePasteTypes asynch (with OwnPaste.setPasteTypes then rescheduling the setEnabled into EQ). This would make a whole class of EQ-blocking bugs disappear. Of course the work would in this case still be being done in the background whereas it probably does not need to be done at all.
Now, when the call to FileUtil.normalizeFile is cached (due to bug 183308), the problem with too often disk touches, shall also be solved.