Bugzilla – Full Text Bug Listing
| Summary: | [1.8] define which JRE8 build we are targeting in BETA_JAVA8 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stephan Herrmann <stephan.herrmann> | ||||
| Component: | Core | Assignee: | Manoj N Palat <manoj.palat> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aclement, anchakrk, daniel.dietrich, david_williams, jarthana, jesper, manju656, manoj.palat, markus.kell.r, noopur_gupta, shankhba, srikanth_sankaran | ||||
| Version: | 4.3 | Flags: | srikanth_sankaran:
review+
|
||||
| Target Milestone: | BETA J8 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 413913 | ||||||
| Bug Blocks: | 380190 | ||||||
| Attachments: |
|
||||||
|
Description
Stephan Herrmann
Marking as top-level blocker of the master bug 380190 (In reply to comment #0) > I propose to use this bug for tracking the current build version of the JRE8 > against which all tests in BETA_JAVA8 should be green. +1. > In HEAD I observe that b50 is too old for the current state of > JavadocTestForClass. OTOH, b67 is too new for the current state of many > other tests. Unfortunately, I don't have the builds in between. We are trying to upgrade to b67, this will take a couple of days or so. (In reply to comment #2) > > In HEAD I observe that b50 is too old for the current state of > > JavadocTestForClass. OTOH, b67 is too new for the current state of many > > other tests. Unfortunately, I don't have the builds in between. > > We are trying to upgrade to b67, this will take a couple of days or so. Great. Do you have any background info regarding the library changes? There is a new bug (bug 396000) reported on master which might be related to this, though I am not entirely sure. (In reply to comment #4) > There is a new bug (bug 396000) reported on master which might be related to > this, though I am not entirely sure. There are lots of mails about "lambdaification" of various existing APIs. Not sure which one is relevant here, (In reply to comment #2) > (In reply to comment #0) > > I propose to use this bug for tracking the current build version of the JRE8 > > against which all tests in BETA_JAVA8 should be green. > > +1. > > > In HEAD I observe that b50 is too old for the current state of > > JavadocTestForClass. OTOH, b67 is too new for the current state of many > > other tests. Unfortunately, I don't have the builds in between. > > We are trying to upgrade to b67, this will take a couple of days or so. Is b67 the current reference or are we still between and betwixt several versions? (In reply to comment #6) > Is b67 the current reference or are we still between and betwixt several > versions? This target is moving fast - b69 is probably what we should settle on. I believe there are 117 failures out of 62430 with this JRE. We should investigate these, clean up the tests and settle on it for a while. (In reply to comment #7) > This target is moving fast - b69 is probably what we should settle on. > I believe there are 117 failures out of 62430 with this JRE. We should > investigate these, clean up the tests and settle on it for a while. Manoj, please on a top priority basis, analyze the issues with b73 so we can all move to it. Stephan, do you have ready reference to commits where you introduced some infrastructural support to handle library changes ? (In reply to comment #8) > (In reply to comment #7) > > > This target is moving fast - b69 is probably what we should settle on. > > I believe there are 117 failures out of 62430 with this JRE. We should > > investigate these, clean up the tests and settle on it for a while. > > Manoj, please on a top priority basis, analyze the issues with b73 so we > can all move to it. Is b73 what we said the other day? (I can't check my latest download because I'm at a different machine right now) If not, let's please skip b73, because it's no longer available. Today's version is b74 <sigh> > Stephan, do you have ready reference to commits where > you introduced some infrastructural support to handle library changes ? You mean stuff like attachment 220709 [details] (from bug 388800)? (In reply to comment #9) > > Stephan, do you have ready reference to commits where > > you introduced some infrastructural support to handle library changes ? > > You mean stuff like attachment 220709 [details] (from bug 388800)? Wait, that commit was later reverted by http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=dd3bff4d99a5193497eb7e3c0e1bc46a32b7c36a on behalf of bug 388954 comment 2. (In reply to comment #9) > Is b73 what we said the other day? > (I can't check my latest download because I'm at a different machine right now) > If not, let's please skip b73, because it's no longer available. > Today's version is b74 <sigh> I checked: my latest download was b69. I'm downloading b74 now, but I'm not able to get a b73 anywhere (for linux that is). I was mostly expecting regressions due to changes in the libraries, but here's an unexpected one: DefaultMethodsTest.testModifiers5() now fails with: java.lang.ClassFormatError: Method foo in class I has illegal modifiers: 0x1 There's some change in the VM between b67 (OK) and b69 (broken). Maybe the VM is now expecting a modifier for default methods? I haven't yet seen such modifier in any spec! When working on adapting our tests to a recent jre be sure to pull the fix for bug 390883, which incidentally resolved about a third of the regressions :) (In reply to comment #10) > Wait, that commit was later reverted by > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=dd3bff4d99a5193497eb7e3c0e1bc46a32b7c36a on behalf of bug 388954 comment > 2. Yep, Thanks. You can move to b74, we will follow suit shortly. Created attachment 226235 [details]
Proposed Patch [b73]
This patch addresses 118 failures of the total 119 failures found. Will raise a separate bug for the single failure
Next upgrade planned is to 8b80 - I see 8b77 is the latest. Please track and download when 8b80 becomes available. We will shortly upgrade to 8b80 or 8b81. Please prepare for it. (In reply to comment #17) > We will shortly upgrade to 8b80 or 8b81. Please prepare for it. Looking today I notice I missed 8b80 (linux x86), so can be please use 8b81? thanks (In reply to comment #18) > (In reply to comment #17) > > We will shortly upgrade to 8b80 or 8b81. Please prepare for it. > > Looking today I notice I missed 8b80 (linux x86), so can be please use 8b81? 8b81 sounds good. If you _happen_ to run tests using this JDK, please share results. Manoj is tasked with addressing failures and raising bugs or adjusting testsuites for JDK upgrades but if this is a NOP, it is good to know. (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > We will shortly upgrade to 8b80 or 8b81. Please prepare for it. > > > > Looking today I notice I missed 8b80 (linux x86), so can be please use 8b81? > > 8b81 sounds good. If you _happen_ to run tests using this JDK, please share > results. Manoj is tasked with addressing failures and raising bugs or > adjusting > testsuites for JDK upgrades but if this is a NOP, it is good to know. I did run some tests, and remember two failures because of a method "spliterator", which I assume is a newly introduced default method, that needs explicit overrides in a few tests for disambiguation. All, please upgrade to 8b81 - test results should be all green. Thanks. All, Please grab a copy of 8b90 when it becomes available. (b89 is the latest as of now). Manoj, let us all upgrade to 8b90 as the reference compiler as soon as it becomes available. Run the test suite, disable failing tests and raise a follow up bug to address the failures. If the failures are small in number (< 100), I would move forward to 8b90 without waiting for the tests to all be green and reenabled. TIA. (In reply to comment #22) > All, Please grab a copy of 8b90 when it becomes available. (b89 is the latest > as of now). It seems we are no longer speaking of the lambda specific download? On the lambda download page I still see b88 as the latest. OTOH, the regular "JDK™ 8 Early Access Release" download does have a b90 by now and from a smoke test it seems to have lambda support baked in. So that's the one we're currently targeting? Sorry if I'm a bit slow, I never saw any announcement that the lambda branch was merged into the main thing. (In reply to comment #23) > It seems we are no longer speaking of the lambda specific download? > On the lambda download page I still see b88 as the latest. > > OTOH, the regular "JDK™ 8 Early Access Release" download does have a b90 by > now and from a smoke test it seems to have lambda support baked in. For a while it's been so that the regular EA had some lambda support, but it's a bit dated, especially in the libraries part. I'm guessing it should work for us, though. Please upgrade to b92. Bug 410402 addresses the b92 failures. Please upgrade to b100 as the corresponding Bug 413913 is resolved Running with b100 I'm getting this for some tests using method references: java.lang.IncompatibleClassChangeError at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:383) at X.main(X.java:6) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) Am I doing something wrong? I also tried b102, same thing. (In reply to comment #27) > Running with b100 I'm getting this for some tests using method references: > > java.lang.IncompatibleClassChangeError > at > java.lang.invoke.MethodHandleNatives. > linkMethodHandleConstant(MethodHandleNatives.java:383) > at X.main(X.java:6) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl. > java:43) > at java.lang.reflect.Method.invoke(Method.java:491) > > Am I doing something wrong? I also tried b102, same thing. Andrew: This is a known issue. More details at bug 413913 comment 4 and follow up comments. Please, all upgrade to 8b104 at least or if you don't have access it and have the more recent 8b106, to that. on 8b104 all tests should be green and 8b106 there could be one failure. IBM committers will catch up to 8b106 shortly as soon as we are able to. b106 has renamed 3 default methods in Comparator. I've adjusted the tests via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=9b4643830ee06b9ae3b83a25e11220a2814a6ade (In reply to Stephan Herrmann from comment #30) > b106 has renamed 3 default methods in Comparator. > > I've adjusted the tests via > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?h=BETA_JAVA8&id=9b4643830ee06b9ae3b83a25e11220a2814a6ade I just upgraded to 8b108 on Windows 64. Java8 tests are green. (In reply to Srikanth Sankaran from comment #31) > > I just upgraded to 8b108 on Windows 64. Java8 tests are green. All, Please upgrade to b108. All, please upgrade to 8b115. JDT/Core tests are green on windows/64 (In reply to Srikanth Sankaran from comment #33) > All, please upgrade to 8b115. JDT/Core tests are green on windows/64 I noticed that when running RunAllJava8Tests, there are 8 failures in APT tests - these are coming from javac runs and not ecj runs, so we can upgrade right away and not allow these to hold us up. (In reply to Srikanth Sankaran from comment #34) > (In reply to Srikanth Sankaran from comment #33) > > All, please upgrade to 8b115. JDT/Core tests are green on windows/64 > > I noticed that when running RunAllJava8Tests, there are 8 failures in APT > tests - these are coming from javac runs and not ecj runs, so we can upgrade > right away and not allow these to hold us up. I have disabled the failing javac tests. So JDT/Core tests are all green with 8b115. I'm currently downloading the latest, just mine is called 8b114. (In reply to Srikanth Sankaran from comment #33) > All, please upgrade to 8b115. JDT/Core tests are green on windows/64 I assume 8b115 is just a typo. LMK if you indeed have a source for 8b115. (In reply to Stephan Herrmann from comment #36) > I assume 8b115 is just a typo. LMK if you indeed have a source for 8b115. It was not a typo - but I am fairly certain the IBM internal mirror is mislabelling them - I noticed a similar discrepancy earlier too. I'll alert them. Thanks! (In reply to Srikanth Sankaran from comment #37) > It was not a typo - but I am fairly certain the IBM internal mirror is > mislabelling > them - I noticed a similar discrepancy earlier too. I'll alert them. Thanks! I am told this *is* 8b115 obtained by IBM through Oracle's partner program. So perhaps the non-public downloads are updated ahead of public download site by Oracle. Today I can also see 8b115. Confusing, but resolved :) All, please upgrade to 8b120 for testing. Tests are green for JDT/Core (*) on Windows x64 for me. (*) Except for org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1146() which I have asked Stephan to take a look at. We are on the latest JRE available. I don't see a reason for leaving this bug open. In future communications on upgrades can be handled via email or jdt-core-dev list. After upgrading from b126 to b129 I see a failure in GTT.test1035(). What's confusing: At 1.7- this test should pass. Does COMPARATOR_IMPL_JRE8 need an update? At 1.8 we want to see two errors and with b129 we do see them. Would be cool to check what has changed (in Comparator?) between these versions. Anyway we need to decide if we test against b129 and adjust this test. (In reply to Stephan Herrmann from comment #42) > After upgrading from b126 to b129 I see a failure in GTT.test1035(). > > What's confusing: > At 1.7- this test should pass. Does COMPARATOR_IMPL_JRE8 need an update? > > At 1.8 we want to see two errors and with b129 we do see them. > > Would be cool to check what has changed (in Comparator?) between these > versions. > > Anyway we need to decide if we test against b129 and adjust this test. I do use b129 in our "production builds" ... if that's a factor in deciding. Thanks, I've adjusted the tests to pass on b129. Released via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=e282a51a768e93122fb029979cda6697735dca49 (In reply to Stephan Herrmann from comment #44) > Thanks, I've adjusted the tests to pass on b129. > > Released via > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?h=BETA_JAVA8&id=e282a51a768e93122fb029979cda6697735dca49 I am a little confused about this commit - this test fails on b129 with 2 errors, elsewhere you say it should issue error in 1.8, but it is a conform test. Was GTT supposed to be a part of this commit and was inadvertently omitted ? (In reply to Srikanth Sankaran from comment #45) > (In reply to Stephan Herrmann from comment #44) > > Thanks, I've adjusted the tests to pass on b129. > > > > Released via > > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > > ?h=BETA_JAVA8&id=e282a51a768e93122fb029979cda6697735dca49 > > I am a little confused about this commit - this test fails on b129 with > 2 errors, Which failures do you see? I had a full RunAllJava8Tests run green ... > elsewhere you say it should issue error in 1.8, but it is a > conform test. Was GTT supposed to be a part of this commit and was > inadvertently omitted ? No, before the fix I saw errors, but these were caused by incompatible implementations of Comparator, nothing intrinsic to the test it seems. As soon as I fixed COMPARATOR_IMPL_JRE8 the additional (desired) errors in GTT disappeared again :( (In reply to Stephan Herrmann from comment #46) > (In reply to Srikanth Sankaran from comment #45) > > (In reply to Stephan Herrmann from comment #44) > > > Thanks, I've adjusted the tests to pass on b129. > > > > > > Released via > > > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > > > ?h=BETA_JAVA8&id=e282a51a768e93122fb029979cda6697735dca49 > > > > I am a little confused about this commit - this test fails on b129 with > > 2 errors, > > Which failures do you see? I had a full RunAllJava8Tests run green ... GTT.test1035() fails on windows with 8b129. The comment just above the test says : // SHOULD FAIL AT 1.8 (RET): multiple but it is a conform test. I recall earlier once we had this situation where same build JRE was showing different APIs and so different failures on linux vs windows. Perhaps another instance ? ATM, I can live with just ignoring this. (In reply to Srikanth Sankaran from comment #47) > (In reply to Stephan Herrmann from comment #46) > > (In reply to Srikanth Sankaran from comment #45) > > > (In reply to Stephan Herrmann from comment #44) > > > > Thanks, I've adjusted the tests to pass on b129. > > > > > > > > Released via > > > > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > > > > ?h=BETA_JAVA8&id=e282a51a768e93122fb029979cda6697735dca49 > > > > > > I am a little confused about this commit - this test fails on b129 with > > > 2 errors, > > > > Which failures do you see? I had a full RunAllJava8Tests run green ... > > GTT.test1035() fails on windows with 8b129. The comment just above the test > says : // SHOULD FAIL AT 1.8 (RET): multiple You seeing that failure is good news. Did you check 1.7- modes? Do those fail, too? > I recall earlier once we had this situation where same build JRE was showing > different APIs and so different failures on linux vs windows. Perhaps another > instance ? Sounds like it. I just reran GTT.1035 on linux 8b129 and it's green as a conform test. :( Kind of weird, huh? I'll leave this REOPENed state till we resolve the present situation where using 8b129, we see some errors in GTT on Windows, while the run on Linux is clean. Looks like the JREs on these platforms are not in sync. Earlier once we had a similar problem. This should hopefully resolve itself as we upgrade to a newer JRE. (In reply to Stephan Herrmann from comment #48) > You seeing that failure is good news. > > Did you check 1.7- modes? Do those fail, too? Yes it seems to fail on all modes on Windows. Manoj, please download the latest (8b131 or is it 132 ?), run all tests to verify all is well and see if the failure in GTT goes away. TIA. (In reply to Srikanth Sankaran from comment #51) > Manoj, please download the latest (8b131 or is it 132 ?), run all tests to > verify > all is well and see if the failure in GTT goes away. TIA. Stephan, please likewise test with 8b132 on Linux and report observations, TIA (In reply to Srikanth Sankaran from comment #52) > (In reply to Srikanth Sankaran from comment #51) > > Manoj, please download the latest (8b131 or is it 132 ?), run all tests to > > verify > > all is well and see if the failure in GTT goes away. TIA. > > Stephan, please likewise test with 8b132 on Linux and report observations, > TIA I already had a green run of RunAllJava8Test with this jre. (In reply to Stephan Herrmann from comment #53) > I already had a green run of RunAllJava8Test with this jre. OK, we have a mystery in our hands. If I grab the program file after "preprocessing" via string substitutions is done and feed it to javac 8b131 - It compiles fine in 1.8 and (in cross compile modes) 1.7, 1.6. and 1.5 - In the eclipse *IDE* it compiles fine in 1.5 - 1.8 - You say the junit passes in Linux as a conform test for you in 1.5 - 1.8 Stephan, can you confirm this compiles fine on Linux using javac both native and cross compile modes ? So without analyzing the merits of the case, the evidence strongly points to this being a conform test. Question: why would this fail under junit on Windows ? I'll follow up. (In reply to Srikanth Sankaran from comment #54) > Question: why would this fail under junit on Windows ? I'll follow up. Mystery indeed. Shorter test case: // -- import java.util.Comparator; class ComparableComparator<T extends Comparable<? super T>> implements Comparator<T> { public int compare(T obj1, T obj2) { return obj1.compareTo(obj2); } public <U> java.util.Comparator<T> thenComparing(java.util.function.Function<? super T, ? extends U> keyExtractor, java.util.Comparator<? super U> keyComparator) { return null;} } Fails as a junit, compiles in IDE + javac. Under investigation. (In reply to Srikanth Sankaran from comment #55) > Fails as a junit, compiles in IDE + javac. Under investigation. Turned out to be a set up issue. My JRE path claiming to be 8b131, but was actually pointing to 8b126 contents. Deleting and readding 8b131 fixed the issue. All, please upgrade to 8b131 or 8b132. |