JBang and Java 26 final fields

[wfouche]

$ jbang run --java 26 hello@jbangdev world

WARNING: Final field catalogRef in class dev.jbang.catalog.CatalogRef has been mutated 
reflectively by class com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$2 in 
unnamed module @7bfcd12c (file:/home/wfouche/.sdkman/candidates/jbang/0.137.0/bin/jbang.jar)

WARNING: Use --enable-final-field-mutation=ALL-UNNAMED to avoid a warning

WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled
Hello world

[quintesse]

Yeah, we should probably make all fields non-final in data classes that are meant to be (de)serialized.
We won't ever change them but insisting on final when it's only to cause issues brings no advantages IMO.

[wfouche]

With PR #2430 applied, JBang supports running scripts with Java 26 without displaying any warning messages:

$ ./build/install/jbang/bin/jbang run --java 26 hello@jbangdev world
Hello world

[maxandersen]

gah - that seriously suck imo :/

will there be an alternative where I can mark a field as final so i can get compile errors at build time when trying to change them but still able to do serialization at runtime?

[wfouche]

We have a few other options to resolve this issue:

• Make the fields private and use Lombok to generate getters. Gson will still use reflection at runtime, and this is not GraalVM native-image friendly.
• Another option is to introduce Kotlin data classes (that supports Java 8). No reflection is required at runtime, and this option is GraalVM native-image friendly. Kotlin data classes are equivalent to Java records, but with support for Java 8. The Kotlin runtime jar will be pulled into JBang.jar
• Use Java records, oh we cannot because we still need to support Java 8.
• As temporary measure, set "Enable-Final-Field-Mutation: ALL-UNNAMED" in Manifest.mf

[wfouche]

Updated build.gradle to include

'Enable-Final-Field-Mutation': 'ALL-UNNAMED'

in Manifest.mf

[quintesse]

Another option would be:

• use a custom deserializer (https://www.javadoc.io/doc/com.google.code.gson/gson/latest/com.google.gson/com/google/gson/JsonDeserializer.html)

[maxandersen]

i was curious and asked an agent how it would look like and #2434 is the result.

I'm not sure I like it much; but thought I would share it to compare :)

[quintesse]

Yeah, that's the other solution I suggested, but I knew it would be a bunch of ugly-looking code. The one-line config change is perhaps not very elegant, but neither is the type-adapter solution. Personally I'd go for the one-liner, we can always reconsider in the future.