From pavel.rappo at gmail.com Sun Jun 8 10:46:10 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Sun, 8 Jun 2025 11:46:10 +0100 Subject: Help rebuild concurrency-interest archives Message-ID: A year ago, I was saddened to learn that the concurrency-interest mailing list broke down irreversibly [^1]. Not only did the list stop functioning, but its archives disappeared as well. The latter seemed especially sad as the list hosted many interesting, in-depth conversations over the years. Is there a way to get some of the archives back? Many concurrency-interest members, myself included, still have some of those conversations in their mailboxes. Given enough members, we could probably rebuild the archives. Maybe not completely, not in the same form, but close. The earliest email from concurrency-interest that I have in my mailbox is dated 2012-01-12 and the most recent is dated 2022-08-10. Since I've never unsubscribed from the list, we can safely say that 2022-08-10 is when the list ended. 2012 is the year I subscribed to the list, but it's not when the list started. To get an idea on when the list started I turned to "Wayback Machine", which showed me [^2] that the first archived email is dated 2002-01-30. So, the list was operational for more than 20 years! I wrote a script to download the monthly "Gzip'd Text" files. The script downloaded 168 out of 238 files. The downloaded files cover the period from 2002-January and up to and including 2016-March, except for 2015-January. So there's some overlap between what my mailbox has and what "Wayback Machine" has. In theory, combining data from my mailbox with data from "Wayback Machine" should be more than enough to rebuild the complete archives. However, I don't know if any of these two datasets have any quality, completeness or some other issues. And it's where the distributed nature of a mail list can help. I was not the only member. Some members subscribed earlier than I did. Their data might be used for cross-checking or filling in gaps. __So here's the deal.__ If you've ever been a member of concurrency-interest, reply with basic stats, such as total number of list emails you have and the time period they cover. And last but not least: consider donating to "Wayback Machine" today. Maybe your company can match your donation too? -Pavel [^1]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127856.html [^2]: https://web.archive.org/web/20220527224446/http://cs.oswego.edu/pipermail/concurrency-interest/ From pavel.rappo at gmail.com Mon Jun 16 19:34:56 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Mon, 16 Jun 2025 20:34:56 +0100 Subject: Help rebuild concurrency-interest archives In-Reply-To: References: Message-ID: It so happens that the discussion has started on another OpenJDK mailing list: https://mail.openjdk.org/pipermail/concurrency-discuss/2025-June/000015.html On Sun, Jun 8, 2025 at 11:46?AM Pavel Rappo wrote: > > A year ago, I was saddened to learn that the concurrency-interest > mailing list broke down irreversibly [^1]. Not only did the list stop > functioning, but its archives disappeared as well. The latter seemed > especially sad as the list hosted many interesting, in-depth > conversations over the years. > > Is there a way to get some of the archives back? Many > concurrency-interest members, myself included, still have some of > those conversations in their mailboxes. Given enough members, we could > probably rebuild the archives. Maybe not completely, not in the same > form, but close. > > The earliest email from concurrency-interest that I have in my mailbox > is dated 2012-01-12 and the most recent is dated 2022-08-10. Since > I've never unsubscribed from the list, we can safely say that > 2022-08-10 is when the list ended. > > 2012 is the year I subscribed to the list, but it's not when the list > started. To get an idea on when the list started I turned to "Wayback > Machine", which showed me [^2] that the first archived email is dated > 2002-01-30. So, the list was operational for more than 20 years! > > I wrote a script to download the monthly "Gzip'd Text" files. The > script downloaded 168 out of 238 files. The downloaded files cover the > period from 2002-January and up to and including 2016-March, except > for 2015-January. So there's some overlap between what my mailbox has > and what "Wayback Machine" has. > > In theory, combining data from my mailbox with data from "Wayback > Machine" should be more than enough to rebuild the complete archives. > However, I don't know if any of these two datasets have any quality, > completeness or some other issues. > > And it's where the distributed nature of a mail list can help. I was > not the only member. Some members subscribed earlier than I did. Their > data might be used for cross-checking or filling in gaps. > > __So here's the deal.__ If you've ever been a member of > concurrency-interest, reply with basic stats, such as total number of > list emails you have and the time period they cover. > > And last but not least: consider donating to "Wayback Machine" today. > Maybe your company can match your donation too? > > -Pavel > > [^1]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127856.html > [^2]: https://web.archive.org/web/20220527224446/http://cs.oswego.edu/pipermail/concurrency-interest/ From some-java-user-99206970363698485155 at vodafonemail.de Wed Jun 25 16:54:00 2025 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Wed, 25 Jun 2025 18:54:00 +0200 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke Message-ID: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> 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: From chen.l.liang at oracle.com Thu Jun 26 15:14:07 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 26 Jun 2025 15:14:07 +0000 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: 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 on behalf of some-java-user-99206970363698485155 at vodafonemail.de Sent: Wednesday, June 25, 2025 11:54 AM To: discuss at openjdk.org Cc: Alan Bateman ; Brian Goetz 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: From pavel.rappo at gmail.com Thu Jun 26 20:12:43 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Thu, 26 Jun 2025 21:12:43 +0100 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: Chen, are you being serious? On Thu 26 Jun 2025 at 16:14, Chen Liang 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 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 > *Cc:* Alan Bateman ; 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: From davidalayachew at gmail.com Fri Jun 27 05:03:53 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 27 Jun 2025 01:03:53 -0400 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: @Pavel Rappo tbf, you would need a lot of context to be able to make that connection. @Chen Liang 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 wrote: > Chen, are you being serious? > > On Thu 26 Jun 2025 at 16:14, Chen Liang 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 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 >> *Cc:* Alan Bateman ; 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: From davidalayachew at gmail.com Fri Jun 27 05:10:00 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 27 Jun 2025 01:10:00 -0400 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: 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 wrote: > @Pavel Rappo tbf, you would need a lot of context > to be able to make that connection. > > @Chen Liang 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 wrote: > >> Chen, are you being serious? >> >> On Thu 26 Jun 2025 at 16:14, Chen Liang 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 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 >>> *Cc:* Alan Bateman ; 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: From maurizio.cimadamore at oracle.com Fri Jun 27 17:14:05 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 27 Jun 2025 18:14:05 +0100 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: <1e3fc4c4-48c6-45a5-9aa8-43bae100653a@oracle.com> 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 ?tbf, you would need a lot > of context to be able to make that connection. > > @Chen Liang ?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 wrote: > > Chen, are you being serious? > > On Thu 26 Jun 2025 at 16:14, Chen Liang > 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 on behalf of > some-java-user-99206970363698485155 at vodafonemail.de > > *Sent:* Wednesday, June 25, 2025 11:54 AM > *To:* discuss at openjdk.org > *Cc:* Alan Bateman ; Brian Goetz > > *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: From ethan at mccue.dev Fri Jun 27 17:21:05 2025 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 27 Jun 2025 13:21:05 -0400 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: 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 wrote: > @Pavel Rappo tbf, you would need a lot of context > to be able to make that connection. > > @Chen Liang 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 wrote: > >> Chen, are you being serious? >> >> On Thu 26 Jun 2025 at 16:14, Chen Liang 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 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 >>> *Cc:* Alan Bateman ; 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: From ethan at mccue.dev Fri Jun 27 17:22:11 2025 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 27 Jun 2025 13:22:11 -0400 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: 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 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 > wrote: > >> @Pavel Rappo tbf, you would need a lot of >> context to be able to make that connection. >> >> @Chen Liang 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 wrote: >> >>> Chen, are you being serious? >>> >>> On Thu 26 Jun 2025 at 16:14, Chen Liang 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 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 >>>> *Cc:* Alan Bateman ; 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: From some-java-user-99206970363698485155 at vodafonemail.de Sun Jun 29 23:54:25 2025 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Mon, 30 Jun 2025 01:54:25 +0200 Subject: Explicitly mark JEP 154 / JDK-8046144 as April Fools joke In-Reply-To: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> References: <2122bb20-6fd7-4e5a-874b-069487deed43@vodafonemail.de> Message-ID: <064dc91a-3c5a-4d23-8991-ea977e610d8e@vodafonemail.de> Thanks for all your comments on this! And also thanks Chen for the information regarding the latest plans for Serialization. I generally find the JEPs to be a great source of information, also to understand the rationale for changes and to gain more insight into the background or history of Java features. Therefore my main concern with such a non-serious JEP is that it 'taints' this information source and that this incorrect information is spread. To someone not familiar with Java Serialization implementation details and its history, it might not be obvious that the information in the JEP is made up. Here are some more cases where this JEP was mentioned and where it potentially caused confusion: * https://www.reddit.com/r/java/comments/1bfg6f/comment/c96cwxd * https://www.reddit.com/r/programming/comments/8mdp1n/comment/dzmzyql * https://stackoverflow.com/a/57463104 The problem with such a 'persistent' April Fools joke which is not revealed / marked as such afterwards is that people might be reading it at any later point, e.g. now in June. And they might generally not pay much attention to the publishing date (except for the year maybe). At least Chen added a comment to JDK-8046144 now which refers to this discussion here (thanks for that!). -------------- next part -------------- An HTML attachment was scrubbed... URL: