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

[Pavel Rappo]

Chen, are you being serious?

On Thu 26 Jun 2025 at 16:14, Chen Liang <chen.l.liang at oracle.com> wrote:

> 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/ea1e966a/attachment.htm>