This field has nothing to do with the package version, but instead the version of the Freedesktop desktop entry specification that the .desktop file conforms to: https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

You should honestly just delete the key entirely as I don't think anything actually cares about it and it's likely to confuse people further in the future.

Using a wrapper script like ipscan uses would probably be a better approach.

Something like this:

#!/bin/sh

if [ -z "$JAVA_HOME" ]; then
    export JAVA_HOME=/usr/lib64/openjdk-17
fi

exec /usr/share/jabref/bin/JabRef "$@"

Which would allow the user to override the JAVA_HOME themselves if they chose to.

You should keep gradle as a build dep and change the ./gradlew command to gradle instead so it uses the system gradle instead of the wrapper.

How interesting, I have written several desktop files before and never knew that!

Will do this, also allows launch from shell

Bit of an issue here

* What went wrong:
Could not compile settings file '/home/build/YPKG/root/jabref/build/jabref-5.5/settings.gradle'.
> startup failed:
  General error during semantic analysis: Unsupported class file major version 61

gradle is 6.8.3 but given the choice jabref uses 7.3.3

OK, use the bundled gradle wrapper but keep gradle as a builddep and add a note that it needs a newer version of gradle. I'm going to be bumping gradle as part of the Java stack update so when we move onto the part where build tooling uses jdk-17 by default and removing explicit JAVA_HOME and related variables we can switch this package to system gradle.