Sending ZonedDateTime through Intent loses tz info if Proguard is enabled

[reisub]

Here is a minimal project to reproduce the issue:
https://github.com/reisub/ZonedDateTimeProguardBug

After fiddling with proguard for the last hour and half - I only know that this will definitely fix it:

-keep class org.threeten.bp.** { *; }

.. but that keeps the whole library from being obfuscated. Proguard is pain.

[JakeWharton]

We can enable ProGuard on the sample and round-trip through a Parcel to ensure that rules (which we can embed in the library) retain the necessary info. I don't have time to work on this right now, unfortunately.

[dbarwacz]

Is this still an issue? We are adding this library and would probably need it fixed so I can create PR if that's still an open and broken.

[marcelpinto]

We are getting crashes in production version when parcelling a class that uses LocalDateTime

Fatal Exception: java.lang.ClassCastException: org.threeten.bp.n cannot be cast to org.threeten.bp.LocalDateTime at com.mypackage.MyTimeClass$NotNow$Creator.createFromParcel(Unknown Source:11)

Adding the rule @reisub mentions works, although is quite drastic to keep all the library. I tried to add rule by rule depending on the classes that LocalDateTime uses but seems not to work.

[JakeWharton]

That overly keepy rule isn't needed, but you might need to keep the names of the types in the library if they're Serializable?

…

On Tue, Jan 8, 2019, 9:33 PM Marcel Pintó Biescas ***@***.*** wrote: We are getting crashes in production version when parcelling a class that uses LocalDateTime Fatal Exception: java.lang.ClassCastException: org.threeten.bp.n cannot be cast to org.threeten.bp.LocalDateTime at com.mypackage.MyTimeClass$NotNow$Creator.createFromParcel(Unknown Source:11) Adding the rule @reisub <https://github.com/reisub> mentions works, although is quite drastic to keep all the library. I tried to add rule by rule depending on the classes that LocalDateTime uses but seems not to work. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEf1_CdbAQjJevnVbIxVW_tKzulI8ks5vBVTdgaJpZM4LR1kA> .

[marcelpinto]

That overly keepy rule isn't needed, but you might need to keep the names of the types in the library if they're Serializable?
…
On Tue, Jan 8, 2019, 9:33 PM Marcel Pintó Biescas @.*** wrote: We are getting crashes in production version when parcelling a class that uses LocalDateTime Fatal Exception: java.lang.ClassCastException: org.threeten.bp.n cannot be cast to org.threeten.bp.LocalDateTime at com.mypackage.MyTimeClass$NotNow$Creator.createFromParcel(Unknown Source:11) Adding the rule @reisub https://github.com/reisub mentions works, although is quite drastic to keep all the library. I tried to add rule by rule depending on the classes that LocalDateTime uses but seems not to work. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEf1_CdbAQjJevnVbIxVW_tKzulI8ks5vBVTdgaJpZM4LR1kA .

I tried keeping all names from the library but still does not work. Maybe I am missing sth...

[JakeWharton]

I would have to dig into the serialization code of ThreeTenBP to see what the problem is. It seems like maybe obfuscation and parts of the serialization code being removed is the problem? On Tue, Jan 8, 2019 at 10:30 PM Marcel Pintó Biescas < notifications@github.com> wrote:

…

That overly keepy rule isn't needed, but you might need to keep the names of the types in the library if they're Serializable? … <#m_6461187954387494611_> On Tue, Jan 8, 2019, 9:33 PM Marcel Pintó Biescas ***@***.*** wrote: We are getting crashes in production version when parcelling a class that uses LocalDateTime Fatal Exception: java.lang.ClassCastException: org.threeten.bp.n cannot be cast to org.threeten.bp.LocalDateTime at com.mypackage.MyTimeClass$NotNow$Creator.createFromParcel(Unknown Source:11) Adding the rule @reisub <https://github.com/reisub> https://github.com/reisub mentions works, although is quite drastic to keep all the library. I tried to add rule by rule depending on the classes that LocalDateTime uses but seems not to work. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment) <#44 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEf1_CdbAQjJevnVbIxVW_tKzulI8ks5vBVTdgaJpZM4LR1kA . I tried keeping all names from the library but still does not work. Maybe I am missing sth... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEES5ereXDIESyV9s4LcFX_Xikjgm3ks5vBWJbgaJpZM4LR1kA> .

[drewhamilton]

Looked into this and found that ProGuard's website has an example for keeping all methods related to processing Serializables:

-keepclassmembers class * implements java.io.Serializable {
    private static final java.io.ObjectStreamField[] serialPersistentFields;
    private void writeObject(java.io.ObjectOutputStream);
    private void readObject(java.io.ObjectInputStream);
    java.lang.Object writeReplace();
    java.lang.Object readResolve();
}

Applying this to @reisub's example repo appears to solve the issue. Is this sufficiently... not overly keepy?

[JakeWharton]

That looks fine, yes. If that's the issue, we can actually ship those rules in the AAR with the wildcard scoped specifically to `org.threetenbp.*`

…

On Wed, Mar 13, 2019 at 5:18 PM Drew Hamilton ***@***.***> wrote: Looked into this and found that ProGuard's website has an example <https://www.guardsquare.com/en/products/proguard/manual/examples#serializable> for keeping all methods related to processing Serializables: -keepclassmembers class * implements java.io.Serializable { private static final java.io.ObjectStreamField[] serialPersistentFields; private void writeObject(java.io.ObjectOutputStream); private void readObject(java.io.ObjectInputStream); java.lang.Object writeReplace(); java.lang.Object readResolve(); } Applying this to @reisub <https://github.com/reisub>'s example repo appears to solve the issue. Is this sufficiently... not overly keepy? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEaNvP7QE7ojj2pAGfvZL3Ys7xuKsks5vWWs8gaJpZM4LR1kA> .

[drewhamilton]

Cool, I'll try to put up a PR with that + related tests soon.

[drewhamilton]

Bump: This is fixed by #102.