Make dependency on JAXB optional

[kwsutter]

There is a very active thread on the Platform Dev mailing list where we are discussing whether to Add the JAXB Spec/API to Jakarta. The latest reply from Markus to me indicated a possibility of marking the dependency on JAXB from JAX-RS as optional, but he would like an issue for further discussion with the JAX-RS development team. Thus, this issue...

Just for some quick background... JAXB moved from Java EE to Java SE several years ago. The Java EE specifications still maintained a dependency on JAXB, but it was clearly now delivered by Java SE. In Java SE 11, the JDK community decided to remove JAXB from their deliverable. So, the question on the table is whether to just continue to have this dependency on JAXB in it's current state and the javax namespace, or whether there is a need to evolve this API which would then require a move to the jakarta namespace.

The vote is kind of split right now. There is the one side that recognizes the dependency between JAX-RS and JAXB and, thus, want to move JAXB to Jakarta. But, there's the other side that recognizes that JAXB probably does not need evolving or updating, so why move it to Jakarta and incur more work?

Anyway, that was more for the background story. The true intent of this issue is to have the discussion as to whether JAXB could be made an optional dependency for JAX-RS.

[mkarg]

Looking at API and Spec I think it would be possible. As modern applications use JSON instead of XML, it might be good idea to make JAXB optional in JAX-RS. This means, we just defined how to treat JAXB if it is supported by an implementation, but we do not request it. For applications this means, they will still run on some implementations, but not necessesarily on all.

[chkal]

I agree with @mkarg. IMO it would be definitely possible to make JAXB optional and I would be fine with doing so.

[andymc12]

The Link class has JAXB annotations and an inner class (JaxbAdapter) with hard dependencies on JAXB.

I see a few approaches that would work for this case:

1. Remove the JAXB inner classes and annotations (and perhaps replace them with JSON-B equivalents?) - this would be irregular since they are not currently deprecated, but not completely without precedent.
2. We leave a compile-time dependency on JAXB, but not a runtime dependency. Then we document in the spec and/or javadoc that JAXB is required for the Link.JaxbAdapter class.
3. We leave the dependency as-is - and we just keep depending on javax JAXB. For Java 8, nobody has a problem. For Java 11+, users (or implementors) would need to pull in a separate javax JAXB module at runtime... not ideal, but still would work...

There are also spec text references to JAXB. If we go with option 1 above, then we would need to remove these references. If we go with option 3 above, then we could leave these references intact. For option 2:

In the spec, section 4.2.4 says that an implementation MUST provided a pre-packaged JAXB MessageBodyReader/Writer. This would need to change to be something like "a JAXB MBR/MBW must be provided in JAXB is available at runtime" - similar to how a JSON-B provider is specified today.

Section 4.3 mentions that users can supply their own JAXBContext to the JAXB MBR/MBW via a context resolver. This would also need to be updated to reflect that the JAXB MBR/MBW is optional.

There might be other options too, but these seem to be the most clear cut. If I've missed something, please let me know.

[spericas]

Andy described the problem very well. The correct thing to do would be to deprecate those JAXB inner classes immediately and remove them in the next version. We can then tweak the text in the spec to make JAXB optional.

[andymc12]

This issue came up again with a presentation from @kwsutter - on the Jakarta EE project page, it mentions that JAXB is optional - see the text Jakarta XML Binding (Optional).

Given that we have a hard dependency on JAXB, I think we'll probably need the Jakarta Platform group to make JAXB a required component of the spec, but I thought I would re-open the discussion here in case we want to either deprecate/remove the JAXB references in the 3.0 release - I think that doing that would require that we submit a release plan proposal.

[chkal]

Would applying option (2) fix this problem? IMO this is essentially what @mkarg also proposed!?

[mkarg]

My personal opinion is that it would be best to go with option (2) for JAX-RS 3.0, but at the same time prepare for option (1) by clearly deprecating it. IMHO a future release of JAX-RS should not force runtime vendors to provide JAXB by themselves, but ask application vendors to provide JAXB API + Impl. as part of the application, and ask vendors to apply that provided API + Impl.

[andymc12]

@chkal - yes, I think Option 2 would solve the main issue without needing any further process. It is a slight change in behavior for users though - in 2.1 application/xml just works out of the box, but in 3.0 a user or implementation may need to provide their own JAXB API and impl to get the same behavior. Most vendors will probably just include JAXB as a dependency for their JAX-RS implementation, so it probably isn't a huge deal. But it might require a release plan... @kwsutter what do you think?

If we want to deprecate it in 3.0 (@mkarg and I think @spericas both support this), then we will for sure need to do a release plan. If we do that, then I'd suggest that we also deprecate getSingletons (see issue #835) in 3.0.

I'd like to hear Kevin's opinion on whether we would need a release plan for option 2 (documenting in the spec that JAXB is only required if the user uses certain APIs/content types). If we would need a release plan, then my opinion would be that we also deprecate the Link.JaxbAdapter API and getSingletons. If we don't need a release plan for option 2, then I lean towards not deprecating until 3.1.

[spericas]

Deprecation in 3.1 seems like the better option to me now.

[kwsutter]

@andymc12 I would say that updating the JAX-RS Spec to indicate the optional aspect of the jaxb dependency falls within the scope of the Jakarta EE Release Plan. Since the Platform is providing jaxb as an optional technology, then your update is just a minor ripple effect of that change.

If you try to take this further by deprecating items, then a separate release plan would be required. And, since we're really past the date of introducing new release plans for Jakarta EE 9, I'd not go the deprecation route for the 3.0 release. Wait for 3.1. That seems consistent with @spericas view.

[andymc12]

@kwsutter Thanks - that sounds good.

All, I'll plan to draft something up for indicating that JAXB is optional in the spec document (option 2). Thanks for the discussion.