Enhancement: Clarify dependency on Jakarta Activation: DataSources no longer work on Java 9+
mrj opened this issue · 8 comments
javax.activation, which creates DataSource objects for attachments, is deprecated in Java 9+. Without the interim fix of adding the javax.activation module to the JVM start, the JVM silently hangs looking for it. It was hard tracking down the reason why after moving from Java 8 to 11 my app hung when one of my classes was loaded.
The docs should be updated to warn that withAttachment using a javax.activation DataSource will fail on Java ≥ 9, and that either byte arrays should be used exclusively, or Jakarta Activation used instead.
Ok, thanks for the forensic work! I'll check the size of the activation library and probably lock it in. Won't be for a few weeks though, currently away from home for two weeks.
Looking into this again I'm getting confused: the activation framework is already included as external dependency by JavaMail:
So why is this failing for you in Java ≥ 9?
Ah. I haven't yet worked out how to use Maven dependencies. I just add libraries to my Eclipse build path that the docs request, plus what prevents compile errors. I guess this is one missing dependency that instead manifests as a run-time hang on Java ≥ 9. Perhaps your docs can mention this stealth dependency.
Well, you made me think now. It comes as a transitive dependency (stealth dependency as you say), but it is also a direct dependency of Simple Java Mail, not just Jakarta JavaMail. That means I should include it as such in the pom.xml and NOTICE.txt.
Would that be enough or are you looking at specific documentation for Simple Java Mail's dependencies?
Sorry, I'm not familiar with Java's dependency-detection mechanisms. Explicit dependency documentation wouldn't be needed if the missing dependency generated a compilation error that suggested what's missing — though explicit docs would help in this case where a dependency is moving from a Java standard component to a third-party library.
Explicit dependency documentation wouldn't be needed if the missing dependency generated a compilation error that suggested what's missing
That's not possible with jars unfortunately (with modules this works much better).
though explicit docs would help in this case
I'll make sure to mention it somewhere. For now I've included it in both the pom.xml and NOTICE.txt, which is not related to Maven.
I've updated the documentation, but it will only show up once 6.0.0 is released.
5.4.0 released.