Migrate to Jakarta EE 9

[tamersaadeh]

Jakarta EE 9 platform renames all the "old" namespaces from javax.* to jakarta.*. This pull request performs this migration so that when Jacakrta EE 9 is released in June 2020 it will be compatible.

I ran mvn test with no* failures and travis builds did not fail.

Note 1: this is completely incompatible with the old namespace, so probably the major version of the library should be bumped.
Note 2: currently depends on pre-released versions of the JAXB specification (RC3). This can be updated when the final version is released.

*: a couple of the afterburner tests failed, but I haven't modified that module and I'm not exactly sure how to debug that.

[cowtowncoder]

Ok, one quick request: could you also create issue with above description, to refer this PR from?

I will have to think about this: I agree that it is a big jump and has to be coordinated.
Change for master (eventual Jackson 3.0) makes sense in that respect.

One question on compatibility: does this change JDK baseline requirement (I don't think so, based on changes)? For 3.0 Java 8 is needed.

One other approach here would be to create separate new JAXB module; this would have the benefit of users being able to use old or new one. If we were to introduce this in 2.x that would probably be necessary. With 3.0, maybe less so.

@GedMarc wdyt?

[GedMarc]

For version 3, I think this is definitely mandatory to go to Jakarta 9.

1. JDK Baseline. Jakarta 9 is on JDK 8, and all profiles must provide JDK 11 compatibility (not necessarily modules which has me grilled a bit)

Java SE Version

For inclusion in Jakarta EE 9, specification’s APIs MUST be compiled at the Java SE 8 source level. However, compatible implementations of the Jakarta EE 9 Web Profile and Full Profile MUST certify compatibility on Java SE 11. Compatible Implementations MAY additionally certify and support Java SE 8.

References - Jakarta 9 Spec (https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan )
Oracle transitioning guide - https://blogs.oracle.com/javamagazine/transition-from-java-ee-to-jakarta-ee

2. From JDK 13, all 1.5 classes can no longer be read (looking at you javax.activation and javax.inject), the new Jakarta coordinates have to be used to even compile from this version and up. The Jakarta 8 libraries (mostly) now have module-info's as well, but the move is still incomplete, and it is using javax.activation locking into this restriction. Jakarta 9 has this resolved.

3. I don't think a new jaxb module would be necessary as you can run both javax.jaxb and jakarta.jaxb alongside each other on classpath mode JDK 8 and up, and modular specifications allow you to requires static to allow multiple module definitions, but for version 3x only Jakarta 9 libraries with the min JDK 8 specification?

Just my 2 cents worth -
For now on my side i'm sticking with javax. namespace until the move across is complete and module-info's are in all Jakarta 9 libraries. It's a massive move

[tamersaadeh]

Ok, one quick request: could you also create issue with above description, to refer this PR from?

Done: #96

For now on my side i'm sticking with javax. namespace until the move across is complete and module-info's are in all Jakarta 9 libraries. It's a massive move

If you are referring to all the other packages in the Jackson suite, I can provide PRs for them too. But obviously as you said it's a massive move and need proper coordination.

[cowtowncoder]

I think the only repos affected would be this (for JAXB annotations module), jackson-dataformat-xml (due to minor references to JAXB annotations, optionally used) and jackson-jaxrs-providers (similarly for optional JAXB annotations usage).

I really do not know if, when and how to proceed here: I do not see this happening in near term, esp. without users requesting it.

[GedMarc]

This is still going to be a while off - M4 just released with 3 more to go, i also see that servlet 5 has a new module name/namespace (relating to jax-rs)

Hibernate module (which may be dropped if I remember right) has a reliance on jaxb as well,
Jakarta namespace may need to become a base requirement for 3 with all the package movements and class reassignments

[cowtowncoder]

Theoretically may even be necessary to create separate repos and modules here :-/

[cowtowncoder]

I think #116 resolved this?

[cowtowncoder]

Note for anyone finding this via search engines etc: for Jackson 2.13, the relevant change is #130: addition of a separate module -- so the existing, "old" module will support old javax/JAXB annotations, and new one Jakarta XML Bind annotations.