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

Bug 330631

Summary:	Inconsistent classfile encountered: The undefined type parameter T is referenced from within String
Product:	[Eclipse Project] JDT	Reporter:	Markus Keller <markus.kell.r>
Component:	UI	Assignee:	Markus Keller <markus.kell.r>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, Olivier_Thomann, srikanth_sankaran
Version:	3.7
Target Milestone:	3.7 M4
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Markus Keller

2010-11-18 19:34:52 EST

The change from bug 330347 is causing test failures in JDT/UI (e.g. in MarkOccurrenceTest).

To reproduce that setup, put
/org.eclipse.jdt.ui.tests/testresources/rtstubs15.jar on the classpath of a
Java project with 1.4 compiler compliance, and then try to compile

package p;
public class A {
	String s;
}

=> Error: Inconsistent classfile encountered: The undefined type parameter T is referenced from within String

I don't say that our test project setup is flawless, but this worked fine up to v_B24.

Comment 1 Srikanth Sankaran

2010-11-18 19:38:32 EST

Will take a look.

Comment 2 Olivier Thomann

2010-11-18 19:52:22 EST

This doesn't happen if I compile the code using a 1.5 rt.jar and compliance 1.4.
I wonder if the problem doesn't come from the stub jar itself.

Comment 3 Olivier Thomann

2010-11-18 19:55:06 EST

The problem occurs while reading the method info for:
public bridge compareTo(TT;)I

Comment 4 Olivier Thomann

2010-11-18 19:58:49 EST

I don't understand why the bridge method has a generic signature:
The one from the stub:

  // Method descriptor #113 (Ljava/lang/Object;)I
  // Signature: (TT;)I
  // Stack: 2, Locals: 2
  public bridge synthetic int compareTo(Object arg0);
    0  aload_0 [this]
    1  aload_1 [arg0]
    2  checkcast String [2]
    5  invokevirtual String.compareTo(String) : int [117]
    8  ireturn

The one from a real 1.5 rt.jar:
  // Method descriptor #207 (Ljava/lang/Object;)I
  // Stack: 2, Locals: 2
  public bridge synthetic int compareTo(Object arg0);
    0  aload_0 [this]
    1  aload_1 [arg0]
    2  checkcast String [188]
    5  invokevirtual String.compareTo(String) : int [379]
    8  ireturn
      Line numbers:
        [pc: 0, line: 90]

Markus, how was the 1.5 stub jar created ?

Comment 5 Olivier Thomann

2010-11-18 20:35:08 EST

Note that the rtstubs16.jar doesn't have the same problem for the java.lang.String class.
The bridge method looks ok:
  // Method descriptor #118 (Ljava/lang/Object;)I
  // Stack: 2, Locals: 2
  public bridge synthetic int compareTo(Object arg0);
    0  aload_0 [this]
    1  aload_1 [arg0]
    2  checkcast String [1]
    5  invokevirtual String.compareTo(String) : int [119]
    8  ireturn

Comment 6 Srikanth Sankaran

2010-11-18 21:19:42 EST

(In reply to comment #4)
> I don't understand why the bridge method has a generic signature:

...

> Markus, how was the 1.5 stub jar created ?

...

Just a wild guess: It was generated by a pre bug# 101794 compiler ? 

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=101794#c5 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=101794#c13

Comment 7 Srikanth Sankaran

2010-11-18 21:47:15 EST

We believe it is an issue with the stubs library.
If it is regenerated with a recent compiler the
problem should go away.

Please reopen in the unlikely event this proves to
be a real compiler issue.

Comment 8 Markus Keller

2010-11-19 07:08:51 EST

> > Markus, how was the 1.5 stub jar created ?
> Just a wild guess: It was generated by a pre bug# 101794 compiler ? 

Indeed, that's it. I've re-generated the rtstubs15.jar, and now it works fine.
Fixed in HEAD, moving the bug to JDT/UI (where the fix was applied).

Thanks for your investigations.