Skip to content
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

Cannot instantiate view: interface org.jabref.gui.frame.UiMessageHandler #11386

Closed
2 tasks done
ryan-carpenter opened this issue Jun 18, 2024 · 13 comments
Closed
2 tasks done

Comments

@ryan-carpenter
Copy link

JabRef version

Latest development branch build (please note build date below)

Operating system

GNU / Linux

Details on version and operating system

openSUSE Tumbleweed with KDE Plasma 6.0.5

Checked with the latest development build (copy version output from About dialog)

  • I made a backup of my libraries before testing the latest development version.
  • I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

  1. Open a library
  2. Click File > Preferences > Citation key generator
  3. Edit the default key pattern
  4. Click save
  5. Error occurs, changes do not save.

JabRef 5.14--2024-06-17--0e7c1ff
Linux 6.9.3-1-default amd64
Java 21.0.2
JavaFX 22.0.1+7

Appendix

...

Log File
java.lang.IllegalStateException: Cannot instantiate view: interface org.jabref.gui.frame.UiMessageHandler
	at afterburner.fx/com.airhacks.afterburner.injection.Injector.lambda$getDefaultInstanceSupplier$6(Unknown Source)
	at afterburner.fx/com.airhacks.afterburner.injection.Injector.instantiateModelOrService(Unknown Source)
	at afterburner.fx/com.airhacks.afterburner.injection.Injector.instantiateModelOrService(Unknown Source)
	at org.jabref@5.14.186/org.jabref.gui.preferences.general.GeneralTabViewModel.storeSettings(Unknown Source)
	at org.jabref@5.14.186/org.jabref.gui.preferences.AbstractPreferenceTabView.storeSettings(Unknown Source)
	at org.jabref@5.14.186/org.jabref.gui.preferences.PreferencesDialogViewModel.storeAllSettings(Unknown Source)
	... <truncated>
Caused by: java.lang.InstantiationException: org.jabref.gui.frame.UiMessageHandler
	at java.base/java.lang.Class.newInstance(Unknown Source)
	... 110 more
Caused by: java.lang.NoSuchMethodException: org.jabref.gui.frame.UiMessageHandler.<init>()
	at java.base/java.lang.Class.getConstructor0(Unknown Source)
	... 111 more
@koppor
Copy link
Member

koppor commented Jun 18, 2024

@ryan-carpenter Thank you for the quick report! Can you retry the latest development build?

@calixtus
Copy link
Member

Thanks for the report, yesterday evening we merged a major code refactoring pr and created a hotfix for the issue about the UiMessageHandler this morning (#11387). It should work again. Please try the latest build.

@ryan-carpenter
Copy link
Author

With the latest build, the error is gone but changes to the key generator pattern do not save.

  1. Edit default or other citation key generator
  2. Click save.
  3. Action appears successful, but changes are not applied.
  4. Reopen preferences to check key generator patterns. Values are the same as before steps 1 and 2.

JabRef 5.14--2024-06-18--524e79b
Linux 6.9.3-1-default amd64
Java 21.0.2
JavaFX 22.0.1+7

@ryan-carpenter
Copy link
Author

Clicking save does produce this notification in the terminal.

2024-06-18 16:04:04 [JavaFX Application Thread] org.jabref.gui.JabRefDialogService.notify()
INFO: Preferences recorded.

I get this when I exit preferences by clicking the Close button.

ANTLR Tool version 4.12.0 used for code generation does not match the current runtime version 4.13.1
ANTLR Runtime version 4.12.0 used for parser compilation does not match the current runtime version 4.13.1
<repeated three more times>

@ryan-carpenter
Copy link
Author

I had the ANTLR message yesterday, and possibly before (on last month's 5.14 development version) but I think this this lucene warning is new today.

2024-06-18 15:53:05 [JavaFX Application Thread] org.apache.lucene.internal.vectorization.VectorizationProvider.lookup()
WARN: Java vector incubator module is not readable. For optimal vector performance, pass '--add-modules jdk.incubator.vector' to enable Vector API.

@ryan-carpenter
Copy link
Author

Probably unrelated, but are the field markers case sensitive? The documentation says to use uppercase, then provides examples in camel case here: https://docs.jabref.org/setup/citationkeypatterns with a few (inconsistent) uppercase examples here: https://docs.jabref.org/setup/citationkeypatterns#modifiers

@calixtus
Copy link
Member

calixtus commented Jun 19, 2024

With the latest build, the error is gone but changes to the key generator pattern do not save.
...

Hi, thanks for the report, but I was not able to reproduce.
Did you hit the return key to commit the changes to the table row before clicking on save? This is a still unresolved javafx bug we tried to workaround with a message.
grafik

@calixtus
Copy link
Member

I had the ANTLR message yesterday, and possibly before (on last month's 5.14 development version) but I think this this lucene warning is new today.
...

This is about a new feature in our backend for fulltext search engine (and maybe soon our main search engine) Apache Lucene. See apache/lucene#12311 . The lucene team is adopting a so called incubating java feature (which will probably be integrated with minor changes as soon as project valhalla is (?) is ready), which could increase the performance of the search engine a bit.

@calixtus
Copy link
Member

As the original issue is resolved im closing it. If the problem with the citation key generator persists, please open a new issue. Thanks again for reporting the issue quickly.

About the field markers (#11386 (comment)): Maybe @ThiloteE can help you, he is our expert on this.

@ryan-carpenter
Copy link
Author

Hi, thanks for the report, but I was not able to reproduce. Did you hit the return key to commit the changes to the table row before clicking on save? This is a still unresolved javafx bug we tried to workaround with a message.

I knew about this, but completely forgot despite the message. Sorry! Resolution confirmed.

@ThiloteE
Copy link
Member

Probably unrelated, but are the field markers case sensitive? The documentation says to use uppercase, then provides examples in camel case here: https://docs.jabref.org/setup/citationkeypatterns with a few (inconsistent) uppercase examples here: https://docs.jabref.org/setup/citationkeypatterns#modifiers

I don't know if field markers are case sensitive. Up until now I followed the documentation and wrote it as shown there. If you try them with different case, you could report back here. Would be interesting to know.

@ryan-carpenter
Copy link
Author

I don't know if field markers are case sensitive. Up until now I followed the documentation and wrote it as shown there. If you try them with different case, you could report back here. Would be interesting to know.

The markers are case sensitive and the documentation is correct. The uppercase examples that I described as "inconsistent" are in fact different by design.

image

@koppor
Copy link
Member

koppor commented Jun 20, 2024

I get this when I exit preferences by clicking the Close button.

ANTLR Tool version 4.12.0 used for code generation does not match the current runtime version 4.13.1
ANTLR Runtime version 4.12.0 used for parser compilation does not match the current runtime version 4.13.1
<repeated three more times>

I was (and still am) too lazy to add a hint that building from source requires "./gradlew clean" now and then. -

During compilation, files are generated. They are not regenerated if they exist. Also if the generator is updated, they are not regenerated. In the concrete case, ANTLR is updated now and then. It is also a generator. It generates Java code based on a Grammar file. That code is not updated if it exits on disk. However during runtime, ANTLR checks for the versions. It sees old files if one updated ANTLR. In your case by pulling the latest main branch.

When generating a build using the GitHub workflows, gradle triggers a regeneration of these files because the generated files are not cached between workflow runs.

Thus, please, try out "clean" and see whether the output persists. If it still does, my guess was not right and we need to check other reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants