Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 443810 - [1.8] Additional <CR> on type annotation of local variable
Summary: [1.8] Additional <CR> on type annotation of local variable
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.4   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 429221
  Show dependency tree
 
Reported: 2014-09-11 07:31 EDT by Noopur Gupta CLA
Modified: 2014-09-11 10:23 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Noopur Gupta CLA 2014-09-11 07:31:44 EDT
@Target(ElementType.TYPE_USE)
@interface TA {
}

class Test {
	private void foo(@TA String s) {
		@TA String s1 = (@TA String) s;
	}
}

Formatting the above code with default formatter profile results in a new line after type annotation on "s1":
class Test {
	private void foo(@TA String s) {
		@TA
		String s1 = (@TA String) s;
	}
}

It happens with the default formatter profile where "Insert new line after annotations on local variables" is checked and does not happen when it is unchecked.
It results in BadLocationException in bug 429221.
See also bug 425040#c13.
Comment 1 Jay Arthanareeswaran CLA 2014-09-11 07:56:10 EDT
Manoj, please take a look it.
Comment 2 Markus Keller CLA 2014-09-11 10:23:55 EDT
As said in bug 425040, this problem is very hard to solve without giving up one of these premises:
1. the Java 8 grammar doesn't allow a syntactic distinction between type annotations and declaration annotations
2. the formatter needs to work without a classpath
3. we support different line breaking options for type annotations and declaration annotations (on various kinds of declarations)

For (3), we need some heuristics to overcome (1), and those choices hurt in the case of bug 429221. We could try to use different heuristics (e.g. assume that ambiguous annotations are type annotations iff they are MarkerAnnotations).

However, I think we should just live with what we have (heuristics from bug 425040 comment 13) and solve bug 429221 in a different way.