Java 11: Unable to load JDK7 types (annotations, java.nio.file.Path): no Java7 support added

[dconnelly]

Might be OK to ignore for now but seeing this warning when running with a jlink'd minimal Java 11 image:

Sep 07, 2019 12:25:42 AM com.fasterxml.jackson.databind.ext.Java7Support <clinit>
WARNING: Unable to load JDK7 types (annotations, java.nio.file.Path): no Java7 support added

On closer inspection it looks like com.fasterxml.jackson.databind.ext.Java7SupportImpl tries to load the annotation java.beans.Transient to detect Java 7 but this doesn't work on Java 11+ without the full java.desktop module dependency.

[cowtowncoder]

Not sure there is a clean way to do much about this unfortunately (since Jackson can't really use any features of Java 8 or beyond as 2.x only requires JDK 6 runtime, JDK 7 compilation).
Jackson 3.0 (master) does include support directly and avoids the issue.

[GedMarc]

@cowtowncoder if you remember this was one of those requires static to make it optional, forcing the client to specify whether they want it or not.

I dont recommend making it mandatory.

@dconnelly This was an intentional decision by me to specify it as optional, in your module info you will need to specify it as a required module, the other route is to change the implementation or to make the dependency requires transient.

Let me know your thoughts

[cowtowncoder]

Ah. Yes, now I remember -- since this particular type came from non-core part of JDK?

But I think it's sort of confusing just because I think java.nio.file.Path would not be the problem (it would be within core part of JDK, I think), but rather "other part", @ConstructorProperties annotation.
In theory it would be possible to separate those out, I suppose.

Let me think about this for a bit now that 2.10 is about to be finalized.

[cowtowncoder]

Ok, so, for 2.10 I split Java7Support/-Impl into 4 classes; 2 new ones being Java7Handlers/-Impl. J7Support now loads annotation part, and J7Handlers serializer/deserializer for Path type, and only latter will log anything in case of failure.
So I think this should work better for J2SE at least.
I'll see if I should change 3.0 a bit as well, to revert merge of annotation access into main part and leave it as extension.

[ber4444]

I think this (and #2466) is badly broken with coreLibraryDesugaringEnabled on android (see https://jakewharton.com/d8-library-desugaring/), creating issues such as wiremock/wiremock#1323

[cowtowncoder]

For anyone following, there is: #2744 for Android part -- question of Java 11 is little bit different.