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

Fri Jun 27 17:22:11 UTC 2025

https://www.supremecourt.gov/DocketPDF/22/22-293/242292/20221003125252896_35295545_1-22.10.03%20-%20Novak-Parma%20-%20Onion%20Amicus%20Brief.pdf.
*

On Fri, Jun 27, 2025, 1:21 PM Ethan McCue <ethan at mccue.dev> wrote:

> 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/236ad98e/attachment-0001.htm>