[4.35] On startup Java editor shows error annotations on valid code that don't always disappear

[Phillipus]

This is transferred from eclipse-jdt/eclipse.jdt.ui#2069

Eclipse 4.35 RC2
Java Temurin 21 SDK
Reproduced on Windows 11 and Mac Sequoia (not tested on Linux)

1. Download Eclipse 4.35 SDK from https://download.eclipse.org/eclipse/downloads/
2. Launch Eclipse with a fresh workspace
3. Create a sample plug-in project "Hello, World Command"
4. Open the file SampleHandler.java in the editor
5. Now close Eclipse and re-open Eclipse a few times.
6. Upon opening Eclipse I get red problem markers in the file. Many times these problem markers do not clear.

Edit - the first time re-opening Eclipse the red markers will disappear but after closing and re-opening thereafter the red markers remain.

A workaround is to add some text to the file such as a space and then undo.

This does not happen in Eclipse 4.34.

[Phillipus]

Comment from eclipse-jdt/eclipse.jdt.ui#2069

Switching PDE.ui to I20250106-1800 fixes the issue.
Updating to the commit 7e45ebb breaks. So it is a regression from #1552.

[iloveeclipse]

I was able to reproduce it easily following the steps in the bug on Linux, so it is not platform dependent.

[laeubi]

Sorry we won't do any fixing here.

See

• JDT calls PDE Classpath on startup with open Editor hindering the UI to show up #1481 (comment)

so if anyone is interested, please fix the issues in JDT / Platform and the problem will go away, there is nothing PDE can do.

[merks]

I've been seeing this as well on and off too. 😢

This is one of those bouncing issues where one seems to be damned if you do and damned if you don't, so I can empathize with not wanting to keep this bouncing this back to the previous poor state. Computing a classpath via some computation that may take minutes on the UI thread really needs to be avoided at the source. But the source seems not to want to do this.

In any case, one would hope and expect that when the job finishes computing the classpath that the editor's state would updated. Is there some notification or interaction missing? That would be the direction on which to focus I think, but I don't know who or where that should happen.

[Phillipus]

So, should I transfer this issue somewhere else? (Don't shoot the messenger)

[laeubi]

In any case, one would hope and expect that when the job finishes computing the classpath that the editor's state would updated. Is there some notification or interaction missing?

That's possible, but still something not PDE can fix ..

So, should I transfer this issue somewhere else? (Don't shoot the messenger)

As said there are already issues created:

• [performance] PackageFragmentRoot.getRawClasspathEntry() has bad impact on startup performance eclipse-jdt/eclipse.jdt.core#3468
• [performance] CloseUnrelatedProjectsAction.buildConnectedComponents(IProject[]) blocks UI startup eclipse-platform/eclipse.platform.ui#2636
• [performance] JDT initialization blocks IDE startup eclipse-jdt/eclipse.jdt.ui#1860

one would maybe open another one for the reasons @merks has mentioned.

[iloveeclipse]

@laeubi : can you proof that the code in #1552 is correct and always works? Why do you think that everything written before this commit can be wrong but the #1552 is for sure fully correct?

The issues in JDT UI you are pointing refer to performance issues (which may existed since ever), this one is a functional problem introduced by #1552.

So you should at least investigate the problem before closing it blaming some other code => reopening.

[laeubi]

The issues in JDT UI you are pointing refer to performance issues

It was JDT that classified them as "performance", I opened them as bugs ...

And there is nothing to "proof" calling the classpath init in the UI thread is simply wrong, it doesn't matter how long it was wrong.

Also the javadoc of the ClasspathContainerInitializer init method mentions:

Binds a classpath container to a IClasspathContainer for a given project, or silently fails if unable to do so.

So any code must listent to classpath changes if it is important to them.

So you should at least investigate the problem before closing it blaming some other code => reopening.

I have already investigated this in depth, and have shown that when the calling code is fix no issues arise anymore. This can easily be reproduced by closing eclipse but have not any java editor being active at that time. So it is solely a JDT issue an nothing PDE can or should fix in any way (beside from protecting IDE lockdown).

[laeubi]

Also please notice this very important sentence:

A workaround is to add some text to the file such as a space and then undo.

The text do not make it clear, but you don't even need to save the file, so it is fixed by simple text edit no compile or whatever required, what shows that everything works fine except the Java editor not updating properly...

[iloveeclipse]

@Phillipus : sorry to say, but there will be no fix for this issue soon, as @laeubi doesn't feel responsible to do so and I have no time. You can try to debug issue by yourself, now you know where the difference in behavior is coming from.

[merks]

My expectation is that the JDT editor processes the source file with an incomplete classpath which of course leads to all kinds of things not being found. That's not so surprising...

But when the classpath container finishes computing the classpath it does this:

I assume this is happening correctly, but good to confirm. Assuming that does happen, then JDT is informed of the change and JDT could and arguably should use that to update/refresh the affected editor(s).

So I would focus on what's happening in JDT when org.eclipse.jdt.core.JavaCore.setClasspathContainer(IPath, IJavaProject[], IClasspathContainer[], IProgressMonitor) is called upon PDE job completion.

[Phillipus]

@Phillipus : sorry to say, but there will be no fix for this issue soon, as @laeubi doesn't feel responsible to do so and I have no time. You can try to debug issue by yourself, now you know where the difference in behavior is coming from.

It's a pity that it goes like this. I guess from now on Eclipse users better get used to seeing red crosses and lines in their code. (I'm afraid I'm not familiar enough with JDT to provide a fix)

[merks]

I really don't want to point any fingers. As they say, whenever you point a finger, there are three fingers pointing back. Nothing is to be gained from that. In the end everyone needs to take some responsibility and we should avoid attempts to shift or offload that responsibility elsewhere. The offending commit was on January 10th; there's been quite some runway for that problem to have been noticed. No doubt I should of taken the problem more seriously when I did see it. In any case, we can only try to move forward and improve things for the next release.

[laeubi]

I have now created

• Java Editor is showing errors due to missing updates from the build sometimes eclipse-jdt/eclipse.jdt.ui#2074

with some more details it all looks to me like an update problem as nothing changes in regards to the classpath between "wrong" and "right" state, I just literally type one (1) character in the editor makes "something" update it.

[Phillipus]

I just literally type one (1) character in the editor makes "something" update it.

But that's normal behaviour. If I type an illegal character inside of a field so String s = ""; becomes StXring s = ""; then the editor is updated and an error marker appears.

[laeubi]

I just literally type one (1) character in the editor makes "something" update it.

But that's normal behaviour. If I type an illegal character inside of a field so String s = ""; becomes StXring s = ""; then the editor is updated and an error marker appears.

I cant see how that contradicts anything regarding the statement "Java Editor is Missing an Update"... So something changes (e.g. a resource is changed, build containers change, a user types a character, JDT Model updated due to a build...) then the Java Editor needs to update, and something here is either not listen for or not correctly performed (e.g. to early).

[laeubi]

This fixes the problem for me:

• Force reconciling if a java project was touched eclipse-jdt/eclipse.jdt.ui#2079