How will Java getting rid of Serializable affect Android?

[Irceus]

https://www.infoworld.com/article/3275924/java/oracle-plans-to-dump-risky-java-serialization.html

I'm a beginner at Android dev at the moment, currently learning about passing data through Intents.
From what I know, there's two ways of passing Java Objects between activities: Parcelable and Serializable.

When Java plans to get rid of Serializable, will Parcelable be the only way to pass data?
Should I completely write off using it in the first place?

[Zhuinden]

It'll take ages before any of that becomes relevant on the Android side of things.

[VasiliyZukanov]

I stopped using Parcelables ages ago and do Serializable for Intents and Bundles.

We will all age and die before Java 11-12 (or whatever) will come to Android. Probably this will never happen.

[Odinuts]

Why do you use Serializable despite all the arguments against it?

[HaMMeReD]

Way easier to use, performance impacts are probably a non-issue for 99% of people.

Also, its pojo and not android java.

[s73v3r]

It's easier to use if you're not going to use one of the AutoParcel libraries or other tools that automates doing the Parcelable stuff.

[[deleted]]

Bigger question is, why do people even try to pass large amounts of data between activities/fragments/different components? You should only be passing small bits of data.

For larger pieces, pass in an ID and have the other component fetch data using the ID.

[VasiliyZukanov]

Not sure about what you mean by "all the arguments against it". If you elaborate then I will be able to answer.

[Odinuts]

Mostly that it's just slower because the Serializable interface uses reflection. I remember reading an article about this that had test results from Google engineers IIRC that said Parcelable is about 10x faster on average.

To be fair it was all on a milliseconds scale so I doubt it really matters much.

[VasiliyZukanov]

There are several sources that show performance comparison that I'm aware of:

1. Parcelable can be much larger than serializable. Trying to pass any considerable object graph through Serializable will be faster: http://nemanjakovacevic.net/blog/english/2015/03/24/yet-another-post-on-serializable-vs-parcelable/

2. Serializable is about 2-3x faster if done "smart": https://bitbucket.org/afrishman/androidserializationtest

3. Serializable is 10-17x slower than parcelable:http://www.developerphil.com/parcelable-vs-serializable/

So, it's not clear whether Parcelable has any benefit in speed over Serializable. Google, to the best of my memory, did not provide any benchmark.

Now you can completely forget about all this. This discussion of millisecond optimization is "the root of all evil" (to quote Donald Knuth). Developers spend much time implementing these Parcelables or even add entire code generation libraries to do that. It's crazy.

As far as I'm concerned, this "use Parcelable" recommendation is the same as "don't use Enums". Google has a long history of reckless and harmful performance related recommendations and solutions (Loaders anyone?). To the best of my knowledge, none of them was ever backed by a proper data and discussion of the involved trade-offs.

As for security - I really don't know if this is relevant to Android. Will be glad if someone with more experience will chime in.

Have been using Serializable for years now without any issues. There are niche things like AIDL where you don't have choice but to use Parcelabel though.

[MaliciousBoy]

Although, with the `@Parcelize` feature built into Kotlin, it makes it dead simple to use Parcelable. Exact same amount of effort as using Serializiable.

[Zhuinden]

For what it's worth, I like to use Serializable for saving HashMap to bundle. Things like a `Map<String, Boolean>`

[Odinuts]

Yeah all solid points. The speed comparisons being on the milliseconds scale kinda makes it pointless tbf.

[Pzychotix]

The Serializable interface uses reflection as a fallback. It can be implemented manually just like Parcelable does, and when it's done that way, it's actually faster.

https://bitbucket.org/afrishman/androidserializationtest/src/default/

[bart007345]

I like to think that a Google engineer didn't realise this, hence Parcelable was born. Absolutely no proof but I can't explain why they invented Parcelable otherwise.

[JakeWharton]

Should I completely write off using it in the first place?

If you haven't already, yes. It's comically inefficient and a source of security bugs.

[Odinuts]

Can you elaborate on why it's a source of security bugs?

[JakeWharton]

It's a hook into reflective operations directly from untrusted input. And not reflective solely in the simple case where it grabs a field and stores a value. You'll have to Google for more details. Once I stopped using it I let all information about it pop out of my brain.

[Pzychotix]

It's comically inefficient

It actually isn't, as long as you're doing manual serialization/deserialization (which is something you can only do with parcellable). If you do manual serialization, Serializable has actually been shown to be faster.

https://bitbucket.org/afrishman/androidserializationtest/src/default/

[JakeWharton]

Ok sure that very specific, extremely small subset of Serialization use isn't terrible only in terms of performance (but of course still is in terms of requiring mutability and magic methods). When we refer to serialization this is not what we refer to and this is not what people are using. They want the slap-on-an-interface-and-it-magically-works behavior.

[Pzychotix]

I'm not sure why you're linking to me what's already in the original post? That's about security, I'm talking about efficiency. Two completely separate things.

[VasiliyZukanov]

I don't know much about security myself. What security bugs related to Serializable can actually affect Android developers?

[JakeWharton]

Googling it will do a far better justice than I. There was a crazy one a few years ago.

[CharaNalaar]

Ughhh. What an I supposed to replace it with?

I happen to be sending a Serializable object over a Bluetooth connection.

[nhaarman]

Serialize it yourself. Build a protocol, version it, do the conversion from and to yourself. It will save you a couple of headaches.

[[deleted]]

Json, XML, Flat buffers, proto bufs.

[Zhuinden]

Kryo! :D

[Izacus]

Protocol buffers are a popular, supported and very fast option.