Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365531

Summary:	[compiler][null] investigate alternative strategy for internally encoding nullness defaults
Product:	[Eclipse Project] JDT	Reporter:	Stephan Herrmann <stephan.herrmann>
Component:	Core	Assignee:	Stephan Herrmann <stephan.herrmann>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	amj87.iitr, daniel_megert, srikanth_sankaran
Version:	3.8
Target Milestone:	3.8 M6
Hardware:	Other
OS:	Linux
Whiteboard:

Description Stephan Herrmann

2011-12-04 15:11:32 EST

Bug 186342 comment 179 contains an experiment in avoiding type bindings
for encoding nullness defaults, but using a bit-based strategy.
Post 3.8 M4 we should investigate if this could yield better code
(ITO structure, memory footprint).

Comment 1 Stephan Herrmann

2012-01-19 16:02:42 EST

Awaiting an agreement in bug 366063 for which this could help internally.

Comment 2 Srikanth Sankaran

2012-01-31 04:03:03 EST

Does this become a NOP if we stop emitting synthetic annotations as per
my understanding of where https://bugs.eclipse.org/bugs/show_bug.cgi?id=366063
is headed ?

Comment 3 Stephan Herrmann

2012-01-31 04:44:30 EST

(In reply to comment #2)
> Does this become a NOP if we stop emitting synthetic annotations as per
> my understanding of where https://bugs.eclipse.org/bugs/show_bug.cgi?id=366063
> is headed ?

No, technically both bugs converge to one big refactoring, were both sides support each other.

In the current implementation, just stopping to emit synth annotations would render any nullness defaults effectless.

Comment 4 Stephan Herrmann

2012-02-14 13:48:30 EST

Resolved for 3.8 M6 via commit 4817a4bde9db799e7a793068d64037f59bfa521f

Along with the purely internal change of representations this patch establishes the following behavioral changes:
- Previously when seeing @NonNullByDefault we looked up the binding for the configured nonnull annotation, and if that could not be found we flagged:
    Buildpath problem: the type in.valid, which is configured as a null annotation type, cannot be resolved
  This lookup is no longer necessary and hence the error is no longer reported (which obsoletes half of the tests in NullAnnotationModelTests)
- We no longer generate those synthetic annotations into the byte code (see also bug 366063), which means the global default no longer works for binary class files.

More to follow in bug 366063

Can anyone recommend how I should document the removal of an IProblem that was introduced in 3.8 M4? Edit the previous entry in the build notes? Add a new entry? Any other doc location to update?

Comment 5 Stephan Herrmann

2012-02-23 05:31:28 EST

*** Bug 371359 has been marked as a duplicate of this bug. ***

Comment 6 Srikanth Sankaran

2012-03-12 05:47:04 EDT

Verified for 3.8 M6 using Build id: I20120306-0800