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

[Ethan McCue]

More than a joke it's satire. Satire does not work with a big "this is a
joke" label.

https://www.supremecourt.gov/DocketPDF/22/22-293/242292/20221003125252896_35295545_1-22.10.03

On Fri, Jun 27, 2025, 1:09 AM David Alayachew <davidalayachew at gmail.com>
wrote:

> @Pavel Rappo <pavel.rappo at gmail.com> tbf, you would need a lot of context
> to be able to make that connection.
>
> @Chen Liang <chen.l.liang at oracle.com> there is a 1000000% chance that the
> JEP in question is being made, at least partially, as a joke. I interpreted
> it as someone with a sense of humor communicating valid points (and at
> least 1 joke point) in a real JEP, but phrasing things in such a way to get
> some laughs because it was April Fool's Day. Stuff like "Twitter: High" and
> "running out of serialVersionUid's" help reveal the joke. The idea of a
> command line utility requiring the ability to phone home in order to
> properly function as a glorified int-generator is pretty wild. 2 instances
> of serialVersionUid need to be unique per class. But after that, the actual
> value doesn't really matter. So, even though I know nothing about
> serialVersionUid past what a junior dev would know, that quote got a laugh
> out of me - which is (I think) its point.
>
>
> On Thu, Jun 26, 2025, 9:33 PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>
>> 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/20250627/5ee00326/attachment.htm>