Community
Participate
Working Groups
I dont know if this is a defect or an intentional feature, but if you have a method with two javadoc comment blocks on top of it, IMethod gives the offset/length including both the comment blocks, whereas AST (MethodDeclaration) takes only the lowest comment block into consideration. An example could be: public class SomeClass{ /** * Comment block 1 */ /** * Comment block 2 */ public void foo(){ } } Is it possible to get a consistent source range from both AST and JDT?
We have been aware of this issue for a long time, but haven't been able to change it so as not to break existing clients who did make assumptions on these. The DOM AST source range should include all leading comments... Jim: could we address this somehow in the new API ? We could say that when using the 3.0 level AST, these positions are now correctly reflecting what they should have been since day one ?
When you have one watch, you can tell what the time is. When you have two watches, you will never be sure ;-)
The new methods Frederic added, CompilationUnit.getExtendedStartPosition (ASTNode) and getExtendedLength(ASTNode), should include all leading (and trailing) comments.
Frederic - pls verify it now works.
I've verified with build I20040407 that CompilationUnit.getExtendedStartPosition (ASTNode) and getExtendedLength(ASTNode) work correctly for provided example => both javadoc comments are including in leading comments :)
Reopen as there are differences. In following example: public class SomeClass{ /** * Comment block 1 */ /** * Comment block 2 */ public void foo(){ } } which looks really similar than initial one, JDT put both comments as leading ones and AST extended range put only second one. They are many other examples which can show different leading/trailing comments... We agree that JDT and AST should behave the same way. I will think about a common behavior and propose it in next comment...
Created attachment 9496 [details] New heuristic proposal This document explain existing JDT and AST currently implemented heuristics and propose a new common one. It also provide examples to try to show old and new expected behaviors. Feedbacks will be greatly appreciated, thx
I've written attached document using word and save it under HTML format. I've verified that I can read it using IE6.1 but I know that HTML generated by Microsoft is often non-standard. So let me know if you get some troubles to read it...
AST heuristic came from JDT-UI who definitely wants it unchanged. Initial reason for this behavior is that detached comments are often not really meaningful for following node. Here's a simple example which shows that: public class Test { //***** Start of methods ***** /* Method foo */ public void foo(){ } // End of foo /* Method bar */ public void bar(){} // End of bar //***** End of methods ***** } In this case '//***** Start of methods' comment is obviously not really attached to foo method declaration. That's why "condition 4" was added to heuristic to stop comments search when an empty line was encountered. However, we also definitely need to have similar extended source range for both Java and AST models... So, if AST heuristic cannot be changed for the while (also due to big impacts on JDT-UI code and tests), the only solution we have is to modify JDT heuristic to behaves like AST one. Also note that problem I mentionned in document about AST heuristic comes from personal and user feedback (bug 46171). As this behavior may be natural for other users (like JDT-UI ones), we'll keep bug 46171 as enhancement to provide user interface to modify this heuristic (surely not targeted for 3.0)...
Fine actually. Although impressed the "New heuristic proposal" I did not agree with it: (1) For the reason examplified in comment #8. (2) Because I believe that the focus on relating as many comments as posssible (in the proposal actual ALL comments) to one node or another is counterproductive from the JDT user's point of view. At all times, even when using refactoring commands or drag&droping program elements, when I edit my code, I naturally want to know exactly what happens with it. Complicated heuristics with tricky corner cases will simply not do. Robustness is the issue, and, as always, doing as little as possible the key. Therefore I believe in a default heuristic much simpler than todays with an added possiblity for the individual user to introduce additional rules to support a specific programming (code formating) style. Just my 0.02.
Too risky for now. Defer. Will reconsider post 3.0
*** Bug 47337 has been marked as a duplicate of this bug. ***
We finally agreed with jdt-ui that bug 47337 was not a duplicate. That bug has been fixed separately and put in 3.0 RC1...
Reopen as LATER is deprecated...
*** Bug 56532 has been marked as a duplicate of this bug. ***
*** Bug 349959 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
