Mark Reinhold has told attendees of the DevoxxUK conference that Oracle does have a long term goal to remove serialization from the language, but just when is less clear.

Answering a question in a session called 'Ask the Architect', Reinhold, chief architect of the Java platform group at Oracle, said:

"Serialization was a horrible mistake in 1997. Some of us tried to fight it, but it went in"

He said the development team call serialization the gift that keeps on giving in terms of vulnerabilities, and that while he didn't have the exact stats to hand:

"at least a third of all the Java vulnerabilities have involved serialization, it could be over half. Its an astonishingly fecund source of vulnerabilities, not to mention instabilities"

Java object serialization means to convert the state of an object to a byte stream so that the byte stream can be reverted back into a copy of the object. It can also be used to reconstruct an object graph from a stream.

The question was asked in a session at DevoxxUK, along with other searching questions about Java, its features and the future:

Reinhold said that the goal is definitely to get rid of serialization in the long term. In the meantime Oracle has taken measures to make it possible to use serialization more safely. They've added a filtering capability, so that if you're using serialization on a network and have to accept untrustable serialization data streams, you have a way to filter what classes they mention, so you can at least try to defend yourself.

Reinhold continued:

"we definitely have do something about it. Serialization is brittle, it pokes into private field, violates constructor invariance, it's horrible in so many ways. The only thing that's appealing about it is that it's simple to use in simple use cases".

He also said that taking out this is very much a long term plan and goal. It's part of Project Amber, which the OpenJDK group says has the goal of exploring and incubating smaller, productivity-oriented Java language features, including lambda leftovers,pattern matching, local-variable syntax for lambda parameters, switch expressions, and raw string literals. Reinhold said:

"Once we have records, the Java version of data classes, then it's part of the long term vision to have a new small clean serialization framework in the platform that can take a graph of records. You'll then be able to plug in a serialization engine of your choice, whether you want JSON, XML, or YAML, you can plug in the engine to get the format you want, and serialize records in a very safe way because the records wouldn't allow serialization invariance."

However, Reinhold says that there's no point asking him which release the change is going to happen in, because he doesn't know. For now, the advice is that if you're going to use serialization, it's more or less acceptable if you're doing it in a closed way and you know where the streams are coming from. In general, though, you're better off using JSON or XML or something else. Reinhold's other session at DevoxxUK on "Java in 2018: Change is the Only Constant" is also worth watching. Reinhold discusses the three main changes to Java made this year - platform modularization, component removal, and the accelerated pace of new releases - and how this affects developers.