OpenAM JAXB 4.x migration

[rohithjayak]

This PR contains the OpenAM migration to JAXB4.x which was discussed in the case: #963

[vharseko]

This branch has conflicts that must be resolved (rebase to origin/master or merge from origin/master)

[maximthomas]

Hi @rohithjayak
Thank you for the contribution. We appreciate the effort you put into the PR. But there are several issues with the PR I have to point out:

• You have removed JDK 17 and older support, but some users are still on 11, so we need to maintain older JDK support
• You upgraded already to JAXB 4 which is Jakarta EE 10, but OpenAM is still on Jakarta EE 9, we have plans to migrate to Jakarta EE 10 in future.
• There is already a PR that migrates to JAXB 3, and I think it has more solid approach, as it restores JAXB classes generation from schema. JAXB3 Migration #1023

[vharseko]

Thanks for the work here, @rohithjayak. Adding a couple of notes on top of @maximthomas's review — mainly about CI status and about sequencing the migration.

CI status. The PR is currently red across the whole build matrix (every build-maven job on all OS/JDK combinations, plus CodeQL). The build never reaches compilation — it fails at POM parsing:

[FATAL] Non-parseable POM openam-shared/pom.xml: Unrecognised tag: 'dependency'
(position: START_TAG seen ...</version>\n <dependency>... @163:21) @ line 163, column 21

So openam-shared/pom.xml has a stray <dependency> outside a <dependencies> block around line 163 — this looks like a leftover from the master merge/conflict resolution (it matches the branch name and the earlier conflict note). Fixing that first would let CI actually build the branch so we can review the real changes.

On sequencing. This PR bundles three large changes at once: the javax.xml.bind → jakarta.xml.bind namespace move, the jump to JAXB 4.x (Jakarta EE 10), and dropping JDK ≤17. That's a lot to validate in a single step, and as Maxim noted OpenAM is still on Jakarta EE 9 and needs to keep JDK 11.

Could we do this more gradually? The natural first step is #1023 (JAXB 3 / Jakarta EE 9): it keeps JDK 11+ support, restores JAXB class generation from schema, and its CI is fully green and mergeable today. Landing #1023 first moves us onto the jakarta.* namespace on a stable footing; the JAXB 4 / Jakarta EE 10 bump (this PR) then becomes a much smaller, isolated follow-up for when the project actually moves to Jakarta EE 10.

Happy to help rebase this on top of #1023 once it's merged.

[rohithjayak]

Hi @maximthomas, @vharseko ,
Thanks a lot for reviewing these changes and providing inputs.
Sorry the dependency tag got missed while resolving the conflict, i have made that change to add one closing dependency tag now and pushed it, could you please check if things are fine?
The dropping of JDK ≤17(i.e., only support JDK 21) was specifically done to make it compatible with our product, let me check on if it is feasible to make it backward compatible as well, If you already know the changes, please let me know i can incorporate it and update it in the PR.
And regarding the PR sequencing, let me check with my team internally and get back...

Thanks,
Rohith Jayakumar

[vharseko]

Hi @rohithjayak,

First, thank you again — to you and the Cisco team — for putting this migration together and for staying engaged through the review. The effort is genuinely appreciated, and it helped us clarify how we want to approach the move onto the jakarta.* stack.

After thinking it through, we've decided to do this migration incrementally rather than as one large step, so I'm going to close this PR. The reasoning, briefly:

• JDK support. OpenAM still needs to build and run on JDK 11 (and 17). This PR targets JDK 21 only — in CI every JDK 11/17 job fails at compile time with invalid target release: 21 — and we can't drop the older JDKs right now.
• Jakarta EE baseline. The project is currently on Jakarta EE 9, while this PR jumps straight to JAXB 4.x (Jakarta EE 10). Moving to EE 10 is on our roadmap, but as a later, isolated step rather than bundled with the namespace migration.
• Overlap with JAXB3 Migration #1023. JAXB3 Migration #1023 already covers the javax → jakarta namespace move on the JAXB 3 / Jakarta EE 9 baseline, keeps JDK 11+ support, and restores JAXB class generation from the schemas. It's green and mergeable today, and we think it's the more solid foundation. (For reference, the JDK 21 jobs here fail later on hundreds of duplicate class errors in openam-saml2-schema, from generated sources colliding with committed ones — exactly the area JAXB3 Migration #1023 handles more cleanly.)

None of this is wasted work: once #1023 lands and we're ready to move to Jakarta EE 10, the JAXB 4 bump becomes a much smaller, focused change, and your branch here will be a valuable reference for it. We'd be very glad to see you or the Cisco team revisit it as a follow-up then — and I'm happy to help rebase it on top of #1023 when the time comes.

Thanks again for the contribution, and for understanding. 🙏

[rohithjayak]

Hi @vharseko,
Thank you for the explanation and for sharing your roadmap regarding the JAXB migration. In the meantime, we plan to integrate the changes from our fork (specifically the changes in #1067) into our product. Could you please share any recommendations on best practices for maintaining this fork, or any specific considerations we should keep in mind as we move forward?

Thanks,
Rohith Jayakumar

[maximthomas]

Hi @rohithjayak,

Our main recommendation would be to avoid letting the fork diverge too far from upstream. It's best to keep tracking master and rebase onto it periodically, rather than continuing to build on the commit you originally branched from.

Once #1023 is merged, we'd suggest rebasing your work on top of it — it already handles the javax → jakarta migration on JDK 11+, so your remaining diff should be reduced mainly to the JAXB 3→4 / Jakarta EE 9→10 upgrade itself, along with any product-specific pieces such as the JDK 21-only changes. This should make the branch considerably easier to maintain and keep in sync going forward.