Bugzilla – Full Text Bug Listing
| Summary: | [compiler][1.8] IncompatibleClassChange error | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Manoj N Palat <manoj.palat> | ||||||
| Component: | Core | Assignee: | Jesper Moller <jesper> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, jarthana, manoj.palat, snorthov, srikanth_sankaran, stephan.herrmann, tom.schindl | ||||||
| Version: | 4.4 | Flags: | srikanth_sankaran:
review+
|
||||||
| Target Milestone: | BETA J8 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Manoj N Palat
Jesper, can you take a look ? TIA, I would suggest this be prioritized above JEP 120 work. Hi Jesper, this is blocking various people from testing early bits. Let me know if you are unable to work on it this in the next 4-5 days - I'll take over in that case. Please see the latest posts in jdt-core-dev for some back ground. (In reply to Srikanth Sankaran from comment #2) > Hi Jesper, this is blocking various people from testing early bits. > Let me know if you are unable to work on it this in the next 4-5 > days - I'll take over in that case. I will be working on this from today, and expect to be done soon. Are we moving to b106 this week - the bug is also against b100, if I'm not mistaken? I've fixed it, will submit a patch as soon as I fix the copyrights. Created attachment 235380 [details]
Patch for the Metafactory change
I didn't use the test source, didn't need to, since this patch fixes the 70+ test failures which have existed since moving to b100 (I think it was, it was during my vacation). Anything with an invokedynamic failed at runtime.
The patch introduces 23 other test failures since the constant pool indixes got shuffled - I will address those in a separate patch, they are just custodial in nature.
Requesting review for the patch. (Still haven't fixed the disassembly-comparison regressions, though) Thanks, I'll review this since I worked with you on lambda code generation and am familiar with the concerned code. Patch looks good, Thanks Jesper. I would change it so as not to call getSingleAbstractMethod from LE and RE and instead use this.descriptor which already caches it. Please release once the tests are fixed. No need to review test changes in this case. As for upgrading, through IBM channels the latest we have access to is 8b104. If all is clean with 8b106, by all means upgrade to that. (In reply to Srikanth Sankaran from comment #8) > As for upgrading, through IBM channels the latest we have access to is > 8b104. If all is clean with 8b106, by all means upgrade to that. Has the bug in the Linux JVM be fixed in one of these? Remember I'm still locked to b92! (In reply to Stephan Herrmann from comment #9) > (In reply to Srikanth Sankaran from comment #8) > > As for upgrading, through IBM channels the latest we have access to is > > 8b104. If all is clean with 8b106, by all means upgrade to that. > > Has the bug in the Linux JVM be fixed in one of these? > Remember I'm still locked to b92! Hi Stephan, by the Linux bug you are perhaps to what we observed as "faulty" behavior at 8b100 time ? It is likely that Windows build was lagging Linux builds for the API change and we starting hitting it in the windows builds after 8b100. So in short, there may not be a Linux bug in the VM that is blocking us - only way to know for sure is to run the tests with Jesper's patch and see what comes. For the record, I am on Windows64, Jesper please call out what platform you are testing on. (In reply to Srikanth Sankaran from comment #10) > (In reply to Stephan Herrmann from comment #9) > > (In reply to Srikanth Sankaran from comment #8) > > > As for upgrading, through IBM channels the latest we have access to is > > > 8b104. If all is clean with 8b106, by all means upgrade to that. > > > > Has the bug in the Linux JVM be fixed in one of these? > > Remember I'm still locked to b92! > > Hi Stephan, by the Linux bug you are perhaps to what we observed as "faulty" > behavior at 8b100 time ? Indeed. > It is likely that Windows build was lagging Linux > builds for the API change and we starting hitting it in the windows builds > after 8b100. So in short, there may not be a Linux bug in the VM that is > blocking us - interesting! > only way to know for sure is to run the tests with Jesper's patch and > see what comes. RunAllJava8Tests with this patch on Linux 32bit with b106 gives a new set of failures (total failures: 26): 1x: an almost normal failure courtesy of bug 414653. 2x: "must implement the inherited abstract method Comparator.thenComparing..." many: disassembled byte code uses a real name instead of lambda$, plus metaFactory vs. metafactory in expected results some more: changes in constantpool indices So it looks like it's going in the right direction, but perhaps b106 brought yet another set of incompatibilities? (In reply to Stephan Herrmann from comment #11) > RunAllJava8Tests with this patch on Linux 32bit with b106 gives a new set of > failures (total failures: 26): > > 1x: an almost normal failure courtesy of bug 414653. > 2x: > "must implement the inherited abstract method Comparator.thenComparing..." > many: > disassembled byte code uses a real name instead of lambda$, > plus metaFactory vs. metafactory in expected results > some more: > changes in constantpool indices They are the ones I'm seeing on b100 (23 in all), and it's taking a while to fix... > So it looks like it's going in the right direction, but perhaps b106 brought > yet another set of incompatibilities? Looks like it. For the record, I'm on OS X (64 bit). Released as http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=114d487223299fbb39233b9fa5b4135ee3c694c5 Disclaimer: I've only tried this on b100, but judged from Stephans comment, b106 should not be a major setback. (In reply to Jesper Moller from comment #13) > Released as > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?h=BETA_JAVA8&id=114d487223299fbb39233b9fa5b4135ee3c694c5 Thanks ! I confirm that on Windows 64, with this patch, all tests are green against 8b104. (In reply to Stephan Herrmann from comment #11) > 2x: > "must implement the inherited abstract method Comparator.thenComparing..." This is likely only in 8b106 as I am not seeing it on 104. > many: > disassembled byte code uses a real name instead of lambda$, > plus metaFactory vs. metafactory in expected results > some more: > changes in constantpool indices These should have gone away with the test suite fix already released. To confirm: RunAllJava8Tests in HEAD of BETA_JAVA8 with b104 I only see these:
> 2x:
> "must implement the inherited abstract method Comparator.thenComparing..."
It's MethodVerifyTest.test331446() f.
(In reply to Stephan Herrmann from comment #15) > To confirm: RunAllJava8Tests in HEAD of BETA_JAVA8 with b104 I only see > these: Did you mean 8b106 and 104 ? With 104 on windows all is clean for me and it is surprising if something is failing on Linux. Could you post a fix that works for both ? Is bug 416480 similar to this? I see this fix doesn't address that one, but stil wondering if they are related. (In reply to Jayaprakash Arthanareeswaran from comment #17) > Is bug 416480 similar to this? I see this fix doesn't address that one, but > stil wondering if they are related. No, they are not, other than the symptom being the same they are unconnected. (In reply to Srikanth Sankaran from comment #16) > (In reply to Stephan Herrmann from comment #15) > > To confirm: RunAllJava8Tests in HEAD of BETA_JAVA8 with b104 I only see > > these: > > Did you mean 8b106 and 104 ? sorry, too sleepy when I wrote the comment: I meant to say b106. |