Using the Jabref 5.0 release then going back to 4.3.x will break the UI because of shared settings

[Sethur]

JabRef version 5.0 and 4.3.1, Windows 10, Bundled JDK 13 and Java 1.8.0_241

I tried the current JabRef 5.0 release today on our database with approx. 2000 entries. Since I was not satisfied with the overall performance (startup time, notable lag while typing, scrolling, etc.) and resource uptake (both CPU and memory) I wanted to go back to Jabref 4.3.1. Note that I did NOT save the BIB-file in Jabref 5.0.

Unfortunately, after going back to 4.3.1., the settings of the table view seemed to have been completely messed up. Most of the columns had different names and where empty. At first I thought the BIB-file was changed, but I did a diff on a recent backup and that was not the case. It turned out, that the preferences that are saved in the windows registry for Jabref 5.0 are incompatible with the settings for previous versions but are still saved at the exact same location. This then brakes the UI.

My suggestion would be to change the path in the registry where JabRef 5.x stores its settings in order to prevent this behavior.

[Siedlerchr]

Thanks for your suggestion, However, I think it's unlikely we will change that as JabRef 5.0 is a new major release. While JabRef is backwards compatible (it can migrate settings and fields from previous versions, it's not forward compatible. With a different storage of preferences this would make no sense. However, what indeed is necessary is that the portable version should not mess with the registry settings.
However, the FAQ has a solution for your question:
https://docs.jabref.org/faq/faqgeneral#q-i-have-tried-the-latest-version-of-jabref-since-then-the-library-entries-are-no-longer-displayed-in-any-old-version-what-should-i-do

[Sethur]

@Siedlerchr : Are you sure you don't want to tackle this? Changing the registry path for the settings of JabRef 5.x versions would be a minimal effort and allow for both versions being worked with next to each other. IMO it is common best practice to prevent a registry conflict with newer software versions by using new paths (or field names) if necessary. It would also allow developers and users to quickly try out new betas/alphas without messing up the settings.

[koppor]

@Sethur Could you please provide me some information why you are going to use 4.3.1 and 5.0 in parallel? We are working hard on improving the latest development version. We have limited resources and want to foster the expericence of the latest version.

Could you please try the latest develoment snapshot: https://builds.jabref.org/master/? We tackeled performance issues (Refs #4430)

Maintaining two preferences is not just about two nodes in the registry - as we offer migration etc. Have to think longer about converting etc etc etc

[Sethur]

@koppor : We are currenlty using JabRef as a group for a larger publication database (>2500 entries). It is important that everything works smoothly, so I want to avoid installing new major releases unless the new features are worth the risk of instability / breaking of the database. We have been using JabRef 3.x for a long time, but since I needed the feature to guess the meta info of PDFs based on content, we updates to 4.x at some point, after I had evaluated that the performance and stability had reached a satisfactory degree. For this evaluation, I had to use both versions in parallel, as I was doing now with JabRef 4.x and 5.x.

Frankly, I have never come across any software where things break so bad when you run a newer version and then go back to an older one, while only working on isolated input data made for the particular version. I can understand that developers at times have to drop backwards compatibility (e.g. for the database, as happened at the jump of 3.x to 4.x) because of limited resources, but using identical setting files/registry folders and not taking care of compatibility there is - in my opinion - very unexpected behavior for any kind of software and should be avoided whenever possible.

You said that just using separate folders is not possible because you are migrating the settings. Without knowing your code in detail I would still argue that you can still easily migrate the settings from the old 4.x registry folder to the new 5.x one by using almost the same logic, you would just need to clone the old settings to the new registry folder first and then do everything as before in the new folder.

[Sethur]

Could you please try the latest develoment snapshot: https://builds.jabref.org/master/? We tackeled performance issues (Refs #4430)

I missed this one, and it sort of answers your own question: I have and cannot easily try any other dev-versions of JabRef 5.x precisely because it will mess up my settings for our production version of JebRef 4.x. I would need to do that on another machine or in a VM, which would be a hassle to setup just to quickly check a new snapshot for performance/stability.

[koppor]

I understand that you have preferences which you cannot loose. Double check: The preferences are something configured there:

Note that JabRef stores the most important settings in the library (.bib file) itself.

Now comes the workaround proposal

Have JabRef 5.x portable edition in use.

1. Start JabRef 4.x

2. Export the preferences

3. Start JabRef portable

4. Test it

5. Start JabRef 4.x as follows

   JabRef.exe -d all -n

6. Then import the preferences you exported at step 2

This way, you can avoid the VM.

Meanwhile, I'm thinking of providing a patched version of JabRef 4.3.1. - Regarding of our increasing amount if issues (https://github.com/JabRef/jabref/projects/5) (not features), and the decision that we want to have the latest JabRef version always being the best version, it is hard for me to work a concept for 5.0 with different preferences.

This refs JabRef/user-documentation#227 and #5730.

[Sethur]

@koppor : Thanks for the workaround, this will work, as will exporting the folder in the windows registry directly and then just importing it after going back to 4.x. However, both are a hassle and new users will not expect something like this to happen. Instead, they will probably thing (like me) that they just killed their database. I understand that you have a lot of issues to tackle with 5.x, but IMO, this is one of them, and it should be quite high up the list.

Since I did not understand what part of changing the path in the registry for JabRef 5.x would be so difficult, I actually looked it up in the source code now, and since you are using the Java Preferences API, it should be as easy as changing the variable PREFS_BASE_CLASS in JabRefPreferences.java to a version specific value.

Edit: And yes, there needs to be some more work regarding the proper selection of preferences nodes for the migration of old settings when coming from previous versions, but that's it. I think this would be well worth the effort.

[koppor]

@Sethur Thank you for looking into the code. Maybe you find some time to support our development. Bug fighting, a new feature. Whatever you feel comfortable --- The good newws is: We finally worked on a fix at #6296. Should be in master soon. If you want, you can test the binaries https://builds.jabref.org/pull/6296/merge/.

[Sethur]

@koppor Thanks for pressing this fix. I see that you chose to change the conflicting variable names for 5.x rather than using an entirely new node name (which would translate to a new registry "folder" with Windows). Not sure why you wanted to go trough the hassle of changing all the variables, but I'm happy as long as there are now more conflicts. I'll certainly come up with some more bugs / pull requests if I find the time.

EDIT: BTW: While downloading the test build I realized that there are now bundles without the Java JRE any longer. Is this intentional? 340 MB is a lot of data for an app like JabRef. Compare this to the 4.x and 3.x releases with around 55 and 34 MBs.

[Sethur]

@koppor : Ok, I found out why the releases are so large. Not only do you bundle the Java JRE now, but there are also jfxwebkit dynamic libraries for both windows and linux/mac inside the JAR-file even not matter what bundle you chose. Besides that, there are also tons of redundant dlls (api-ms-win-...) in the main JabRef jar file, which are already present on the lowest level, but the double WebKit is definitely the main culprit.

[Siedlerchr]

@Sethur We bundle a custom jdk which contains only the modules JabRef needs. (We use the new jpackage + jlink tools)
We also noticed the duplicate files and try to work on it #5748

[Sethur]

@Siedlerchr : Well, the full JDK for Java 11 to 14 is around 300 MB when installed, while the JabRef runtime directory for 5.x is >210 MBs, so I would guess that something went wrong with jpackage/jlink. I put in an improvement request for this here: #6340