-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AnnotateAssistTest1d8 test failed #736
Comments
org.eclipse.jdt.ui.tests.quickfix.AnnotateAssistTest1d8.testAnnotateParameter_WildcardBound failed in I20231115-1800, macosx.cocoa.x86_64 java17.
|
AnnotateAssistTest1d8 frequentl fails on I-Build I20240123-1800 on all platforms with various exceptions for example NPE or "Wrong number of proposals" |
also frequently fails on CI jenkins |
org.eclipse.jdt.ui.tests.quickfix.AnnotateAssistTest1d8 Failed on I20240522-1800, java17_macosx.
|
This suggests a problem in this code section of ExternalNullAnnotationQuickAssistProcessor.computeQuickAssistProposals()
Candidates:
At the bottom line this doesn't look like a problem specific to the functionality being tested, but more like a problem in general handling of buffers for a classfile. As I'm unable to reproduce locally, I don't think I can help much to resolve this. Anyway, please let me know if ever a JavaModelException is logged by this test. |
I plan to review that Buffer code. |
Some field accesses had not been synchronized which may have caused NPEs in access from different thread. eclipse-jdt/eclipse.jdt.ui#736
Some field accesses had not been synchronized which may have caused NPEs in access from different thread. eclipse-jdt/eclipse.jdt.ui#736
Some field accesses had not been synchronized which may have caused NPEs in access from different thread. eclipse-jdt/eclipse.jdt.ui#736
failed again with updated error message - @stephan-herrmann does that help?
|
The logfile
|
Sounds wrong that org.eclipse.jdt.ui.JavaUI.openInEditor(IJavaElement) for a .class file returns Editor from bndtools which is registered for .jar files. |
I agree, this looks weird. In the good case, If another editor is registered for
The failing cast happens in the test class, not in productive code, so we could get away in tests by either
|
addresses the ClassCastException fixes eclipse-jdt#736
addresses the ClassCastException fixes #736
I hope the ClassCastException will no longer occur after #1478 Seeing also changes in Buffer synchronization (eclipse-jdt/eclipse.jdt.core#2596) let's keep fingers crossed. To be re-opened if the problem persists. |
still happens:
|
explicitly request a ClassfileEditor 2nd attempt at eclipse-jdt#736
Previous theory was, that a "foreign" editor for .class (from bndtools) was selected randomly (which would have been fixed by making JDT's editor the default in preferences). In #1486 I'm short-cutting the selection of an editor ID, by directly requesting an editor for ID |
explicitly request a ClassfileEditor 2nd attempt at #736
the error message changed to:
|
ErrorEditorPart means Java editor failed to initialize, this is reported to the log:
|
Assert that the java element is child of a classfile debugging eclipse-jdt#736
@iloveeclipse thanks for collecting this error output! At first look this seems to imply, that
Next attempt in #1501: assert that the java element is indeed a child of a classfile, otherwise let failure report the actual element. |
Assert that the java element is child of a classfile debugging #736
error changed to:
|
So the first of 4 failures is caused by a missing buffer, only after that we get IJavaElements saying "in [Working copy] X.class" without having an IClassFile parent. Missing buffer could be caused by a problem in |
Some field accesses had not been synchronized which may have caused NPEs in access from different thread. eclipse-jdt/eclipse.jdt.ui#736
Some field accesses had not been synchronized which may have caused NPEs in access from different thread. eclipse-jdt/eclipse.jdt.ui#736
Interestingly, this test class previously exposed a bug in buffer management, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=550180:
Unfortunately, what could previously be observed also locally no longer occurs on my machine. |
the ClassCastException still happens:
|
failed again with
|
failing really often, with alternating errors
|
Previous theory was: if multiple editors for .class are registered, then setting JDT's class file editor as the default should ensure that we don't get bndtools' JAREditor instead. Thus #1478 made our classfile editor the default during this test. Still we get the undesired editor, which cannot be used for the test. Is it possible that bndtools replaces editors, i.e., unregisters the "org.eclipse.jdt.ui.ClassFileEditor" editor?? |
AnnotateAssistTest1d8.testAnnotateParameter_Varargs2 test failed on mac in I20230824-0400.
The text was updated successfully, but these errors were encountered: