New candidate JEP: 415: Context-Specific Deserialization Filters

Roger Riggs roger.riggs at
Fri May 7 21:30:30 UTC 2021

Hi Peter,

Point noted, but does not address existing production apps dependent on 
We've been encouraging developers to use other serialization mechanisms 
for years.

As of JDK 9, JEP 290 can specify a filter on the command line to reject 
all classes.

  ...  "-Djdk.serialFilter=!*" ...

Regards, Roger

On 5/6/21 8:44 PM, Peter Firmstone wrote:
> While I'm not against such a thing, it indicates increasing complexity 
> in the game of de-serialization whack-a-mole.
> It also suggests people are using Java Serialization to process 
> un-trusted data.
> I think that Serialization Filter's are a design mistake, we should 
> just enable the existing Java Serialization to be turned off 
> completely.  The time spent writing these things should be spent 
> implementing new Serialization API's.
> A property or command line argument that cannot be changed at runtime 
> to switch off Java Serialization would be appreciated.
> A new public API for Serialization which includes Object level input 
> validation and failure atomicity needs to be designed that is suitable 
> for use with many Serialization protocols.
> Serialization is a public interface, we should start declaring it as 
> such.

More information about the jdk-dev mailing list