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

Fri Jun 27 17:14:05 UTC 2025

IMHO the very discussion in this thread suggests that, perhaps, this JEP 
is indeed creating confusion :-)

To me, this JEP looks totally like a joke -- but now that there are more 
concrete plans to look at serialization again (as Chen noted), I defo 
see the possibility for this to be picked up more, which is not what we 
ultimately want.

Also, for those who (like me) are non-native english speaker, it could 
be sometimes more difficult to assess whether something is a joke or not.

So, while I'm all for having a laugh (and I did have more than one when 
reading this JEP), perhaps the time has come to do something about it.

Cheers
Maurizio

On 27/06/2025 06:03, David Alayachew wrote:
> @Pavel Rappo <mailto:pavel.rappo at gmail.com> tbf, you would need a lot 
> of context to be able to make that connection.
>
> @Chen Liang <mailto: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/f6789a14/attachment-0001.htm>