Re: [jackson-user] Jackson 2.9.8 and Jva 8 support - Can we keep using Java 7 with Jackson 2.9.8 (Build and Runtime)

[Tatu Saloranta]

On Thu, Jan 31, 2019 at 3:34 PM Penny Wells <penny.w...@gmail.com> wrote:
>
> The Jackson component is embedded into an enterprise software of our company that will not go beyond Java 7 for many years to come.
> Can we safely make the assumption that Jackson 2.9.8 will never require Java version 7 ? We will not use any Java 8-specific features (Lambda expressions, etc), but will that guarantee taht the Jackson 2.9.8 will worked as they have been in the recent versions on Java 7 ? (Build and Runtime).Is it possible to exclude any Java-8-specific support from Jackson libraries version 2.9.8 ?

Yes. Jackson 2.9.x in general does not use any Java 8 (or beyond
features) without additional modules (there are 3 that can be used to
add Java 8 features like Optional, and Java 8 date/time). Runtime
attempts to work on Java 6, with (small number of) Java 7 types being
dynamically loaded, but build requires JDK 7.

It is our intention to keep the same baseline for 2.10 as well, and
barring any unforeseen major breakages, I don't see why 2.x major
version would ever require Java 8 to run.

-+ Tatu +-

ps. I am happy this question gets asked as often feedback on need for
support for older JVM/JDK versions is not nearly as loud as one for
forward-direction (when does Jackson fully support Java 11) -- there's
fine balance with things

[Mediocaballero MidKnight]

Sorry to revive this old, thread, but it's related to an issue I'm finding now.

We are also in the situation of upgrading some dependencies on corporate legacy software, which, for runtime platform restrictions can only use jdk 6.

We've found that jackson 2.9.9 solves all current vulnerabilities found but, when updating from 2.3.0 (yup, I know this was a long, long time ago) we are getting runtime errors on required runtime version for jackson-databind ObjectMapper:

java.lang.UnsupportedClassVersionError: com/fasterxml/jackson/databind/ObjectMapper : Unsupported major.minor version 51.0

I've looked at the pom and, indeed, jackson-databind is compiled with java 7 as target, although it mentions java 6 compatibility:

<properties>

<!--

With Jackson 2.9 we will require JDK 7 (except for annotations/streaming),
         and new language features (diamond pattern) may be used.
         JDK classes are still loaded dynamically since there isn't much downside
         (small number of types); this allows use on JDK 6 platforms still (including
         Android)
     

-->

<javac.src.version>1.7</javac.src.version>

<javac.target.version>1.7</javac.target.version>

The last one with java 6 target is 2.7.9.5, but this one still carries 9 known CVEs...

Is there any workaround known/suggested?

Thanks and greetings!!!

[Tatu Saloranta]

On Mon, Jul 1, 2019 at 7:44 AM Mediocaballero MidKnight
<medioca...@gmail.com> wrote:
>
> Sorry to revive this old, thread, but it's related to an issue I'm finding now.
>
> We are also in the situation of upgrading some dependencies on corporate legacy software, which, for runtime platform restrictions can only use jdk 6.
>
> We've found that jackson 2.9.9 solves all current vulnerabilities found but, when updating from 2.3.0 (yup, I know this was a long, long time ago) we are getting runtime errors on required runtime version for jackson-databind ObjectMapper:
>
> java.lang.UnsupportedClassVersionError: com/fasterxml/jackson/databind/ObjectMapper : Unsupported major.minor version 51.0
>
> I've looked at the pom and, indeed, jackson-databind is compiled with java 7 as target, although it mentions java 6 compatibility:

Ah. You are right in that it is then that although bytecode, if it was
targeted at Java 6, would work, in practice this isn't of much help
unless a converter was used to mark jars as compiled for Java 6.
You could try an earlier version (but newer than 2.3) to get some of
the fixes -- looking at release notes I think 2.6 was targeting Java
6; and perhaps 2.7 was compiled in such a way as well.

One key challenge that actually prevents better bytecode backwards
compatibility as this point is tooling, because:

1. Javac 8 does not allow target of 1.6 (I think), at least not directly.
2. It is not possible (or at least not easy enough for me to figure
out how.. :-( ) to use JDK 7 with Maven release tools in a way
actually deploy releases to Sonatype's OSS repository -- this had to
do with security aspects (certificates) needed for
upload/verification.

so that even if I otherwise could build backwards compatible versions,
I can't get them to be released.

If anyone is aware of retro-weaver style tools that can take jars with
newer declared bytecode version and convert to older, that'd be great,
sharing most appreciated.
Most likely that would still require some local work from user's part,
but I think would allow use of newer Jackson versions on Java 6.

-+ Tatu +-

> --
> You received this message because you are subscribed to the Google Groups "jackson-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
> To post to this group, send email to jackso...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/bb14f34d-c934-4f71-bf1e-ac2af2b2caf2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michael Rogers]

On 01/07/2019 15:57, Tatu Saloranta wrote:
> If anyone is aware of retro-weaver style tools that can take jars with
> newer declared bytecode version and convert to older, that'd be great,
> sharing most appreciated.

I haven't tried it myself, but I believe Retrolambda can convert Java 8
bytecode to run on a Java 6 JVM, as long as the code only depends on the
Java 6 standard library (which can be checked by including Animal
Sniffer in your build process).

https://github.com/luontola/retrolambda

https://www.mojohaus.org/animal-sniffer/

Cheers,
Michael

[Tatu Saloranta]

That sounds like a promising possibility, thank you for sharing.

-+ Tatu +-