Bug 365531 - [compiler][null] investigate alternative strategy for internally encoding nullness defaults
Summary: [compiler][null] investigate alternative strategy for internally encoding nul...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.8   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 3.8 M6   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 371359 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-12-04 15:11 EST by Stephan Herrmann CLA
Modified: 2012-03-12 05:47 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 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 CLA 2012-01-19 16:02:42 EST 
Awaiting an agreement in bug 366063 for which this could help internally.
Comment 2 Srikanth Sankaran CLA 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 CLA 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 CLA 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 CLA 2012-02-23 05:31:28 EST 
*** Bug 371359 has been marked as a duplicate of this bug. ***
Comment 6 Srikanth Sankaran CLA 2012-03-12 05:47:04 EDT 
Verified for 3.8 M6 using Build id: I20120306-0800