Community
Participate
Working Groups
I am using eclipse-SDK-I20200226-1800-macosx-cocoa-x86_64. While I was trying ti find the root cause for #560585, I stumbled upon multiple wired compilation issues and errors that do not happen in the 2019-12 release. Since this is a PDE project, maybe the root cause is in PDE, but it surfaces through the Java code, therefore filing the issue here. Steps to reproduce: - use latest Eclipse SDK as your IDE - target platform: download latest nightly build of STS4 on Eclipse 4.15 from here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html - set the STS4 install as your target platform (not your IDE) - git clone https://github.com/spring-projects/spring-ide.git - Import As Existing Project "org.springframework.ide.eclipse.boot.dash" from the "plugins" folder. (sorry, but I wasn't able to create a simple sample that reproduces this) That should result in a PDE/Java project in your workspace. This works fine in Eclipse 2019-12 (even if the target platform is a newer Eclipse). In the latest 4.15 builds, this shows up with a compiler error on the enum: org.springframework.ide.eclipse.boot.dash.model.RunState When opening org.springframework.ide.eclipse.boot.dash.model.AbstractLaunchConfigurationsDashElement a similar error shows up at the bottom of that file on the overridden method. This itself is strange, but when I change something in that file and press save, tons of errors show up about types that cannot be resolved. When doing a clean build, everything resolves fine again (another issue, I think). I am not sure about the compiler error above, but the tons of errors about missing types is very similar to the bug that I reported today about cross-plugin resolution issues. This might all be rooted in some strange things in my projects (since I am not able to reproduce this with a simple example), but I am super worried about the 4.15 release exactly the same steps behave just perfectly well in 2019-12...
Which JDK are you using? Can you attach your error log please?
I get the following compilation error with corretto 1.8.0 202: Bound mismatch: The type Enum<E> is not a valid substitute for the bounded parameter <E extends Enum<E>> of the type RunState
(In reply to Julian Honnen from comment #2) > I get the following compilation error with corretto 1.8.0 202: > > Bound mismatch: The type Enum<E> is not a valid substitute for the bounded > parameter <E extends Enum<E>> of the type RunState The error is reported on clean build only. Touching the org.springframework.ide.eclipse.boot.dash.model.RunState and saving it (just a space or comment change) fixes the error till next clean build.
(In reply to Andrey Loskutov from comment #1) > Which JDK are you using? Can you attach your error log please? JDK is (for both the same, 2019-12 and 2020-03): java.vm.vendor=Oracle Corporation java.vm.version=13.0.1+9 Error Log doesn't reveal anything More details/steps/observations: open: org.springframework.ide.eclipse.boot.dash.model.AbstractLaunchConfigurationsDashElement The error shows up on the "supportedGoalStates" method at the bottom of that class. When I delete that method and instead copy it into the subclasses: - BootProjectDashElement - LaunchConfDashElement All the errors go away, and working on the source works just fine. Even the "resolve types from different plugin" works again. When undo-ing those changes, I get the wrong behavior again.
Martin, to help me decide if I should urgently look at this, please give more details on what problems exactly you see. Just knowing that there are unexpected compile errors doesn't give a hint if one of my changes might be responsible.
I've bisected this, regression is coming from bug 527761 commit 97609bfc7e97c6f6ae7ba958f656e2efd47c7fce.
(In reply to Andrey Loskutov from comment #6) > I've bisected this, regression is coming from bug 527761 commit > 97609bfc7e97c6f6ae7ba958f656e2efd47c7fce. More precisely, commenting out the new if block below fixes the error: https://git.eclipse.org/r/#/c/155140/2/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/lookup/ReferenceBinding.java@2104
(In reply to Stephan Herrmann from comment #5) > Martin, to help me decide if I should urgently look at this, please give > more details on what problems exactly you see. Just knowing that there are > unexpected compile errors doesn't give a hint if one of my changes might be > responsible. This error shows up on the "RunStatus" enum: === Bound mismatch: The type Enum<E> is not a valid substitute for the bounded parameter <E extends Enum<E>> of the type RunState === The same error shows up on the method "supportedGoalStates" on "AbstractLaunchConfigurationsDashElement", but it shows up in the editor only. When commenting out the method and pressing save on that source file, results in about 100 errors in that file, most of them: "<type> cannot be resolved" Does that help? To me this looks like a small, but severe problem that seems to trigger other issues (like the type resolving between plugins), but that is a different piece of the puzzle here.
Created attachment 281958 [details] Compiler options to disable Martin, please disable the options in the attached screenshot in your workspace (I did this for the concrete project only). This should fix the compilation error with the RunState / org.springframework.ide.eclipse.boot.dash project. Please check if all other issues disappear, and if not, please post what else is not working.
(In reply to Andrey Loskutov from comment #9) > Created attachment 281958 [details] > Compiler options to disable > > Martin, please disable the options in the attached screenshot in your > workspace (I did this for the concrete project only). This should fix the > compilation error with the RunState / > org.springframework.ide.eclipse.boot.dash project. > > Please check if all other issues disappear, and if not, please post what > else is not working. This workaround indeed solves the issue and the other strange side effects are gone, too. So this is great news!!!
*** Bug 560585 has been marked as a duplicate of this bug. ***
Thanks for analysis so far. I'm looking into it now
As downloads/clone are taking a loooong time on my end ... (In reply to Martin Lippert from comment #0) > - git clone https://github.com/spring-projects/spring-ide.git > - Import As Existing Project "org.springframework.ide.eclipse.boot.dash" > from the "plugins" folder. could s.o. attach just the needed project here?
... should've said: please send a harddisk with everything installed. Seems this bug set a record on size of downloads and git repo to clone just for investigating one compile error. Frankly I've never seen a git repo of that size. Starting the work only now.
New Gerrit change created: https://git.eclipse.org/r/158525
(In reply to Eclipse Genie from comment #15) > New Gerrit change created: https://git.eclipse.org/r/158525 ParameterizedTypeBinding is affected by the same problem as detected regarding SourceTypeBinding in bug 558759 comment 10: method unResolvedMethods() intended for inspecting method bindings without triggering any resolution, did trigger resolving of lots of things, including a bound check involing enum RunState before that enum had its super class connected. Fix is simple. I'm trying to create a regression test for this.
(In reply to Stephan Herrmann from comment #14) > ... should've said: please send a harddisk with everything installed. LOL... Indeed... > Seems this bug set a record on size of downloads and git repo to clone just > for investigating one compile error. Frankly I've never seen a git repo of > that size. Yeah, I am sorry for that, it is indeed an old repo, containing about 15 years of work on the various Spring IDE components... My bad that I wasn't able to strip this down to a simple sample project, because I had no idea where to start looking with regards to that error. And many many many thanks for all involved here for the super quick turnaround on this, this is AWESOME !!!
@Manoj: While jenkins is still testing, may I already ask you to start collecting the necessary approvals for inclusion in RC2? @Andrey: as you already came near the buggy code, do you want to do a code review? Description of problem and fix: - The change for Bug 527761 uses method ReferenceBinding.unResolvedMethods() by the assumption that this method will not cause any unwanted resolving. Call site is the new method hasMethodWithNumArgs(). - In bug 558759 comment 10 I detected that SourceTypeBinding did not behave well: we *did* invoke unwanted resolving. I fixed that type. Now STB.hasMethodWithNumArgs() avoids calling that unhappy unResolvedMethods() - In this bug we see that ParameterizedTypeBinding still suffers from the same problem, requiring another override of hasMethodWithNumArgs(). Since this method doesn't care about any types, it is safe to just delegate to this.type, so that STB.hasMethodWithNumArgs() can take over. The bug is a bit hard to reproduce since it happens only in a very specific call sequence, finally resulting in performing a bound check involving an enum class which did not yet have its superclass set. I managed to reduce a small but quite complex test case (in path set #2). Without the fix it spits out: ---------- 1. ERROR in EN.java (at line 1) public enum EN { ^ Bound mismatch: The type Enum<E> is not a valid substitute for the bounded parameter <E extends Enum<E>> of the type EN ---------- With the fix, the example is accepted, as is the original project referenced by Martin. I haven't analysed why this simple compiler bug caused floods of secondary compile errors, but after fixing the original bug the affected project is healthy again.
(In reply to Stephan Herrmann from comment #18) > @Andrey: as you already came near the buggy code, do you want to do a code > review? I did, but I didn't understand it (I'm not in this business), so sorry, no +1 from me. I personally would also love to see this fixed in 4.15, but if not, I can understand it because it is pretty late and a workaround is possible.
(I've corrected the target to 4.15RC2) +1 from me.
(In reply to Till Brychcy from comment #20) > (I've corrected the target to 4.15RC2) > > +1 from me. thanks for both :)
Jay, we need approval to release it in RC2.
This didn't make the cut for 4.15.
(In reply to Andrey Loskutov from comment #22) > Jay, we need approval to release it in RC2. *sigh*, looks like this was a casualty when bugzilla genie wasn't sending mails last week. Sorry about it.
Gerrit change https://git.eclipse.org/r/158525 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=0868f3b2221bc1d98910c1d867395871c555bc88
(In reply to Eclipse Genie from comment #25) > Gerrit change https://git.eclipse.org/r/158525 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=0868f3b2221bc1d98910c1d867395871c555bc88 Released for 4.16 M1
Thanks again to all involved here and especially Stephan for fixing this. Much much appreciated and great to see that the fix made it now into the repo.
New Gerrit change created: https://git.eclipse.org/r/159664
(In reply to Eclipse Genie from comment #28) > New Gerrit change created: https://git.eclipse.org/r/159664 Backport patch for 4.15 stream.
Verified for Eclipse Version: 2020-06 (4.16) M3 with Build id: I20200406-0600
(In reply to Manoj Palat from comment #30) > Verified for Eclipse Version: 2020-06 (4.16) M3 with Build id: I20200406-0600 I mean 4.16 M1 - sorry for the typo/c&p
