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

Fri Jun 27 05:10:00 UTC 2025

And to address the original point of this thread -- let them have this one
lol.

It's not like there are piles of joke JEP's that make it hard to tell the
real from the fakes. And that's even moreso, considering that Serialization
is such a researched subject in Java. Plus, if there is any pain point in
Java that deserves Catharsis by comedy, it's this one lol.

On Fri, Jun 27, 2025, 1:03 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/c563c270/attachment.htm>