Get rid of defensive checks for JAF across the framework [SPR-13807]

[spring-projects-issues]

Sam Brannen opened SPR-13807 and commented

Status Quo

Since JDK 1.6, the JavaBeans Activation Framework (JAF) is a standard part of the JDK. However, several parts of the framework perform defensive checks regarding the availability of JAF on the classpath. In addition, several parts of the documentation contain language similar to "if JAF is present".

Deliverables

1. Get rid of defensive checks for the presence of JAF
2. Update Javadoc and the reference manual accordingly

---

No further details from SPR-13807

[spring-projects-issues]

Juergen Hoeller commented

After some consideration, I'll keep these defensive checks in place for the time being: not only for JAF but also for JSR-310 (java.time).

Despite the JAF classes being commonly available since JDK 6, they are not in the "java.base" module in JDK 9 since they're considered "EE" which Jigsaw factors out into separate modules for potential overriding in application servers. In other words, in a modular JDK 9 world, a minimal JDK layout does not actually expose JAF.

As for JSR-310, the java.time package is available in the JDK 9 "java.base" module... but apparently not included in Android N's Java 8 support. Our traditional defensive registration doesn't seem to hurt there either.

[spring-projects-issues]

Sam Brannen commented

Fair enough.

That's unfortunate about the change with Jigsaw. So it's great that you already have that change on your radar!

By the way, due to Jigsaw, do you think we should make MockServletContext.getMimeType(String) defensive once again with respect to JAF?

[spring-projects-issues]

Juergen Hoeller commented

Good point, this might be reason enough for MockServletContext to defensively access JAF again...