Community
Participate
Working Groups
200405190010 In the configuration below, 'Go to Next Annotation' doesn't find the error after jumping to the warning. 'Go to Previous Annotation' however correctly cycles through both Markers. - set 'Prefs > Java > Compiler > Style > Undocumented empty block' to Warning - check 'Errors' and 'Warnings' in 'Go to Next Annotation' toolbar button menu - Ctrl+. -> correctly jumps to "Empty block should be documented" (local class) - Ctrl+. -> expected: jumps to "Type mismatch: ..." -> was: stays on first annotation. public class Klazz { public Runnable getHoverUpdater() { class Lokal { } return new Object(); } }
not critical for 3.0 M9 should fix for 3.0 since it blocks to go to other annotations.
The endPosition (85) of the problem reported by J Core is off by one (too long) - it points to '\r'. This causes the real selection to be smaller than the annotation and hence we can no longer navigate.
Olivier - pls investigate and let me know.
I am investigating.
The error is reported using bodyEnd + 1 for the end position. I believe that removing this + 1 should be good enough. I will check if bodyEnd includes the closing '}' or not. If not, then the right fix is to scan for the '}' starting at bodyEnd position and then removing one to the resulting position.
Sounds good. The only real problem for us is if it contains partial line delimiter
Understood. To clarify, the end position we want includes the '}', but it should not go further. The following '\r' should clearly not be included.
For a type declaration, bodyEnd is the position we want. But for a method declaration, we want bodyEnd + 1. Ideally we want to scan the position of the '}' in order to handle unicodes properly.
Changing the end position to bodyEnd in the type declaration case instead of bodyEnd + 1 fixes it. It also works with unicode. The problem with unicode remains in case of a '}' written as unicode for the method declaration. The only way to fix it would be to scan the source again. Not sure this is necessary. Reporting a position inside a unicore character should not be a problem.
Fixed and released in HEAD. NegativeTest>test392 is updated to reflect the changes.
Verified in 200405281200
