From magnus.ihse.bursie at oracle.com Thu Apr 1 08:18:11 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Apr 2021 10:18:11 +0200 Subject: Announcement: Skara update to support CVS and SourceForge Message-ID: <6acde917-7014-5ed7-222d-391cd0cd4ba9@oracle.com> The Skara team is proud to present the latest additions to the Skara tooling, support for the CVS revision system and the SourceForge code repository and developer hub. This recently added support to the Skara tooling will allow us to aggressively push a conversion away from the johnny-come-lately "git" version system, to the trusty and well-understood CVS. Abandoning this dependency of git will consequently allow us to leave the controversial GitHub provider, and instead relying on SourceForge, the developer central with the longest and richest history in source collaboration on Internet. Starting today, all OpenJDK project repos will be available at their new home on SourceForge[1]. The initiative presented today will allow us to shut down the OpenJDK presence on GitHub completely a year after this, on April 1, 2022. About CVS CVS is a revolutionary revision control system, which allow concurrent usage from multiple, independent developers. The ability to host CVS on a remote server has made it extremely popular for development projects which has run into scalability issues with local RCS, or RCS over NFS. CVS also introduces the concept of a "branch", which allows for a single repository to contain multiple, independent versions of a software product to be developed, in parallel. About SourceForge SourceForge is the leading center of software development on Internet. It has jump-started from obscurity to being "the place to be" for all open source developers. With it's modern suite of collaboration tools, including online accessible SVN repositories, per-project mailing lists, and an option to use the new secure "https" protocol, it offers world-class support to make any open source project a success. /Magnus [1] http://sourceforge.net/projects/ohnojdk/ From forax at univ-mlv.fr Thu Apr 1 08:55:02 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 1 Apr 2021 10:55:02 +0200 (CEST) Subject: Announcement: Skara update to support CVS and SourceForge In-Reply-To: <6acde917-7014-5ed7-222d-391cd0cd4ba9@oracle.com> References: <6acde917-7014-5ed7-222d-391cd0cd4ba9@oracle.com> Message-ID: <1700577606.228646.1617267302978.JavaMail.zimbra@u-pem.fr> Hi Magnus, at last ! We can now say that the OpenJDK is pulling forward. Is there a SCCS addon somewhere, because it will be hard for me to migrate otherwise ? R?mi ----- Mail original ----- > De: "Magnus Ihse Bursie" > ?: "announce" > Cc: skara-dev at openjdk.java.net, "jdk-dev" > Envoy?: Jeudi 1 Avril 2021 10:18:11 > Objet: Announcement: Skara update to support CVS and SourceForge > The Skara team is proud to present the latest additions to the Skara > tooling, support for the CVS revision system and the SourceForge code > repository and developer hub. > > This recently added support to the Skara tooling will allow us to > aggressively push a conversion away from the johnny-come-lately "git" > version system, to the trusty and well-understood CVS. Abandoning this > dependency of git will consequently allow us to leave the controversial > GitHub provider, and instead relying on SourceForge, the developer > central with the longest and richest history in source collaboration on > Internet. > > Starting today, all OpenJDK project repos will be available at their new > home on SourceForge[1]. The initiative presented today will allow us to > shut down the OpenJDK presence on GitHub completely a year after this, > on April 1, 2022. > > About CVS > > CVS is a revolutionary revision control system, which allow concurrent > usage from multiple, independent developers. The ability to host CVS on > a remote server has made it extremely popular for development projects > which has run into scalability issues with local RCS, or RCS over NFS. > CVS also introduces the concept of a "branch", which allows for a single > repository to contain multiple, independent versions of a software > product to be developed, in parallel. > > About SourceForge > > SourceForge is the leading center of software development on Internet. > It has jump-started from obscurity to being "the place to be" for all > open source developers. With it's modern suite of collaboration tools, > including online accessible SVN repositories, per-project mailing lists, > and an option to use the new secure "https" protocol, it offers > world-class support to make any open source project a success. > > /Magnus > > [1] http://sourceforge.net/projects/ohnojdk/ From john.r.rose at oracle.com Thu Apr 1 09:23:05 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Apr 2021 09:23:05 +0000 Subject: Announcement: Skara update to support CVS and SourceForge In-Reply-To: <1700577606.228646.1617267302978.JavaMail.zimbra@u-pem.fr> References: <6acde917-7014-5ed7-222d-391cd0cd4ba9@oracle.com> <1700577606.228646.1617267302978.JavaMail.zimbra@u-pem.fr> Message-ID: On Apr 1, 2021, at 1:55 AM, Remi Forax wrote: > > Hi Magnus, > at last ! > We can now say that the OpenJDK is pulling forward. > > Is there a SCCS addon somewhere, because it will be hard for me to migrate otherwise ? > > R?mi No, Remi, there is no SCCS view, because RCS is superior. RCS uses backward deltas, as any reasonable versioning scheme must, because deriving the current version of a file must be faster than deriving a historic version. SCCS is wrong-headedly out of step with history, because it uses forward deltas, and thus requires the CPU-wasting recapitulation of the entire history of a file in order to materialize its most recent version. Thus, SCCS is almost as dumb as a loser-system which which would store bit-images of *every* version of a file, and then (magically, as if it were possible) would retrieve those bit images on demand by some sort of magic name. Hah, as if one could build some sort of interplanetary file system (they?d call it ?IPFS?, the losers) that just shared files by *wishing* for them! ? John P.S. I once wrote an SCCS ingester in Java, when HotSpot was stored in SCCS. I lost it. True facts, those. From forax at univ-mlv.fr Thu Apr 1 12:54:09 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 1 Apr 2021 14:54:09 +0200 (CEST) Subject: Announcement: Skara update to support CVS and SourceForge In-Reply-To: References: <6acde917-7014-5ed7-222d-391cd0cd4ba9@oracle.com> <1700577606.228646.1617267302978.JavaMail.zimbra@u-pem.fr> Message-ID: <2016212511.704375.1617281648999.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "Remi Forax" > Cc: "Magnus Ihse Bursie" , "announce" , "skara-dev" > , "jdk-dev" > Envoy?: Jeudi 1 Avril 2021 11:23:05 > Objet: Re: Announcement: Skara update to support CVS and SourceForge > On Apr 1, 2021, at 1:55 AM, Remi Forax wrote: >> >> Hi Magnus, >> at last ! >> We can now say that the OpenJDK is pulling forward. >> >> Is there a SCCS addon somewhere, because it will be hard for me to migrate >> otherwise ? >> >> R?mi > > No, Remi, there is no SCCS view, because RCS is superior. > > RCS uses backward deltas, as any reasonable versioning > scheme must, because deriving the current version of > a file must be faster than deriving a historic version. > SCCS is wrong-headedly out of step with history, > because it uses forward deltas, and thus requires > the CPU-wasting recapitulation of the entire history > of a file in order to materialize its most recent version. For me, RCS, CVS, SVN and Git are the losers, because they are thinking in term of how beautiful and fast their internal data structures are instead of term of user model, a versioned code is a graph of patches, at least with SCCS, you have a list of patches, that's why SCCS is far better than any other SCMs. As a users, i don't care about git rerere being fast, i want to see a graph of patches and be able to bubble them up/down/"on the side" so i don't need git rerere. While i get why Linus Torvald wants each commit to have a SHA for the linux kernel, in practice, it means that i can not swap two patches easily, why the tree of software versions (where you need SHA) and the graph of patches has to be the very same data structure ? > > Thus, SCCS is almost as dumb as a loser-system which > which would store bit-images of *every* version of a file, > and then (magically, as if it were possible) would retrieve > those bit images on demand by some sort of magic > name. Hah, as if one could build some sort of > interplanetary file system (they?d call it ?IPFS?, > the losers) that just shared files by *wishing* > for them! > > ? John > > P.S. I once wrote an SCCS ingester in Java, > when HotSpot was stored in SCCS. I lost it. > True facts, those. R?mi From ebresie at gmail.com Fri Apr 2 17:12:42 2021 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 2 Apr 2021 12:12:42 -0500 Subject: Package Aliases Message-ID: <2538b7f6-1344-4506-8f0d-f02c6ae91a6e@Erics-iPhone-12-Pro-Max> I?m not sure if this is viable or valuable but thought I would ask the experts. With the recent discussion on sun namespaces regarding ?JEP: 408: Simple Web Server? this got me wondering if it?s worth the concept of a package namespace ?alias? or link to another to another package to ease migration when changing package names. The use case would mainly be when for a given package, ownership or transition from one organization to another allowing a way to have a new package name. Maybe add an ?alias? keyword with an alternative name which would allow usage of either alias or real package name from external package usage. Assuming there could be a risk of security concerns of having an alias to a malicious package name some that might also have to be considered. With module naming, I?m not sure if this would sort of be possible in this context but thought I would put it out to see. Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) From kariyam at oss.nttdata.com Sun Apr 4 08:31:09 2021 From: kariyam at oss.nttdata.com (kariyam) Date: Sun, 04 Apr 2021 17:31:09 +0900 Subject: *Address.hashCode ignore the upper 32 bits of a long value Message-ID: <9611e414ab996d463c07e17867252980@oss.nttdata.com> Hi, I found that sun.jvm.hotspot.debugger.*.*Address.hashCode ignore the upper 32 bits of a long value. e.g. https://github.com/openjdk/jdk/blob/3789983e89c9de252ef546a1b98a732a7d066650/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java#L56 I don't think the upper 32 bits of a long value should be ignored. IMHO, the Long.hashCode static method is suitable for such cases. If it's worth making this change, could anyone submit this issue to JBS? I'm ready to submit a pull request, but I don't have an Author role. Please let me know if there is a better place to do so. Thanks From pavel.rappo at oracle.com Sun Apr 4 10:50:45 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sun, 4 Apr 2021 10:50:45 +0000 Subject: *Address.hashCode ignore the upper 32 bits of a long value In-Reply-To: <9611e414ab996d463c07e17867252980@oss.nttdata.com> References: <9611e414ab996d463c07e17867252980@oss.nttdata.com> Message-ID: <6D1AB0C4-C6A6-470D-AB4F-DE3F488A7B99@oracle.com> A better place for this email might be the serviceability-dev mailing list (CC'ed). > On 4 Apr 2021, at 09:31, kariyam wrote: > > Hi, > > I found that sun.jvm.hotspot.debugger.*.*Address.hashCode ignore the upper 32 bits of a long value. > > e.g. https://github.com/openjdk/jdk/blob/3789983e89c9de252ef546a1b98a732a7d066650/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java#L56 > > I don't think the upper 32 bits of a long value should be ignored. > IMHO, the Long.hashCode static method is suitable for such cases. > > If it's worth making this change, could anyone submit this issue to JBS? > > I'm ready to submit a pull request, but I don't have an Author role. > > Please let me know if there is a better place to do so. > > Thanks From dalibor.topic at oracle.com Mon Apr 5 13:28:02 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 5 Apr 2021 15:28:02 +0200 Subject: Package Aliases In-Reply-To: <2538b7f6-1344-4506-8f0d-f02c6ae91a6e@Erics-iPhone-12-Pro-Max> References: <2538b7f6-1344-4506-8f0d-f02c6ae91a6e@Erics-iPhone-12-Pro-Max> Message-ID: <94f06e9c-4cad-21d9-6178-1c251ea16388@oracle.com> On 02.04.2021 19:12, Eric Bresie wrote: > I?m not sure if this is viable or valuable but thought I would ask the experts. > > With the recent discussion on sun namespaces regarding ?JEP: 408: Simple Web Server? this got me wondering if it?s worth the concept of a package namespace ?alias? or link to another to another package to ease migration when changing package names. That could become complicated quite quickly. Consider a security policy that provides access permissions based on a fully qualified package name. Does the permission still work with the aliased name? Should it even, despite its authors asking for something else? Sometimes the reason for changing names is to reset backwards compatibility constrains and expectations. Aliasing would not help with that use case, since the new namespace would then have to evolve in lockstep with the old one for it to work, and that would not be the desired outcome. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From orionllmain at gmail.com Mon Apr 5 15:09:15 2021 From: orionllmain at gmail.com (Zheka Kozlov) Date: Mon, 5 Apr 2021 22:09:15 +0700 Subject: New candidate JEP: 408: Simple Web Server In-Reply-To: References: <20210329191606.929913DDF64@eggemoggin.niobe.net> Message-ID: Can we put at least new classes to some java.* package (SimpleFileServer, HttpHandlers, Request)? For example, java.net.httpserver. ??, 30 ???. 2021 ?. ? 20:14, Julia Boes : > Hi Krzysztof, > > Is there a plan to change the package name? > I always thought that com.sun.* package was for old internal code and I > assume I'm not the only one. > > the simple server builds on the existing API in the com.sun.net.httpserver > package, which was added in JDK 1.6. At that time, the convention for > JDK-specific APIs was to use the com.sun namespace. Other examples are > com.sun.nio.sctp or com.sun.security.ntlm. In more recent times, this > convention has been replaced with the jdk namespace. Both name spaces are > JDK-specific, as such the simple server API is a supported JDK API. > > Given that we're simply building on top of the long-standing API in > com.sun.net.httpserver, revisiting the package name is out of the scope of > this project. > > Regards, > Julia > From mark.yagnatinsky at barclays.com Thu Apr 1 20:49:55 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Thu, 1 Apr 2021 20:49:55 +0000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal Message-ID: Not sure what the proper etiquette for this list is, hope someone will tell me if I'm breaking any rules. I'd like to make an argument against deprecating the applet API for removal. Namely, it used to be a common practice to write Swing apps in such a way that they can run either as an applet, or as a desktop application. There are thus all sorts of nice little jars floating around the web, which remain perfectly usable as desktop applications today, but would suddenly stop working on newer JDKs because they happen to have the magic words "extends Applet". (For instance, this one I've used personally that would probably break: http://www.science.smith.edu/~jorourke/books/CompGeom/CompGeom.html) These are often un-maintained so it's probably unrealistic to expect all of them to be "fixed". Thus I propose that rather than removing the API's outright, one of the following options can be taken: Option 1: do nothing: keep applets deprecated, but not for removal, and eventually stop testing or maintaining the relevant code. Option 2: remove the bulk of the implementation, leaving just enough so that code that mentions the applet AIP can compile and run successfully. This is a little bit tricky, in that you have to figure out what counts as a "workable stub". For instance, the applet constructor can't be changed to unconditionally throw an exception since the "extends Applet" trick mentioned above results in calling that constructor even when running as a desktop app. That's my two cents. Thanks, Mark. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From kariyam at oss.nttdata.com Sun Apr 4 16:38:50 2021 From: kariyam at oss.nttdata.com (Mitsuru Kariya) Date: Mon, 05 Apr 2021 01:38:50 +0900 Subject: *Address.hashCode ignore the upper 32 bits of a long value In-Reply-To: <6D1AB0C4-C6A6-470D-AB4F-DE3F488A7B99@oracle.com> References: <9611e414ab996d463c07e17867252980@oss.nttdata.com> <6D1AB0C4-C6A6-470D-AB4F-DE3F488A7B99@oracle.com> Message-ID: <0722133b150866bb147f4ec353323878@oss.nttdata.com> Thank you for your advice. I subscribed serviceability-dev mailing list. 2021-04-04 19:50 ? Pavel Rappo ????????: > A better place for this email might be the serviceability-dev mailing > list (CC'ed). > >> On 4 Apr 2021, at 09:31, kariyam wrote: >> >> Hi, >> >> I found that sun.jvm.hotspot.debugger.*.*Address.hashCode ignore the >> upper 32 bits of a long value. >> >> e.g. >> https://github.com/openjdk/jdk/blob/3789983e89c9de252ef546a1b98a732a7d066650/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java#L56 >> >> I don't think the upper 32 bits of a long value should be ignored. >> IMHO, the Long.hashCode static method is suitable for such cases. >> >> If it's worth making this change, could anyone submit this issue to >> JBS? >> >> I'm ready to submit a pull request, but I don't have an Author role. >> >> Please let me know if there is a better place to do so. >> >> Thanks From mark.yagnatinsky at barclays.com Mon Apr 5 23:51:24 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Mon, 5 Apr 2021 23:51:24 +0000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal Message-ID: Not sure what the proper etiquette for this list is, hope someone will tell me if I'm breaking any rules. I'd like to make an argument against deprecating the applet API for removal. Namely, it used to be a common practice to write Swing apps in such a way that they can run either as an applet, or as a desktop application. There are thus all sorts of nice little jars floating around the web, which remain perfectly usable as desktop applications today, but would suddenly stop working on newer JDKs because they happen to have the magic words "extends Applet". (For instance, this one I've used personally that would probably break: http://www.science.smith.edu/~jorourke/books/CompGeom/CompGeom.html) These are often un-maintained so it's probably unrealistic to expect all of them to be "fixed". Thus I propose that rather than removing the API's outright, one of the following options can be taken: Option 1: do nothing: keep applets deprecated, but not for removal, and eventually stop testing or maintaining the relevant code. Option 2: remove the bulk of the implementation, leaving just enough so that code that mentions the applet AIP can compile and run successfully. This is a little bit tricky, in that you have to figure out what counts as a "workable stub". For instance, the applet constructor can't be changed to unconditionally throw an exception since the "extends Applet" trick mentioned above results in calling that constructor even when running as a desktop app. That's my two cents. Thanks, Mark. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From forax at univ-mlv.fr Tue Apr 6 06:41:06 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 6 Apr 2021 08:41:06 +0200 (CEST) Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: Message-ID: <24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr> Hi Mark, As the JEP says, browsers don't support the applet API anymore, the plugin API has been deprecated because it lacks any sandboxing. Currently, the only way to see an applet is to use Internet Explorer on Windows. Anyway, this JEP is about tagging the Applet API with @Deprecated(forRemoval = true), so in the JDK 17, the applet API will still exist. Given that the JDK 17 is a LTS, a long term support release, you get at least 8 to 10 years of support, so you still be able to use applets until 2030, if Microsoft does not drop the support of Internet Explorer before. regards, R?mi ----- Mail original ----- > De: "mark yagnatinsky" > ?: "jdk-dev" > Envoy?: Jeudi 1 Avril 2021 22:49:55 > Objet: a case for reconsidering JEP 398: Deprecate the Applet API for Removal > Not sure what the proper etiquette for this list is, hope someone will tell me > if I'm breaking any rules. > > I'd like to make an argument against deprecating the applet API for removal. > Namely, it used to be a common practice to write Swing apps in such a way that > they can run either as an applet, or as a desktop application. > There are thus all sorts of nice little jars floating around the web, which > remain perfectly usable as desktop applications today, > but would suddenly stop working on newer JDKs because they happen to have the > magic words "extends Applet". > (For instance, this one I've used personally that would probably break: > http://www.science.smith.edu/~jorourke/books/CompGeom/CompGeom.html) > These are often un-maintained so it's probably unrealistic to expect all of them > to be "fixed". > > Thus I propose that rather than removing the API's outright, one of the > following options can be taken: > > Option 1: do nothing: keep applets deprecated, but not for removal, and > eventually stop testing or maintaining the relevant code. > > Option 2: remove the bulk of the implementation, leaving just enough so that > code that mentions the applet AIP can compile and run successfully. > This is a little bit tricky, in that you have to figure out what counts as a > "workable stub". > For instance, the applet constructor can't be changed to unconditionally throw > an exception since the "extends Applet" trick mentioned above results > in calling that constructor even when running as a desktop app. > > That's my two cents. > > Thanks, > Mark. > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > This message is for information purposes only, it is not a recommendation, > advice, offer or solicitation to buy or sell a product or service nor an > official confirmation of any transaction. It is directed at persons who are > professionals and is not intended for retail customer use. Intended for > recipient only. This message is subject to the terms at: > www.barclays.com/emaildisclaimer. > > For important disclosures, please see: > www.barclays.com/salesandtradingdisclaimer regarding market commentary from > Barclays Sales and/or Trading, who are active market participants; > https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html > regarding our standard terms for the Investment Bank of Barclays where we trade > with you in principal-to-principal wholesale markets transactions; and in > respect of Barclays Research, including disclosures relating to specific > issuers, please see http://publicresearch.barclays.com. > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > If you are incorporated or operating in Australia, please see > https://www.home.barclays/disclosures/importantapacdisclosures.html for > important disclosure. > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > How we use personal information see our privacy notice > https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From mark at lawinegevaar.nl Tue Apr 6 09:16:43 2021 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 06 Apr 2021 11:16:43 +0200 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: <24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr> References: <24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, You are ignoring the core of Mark's argument. It is not about using applets as such, but that there are unmaintained Swing applications in the wild that are implemented both as an applet and as a normal Java application. Removal of applet classes would therefor render those applications inoperable, even if they are not used as applets, but as normal applications. Mark On 2021-04-06 08:41, Remi Forax wrote: > Hi Mark, > As the JEP says, browsers don't support the applet API anymore, > the plugin API has been deprecated because it lacks any sandboxing. > Currently, the only way to see an applet is to use Internet Explorer on > Windows. > > Anyway, this JEP is about tagging the Applet API with > @Deprecated(forRemoval = true), > so in the JDK 17, the applet API will still exist. Given that the JDK > 17 is a LTS, a long term support release, > you get at least 8 to 10 years of support, so you still be able to use > applets until 2030, > if Microsoft does not drop the support of Internet Explorer before. > > regards, > R?mi > > ----- Mail original ----- >> De: "mark yagnatinsky" >> ?: "jdk-dev" >> Envoy?: Jeudi 1 Avril 2021 22:49:55 >> Objet: a case for reconsidering JEP 398: Deprecate the Applet API for >> Removal > >> Not sure what the proper etiquette for this list is, hope someone will >> tell me >> if I'm breaking any rules. >> >> I'd like to make an argument against deprecating the applet API for >> removal. >> Namely, it used to be a common practice to write Swing apps in such a >> way that >> they can run either as an applet, or as a desktop application. >> There are thus all sorts of nice little jars floating around the web, >> which >> remain perfectly usable as desktop applications today, >> but would suddenly stop working on newer JDKs because they happen to >> have the >> magic words "extends Applet". >> (For instance, this one I've used personally that would probably >> break: >> http://www.science.smith.edu/~jorourke/books/CompGeom/CompGeom.html) >> These are often un-maintained so it's probably unrealistic to expect >> all of them >> to be "fixed". >> >> Thus I propose that rather than removing the API's outright, one of >> the >> following options can be taken: >> >> Option 1: do nothing: keep applets deprecated, but not for removal, >> and >> eventually stop testing or maintaining the relevant code. >> >> Option 2: remove the bulk of the implementation, leaving just enough >> so that >> code that mentions the applet AIP can compile and run successfully. >> This is a little bit tricky, in that you have to figure out what >> counts as a >> "workable stub". >> For instance, the applet constructor can't be changed to >> unconditionally throw >> an exception since the "extends Applet" trick mentioned above results >> in calling that constructor even when running as a desktop app. >> >> That's my two cents. >> >> Thanks, >> Mark. >> >> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >> This message is for information purposes only, it is not a >> recommendation, >> advice, offer or solicitation to buy or sell a product or service nor >> an >> official confirmation of any transaction. It is directed at persons >> who are >> professionals and is not intended for retail customer use. Intended >> for >> recipient only. This message is subject to the terms at: >> www.barclays.com/emaildisclaimer. >> >> For important disclosures, please see: >> www.barclays.com/salesandtradingdisclaimer regarding market commentary >> from >> Barclays Sales and/or Trading, who are active market participants; >> https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html >> regarding our standard terms for the Investment Bank of Barclays where >> we trade >> with you in principal-to-principal wholesale markets transactions; and >> in >> respect of Barclays Research, including disclosures relating to >> specific >> issuers, please see http://publicresearch.barclays.com. >> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >> If you are incorporated or operating in Australia, please see >> https://www.home.barclays/disclosures/importantapacdisclosures.html >> for >> important disclosure. >> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >> How we use personal information see our privacy notice >> https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html >> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From julia.boes at oracle.com Tue Apr 6 10:25:44 2021 From: julia.boes at oracle.com (Julia Boes) Date: Tue, 6 Apr 2021 11:25:44 +0100 Subject: [External] : Re: Re: New candidate JEP: 408: Simple Web Server In-Reply-To: References: <20210329191606.929913DDF64@eggemoggin.niobe.net> Message-ID: <570296fd-302f-47c4-0d85-74da057f08c2@oracle.com> Hi Zheka, On 05/04/2021 16:09, Zheka Kozlov wrote: > Can we put at least new classes to some java.* package (SimpleFileServer, > HttpHandlers, Request)? For example, java.net.httpserver. The new classes extend/implement/build upon the existing abstractions in jdk.httpserver, they have a clear API relationship and cannot be easily separated out. Indeed, separating them out would make things much more confusing, given they are a logical extension of the existing classes. Where would we cut ties exactly? Old vs. new API points would be a misleading distinction here and we would end up with a partial and incomplete package that cannot stand on its own feet. If the HTTP Server API were ever to be standardized (moved to the java. namespace), it should be considered as a whole - with all the additional considerations this would bring. And as said before, the java. vs. jdk. namespace question is bigger than this JEP and will not be addressed in this work. Regards, Julia From forax at univ-mlv.fr Tue Apr 6 10:50:18 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 6 Apr 2021 12:50:18 +0200 (CEST) Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr> Message-ID: <1857883128.792618.1617706218007.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mark Rotteveel" > ?: "jdk-dev" > Envoy?: Mardi 6 Avril 2021 11:16:43 > Objet: Re: a case for reconsidering JEP 398: Deprecate the Applet API for Removal > Hi Remi, > > You are ignoring the core of Mark's argument. It is not about using > applets as such, but that there are unmaintained Swing applications in > the wild that are implemented both as an applet and as a normal Java > application. Removal of applet classes would therefor render those > applications inoperable, even if they are not used as applets, but as > normal applications. Java loads classes lazily, so depending on how the the application is coded, it may not an issue at all because the VM has to load the applet code to see that the dependency is missing. Again, we are talking about a post 2030 world and after that writing an agent that provides the necessary bits and bolts is always possible, if the application is popular enough. > > Mark > R?mi > > On 2021-04-06 08:41, Remi Forax wrote: >> Hi Mark, >> As the JEP says, browsers don't support the applet API anymore, >> the plugin API has been deprecated because it lacks any sandboxing. >> Currently, the only way to see an applet is to use Internet Explorer on >> Windows. >> >> Anyway, this JEP is about tagging the Applet API with >> @Deprecated(forRemoval = true), >> so in the JDK 17, the applet API will still exist. Given that the JDK >> 17 is a LTS, a long term support release, >> you get at least 8 to 10 years of support, so you still be able to use >> applets until 2030, >> if Microsoft does not drop the support of Internet Explorer before. >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "mark yagnatinsky" >>> ?: "jdk-dev" >>> Envoy?: Jeudi 1 Avril 2021 22:49:55 >>> Objet: a case for reconsidering JEP 398: Deprecate the Applet API for >>> Removal >> >>> Not sure what the proper etiquette for this list is, hope someone will >>> tell me >>> if I'm breaking any rules. >>> >>> I'd like to make an argument against deprecating the applet API for >>> removal. >>> Namely, it used to be a common practice to write Swing apps in such a >>> way that >>> they can run either as an applet, or as a desktop application. >>> There are thus all sorts of nice little jars floating around the web, >>> which >>> remain perfectly usable as desktop applications today, >>> but would suddenly stop working on newer JDKs because they happen to >>> have the >>> magic words "extends Applet". >>> (For instance, this one I've used personally that would probably >>> break: >>> http://www.science.smith.edu/~jorourke/books/CompGeom/CompGeom.html) >>> These are often un-maintained so it's probably unrealistic to expect >>> all of them >>> to be "fixed". >>> >>> Thus I propose that rather than removing the API's outright, one of >>> the >>> following options can be taken: >>> >>> Option 1: do nothing: keep applets deprecated, but not for removal, >>> and >>> eventually stop testing or maintaining the relevant code. >>> >>> Option 2: remove the bulk of the implementation, leaving just enough >>> so that >>> code that mentions the applet AIP can compile and run successfully. >>> This is a little bit tricky, in that you have to figure out what >>> counts as a >>> "workable stub". >>> For instance, the applet constructor can't be changed to >>> unconditionally throw >>> an exception since the "extends Applet" trick mentioned above results >>> in calling that constructor even when running as a desktop app. >>> >>> That's my two cents. >>> >>> Thanks, >>> Mark. >>> >>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >>> This message is for information purposes only, it is not a >>> recommendation, >>> advice, offer or solicitation to buy or sell a product or service nor >>> an >>> official confirmation of any transaction. It is directed at persons >>> who are >>> professionals and is not intended for retail customer use. Intended >>> for >>> recipient only. This message is subject to the terms at: >>> www.barclays.com/emaildisclaimer. >>> >>> For important disclosures, please see: >>> www.barclays.com/salesandtradingdisclaimer regarding market commentary >>> from >>> Barclays Sales and/or Trading, who are active market participants; >>> https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html >>> regarding our standard terms for the Investment Bank of Barclays where >>> we trade >>> with you in principal-to-principal wholesale markets transactions; and >>> in >>> respect of Barclays Research, including disclosures relating to >>> specific >>> issuers, please see http://publicresearch.barclays.com. >>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >>> If you are incorporated or operating in Australia, please see >>> https://www.home.barclays/disclosures/importantapacdisclosures.html >>> for >>> important disclosure. >>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >>> How we use personal information see our privacy notice >>> https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html > >> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From Alan.Bateman at oracle.com Tue Apr 6 10:52:14 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Apr 2021 11:52:14 +0100 Subject: [External] : Re: Re: New candidate JEP: 408: Simple Web Server In-Reply-To: <570296fd-302f-47c4-0d85-74da057f08c2@oracle.com> References: <20210329191606.929913DDF64@eggemoggin.niobe.net> <570296fd-302f-47c4-0d85-74da057f08c2@oracle.com> Message-ID: On 06/04/2021 11:25, Julia Boes wrote: > : > The new classes extend/implement/build upon the existing abstractions in > jdk.httpserver, they have a clear API relationship and cannot be easily > separated out. Indeed, separating them out would make things much more > confusing, given they are a logical extension of the existing classes. Where > would we cut ties exactly? Old vs. new API points would be a misleading > distinction here and we would end up with a partial and incomplete package that > cannot stand on its own feet. > > If the HTTP Server API were ever to be standardized (moved to the java. > namespace), it should be considered as a whole - with all the additional > considerations this would bring. And as said before, the java. vs. jdk. > namespace question is bigger than this JEP and will not be addressed in this work. Right, and the effort to do that should not be under estimated as it would be very difficult to agreement on the scope. Also just to mention that the original proposal for the web services stack in Java SE 6 (web services callbacks were the the original motive for the http server API) did have the http server API in the javax.* name space. JSR 270 (the umbrella JSR for Java SE 6) had some concerns so it had to be introduced as a JDK-specific API instead. -Alan From mark.yagnatinsky at barclays.com Tue Apr 6 14:13:31 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Tue, 6 Apr 2021 14:13:31 +0000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: <1857883128.792618.1617706218007.JavaMail.zimbra@u-pem.fr> References: <24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr> <1857883128.792618.1617706218007.JavaMail.zimbra@u-pem.fr> Message-ID: > Java loads classes lazily, so depending on how the application is coded, it may not an issue at all I think the usual pattern is class MyLittleApp extends Applet { public static void main(String... args) { invokeLater(some runnable that creates the main window); } } And I think here Java has to load Applet eagerly because Applet might have a static init block. And yes, I agree that this is not an issue until 2030 or so. But if I wait until then to speak up, the response will likely be: "Why didn't you say anything when we were making these decisions? You had a whole decade." And yes, writing an agent would work if the application is popular enough. Lots of things are possible for applications that are popular enough. But there's a long tail of things that are not popular enough. In my first email I included as an example some Java code that some professor wrote as a companion to a book on computational geometry in C. (Yes, the book was about C; the Java code is just "bonus content".) I expect that once that professor retires, this code will have zero maintainers. My concern is for this "long tail" of combo desktop apps / java applets that are not popular at all, but still appreciated by their few users. Thoughts? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From mark.reinhold at oracle.com Tue Apr 6 22:43:21 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 6 Apr 2021 15:43:21 -0700 (PDT) Subject: New candidate JEP: 409: Sealed Classes Message-ID: <20210406224321.3D0B93DEDBE@eggemoggin.niobe.net> https://openjdk.java.net/jeps/409 Summary: Enhance the Java programming language with sealed classes and interfaces. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. - Mark From thihup at gmail.com Tue Apr 6 22:50:45 2021 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Tue, 6 Apr 2021 19:50:45 -0300 Subject: New candidate JEP: 409: Sealed Classes In-Reply-To: <20210406224321.3D0B93DEDBE@eggemoggin.niobe.net> References: <20210406224321.3D0B93DEDBE@eggemoggin.niobe.net> Message-ID: Hi. Is the plan to show in the Javadoc that a class is sealed or is this an implementation detail? Thanks Em ter., 6 de abr. de 2021 ?s 19:43, escreveu: > https://openjdk.java.net/jeps/409 > > Summary: Enhance the Java programming language with sealed classes and > interfaces. Sealed classes and interfaces restrict which other classes > or interfaces may extend or implement them. > > - Mark > From brian.goetz at oracle.com Wed Apr 7 01:08:20 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 6 Apr 2021 21:08:20 -0400 Subject: New candidate JEP: 409: Sealed Classes In-Reply-To: References: <20210406224321.3D0B93DEDBE@eggemoggin.niobe.net> Message-ID: Yes, Javadoc shows that a class is sealed, and its permitted subtypes (if accessible). On 4/6/2021 6:50 PM, Thiago Henrique Hupner wrote: > Hi. > Is the plan to show in the Javadoc that a class is sealed or is this an > implementation detail? > > Thanks > > Em ter., 6 de abr. de 2021 ?s 19:43, escreveu: > >> https://openjdk.java.net/jeps/409 >> >> Summary: Enhance the Java programming language with sealed classes and >> interfaces. Sealed classes and interfaces restrict which other classes >> or interfaces may extend or implement them. >> >> - Mark >> From mark.reinhold at oracle.com Wed Apr 7 21:47:19 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 7 Apr 2021 14:47:19 -0700 (PDT) Subject: New candidate JEP: 410: Remove the Experimental AOT and JIT Compiler Message-ID: <20210407214719.2E6553DF0DA@eggemoggin.niobe.net> https://openjdk.java.net/jeps/410 Summary: Remove the experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler. This compiler has seen little use since its introduction and the effort required to maintain it is significant. Retain the experimental Java-level JVM compiler interface (JVMCI) so that developers can continue to use externally-built versions of the compiler for JIT compilation. - Mark From mark.reinhold at oracle.com Wed Apr 7 22:01:31 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 07 Apr 2021 15:01:31 -0700 Subject: Proposed schedule for JDK 17 In-Reply-To: <20210329143018.403323786@eggemoggin.niobe.net> References: <20210329143018.403323786@eggemoggin.niobe.net> Message-ID: <20210407150131.5677184@eggemoggin.niobe.net> 2021/3/29 14:30:18 -0700, mark.reinhold at oracle.com: > With JDK 16 done and gone, here?s a proposed schedule for JDK 17: > > 2021/06/10 Rampdown Phase One > 2021/07/15 Rampdown Phase Two > 2021/08/05 Initial Release Candidate > 2021/08/19 Final Release Candidate > 2021/09/14 General Availability > > The phases are defined in JEP 3 [1]. > > Comments on this proposal from JDK Committers and Reviewers [2] are > welcome, as are reasoned objections. If no such objections are > raised by 23:00 UTC next Monday, 5 April, or if they?re raised and > satisfactorily answered, then per the JEP 2.0 process proposal [3] > this will be the schedule for JDK 17. Hearing no objections, this is the schedule for JDK 17. - Mark From henri.tremblay at gmail.com Tue Apr 13 11:26:21 2021 From: henri.tremblay at gmail.com (Henri Tremblay) Date: Tue, 13 Apr 2021 07:26:21 -0400 Subject: New candidate JEP: 410: Remove the Experimental AOT and JIT Compiler In-Reply-To: <20210407214719.2E6553DF0DA@eggemoggin.niobe.net> References: <20210407214719.2E6553DF0DA@eggemoggin.niobe.net> Message-ID: Hi, Does it mean that the chances to see GraalVM becoming the default JIT are now becoming thiner and thiner? Thanks, Henri On Wed, 7 Apr 2021 at 17:47, wrote: > https://openjdk.java.net/jeps/410 > > Summary: Remove the experimental Java-based ahead-of-time (AOT) and > just-in-time (JIT) compiler. This compiler has seen little use since > its introduction and the effort required to maintain it is significant. > Retain the experimental Java-level JVM compiler interface (JVMCI) so > that developers can continue to use externally-built versions of the > compiler for JIT compilation. > > - Mark > From mark.reinhold at oracle.com Thu Apr 15 18:05:00 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Apr 2021 11:05:00 -0700 (PDT) Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal Message-ID: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> https://openjdk.java.net/jeps/411 Summary: Deprecate the Security Manager for removal in a future release. The Security Manager dates from Java 1.0. It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code. To move Java forward, we intend to deprecate the Security Manager for removal in concert with the legacy Applet API (JEP 398). - Mark From mark.reinhold at oracle.com Thu Apr 15 21:05:46 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 15 Apr 2021 14:05:46 -0700 (PDT) Subject: JEP proposed to target JDK 17: 410: Remove the Experimental AOT and JIT Compiler Message-ID: <20210415210546.3BEEF3E0138@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 410: Remove the Experimental AOT and JIT Compiler https://openjdk.java.net/jeps/410 Summary: Remove the experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler. This compiler has seen little use since its introduction and the effort required to maintain it is significant. Retain the experimental Java-level JVM compiler interface (JVMCI) so that developers can continue to use externally-built versions of the compiler for JIT compilation. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Thursday, 22 April, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.yagnatinsky at barclays.com Thu Apr 15 21:13:15 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Thu, 15 Apr 2021 21:13:15 +0000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr> <1857883128.792618.1617706218007.JavaMail.zimbra@u-pem.fr> Message-ID: And answer came there none? -----Original Message----- From: Yagnatinsky, Mark : Markets Pre Trade Sent: Tuesday, April 6, 2021 10:14 AM To: Remi Forax ; Mark Rotteveel Cc: jdk-dev Subject: RE: a case for reconsidering JEP 398: Deprecate the Applet API for Removal > Java loads classes lazily, so depending on how the application is > coded, it may not an issue at all I think the usual pattern is class MyLittleApp extends Applet { public static void main(String... args) { invokeLater(some runnable that creates the main window); } } And I think here Java has to load Applet eagerly because Applet might have a static init block. And yes, I agree that this is not an issue until 2030 or so. But if I wait until then to speak up, the response will likely be: "Why didn't you say anything when we were making these decisions? You had a whole decade." And yes, writing an agent would work if the application is popular enough. Lots of things are possible for applications that are popular enough. But there's a long tail of things that are not popular enough. In my first email I included as an example some Java code that some professor wrote as a companion to a book on computational geometry in C. (Yes, the book was about C; the Java code is just "bonus content".) I expect that once that professor retires, this code will have zero maintainers. My concern is for this "long tail" of combo desktop apps / java applets that are not popular at all, but still appreciated by their few users. Thoughts? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From neugens.limasoftware at gmail.com Thu Apr 15 23:59:55 2021 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 16 Apr 2021 01:59:55 +0200 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr> <1857883128.792618.1617706218007.JavaMail.zimbra@u-pem.fr> Message-ID: <316b3faf-7ec4-4a49-ad75-414679c6d8b1@Canary> Unlike the options available to the previous generations with other software, in 2030 you?ll still have the option to add back applet support and compile your own JDK if you need to support a 20 years old - never updated - application. Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ > On Thursday, Apr 15, 2021 at 23:13, wrote: > And answer came there none? > > -----Original Message----- > From: Yagnatinsky, Mark : Markets Pre Trade > Sent: Tuesday, April 6, 2021 10:14 AM > To: Remi Forax ; Mark Rotteveel > Cc: jdk-dev > Subject: RE: a case for reconsidering JEP 398: Deprecate the Applet API for Removal > > > Java loads classes lazily, so depending on how the application is > > coded, it may not an issue at all > > I think the usual pattern is > > class MyLittleApp extends Applet { > public static void main(String... args) { > invokeLater(some runnable that creates the main window); > } > } > > And I think here Java has to load Applet eagerly because Applet might have a static init block. > > And yes, I agree that this is not an issue until 2030 or so. > But if I wait until then to speak up, the response will likely be: > "Why didn't you say anything when we were making these decisions? You had a whole decade." > > And yes, writing an agent would work if the application is popular enough. > Lots of things are possible for applications that are popular enough. > But there's a long tail of things that are not popular enough. > > In my first email I included as an example some Java code that some professor wrote as a companion to a book on computational geometry in C. > (Yes, the book was about C; the Java code is just "bonus content".) I expect that once that professor retires, this code will have zero maintainers. > > My concern is for this "long tail" of combo desktop apps / java applets that are not popular at all, but still appreciated by their few users. > > Thoughts? > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. > > For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From ebresie at gmail.com Fri Apr 16 01:02:34 2021 From: ebresie at gmail.com (Eric Bresie) Date: Thu, 15 Apr 2021 20:02:34 -0500 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: 316b3faf-7ec4-4a49-ad75-414679c6d8b1@Canary References: AM6PR01MB41660D2FEC5A4BB069B5B690F97B9@AM6PR01MB4166.eurprd01.prod.exchangelabs.com 24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr b949bc42bb4a32eccdb5eff5e3668061@lawinegevaar.nl 1857883128.792618.1617706218007.JavaMail.zimbra@u-pem.fr AM6PR01MB41664D56D26F96860C6B0EDBF9769@AM6PR01MB4166.eurprd01.prod.exchangelabs.com AM6PR01MB416697CD6AEE3E58D80E2B00F94D9@AM6PR01MB4166.eurprd01.prod.exchangelabs.com AM6PR01MB416697CD6AEE3E58D80E2B00F94D9@AM6PR01MB4166.eurprd01.prod.exchangelabs.com Message-ID: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Is this a case where an alternative would be a possible migration path? Something like https://openwebstart.com/ ? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On April 15, 2021 at 6:59:55 PM CDT, Mario Torre wrote: > Unlike the options available to the previous generations with other software, in 2030 you?ll still have the option to add back applet support and compile your own JDK if you need to support a 20 years old - never updated - application. > > Cheers, > Mario > > ? > Mario Torre > Java Champion and OpenJDK contributor > > PGP Key: 0BAB254E > Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E > > Twitter: @neugens > Web: https://www.mario-torre.eu/ > Music: https://mario-torre.bandcamp.com/ > > > On Thursday, Apr 15, 2021 at 23:13 (x-apple-data-detectors://7), wrote: > > And answer came there none? > > > > -----Original Message----- > > From: Yagnatinsky, Mark : Markets Pre Trade > > Sent: Tuesday, April 6, 2021 10:14 AM > > To: Remi Forax ; Mark Rotteveel > > Cc: jdk-dev > > Subject: RE: a case for reconsidering JEP 398: Deprecate the Applet API for Removal > > > > > Java loads classes lazily, so depending on how the application is > > > coded, it may not an issue at all > > > > I think the usual pattern is > > > > class MyLittleApp extends Applet { > > public static void main(String... args) { > > invokeLater(some runnable that creates the main window); > > } > > } > > > > And I think here Java has to load Applet eagerly because Applet might have a static init block. > > > > And yes, I agree that this is not an issue until 2030 or so. > > But if I wait until then to speak up, the response will likely be: > > "Why didn't you say anything when we were making these decisions? You had a whole decade." > > > > And yes, writing an agent would work if the application is popular enough. > > Lots of things are possible for applications that are popular enough. > > But there's a long tail of things that are not popular enough. > > > > In my first email I included as an example some Java code that some professor wrote as a companion to a book on computational geometry in C. > > (Yes, the book was about C; the Java code is just "bonus content".) I expect that once that professor retires, this code will have zero maintainers. > > > > My concern is for this "long tail" of combo desktop apps / java applets that are not popular at all, but still appreciated by their few users. > > > > Thoughts? > > > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > > ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer (http://www.barclays.com/emaildisclaimer). > > > > For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer (http://www.barclays.com/salesandtradingdisclaimer) regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > > If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > > How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From mark.yagnatinsky at barclays.com Fri Apr 16 02:51:42 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Fri, 16 Apr 2021 02:51:42 +0000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> References: AM6PR01MB41660D2FEC5A4BB069B5B690F97B9@AM6PR01MB4166.eurprd01.prod.exchangelabs.com 24738877.519783.1617691266992.JavaMail.zimbra@u-pem.fr b949bc42bb4a32eccdb5eff5e3668061@lawinegevaar.nl 1857883128.792618.1617706218007.JavaMail.zimbra@u-pem.fr AM6PR01MB41664D56D26F96860C6B0EDBF9769@AM6PR01MB4166.eurprd01.prod.exchangelabs.com AM6PR01MB416697CD6AEE3E58D80E2B00F94D9@AM6PR01MB4166.eurprd01.prod.exchangelabs.com AM6PR01MB416697CD6AEE3E58D80E2B00F94D9@AM6PR01MB4166.eurprd01.prod.exchangelabs.com <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Message-ID: I think talking about a "migration path" here is missing the point: I'm worried about stuff that has zero maintainers but non-zero users. So there's no one around to perform any migration. Similarly, Mario's phrase "if you need to support a 20 years old [..] application" is missing the point: There is no one who "needs to support" anything. There is no support. There are users who are benefiting from an application that exists and happens to work. One fine day it will stop working and there will be no one they can turn to. If the users are programmers, it's not too hard to manually remove all mentions of the applet API and recompile. If the users are not programmers, then asking them to install a new JDK is pretty much the limit of technical sophistication that's reasonable to expect. (Unlike the old days, there's no user-friendly installer to install just a JRE.) So I guess the real question is this: once Java 8 is unsupported, do we want people to download the latest JDK to run unmaintained Swing apps? Or do we expect users to keep their trusty Java 8 JRE's around, since JDK 23 won't work and JDK 17 will be unsupported by then anyway? -----Original Message----- From: jdk-dev On Behalf Of Eric Bresie Sent: Thursday, April 15, 2021 9:03 PM To: jdk-dev at openjdk.java.net Subject: Re: Re: a case for reconsidering JEP 398: Deprecate the Applet API for Removal This message originated from outside our organisation and is from web based email - ebresie at gmail.com Is this a case where an alternative would be a possible migration path? Something like https://clicktime.symantec.com/3BbwXEL9xRE1Stej35LUPto6H2?u=https%3A%2F%2Fopenwebstart.com%2F ? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On April 15, 2021 at 6:59:55 PM CDT, Mario Torre wrote: > Unlike the options available to the previous generations with other software, in 2030 you???ll still have the option to add back applet support and compile your own JDK if you need to support a 20 years old - never updated - application. > > Cheers, > Mario > > ??? > Mario Torre > Java Champion and OpenJDK contributor > > PGP Key: 0BAB254E > Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E > > Twitter: @neugens > Web: > https://clicktime.symantec.com/3WKs8UzMnMQa4Jy7JsHi9js6H2?u=https%3A%2 > F%2Fwww.mario-torre.eu%2F > Music: > https://clicktime.symantec.com/3J1mbpEVAPCfwtyiLqaCqkb6H2?u=https%3A%2 > F%2Fmario-torre.bandcamp.com%2F > > > On Thursday, Apr 15, 2021 at 23:13 (x-apple-data-detectors://7), wrote: > > And answer came there none? > > > > -----Original Message----- > > From: Yagnatinsky, Mark : Markets Pre Trade > > Sent: Tuesday, April 6, 2021 10:14 AM > > To: Remi Forax ; Mark > > Rotteveel > > Cc: jdk-dev > (mailto:jdk-dev at openjdk.java.net)> > > Subject: RE: a case for reconsidering JEP 398: Deprecate the Applet > > API for Removal > > > > > Java loads classes lazily, so depending on how the application is > > > coded, it may not an issue at all > > > > I think the usual pattern is > > > > class MyLittleApp extends Applet { > > public static void main(String... args) { invokeLater(some runnable > > that creates the main window); } } > > > > And I think here Java has to load Applet eagerly because Applet might have a static init block. > > > > And yes, I agree that this is not an issue until 2030 or so. > > But if I wait until then to speak up, the response will likely be: > > "Why didn't you say anything when we were making these decisions? You had a whole decade." > > > > And yes, writing an agent would work if the application is popular enough. > > Lots of things are possible for applications that are popular enough. > > But there's a long tail of things that are not popular enough. > > > > In my first email I included as an example some Java code that some professor wrote as a companion to a book on computational geometry in C. > > (Yes, the book was about C; the Java code is just "bonus content".) I expect that once that professor retires, this code will have zero maintainers. > > > > My concern is for this "long tail" of combo desktop apps / java applets that are not popular at all, but still appreciated by their few users. > > > > Thoughts? > > > > ____________________________________________________________________ > > ____________________________________________________________________ > > ____________________________________________________________________ > > _____________________ This message is for information purposes > > only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: https://clicktime.symantec.com/3KwFNfTCLoFEi7ZdLArcP1Q6H2?u=www.barclays.com%2Femaildisclaimer (https://clicktime.symantec.com/3RqSgbHSsqgS7PnpkSA9nwf6H2?u=http%3A%2F%2Fwww.barclays.com%2Femaildisclaimer). > > > > For important disclosures, please see: > > https://clicktime.symantec.com/3VVzYzRi3nab2AD8A76aA3g6H2?u=www.barc > > lays.com%2Fsalesandtradingdisclaimer > > (https://clicktime.symantec.com/3LMPK1UmUQNM1tQpFBNzcc46H2?u=http%3A > > %2F%2Fwww.barclays.com%2Fsalesandtradingdisclaimer) regarding market > > commentary from Barclays Sales and/or Trading, who are active market > > participants; > > https://clicktime.symantec.com/3Pzg14TBasnWTuSjCH77xNK6H2?u=https%3A > > %2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fbarclays-globa > > l-markets-disclosures.html regarding our standard terms for the > > Investment Bank of Barclays where we trade with you in > > principal-to-principal wholesale markets transactions; and in > > respect of Barclays Research, including disclosures relating to > > specific issuers, please see http://publicresearch.barclays.com. > > ____________________________________________________________________ > > ____________________________________________________________________ > > ____________________________________________________________________ > > _____________________ If you are incorporated or operating in > > Australia, please see https://clicktime.symantec.com/35UftLKtGF6YJ5ffcRVmLYn6H2?u=https%3A%2F%2Fwww.home.barclays%2Fdisclosures%2Fimportantapacdisclosures.html for important disclosure. > > ____________________________________________________________________ > > ____________________________________________________________________ > > ____________________________________________________________________ > > _____________________ How we use personal information see our > > privacy notice > > https://clicktime.symantec.com/3X2TVJiJf8ncsyvc94Xff6K6H2?u=https%3A > > %2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fpersonalinform > > ationuse.html > > ____________________________________________________________________ > > ____________________________________________________________________ > > ____________________________________________________________________ > > _____________________ _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From david.holmes at oracle.com Fri Apr 16 05:20:22 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2021 15:20:22 +1000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Message-ID: On 16/04/2021 12:51 pm, mark.yagnatinsky at barclays.com wrote: > I think talking about a "migration path" here is missing the point: > I'm worried about stuff that has zero maintainers but non-zero users. > So there's no one around to perform any migration. > > Similarly, Mario's phrase "if you need to support a 20 years old [..] application" is missing the point: > There is no one who "needs to support" anything. There is no support. > There are users who are benefiting from an application that exists and happens to work. > One fine day it will stop working and there will be no one they can turn to. Yes and that can happen for a number of reasons unrelated to the JDK. If people want really old software to keep working on newer hardware, and newer OS etc, than at some point someone has to put in the work to make that so. There is no perpetual free-lunch here. > If the users are programmers, it's not too hard to manually remove all mentions of the applet API and recompile. > If the users are not programmers, then asking them to install a new JDK is pretty much the limit of technical sophistication that's reasonable to expect. > (Unlike the old days, there's no user-friendly installer to install just a JRE.) > > So I guess the real question is this: once Java 8 is unsupported, do we want people to download the latest JDK to run unmaintained Swing apps? > Or do we expect users to keep their trusty Java 8 JRE's around, since JDK 23 won't work and JDK 17 will be unsupported by then anyway? As Remi indicated JDK 17 is a LTS release and is to be supported until at least September 2029 (Five years after JDK 23 comes out). So there's 8 years for people to decide if they need to fix anything and if so decide how. And of course they can keep running JDK 17 after that for as long as it still runs on their hardware and OS. It won't be supported but that's obviously not an issue here as they are already happily using unsupported software. Just my 2c. Cheers, David > -----Original Message----- > From: jdk-dev On Behalf Of Eric Bresie > Sent: Thursday, April 15, 2021 9:03 PM > To: jdk-dev at openjdk.java.net > Subject: Re: Re: a case for reconsidering JEP 398: Deprecate the Applet API for Removal > > > This message originated from outside our organisation and is from web based email - ebresie at gmail.com > > Is this a case where an alternative would be a possible migration path? Something like https://clicktime.symantec.com/3BbwXEL9xRE1Stej35LUPto6H2?u=https%3A%2F%2Fopenwebstart.com%2F ? > > Eric Bresie > Ebresie at gmail.com (mailto:Ebresie at gmail.com) > >> On April 15, 2021 at 6:59:55 PM CDT, Mario Torre wrote: >> Unlike the options available to the previous generations with other software, in 2030 you?ll still have the option to add back applet support and compile your own JDK if you need to support a 20 years old - never updated - application. >> >> Cheers, >> Mario >> >> ? >> Mario Torre >> Java Champion and OpenJDK contributor >> >> PGP Key: 0BAB254E >> Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E >> >> Twitter: @neugens >> Web: >> https://clicktime.symantec.com/3WKs8UzMnMQa4Jy7JsHi9js6H2?u=https%3A%2 >> F%2Fwww.mario-torre.eu%2F >> Music: >> https://clicktime.symantec.com/3J1mbpEVAPCfwtyiLqaCqkb6H2?u=https%3A%2 >> F%2Fmario-torre.bandcamp.com%2F >> >>> On Thursday, Apr 15, 2021 at 23:13 (x-apple-data-detectors://7), wrote: >>> And answer came there none? >>> >>> -----Original Message----- >>> From: Yagnatinsky, Mark : Markets Pre Trade >>> Sent: Tuesday, April 6, 2021 10:14 AM >>> To: Remi Forax ; Mark >>> Rotteveel >>> Cc: jdk-dev >> (mailto:jdk-dev at openjdk.java.net)> >>> Subject: RE: a case for reconsidering JEP 398: Deprecate the Applet >>> API for Removal >>> >>>> Java loads classes lazily, so depending on how the application is >>>> coded, it may not an issue at all >>> >>> I think the usual pattern is >>> >>> class MyLittleApp extends Applet { >>> public static void main(String... args) { invokeLater(some runnable >>> that creates the main window); } } >>> >>> And I think here Java has to load Applet eagerly because Applet might have a static init block. >>> >>> And yes, I agree that this is not an issue until 2030 or so. >>> But if I wait until then to speak up, the response will likely be: >>> "Why didn't you say anything when we were making these decisions? You had a whole decade." >>> >>> And yes, writing an agent would work if the application is popular enough. >>> Lots of things are possible for applications that are popular enough. >>> But there's a long tail of things that are not popular enough. >>> >>> In my first email I included as an example some Java code that some professor wrote as a companion to a book on computational geometry in C. >>> (Yes, the book was about C; the Java code is just "bonus content".) I expect that once that professor retires, this code will have zero maintainers. >>> >>> My concern is for this "long tail" of combo desktop apps / java applets that are not popular at all, but still appreciated by their few users. >>> >>> Thoughts? >>> >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> _____________________ This message is for information purposes >>> only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: https://clicktime.symantec.com/3KwFNfTCLoFEi7ZdLArcP1Q6H2?u=www.barclays.com%2Femaildisclaimer (https://clicktime.symantec.com/3RqSgbHSsqgS7PnpkSA9nwf6H2?u=http%3A%2F%2Fwww.barclays.com%2Femaildisclaimer). >>> >>> For important disclosures, please see: >>> https://clicktime.symantec.com/3VVzYzRi3nab2AD8A76aA3g6H2?u=www.barc >>> lays.com%2Fsalesandtradingdisclaimer >>> (https://clicktime.symantec.com/3LMPK1UmUQNM1tQpFBNzcc46H2?u=http%3A >>> %2F%2Fwww.barclays.com%2Fsalesandtradingdisclaimer) regarding market >>> commentary from Barclays Sales and/or Trading, who are active market >>> participants; >>> https://clicktime.symantec.com/3Pzg14TBasnWTuSjCH77xNK6H2?u=https%3A >>> %2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fbarclays-globa >>> l-markets-disclosures.html regarding our standard terms for the >>> Investment Bank of Barclays where we trade with you in >>> principal-to-principal wholesale markets transactions; and in >>> respect of Barclays Research, including disclosures relating to >>> specific issuers, please see http://publicresearch.barclays.com. >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> _____________________ If you are incorporated or operating in >>> Australia, please see https://clicktime.symantec.com/35UftLKtGF6YJ5ffcRVmLYn6H2?u=https%3A%2F%2Fwww.home.barclays%2Fdisclosures%2Fimportantapacdisclosures.html for important disclosure. >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> _____________________ How we use personal information see our >>> privacy notice >>> https://clicktime.symantec.com/3X2TVJiJf8ncsyvc94Xff6K6H2?u=https%3A >>> %2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fpersonalinform >>> ationuse.html >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> ____________________________________________________________________ >>> _____________________ > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. > > For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > From jan at schloessin.de Fri Apr 16 08:35:55 2021 From: jan at schloessin.de (=?UTF-8?B?SmFuIFNjaGzDtsOfaW4=?=) Date: Fri, 16 Apr 2021 10:35:55 +0200 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Message-ID: <263b316f-1dbe-1050-6eae-3e9dde59615a@schloessin.de> Am 16.04.21 um 04:51 schrieb mark.yagnatinsky at barclays.com: > I think talking about a "migration path" here is missing the point: > I'm worried about stuff that has zero maintainers but non-zero users. > So there's no one around to perform any migration. > > Similarly, Mario's phrase "if you need to support a 20 years old [..] application" is missing the point: > There is no one who "needs to support" anything. There is no support. > There are users who are benefiting from an application that exists and happens to work. > One fine day it will stop working and there will be no one they can turn to. > > If the users are programmers, it's not too hard to manually remove all mentions of the applet API and recompile. > If the users are not programmers, then asking them to install a new JDK is pretty much the limit of technical sophistication that's reasonable to expect. > (Unlike the old days, there's no user-friendly installer to install just a JRE.) > > So I guess the real question is this: once Java 8 is unsupported, do we want people to download the latest JDK to run unmaintained Swing apps? > Or do we expect users to keep their trusty Java 8 JRE's around, since JDK 23 won't work and JDK 17 will be unsupported by then anyway? So we are talking about what removal means in that case. Do we have to remove the class Applet or is it enough to replace all method bodies with throwing UnsuportedOperationException? I think I want to make a point for the fact that Java is famous for not breaking old code and therefor IMHO such an empty Applet class could fly around in the JDK for eternity without accumulating too much maintenance time. We only have to document once, that this skeleton is there for compatibility reasons with legacy code. Regards, Jan From neugens.limasoftware at gmail.com Fri Apr 16 12:01:24 2021 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 16 Apr 2021 14:01:24 +0200 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: <263b316f-1dbe-1050-6eae-3e9dde59615a@schloessin.de> References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> <263b316f-1dbe-1050-6eae-3e9dde59615a@schloessin.de> Message-ID: <5CBFE0F0-31E5-4472-BFA3-EC055586977A@gmail.com> > On 16. Apr 2021, at 10:35, Jan Schl??in wrote: > > Am 16.04.21 um 04:51 schrieb mark.yagnatinsky at barclays.com: >> I think talking about a "migration path" here is missing the point: >> I'm worried about stuff that has zero maintainers but non-zero users. >> So there's no one around to perform any migration. >> >> Similarly, Mario's phrase "if you need to support a 20 years old [..] application" is missing the point: >> There is no one who "needs to support" anything. There is no support. >> There are users who are benefiting from an application that exists and happens to work. >> One fine day it will stop working and there will be no one they can turn to. >> >> If the users are programmers, it's not too hard to manually remove all mentions of the applet API and recompile. >> If the users are not programmers, then asking them to install a new JDK is pretty much the limit of technical sophistication that's reasonable to expect. >> (Unlike the old days, there's no user-friendly installer to install just a JRE.) >> >> So I guess the real question is this: once Java 8 is unsupported, do we want people to download the latest JDK to run unmaintained Swing apps? >> Or do we expect users to keep their trusty Java 8 JRE's around, since JDK 23 won't work and JDK 17 will be unsupported by then anyway? > > So we are talking about what removal means in that case. Do we have to > remove the class Applet or is it enough to replace all method bodies > with throwing UnsuportedOperationException? If it?s an API it needs to work. Removing is the only option. Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ From mark.yagnatinsky at barclays.com Fri Apr 16 12:54:27 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Fri, 16 Apr 2021 12:54:27 +0000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Message-ID: > And of course they can keep running JDK 17 after that for as long as it still runs on their hardware and OS That's a good point. For Windows user's that's likely pretty long. Even for Mac users it's likely until the next time Apple decides to do yet another CPU architecture change. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From mark.yagnatinsky at barclays.com Fri Apr 16 13:05:36 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Fri, 16 Apr 2021 13:05:36 +0000 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: <5CBFE0F0-31E5-4472-BFA3-EC055586977A@gmail.com> References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> <263b316f-1dbe-1050-6eae-3e9dde59615a@schloessin.de> <5CBFE0F0-31E5-4472-BFA3-EC055586977A@gmail.com> Message-ID: > If it???s an API it needs to work. Removing is the only option. This is actually not obvious to me at all. Consider Thread.stop(Throwable). In JDK 8 it was changed to always throw UnsupportedOperationException, but it was not removed outright. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From javalists at cbfiddle.com Sat Apr 17 19:44:52 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Sat, 17 Apr 2021 12:44:52 -0700 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Message-ID: > On Apr 16, 2021, at 5:54 AM, wrote: > >> And of course they can keep running JDK 17 after that for as long as it still runs on their hardware and OS > > That's a good point. For Windows user's that's likely pretty long. > Even for Mac users it's likely until the next time Apple decides to do yet another CPU architecture change. > I beg to differ. At some point, an application using the ?old? library may need to switch to a newer JDK for unrelated reasons, at which point the ?old? library would fail if Applet had been removed. Although Applet may not be the most important compatibility issue, the proposed resolution (keep the class but rewrite the methods to throw an exception) seems harmless. Why not do that? Perhaps we need a new deprecation category: "deprecated for defunctionalization? (in other words, it is not removed but stops working). (Sorry about the odd terminology, but I was unable to think of a better term that could not be accused of being ?politically incorrect?). Alan From cay.horstmann at gmail.com Sun Apr 18 05:55:08 2021 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Sun, 18 Apr 2021 07:55:08 +0200 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: <5CBFE0F0-31E5-4472-BFA3-EC055586977A@gmail.com> References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> <263b316f-1dbe-1050-6eae-3e9dde59615a@schloessin.de> <5CBFE0F0-31E5-4472-BFA3-EC055586977A@gmail.com> Message-ID: On 16/04/2021 14:01, Mario Torre wrote: > > >> On 16. Apr 2021, at 10:35, Jan Schl??in wrote: >> >> >> So we are talking about what removal means in that case. Do we have to >> remove the class Applet or is it enough to replace all method bodies >> with throwing UnsuportedOperationException? > > If it?s an API it needs to work. Removing is the only option. > > Cheers, > Mario The use case is to keep ancient apps alive that can function both as applets and as applications. This can be done by removing all functionality from the Applet classes (NOT throwing exceptions, but doing nothing, returning empty strings, and so on). Mostly this is trivial. The painful parts are AudioClip and adapting the tests. Even though minimal, it is an engineering effort. To justify it, a starting point might be to collect some of those ancient apps. Cheers, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From Alan.Bateman at oracle.com Sun Apr 18 14:23:26 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 18 Apr 2021 15:23:26 +0100 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Message-ID: On 17/04/2021 20:44, Alan Snyder wrote: > : > Although Applet may not be the most important compatibility issue, the proposed resolution (keep the class but rewrite the methods to throw an exception) seems harmless. Why not do that? > > Perhaps we need a new deprecation category: "deprecated for defunctionalization? (in other words, it is not removed but stops working). > > (Sorry about the odd terminology, but I was unable to think of a better term that could not be accused of being ?politically incorrect?). > There are examples where terminally deprecated APIs have been re-specified to work in a "degraded way" before eventually being removed. Thread.stop(Throwable) was mentioned in one of the replies here. That one was deprecated in Java 1.2, terminally deprecated and re-specified to throw UOE in Java 9, and eventually removed in Java 11. Thread.countStackFrames() is following a similar path. It was deprecated in Java 1.2,? terminally deprecated and re-specified to throw UOE in Java 14 and will eventually be proposed to be removed too. So yes, in some cases at least, it is possible to create a more gentle off ramp for legacy or abandoned code. It may be that JEP 277 needs a successor, in the form of an Informational JEP, to provide more up to date guidelines on migration and timing of next steps after deprecating an API for future removal. Most of mails on this thread don't seem to concerned with JEP 398 but rather on some future JEP that will propose to remove the Applet classes. It seems reasonable to use the intervening period to explore migration options and see if it's worth leaving some kind of carcass in place to keep the abandoned code running in stand-alone code for a bit longer. -Alan From dblack at atlassian.com Sun Apr 18 23:50:32 2021 From: dblack at atlassian.com (David Black) Date: Mon, 19 Apr 2021 09:50:32 +1000 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: On Fri, 16 Apr 2021 at 04:05, wrote: > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > - Mark > Hi, How can those interested in the JEP get involved? (I am asking because Atlassian makes use of a custom java security manager, based on the manas security manager[0], to help mitigate SSRF attacks[1]) [0] - https://code.google.com/archive/p/manas-java-security/ [1] - https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager/blob/master/example-security-manager-core/src/main/java/com/google/security/manas/ManasSecurityManager.java#L410 From claes.redestad at oracle.com Mon Apr 19 13:12:02 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 19 Apr 2021 15:12:02 +0200 Subject: CFV: New JDK Reviewer: Jorn Vernee Message-ID: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. Jorn is a very active committer in the panama project with 133 commits to parama-foreign[1], many of which has been integrated into the mainline JDK. He has also contributed 20+ patches directly to the main JDK project[2], most of which I would consider significant. Outside of his joint work on things like the Memory Access API, Jorn has made valuable contributions to java.lang.invoke and the JIT compilers. I think making him a reviewer would help us all move things ahead in several key areas in days to come. Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. Only current OpenJDK Reviewers (and above) [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks! /Claes [0] https://openjdk.java.net/census#jvernee [1] https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits [2] https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits [3] https://openjdk.java.net/census#jdk [4] http://openjdk.java.net/projects/#reviewer-vote From sundararajan.athijegannathan at oracle.com Mon Apr 19 13:13:32 2021 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 19 Apr 2021 13:13:32 +0000 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: Yes! -Sundar ________________________________ From: jdk-dev on behalf of Claes Redestad Sent: 19 April 2021 18:42 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Jorn Vernee I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. Jorn is a very active committer in the panama project with 133 commits to parama-foreign[1], many of which has been integrated into the mainline JDK. He has also contributed 20+ patches directly to the main JDK project[2], most of which I would consider significant. Outside of his joint work on things like the Memory Access API, Jorn has made valuable contributions to java.lang.invoke and the JIT compilers. I think making him a reviewer would help us all move things ahead in several key areas in days to come. Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. Only current OpenJDK Reviewers (and above) [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks! /Claes [0] https://openjdk.java.net/census#jvernee [1] https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits [2] https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits [3] https://openjdk.java.net/census#jdk [4] http://openjdk.java.net/projects/#reviewer-vote From james.laskey at oracle.com Mon Apr 19 13:19:17 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 19 Apr 2021 13:19:17 +0000 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: Yes > On Apr 19, 2021, at 10:12 AM, Claes Redestad wrote: > > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From vladimir.x.ivanov at oracle.com Mon Apr 19 13:23:10 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 19 Apr 2021 16:23:10 +0300 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <99a7d7c1-03b4-e1a1-d81c-7bd0aa26035d@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 19.04.2021 16:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > From daniel.daugherty at oracle.com Mon Apr 19 13:53:16 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 19 Apr 2021 09:53:16 -0400 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: yes Dan On 4/19/21 9:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From harold.seigel at oracle.com Mon Apr 19 14:00:06 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Mon, 19 Apr 2021 10:00:06 -0400 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <2608c955-3eda-f13c-72f9-a2f38bcec72a@oracle.com> Vote: yes Harold On 4/19/2021 9:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From mbien42 at gmail.com Mon Apr 19 14:03:50 2021 From: mbien42 at gmail.com (Michael Bien) Date: Mon, 19 Apr 2021 16:03:50 +0200 Subject: a case for reconsidering JEP 398: Deprecate the Applet API for Removal In-Reply-To: References: <9cd3b097-cf3a-4b81-af0e-f6b545ea7823@iPad> Message-ID: <52218a10-e0cb-f23f-9e06-ff9dfbbdcf0e@gmail.com> On 18.04.21 16:23, Alan Bateman wrote: > On 17/04/2021 20:44, Alan Snyder wrote: >> : >> Although Applet may not be the most important compatibility issue, >> the proposed resolution (keep the class but rewrite the methods to >> throw an exception) seems harmless. Why not do that? >> >> Perhaps we need a new deprecation category: "deprecated for >> defunctionalization? (in other words, it is not removed but stops >> working). >> >> (Sorry about the odd terminology, but I was unable to think of a >> better term that could not be accused of being ?politically incorrect?). >> > There are examples where terminally deprecated APIs have been > re-specified to work in a "degraded way" before eventually being > removed. Thread.stop(Throwable) was mentioned in one of the replies > here. That one was deprecated in Java 1.2, terminally deprecated and > re-specified to throw UOE in Java 9, and eventually removed in Java > 11. Thread.countStackFrames() is following a similar path. It was > deprecated in Java 1.2,? terminally deprecated and re-specified to > throw UOE in Java 14 and will eventually be proposed to be removed too. > > So yes, in some cases at least, it is possible to create a more gentle > off ramp for legacy or abandoned code. It may be that JEP 277 needs a > successor, in the form of an Informational JEP, to provide more up to > date guidelines on migration and timing of next steps after > deprecating an API for future removal. Most of mails on this thread > don't seem to concerned with JEP 398 but rather on some future JEP > that will propose to remove the Applet classes. It seems reasonable to > use the intervening period to explore migration options and see if > it's worth leaving some kind of carcass in place to keep the abandoned > code running in stand-alone code for a bit longer. > > -Alan I am wondering if the applet classes could be moved from java.desktop to a separate deprecated/retired module prior to removal (opposite of incubation). This would give the option to run code found on old master thesis CDs by adding this retired module to future JDKs - as long someone from the community is willing to maintain it (once its actually removed). On the other hand there will be always the option to use java 8 to run retro jars for experiments, even after the support expired - old JDKs won't just disappear. best regards, michael From maurizio.cimadamore at oracle.com Mon Apr 19 15:03:20 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 19 Apr 2021 16:03:20 +0100 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <7340cb4f-b4c7-ef65-2bf4-23e1c8b2e224@oracle.com> Vote: yes! Maurizio On 19/04/2021 14:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From Alan.Bateman at oracle.com Mon Apr 19 15:24:36 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Apr 2021 16:24:36 +0100 Subject: CFV: New OpenJDK Committer: Jorn Vernee In-Reply-To: <9b26720e-6c8b-ba4b-6b1a-a5fdc94952bf@oracle.com> References: <9b26720e-6c8b-ba4b-6b1a-a5fdc94952bf@oracle.com> Message-ID: <8bf1b861-6cc4-9ca4-ac2e-c10f0a2374c5@oracle.com> Vote: yes From jan.lahoda at oracle.com Mon Apr 19 15:28:48 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 19 Apr 2021 17:28:48 +0200 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <3bf0fabd-99f6-cc59-ff97-3f633d209840@oracle.com> Vote: yes On 19. 04. 21 15:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From Alan.Bateman at oracle.com Mon Apr 19 15:32:39 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Apr 2021 16:32:39 +0100 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <3bf0fabd-99f6-cc59-ff97-3f633d209840@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> <3bf0fabd-99f6-cc59-ff97-3f633d209840@oracle.com> Message-ID: <017214bd-84df-0f4d-c1a8-31d66785d8d7@oracle.com> Vote: yes From chris.hegarty at oracle.com Mon Apr 19 15:46:22 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 19 Apr 2021 15:46:22 +0000 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <0FF09157-A321-48A6-9BB0-75BD3ED35ECF@oracle.com> Vote: YES. -Chris. > On 19 Apr 2021, at 14:12, Claes Redestad wrote: > > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. From mandy.chung at oracle.com Mon Apr 19 16:05:05 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Apr 2021 09:05:05 -0700 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <25c0d8f2-6fa7-1e4f-c900-91f951148ee9@oracle.com> Vote: yes Mandy On 4/19/21 6:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From sean.mullan at oracle.com Mon Apr 19 13:49:31 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Apr 2021 09:49:31 -0400 Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: -bcc jdk-dev at openjdk.java.net On 4/18/21 7:50 PM, David Black wrote: > On Fri, 16 Apr 2021 at 04:05, > wrote: > > https://openjdk.java.net/jeps/411 > > ? Summary: Deprecate the Security Manager for removal in a future > ? release. The Security Manager dates from Java 1.0. It has not > been the > ? primary means of securing client-side Java code for many years, > and it > ? has rarely been used to secure server-side code. To move Java > forward, > ? we intend to deprecate the Security Manager for removal in > concert with > ? the legacy Applet API (JEP 398). > > - Mark > > > Hi, > How can those interested in the JEP get involved? Please provide feedback on the security-dev at openjdk.java.net list. --Sean > (I am asking because Atlassian makes use of a custom java security > manager, based on the manas security manager[0], to help mitigate SSRF > attacks[1]) > > > [0] - https://code.google.com/archive/p/manas-java-security/ > > [1] - > https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager/blob/master/example-security-manager-core/src/main/java/com/google/security/manas/ManasSecurityManager.java#L410 > > From naoto.sato at oracle.com Mon Apr 19 16:21:07 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 19 Apr 2021 09:21:07 -0700 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <7b0791ee-5f38-fc88-3155-eae758c8d562@oracle.com> Vote: yes Naoto On 4/19/21 6:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From brian.burkhalter at oracle.com Mon Apr 19 16:25:01 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 19 Apr 2021 16:25:01 +0000 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <582E6728-F74F-4B64-9E7F-AC89D63A20CF@oracle.com> Vote: yes On Apr 19, 2021, at 6:12 AM, Claes Redestad > wrote: I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. Jorn is a very active committer in the panama project with 133 commits to parama-foreign[1], many of which has been integrated into the mainline JDK. He has also contributed 20+ patches directly to the main JDK project[2], most of which I would consider significant. From daniel.fuchs at oracle.com Mon Apr 19 16:33:53 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Apr 2021 17:33:53 +0100 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <5d1b0291-741b-ff4c-7fac-2c5c7c3a8f76@oracle.com> Vote: yes best regards, -- daniel On 19/04/2021 14:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. From joe.darcy at oracle.com Mon Apr 19 16:43:22 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 19 Apr 2021 09:43:22 -0700 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <9b0addb9-fe2c-3fff-5307-0814308d92e5@oracle.com> Vote: yes -Joe On 4/19/2021 6:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From stefan.karlsson at oracle.com Mon Apr 19 16:47:18 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 19 Apr 2021 18:47:18 +0200 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: yes StefanK On 2021-04-19 15:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From vicente.romero at oracle.com Mon Apr 19 17:11:10 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 19 Apr 2021 13:11:10 -0400 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: vote: yes! Vicente On 4/19/21 9:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From brian.goetz at oracle.com Mon Apr 19 17:32:35 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Apr 2021 13:32:35 -0400 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: Yes On 4/19/2021 9:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From huizhe.wang at oracle.com Mon Apr 19 17:39:41 2021 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 19 Apr 2021 10:39:41 -0700 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <895e65b5-c595-0b9e-6e59-b9c2f79bb319@oracle.com> Vote: yes Joe (joehw) On 4/19/21 6:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. From paul.sandoz at oracle.com Mon Apr 19 19:34:13 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Apr 2021 19:34:13 +0000 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <0B4CCC12-08B3-4B22-B2CB-D5BABCC16488@oracle.com> Vote: yes Paul. From sean.coffey at oracle.com Mon Apr 19 19:46:19 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 19 Apr 2021 20:46:19 +0100 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <5c479f73-ba14-0307-e3e9-cea6ddaad869@oracle.com> Vote: yes regards, Sean. On 19/04/2021 14:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From lois.foltan at oracle.com Mon Apr 19 20:34:33 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 19 Apr 2021 16:34:33 -0400 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: yes Lois On 4/19/2021 9:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From stefan.johansson at oracle.com Tue Apr 20 10:41:06 2021 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 20 Apr 2021 12:41:06 +0200 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: <1e4f017b-12b4-b2b5-06bb-dbf43ea69a69@oracle.com> Vote: yes On 2021-04-19 15:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From vkempik at azul.com Tue Apr 20 11:42:26 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 20 Apr 2021 11:42:26 +0000 Subject: CFV: New JDK Committer: Anton Kozlov Message-ID: I hereby nominate Anton Kozlov (akozlov) to JDK Committer. Anton is a part of Zulu team at Azul working on OpenJDK development. He authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 implementation is among them, Anton made a significant contribution to this effort. So in total 13 contributions can be considered significant [4]. Votes are due by 14:00 UTC, 4 May 2021. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Regards, Vladimir [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html [4] https://github.com/openjdk/jdk/commit/283d64f8153 https://github.com/openjdk/jdk/commit/114e3c3e2da https://github.com/openjdk/jdk/commit/8a4a9117f5e https://github.com/openjdk/jdk/commit/dbc9e4b50cd https://github.com/openjdk/jdk/commit/b670efd896a https://github.com/openjdk/jdk/commit/682e78e89b3 https://github.com/openjdk/jdk/commit/d4c7db50609 https://github.com/openjdk/jdk/commit/2273f9555ab https://github.com/openjdk/jdk/commit/acd0e2560c9 https://github.com/openjdk/jdk/commit/ec9bee68660 https://github.com/openjdk/jdk/commit/f1e07806686 https://github.com/openjdk/jdk/commit/4b7bbaf5b00 https://github.com/openjdk/jdk/commit/a17ce440a56 From thomas.stuefe at gmail.com Tue Apr 20 11:49:42 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 20 Apr 2021 13:49:42 +0200 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes On Tue, Apr 20, 2021 at 1:43 PM Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 > From sgehwolf at redhat.com Tue Apr 20 12:03:36 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 20 Apr 2021 14:03:36 +0200 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <20454b243271cfaeed6ab3567fdb6c56c29d8951.camel@redhat.com> Vote: yes. On Tue, 2021-04-20 at 11:42 +0000, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. From david.holmes at oracle.com Tue Apr 20 12:08:56 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Apr 2021 22:08:56 +1000 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <83e476c8-06ae-84f3-846e-d7c2ecac52fc@oracle.com> Vote: yes David On 20/04/2021 9:42 pm, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 > From yan at azul.com Tue Apr 20 12:21:29 2021 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 20 Apr 2021 15:21:29 +0300 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: <20454b243271cfaeed6ab3567fdb6c56c29d8951.camel@redhat.com> References: <20454b243271cfaeed6ab3567fdb6c56c29d8951.camel@redhat.com> Message-ID: <4652ea9a-d7e5-5a2b-e83c-fc804465f5a4@azul.com> Vote: yes. > > On Tue, 2021-04-20 at 11:42 +0000, Vladimir Kempik wrote: >> I hereby nominate Anton Kozlov (akozlov) to JDK Committer. From Alan.Bateman at oracle.com Tue Apr 20 12:38:21 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Apr 2021 13:38:21 +0100 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <0a438246-db61-a6af-5f44-e9e841259616@oracle.com> Vote: yes From abrygin at azul.com Tue Apr 20 12:43:06 2021 From: abrygin at azul.com (Andrew Brygin) Date: Tue, 20 Apr 2021 15:43:06 +0300 Subject: CFV: New JDK Committer: Anton Kozlov Message-ID: <1c894ebb-97d7-9a89-750e-be8b38d6f36c@azul.com> Vote: yes Thanks, Andrew On Tue, Apr 20, 2021 at 1:43 PM Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 > From dcherepanov at azul.com Tue Apr 20 12:46:51 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Tue, 20 Apr 2021 15:46:51 +0300 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: <20454b243271cfaeed6ab3567fdb6c56c29d8951.camel@redhat.com> References: <20454b243271cfaeed6ab3567fdb6c56c29d8951.camel@redhat.com> Message-ID: Vote: yes > On Tue, 2021-04-20 at 11:42 +0000, Vladimir Kempik wrote: >> I hereby nominate Anton Kozlov (akozlov) to JDK Committer. From harold.seigel at oracle.com Tue Apr 20 13:07:57 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 20 Apr 2021 09:07:57 -0400 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes Harold On 4/20/2021 7:42 AM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From jdk at fiolino.de Tue Apr 20 13:29:21 2021 From: jdk at fiolino.de (Michael Kuhlmann) Date: Tue, 20 Apr 2021 15:29:21 +0200 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: <20210317214943.085423DBBFE@eggemoggin.niobe.net> References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> Message-ID: <196cc359-14f3-59d5-b0ba-69f47a8647b7@fiolino.de> Hi, sorry to coming back to this topic after more than a month, but I thought about it several times and want to share my thoughts. Maybe the ideas are long discussed already and nobody wants to read about it any more, but I looked in the archives and didn't find anything, so I'll give it a try. If it's a stupid idea, just let me know, I can live with that. I'm not a contributor, but I'm using Java for more than twenty years, since Java 1.1 precisely. I really love the idea of having primitive classes, that would be amazing! I'm just concerned that we won't make the best use out of it, especially because of compatibility reasons, and I was wondering if this can be achieved with a simple design change. The problems I'm seeing: * Primitive classes behave very different from standard object classes, but users don't immediately see this. You have to look into the definition to know whether an instance variable of SomeType will be initialized with null or a default value. * The suffixes .ref and .val don't fit into our concept of class names, they look ugly and can easily be mixed up * That we have to introduce .rel just for the existing classes is even worse * Existing classes like Optional will be mostly used in their original form. That's unfortunate, not that much for performance reasons but rather because such a value should never be null, so it could make most use out of this concept. * There's already the discussion to delay the implementation of typical primitive classes. Raffaelo proposed to invent classes Decimal64 and Decimal128, but it will not be added before this JEP is going live to avoid the need of the ugly compatibility hack. * We have to treat the seven existing primitive types in a very special way. People are already used to the idea that normal classes start with an uppercase character, but primitives are in lowercase characters. The predecessor language Oak even defined string as a primitive type. So why not picking up this idea and forcing all future primitive types to start with lowercase characters as well? Java has been very concrete in style guides but very relaxed in enforcing them in the past. You can define a class named 'integer' without problems. I would see this as a design bug and would rather enforce some stricter rules. So we could make it mandatory to have all primitive class names start with a lowercase character, more concrete to a character that can be converted to an uppercase character. Instead of creating a twin class names 'someClass.ref' what is proposed in the JEP, the reference class could be named like the primitive class just starting with the uppercase character. So if you define a primitive class 'someType', you immediately have a reference type 'SomeType' defined as well. Existing classes can be directly converted to primitive classes without breaking backwards compatibility. For instance, Optional would be declared as a primitive class 'optional', and existing code would still refer to the reference type 'Optional'. No special treatment of existing classes! Also Raffaelo can already add Decimal64 and Decimal128 to the JDK. Once this JEP is live, he only has to change the 'final' modifier to 'primitive' and make the 'D' in the class name lowercase. That's it! This is even more important for libraries who want to stay compatible for existing JDK releases and want to make use of this feature only later. There are some more benefits: * Primitive types are immediately identifiable by their class name * No ugly suffixes! * The naming fits very well into the existing primitives. long, float, boolean etc. already match with their wrapper classes Long, Float, Boolean. Only int and char have to be defined as aliases, as already proposed in the JEP. (I know that these primitives still need special handling under the hood, but I assume it won't be bigger than in the proposed solution, and for users it doesn't matter.) So in summary, I think it would improve readability and even more compatibility. Maybe I missed something, but wouldn't this make sense? On 3/17/21 10:49 PM, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/401 > > Summary: Enhance the Java object model with user-declared primitive > objects, which are class instances that lack object identity > and can be stored and passed directly, without object headers or > indirections. This is a preview language and VM feature. > > - Mark > From lois.foltan at oracle.com Tue Apr 20 14:03:08 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 20 Apr 2021 10:03:08 -0400 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <33b5e192-4c44-30c7-d6ad-99692a961e5a@oracle.com> Vote: yes Lois On 4/20/2021 7:42 AM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From roger.riggs at oracle.com Tue Apr 20 14:26:39 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 20 Apr 2021 10:26:39 -0400 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: Yes On 4/20/21 7:42 AM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. From brian.goetz at oracle.com Tue Apr 20 14:33:41 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 20 Apr 2021 10:33:41 -0400 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: <196cc359-14f3-59d5-b0ba-69f47a8647b7@fiolino.de> References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> <196cc359-14f3-59d5-b0ba-69f47a8647b7@fiolino.de> Message-ID: <3b36aa11-636d-8650-c7da-8bf13f985f46@oracle.com> Thanks for these thoughts. You may, or may not, find it comforting to know that all these concerns -- and the syntactic "hack" you propose -- have been considered extensively prior to settling on this design.? While it's not intrinsically a terrible idea, it's not as powerful as it first appears, and the problems that you are concerned about loom much larger when contemplating this big change than they are likely to actually be once you start using them. The main question you are addressing is: primitive classes are different, so should they look different?? It is a very natural temptation to want the new features to StAnD OuT and LooK D!FFeR3nt; these things are new and we are worried users will be confused.? (See https://www.thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/ for a more detailed description of this common phenomena.) Indeed, the original strawman syntax of lambdas was LOUD -- the first proposal used `#(int x, int y)(x * y)`.? When we changed this to `(x, y) -> x*y`, people first complained "that's too subtle!"? But it took all of about five minutes to get over this, and looking back to the original syntax, it feels like a hammer blow to the head.? "I'M NEW AND DIFFERENT", it shouts! Your proposal seems to be to continue using lower-case identifiers for primitive classes, and the leading-upper-case version for their reference projection.? This has been made before.? It has some apparent upsides, as you propose, but also some downsides. First, it takes decades of naming conventions and throws them out the window.? Previously, lower-case identifiers are either keywords (drawn from a fixed list, which includes `int` and friends) or variable/method names; type names (except for the ones which are keywords) begin with an upper case.? This proposal spills type names into the identifier space, meaning that we have lost valuable clues for both types and variable/method names.? This creates new problems as it attempts to solve others. Second, it creates an uncomfortable coupling between two identifiers, whose names are only related through an ad-hoc (and latin-centric) mechanism, upper-casing the first letter.? Where is the definition of `Point`?? Having it be in `primitive class point { }` is confusing.? The language and JVM have gone to great lengths to avoid making such couplings in the past. Third, it doesn't really solve all the problems you think it does; your point about Optional works exactly the same way under this proposal (you have to stick with non-flat `Optional` in existing APIs, and switch to `optional` to flatten where you can) as it does under the current plan (switch to `Optional.val` to flatten where you can.) Fourth, while this reduces the chance that a user will mistake a primitive class instance for a reference class instance, the cost of this is that APIs become, from the perspective of many users, gratuitously inconsistent.? Having some classes called "account" and others called "AccountGroup" will also be a persistent irritant. Fifth, using naming like this asks users to remember the identity-primitive polarity of every identifier if they want to get the benefits of flattening, and if they don't, they'll get the worst of both worlds.? Since `Point` is a valid type name, users are more likely to type `Point` when they mean `point` (or worse, do so inconsistently), and not get the runtime behavior they expect.? Freely mixing `point` and `Point` in programs is allowable, but creates potential performance issues and null injection issues at the boundaries.? If the boundary is small and well-defined (existing APIs that have been compatibly migrated), that's acceptable; if the boundary is pervasive and complex, this might be worse than nothing. So, this proposal is one that I put in the category of "seems attractive at first" (it was attractive to us, at first, too), but I don't think it is in the long-term best interests of the language. More comments inline. On 4/20/2021 9:29 AM, Michael Kuhlmann wrote: > Hi, > > sorry to coming back to this topic after more than a month, but I > thought about it several times and want to share my thoughts. Maybe > the ideas are long discussed already and nobody wants to read about it > any more, but I looked in the archives and didn't find anything, so > I'll give it a try. If it's a stupid idea, just let me know, I can > live with that. > > I'm not a contributor, but I'm using Java for more than twenty years, > since Java 1.1 precisely. I really love the idea of having primitive > classes, that would be amazing! I'm just concerned that we won't make > the best use out of it, especially because of compatibility reasons, > and I was wondering if this can be achieved with a simple design change. > > The problems I'm seeing: > * Primitive classes behave very different from standard object > classes, but users don't immediately see this. You have to look into > the definition to know whether an instance variable of SomeType will > be initialized with null or a default value. This is true, but relying on uninitialized variables isn't a particularly great idea either way (and the language doesn't even let you do this for locals.)?? This point, though, embodies a hard choice: are users better served by presenting all user-written abstractions the same way, or by having a mandatory syntactic designation for classes that have a certain runtime behavior?? For reasons above, I don't think users are well served by this (well-intentioned!) suggestion. > * The suffixes .ref and .val don't fit into our concept of class > names, they look ugly and can easily be mixed up I'm really glad you brought this up, because it's a common misperception. The docs on Valhalla feature .val and .ref prominently, because this is a critical piece of making the whole fit together and proving that we can solve the problems that Valhalla set out to solve.? But it is easy to jump from there to the assumption that users will be dealing with .ref and .val as often as C programmers have to deal with the difference between X and *X.? This is totally not the case! It has been a central design requirement to ensure that the use of .ref and .val are minimized; in most normal situations, they will never appear.? Motivating use cases for explicit .ref are: ?- When you explicitly do not want flattening, generally for memory consumption management.? This is an advanced use case for performance weenies. ?- When you want to support type circularity (e.g., a linked list node that points to the next node.)? Generally a low-level implementation concern. ?- (Later on) When you want to express generics _without_ specialization (List).? This is analogous to the "no flattening" case above, for the same reasons. Motivating use cases for .val are: ?- When you are using a migrated class and want to get flattening. This is a pure optimization; you can always use the unadorned class name here, you just don't get flattening. These all have to do with micro-performance adjustments. Additionally, users may choose to use P.ref to get "nullable primitives"; they may also figure into the story for "no good default", but this is not yet clear. (In an earlier version, `P.ref` was called `P.box`.) So: ?- Ugly: Ugly is in the eye of the beholder, but such opinions are (a) not universal and (b) not always permanent.? (The lambda syntax we have now was called ugly when it was first proposed.) ?- Don't fit: They don't fit because our mental model does not yet have a concept of "two ways to represent the same value".? That's the real challenge, not the syntax. ?- Easily mixed up: I don't think this will be the case in practice. > * That we have to introduce .rel just for the existing classes is even > worse Not sure what this point is about.? There's no `.rel`, and if you mean `.ref`, I'm not sure what you mean. > * Existing classes like Optional will be mostly used in their original > form. That's unfortunate, not that much for performance reasons but > rather because such a value should never be null, so it could make > most use out of this concept. Yes, but this is "glass 99% full."? In the early years of this project, people said we were insane to even consider trying to compatibly migrate Optional.? "It's impossible!? Just leave it be!"?? (These gave way to complaints about the complexity of migration, which is where we are now.)? I think the solution we have represents a dramatically-better-than-expected outcome; the alternate is almost certainly "sorry, Optional was born an identity class, and so it stays." The syntactic hack of "colonize `optional` as the new name" is just a different spelling of `Optional.val`; everything else about this is the same. > * There's already the discussion to delay the implementation of > typical primitive classes. Raffaelo proposed to invent classes > Decimal64 and Decimal128, but it will not be added before this JEP is > going live to avoid the need of the ugly compatibility hack. Same is true here; if we had Decimal64 now, regardless of how we spell it, it would be nullable, and then if we migrated it in-place, it would be an incompatible change for existing clients of `decimal64`.? In this case, this proposal does not improve compatibility, it just moves the breakage around. (General lesson: no matter how hard you think migration compatibility is, its harder.) > * We have to treat the seven existing primitive types in a very > special way. Not as special as "very" implies, but ... again, I think this is glass 1% empty.? Again, in the early days, it was considered unthinkable that we would be able to compatibly migrate `int` to be an object, but here we are.? Yes, there are some legacy considerations, but they are fewer than you probably think.? The main one is the most superficial -- that its name is spelled differently, and its box has an ad-hoc name too.? (But even this is half hidden behind the fact that you can spell `Integer` as `int.ref` if you like.)? The other is that you can't synchronize on Integer any more -- but if this is the biggest compatibility sin we've committed, then we've hit this out of the park. What other "very special" considerations are you worried about? > People are already used to the idea that normal classes start with an > uppercase character, but primitives are in lowercase characters. The > predecessor language Oak even defined string as a primitive type. So > why not picking up this idea and forcing all future primitive types to > start with lowercase characters as well? > > Java has been very concrete in style guides but very relaxed in > enforcing them in the past. You can define a class named 'integer' > without problems. I would see this as a design bug and would rather > enforce some stricter rules. > > So we could make it mandatory to have all primitive class names start > with a lowercase character, more concrete to a character that can be > converted to an uppercase character. Instead of creating a twin class > names 'someClass.ref' what is proposed in the JEP, the reference class > could be named like the primitive class just starting with the > uppercase character. For the reasons above, this seems like a small change but it ripples in unexpected ways, and not all the advantages actually work as they might first appear. The reality is that the visible warts of this proposal come, in no small part, from the desire for compatible migration for existing identity classes.? For example, we could have just said "Optional is frozen in time forever", and we might have been able to banish `.val` from the vocabulary, and then perhaps found another spelling for `.ref`.? But, is that the world we want to live in?? If we accept that compatible migration is a worthwhile goal, and "old optional" and "new optional" have any difference in semantics, there have to be two names, and the existing uses have to get the old name, since its burned into classfiles (`java/util/Optional;`). Should we just give up on compatible migration? The real shame is that the only difference in semantics that we can't paper over is nullability (and for Optional, this is adding insult to injury because the Whole Point of Optional is to not use null.)? If we could, then we wouldn't have to pick another name, and there would be different options available to us.? The pain of null keeps on giving. From vladimir.kozlov at oracle.com Tue Apr 20 14:44:13 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Apr 2021 07:44:13 -0700 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <3ac60cd9-a435-a9aa-fb13-69c0369efe7b@oracle.com> Vote: yes Thanks, Vladimir K On 4/20/21 4:42 AM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 > From adinn at redhat.com Tue Apr 20 15:00:12 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 20 Apr 2021 16:00:12 +0100 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <905541ad-fc54-7a7b-1ce5-1d9421c8dd65@redhat.com> Vote: yes On 20/04/2021 12:42, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Tue Apr 20 15:00:38 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 20 Apr 2021 16:00:38 +0100 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: yes On 19/04/2021 14:12, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From mikhailo.seledtsov at oracle.com Tue Apr 20 15:01:19 2021 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Tue, 20 Apr 2021 08:01:19 -0700 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <6f4d0611-dfae-659e-1efe-c85edf430c56@oracle.com> Vote: yes On 4/20/21 4:42 AM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From igor.ignatyev at oracle.com Tue Apr 20 15:09:01 2021 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Tue, 20 Apr 2021 15:09:01 +0000 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: yes -- Igor On Apr 19, 2021, at 6:12 AM, Claes Redestad > wrote: I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. From igor.ignatyev at oracle.com Tue Apr 20 15:09:21 2021 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Tue, 20 Apr 2021 15:09:21 +0000 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <6DD30048-9CFC-4699-B556-1DB227252B7F@oracle.com> Vote: yes -- Igor On Apr 20, 2021, at 4:42 AM, Vladimir Kempik > wrote: I hereby nominate Anton Kozlov (akozlov) to JDK Committer. From christoph.langer at sap.com Tue Apr 20 15:19:30 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 20 Apr 2021 15:19:30 +0000 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Claes > Redestad > Sent: Montag, 19. April 2021 15:12 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Jorn Vernee > > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author- > name%3A%22Jorn+Vernee%22&type=commits > [2] > https://github.com/openjdk/jdk/search?p=3&q=author- > name%3A%22Jorn+Vernee%22&type=commits > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From christoph.langer at sap.com Tue Apr 20 15:19:40 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 20 Apr 2021 15:19:40 +0000 Subject: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Vladimir > Kempik > Sent: Dienstag, 20. April 2021 13:42 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Anton Kozlov > > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017- > October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From martin.doerr at sap.com Tue Apr 20 15:50:58 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Apr 2021 15:50:58 +0000 Subject: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes /Martin From richard.reingruber at sap.com Tue Apr 20 16:27:36 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 20 Apr 2021 16:27:36 +0000 Subject: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes Richard. -----Original Message----- From: jdk-dev On Behalf Of Vladimir Kempik Sent: Dienstag, 20. April 2021 13:42 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Anton Kozlov I hereby nominate Anton Kozlov (akozlov) to JDK Committer. Anton is a part of Zulu team at Azul working on OpenJDK development. He authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 implementation is among them, Anton made a significant contribution to this effort. So in total 13 contributions can be considered significant [4]. Votes are due by 14:00 UTC, 4 May 2021. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Regards, Vladimir [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html [4] https://github.com/openjdk/jdk/commit/283d64f8153 https://github.com/openjdk/jdk/commit/114e3c3e2da https://github.com/openjdk/jdk/commit/8a4a9117f5e https://github.com/openjdk/jdk/commit/dbc9e4b50cd https://github.com/openjdk/jdk/commit/b670efd896a https://github.com/openjdk/jdk/commit/682e78e89b3 https://github.com/openjdk/jdk/commit/d4c7db50609 https://github.com/openjdk/jdk/commit/2273f9555ab https://github.com/openjdk/jdk/commit/acd0e2560c9 https://github.com/openjdk/jdk/commit/ec9bee68660 https://github.com/openjdk/jdk/commit/f1e07806686 https://github.com/openjdk/jdk/commit/4b7bbaf5b00 https://github.com/openjdk/jdk/commit/a17ce440a56 From daniel.fuchs at oracle.com Tue Apr 20 17:04:38 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 20 Apr 2021 18:04:38 +0100 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 20/04/2021 12:42, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. From stuart.marks at oracle.com Tue Apr 20 17:26:08 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 20 Apr 2021 10:26:08 -0700 Subject: CFV: New JDK Reviewer: Jorn Vernee In-Reply-To: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> References: <2bf41ae3-2d9e-9087-66c3-00ec2224d17c@oracle.com> Message-ID: Vote: yes On 4/19/21 6:12 AM, Claes Redestad wrote: > I hereby nominate Jorn Vernee (jvernee)[0] to OpenJDK Reviewer. > > Jorn is a very active committer in the panama project with 133 commits > to parama-foreign[1], many of which has been integrated into the > mainline JDK. He has also contributed 20+ patches directly to the main > JDK project[2], most of which I would consider significant. > > Outside of his joint work on things like the Memory Access API, Jorn has > made valuable contributions to java.lang.invoke and the JIT compilers. I > think making him a reviewer would help us all move things ahead in > several key areas in days to come. > > Votes are due by 14h00 UTC on Monday, the 3rd of May, 2021. > > Only current OpenJDK Reviewers (and above) [3] are eligible to > vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks! > > /Claes > > [0] https://openjdk.java.net/census#jvernee > [1] > https://github.com/openjdk/panama-foreign/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [2] > https://github.com/openjdk/jdk/search?p=3&q=author-name%3A%22Jorn+Vernee%22&type=commits > > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From jdk at fiolino.de Tue Apr 20 17:34:35 2021 From: jdk at fiolino.de (Michael Kuhlmann) Date: Tue, 20 Apr 2021 19:34:35 +0200 Subject: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: <3b36aa11-636d-8650-c7da-8bf13f985f46@oracle.com> References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> <196cc359-14f3-59d5-b0ba-69f47a8647b7@fiolino.de> <3b36aa11-636d-8650-c7da-8bf13f985f46@oracle.com> Message-ID: Hi Brian, thank you so much for the detailed answer! I understand that the case was already discussed in the very beginning. I was expecting this but wanted to understand the reasoning behind, so your explanation helped a lot. I don't want to open the whole discussion again, but since you gave such a detailed explanation, I want to answer them and share my motivation a bit further. Even though it's clear it won't change anything in the current proposal, it stays as it is, and I'm fine with it - at the end it's just another proposal from my side, nothing more. Please see my comments inline. On 4/20/21 4:33 PM, Brian Goetz wrote: > The main question you are addressing is: primitive classes are > different, so should they look different?? It is a very natural > temptation to want the new features to StAnD OuT and LooK D!FFeR3nt; > these things are new and we are worried users will be confused.? (See > https://www.thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/ > for a more detailed description of this common phenomena.) Indeed, the > original strawman syntax of lambdas was LOUD -- the first proposal used > `#(int x, int y)(x * y)`.? When we changed this to `(x, y) -> x*y`, > people first complained "that's too subtle!"? But it took all of about > five minutes to get over this, and looking back to the original syntax, > it feels like a hammer blow to the head.? "I'M NEW AND DIFFERENT", it > shouts! Yes, I think they should look different. Not too much, sure, but I wouldn't mind marking them a bit with a different naming scheme. Let me add that I don't think that primitive classes will be a frequent case for a standard developer. 98% of Java developers will probably never be tempted to ever write their own primitive classes. I see this as a feature only for some rather low-level types, like Optional or some of the java.util.time classes. I can hardly imagine much more, even including all the standard frameworks - only some mathematical libraries and some internal classes in collection frameworks will make use of it. Or the disruptor framework. But there the benefit is huge! So I don't think we'll be flooded with thousands of primitive classes looking different in the near future. Honestly I think even Point is not the best example. If you deal with image or 3D vector processing, having a lot of point and color elements in rather low level code, it might make sense to have this data in a condensed form using primitive classes, but if you model geometrical objects such as points, circles and rectangles, I would go for the standard reference types (or records probably). One side note, I sometimes find it confusing that enums look the same as normal domain classes, where they are often mixed upon. You can't instantiate them, they're usually immutable, you might want to compare them by identity. Good that normal IDEs render them with a different icon, but that doesn't help within Java code. I would not propose to have a different naming style for enums, at the end they're still relatively normal Java classes. But since primitive classes are even more different, and also much less frequent, it could justify a different naming style. But at the end, it's a matter of opinion, and I understand your concerns against such an "awkward look" for primitive class names. > > Your proposal seems to be to continue using lower-case identifiers for > primitive classes, and the leading-upper-case version for their > reference projection.? This has been made before.? It has some apparent > upsides, as you propose, but also some downsides. > > First, it takes decades of naming conventions and throws them out the > window.? Previously, lower-case identifiers are either keywords (drawn > from a fixed list, which includes `int` and friends) or variable/method > names; type names (except for the ones which are keywords) begin with an > upper case.? This proposal spills type names into the identifier space, > meaning that we have lost valuable clues for both types and > variable/method names.? This creates new problems as it attempts to > solve others. I agree, this is a downside. But you could argue that current primitive classes already are defined like this, they are types starting with a lowercase character, as method or variable names. That all primitive names are also listed as reserved keywords doesn't change much, it's more a language spec detail. And I wouldn't have come up with a proposal that is contrary to the standard naming conventions if the whole JEP wouldn't be already kind of revolutionary. Having all current classes automatically implement some marker interface is definitely something very new and unexpected, so I thought all gates are open already. ;) > > Second, it creates an uncomfortable coupling between two identifiers, > whose names are only related through an ad-hoc (and latin-centric) > mechanism, upper-casing the first letter.? Where is the definition of > `Point`?? Having it be in `primitive class point { }` is confusing.? The > language and JVM have gone to great lengths to avoid making such > couplings in the past. The latin centric mechanism is indeed something I was thinking about as well. (But honestly, if you define the chinese class ?, and refer to the reference type, then ?.ref also looks very latin-centric.) You could also ask, where is the class definition of Point.ref? Is Point the package name and ref the class name? But agreed, this argument still is more against the lowercase proposal. > > Third, it doesn't really solve all the problems you think it does; your > point about Optional works exactly the same way under this proposal (you > have to stick with non-flat `Optional` in existing APIs, and switch to > `optional` to flatten where you can) as it does under the current plan > (switch to `Optional.val` to flatten where you can.) That is true. But in future code, I assume it will be much less likely that interface designers will declare the return type with the concatenated name monster 'Optional.val' that with a lowercase type 'optional'. And it even reads nice: 'optional' looks like an optional String, as if optional with be a modifier like volatile. Of course, that's just my personal preference. > > Fourth, while this reduces the chance that a user will mistake a > primitive class instance for a reference class instance, the cost of > this is that APIs become, from the perspective of many users, > gratuitously inconsistent.? Having some classes called "account" and > others called "AccountGroup" will also be a persistent irritant. You will find examples where this is true, but I don't buy this one. ;) I can't imagine why someone would want to declare the domain class 'Account' as primitive? Especially when other classes in the same model are not. If someone is mixing primitive and reference types in the same model together, then he or she is doing something very wrong. I would be curious if there is a useful real life example for such a use case, but I can't find one. And even if they do so: It's not much better with the current proposal. If you ask the account for its groups, you get instances of AccountGroup, but if you ask the group for its accounts, you get instances of Account.ref. That's also irritant. > > Fifth, using naming like this asks users to remember the > identity-primitive polarity of every identifier if they want to get the > benefits of flattening, and if they don't, they'll get the worst of both > worlds.? Since `Point` is a valid type name, users are more likely to > type `Point` when they mean `point` (or worse, do so inconsistently), > and not get the runtime behavior they expect.? Freely mixing `point` and > `Point` in programs is allowable, but creates potential performance > issues and null injection issues at the boundaries.? If the boundary is > small and well-defined (existing APIs that have been compatibly > migrated), that's acceptable; if the boundary is pervasive and complex, > this might be worse than nothing. That's a valid point. (Point, hehe.) But as said, I would anyway not recommend to use primitive types for domain classes, but only low level types as Instant for example. You can still mix up Instant and instant, but people who do this are often those who anyway already mix up int and Integer or Long and long. > > So, this proposal is one that I put in the category of "seems attractive > at first" (it was attractive to us, at first, too), but I don't think it > is in the long-term best interests of the language. > > More comments inline. Thanks again, I'll comment them as well. > > On 4/20/2021 9:29 AM, Michael Kuhlmann wrote: >> The problems I'm seeing: >> * Primitive classes behave very different from standard object >> classes, but users don't immediately see this. You have to look into >> the definition to know whether an instance variable of SomeType will >> be initialized with null or a default value. > > This is true, but relying on uninitialized variables isn't a > particularly great idea either way (and the language doesn't even let > you do this for locals.)?? This point, though, embodies a hard choice: > are users better served by presenting all user-written abstractions the > same way, or by having a mandatory syntactic designation for classes > that have a certain runtime behavior?? For reasons above, I don't think > users are well served by this (well-intentioned!) suggestion. Hmh, depends. I agree relying on uninitialized variables isn't a great idea, but people do that. They know when the variable is of type int, it's initialized to zero, but if it's of type Point, they might wonder why it's set to (0,0), something like the upper left corner of the screen. Again, it's a matter of opinion. > >> * The suffixes .ref and .val don't fit into our concept of class >> names, they look ugly and can easily be mixed up > > I'm really glad you brought this up, because it's a common misperception. > > [Some good context here] Thanks for the insight. And to be honest, I have no concerns against the .ref suffix; one would rarely explicitly use the reference type when the value type could also be used, and if so, it's perhaps a good idea to mark this more prominent. Also primitive types will rarely be used in standard collections, I assume. So an argument for the suffix style. what I find sad is that we're in the need for the .val suffix. But that better explained in the next section. > >> * That we have to introduce .rel just for the existing classes is even >> worse > > Not sure what this point is about.? There's no `.rel`, and if you mean > `.ref`, I'm not sure what you mean. Yeah, my bad, here I already mixed those two up. Or I types too fast. I meant the .val suffix, and that's AFAIU only introduced for the existing classes. So in future we'll have two different naming schemas for the same concept: * Existing classes can be addressed using Instant for the reference type, and Instant.val for the value type * New classes can be addressed using Point.ref for the reference type and Point for the value type. So there are two distinct naming schemas for the same kind of reference/value pairs. The only difference is that the one class was introduced before the JEP, and the second one after that. And for libraries who want to stay compatible with older JDKs, but eventually want to make use of this feature in future releases, it's even more complicated. I was trying to find a solution to get around with this. To make use of your metaphor, if the glass is 90% full, but we can fill it up to 100% without additional overhead, it would be even better. > >> * Existing classes like Optional will be mostly used in their original >> form. That's unfortunate, not that much for performance reasons but >> rather because such a value should never be null, so it could make >> most use out of this concept. > > Yes, but this is "glass 99% full."? In the early years of this project, > people said we were insane to even consider trying to compatibly migrate > Optional.? "It's impossible!? Just leave it be!"?? (These gave way to > complaints about the complexity of migration, which is where we are > now.)? I think the solution we have represents a > dramatically-better-than-expected outcome; the alternate is almost > certainly "sorry, Optional was born an identity class, and so it stays." > > The syntactic hack of "colonize `optional` as the new name" is just a > different spelling of `Optional.val`; everything else about this is the > same. True, at the end it's just a naming concept, but at least a consistent one for old and new classes. (But I generally agree to your arguments, and thank you for the insights into the evaluation of these concepts.) > >> * We have to treat the seven existing primitive types in a very >> special way. > > Not as special as "very" implies, but ... again, I think this is glass > 1% empty.? Again, in the early days, it was considered unthinkable that > we would be able to compatibly migrate `int` to be an object, but here > we are.? Yes, there are some legacy considerations, but they are fewer > than you probably think.? The main one is the most superficial -- that > its name is spelled differently, and its box has an ad-hoc name too. > (But even this is half hidden behind the fact that you can spell > `Integer` as `int.ref` if you like.)? The other is that you can't > synchronize on Integer any more -- but if this is the biggest > compatibility sin we've committed, then we've hit this out of the park. > > What other "very special" considerations are you worried about? I wonder if we can get around of all these inconsistencies. Not only between legacy code and post-JEP401-code, but also between core primitives and new ones. If there wouldn't be a 'float' primitive yet, we would call the class Float and the boxed type Float.ref. Or if it would've been introduced a bit earlier, it would have been Float.val and Float. But it's not, the primitive name if float and the boxed type Float, just as in my proposal. What I read is that you plan to define aliases for, e.g., float that refers to Float.val. This wouldn't be necessary if the naming scheme would already cover the existing pattern of primitive types. Except int and char which are falling out a bit. So the idea is avoiding three different naming schemes for the same concept. And if someone want to invent a type for imaginary numbers, they can call the class imaginary, the boxed type is Imaginary, and it fits very well into the existing primitive types. It just feels similar. > >> People are already used to the idea that normal classes start with an >> uppercase character, but primitives are in lowercase characters. The >> predecessor language Oak even defined string as a primitive type. So >> why not picking up this idea and forcing all future primitive types to >> start with lowercase characters as well? >> >> Java has been very concrete in style guides but very relaxed in >> enforcing them in the past. You can define a class named 'integer' >> without problems. I would see this as a design bug and would rather >> enforce some stricter rules. >> >> So we could make it mandatory to have all primitive class names start >> with a lowercase character, more concrete to a character that can be >> converted to an uppercase character. Instead of creating a twin class >> names 'someClass.ref' what is proposed in the JEP, the reference class >> could be named like the primitive class just starting with the >> uppercase character. > > For the reasons above, this seems like a small change but it ripples in > unexpected ways, and not all the advantages actually work as they might > first appear. > > > The reality is that the visible warts of this proposal come, in no small > part, from the desire for compatible migration for existing identity > classes.? For example, we could have just said "Optional is frozen in > time forever", and we might have been able to banish `.val` from the > vocabulary, and then perhaps found another spelling for `.ref`.? But, is > that the world we want to live in?? If we accept that compatible > migration is a worthwhile goal, and "old optional" and "new optional" > have any difference in semantics, there have to be two names, and the > existing uses have to get the old name, since its burned into classfiles > (`java/util/Optional;`). Should we just give up on compatible migration? > > The real shame is that the only difference in semantics that we can't > paper over is nullability (and for Optional, this is adding insult to > injury because the Whole Point of Optional is to not use null.)? If we > could, then we wouldn't have to pick another name, and there would be > different options available to us.? The pain of null keeps on giving. > That is so true, and I agre completely. Thank you very much for the detailed explanation. I see that we'll be using .val and .ref in future, and I agree that there will be only few cases where it's really needed. > From brian.goetz at oracle.com Tue Apr 20 18:46:57 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 20 Apr 2021 14:46:57 -0400 Subject: [External] : Re: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> <196cc359-14f3-59d5-b0ba-69f47a8647b7@fiolino.de> <3b36aa11-636d-8650-c7da-8bf13f985f46@oracle.com> Message-ID: <5490afee-88fd-0476-7367-68f1cf5f9878@oracle.com> > Let me add that I don't think that primitive classes will be a > frequent case for a standard developer. 98% of Java developers will > probably never be tempted to ever write their own primitive classes. I > see this as a feature only for some rather low-level types, like > Optional or some of the java.util.time classes. I can hardly imagine > much more, even including all the standard frameworks - only some > mathematical libraries and some internal classes in collection > frameworks will make use of it. Or the disruptor framework. But there > the benefit is huge! I hope this will be true, but I'm also aware that developers don't always do what you expect them to.? Developers can be inordinately attracted to "performance" features; if some blog author says "primitive classes are faster" (which surely will happen), that may motivate a lot of developers using them, even when they shouldn't, at least for the first few years until more universally-accepted "best practices" emerge. > But at the end, it's a matter of opinion, and I understand your > concerns against such an "awkward look" for primitive class names. FWIW, in the early days of OO languages, we saw a lot of conventions like "interface names begin with `I`" and "field names begin with `f_`.? I'm glad that burned itself out before Java came along. Also FWIW, one of the considerations when choosing this was: in the difference between "Point by value" and "Point by reference", which is more important to readers, Point-ness, or val/ref-ness?? We deemed it to be the data type, which is why that comes first and the carrier marking, if any, comes last. > >> >> Fourth, while this reduces the chance that a user will mistake a >> primitive class instance for a reference class instance, the cost of >> this is that APIs become, from the perspective of many users, >> gratuitously inconsistent.? Having some classes called "account" and >> others called "AccountGroup" will also be a persistent irritant. > > You will find examples where this is true, but I don't buy this one. > ;) I can't imagine why someone would want to declare the domain class > 'Account' as primitive? Especially when other classes in the same > model are not. If someone is mixing primitive and reference types in > the same model together, then he or she is doing something very wrong. > I would be curious if there is a useful real life example for such a > use case, but I can't find one. I think it goes back to the "performance is (over)important" thing. I can easily imagine developers will declare the classes that can be primitives, as primitives, only using identity where they need to. Whether this is good or bad is another question, but I suspect it will happen.? (We see this today with enums and records; where people can use the more restricted form, they do, because of the benefits.? We see this as normal, in part because we've set up enums and records as "just being classes".) > And even if they do so: It's not much better with the current > proposal. If you ask the account for its groups, you get instances of > AccountGroup, but if you ask the group for its accounts, you get > instances of Account.ref. That's also irritant. No, that's not right.? If I have: ??? Point.val p1 = ... ??? Point.ref p2 = p1 then `p1 == p2` and `p1.getClass() == p2.getClass()`.? The ref/val is just the "envelope"; the enclosed object is the same either way. > >> >>> * The suffixes .ref and .val don't fit into our concept of class >>> names, they look ugly and can easily be mixed up >> >> I'm really glad you brought this up, because it's a common >> misperception. >> >> [Some good context here] > > Thanks for the insight. And to be honest, I have no concerns against > the .ref suffix; one would rarely explicitly use the reference type > when the value type could also be used, and if so, it's perhaps a good > idea to mark this more prominent. Also primitive types will rarely be > used in standard collections, I assume. So an argument for the suffix > style. > > what I find sad is that we're in the need for the .val suffix. But > that better explained in the next section. Yes, I am sad too!? But realistically, this _will_ be rare, because relatively few classes will get migrated.? (Probably 90% of the pain will be with Optional.)? But there's a principle here, too: make the migrated classes carry the cost of migration, so that all-new code doesn't have to.? In the all-new-code world, you never say .val except in very strange circumstances. > So there are two distinct naming schemas for the same kind of > reference/value pairs. The only difference is that the one class was > introduced before the JEP, and the second one after that. Close -- the difference is that the class was _migrated to a primitive class_.? One can imagine classes being born identity classes after this JEP, and still migrating.? Not all classes will migrate on a special Migration Day.? But yes, your point stands, if the class was born differently, it gets the reversed naming convention.? Still, most of the time, in either case, you can just say Optional, and the system will do something reasonable.? Only in the conjunction of (a) migrated types and (b) performance-obsession will you tune the envelope of each declaration explicitly. > If there wouldn't be a 'float' primitive yet, we would call the class > Float and the boxed type Float.ref. Or if it would've been introduced > a bit earlier, it would have been Float.val and Float. But it's not, > the primitive name if float and the boxed type Float, just as in my > proposal. > > What I read is that you plan to define aliases for, e.g., float that > refers to Float.val. This wouldn't be necessary if the naming scheme > would already cover the existing pattern of primitive types. Except > int and char which are falling out a bit. > > So the idea is avoiding three different naming schemes for the same > concept. > > And if someone want to invent a type for imaginary numbers, they can > call the class imaginary, the boxed type is Imaginary, and it fits > very well into the existing primitive types. It just feels similar. This is the subject of JEP 402.? Currently we have eight primitive / box pairs (of which two have the unfortunate characteristic that the name is not even the same modulo case of the first character, Integer and Character.)? The plan is to: ?- migrate the box classes to primitive classes; ?- define int.ref to mean Integer; ?- define Integer.val to mean int. This way, the only special thing is that these legacy classes have ad-hoc aliases; int and Integer.val are the same type, and int.ref and Integer are the same type.? Clearly we can't get rid of these names, they're too pervasive, but we can tame them a bit. Cheers, -Brian From daniel.daugherty at oracle.com Tue Apr 20 19:04:56 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 20 Apr 2021 15:04:56 -0400 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <12677fdf-6665-04d1-34c7-072bc01ae225@oracle.com> Vote: yes Dan On 4/20/21 7:42 AM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From goetz.lindenmaier at sap.com Tue Apr 20 19:32:51 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Apr 2021 19:32:51 +0000 Subject: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Vladimir > Kempik > Sent: Tuesday, April 20, 2021 1:42 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Anton Kozlov > > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017- > October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From felix.yang at huawei.com Wed Apr 21 02:46:02 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 21 Apr 2021 02:46:02 +0000 Subject: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] On Behalf Of > Vladimir Kempik > Sent: Tuesday, April 20, 2021 7:42 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Anton Kozlov > > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017- > October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From ningsheng.jian at arm.com Wed Apr 21 03:14:53 2021 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 21 Apr 2021 11:14:53 +0800 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <11a6e168-a117-5edb-a373-b8381c7dc5ff@arm.com> Vote: yes -Ningsheng On 4/20/21 7:42 PM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 > From abdul.kolarkunnu at oracle.com Wed Apr 21 03:41:04 2021 From: abdul.kolarkunnu at oracle.com (abdul.kolarkunnu at oracle.com) Date: Wed, 21 Apr 2021 09:11:04 +0530 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <8e5fc4e9-edde-6ca8-27c0-0cd65b2b6d3a@oracle.com> Vote: yes -Muneer On 20/04/21 5:12 pm, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From jdk at fiolino.de Wed Apr 21 06:12:05 2021 From: jdk at fiolino.de (Michael Kuhlmann) Date: Wed, 21 Apr 2021 08:12:05 +0200 Subject: [External] : Re: New candidate JEP: 401: Primitive Objects (Preview) In-Reply-To: <5490afee-88fd-0476-7367-68f1cf5f9878@oracle.com> References: <20210317214943.085423DBBFE@eggemoggin.niobe.net> <196cc359-14f3-59d5-b0ba-69f47a8647b7@fiolino.de> <3b36aa11-636d-8650-c7da-8bf13f985f46@oracle.com> <5490afee-88fd-0476-7367-68f1cf5f9878@oracle.com> Message-ID: On 4/20/21 8:46 PM, Brian Goetz wrote: > > >> Let me add that I don't think that primitive classes will be a >> frequent case for a standard developer. 98% of Java developers will >> probably never be tempted to ever write their own primitive classes. I >> see this as a feature only for some rather low-level types, like >> Optional or some of the java.util.time classes. I can hardly imagine >> much more, even including all the standard frameworks - only some >> mathematical libraries and some internal classes in collection >> frameworks will make use of it. Or the disruptor framework. But there >> the benefit is huge! > > I hope this will be true, but I'm also aware that developers don't > always do what you expect them to.? Developers can be inordinately > attracted to "performance" features; if some blog author says "primitive > classes are faster" (which surely will happen), that may motivate a lot > of developers using them, even when they shouldn't, at least for the > first few years until more universally-accepted "best practices" emerge. Hey, that would be a good argument for having a different naming convention, so that developers immediately see "wow, the class looks different, shall I really use that concept for my Customer domain class?" :D Okay, I'll be quiet already... > >> But at the end, it's a matter of opinion, and I understand your >> concerns against such an "awkward look" for primitive class names. > > FWIW, in the early days of OO languages, we saw a lot of conventions > like "interface names begin with `I`" and "field names begin with `f_`. > I'm glad that burned itself out before Java came along. Oh, that was even long after Java was invented. In OSGi/SWT/RCP programming it is still standard to mark all interfaces with an 'I' as the first character. And even worse, there's a Checkstyle rule to enforce that all abstract classes start with 'Abstract'. I never understood why someone should do this. > > Also FWIW, one of the considerations when choosing this was: in the > difference between "Point by value" and "Point by reference", which is > more important to readers, Point-ness, or val/ref-ness?? We deemed it to > be the data type, which is why that comes first and the carrier marking, > if any, comes last. I agree, when it comes to the semantics of, for instance, the java.util.time classes, it shouldn't make a difference that Instant is a primitive type and TimeZone is not. On the other hand, something like an Optional should anyway not treated as an independent object. It's rather annotating some field or return type as being optional. There it makes sense to have an exceptional naming. But this isn't really an argument for my proposal because developers are still free to give their primitive classes lowercased names when it makes sense. >> And even if they do so: It's not much better with the current >> proposal. If you ask the account for its groups, you get instances of >> AccountGroup, but if you ask the group for its accounts, you get >> instances of Account.ref. That's also irritant. > > No, that's not right.? If I have: > > ??? Point.val p1 = ... > ??? Point.ref p2 = p1 > > then `p1 == p2` and `p1.getClass() == p2.getClass()`.? The ref/val is > just the "envelope"; the enclosed object is the same either way. Oh, I missed this. I was assuming it's like the difference between boxed and unboxed types as of now. I should read the JEPs 401 and 402 more carefully. Thanks for the clarification! From mikael.vidstedt at oracle.com Wed Apr 21 06:35:22 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 21 Apr 2021 06:35:22 +0000 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <45C8829C-FF7E-43DC-866F-E962730CA5C9@oracle.com> Vote: yes Cheers, Mikael > On Apr 20, 2021, at 4:42 AM, Vladimir Kempik wrote: > > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From coleen.phillimore at oracle.com Wed Apr 21 15:17:55 2021 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Apr 2021 11:17:55 -0400 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes On 4/20/21 7:42 AM, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From chris.hegarty at oracle.com Wed Apr 21 15:21:14 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 21 Apr 2021 15:21:14 +0000 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: <3C254C12-FCBA-480F-8928-BF3945E790B8@oracle.com> Vote: YES -Chris. > On 20 Apr 2021, at 12:42, Vladimir Kempik wrote: > > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > From vladimir.x.ivanov at oracle.com Wed Apr 21 15:25:16 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 21 Apr 2021 18:25:16 +0300 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 20.04.2021 14:42, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. From volker.simonis at gmail.com Wed Apr 21 16:56:13 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 21 Apr 2021 18:56:13 +0200 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes On Tue, Apr 20, 2021 at 1:42 PM Vladimir Kempik wrote: > > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From mark.reinhold at oracle.com Thu Apr 22 18:27:41 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 22 Apr 2021 11:27:41 -0700 (PDT) Subject: New candidate JEP: 412: Foreign Function & Memory API (Incubator) Message-ID: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> https://openjdk.java.net/jeps/412 Summary: Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. - Mark From gerard.ziemski at oracle.com Thu Apr 22 21:42:56 2021 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 22 Apr 2021 21:42:56 +0000 Subject: New candidate JEP: 412: Foreign Function & Memory API (Incubator) In-Reply-To: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> References: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> Message-ID: <31FDAC07-2070-4AFD-ACB2-D967A1676DF4@oracle.com> hi, I read this JEP only once so far, but one thing that I immediately noticed was whether MethodType is really necessary when constructing a MethodHandle, or whether that info can be inferred from FunctionDescriptor as in this given example: MethodHandle qsort = CLinker.getInstance().downcallHandle( LibraryLookup.ofDefault().lookup("qsort").get(), MethodType.methodType(void.class, MemoryAddress.class, long.class, long.class, MemoryAddress.class), FunctionDescriptor.ofVoid(C_POINTER, C_LONG, C_LONG, C_POINTER) ); Seems to me that FunctionDescriptor and MethodType describe the same layout? cheers > On Apr 22, 2021, at 1:27 PM, mark.reinhold at oracle.com wrote: > > https://openjdk.java.net/jeps/412 > > Summary: Introduce an API by which Java programs can interoperate with > code and data outside of the Java runtime. By efficiently invoking > foreign functions (i.e., code outside the JVM), and by safely accessing > foreign memory (i.e., memory not managed by the JVM), the API enables > Java programs to call native libraries and process native data without > the brittleness and danger of JNI. > > - Mark From alex.buckley at oracle.com Thu Apr 22 22:04:19 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 22 Apr 2021 15:04:19 -0700 Subject: New candidate JEP: 412: Foreign Function & Memory API (Incubator) In-Reply-To: <31FDAC07-2070-4AFD-ACB2-D967A1676DF4@oracle.com> References: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> <31FDAC07-2070-4AFD-ACB2-D967A1676DF4@oracle.com> Message-ID: On 4/22/2021 2:42 PM, Gerard Ziemski wrote: > I read this JEP only once so far, but one thing that I immediately noticed was whether MethodType is really necessary when constructing a MethodHandle, or whether that info can be inferred from FunctionDescriptor as in this given example: > > > MethodHandle qsort = CLinker.getInstance().downcallHandle( > LibraryLookup.ofDefault().lookup("qsort").get(), > MethodType.methodType(void.class, MemoryAddress.class, long.class, > long.class, MemoryAddress.class), > FunctionDescriptor.ofVoid(C_POINTER, C_LONG, C_LONG, C_POINTER) > ); > > Seems to me that FunctionDescriptor and MethodType describe the same layout? Please review the section "Describing C types in Java": https://openjdk.java.net/jeps/412#Describing-C-types-in-Java It describes how the MethodType relates to the FunctionDescriptor. The interesting case is the final example, regarding structured data. Alex From forax at univ-mlv.fr Thu Apr 22 22:54:32 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 23 Apr 2021 00:54:32 +0200 (CEST) Subject: New candidate JEP: 412: Foreign Function & Memory API (Incubator) In-Reply-To: <31FDAC07-2070-4AFD-ACB2-D967A1676DF4@oracle.com> References: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> <31FDAC07-2070-4AFD-ACB2-D967A1676DF4@oracle.com> Message-ID: <1344918593.748460.1619132072195.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Gerard Ziemski" > ?: "panama-dev at openjdk.java.net'" > Cc: "Maurizio Cimadamore" , "jdk-dev" > Envoy?: Jeudi 22 Avril 2021 23:42:56 > Objet: Re: New candidate JEP: 412: Foreign Function & Memory API (Incubator) > hi, Hi, > > I read this JEP only once so far, but one thing that I immediately noticed was > whether MethodType is really necessary when constructing a MethodHandle, or > whether that info can be inferred from FunctionDescriptor as in this given > example: > > > MethodHandle qsort = CLinker.getInstance().downcallHandle( > LibraryLookup.ofDefault().lookup("qsort").get(), > MethodType.methodType(void.class, MemoryAddress.class, long.class, > long.class, MemoryAddress.class), > FunctionDescriptor.ofVoid(C_POINTER, C_LONG, C_LONG, C_POINTER) > ); > > Seems to me that FunctionDescriptor and MethodType describe the same layout ? MethodType is the Java signature, FunctionDescriptor is the C signature, the CLinker is the one knowing the C convention on the actual Archiecture/OS (by example, the first two parameters are in registers, etc) so CLinker is able to expose the symbol "qsort" with the FunctionDescriptor as a method handle with the MethodType. As noted at the end of the JEP, this is the low level API, there is a tool named jextract that provides a more high level API by generating the mapping from a C header file. > > > cheers regards, R?mi > >> On Apr 22, 2021, at 1:27 PM, mark.reinhold at oracle.com wrote: >> >> https://openjdk.java.net/jeps/412 >> >> Summary: Introduce an API by which Java programs can interoperate with >> code and data outside of the Java runtime. By efficiently invoking >> foreign functions (i.e., code outside the JVM), and by safely accessing >> foreign memory (i.e., memory not managed by the JVM), the API enables >> Java programs to call native libraries and process native data without >> the brittleness and danger of JNI. >> > > - Mark From maurizio.cimadamore at oracle.com Fri Apr 23 01:05:09 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 23 Apr 2021 02:05:09 +0100 Subject: New candidate JEP: 412: Foreign Function & Memory API (Incubator) In-Reply-To: <31FDAC07-2070-4AFD-ACB2-D967A1676DF4@oracle.com> References: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> <31FDAC07-2070-4AFD-ACB2-D967A1676DF4@oracle.com> Message-ID: Hi, as other have replied in this thread, while it is tempting to try to compress the information more (we surely have tried many times!), down to a single vector of types - in reality there are truly two things which needs to be described: * which Java signatures will Java clients use to interact with the method handle (this is not dissimilar to the method type specified in a MethodHandle.Lookup call) * which C signature will the downcall method handle target A single Java type (e.g. MemorySegment) can correspond to many different C types (e.g. all structs and union types). While in the reverse direction the freedom is not that dramatic, there is some freedom - for instance on 64 bit systems, a C_SHORT can be mapped back to a Java short, or into a Java char type (as they are both 16 bits). Additional degrees of freedom might arise at a later point: we might have additional Java carrier types for vectors (see vector API), half floats, long doubles, etc. (especially with the help of Valhalla), so e.g. it is a legitimate for a user to decide whether to map a C "long double" back to a Java double (with some loss), or to use a more lossless carrier. So, in the general case, the relationship between Java types and C descriptors is N:N, and, because of that, inference doesn't seem like a good way to go. That said, the presence of the method type is, I think, also beneficial, as Java types are laid out explicitly; if things are inferred from the function descriptor, some of the failures that are now detected at downcall method handle creation will only be detected when the method handle is first invoked (that is, when the user expectation about what the inference process happens to be incorrect). Cheers Maurizio On 22/04/2021 22:42, Gerard Ziemski wrote: > hi, > > I read this JEP only once so far, but one thing that I immediately noticed was whether MethodType is really necessary when constructing a MethodHandle, or whether that info can be inferred from FunctionDescriptor as in this given example: > > > MethodHandle qsort = CLinker.getInstance().downcallHandle( > LibraryLookup.ofDefault().lookup("qsort").get(), > MethodType.methodType(void.class, MemoryAddress.class, long.class, > long.class, MemoryAddress.class), > FunctionDescriptor.ofVoid(C_POINTER, C_LONG, C_LONG, C_POINTER) > ); > > Seems to me that FunctionDescriptor and MethodType describe the same layout? > > > cheers > >> On Apr 22, 2021, at 1:27 PM, mark.reinhold at oracle.com wrote: >> >> https://openjdk.java.net/jeps/412 >> >> Summary: Introduce an API by which Java programs can interoperate with >> code and data outside of the Java runtime. By efficiently invoking >> foreign functions (i.e., code outside the JVM), and by safely accessing >> foreign memory (i.e., memory not managed by the JVM), the API enables >> Java programs to call native libraries and process native data without >> the brittleness and danger of JNI. >> >> - Mark From stefan.karlsson at oracle.com Fri Apr 23 05:12:43 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 23 Apr 2021 07:12:43 +0200 Subject: CFV: New JDK Committer: Anton Kozlov In-Reply-To: References: Message-ID: Vote: yes StefanK On 2021-04-20 13:42, Vladimir Kempik wrote: > I hereby nominate Anton Kozlov (akozlov) to JDK Committer. > > Anton is a part of Zulu team at Azul working on OpenJDK development. He > authored and co-authored 18 changes [3] to JDK project. A notable JEP-391 > implementation is among them, Anton made a significant contribution to this > effort. So in total 13 contributions can be considered significant [4]. > Votes are due by 14:00 UTC, 4 May 2021. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > Regards, Vladimir > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/commits?author=akozlov at openjdk.org > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024698.html > [4] > https://github.com/openjdk/jdk/commit/283d64f8153 > https://github.com/openjdk/jdk/commit/114e3c3e2da > https://github.com/openjdk/jdk/commit/8a4a9117f5e > https://github.com/openjdk/jdk/commit/dbc9e4b50cd > https://github.com/openjdk/jdk/commit/b670efd896a > https://github.com/openjdk/jdk/commit/682e78e89b3 > https://github.com/openjdk/jdk/commit/d4c7db50609 > https://github.com/openjdk/jdk/commit/2273f9555ab > https://github.com/openjdk/jdk/commit/acd0e2560c9 > https://github.com/openjdk/jdk/commit/ec9bee68660 > https://github.com/openjdk/jdk/commit/f1e07806686 > https://github.com/openjdk/jdk/commit/4b7bbaf5b00 > https://github.com/openjdk/jdk/commit/a17ce440a56 From maurizio.cimadamore at oracle.com Fri Apr 23 14:49:51 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 23 Apr 2021 15:49:51 +0100 Subject: New candidate JEP: 412: Foreign Function & Memory API (Incubator) In-Reply-To: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> References: <20210422182741.B3DA43E10CB@eggemoggin.niobe.net> Message-ID: Hi Some of you might wonder as to why the API in this JEP is "still" incubating, and what the exit criteria from incubation are. This is, we think, a valid point, and one which we'd like to clarify/address a bit here. First, while it's true that the API has improved considerably over the last couple of years, we believe the changes described in this latest JEP constitute, to date, the best effort to capture all the moving part when it comes to managing off-heap memory. The addition of the new ResourceScope/SegmentAllocator abstractions has been instrumental in order to address several issues in the previous iterations of the API. As with all biggie API changes, there is a source compatibility price to pay; I believe this iteration has a much higher chance to break existing code written against the Foreign Memory Access API (for one, MemorySegment is no longer an AutoCloseable). Because of this, it seemed sensible to give them a bit more bake time, rather than declaring it done. Secondly, there's the issue of VM optimizations; while a lot of work has been done in this area, there are still two ways in which the VM support for the Foreign Function and Memory API lags behind. Optimization of long loops, while improved, still doesn't contain certain bits which are crucial to make memory segment access fast [1]. Without those, clients are forced to workaround some of the issues, by using `int` (and then cast things back to `long`), which is cumbersome and, we feel, way too sharp for a "final" API. And, while this iteration vastly improves support for upcalls (calling Java from native code), in general the linker support is still missing intrinsification support in few important cases, such as when arguments are spilled on the stack [2]. While this is not rocket science, it's more work that needs to be done, so that user can enjoy a predictable performance model, both when accessing off-memory, and when calling native functions. Lastly, while the concept of restricted methods has been present in previous JEPs, this JEP is the first one which adds a new launcher option for it (--enable-native-access). While the impact on clients should be limited (after all, even before some command line option was required - e.g. `-Dforeign.restricted=permit`), we feel that this is a big enough change to warrant for another round of incubation, to make sure that the new option is working as expected. There is also more work to be done there, to integrate support for restricted methods in javadoc (so that restricted methods are rendered in a special way, similarly to preview methods) which we won't be able to fully deliver in 17. So, while we understand that there might be a desire to move things forwards, we felt moving to preview (or finalize the API) at this point would have been simply premature. Cheers Maurizio [1] - https://bugs.openjdk.java.net/browse/JDK-8259609 [2] - https://bugs.openjdk.java.net/browse/JDK-8255902 On 22/04/2021 19:27, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/412 > > Summary: Introduce an API by which Java programs can interoperate > with code and data outside of the Java runtime. By efficiently > invoking foreign functions (i.e., code outside the JVM), and by > safely accessing foreign memory (i.e., memory not managed by the > JVM), the API enables Java programs to call native libraries and > process native data without the brittleness and danger of JNI. > > - Mark From philip.race at oracle.com Fri Apr 23 20:13:49 2021 From: philip.race at oracle.com (Philip Race) Date: Fri, 23 Apr 2021 13:13:49 -0700 Subject: Fwd: Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS. In-Reply-To: <9826c9ab-273e-b387-a5f1-f44f855007f7@oracle.com> References: <9826c9ab-273e-b387-a5f1-f44f855007f7@oracle.com> Message-ID: FYI to the wider community that may not subscribe to the client mailing lists, nor appreciate too much cross-posting. -phil. -------- Forwarded Message -------- Subject: Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS. Date: Fri, 23 Apr 2021 13:10:46 -0700 From: Philip Race To: 2d-dev at openjdk.java.net <2d-dev at openjdk.java.net> CC: lanai-dev at openjdk.java.net, swing-dev at openjdk.java.net , awt-dev at openjdk.java.net Heads up to anyone who is testing JDK 17 for running apps on macOS. Starting with build 19 [1], JDK 17 for macOS is *temporarily* switched from using OpenGL to using Apple's Metal API for Java 2D rendering. This should be invisible to applications. We expect to revert this temporary switch in JDK 17 build 23,meaning b22 will be the last build with Metal as default. See JEP 382 [2] for more information about how Metal is used by JDK. If you are running any kind of 2D / Swing/ AWT UI application on macOS, and see any rendering related problems starting with JDK 17 b19, please do report them to us at either the usual bug submission channel [3], or on the 2d-dev at openjdk.java.net OpenJDK mailing list [4] Please be ready to provide us with a test case and screen shots. You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which? implicitly disables Metal - to confirm that any problem you see is a Metal related rendering glitch. I will also forward this email to jdk-dev at openjdk.java.net -Phil. [1] https://jdk.java.net/17/ [2] https://openjdk.java.net/jeps/382 [3] https://bugreport.java.com/bugreport/ [4] https://mail.openjdk.java.net/mailman/listinfo/2d-dev From stuart.marks at oracle.com Fri Apr 23 21:46:06 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 23 Apr 2021 14:46:06 -0700 Subject: CFV: New JDK Committer: Ian Graves Message-ID: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> I hereby nominate Ian Graves (igraves)[1] to JDK Committer. Ian is a member of the Oracle JDK Core Libraries team, and he has been working on Vector, Formatter, Regex, and some code modernization. He has authored the following 15 commits in the JDK: $ git log --author igraves --format='%h %s' 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() b337f633611 8037397: RegEx pattern matching loses character class after intersection (&&) operator 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits fad8484058f 8263411: Convert jshell tool to use Stream.toList() 0b5216a922b 8263545: Convert jpackage to use Stream.toList() 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* 350303d4f0c 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() 080c707aabc 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures 5d84e95ed59 8204256: improve jlink error message to report unsupported class file format 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy 79904c1fa38 8252730: jlink does not create reproducible builds on different servers de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate (Note that several of these commits include specification and behavioral changes and thus are linked to CSRs and Release Notes. These should be considered as part of the work product of the commit.) In addition, Ian is a Committer on project Panama, and he has made significant design, prototyping, and testing contributions to Panama's Vector API. His work is represented in this commit of the incubating Vector API: commit 0c99b192588b04aceaa27cda9cb42b45f95adffe Author: Paul Sandoz Date: Wed Oct 14 20:02:46 2020 +0000 8223347: Integration of Vector API (Incubator) ... Co-authored-by: Ian Graves Votes are due by 2021-05-07 23:59 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. s'marks [1] https://openjdk.java.net/census#igraves [2] https://openjdk.java.net/census#jdk [3] https://openjdk.java.net/projects/#committer-vote From brian.burkhalter at oracle.com Fri Apr 23 21:47:22 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 23 Apr 2021 21:47:22 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <67FDECEB-2E64-4EF1-9D32-D5582CCEAD18@oracle.com> Vote: yes On Apr 23, 2021, at 2:46 PM, Stuart Marks > wrote: I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From roger.riggs at oracle.com Fri Apr 23 21:48:13 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 23 Apr 2021 17:48:13 -0400 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <13a4ba99-6168-8fbd-b5b4-6eaf2ec05aa5@oracle.com> Vote: Yes On 4/23/21 5:46 PM, Stuart Marks wrote: > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From naoto.sato at oracle.com Fri Apr 23 21:57:31 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 23 Apr 2021 14:57:31 -0700 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes Naoto On 4/23/21 2:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He has > authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after > intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral > changes and thus are linked to CSRs and Release Notes. These should be > considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From claes.redestad at oracle.com Fri Apr 23 22:06:30 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 24 Apr 2021 00:06:30 +0200 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes On 2021-04-23 23:46, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From brent.christian at oracle.com Fri Apr 23 22:16:33 2021 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 23 Apr 2021 15:16:33 -0700 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <92004f2f-5d69-36e5-2a0d-44ba2393490c@oracle.com> Vote: Yes On 4/23/21 2:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > From vladimir.x.ivanov at oracle.com Fri Apr 23 22:40:07 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 24 Apr 2021 01:40:07 +0300 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <25d1f312-8d88-c3c7-3b2b-90891146bed4@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 24.04.2021 00:46, Stuart Marks wrote: > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From joe.darcy at oracle.com Fri Apr 23 23:11:31 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 23 Apr 2021 16:11:31 -0700 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes -Joe On 4/23/2021 2:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From mandy.chung at oracle.com Fri Apr 23 23:17:23 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 23 Apr 2021 16:17:23 -0700 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes Mandy From pavel.rappo at oracle.com Fri Apr 23 23:21:55 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 23 Apr 2021 23:21:55 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes > On 23 Apr 2021, at 22:46, Stuart Marks wrote: > > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been working on Vector, Formatter, Regex, and some code modernization. He has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral changes and thus are linked to CSRs and Release Notes. These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made significant design, prototyping, and testing contributions to Panama's Vector API. His work is represented in this commit of the incubating Vector API: > > commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > Author: Paul Sandoz > Date: Wed Oct 14 20:02:46 2020 +0000 > 8223347: Integration of Vector API (Incubator) > ... > Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From paul.sandoz at oracle.com Fri Apr 23 23:34:35 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 23 Apr 2021 23:34:35 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes Paul, From james.laskey at oracle.com Fri Apr 23 23:45:46 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 23 Apr 2021 23:45:46 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com>, Message-ID: Vote: yes ?? > On Apr 23, 2021, at 8:34 PM, Paul Sandoz wrote: > > ?Vote: yes > > Paul, From iris.clark at oracle.com Sat Apr 24 05:59:58 2021 From: iris.clark at oracle.com (Iris Clark) Date: Sat, 24 Apr 2021 05:59:58 +0000 Subject: Fw: CFV: New JDK Committer: Ian Graves In-Reply-To: References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com>, Message-ID: Vote: yes Iris From christoph.langer at sap.com Sat Apr 24 20:58:43 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 24 Apr 2021 20:58:43 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Stuart Marks > Sent: Freitag, 23. April 2021 23:46 > To: jdk-dev > Subject: CFV: New JDK Committer: Ian Graves > > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on > Vector, Formatter, Regex, and some code modernization. He has authored > the following > 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after > intersection > (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal > rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion > with a > sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags > in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE > incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on different > servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and behavioral > changes and > thus are linked to CSRs and Release Notes. These should be considered as > part of the > work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant > design, prototyping, and testing contributions to Panama's Vector API. His > work is > represented in this commit of the incubating Vector API: > > commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > Author: Paul Sandoz > Date: Wed Oct 14 20:02:46 2020 +0000 > 8223347: Integration of Vector API (Incubator) > ... > Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. > Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From volker.simonis at gmail.com Sun Apr 25 07:08:02 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 25 Apr 2021 09:08:02 +0200 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes Stuart Marks schrieb am Fr., 23. Apr. 2021, 23:46: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on > Vector, Formatter, Regex, and some code modernization. He has authored the > following > 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after > intersection > (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal > rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a > sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags > in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE > incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral > changes and > thus are linked to CSRs and Release Notes. These should be considered as > part of the > work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant > design, prototyping, and testing contributions to Panama's Vector API. His > work is > represented in this commit of the incubating Vector API: > > commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > Author: Paul Sandoz > Date: Wed Oct 14 20:02:46 2020 +0000 > 8223347: Integration of Vector API (Incubator) > ... > Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. > Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote > From sean.coffey at oracle.com Sun Apr 25 13:31:23 2021 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sun, 25 Apr 2021 14:31:23 +0100 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <7258ef05-69e4-3da4-609d-d83c442e1a3a@oracle.com> Vote: yes regards, Sean. On 23/04/2021 22:46, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From sean at pekinsoft.com Mon Apr 26 04:05:49 2021 From: sean at pekinsoft.com (Sean Carrick) Date: Sun, 25 Apr 2021 23:05:49 -0500 Subject: Weird Question Regarding JVM and Packages Message-ID: <535940bc-c509-f7f7-8029-d528fb59d280@pekinsoft.com> Greetings, All! I have an old project that I maintain, which uses an ancient library. The library it uses does an excellent job for the project, but lacks one thing: the ability to save session state of JInternalFrame windows. I have figured a fix for this, but, I am using a plugin for my IDE that relies on the original library. So, let me explain the situation and then ask the question... The library in question provides for application life-cycle and session state saving/restoring. It works great for top-level windows, such as JFrame and JDialog windows. It also is able to save/restore session state for items such as JSplitPane, JTabbedPane, and JTable controls within the windows. However, my project uses the JDesktopPane and JInternalPane windows, and I have clients asking (practically begging) for me to get the project to save the state of the JInternalPanes. The library that I am using is completely dead: there has not been any active maintenance on it in over a decade. The project that is using it does not generate enough revenue to justify the work that would be involved by moving the project to a newer framework. But, I have figured out a solution to my issue, though I do not know if it will work as I think it will... My project has its packages, such as com.mycompany.project, with many sub-packages below that. The library has its packages, such as com.library.lib. My question involves how the JVM parses out this information. The reason I am curious about this is because the solution that I discovered involves subclassing one of the old library classes. However, that class has package private and private methods that I would not be able to reach if I included my subclass within my own package structure. Therefore, I was thinking, "What's in a name?" I got to wondering, if I placed my new version of the library class on the root of my source tree, mimicking the original library's package structure, would I get access to the original class' private methods and members, if I named my class the same, but was just adding what is missing from the original class. For example, if the original library class' absolute classname was com.library.lib.SessionStorage, and I recreated that package structure on the root of my project source folder: com.library.lib.SessionStorage, but only added to it the missing requirements, would the JVM merge them at runtime? To further explain, let's say the original SessionStorage class has all of the functionality I need, except for the ability to save the session state of the JInternalFrames within my application, would I be able to create a class called SessionStorage in a package named the same as the original library's and only include the ability to get the session state from the JInternalFrames, would this work. Let's say that the original SessionStorage class contained the following methods and classes: * public void save(Component root) * private void saveTree(List roots, Map stateMap) * public void restore(Component root) * private void restoreTree(List roots, Map stateMap) * public interface Property * public JSplitPaneProperty * public JSplitPaneState * public JTabbedPaneProperty * public JTabbedPaneState * public WindowProperty * public WindowState Then, let's say that I create the package structure 'MyProject/src/com/library/lib/', then create the class JInternalSessionState within that package, which contains only the following: * public JInternalFrameProperty * public JInternalFrameState Let's go one step further and say that my JInternalSessionState class extends SessionState. Would what I believe would be the case actually happen? Would the JVM simply use my class as an overridden version of the SessionState class, even though they are in completely different projects, because their packages are named the same? For example, would I be able to replace the private saveTree and restoreTree methods with custom methods that would use the two new classes that I created, without the need of overriding the two public methods, save and restore? I hope that I have explained my thought process well enough for someone to give me an answer, even if it is just laughter for thinking way too far on this. I appreciate any responses that I may get, and thank you in advance. -SC From michael.x.mcmahon at oracle.com Mon Apr 26 08:04:07 2021 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 26 Apr 2021 09:04:07 +0100 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <9aa40263-29bf-0612-ed50-72ee1e00b421@oracle.com> Vote: yes On 23/04/2021 22:46, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From rahul.r.yadav at oracle.com Mon Apr 26 08:20:01 2021 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Mon, 26 Apr 2021 08:20:01 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote : yes Rahul From: jdk-dev on behalf of Stuart Marks Date: Friday, 23 April 2021 at 22:46 To: jdk-dev Subject: CFV: New JDK Committer: Ian Graves I hereby nominate Ian Graves (igraves)[1] to JDK Committer. Ian is a member of the Oracle JDK Core Libraries team, and he has been working on Vector, Formatter, Regex, and some code modernization. He has authored the following 15 commits in the JDK: $ git log --author igraves --format='%h %s' 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() b337f633611 8037397: RegEx pattern matching loses character class after intersection (&&) operator 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits fad8484058f 8263411: Convert jshell tool to use Stream.toList() 0b5216a922b 8263545: Convert jpackage to use Stream.toList() 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* 350303d4f0c 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() 080c707aabc 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures 5d84e95ed59 8204256: improve jlink error message to report unsupported class file format 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy 79904c1fa38 8252730: jlink does not create reproducible builds on different servers de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate (Note that several of these commits include specification and behavioral changes and thus are linked to CSRs and Release Notes. These should be considered as part of the work product of the commit.) In addition, Ian is a Committer on project Panama, and he has made significant design, prototyping, and testing contributions to Panama's Vector API. His work is represented in this commit of the incubating Vector API: commit 0c99b192588b04aceaa27cda9cb42b45f95adffe Author: Paul Sandoz Date: Wed Oct 14 20:02:46 2020 +0000 8223347: Integration of Vector API (Incubator) ... Co-authored-by: Ian Graves Votes are due by 2021-05-07 23:59 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. s'marks [1] https://openjdk.java.net/census#igraves [2] https://openjdk.java.net/census#jdk [3] https://openjdk.java.net/projects/#committer-vote From sgehwolf at redhat.com Mon Apr 26 08:42:49 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Apr 2021 10:42:49 +0200 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes. On Fri, 2021-04-23 at 14:46 -0700, Stuart Marks wrote: > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From dmitry.markov at oracle.com Mon Apr 26 09:08:51 2021 From: dmitry.markov at oracle.com (Dmitrii Markov) Date: Mon, 26 Apr 2021 09:08:51 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <2C601B30-569F-404C-B930-6795F267E0E6@oracle.com> Vote: yes Regards, Dmitry > On 23 Apr 2021, at 22:46, Stuart Marks wrote: > > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been working on Vector, Formatter, Regex, and some code modernization. He has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral changes and thus are linked to CSRs and Release Notes. These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made significant design, prototyping, and testing contributions to Panama's Vector API. His work is represented in this commit of the incubating Vector API: > > commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > Author: Paul Sandoz > Date: Wed Oct 14 20:02:46 2020 +0000 > 8223347: Integration of Vector API (Incubator) > ... > Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From chris.hegarty at oracle.com Mon Apr 26 09:14:36 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 26 Apr 2021 09:14:36 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <0B5BDEA6-2517-4CFF-B545-EB1E609DF712@oracle.com> Vote: YES -Chris. > On 23 Apr 2021, at 22:46, Stuart Marks wrote: > > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From adinn at redhat.com Mon Apr 26 13:40:22 2021 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 26 Apr 2021 14:40:22 +0100 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes On 23/04/2021 22:46, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He has > authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after > intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral > changes and thus are linked to CSRs and Release Notes. These should be > considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From mark.yagnatinsky at barclays.com Mon Apr 26 14:07:16 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Mon, 26 Apr 2021 14:07:16 +0000 Subject: Weird Question Regarding JVM and Packages In-Reply-To: <535940bc-c509-f7f7-8029-d528fb59d280@pekinsoft.com> References: <535940bc-c509-f7f7-8029-d528fb59d280@pekinsoft.com> Message-ID: That was a rather long email and I didn't really read the whole thing carefully, but as far as I can tell, what you're asking is this: You have some third party dependency in package com.library.lib, or whatever, and you are not quite willing to fork this dependency. Instead, you want to "tweak" a few of its classes. In particular, you want to tweak com.library.lib.SessionStorage. So you decided to create your very own class with that name, in the hope that Java will use your class instead of the "official one" and you're wondering if that will work. Usually I use Stack Overflow for that kind of question, but since you've decided to ask it here... The answer is it depends. In the world of Java 9+ modules, that totally would not work, but I'm guessing you have no plans to convert this ancient lib into a module anyway. So the real answer is: it depends on who goes first. Suppose you launch java like this: java -cp my-stuff.jar;old-lib.jar MyMainClass Then it will work exactly as you hope. Your class will have access to the package private members of the com.library.lib, since it is indeed a member of that package. But suppose you instead run java -cp old-lib.jar;my-stuff.jar MyMainClass Then your class will never be loaded at all, since the one from old-lib will be found first. If you're running in such a way as to make tweaking the class path inconvenient, you could actually remove the class SessionStorage from old-lib.jar. (Probably best to make a backup copy of the jar just in case then.) Hope that helps. Or at least I hope that I didn't totally misunderstand your question. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From brian.goetz at oracle.com Mon Apr 26 14:17:26 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 26 Apr 2021 10:17:26 -0400 Subject: Weird Question Regarding JVM and Packages In-Reply-To: <535940bc-c509-f7f7-8029-d528fb59d280@pekinsoft.com> References: <535940bc-c509-f7f7-8029-d528fb59d280@pekinsoft.com> Message-ID: <8ec6a39f-3255-f035-0644-b6b01486f2cf@oracle.com> It's a complicated question, because you've left out some detail needed to answer. If you are in a non-modular world, yes, JARs are irrelevant to package boundaries.? One of the big changes of the Java module system is to enforce that modules represent a partitioning of packages (this improves both security and performance.) The missing piece of the story here is class loaders.? A class loader is responsible (among other things) for taking a class name (including the package name) and finding its classfile bytes.? Different parts of an application may use different class loaders to resolve class names.? So the question of "will it pick up my weirdly named classfile when someone says `new JInternalFrame`" depends on which class loader they ask.? If both your library and your application are using the same class loader, *and* that class loader's search priority (such as the class path) prefers your JAR over the library JAR (such as, yours appears first in the class path), then JInternalFrame will resolve to your version.? But that's a lot of ifs. On 4/26/2021 12:05 AM, Sean Carrick wrote: > Greetings, All! > > I have an old project that I maintain, which uses an ancient library. > The library it uses does an excellent job for the project, but lacks one > thing: the ability to save session state of JInternalFrame windows. I > have figured a fix for this, but, I am using a plugin for my IDE that > relies on the original library. So, let me explain the situation and > then ask the question... > > The library in question provides for application life-cycle and session > state saving/restoring. It works great for top-level windows, such as > JFrame and JDialog windows. It also is able to save/restore session > state for items such as JSplitPane, JTabbedPane, and JTable controls > within the windows. However, my project uses the JDesktopPane and > JInternalPane windows, and I have clients asking (practically begging) > for me to get the project to save the state of the JInternalPanes. > > The library that I am using is completely dead: there has not been any > active maintenance on it in over a decade. The project that is using it > does not generate enough revenue to justify the work that would be > involved by moving the project to a newer framework. But, I have figured > out a solution to my issue, though I do not know if it will work as I > think it will... > > My project has its packages, such as com.mycompany.project, with many > sub-packages below that. The library has its packages, such as > com.library.lib. My question involves how the JVM parses out this > information. The reason I am curious about this is because the solution > that I discovered involves subclassing one of the old library classes. > However, that class has package private and private methods that I would > not be able to reach if I included my subclass within my own package > structure. > > Therefore, I was thinking, "What's in a name?" I got to wondering, if I > placed my new version of the library class on the root of my source > tree, mimicking the original library's package structure, would I get > access to the original class' private methods and members, if I named my > class the same, but was just adding what is missing from the original class. > > For example, if the original library class' absolute classname was > com.library.lib.SessionStorage, and I recreated that package structure > on the root of my project source folder: com.library.lib.SessionStorage, > but only added to it the missing requirements, would the JVM merge them > at runtime? > > To further explain, let's say the original SessionStorage class has all > of the functionality I need, except for the ability to save the session > state of the JInternalFrames within my application, would I be able to > create a class called SessionStorage in a package named the same as the > original library's and only include the ability to get the session state > from the JInternalFrames, would this work. > > Let's say that the original SessionStorage class contained the following > methods and classes: > > * public void save(Component root) > * private void saveTree(List roots, Map > stateMap) > * public void restore(Component root) > * private void restoreTree(List roots, Map > stateMap) > * public interface Property > * public JSplitPaneProperty > * public JSplitPaneState > * public JTabbedPaneProperty > * public JTabbedPaneState > * public WindowProperty > * public WindowState > > Then, let's say that I create the package structure > 'MyProject/src/com/library/lib/', then create the class > JInternalSessionState within that package, which contains only the > following: > > * public JInternalFrameProperty > * public JInternalFrameState > > Let's go one step further and say that my JInternalSessionState class > extends SessionState. Would what I believe would be the case actually > happen? > > Would the JVM simply use my class as an overridden version of the > SessionState class, even though they are in completely different > projects, because their packages are named the same? For example, would > I be able to replace the private saveTree and restoreTree methods with > custom methods that would use the two new classes that I created, > without the need of overriding the two public methods, save and restore? > > I hope that I have explained my thought process well enough for someone > to give me an answer, even if it is just laughter for thinking way too > far on this. I appreciate any responses that I may get, and thank you in > advance. > > -SC > From eric.caspole at oracle.com Mon Apr 26 14:22:55 2021 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Mon, 26 Apr 2021 10:22:55 -0400 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <3387d795-0448-7f2e-9cf4-12cdfec8ee1a@oracle.com> Vote: yes On 4/23/21 5:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From mark.reinhold at oracle.com Mon Apr 26 17:13:27 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 26 Apr 2021 10:13:27 -0700 Subject: JEP proposed to target JDK 17: 410: Remove the Experimental AOT and JIT Compiler In-Reply-To: <20210415210546.3BEEF3E0138@eggemoggin.niobe.net> References: <20210415210546.3BEEF3E0138@eggemoggin.niobe.net> Message-ID: <20210426101327.912109540@eggemoggin.niobe.net> 2021/4/15 14:05:46 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 410: Remove the Experimental AOT and JIT Compiler > https://openjdk.java.net/jeps/410 > > Summary: Remove the experimental Java-based ahead-of-time (AOT) and > just-in-time (JIT) compiler. This compiler has seen little use since > its introduction and the effort required to maintain it is significant. > Retain the experimental Java-level JVM compiler interface (JVMCI) so > that developers can continue to use externally-built versions of the > compiler for JIT compilation. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Thursday, 22 April, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From daniel.fuchs at oracle.com Mon Apr 26 17:45:00 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 26 Apr 2021 18:45:00 +0100 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <7ca36590-cef3-081b-0d43-fe4c3ea8f822@oracle.com> Vote: yes best regards, -- daniel On 23/04/2021 22:46, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From stuart.marks at oracle.com Mon Apr 26 17:51:08 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 26 Apr 2021 10:51:08 -0700 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <9966f908-c29e-8324-c6ea-89447915a29f@oracle.com> Vote: yes On 4/23/21 2:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been working on > Vector, Formatter, Regex, and some code modernization. He has authored the following > 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after intersection > (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for BigDecimal > rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a > sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for mismatched flags > in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE > incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported class file > format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral changes and > thus are linked to CSRs and Release Notes. These should be considered as part of the > work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made significant > design, prototyping, and testing contributions to Panama's Vector API. His work is > represented in this commit of the incubating Vector API: > > ??? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ??? Author: Paul Sandoz > ??? Date:? Wed Oct 14 20:02:46 2020 +0000 > ??? 8223347: Integration of Vector API (Incubator) > ??? ... > ??? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination.? Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From huizhe.wang at oracle.com Mon Apr 26 18:32:29 2021 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 26 Apr 2021 11:32:29 -0700 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <119a0a5b-8e90-a8bf-73d3-5b034687fd6b@oracle.com> Vote: yes -Joe (joehw) On 4/23/21 2:46 PM, Stuart Marks wrote: > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From joe.darcy at oracle.com Tue Apr 27 00:12:42 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 26 Apr 2021 17:12:42 -0700 Subject: Reminder: submit CSRs for JDK 17 changes ahead of rampdown 1 milestone of June 10, 2021 Message-ID: <0ff6f527-a4b4-344e-ec88-388e02f60c49@oracle.com> Hello, Per the JDK 17 schedule (http://openjdk.java.net/projects/jdk/17/), rampdown phase one is coming up on June 10, 2021. An advanced reminder to factor in sufficient review time for any projects needing CSRs before getting pushed into JDK 17. Large projects, including JEPs, should often use the two-phase CSR process (https://wiki.openjdk.java.net/display/csr/Main) rather than the one-phase process. The nominally SLA for each CSR phase is one week. To accommodate the possibility of needing to respond to feedback from the CSR, I recommend a large project plan for at least three weeks for CSR review time ahead of a planned integration date. Cheers, -Joe CSR Lead From doko at ubuntu.com Tue Apr 27 06:33:27 2021 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 27 Apr 2021 08:33:27 +0200 Subject: problematic pkcs11 license Message-ID: A Debian issue points out a problematic license for some imported header files, see https://bugs.debian.org/985765, and also https://bugs.debian.org/952951 pointing out the issue with the OASIS license. The header files currently have /* Copyright (c) OASIS Open 2016-2019. All Rights Reserved. * Distributed under the terms of the OASIS IPR Policy, * [http://www.oasis-open.org/policies-guidelines/ipr], AS-IS, WITHOUT ANY * IMPLIED OR EXPRESS WARRANTY; there is no warranty of MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE or NONINFRINGEMENT of the rights of others. */ The proposed alternative headers from NSS (which is already used as a build dependency for OpenJDK), have: /* This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ /* * Copyright (C) 1994-1999 RSA Security Inc. Licence to copy this document * is granted provided that it is identified as "RSA Security In.c Public-Key * Cryptography Standards (PKCS)" in all material mentioning or referencing * this document. * * The latest version of this header can be found at: * http://www.rsalabs.com/pkcs/pkcs-11/index.html */ Is this something which could be addressed upstream? Which group to contact? Thanks, Matthias From mikael.vidstedt at oracle.com Tue Apr 27 07:05:16 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 27 Apr 2021 07:05:16 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <77234FF9-98E3-429F-B1FC-0A1893977D99@oracle.com> Vote: yes Cheers, Mikael > On Apr 23, 2021, at 2:46 PM, Stuart Marks wrote: > > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been working on Vector, Formatter, Regex, and some code modernization. He has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral changes and thus are linked to CSRs and Release Notes. These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made significant design, prototyping, and testing contributions to Panama's Vector API. His work is represented in this commit of the incubating Vector API: > > commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > Author: Paul Sandoz > Date: Wed Oct 14 20:02:46 2020 +0000 > 8223347: Integration of Vector API (Incubator) > ... > Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From thomas.stuefe at gmail.com Tue Apr 27 07:30:06 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 27 Apr 2021 09:30:06 +0200 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes On Fri, Apr 23, 2021 at 11:47 PM Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on > Vector, Formatter, Regex, and some code modernization. He has authored the > following > 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class after > intersection > (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal > rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a > sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags > in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE > incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate > > (Note that several of these commits include specification and behavioral > changes and > thus are linked to CSRs and Release Notes. These should be considered as > part of the > work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant > design, prototyping, and testing contributions to Panama's Vector API. His > work is > represented in this commit of the incubating Vector API: > > commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > Author: Paul Sandoz > Date: Wed Oct 14 20:02:46 2020 +0000 > 8223347: Integration of Vector API (Incubator) > ... > Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. > Votes must > be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote > From harold.seigel at oracle.com Tue Apr 27 13:31:46 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 27 Apr 2021 09:31:46 -0400 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <1a1dc166-ab23-d781-8409-cc13d22375b1@oracle.com> Vote: Yes Harold On 4/23/2021 5:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From lois.foltan at oracle.com Tue Apr 27 14:41:37 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 27 Apr 2021 10:41:37 -0400 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <5012c834-df95-9440-e428-c731eb5161ff@oracle.com> Vote: yes Lois On 4/23/2021 5:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From maurizio.cimadamore at oracle.com Tue Apr 27 16:18:06 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 27 Apr 2021 17:18:06 +0100 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <70fa1dcc-2965-1d5e-2920-118363f5a22b@oracle.com> Vote: yes! Maurizio On 23/04/2021 22:46, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ??? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ??? Author: Paul Sandoz > ??? Date:? Wed Oct 14 20:02:46 2020 +0000 > ??? 8223347: Integration of Vector API (Incubator) > ??? ... > ??? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From john.r.rose at oracle.com Tue Apr 27 22:35:59 2021 From: john.r.rose at oracle.com (John Rose) Date: Tue, 27 Apr 2021 22:35:59 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes (Go, Ian!) On Apr 23, 2021, at 2:46 PM, Stuart Marks > wrote: I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From Alan.Bateman at oracle.com Wed Apr 28 06:13:01 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Apr 2021 07:13:01 +0100 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <9e286d55-a74d-e9f3-ffe3-996954d37714@oracle.com> Vote: yes From igor.ignatyev at oracle.com Wed Apr 28 06:30:23 2021 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Wed, 28 Apr 2021 06:30:23 +0000 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <9200CD30-3EB3-4949-8362-4A7581739B93@oracle.com> Vote: yes -- Igor On Apr 23, 2021, at 2:46 PM, Stuart Marks > wrote: I hereby nominate Ian Graves (igraves)[1] to JDK Committer. From abdul.kolarkunnu at oracle.com Wed Apr 28 08:58:54 2021 From: abdul.kolarkunnu at oracle.com (abdul.kolarkunnu at oracle.com) Date: Wed, 28 Apr 2021 14:28:54 +0530 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <5e0be375-bbf3-d4ed-2c0c-655d34cdac6a@oracle.com> Vote: yes -Muneer On 24/04/21 3:16 am, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ??? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ??? Author: Paul Sandoz > ??? Date:? Wed Oct 14 20:02:46 2020 +0000 > ??? 8223347: Integration of Vector API (Incubator) > ??? ... > ??? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From fweimer at redhat.com Wed Apr 28 10:16:08 2021 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 28 Apr 2021 12:16:08 +0200 Subject: problematic pkcs11 license In-Reply-To: (Matthias Klose's message of "Tue, 27 Apr 2021 08:33:27 +0200") References: Message-ID: <878s52iujb.fsf@oldenburg.str.redhat.com> * Matthias Klose: > A Debian issue points out a problematic license for some imported header files, > see https://bugs.debian.org/985765, and also https://bugs.debian.org/952951 > pointing out the issue with the OASIS license. > > The header files currently have > > /* Copyright (c) OASIS Open 2016-2019. All Rights Reserved. > * Distributed under the terms of the OASIS IPR Policy, > * [http://www.oasis-open.org/policies-guidelines/ipr], AS-IS, WITHOUT ANY > * IMPLIED OR EXPRESS WARRANTY; there is no warranty of MERCHANTABILITY, FITNESS > FOR A > * PARTICULAR PURPOSE or NONINFRINGEMENT of the rights of others. > */ > > The proposed alternative headers from NSS (which is already used as a build > dependency for OpenJDK), have: > > /* This Source Code Form is subject to the terms of the Mozilla Public > * License, v. 2.0. If a copy of the MPL was not distributed with this > * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ > /* > * Copyright (C) 1994-1999 RSA Security Inc. Licence to copy this document > * is granted provided that it is identified as "RSA Security In.c Public-Key > * Cryptography Standards (PKCS)" in all material mentioning or referencing > * this document. > * > * The latest version of this header can be found at: > * http://www.rsalabs.com/pkcs/pkcs-11/index.html > */ > > Is this something which could be addressed upstream? Which group to > contact? For some additional context on the OASIS license, there is also a discussion here: Thanks, Florian From dalibor.topic at oracle.com Wed Apr 28 14:39:17 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 28 Apr 2021 16:39:17 +0200 Subject: Weird Question Regarding JVM and Packages In-Reply-To: <8ec6a39f-3255-f035-0644-b6b01486f2cf@oracle.com> References: <535940bc-c509-f7f7-8029-d528fb59d280@pekinsoft.com> <8ec6a39f-3255-f035-0644-b6b01486f2cf@oracle.com> Message-ID: On 26.04.2021 16:17, Brian Goetz wrote: > It's a complicated question, because you've left out some detail needed > to answer. > > If you are in a non-modular world, yes, JARs are irrelevant to package > boundaries. With the small, rarely used exception of sealed jars. https://docs.oracle.com/javase/tutorial/deployment/jar/sealman.html cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From mark.reinhold at oracle.com Wed Apr 28 21:40:31 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Apr 2021 14:40:31 -0700 (PDT) Subject: New candidate JEP: 413: Code Snippets in Java API Documentation Message-ID: <20210428214031.EE8113E1E4E@eggemoggin.niobe.net> https://openjdk.java.net/jeps/413 Summary: Introduce an @snippet tag for JavaDoc's Standard Doclet, to simplify the inclusion of example source code in API documentation. - Mark From lance.andersen at oracle.com Thu Apr 29 10:13:35 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 29 Apr 2021 06:13:35 -0400 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: Vote: yes > >> On Apr 23, 2021, at 5:46 PM, Stuart Marks > wrote: >> >> >> I hereby nominate Ian Graves (igraves)[1] to JDK Committer. >> >> Ian is a member of the Oracle JDK Core Libraries team, and he has been working on Vector, Formatter, Regex, and some code modernization. He has authored the following 15 commits in the JDK: >> >> $ git log --author igraves --format='%h %s' >> 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() >> b337f633611 8037397: RegEx pattern matching loses character class after intersection (&&) operator >> 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits >> fad8484058f 8263411: Convert jshell tool to use Stream.toList() >> 0b5216a922b 8263545: Convert jpackage to use Stream.toList() >> 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character >> dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* >> 350303d4f0c 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion >> edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() >> 080c707aabc 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly >> 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures >> 5d84e95ed59 8204256: improve jlink error message to report unsupported class file format >> 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy >> 79904c1fa38 8252730: jlink does not create reproducible builds on different servers >> de49337060e 8252529: Unsafe Documentation around Barrier Methods Inaccurate >> >> (Note that several of these commits include specification and behavioral changes and thus are linked to CSRs and Release Notes. These should be considered as part of the work product of the commit.) >> >> In addition, Ian is a Committer on project Panama, and he has made significant design, prototyping, and testing contributions to Panama's Vector API. His work is represented in this commit of the incubating Vector API: >> >> commit 0c99b192588b04aceaa27cda9cb42b45f95adffe >> Author: Paul Sandoz > >> Date: Wed Oct 14 20:02:46 2020 +0000 >> 8223347: Integration of Vector API (Incubator) >> ... >> Co-authored-by: Ian Graves > >> >> Votes are due by 2021-05-07 23:59 UTC. >> >> Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> s'marks >> >> >> [1] https://openjdk.java.net/census#igraves >> [2] https://openjdk.java.net/census#jdk >> [3] https://openjdk.java.net/projects/#committer-vote > > > > From vicente.romero at oracle.com Thu Apr 29 11:11:31 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 29 Apr 2021 07:11:31 -0400 Subject: CFV: New JDK Committer: Ian Graves In-Reply-To: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> References: <99b6450a-586a-3378-5098-ff0668ba440d@oracle.com> Message-ID: <60293b34-5a09-de8c-dd4e-63062196609e@oracle.com> vote: yes Vicente On 4/23/21 5:46 PM, Stuart Marks wrote: > > I hereby nominate Ian Graves (igraves)[1] to JDK Committer. > > Ian is a member of the Oracle JDK Core Libraries team, and he has been > working on Vector, Formatter, Regex, and some code modernization. He > has authored the following 15 commits in the JDK: > > $ git log --author igraves --format='%h %s' > 33a86b9e407 8263621: Convert jdk.compiler to use Stream.toList() > b337f633611 8037397: RegEx pattern matching loses character class > after intersection (&&) operator > 0bdc3e7a41b 8262744: Formatter '%g' conversion uses wrong format for > BigDecimal rounding up to limits > fad8484058f 8263411: Convert jshell tool to use Stream.toList() > 0b5216a922b 8263545: Convert jpackage to use Stream.toList() > 6971c23a3a2 8262351: Extra '0' in java.util.Formatter for '%012a' > conversion with a sign character > dbef0ec95d0 6323374: (coll) Optimize Collections.unmodifiable* and > synchronized* > 350303d4f0c 8260221: java.util.Formatter throws wrong exception for > mismatched flags in %% conversion > edd5fc883a3 8261096: Convert jlink tool to use Stream.toList() > 080c707aabc 8253459: Formatter treats index, width and precision > > Integer.MAX_VALUE incorrectly > 77921b97365 8254080: fix for JDK-8204256 causes jlink test failures > 5d84e95ed59 8204256: improve jlink error message to report unsupported > class file format > 8df3e72cea9 8218685: jlink --list-plugins needs to be readable and tidy > 79904c1fa38 8252730: jlink does not create reproducible builds on > different servers > de49337060e 8252529: Unsafe Documentation around Barrier Methods > Inaccurate > > (Note that several of these commits include specification and > behavioral changes and thus are linked to CSRs and Release Notes. > These should be considered as part of the work product of the commit.) > > In addition, Ian is a Committer on project Panama, and he has made > significant design, prototyping, and testing contributions to Panama's > Vector API. His work is represented in this commit of the incubating > Vector API: > > ?? commit 0c99b192588b04aceaa27cda9cb42b45f95adffe > ?? Author: Paul Sandoz > ?? Date:? Wed Oct 14 20:02:46 2020 +0000 > ?? 8223347: Integration of Vector API (Incubator) > ?? ... > ?? Co-authored-by: Ian Graves > > Votes are due by 2021-05-07 23:59 UTC. > > Only current JDK Committers [2] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > s'marks > > > [1] https://openjdk.java.net/census#igraves > [2] https://openjdk.java.net/census#jdk > [3] https://openjdk.java.net/projects/#committer-vote From philip.race at oracle.com Thu Apr 29 19:02:03 2021 From: philip.race at oracle.com (Philip Race) Date: Thu, 29 Apr 2021 12:02:03 -0700 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) Message-ID: I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer Alexey is a previous member of the Java 2D team at Sun Microsystems and contributed to OpenJDK even before it existed - notably adopting LittleCMS as the open source color management engine for OpenJDK as part of Sun's effort to provide open source replacements for proprietary code. Since returning to work on OpenJDK he has been a major contributor to JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author of that work, and additionally has made an additional 9 contributions beyond that, enumerated below. git log --author avu --format='%h %s' 155da257fd9 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 714ae54f91d 8258788: incorrect response to change in window insets [lanai] a4905bae9b2 8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK librarie c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) usage on macOS Mojave 10ef2cd87ca 8197499: RepaintManager does not increase double buffer after attaching a device with higher resolution af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an AWT regression test 7f2828e070a 6733501: Apply IcedTea little cms patches git log --author alexey.ushakov --format='%h %s' 164537ebd4b 8147542: ClassCastException when repainting after display resolution change Votes are due by 2021-05-13 19:05 UTC. Only current JDK Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -phil. [1] https://openjdk.java.net/census#avu [2] http://openjdk.java.net/jeps/382 [3] commit 8afec70c283ee549795996031e3a53a3212bf35a Author: Ajit Ghaisas Date: Mon Mar 15 06:41:44 2021 +0000 8260931: Implement JEP 382: New macOS Rendering Pipeline Co-authored-by: Jayathirth D V Co-authored-by: Alexey Ushakov Co-authored-by: Artem Bochkarev Co-authored-by: Prasanta Sadhukhan Co-authored-by: Denis Konoplev Co-authored-by: Phil Race Co-authored-by: Kevin Rushforth Co-authored-by: Magnus Ihse Bursie Co-authored-by: Ajit Ghaisas Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb [4]https://openjdk.java.net/census#jdk [5]https://openjdk.java.net/projects/#committer-vote From philip.race at oracle.com Thu Apr 29 19:02:35 2021 From: philip.race at oracle.com (Philip Race) Date: Thu, 29 Apr 2021 12:02:35 -0700 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: Vote: yes -phil From eric.caspole at oracle.com Thu Apr 29 19:33:01 2021 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Thu, 29 Apr 2021 15:33:01 -0400 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <19c47230-0aba-1a02-a91a-7fe85f6aba03@oracle.com> Vote: yes Eric On 4/29/21 3:02 PM, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems > and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the > open source > color management engine for OpenJDK as part of Sun's effort to provide > open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a > co-author of that work, > and additionally has made an additional 9 contributions beyond that, > enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: > apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java > fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets > [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with > "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector > (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer > after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running > an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display > resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date:?? Mon Mar 15 06:41:44 2021 +0000 > > ?? 8260931: Implement JEP 382: New macOS Rendering Pipeline > ?? ?? Co-authored-by: Jayathirth D V > ?? Co-authored-by: Alexey Ushakov > ?? Co-authored-by: Artem Bochkarev > ?? Co-authored-by: Prasanta Sadhukhan > ?? Co-authored-by: Denis Konoplev > ?? Co-authored-by: Phil Race > ?? Co-authored-by: Kevin Rushforth > ?? Co-authored-by: Magnus Ihse Bursie > ?? Co-authored-by: Ajit Ghaisas > ?? Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, > psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From andy.herrick at oracle.com Thu Apr 29 20:06:29 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 29 Apr 2021 16:06:29 -0400 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: vote: yes /Andy On 4/29/2021 3:02 PM, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems > and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the > open source > color management engine for OpenJDK as part of Sun's effort to provide > open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a > co-author of that work, > and additionally has made an additional 9 contributions beyond that, > enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: > apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java > fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets > [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with > "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector > (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer > after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running > an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display > resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date:?? Mon Mar 15 06:41:44 2021 +0000 > > ?? 8260931: Implement JEP 382: New macOS Rendering Pipeline > ?? ?? Co-authored-by: Jayathirth D V > ?? Co-authored-by: Alexey Ushakov > ?? Co-authored-by: Artem Bochkarev > ?? Co-authored-by: Prasanta Sadhukhan > ?? Co-authored-by: Denis Konoplev > ?? Co-authored-by: Phil Race > ?? Co-authored-by: Kevin Rushforth > ?? Co-authored-by: Magnus Ihse Bursie > ?? Co-authored-by: Ajit Ghaisas > ?? Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, > psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From Sergey.Bylokhov at oracle.com Thu Apr 29 20:11:38 2021 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 29 Apr 2021 13:11:38 -0700 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <080d6392-303b-3108-b519-c25371c39d42@oracle.com> vote: yes On 29.04.2021 12:02, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the open source > color management engine for OpenJDK as part of Sun's effort to provide open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author of that work, > and additionally has made an additional 9 contributions beyond that, enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date:?? Mon Mar 15 06:41:44 2021 +0000 > > ?? 8260931: Implement JEP 382: New macOS Rendering Pipeline > ?? Co-authored-by: Jayathirth D V > ?? Co-authored-by: Alexey Ushakov > ?? Co-authored-by: Artem Bochkarev > ?? Co-authored-by: Prasanta Sadhukhan > ?? Co-authored-by: Denis Konoplev > ?? Co-authored-by: Phil Race > ?? Co-authored-by: Kevin Rushforth > ?? Co-authored-by: Magnus Ihse Bursie > ?? Co-authored-by: Ajit Ghaisas > ?? Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Fri Apr 30 03:16:12 2021 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 30 Apr 2021 03:16:12 +0000 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <7B5FBEE2-5D25-4680-80D7-F0ED12DC985F@oracle.com> Vote : Yes Thanks, Jay > On 30-Apr-2021, at 12:32 AM, Philip Race wrote: > > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the open source > color management engine for OpenJDK as part of Sun's effort to provide open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author of that work, > and additionally has made an additional 9 contributions beyond that, enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date: Mon Mar 15 06:41:44 2021 +0000 > > 8260931: Implement JEP 382: New macOS Rendering Pipeline > Co-authored-by: Jayathirth D V > Co-authored-by: Alexey Ushakov > Co-authored-by: Artem Bochkarev > Co-authored-by: Prasanta Sadhukhan > Co-authored-by: Denis Konoplev > Co-authored-by: Phil Race > Co-authored-by: Kevin Rushforth > Co-authored-by: Magnus Ihse Bursie > Co-authored-by: Ajit Ghaisas > Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From alexander.zuev at oracle.com Fri Apr 30 04:38:52 2021 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 29 Apr 2021 21:38:52 -0700 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: Vote: yes On 4/29/2021 12:02 PM, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems > and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the > open source > color management engine for OpenJDK as part of Sun's effort to provide > open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a > co-author of that work, > and additionally has made an additional 9 contributions beyond that, > enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: > apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java > fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets > [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with > "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector > (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer > after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running > an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display > resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date:?? Mon Mar 15 06:41:44 2021 +0000 > > ?? 8260931: Implement JEP 382: New macOS Rendering Pipeline > ?? ?? Co-authored-by: Jayathirth D V > ?? Co-authored-by: Alexey Ushakov > ?? Co-authored-by: Artem Bochkarev > ?? Co-authored-by: Prasanta Sadhukhan > ?? Co-authored-by: Denis Konoplev > ?? Co-authored-by: Phil Race > ?? Co-authored-by: Kevin Rushforth > ?? Co-authored-by: Magnus Ihse Bursie > ?? Co-authored-by: Ajit Ghaisas > ?? Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, > psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From ajit.ghaisas at oracle.com Fri Apr 30 05:00:26 2021 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 30 Apr 2021 10:30:26 +0530 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <9EEA24F6-5942-43FF-86F5-0418C567EF46@oracle.com> Vote : YES Regards, Ajit > On 30-Apr-2021, at 12:32 AM, Philip Race wrote: > > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the open source > color management engine for OpenJDK as part of Sun's effort to provide open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author of that work, > and additionally has made an additional 9 contributions beyond that, enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date: Mon Mar 15 06:41:44 2021 +0000 > > 8260931: Implement JEP 382: New macOS Rendering Pipeline > Co-authored-by: Jayathirth D V > Co-authored-by: Alexey Ushakov > Co-authored-by: Artem Bochkarev > Co-authored-by: Prasanta Sadhukhan > Co-authored-by: Denis Konoplev > Co-authored-by: Phil Race > Co-authored-by: Kevin Rushforth > Co-authored-by: Magnus Ihse Bursie > Co-authored-by: Ajit Ghaisas > Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From yan at azul.com Fri Apr 30 06:40:34 2021 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 30 Apr 2021 09:40:34 +0300 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <53b93acf-42fb-ab3d-5658-f96eab1d25f9@azul.com> Vote: yes --yan On 29.04.2021 22:02, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the open source > color management engine for OpenJDK as part of Sun's effort to provide open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author of that work, > and additionally has made an additional 9 contributions beyond that, enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to > load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer after attaching a device with > higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date:?? Mon Mar 15 06:41:44 2021 +0000 > > ??? 8260931: Implement JEP 382: New macOS Rendering Pipeline > ??? ??? Co-authored-by: Jayathirth D V > ??? Co-authored-by: Alexey Ushakov > ??? Co-authored-by: Artem Bochkarev > ??? Co-authored-by: Prasanta Sadhukhan > ??? Co-authored-by: Denis Konoplev > ??? Co-authored-by: Phil Race > ??? Co-authored-by: Kevin Rushforth > ??? Co-authored-by: Magnus Ihse Bursie > ??? Co-authored-by: Ajit Ghaisas > ??? Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote From dmitry.batrak at jetbrains.com Fri Apr 30 07:10:33 2021 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Fri, 30 Apr 2021 10:10:33 +0300 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: Vote: yes -- Dmitry Batrak On Thu, Apr 29, 2021 at 10:02 PM Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and > contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the > open source > color management engine for OpenJDK as part of Sun's effort to provide > open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author > of that work, > and additionally has made an additional 9 contributions beyond that, > enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: > apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java > fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with > "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) > usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer > after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an > AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display > resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date: Mon Mar 15 06:41:44 2021 +0000 > > 8260931: Implement JEP 382: New macOS Rendering Pipeline > > Co-authored-by: Jayathirth D V > Co-authored-by: Alexey Ushakov > Co-authored-by: Artem Bochkarev > Co-authored-by: Prasanta Sadhukhan > Co-authored-by: Denis Konoplev > Co-authored-by: Phil Race > Co-authored-by: Kevin Rushforth > Co-authored-by: Magnus Ihse Bursie > Co-authored-by: Ajit Ghaisas > Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, > serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > > From dmitry.markov at oracle.com Fri Apr 30 07:45:58 2021 From: dmitry.markov at oracle.com (Dmitrii Markov) Date: Fri, 30 Apr 2021 07:45:58 +0000 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <4D1E721B-3585-4639-ADEF-2BECA9116CEF@oracle.com> Vote: yes Regards, Dmitry > On 29 Apr 2021, at 20:02, Philip Race wrote: > > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the open source > color management engine for OpenJDK as part of Sun's effort to provide open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author of that work, > and additionally has made an additional 9 contributions beyond that, enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date: Mon Mar 15 06:41:44 2021 +0000 > > 8260931: Implement JEP 382: New macOS Rendering Pipeline > Co-authored-by: Jayathirth D V > Co-authored-by: Alexey Ushakov > Co-authored-by: Artem Bochkarev > Co-authored-by: Prasanta Sadhukhan > Co-authored-by: Denis Konoplev > Co-authored-by: Phil Race > Co-authored-by: Kevin Rushforth > Co-authored-by: Magnus Ihse Bursie > Co-authored-by: Ajit Ghaisas > Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From daniel.fuchs at oracle.com Fri Apr 30 09:54:22 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 30 Apr 2021 10:54:22 +0100 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <4ec4c561-6f7f-adf5-8a8d-df14ee73ec64@oracle.com> Vote: yes best regards, -- daniel On 29/04/2021 20:02, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer From adinn at redhat.com Fri Apr 30 10:27:36 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 30 Apr 2021 11:27:36 +0100 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <4791d877-1d7a-87a8-336e-9d0f4ee6f56b@redhat.com> Vote: yes On 29/04/2021 20:02, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and > contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the > open source > color management engine for OpenJDK as part of Sun's effort to provide > open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author > of that work, > and additionally has made an additional 9 contributions beyond that, > enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: > apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java > fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with > "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) > usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer > after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an > AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display > resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date:?? Mon Mar 15 06:41:44 2021 +0000 > > ?? 8260931: Implement JEP 382: New macOS Rendering Pipeline > ?? Co-authored-by: Jayathirth D V > ?? Co-authored-by: Alexey Ushakov > ?? Co-authored-by: Artem Bochkarev > ?? Co-authored-by: Prasanta Sadhukhan > ?? Co-authored-by: Denis Konoplev > ?? Co-authored-by: Phil Race > ?? Co-authored-by: Kevin Rushforth > ?? Co-authored-by: Magnus Ihse Bursie > ?? Co-authored-by: Ajit Ghaisas > ?? Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, > serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Fri Apr 30 11:35:50 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 30 Apr 2021 13:35:50 +0200 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <9baa41f8dd04bacab4e062b0d6d357efdbc5e897.camel@redhat.com> Vote: yes. On Thu, 2021-04-29 at 12:02 -0700, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer From bourges.laurent at gmail.com Fri Apr 30 12:02:39 2021 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 30 Apr 2021 14:02:39 +0200 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: Vote: yes Le jeu. 29 avr. 2021 ? 21:02, Philip Race a ?crit : > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and > contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the > open source > color management engine for OpenJDK as part of Sun's effort to provide > open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author > of that work, > and additionally has made an additional 9 contributions beyond that, > enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: > apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java > fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with > "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) > usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer > after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an > AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display > resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date: Mon Mar 15 06:41:44 2021 +0000 > > 8260931: Implement JEP 382: New macOS Rendering Pipeline > > Co-authored-by: Jayathirth D V > Co-authored-by: Alexey Ushakov > Co-authored-by: Artem Bochkarev > Co-authored-by: Prasanta Sadhukhan > Co-authored-by: Denis Konoplev > Co-authored-by: Phil Race > Co-authored-by: Kevin Rushforth > Co-authored-by: Magnus Ihse Bursie > Co-authored-by: Ajit Ghaisas > Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, > serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > > From tejpal.rebari at oracle.com Fri Apr 30 13:16:58 2021 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Fri, 30 Apr 2021 13:16:58 +0000 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <18A7B16A-8F48-4421-A8F6-EDBB686B03A8@oracle.com> Vote : yes Regards Tejpal > On 30-Apr-2021, at 12:32 AM, Philip Race wrote: > > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the open source > color management engine for OpenJDK as part of Sun's effort to provide open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a co-author of that work, > and additionally has made an additional 9 contributions beyond that, enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date: Mon Mar 15 06:41:44 2021 +0000 > > 8260931: Implement JEP 382: New macOS Rendering Pipeline > Co-authored-by: Jayathirth D V > Co-authored-by: Alexey Ushakov > Co-authored-by: Artem Bochkarev > Co-authored-by: Prasanta Sadhukhan > Co-authored-by: Denis Konoplev > Co-authored-by: Phil Race > Co-authored-by: Kevin Rushforth > Co-authored-by: Magnus Ihse Bursie > Co-authored-by: Ajit Ghaisas > Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From vladimir.x.ivanov at oracle.com Fri Apr 30 15:33:51 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Apr 2021 18:33:51 +0300 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: <3e60bd09-af9b-3e2b-afce-3744544d77bc@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 29.04.2021 22:02, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > From brent.christian at oracle.com Fri Apr 30 17:15:15 2021 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 30 Apr 2021 10:15:15 -0700 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: Vote: Yes On 4/29/21 12:02 PM, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > From mark.reinhold at oracle.com Fri Apr 30 22:41:12 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 30 Apr 2021 15:41:12 -0700 (PDT) Subject: New candidate JEP: 414: Vector API (Second Incubator) Message-ID: <20210430224112.273E43E22F6@eggemoggin.niobe.net> https://openjdk.java.net/jeps/414 Summary: Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. - Mark