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

Bug 354579

Summary:

Fup of bug 289247: Investigate validity of the fix vis-a-vis JLS.

Product:

[Eclipse Project] JDT

Reporter:

Ayushman Jain <amj87.iitr>

Component:

Core

Assignee:

Ayushman Jain <amj87.iitr>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

jarthana, Olivier_Thomann, satyam.kandula, srikanth_sankaran

Version:

3.7

Flags:

srikanth_sankaran: review+

Target Milestone:

3.7.1

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
proposed fix v0.5 + updated tests	none
proposed fix v1.0 + updated tests	none
Revised patch under test	none
Proposed patch - Passes all tests.	none

Description Ayushman Jain

2011-08-12 02:58:21 EDT

HEAD

After the fix for bug 317719, ECJ in compliance 1.6 compiles both of these

 interface J {  
  <T extends Number> T foo(final Number p); 
  Float foo(final Number p);
}

--------------------------------------------------
class X {
     <N extends B> N a(A<Number> s) { return null; }
     <N> Object a(A<Number> n) { return null; }
}
class A<T> {}
class B {}
--------------------------------------------------

However, the first one does NOT compile with javac6. 

bug 317719 comment 48 documents my findings that we may have sidestepped JLS 8.4.2 after the fix for bug 289247. This may be one reason why ECJ in 1.6 compliance is more liberal than javac6

Comment 1 Ayushman Jain

2011-08-12 03:00:10 EDT

Srikanth, the patch in bug 317719 comment 50 is a step towards rectifying this. You can see how valid that is.

Comment 2 Ayushman Jain

2011-08-16 07:39:10 EDT

Created attachment 201561 [details]
proposed fix v0.5 + updated tests

The LS 8.4.2 says that The signature of a method m1 is a subsignature of the signature of a method m2 if either:
• m2 has the same signature as m1, or
• the signature of m1 is the same as the erasure of the signature of m2.

It seems that the logic for point 2 is the only thing which currently distinguishes ECJ compliance 1.6 behaviour with javac6. 

This patch adds that logic, special cased for 1.6 compliance. This is on the lines of the logic we also had before fix for bug 289247 deleted it.

Comment 3 Ayushman Jain

2011-08-16 09:38:22 EDT

Created attachment 201564 [details]
proposed fix v1.0 + updated tests

This patch adds some more logic that was removed after the fix for bug 289247. So, now we're more closely compatible with javac6 and many cases where we were being more liberal than javac6 due to the fix for bug 317719 now agree with javac6.

Cases such as these also complain now:

int foo() {return 1;}
float foo() {return 1.0;}

Comment 4 Srikanth Sankaran

2011-08-16 11:46:34 EDT

Created attachment 201587 [details]
Revised patch under test

Same patch with minor clean ups.

Comment 5 Srikanth Sankaran

2011-08-16 20:30:25 EDT

Created attachment 201611 [details]
Proposed patch - Passes all tests.

Comment 6 Srikanth Sankaran

2011-08-18 04:51:22 EDT

I think this patch correctly restores the fragment of the code
deleted by bug 289247 and in combination with the fix for 
bug 317719, effectively restores the behavior at compliance level
1.6 to how it stood before the combination of fixes for the bug 289247
and bug 273862. Thanks Ayush. 

+1 for the patch. Please release for HEAD and 3.7.1.

Comment 7 Ayushman Jain

2011-08-18 06:32:34 EDT

Thanks Srikanth.

Released in HEAD for 3.8M2 and in R3_7_maintenance for 3.7.1

Comment 8 Satyam Kandula

2011-08-25 10:14:27 EDT

Verified for 3.7.1 RC2 using build M20110824-0800

Comment 9 Jay Arthanareeswaran

2011-09-14 06:21:58 EDT

Verified for 3.8M2 with build I20110912-2126.