As a developer, I want to make breaking changes now that Payara 5 is an option

[poikilotherm]

As discussed with @scolapasta in Tromso, I would like to start a discussion how we are going to do breaking changes, that do good things to the codebase but are not backward compatible with Glassfish 4.1.

Examples for this are many of the things described in #5292, like #5274, #5360 plus IQSS/dataverse-security#12, #5293 etc.

This is a follow up to #6230, #6593, #6595 and is related to #4259

Gustavo, you being the Lead Architect for this great software package, pretty please enlighten us. (I took the liberty to assign this to you.)

[poikilotherm]

BOOM. 💥

Here we go. Simple thing: I want to use JSON binding for #6694 which is a native part of Java EE 8 (JSR367). Glassfish 4.1 means Java EE 7 only.

There is JSON binding available via MOXy/EclipseLink, but JSON was far away from being a first class citizen back in the day (meaning only very simple mappings are usable without a lot of boilerplate). Now I would need to mess around with a framework written for XML, make many workarounds etc instead of relying on a standard, writting lean code.

It's also not so easy to find proper docs dealing with the old ways, as most search results regard new stuff. Lots of stones, which can be moved, but need a lot of extra energy.

What can we do?

(Looking into parsing and validating the JSON manually with Jackson et al. But still: we need a way forward. Jakarta EE 9 at the horizon and Java 14 coming, being the next LTS)

[scolapasta]

@poikilotherm now that the latest version of Payara has been released, we'll be revisiting that work in the next sprint. I don't expect to see any major issues (as we addressed all of them with our patched version), so my expectation is that we are not far from Dataverse 5. With that release, we will be updating doc and installers as well, and drop official support for Glassfish 4.1.

All that to say, we will not need to worry changes that are are not backward compatible with Glassfish 4.1. I think it is soon enough that we should just go through with these types of changes; we won't be able to merge ASAP, but it won't be long either.