Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1. Add comment (javadoc) any method 2. Change this method (IMethod) using ISourceRange 3. Javadoc is deleted :/ More information: I'm using this code (see below) to change a method in a class. It works perfectly. But if before the method I put any comment (javadoc) it is deleted :/ ------------ IBuffer buffer = imethod.getOpenable().getBuffer(); ISourceRange sourceRange = imethod.getSourceRange(); StringBuffer sourceMethod = new StringBuffer(); //sourceMethod = new method source buffer.replace(sourceRange.getOffset(), sourceRange.getLength(), sourceMethod.toString()); imethod.getOpenable().save(null, true); ------------ In debug IMethod source does not have the javadoc comment (correct), but at the time of saving it's deleted and certainly would change only the source of the method, not the comment.
The javadoc comment is a part of the IMember when the element was got from source (see IMember#getJavadocRange()). So, if you replace the entire method source, then you have to include the new javadoc comment in it. If you do not want to change it then get it from the existing method first and add it at the beginning of the new source method before. So, close as INVALID.
hmmmm, ok. Sorry for the issue. I didn't know if it was a bug or if works differently. I asked in 2 places and nobody answered. Then I had to open an issue to make sure that it was not a bug :) http://www.eclipse.org/newsportal/article.php?id=22009&group=eclipse.tools.jdt#22009 http://www.eclipsezone.com/eclipse/forums/t105082.html Thanks a lot!
Beyond the fact that the documentation of IMember#getJavadocRange could certainly bear some polishing (since it returns a range, why would we extract a javadoc from attached sources?), I don't quite see where it explains the relationships of the javadoc range to the source range (which according to comment #1 should, at least it case of source files, be an inclusion of the former into the latter). Hence if the behavior is the intended one, I would suggest that it be made more immediately understandable from the API.
Discussed with Frédéric and Jérôme and we agreed to open a fup bug to take care of documentation improvements. The behavior described in this bug is the expected one, hence: Verified for 3.4M5 using I20080204-0010 build.
hmmmm... good :)
(In reply to comment #4) > Discussed with Frédéric and Jérôme and we agreed to open a fup bug to take care > of documentation improvements. This is bug 217837.
