Record types are broken on Android when using R8

[HelloOO7]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

When using Jackson along with the Android record support module, processing of record types fails when R8 (Android's code minifier) is used.

The real cause behind this problem lies not within Jackson, but is a consequence of the fact that R8 will rename all occurences of "java.lang.Record" to "com.android.tools.r8.RecordTag" when minification is enabled (for some reason, it does not happen when it is off - in that case everything works fine).

However, Jackson's ClassUtil.isRecordType detects whether a class is or is not a record by comparing the class name (which R8 replaces), thus erroneously deeming an Android record to be a Java record, which it is, in fact, not. Subsequently, an exception is thrown in JDK14Util when it tries to access Record-related methods on java.lang.Class, which are not present on Android.

I came up with a workaround of using "java.lang.Record".equals(parent.getName()) && !"com.android.tools.r8.RecordTag".equals(parent.getName()), which will always evaluate to false on Android. But given that Jackson by itself isn't Android-focused, I'm not sure if that is a proper solution. Perhaps calling class.isRecord() via reflection (and returning false if the method does not exist) would be better?

Version Information

2.19.0

Reproduction

1. Create a record in an Android project and compile it with R8/Proguard enabled.
2. Attempt to deserialize the record using Jackson.
3. An exception Failed to access Methods needed to support java.lang.Record: (java.lang.NoSuchMethodException) getRecordComponents [] will be thrown.

Expected behavior

Jackson should not consider records on Android to be actual Java records, even if R8 manipulates the class name strings.

Additional context

No response

[pjfanning]

Can't you contact Android R8 team to see if there is a way to turn off minification of Records?
jackson-databind is a Java lib. We don't want to end up with lots of Android specific workarounds.
We have zero Android test coverage and I don't see any plan for us to create Android specific testing.

[pjfanning]

It may be feasible to adjust ClassUtil.isRecord to make it return false for com.android.tools.r8.RecordTag but the real issue is that we don't have Android enabled test coverage to make sure that it works as expected and that it continues to work as expected in future.

[pjfanning]

All that I know of is this wiki page - https://github.com/FasterXML/jackson-docs/wiki/JacksonOnAndroid

If anyone can suggest improvements to that wiki, it would be appreciated.

[HelloOO7]

Can't you contact Android R8 team to see if there is a way to turn off minification of Records

Possibly, but barring the fact that it would probably be resolved no sooner than in a matter of months, the Record processing in R8/D8 is a rather hardcoded matter and there are probably already a lot of cases that rely on the current behavior (which is, as far as Proguard goes, "correct").

It may be feasible to adjust ClassUtil.isRecord to make it return false for com.android.tools.r8.RecordTag but the real issue is that we don't have Android enabled test coverage

That's fair. I agree that having Android-specific code in jackson-databind is not a great solution. What is the rationale behind checking for records using the class name? Would there be a way to use Java's isRecord instead? As far as I know, that would fix this problem and still be transparent implementation-wise.

[pjfanning]

I think isRecord is written the current way so that the code can compiled with Java 8 and 11 (which don't have the Record class).
I wonder if Jackson-Databind should try to support Multi-Release jar format so that we can have Java 17+ specific code?
https://www.baeldung.com/java-multi-release-jar

[HelloOO7]

That could be alleviated by calling the method via Reflection. If the method does not exist, then records are simply not supported (so it can return false), and if it does, then "isRecord" returns whether the class is an actual Java record. IIRC this is the way JDK14Util works.

That is not to say it's the end of all problems, as starting with Android U, the isRecord method is present in Android as well (see https://issuetracker.google.com/issues/293569157). At the moment, it should not break anything, as it does not return true for R8'd records, but not sure yet what will happen once these methods are implemented properly. I would not consider this to be an issue at the present time though.

[pjfanning]

tools.jackson.core:jackson-databind 3.0.0-rc5 only supports Java 17+ - so it already uses the Class#isRecord method.

[HelloOO7]

Realistically, we're not going to be targeting Android apps to Android 14 for the next couple of years, so I'm not very optimistic about being able to use Jackson 3.x on Android to be honest.

Any chance this could be done in 2.x? I could work on a PR for that if needed, provided that the Reflection approach would be acceptable.

[pjfanning]

I'm working on a Jackson 2 PR.

[pjfanning]

@HelloOO7 do you think #5195 would solve your issue?

[HelloOO7]

Not entirely - it would only solve it on Android 14 and up, which have the isRecord method.

You mention that isRecord was added in JDK 16 - is that really so? It was part of the original JEP, so I would expect it to be present in JDK 14 as a preview feature as well. OpenJDK sources would confirm that: https://github.com/openjdk/jdk14/blob/abc56193174dd6a11a8453bd5036fc8618ecca61/src/java.base/share/classes/java/lang/Class.java#L3632

If it were possible to use isRecord universally (without the fallback, i. e. always returning false if isRecord is not available), then it would solve this issue.

[pjfanning]

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L3380-L3382 says Java16 - maybe Java14 had it only enabled if you enabled preview. See the annotations in the Java 14 code.

I don't really mind throwing Java 14 and 15 users under the bus. So I will remove the fallback.

[HelloOO7]

maybe Java14 had it only enabled if you enabled preview

Indeed, but that should not be an issue, as preview-compiled classes will not run under JVMs without enabled preview features.

If you'd like, I can test your branch on my Android setup.