On Wed, Dec 4, 2019 at 2:36 AM Michael Rogers <mich...@briarproject.org> wrote: > > The situation on Android is that unfortunately we still need to maintain > compatibility with the Java 6 API to support Android 6 and older (about > half of currently active devices). Java 8 language features are OK - the > Android toolchain transforms them into Java 6-compatible bytecode. > > So from my point of view it would be nice if a supported version of > Jackson was compatible with the Java 6 API for a few more years. > > Animal Sniffer can be used to check API compatibility at build time.
Interesting. One thing that I am missing, unfortunately, is a regression test suite that could detect cases where post-JDK6 API was being used. It would be great if there was a profile for Travis (for example), to test this out. I do get bug reports for regressions, but those are after-the-fact (i.e. when a version has broken compatibility). -+ Tatu +- > > Cheers, > Michael > > On 21/11/2019 18:53, Marshall Pierce wrote: > > I think anyone who's current enough to be on recent Jackson is going to > > be on at least Java 8. I see pretty widespread Java 8 minimums on > > libraries these days, so I think 2.11 is fine as long as you're OK with > > 2.10 being the LTS one. > > > > That said, I'm mercifully not working in Android for a long time so I > > don't know what their situation is; maybe everyone just uses org.json > > there ;) > > > > On 11/21/19 11:31 AM, Tatu Saloranta wrote: > >> Ok, time to bring this up again. > >> > >> So. Currently jackson-databind 2.10 may be run on JDK 7 (*). Other > >> components differ in that jackson-annotations and jackson-core run on > >> JDK 6, and some modules need JDK8 (Java 8 obviously, but some > >> dataformats have deps that need Java 8 as well). > >> > >> Jackson 3.0 (master) requires JDK 8 already; but since it is in > >> development, target JDK can be re-considered at some point. > >> > >> But. Would it make sense to upgrade baseline JDK 8 requirement for > >> `jackson-databind`? Doing this would mostly matter (IMO) in that doing > >> that would allow use of closures (method pointers) for API / > >> configuration. There would be some other smaller benefits, like > >> directly including `Optional` support, constructor name parameter > >> access. > >> > >> If we were to move the baseline, this could happen as early as 2.11 > >> (probably due in Jan 2020), or if not, following that in 2.12. > >> Whatever version predating this version would also become "long-term > >> supported" Jackson version, i.e. be patched longer than usual, to > >> support use cases where going Java 8 is not possible > >> > >> But first I would like to know of users, if any, that use Jackson on > >> pre-Java8 platforms (or platforms where full JDK 8 based version would > >> not work). > >> > >> So: concerns, comments, suggestions? > >> > >> -+ Tatu +- > >> > >> (*) there are occasionally reported issues wrt whether it truly works > >> on some of sorta-J2SE platforms, like Android, but aside from those > >> > > > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/60029ccb-fc02-0ded-a15d-351462ffb133%40briarproject.org. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAL4a10iepJ6bxWM%2Bq8moZo6%3Dq%3D%2BtMKuBByqq2_Wtyp1CGS5KMg%40mail.gmail.com.
