Explicitly mark JEP 154 / JDK-8046144 as April Fools joke

[Chen Liang]

Hello,
I don't think this is an AF joke. There is still plan to remove serialization, which is currently taking a somewhat different roadmap.

If you pay attention to conferences like JavaOne, you should have noticed that Viktor Klang is working on Marshalling. There is already "Serailzation - A New Hope" from Devoxx 2024 available on YouTube Java channel, and in the upcoming JVMLS there will be a "Marshalling: Serialization 2.0" talk as well, both of which can provide you with more details. The problem with JEP 154 was this JEP did not provide a replacement mechanism for serialization, so we plan to resume the process of removing serialization once Marshalling is available. During this time, we plan to make minimal changes to serialization, mostly just the most critical fixes, to reduce maintenance burden.

For the concerns you list, I believe at least two of them are not valid:

  1.
Antivirus program scans do affect program execution speed significantly; for example, this is especially obvious for building the JDK on Windows. I thought this was written in the OpenJDK guides or documents but apparently it isn't. If a program retries an action based on a fixed timeout, the scenario described in the JEP can happen.
  2.
Building two copies of classes is a valid approach for JDK distributions. For instance, when compact object headers are made no longer experimental, the JDK image, at least that provided by Oracle, comes with two copies of CDS archives - one with no compact object headers, and another with that enabled. In project Valhalla, we are already distributing value classes for JEP 401 the same way - one copy for when the runtime is running with no preview feature enabled, and another with value classes for when the runtime has preview features enabled.

Regards,
Chen Liang
________________________________
From: discuss <discuss-retn at openjdk.org> on behalf of some-java-user-99206970363698485155 at vodafonemail.de <some-java-user-99206970363698485155 at vodafonemail.de>
Sent: Wednesday, June 25, 2025 11:54 AM
To: discuss at openjdk.org <discuss at openjdk.org>
Cc: Alan Bateman <alan.bateman at oracle.com>; Brian Goetz <brian.goetz at oracle.com>
Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke


Hello,

it seems JEP 154 / JDK-8046144 "Remove Serialization" is an April Fools joke:

  *   It was created on 2012/04/01 20:00
  *   It says "severely-degraded environments, e.g., Microsoft Windows machines running the McAfee Antivirus program"
I doubt that in any official document the JDK maintainers would dare writing this, and even in this April Fools JEP it seems risky.
  *   It says "available values for serialVersionUID are running out"
To my knowledge the serialVersionUID value is per class, so this seems to be made up (at least to some extent).
  *   As solution it suggests "build two copies of rt.jar"
  *   Under "Impact" it says "Twitter: High"


The main problem is that it is not immediately obvious that this is an April Fools joke, because it appears as regular JEP within the list of other legit JEPs and there is no explicit mention of it being an April Fools joke. The JEP also sounds plausible to some extent because there are multiple real flaws with Java Serialization.

This has lead to this JEP being referenced (unironically) in real discussions and also recently in a scientific paper, https://arxiv.org/abs/2504.20485.
It could also harm future discussions about removing or refactoring Java Serialization in case it is used as argument that this had already been rejected in the past.

Therefore to avoid any further harm / confusion by this JEP, please:

  *   Change JEP 154 to clearly indicate that it is an April Fools joke; ideally by prepending its title with something like "April Fools"
  *   Change JDK-8046144 in a similar way
  *   Do not delete either of them; it might only cause more confusion [1]


Kind regards


[1] See also JEP 187 and https://marxsoftware.blogspot.com/2021/09/missing-jeps-145-187.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20250626/cf60a41f/attachment-0001.htm>