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

[David Alayachew]

@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/f536f1dc/attachment-0001.htm>