Bug 539105 - Signature of anonymous class with parameterized outer
Summary: Signature of anonymous class with parameterized outer
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.9   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug bulk move
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-15 17:08 EDT by Stephan Herrmann CLA
Modified: 2022-05-27 15:39 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 Stephan Herrmann CLA 2018-09-15 17:08:04 EDT
See https://bugs.openjdk.java.net/browse/JDK-8203436

When compiled with javac 10, the compile Outer$1.class contained:

Signature: #15                          // LOuter<T<captured wildcard>;>.Inner;

When compiled with javac 11, this error is raised:

error: error while generating class <anonymous Outer$1>
  (illegal signature attribute for type CAP#1)
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object from capture of ?


By contrast, ecj happily generates:

Signature: #19                          // LOuter<Ljava/lang/Object;>.Inner;

This doen't pose the problem addressed by JDK-8203436, but what's correct: capture or erasure? If the former, then ecj, too, should start failing early when illegal signatures would result.
Comment 1 Stephan Herrmann CLA 2018-11-27 13:50:29 EST
JLS ยง4.5.2 probably comes closest to answering the above question. It seems moraly OK to follow javac and use capture in the compiler. When going from JLS to JVMS I see no mentioning of any conversions, so the Signature would indeed have to encode a capture -> bail out.

Does this mean a captured outer for an inner instantiation is always illegal?
Comment 2 Manoj N Palat CLA 2019-02-11 04:10:48 EST
Bulk move out of 4.11
Comment 3 Manoj N Palat CLA 2019-08-27 02:06:00 EDT
Bulk move out of 4.13
Comment 4 Holger Voormann CLA 2019-10-10 08:36:33 EDT
Is the following the same or should I open a new bug for that?

class Outer<T> {
    class Inner {}
    java.util.List<Outer<T>.Inner> l1 = null;
    java.util.List<Outer<?>.Inner> l2 = l1; // compiler error not shown by Eclipse
    java.util.List<? extends Outer<?>.Inner> l3 = l1;
}

See also https://stackoverflow.com/q/58270647
Comment 5 Stephan Herrmann CLA 2019-10-13 10:24:23 EDT
I don't see a close connection. Moreover on stackoverflow I had discussed why I didn't agree with the answer. I don't know why all my comments have disappeared :(
Comment 6 Stephan Herrmann CLA 2019-10-24 14:19:52 EDT
(In reply to Holger Voormann from comment #4)

Thanks for reporting. While debugging one of the variants I found where exactly ecj is inconsistent. Over to bug 552388.
Comment 7 Eclipse Genie CLA 2022-05-27 15:39:57 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.