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.
NetBeans IDE Dev (Build 061101) 1.6.0-rc; Java HotSpot(TM) Client VM 1.6.0-rc-b100 Windows XP version 5.1 running on x86 en_US (nb); Cp1252 Copy&Pasting class t odifferent package corrupts package statement. Steps to reproduce: 1) have an empty class in org.netbeans.test.java.gui.copypaste.test package 2) create package org.netbeans.test.java.gui.copypaste.test2 3) copy & paste (in the project view) the class to the new package -> /* * TestClass.java * */ pacorg.netbeans.test.java.gui.copypaste.test2.test; /** * */ public class TestClass { /** Creates a new instance of TestClass */ public TestClass() { } }
I'm not able to reproduce it, maybe it is a platform specific for windows. The number of new lines are 5, missing characters are also 5 - "kage ". Seems like there are \r characters which were not used in position computing.
Description how to reproduce steps: i) use source text with cr/lf sequence before the package statement, ii) position for package name is moved - the shift is number of cr chars.
Created attachment 35801 [details] Hack for fixing problem - not applicable!
By the way, this is a more general issue - when reading source SourceFileObject.getCharContentImpl() - all \r characters are filtered out. This means that position are resolved for the source without \r, i.e. offsets are correct when document for file exists. Then, when write operation is used and ModificationResult class takes down the changes to file, positions are incorrect. Bear in mind this is only in cases \r characters are in the file. (All works as expected if document exists, then ModificationResult writes down changes to document instead of file.)
Possible solutions: i) apply "not applicable" hack - for not opened files document will be created. This will have negative impact to performance, that is the reason why it is marked as "not applicable". ii) encapsulate offsets to class - Such a class will provide correct offsets for closed/opened files. This means huge number of changes, direct offset handling has to be forbidden. iii) when document is created for file, notify users that position obtained before are no longer valid. It is breakneck solution, but currently just refactoring are client which uses positions from file which has to be converted to new position. (Consider click to usage in the file which is not opened - file is opened and correct selection has to be done in editor.)
*** Issue 89209 has been marked as a duplicate of this issue. ***
In case we have to fix it in 6.0, I suggest to apply "not applicable" fix. This will have negative performance impact.
FYI, I see this problem constantly - copying a class makes complete hamburger out of the head of the file - all the imports part of the opening comment, the package statement gets characters from the class name mixed into it - you get an uncompilable mess. I was figuring it was probably a CRLF-related problem. Swing Swing documents exclusively use \n as the line terminator, you could avoid creating the Document, but preprocess the document text, e.g. String lt = (String) System.getProperty ("line.separator"); if (lt.length() > 1) { documentContent = documentContent.replace (lt, "\n"); } and if necessary, replace "\n" with lt again before writing out the result. I had to do something like this to do error hints for included XML files in the DocBook module. It's still extra work, but less work than creating a Document for the file.
Yes. This seems to be the best solution. Just one question: Consider sources checked out with \r\n on Windows. File will change and all its \r\n will be converted to \n. When file is check in, is just the 'real' change visible (though no changes in end lines are registered? -- When file is check out again, are there again \r\n?
*** Issue 92132 has been marked as a duplicate of this issue. ***
This is a big issue for windows users. I wish to test the new 6.0 features, but all the copied java class result corrupted, and this makes the IDE impossible to use. please fix it. thanks
We know we have to fix it. But this need some consensus how to do that, we still do not have good solution for it. For the time being, use the hack attached, which can temporarily help.
*** Issue 92775 has been marked as a duplicate of this issue. ***
It's really annoying issue. I don't want to see it fixed somewhere in "future". IMO, there is plenty of time to fix it in 6.0
Of course, it has to be fixed in 6.0. You are a hair-splitter. :-)
*** Issue 90835 has been marked as a duplicate of this issue. ***
*** Issue 96337 has been marked as a duplicate of this issue. ***
*** Issue 99900 has been marked as a duplicate of this issue. ***
*** Issue 99922 has been marked as a duplicate of this issue. ***
Created attachment 40685 [details] Another bad solution
Previously added attachment removes all \r characters from input stream during writing output. It should eliminate problems reported here, unfortunately there will be just \n characters. -- During writing, I can change it back to \r\n. Both things can have negative perf impact, especially the second one. (not implemented yet.)
Our generation for web services also experiences this problem. See attached. Our use case is: 1) create an empty class from a template. 2) generate new methods and annotations to it.
Created attachment 40759 [details] Corrupted Java file for web service created from WSDL
After the discussion with other team members, we finally decided to reparse the source when opened to editor. -- There will be no need to preprocess \r characters when reading files and offset positions will be correct. Hopefully nobody holds the offset positions outside the task.
Checking in src/org/netbeans/api/java/source/JavaSource.java; /cvs/java/source/src/org/netbeans/api/java/source/JavaSource.java,v <-- JavaSource.java new revision: 1.37; previous revision: 1.36 done Checking in src/org/netbeans/modules/java/source/parsing/SourceFileObject.java; /cvs/java/source/src/org/netbeans/modules/java/source/parsing/SourceFileObject.java,v <-- SourceFileObject.java new revision: 1.7; previous revision: 1.6 done Checking in test/unit/src/org/netbeans/api/java/source/JavaSourceTest.java; /cvs/java/source/test/unit/src/org/netbeans/api/java/source/JavaSourceTest.java,v <-- JavaSourceTest.java new revision: 1.9; previous revision: 1.8 done
v.
*** Issue 101932 has been marked as a duplicate of this issue. ***