From suenaga at oss.nttdata.com Mon Oct 4 00:26:56 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 4 Oct 2021 09:26:56 +0900 Subject: Is jcheck on GitHub PRs down? In-Reply-To: <96ddedea-3e6b-5dd1-1307-424bc3ac71b8@oracle.com> References: <440cc50b-617b-a323-a93f-3b6a1b8a8671@gmail.com> <268ea624-7021-8f03-8fd3-05eab487fe3d@oracle.com> <96ddedea-3e6b-5dd1-1307-424bc3ac71b8@oracle.com> Message-ID: <8243bdf4-4731-8f7e-c532-9cc9ab96f391@oss.nttdata.com> Hi, I sent PR to openjdk/jdk last night [1], but jcheck hasn't done yet. Should I do something operations? Thanks, Yasumasa [1] https://github.com/openjdk/jdk/pull/5797 On 2021/09/27 22:52, erik.joelsson at oracle.com wrote: > Hello, > > I believe I've found the underlying cause for the slowdown of the PR bot. I will be working on a fix today. In the meantime, regular restarts will alleviate the problem. > > https://bugs.openjdk.java.net/browse/SKARA-1191 > > /Erik > > On 2021-09-27 01:50, David Holmes wrote: >> The bots are having another problem. It is being investigated. >> >> David >> >> On 27/09/2021 6:33 pm, Severin Gehwolf wrote: >>> On Mon, 2021-09-27 at 06:56 +0000, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I observed this too. >>>> Yesterday I thought the bots would not work at all, but then they >>>> processed my PRs at some point. >>>> >>>> But now again I am waiting for my >>>> /backport jdk11u-dev >>>> command for 30+min. >>>> https://github.com/openjdk/jdk/commit/0544a732a44309bf7cbb44846dd9320c6096de17 >>>> I'll work around this by just making the downport PRs by hand. >>> >>> Sounds like a repeat of: >>> https://bugs.openjdk.java.net/browse/SKARA-1178 >>> >>> Erik, it seems it's not fixed after all? >>> >>> Thanks, >>> Severin >>> From liangchenblue at gmail.com Mon Oct 4 12:38:06 2021 From: liangchenblue at gmail.com (-) Date: Mon, 4 Oct 2021 07:38:06 -0500 Subject: Different behaviors of Ref_InvokeSpecial In-Reply-To: References: Message-ID: Hello, Bystander here. This comment in code [1] may be related information. The question here is more like how the access to methods should be changed. In prior versions, if you want to expose a private method to be overridable, you have to change all calls to it from invokespecial to invokevirtual, and it's no surprise if you need extra housekeeping around simple access changes. But let's take a step back, why are we changing the access of these methods at all, and how are they necessary? Sending this to jdk-dev as this is related to jdk itself than valhalla. Best regards [1] https://github.com/openjdk/jdk/blob/0828273b898cca5368344e75f1c3f4c3a29dde80/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L157 From zekerzhayard at gmail.com Mon Oct 4 13:42:39 2021 From: zekerzhayard at gmail.com (Zeker Zhayard) Date: Mon, 4 Oct 2021 21:42:39 +0800 Subject: Different behaviors of Ref_InvokeSpecial In-Reply-To: References: Message-ID: Hi, This is indeed an edge usage. This is an issue I accidentally discovered in Minecraft modding. Sometimes we need to raise the access level to access internal codes of Minecraft. There are some tools for modifying the access level [1]. However, they only modified invokespecial to invokevirtual, but did not modify ref_invokespecial to ref_invokevirtual, and then I found such a different behavior. Because in the previous jdk versions, calling base class methods all use invokespecial, so it seems to be incorrect of the behavior of invokevirtual after JDK 15 when class version is 52.0 Yours sincerely [1] https://github.com/FabricMC/access-widener - ?2021?10?4??? ??8:38??? > Hello, > Bystander here. This comment in code [1] may be related information. > > The question here is more like how the access to methods should be > changed. In prior versions, if you want to expose a private method to > be overridable, you have to change all calls to it from invokespecial > to invokevirtual, and it's no surprise if you need extra housekeeping > around simple access changes. But let's take a step back, why are we > changing the access of these methods at all, and how are they > necessary? > > Sending this to jdk-dev as this is related to jdk itself than valhalla. > > Best regards > > [1] > https://github.com/openjdk/jdk/blob/0828273b898cca5368344e75f1c3f4c3a29dde80/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L157 > From mandy.chung at oracle.com Mon Oct 4 20:59:39 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 4 Oct 2021 13:59:39 -0700 Subject: Different behaviors of Ref_InvokeSpecial In-Reply-To: References: Message-ID: (valhalla-dev is a proper mailing list to discuss that.? I bcc jdk-dev). Hi Zeker, Which version of javac are you using?? I compiled it with JDK 8u331 and can't reproduce the problem. $ jdk1.8.0_311.jdk/bin/java -version java version "1.8.0_311-ea" Java(TM) SE Runtime Environment (build 1.8.0_311-ea-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.311-b01, mixed mode) $ jdk1.8.0_311.jdk/bin/javac -version javac 1.8.0_311-ea $ jdk1.8.0_311.jdk/bin/javac ExampleClass.java $ jdk1.8.0_311.jdk/bin/java ExampleClass 123 $ jdk-15.jdk/bin/java -version java version "15" 2020-09-15 Java(TM) SE Runtime Environment (build 15+36-1562) Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) $ jdk-15.jdk/bin/java ExampleClass 123 Note that the JVMS change related to invokespecial is part of JEP 181 Nest-based Access Control.? The hidden classes generated by LambdaMetaFactory is a nestmate of the target class and so the bytecode generated was fixed in JEP 371 to use invokevirtual or invokeinterface per JVMS. The bootstrap method javac generated is REF_invokeSpecial in your ExampleClass.? LMF does special handle it for compatibility for existing code to behave as in older releases. BootstrapMethods: ? 0: #34 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; ??? Method arguments: ????? #35 ()Ljava/lang/Object; ????? #36 REF_invokeSpecial ExampleClass.testPrivate:()Ljava/lang/String; ????? #37 ()Ljava/lang/String; I don't see any issue from ExampleClass. Mandy On 10/4/21 2:50 AM, Zeker Zhayard wrote: > Hi, > JEP 371 describes that to invoke private nestmate instance methods from > code in a hidden class, use invokevirtual or invokeinterface instead of > invokespecial and generated bytecode that uses invokespecial to invoke a > private nestmate instance method will fail verification. invokespecial > should only be used to invoke private nestmate constructors. > However, consider the following use case: > > import java.util.function.Supplier; > > public class ExampleClass { > public static void main(String[] args) { > System.out.println(new SubClass().test()); > } > > public String test() { > Supplier supplier = this::testPrivate; > return supplier.get(); > } > > private String testPrivate() { > return "123"; > } > > public static class SubClass extends ExampleClass { > public String testPrivate() { > return "456"; > } > } > } > > 1. Compile it with Java 8 > 2. Modify the access of ExampleClass#testPrivate to protected in bytecode > 3. Running in Java 15+ will get "456" rather than "123" in Java 8~14 From archana.nogriya at uk.ibm.com Tue Oct 5 09:17:52 2021 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Tue, 5 Oct 2021 10:17:52 +0100 Subject: Copyright Issues : JDK8 - GPLv2 is present but Classpath exception is missing In-Reply-To: References: Message-ID: Hi David, Sorry for approaching you directly hoping that you might be able help in JDK8 copyrights issue as well. Thank you in advance. Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Working hrs (Mon-Fri)- 9am - 3pm From: Archana Nogriya/UK/IBM To: jdk-dev at openjdk.java.net Cc: Anthony Renaud/Ottawa/IBM at IBM, Peter Shipton/Ottawa/IBM at IBM, Adam Brousseau/Ottawa/IBM at IBM Date: 07/09/2021 13:54 Subject: Copyright Issues : JDK8 - GPLv2 is present but Classpath exception is missing Hi, Please can someone help to fix the copyright issues in JDK8. We found in our internal scan that - jdk/src/share/native/sun/security/pkcs11/wrapper/pkcs11gcm2.h: GPLv2 is present but Classpath exception is missing. Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Working hrs (Mon-Fri)- 9am - 3pm Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.holmes at oracle.com Tue Oct 5 09:44:42 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Oct 2021 19:44:42 +1000 Subject: Copyright Issues : JDK8 - GPLv2 is present but Classpath exception is missing In-Reply-To: References: Message-ID: Hi Archana, On 5/10/2021 7:17 pm, Archana Nogriya wrote: > Hi David, > > Sorry for approaching you directly hoping that you might be able help in > JDK8 copyrights issue as well. You need to have someone backport: https://bugs.openjdk.java.net/browse/JDK-8236897 to JDK 8u. It is a simple enough process - see: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html for some guidance, and: https://wiki.openjdk.java.net/display/jdk8u/Main but I'm unable to perform that for you. Cheers, David > Thank you in advance. > > > > Many Thanks & Regards > Archana Nogriya > Java Runtimes Development and Project Manager > IBM Hursley > IBM United Kingdom Ltd > internet email: archana.nogriya at uk.ibm.com > Working hrs (Mon-Fri)- 9am - 3pm > > > > > > From: Archana Nogriya/UK/IBM > To: jdk-dev at openjdk.java.net > Cc: Anthony Renaud/Ottawa/IBM at IBM, Peter Shipton/Ottawa/IBM at IBM, Adam > Brousseau/Ottawa/IBM at IBM > Date: 07/09/2021 13:54 > Subject: Copyright Issues : JDK8 - GPLv2 is present but Classpath > exception is missing > ------------------------------------------------------------------------ > > > Hi, > > Please can someone help to fix the copyright issues in JDK8. > We found in our internal scan that > > - jdk/src/share/native/sun/security/pkcs11/wrapper/pkcs11gcm2.h: GPLv2 > is present but Classpath exception is missing. > > > Many Thanks & Regards > Archana Nogriya > Java Runtimes Development and Project Manager > IBM Hursley > IBM United Kingdom Ltd > internet email: archana.nogriya at uk.ibm.com > Working hrs (Mon-Fri)- 9am - 3pm > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From archana.nogriya at uk.ibm.com Tue Oct 5 10:07:10 2021 From: archana.nogriya at uk.ibm.com (Archana Nogriya) Date: Tue, 5 Oct 2021 11:07:10 +0100 Subject: Copyright Issues : JDK8 - GPLv2 is present but Classpath exception is missing In-Reply-To: References: Message-ID: Thank you David for your suggestions. Let me get that on board. Thanks again. Many Thanks & Regards Archana Nogriya Java Runtimes Development and Project Manager IBM Hursley IBM United Kingdom Ltd internet email: archana.nogriya at uk.ibm.com Working hrs (Mon-Fri)- 9am - 3pm From: "David Holmes" To: "Archana Nogriya" , "Severin Gehwolf" Cc: "Anthony Renaud" , "Peter Shipton" , "Adam Brousseau" , jdk-dev at openjdk.java.net Date: 05/10/2021 10:45 Subject: [EXTERNAL] Re: Copyright Issues : JDK8 - GPLv2 is present but Classpath exception is missing Hi Archana, On 5/10/2021 7:17 pm, Archana Nogriya wrote: > Hi David, > > Sorry for approaching you directly hoping that you might be able help in > JDK8 copyrights issue as well. You need to have someone backport: https://bugs.openjdk.java.net/browse/JDK-8236897 to JDK 8u. It is a simple enough process - see: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html for some guidance, and: https://wiki.openjdk.java.net/display/jdk8u/Main but I'm unable to perform that for you. Cheers, David > Thank you in advance. > > > > Many Thanks & Regards > Archana Nogriya > Java Runtimes Development and Project Manager > IBM Hursley > IBM United Kingdom Ltd > internet email: archana.nogriya at uk.ibm.com > Working hrs (Mon-Fri)- 9am - 3pm > > > > > > From: Archana Nogriya/UK/IBM > To: jdk-dev at openjdk.java.net > Cc: Anthony Renaud/Ottawa/IBM at IBM, Peter Shipton/Ottawa/IBM at IBM, Adam > Brousseau/Ottawa/IBM at IBM > Date: 07/09/2021 13:54 > Subject: Copyright Issues : JDK8 - GPLv2 is present but Classpath > exception is missing > ------------------------------------------------------------------------ > > > Hi, > > Please can someone help to fix the copyright issues in JDK8. > We found in our internal scan that > > - jdk/src/share/native/sun/security/pkcs11/wrapper/pkcs11gcm2.h: GPLv2 > is present but Classpath exception is missing. > > > Many Thanks & Regards > Archana Nogriya > Java Runtimes Development and Project Manager > IBM Hursley > IBM United Kingdom Ltd > internet email: archana.nogriya at uk.ibm.com > Working hrs (Mon-Fri)- 9am - 3pm > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From zekerzhayard at gmail.com Tue Oct 5 13:43:30 2021 From: zekerzhayard at gmail.com (Zeker Zhayard) Date: Tue, 5 Oct 2021 21:43:30 +0800 Subject: Different behaviors of Ref_InvokeSpecial In-Reply-To: References: Message-ID: Hi, I'm using: $ java -version openjdk version "1.8.0_302" OpenJDK Runtime Environment (Temurin)(build 1.8.0_302-b08) OpenJDK 64-Bit Server VM (Temurin)(build 25.302-b08, mixed mode) Yes, it is true that there will be no issues when compiling with javac alone. However, if we change the access of a method from private to public in .class file and do not change the invokespecial/ref_invokespecial of this method in the class to invokevirtual/ref_invokevirtual, some different behaviors will occur. For invokespecial, it is not surprising that it will invoke the method in super class no matter what java version is, but for ref_invokespecial, before java 14, it will invoke super method, but after java 15, the subclass method will be invoked. Specific to this use case: import java.util.function.Supplier; public class ExampleClass { public static void main(String[] args) { System.out.println(new SubClass().test()); System.out.println(new SubClass().testWithLMF()); } public String test() { return this.testPrivate(); } public String testWithLMF() { Supplier supplier = this::testPrivate; return supplier.get(); } private String testPrivate() { return "123"; } public static class SubClass extends ExampleClass { public String testPrivate() { return "456"; } } } Compile it with java 8 and modify the access of testPrivate from private to public in .class file (do not modify any invokespecial and ref_invokespecial). Java 14: $ java ExampleClass 123 123 Java 15: $ java ExampleClass 123 456 I think this result is not as expected. This part of the code may not be thoughtful [1]. [1] https://github.com/openjdk/jdk/blob/0828273b898cca5368344e75f1c3f4c3a29dde80/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L157 Yours sincerely On Tue, Oct 5, 2021 at 5:00 AM Mandy Chung wrote: > (valhalla-dev is a proper mailing list to discuss that. I bcc jdk-dev). > > Hi Zeker, > > Which version of javac are you using? I compiled it with JDK 8u331 and > can't reproduce the problem. > > $ jdk1.8.0_311.jdk/bin/java -version > java version "1.8.0_311-ea" > Java(TM) SE Runtime Environment (build 1.8.0_311-ea-b01) > Java HotSpot(TM) 64-Bit Server VM (build 25.311-b01, mixed mode) > > $ jdk1.8.0_311.jdk/bin/javac -version > javac 1.8.0_311-ea > > $ jdk1.8.0_311.jdk/bin/javac ExampleClass.java > $ jdk1.8.0_311.jdk/bin/java ExampleClass > 123 > > $ jdk-15.jdk/bin/java -version > java version "15" 2020-09-15 > Java(TM) SE Runtime Environment (build 15+36-1562) > Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) > > $ jdk-15.jdk/bin/java ExampleClass > 123 > > > Note that the JVMS change related to invokespecial is part of JEP 181 > Nest-based Access Control. The hidden classes generated by > LambdaMetaFactory is a nestmate of the target class and so the bytecode > generated was fixed in JEP 371 to use invokevirtual or invokeinterface per > JVMS. > > The bootstrap method javac generated is REF_invokeSpecial in your > ExampleClass. LMF does special handle it for compatibility for existing > code to behave as in older releases. > > BootstrapMethods: > 0: #34 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > Method arguments: > #35 ()Ljava/lang/Object; > #36 REF_invokeSpecial ExampleClass.testPrivate:()Ljava/lang/String; > #37 ()Ljava/lang/String; > > > I don't see any issue from ExampleClass. > > Mandy > > On 10/4/21 2:50 AM, Zeker Zhayard wrote: > > Hi, > JEP 371 describes that to invoke private nestmate instance methods from > code in a hidden class, use invokevirtual or invokeinterface instead of > invokespecial and generated bytecode that uses invokespecial to invoke a > private nestmate instance method will fail verification. invokespecial > should only be used to invoke private nestmate constructors. > However, consider the following use case: > > import java.util.function.Supplier; > > public class ExampleClass { > public static void main(String[] args) { > System.out.println(new SubClass().test()); > } > > public String test() { > Supplier supplier = this::testPrivate; > return supplier.get(); > } > > private String testPrivate() { > return "123"; > } > > public static class SubClass extends ExampleClass { > public String testPrivate() { > return "456"; > } > } > } > > 1. Compile it with Java 8 > 2. Modify the access of ExampleClass#testPrivate to protected in bytecode > 3. Running in Java 15+ will get "456" rather than "123" in Java 8~14 > > > From mark.yagnatinsky at barclays.com Tue Oct 5 21:55:45 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Tue, 5 Oct 2021 21:55:45 +0000 Subject: crazy idea: weaken the effectively final restriction Message-ID: I'm not sure if this is the right list for this; if not I hope someone can redirect me. Java requires that local variables that are captured by a lambda must be effectively final. This restriction has the benefit that no one needs to worry about annoying questions such as "what are the semantics of a data race on a local variable" and other such horrors. But this benefit can still be obtained by a weaker restriction. For instance, consider this code, which currently does not compile: Runnable f(String s) { s = normalize(s); return () -> println(s); // no can do: s is not effectively final } However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. What do we gain by allowing the code above? Well, if we don't allow it, how can the code above be fixed? We would have to introduce a new local variable. That would actually be fine, except for another rule Java has, also for a good reason: one local variable name can NOT "shadow" another: all local variables must have distinct names. That is, we can do something like this: String s = "hello"; String s = s.trim(); So we need to come up with a new name, and this has two costs: First, coming up with good names is hard, and coming up with two good names for what is basically the same thing is harder. Second, suppose that when we first wrote the method, the variable really was effectively final, and we needed to change it many months/years/decades later. We now need to update the appropriate usages to the new name. This tends to clutter line-based diffs, creating more work for reviewers during pull requests, and also for code archeologists. Third (did I say two?): we must spend mental bandwidth deciding how to accomplish renaming things. In the example above we have at least two options: Runnable f(String t) {// option 1: rename original String s = normalize(t); return () -> println(s); } Runnable f(String s) {// option 2: keep original String t = normalize(s); return () -> println(t); } Deciding which option is better might actually involve non-trivial tradeoffs. Perhaps option 1 leads to a smaller diff, but option 2 leads to a better parameter name for the method signature. How important are good parameter names? What if it's a private method with only one caller? Etc. It seems that all this nuisance would go away almost for free if we just weaken the restriction to "effectively final from point of capture". The only possible downside I can see is that this would be a bit more annoying to properly specify in the language spec. So... opinions? Good idea? Bad idea? 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 lutz.schmidt at sap.com Wed Oct 6 07:51:19 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 6 Oct 2021 07:51:19 +0000 Subject: New JDK Reviewer: Ralf Schmelter Message-ID: Vote: yes Cheers, Lutz From: G?tz Lindenmaier Date: Wednesday, 6. October 2021 at 09:17 To: Lutz Schmidt Subject: FW: CFV: New JDK Reviewer: Ralf Schmelter From: Lindenmaier, Goetz Sent: Wednesday, September 22, 2021 11:52 AM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Ralf Schmelter I hereby nominate Ralf Schmelter (rschmelter)[0] to OpenJDK Reviewer. Ralf is currently a JDK Committer and a member of the SAP JVM team. He has a long history in the SAP JVM team and basically knows each corner of the OpenJDK. In Hotspot, he has deep knowledge of the various garbage collections, the basic runtime implementation, debugging and JVMTI support and many more. At SAP, he developed a row of profiling and supportability tools. A large part of his changes in OpenJDK address supportability improvements of the VM, as, e.g., improving the experience of working with heap dumps[1]. He always follows a global approach, e.g., also addressing changes needed in tools. He has contributed overall 32 changes [4] in the past years. He also already reviewed a row of complex changes. He is an expert in Windows, which is nowadays rare in the OpenJDK community. Votes are due 12:00 CEST on Wednesday, the 6th of October, 2021 Only current OpenJDK Reviewers (and above) [5] 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 [6]. Best regards, Goetz. [0] http://openjdk.java.net/census#rschmelter [1] https://bugs.openjdk.java.net/browse/JDK-8237354: Add option to jcmd to write a gzipped heap dump [2] https://bugs.openjdk.java.net/browse/JDK-8234510: Remove file seeking requirement for writing a heap dump [3] https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/173722 [4] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Ralf+Schmelter%22&type=commits [5] https://openjdk.java.net/census#jdk [6] http://openjdk.java.net/projects/#reviewer-vote From raffaello.giulietti at gmail.com Wed Oct 6 12:51:19 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 6 Oct 2021 14:51:19 +0200 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: References: Message-ID: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> Hi, what if the variable is reassigned after the capture? Runnable f(String s) { Runnable r = () -> println(s); s = normalize(s); // perfectly useless assignment return r; } It would not be "effectively final from point of capture", so would this lead to a compilation error? Greetings Raffaello On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: > I'm not sure if this is the right list for this; if not I hope someone can redirect me. > > Java requires that local variables that are captured by a lambda must be effectively final. > This restriction has the benefit that no one needs to worry about annoying questions such as "what are the semantics of a data race on a local variable" and other such horrors. > > But this benefit can still be obtained by a weaker restriction. For instance, consider this code, which currently does not compile: > > Runnable f(String s) { > s = normalize(s); > return () -> println(s); // no can do: s is not effectively final > } > > However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. > Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. > > What do we gain by allowing the code above? Well, if we don't allow it, how can the code above be fixed? We would have to introduce a new local variable. > That would actually be fine, except for another rule Java has, also for a good reason: one local variable name can NOT "shadow" another: all local variables must have distinct names. > That is, we can do something like this: String s = "hello"; String s = s.trim(); > So we need to come up with a new name, and this has two costs: > First, coming up with good names is hard, and coming up with two good names for what is basically the same thing is harder. > Second, suppose that when we first wrote the method, the variable really was effectively final, and we needed to change it many months/years/decades later. > We now need to update the appropriate usages to the new name. This tends to clutter line-based diffs, creating more work for reviewers during pull requests, and also for code archeologists. > Third (did I say two?): we must spend mental bandwidth deciding how to accomplish renaming things. In the example above we have at least two options: > > Runnable f(String t) {// option 1: rename original > String s = normalize(t); > return () -> println(s); > } > > Runnable f(String s) {// option 2: keep original > String t = normalize(s); > return () -> println(t); > } > > Deciding which option is better might actually involve non-trivial tradeoffs. Perhaps option 1 leads to a smaller diff, but option 2 leads to a better parameter name for the method signature. > How important are good parameter names? What if it's a private method with only one caller? Etc. > > It seems that all this nuisance would go away almost for free if we just weaken the restriction to "effectively final from point of capture". > The only possible downside I can see is that this would be a bit more annoying to properly specify in the language spec. > > So... opinions? Good idea? Bad idea? > > 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.yagnatinsky at barclays.com Wed Oct 6 13:34:47 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Wed, 6 Oct 2021 13:34:47 +0000 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> References: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> Message-ID: Yeah, that should be a compilation error, no doubt in my mind. -----Original Message----- From: Raffaello Giulietti Sent: Wednesday, October 6, 2021 8:51 AM To: Yagnatinsky, Mark : Markets Pre Trade ; jdk-dev at openjdk.java.net Subject: Re: crazy idea: weaken the effectively final restriction CAUTION: This email originated from outside our organisation - raffaello.giulietti at gmail.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Hi, what if the variable is reassigned after the capture? Runnable f(String s) { Runnable r = () -> println(s); s = normalize(s); // perfectly useless assignment return r; } It would not be "effectively final from point of capture", so would this lead to a compilation error? Greetings Raffaello On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: > I'm not sure if this is the right list for this; if not I hope someone can redirect me. > > Java requires that local variables that are captured by a lambda must be effectively final. > This restriction has the benefit that no one needs to worry about annoying questions such as "what are the semantics of a data race on a local variable" and other such horrors. > > But this benefit can still be obtained by a weaker restriction. For instance, consider this code, which currently does not compile: > > Runnable f(String s) { > s = normalize(s); > return () -> println(s); // no can do: s is not > effectively final } > > However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. > Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. > > What do we gain by allowing the code above? Well, if we don't allow it, how can the code above be fixed? We would have to introduce a new local variable. > That would actually be fine, except for another rule Java has, also for a good reason: one local variable name can NOT "shadow" another: all local variables must have distinct names. > That is, we can do something like this: String s = "hello"; String s = > s.trim(); So we need to come up with a new name, and this has two costs: > First, coming up with good names is hard, and coming up with two good names for what is basically the same thing is harder. > Second, suppose that when we first wrote the method, the variable really was effectively final, and we needed to change it many months/years/decades later. > We now need to update the appropriate usages to the new name. This tends to clutter line-based diffs, creating more work for reviewers during pull requests, and also for code archeologists. > Third (did I say two?): we must spend mental bandwidth deciding how to accomplish renaming things. In the example above we have at least two options: > > Runnable f(String t) {// option 1: rename original > String s = normalize(t); > return () -> println(s); } > > Runnable f(String s) {// option 2: keep original > String t = normalize(s); > return () -> println(t); } > > Deciding which option is better might actually involve non-trivial tradeoffs. Perhaps option 1 leads to a smaller diff, but option 2 leads to a better parameter name for the method signature. > How important are good parameter names? What if it's a private method with only one caller? Etc. > > It seems that all this nuisance would go away almost for free if we just weaken the restriction to "effectively final from point of capture". > The only possible downside I can see is that this would be a bit more annoying to properly specify in the language spec. > > So... opinions? Good idea? Bad idea? > > 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: https://clicktime.symantec.com/32UvaghDwddiNtyxZshdxn26H2?u=www.barclays.com%2Femaildisclaimer. > > For important disclosures, please see: https://clicktime.symantec.com/3R6wy3W52RJZVEpxfpnmMVP6H2?u=www.barclays.com%2Fsalesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://clicktime.symantec.com/3NnpKFi1A6juTKGF98ZrfGD6H2?u=https%3A%2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fbarclays-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://clicktime.symantec.com/36u32shw9johG9qDniZaV7e6H2?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/3WVoFxocZXBFDZdoaxRdCKz6H2?u=https%3A%2 > F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fpersonalinformatio > nuse.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 brian.goetz at oracle.com Wed Oct 6 15:12:18 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 6 Oct 2021 15:12:18 +0000 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> References: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> Message-ID: <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> A good way to think about this is to zoom out and realize that there is a spectrum, with trade-offs. At one end of the spectrum is ?no capture at all?, which is simple and easy to reason about, but ? unsatisfying. At the other end is that we close over variables rather than values, which some languages do, which is defensible but leads to surprising bugs. In the middle are options like ?capture final variables only?, ?capture effectively final variables only?, etc. Your option is somewhat to the ?right? of ?effectively final.? What you?re saying is that we could capture things that are not effectively final, if we can prove that all writes happen before the capture point in the execution order. Java does flow analysis to determine definite assignment, so such an enhanced flow analysis is imaginable. The way to think about this is whether the incremental expressiveness warrants the incremental complexity. Yes, there are a small number of cases where the more refined analysis would make a difference, but it?s really not that many. On the other side, ?effectively final? is an easier concept to explain to developers; there is definitely incremental complexity in the user model here. Is the trade worth it? My sense: meh. I don?t see a huge degree of leverage here. A similar example where we chose a simpler rule than necessary was in `var`. The intent is that local variable type inference is for implementation, not for API. So you can use it for locals, but not for, say, method returns, because that?s API, not just implementation. Invariably, some slightly-too-clever person asks ?but, then why can?t I use it for the return of a *private* method? That?s not API. AHA! Gotcha!? The answer is of course simple; we could make the boundary of the feature arbitrarily complex, but if the incremental complexity makes it harder for people to reason about when they can use var and when not, then we?re not necessarily helping by making it incrementally more expressive. A simple rule that is easy to reason about is often better than a fractally complex one that is slightly more powerful. So, to summarize, the idea isn?t crazy, it just doesn?t seem worth it in the balance between complexity and expressiveness. I?d rather spend that complexity budget on something with more leverage. Cheers, -Brian > On Oct 6, 2021, at 8:51 AM, Raffaello Giulietti wrote: > > Hi, > > what if the variable is reassigned after the capture? > > Runnable f(String s) { > Runnable r = () -> println(s); > s = normalize(s); // perfectly useless assignment > return r; > } > > It would not be "effectively final from point of capture", so would this lead to a compilation error? > > > Greetings > Raffaello > > > > On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: >> I'm not sure if this is the right list for this; if not I hope someone can redirect me. >> Java requires that local variables that are captured by a lambda must be effectively final. >> This restriction has the benefit that no one needs to worry about annoying questions such as "what are the semantics of a data race on a local variable" and other such horrors. >> But this benefit can still be obtained by a weaker restriction. For instance, consider this code, which currently does not compile: >> Runnable f(String s) { >> s = normalize(s); >> return () -> println(s); // no can do: s is not effectively final >> } >> However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. >> Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. >> What do we gain by allowing the code above? Well, if we don't allow it, how can the code above be fixed? We would have to introduce a new local variable. >> That would actually be fine, except for another rule Java has, also for a good reason: one local variable name can NOT "shadow" another: all local variables must have distinct names. >> That is, we can do something like this: String s = "hello"; String s = s.trim(); >> So we need to come up with a new name, and this has two costs: >> First, coming up with good names is hard, and coming up with two good names for what is basically the same thing is harder. >> Second, suppose that when we first wrote the method, the variable really was effectively final, and we needed to change it many months/years/decades later. >> We now need to update the appropriate usages to the new name. This tends to clutter line-based diffs, creating more work for reviewers during pull requests, and also for code archeologists. >> Third (did I say two?): we must spend mental bandwidth deciding how to accomplish renaming things. In the example above we have at least two options: >> Runnable f(String t) {// option 1: rename original >> String s = normalize(t); >> return () -> println(s); >> } >> Runnable f(String s) {// option 2: keep original >> String t = normalize(s); >> return () -> println(t); >> } >> Deciding which option is better might actually involve non-trivial tradeoffs. Perhaps option 1 leads to a smaller diff, but option 2 leads to a better parameter name for the method signature. >> How important are good parameter names? What if it's a private method with only one caller? Etc. >> It seems that all this nuisance would go away almost for free if we just weaken the restriction to "effectively final from point of capture". >> The only possible downside I can see is that this would be a bit more annoying to properly specify in the language spec. >> So... opinions? Good idea? Bad idea? >> 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.yagnatinsky at barclays.com Wed Oct 6 15:44:58 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Wed, 6 Oct 2021 15:44:58 +0000 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> References: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> Message-ID: Thank you the detailed response! I wonder if local variable type inference is the right analogy here. Let me propose my own analogy: type inference for method overloads and its interaction with lambdas and such. The rules there are insanely complicated, to the point where hardly anyone understands them. But all that complexity accomplishes something very nice: things tend to Just Work, so no one has to even think about the rules most of the time. Sometimes you hit a case where it breaks down and you have to be explicit about something the compiler "should" be able to infer, but it's pretty rare. (Though I few times I've hit a case where the compiler didn't like my comparator because of this.) Similarly, this proposal trades off explain-ability of rules (though they still remain simpler than the stuff that goes on with method overloads I think), and in exchange buys freedom from the rules getting in your way. Whether this trade-off is worth it I think should ultimately depend on how often such "pointless" variable declarations end up being needed. For instance, I think you would agree that if such variable declarations made up 10% of all local variables in a typical Java code base, this feature probably would be worth the complexity. I'm not sure how common they actually are; obviously, they are nowhere near 10%. Okay I'll stop arguing/whining now :) Mark. P.S. thanks again for the detailed response! -----Original Message----- From: Brian Goetz Sent: Wednesday, October 6, 2021 11:12 AM To: Raffaello Giulietti Cc: Yagnatinsky, Mark : Markets Pre Trade ; jdk-dev at openjdk.java.net Subject: Re: crazy idea: weaken the effectively final restriction CAUTION: This email originated from outside our organisation - brian.goetz at oracle.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. A good way to think about this is to zoom out and realize that there is a spectrum, with trade-offs. At one end of the spectrum is ???no capture at all???, which is simple and easy to reason about, but ??? unsatisfying. At the other end is that we close over variables rather than values, which some languages do, which is defensible but leads to surprising bugs. In the middle are options like ???capture final variables only???, ???capture effectively final variables only???, etc. Your option is somewhat to the ???right??? of ???effectively final.??? What you???re saying is that we could capture things that are not effectively final, if we can prove that all writes happen before the capture point in the execution order. Java does flow analysis to determine definite assignment, so such an enhanced flow analysis is imaginable. The way to think about this is whether the incremental expressiveness warrants the incremental complexity. Yes, there are a small number of cases where the more refined analysis would make a difference, but it???s really not that many. On the other side, ???effectively final??? is an easier concept to explain to developers; there is definitely incremental complexity in the user model here. Is the trade worth it? My sense: meh. I don???t see a huge degree of leverage here. A similar example where we chose a simpler rule than necessary was in `var`. The intent is that local variable type inference is for implementation, not for API. So you can use it for locals, but not for, say, method returns, because that???s API, not just implementation. Invariably, some slightly-too-clever person asks ???but, then why can???t I use it for the return of a *private* method? That???s not API. AHA! Gotcha!??? The answer is of course simple; we could make the boundary of the feature arbitrarily complex, but if the incremental complexity makes it harder for people to reason about when they can use var and when not, then we???re not necessarily helping by making it incrementally more expressive. A simple rule that is easy to reason about is often better than a fractally complex one that is slightly more powerful. So, to summarize, the idea isn???t crazy, it just doesn???t seem worth it in the balance between complexity and expressiveness. I???d rather spend that complexity budget on something with more leverage. Cheers, -Brian > On Oct 6, 2021, at 8:51 AM, Raffaello Giulietti wrote: > > Hi, > > what if the variable is reassigned after the capture? > > Runnable f(String s) { > Runnable r = () -> println(s); > s = normalize(s); // perfectly useless assignment > return r; > } > > It would not be "effectively final from point of capture", so would this lead to a compilation error? > > > Greetings > Raffaello > > > > On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: >> I'm not sure if this is the right list for this; if not I hope someone can redirect me. >> Java requires that local variables that are captured by a lambda must be effectively final. >> This restriction has the benefit that no one needs to worry about annoying questions such as "what are the semantics of a data race on a local variable" and other such horrors. >> But this benefit can still be obtained by a weaker restriction. For instance, consider this code, which currently does not compile: >> Runnable f(String s) { >> s = normalize(s); >> return () -> println(s); // no can do: s is not >> effectively final } However, this seems a bit silly because although >> s is not final throughout the entire method, it's final where it actually matters. >> Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. >> What do we gain by allowing the code above? Well, if we don't allow it, how can the code above be fixed? We would have to introduce a new local variable. >> That would actually be fine, except for another rule Java has, also for a good reason: one local variable name can NOT "shadow" another: all local variables must have distinct names. >> That is, we can do something like this: String s = "hello"; String s >> = s.trim(); So we need to come up with a new name, and this has two costs: >> First, coming up with good names is hard, and coming up with two good names for what is basically the same thing is harder. >> Second, suppose that when we first wrote the method, the variable really was effectively final, and we needed to change it many months/years/decades later. >> We now need to update the appropriate usages to the new name. This tends to clutter line-based diffs, creating more work for reviewers during pull requests, and also for code archeologists. >> Third (did I say two?): we must spend mental bandwidth deciding how to accomplish renaming things. In the example above we have at least two options: >> Runnable f(String t) {// option 1: rename original >> String s = normalize(t); >> return () -> println(s); } Runnable f(String s) {// >> option 2: keep original >> String t = normalize(s); >> return () -> println(t); } Deciding which option is >> better might actually involve non-trivial tradeoffs. Perhaps option 1 leads to a smaller diff, but option 2 leads to a better parameter name for the method signature. >> How important are good parameter names? What if it's a private method with only one caller? Etc. >> It seems that all this nuisance would go away almost for free if we just weaken the restriction to "effectively final from point of capture". >> The only possible downside I can see is that this would be a bit more annoying to properly specify in the language spec. >> So... opinions? Good idea? Bad idea? >> 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: https://clicktime.symantec.com/3RvVXadG34hwCBkP8n8LdA6H2?u=www.barclays.com%2Femaildisclaimer. >> For important disclosures, please see: https://clicktime.symantec.com/32YvpMq3ywF4MBUgrYcExHk6H2?u=www.barclays.com%2Fsalesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://clicktime.symantec.com/3CeFiviotYo7kzb3sfoB4H46H2?u=https%3A%2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fbarclays-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://clicktime.symantec.com/363JsWkoFWSnAzXKqMUkAxC6H2?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/3KcfyEdGC8pv5YeHZ23xfDv6H2?u=https%3A% >> 2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fpersonalinformat >> ionuse.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 mandy.chung at oracle.com Wed Oct 6 16:19:35 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 6 Oct 2021 09:19:35 -0700 Subject: Different behaviors of Ref_InvokeSpecial In-Reply-To: References: Message-ID: <54fe4de3-b8a3-ed47-1678-ec06e7e653c5@oracle.com> Thanks for reporting. I have created https://bugs.openjdk.java.net/browse/JDK-8274848 to follow up this issue. Mandy On 10/5/21 6:43 AM, Zeker Zhayard wrote: > Hi, > > I'm using: > > $ java -version > openjdk version "1.8.0_302" > OpenJDK Runtime Environment (Temurin)(build 1.8.0_302-b08) > OpenJDK 64-Bit Server VM (Temurin)(build 25.302-b08, mixed mode) > > Yes, it is true that there will be no issues when compiling with javac > alone.?However, if we change the access of a method from private to > public in .class file and do not change the > invokespecial/ref_invokespecial of this method in the class to > invokevirtual/ref_invokevirtual,?some different behaviors will occur. > > For invokespecial, it is not surprising?that it will invoke the method > in super class no matter what java version is, but for > ref_invokespecial, before java 14, it will invoke super method, but > after java 15, the subclass method will be invoked. > > Specific to this use case: > > import java.util.function.Supplier; > > public class ExampleClass { > ? ? public static void main(String[] args) { > System.out.println(new SubClass().test()); > System.out.println(new SubClass().testWithLMF()); > ? ? } > > ? ? public String test() { > ? ? ? ? return this.testPrivate(); > ? ? } > > ? ? public String testWithLMF() { > Supplier supplier = this::testPrivate; > ? ? ? ? return supplier.get(); > ? ? } > > ? ? private String testPrivate() { > ? ? ? ? return "123"; > ? ? } > > ? ? public static class SubClass extends ExampleClass { > ? ? ? ? public String testPrivate() { > ? ? ? ? ? ? return "456"; > ? ? ? ? } > ? ? } > } > > Compile it with java 8 and modify the access of testPrivate from > private to public in .class file (do not modify any invokespecial and > ref_invokespecial). > > Java 14: > > $ java ExampleClass > 123 > 123 > > Java 15: > > $ java ExampleClass > 123 > 456 > > I think this result is not as expected. This part of the code may not > be thoughtful [1]. > > [1] > https://github.com/openjdk/jdk/blob/0828273b898cca5368344e75f1c3f4c3a29dde80/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java#L157 > > > Yours sincerely > > On Tue, Oct 5, 2021 at 5:00 AM Mandy Chung > wrote: > > (valhalla-dev is a proper mailing list to discuss that.? I bcc > jdk-dev). > > Hi Zeker, > > Which version of javac are you using?? I compiled it with JDK > 8u331 and can't reproduce the problem. > > $ jdk1.8.0_311.jdk/bin/java -version > java version "1.8.0_311-ea" > Java(TM) SE Runtime Environment (build 1.8.0_311-ea-b01) > Java HotSpot(TM) 64-Bit Server VM (build 25.311-b01, mixed mode) > > $ jdk1.8.0_311.jdk/bin/javac -version > javac 1.8.0_311-ea > > $ jdk1.8.0_311.jdk/bin/javac ExampleClass.java > $ jdk1.8.0_311.jdk/bin/java ExampleClass > 123 > > $ jdk-15.jdk/bin/java -version > java version "15" 2020-09-15 > Java(TM) SE Runtime Environment (build 15+36-1562) > Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, > sharing) > > $ jdk-15.jdk/bin/java ExampleClass > 123 > > > Note that the JVMS change related to invokespecial is part of JEP > 181 Nest-based Access Control.? The hidden classes generated by > LambdaMetaFactory is a nestmate of the target class and so the > bytecode generated was fixed in JEP 371 to use invokevirtual or > invokeinterface per JVMS. > > The bootstrap method javac generated is REF_invokeSpecial in your > ExampleClass.? LMF does special handle it for compatibility for > existing code to behave as in older releases. > > BootstrapMethods: > ? 0: #34 REF_invokeStatic > java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > ??? Method arguments: > ????? #35 ()Ljava/lang/Object; > ????? #36 REF_invokeSpecial > ExampleClass.testPrivate:()Ljava/lang/String; > ????? #37 ()Ljava/lang/String; > > > I don't see any issue from ExampleClass. > > Mandy > > On 10/4/21 2:50 AM, Zeker Zhayard wrote: >> Hi, >> JEP 371 describes that to invoke private nestmate instance methods from >> code in a hidden class, use invokevirtual or invokeinterface instead of >> invokespecial and generated bytecode that uses invokespecial to invoke a >> private nestmate instance method will fail verification. invokespecial >> should only be used to invoke private nestmate constructors. >> However, consider the following use case: >> >> import java.util.function.Supplier; >> >> public class ExampleClass { >> public static void main(String[] args) { >> System.out.println(new SubClass().test()); >> } >> >> public String test() { >> Supplier supplier = this::testPrivate; >> return supplier.get(); >> } >> >> private String testPrivate() { >> return "123"; >> } >> >> public static class SubClass extends ExampleClass { >> public String testPrivate() { >> return "456"; >> } >> } >> } >> >> 1. Compile it with Java 8 >> 2. Modify the access of ExampleClass#testPrivate to protected in bytecode >> 3. Running in Java 15+ will get "456" rather than "123" in Java 8~14 > From forax at univ-mlv.fr Wed Oct 6 16:23:57 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Oct 2021 18:23:57 +0200 (CEST) Subject: crazy idea: weaken the effectively final restriction In-Reply-To: <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> References: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> Message-ID: <119650079.1802776.1633537437560.JavaMail.zimbra@u-pem.fr> Hi Mark, to complete Brian answer, - Reassigning a local variable without being inside a loop is usually seen as a code smell, because when you read the code a little to fast you can miss the second assignment thus believe that the code behave differently than what is written. - The semantics you propose behave differently if the captured variable is available outside the loop or not, so Runnable r = () -> println(s); s = normalize(s); will behave differently from var s = for(...) { Runnable r = () -> println(s); s = normalize(s); } ... s ... If you see the local variable in SSA form, the semantics depend if there is a phi or not. - We also did not want to have a semantics depending on what you call "the point of capture", i.e. we wanted to have a semantics that does not explicitly specify when the lambda is created, this allows implementations/translation strategies to create reusable lambda instance either lazily or eagerly. This is something important because we can support both invokedynamic which does the allocation as late as possible and GraalVM native image / AppCDS that may store the lambda instance directly in the image. You may think that we are talking about capture here so a lambda instance can not be reused but a captured value can be proved to be a constant by a static/runtime analysis. - Effectively final is a semantics that is used not only for lambdas but also for anonymous classes and recently for guarded patterns, for a pattern the "the point of capture" is not clearly defined. Is it when you want to evaluate the switch ? or when you evaluate the guard of the pattern ? So yes, we can try to tweak that rule but as Brian said, it just doesn?t seem worth the complexity. regards, R?mi ----- Original Message ----- > From: "Brian Goetz" > To: "raffaello giulietti" > Cc: "mark yagnatinsky" , "jdk-dev" > Sent: Mercredi 6 Octobre 2021 17:12:18 > Subject: Re: crazy idea: weaken the effectively final restriction > A good way to think about this is to zoom out and realize that there is a > spectrum, with trade-offs. At one end of the spectrum is ?no capture at all?, > which is simple and easy to reason about, but ? unsatisfying. At the other end > is that we close over variables rather than values, which some languages do, > which is defensible but leads to surprising bugs. In the middle are options > like ?capture final variables only?, ?capture effectively final variables > only?, etc. Your option is somewhat to the ?right? of ?effectively final.? > > What you?re saying is that we could capture things that are not effectively > final, if we can prove that all writes happen before the capture point in the > execution order. Java does flow analysis to determine definite assignment, so > such an enhanced flow analysis is imaginable. > > The way to think about this is whether the incremental expressiveness warrants > the incremental complexity. Yes, there are a small number of cases where the > more refined analysis would make a difference, but it?s really not that many. > On the other side, ?effectively final? is an easier concept to explain to > developers; there is definitely incremental complexity in the user model here. > Is the trade worth it? My sense: meh. I don?t see a huge degree of leverage > here. > > A similar example where we chose a simpler rule than necessary was in `var`. > The intent is that local variable type inference is for implementation, not > for API. So you can use it for locals, but not for, say, method returns, > because that?s API, not just implementation. Invariably, some > slightly-too-clever person asks ?but, then why can?t I use it for the return of > a *private* method? That?s not API. AHA! Gotcha!? > > The answer is of course simple; we could make the boundary of the feature > arbitrarily complex, but if the incremental complexity makes it harder for > people to reason about when they can use var and when not, then we?re not > necessarily helping by making it incrementally more expressive. A simple rule > that is easy to reason about is often better than a fractally complex one that > is slightly more powerful. > > So, to summarize, the idea isn?t crazy, it just doesn?t seem worth it in the > balance between complexity and expressiveness. I?d rather spend that > complexity budget on something with more leverage. > > Cheers, > -Brian > >> On Oct 6, 2021, at 8:51 AM, Raffaello Giulietti >> wrote: >> >> Hi, >> >> what if the variable is reassigned after the capture? >> >> Runnable f(String s) { >> Runnable r = () -> println(s); >> s = normalize(s); // perfectly useless assignment >> return r; >> } >> >> It would not be "effectively final from point of capture", so would this lead to >> a compilation error? >> >> >> Greetings >> Raffaello >> >> >> >> On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: >>> I'm not sure if this is the right list for this; if not I hope someone can >>> redirect me. >>> Java requires that local variables that are captured by a lambda must be >>> effectively final. >>> This restriction has the benefit that no one needs to worry about annoying >>> questions such as "what are the semantics of a data race on a local variable" >>> and other such horrors. >>> But this benefit can still be obtained by a weaker restriction. For instance, >>> consider this code, which currently does not compile: >>> Runnable f(String s) { >>> s = normalize(s); >>> return () -> println(s); // no can do: s is not effectively final >>> } >>> However, this seems a bit silly because although s is not final throughout the >>> entire method, it's final where it actually matters. >>> Namely, it is final from the point of capture to the end of the method, and >>> that's the only condition we need to avoid those annoying questions. >>> What do we gain by allowing the code above? Well, if we don't allow it, how can >>> the code above be fixed? We would have to introduce a new local variable. >>> That would actually be fine, except for another rule Java has, also for a good >>> reason: one local variable name can NOT "shadow" another: all local variables >>> must have distinct names. >>> That is, we can do something like this: String s = "hello"; String s = s.trim(); >>> So we need to come up with a new name, and this has two costs: >>> First, coming up with good names is hard, and coming up with two good names for >>> what is basically the same thing is harder. >>> Second, suppose that when we first wrote the method, the variable really was >>> effectively final, and we needed to change it many months/years/decades later. >>> We now need to update the appropriate usages to the new name. This tends to >>> clutter line-based diffs, creating more work for reviewers during pull >>> requests, and also for code archeologists. >>> Third (did I say two?): we must spend mental bandwidth deciding how to >>> accomplish renaming things. In the example above we have at least two options: >>> Runnable f(String t) {// option 1: rename original >>> String s = normalize(t); >>> return () -> println(s); >>> } >>> Runnable f(String s) {// option 2: keep original >>> String t = normalize(s); >>> return () -> println(t); >>> } >>> Deciding which option is better might actually involve non-trivial tradeoffs. >>> Perhaps option 1 leads to a smaller diff, but option 2 leads to a better >>> parameter name for the method signature. >>> How important are good parameter names? What if it's a private method with only >>> one caller? Etc. >>> It seems that all this nuisance would go away almost for free if we just weaken >>> the restriction to "effectively final from point of capture". >>> The only possible downside I can see is that this would be a bit more annoying >>> to properly specify in the language spec. >>> So... opinions? Good idea? Bad idea? >>> 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.yagnatinsky at barclays.com Wed Oct 6 17:05:57 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Wed, 6 Oct 2021 17:05:57 +0000 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: <119650079.1802776.1633537437560.JavaMail.zimbra@u-pem.fr> References: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> <119650079.1802776.1633537437560.JavaMail.zimbra@u-pem.fr> Message-ID: Re: guarded switch: I confess I have not been watching the latest developments in pattern matching. (Enhanced instanceof is great though!) If it turns out that effectively final makes sense there too, then I guess that's another strike against my idea; might as well re-use the same concept with lambdas too. Re: reading code too fast could result in overlooking an assignment: this has recently become a "solved problem" for me, because IntelliJ by default underlines local variables that are NOT effectively final. I do have one quibble with what you said though: my proposed semantics do NOT behave differently in the two examples you listed. In particular, neither example compiles, since there is an assignment to the variable AFTER it was already captured. Of course, your misunderstanding is also a strike against my idea: if I can't even explain it to experts, what hope is there that mere mortals can keep this straight? -----Original Message----- From: Remi Forax Sent: Wednesday, October 6, 2021 12:24 PM To: Brian Goetz Cc: raffaello giulietti ; Yagnatinsky, Mark : Markets Pre Trade ; jdk-dev Subject: Re: crazy idea: weaken the effectively final restriction CAUTION: This email originated from outside our organisation - forax at univ-mlv.fr Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Hi Mark, to complete Brian answer, - Reassigning a local variable without being inside a loop is usually seen as a code smell, because when you read the code a little to fast you can miss the second assignment thus believe that the code behave differently than what is written. - The semantics you propose behave differently if the captured variable is available outside the loop or not, so Runnable r = () -> println(s); s = normalize(s); will behave differently from var s = for(...) { Runnable r = () -> println(s); s = normalize(s); } ... s ... If you see the local variable in SSA form, the semantics depend if there is a phi or not. - We also did not want to have a semantics depending on what you call "the point of capture", i.e. we wanted to have a semantics that does not explicitly specify when the lambda is created, this allows implementations/translation strategies to create reusable lambda instance either lazily or eagerly. This is something important because we can support both invokedynamic which does the allocation as late as possible and GraalVM native image / AppCDS that may store the lambda instance directly in the image. You may think that we are talking about capture here so a lambda instance can not be reused but a captured value can be proved to be a constant by a static/runtime analysis. - Effectively final is a semantics that is used not only for lambdas but also for anonymous classes and recently for guarded patterns, for a pattern the "the point of capture" is not clearly defined. Is it when you want to evaluate the switch ? or when you evaluate the guard of the pattern ? So yes, we can try to tweak that rule but as Brian said, it just doesn???t seem worth the complexity. regards, R??mi ----- Original Message ----- > From: "Brian Goetz" > To: "raffaello giulietti" > Cc: "mark yagnatinsky" , "jdk-dev" > > Sent: Mercredi 6 Octobre 2021 17:12:18 > Subject: Re: crazy idea: weaken the effectively final restriction > A good way to think about this is to zoom out and realize that there > is a spectrum, with trade-offs. At one end of the spectrum is ???no > capture at all???, which is simple and easy to reason about, but ??? > unsatisfying. At the other end is that we close over variables rather > than values, which some languages do, which is defensible but leads to > surprising bugs. In the middle are options like ???capture final > variables only???, ???capture effectively final variables only???, etc. Your option is somewhat to the ???right??? of ???effectively final.??? > > What you???re saying is that we could capture things that are not > effectively final, if we can prove that all writes happen before the > capture point in the execution order. Java does flow analysis to > determine definite assignment, so such an enhanced flow analysis is imaginable. > > The way to think about this is whether the incremental expressiveness > warrants the incremental complexity. Yes, there are a small number of > cases where the more refined analysis would make a difference, but it???s really not that many. > On the other side, ???effectively final??? is an easier concept to explain > to developers; there is definitely incremental complexity in the user model here. > Is the trade worth it? My sense: meh. I don???t see a huge degree of > leverage here. > > A similar example where we chose a simpler rule than necessary was in `var`. > The intent is that local variable type inference is for > implementation, not for API. So you can use it for locals, but not > for, say, method returns, because that???s API, not just implementation. > Invariably, some slightly-too-clever person asks ???but, then why can???t > I use it for the return of a *private* method? That???s not API. AHA! Gotcha!??? > > The answer is of course simple; we could make the boundary of the > feature arbitrarily complex, but if the incremental complexity makes > it harder for people to reason about when they can use var and when > not, then we???re not necessarily helping by making it incrementally > more expressive. A simple rule that is easy to reason about is often > better than a fractally complex one that is slightly more powerful. > > So, to summarize, the idea isn???t crazy, it just doesn???t seem worth it in the > balance between complexity and expressiveness. I???d rather spend that > complexity budget on something with more leverage. > > Cheers, > -Brian > >> On Oct 6, 2021, at 8:51 AM, Raffaello Giulietti >> >> wrote: >> >> Hi, >> >> what if the variable is reassigned after the capture? >> >> Runnable f(String s) { >> Runnable r = () -> println(s); >> s = normalize(s); // perfectly useless assignment >> return r; >> } >> >> It would not be "effectively final from point of capture", so would >> this lead to a compilation error? >> >> >> Greetings >> Raffaello >> >> >> >> On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: >>> I'm not sure if this is the right list for this; if not I hope >>> someone can redirect me. >>> Java requires that local variables that are captured by a lambda >>> must be effectively final. >>> This restriction has the benefit that no one needs to worry about >>> annoying questions such as "what are the semantics of a data race on a local variable" >>> and other such horrors. >>> But this benefit can still be obtained by a weaker restriction. For >>> instance, consider this code, which currently does not compile: >>> Runnable f(String s) { >>> s = normalize(s); >>> return () -> println(s); // no can do: s is not >>> effectively final } However, this seems a bit silly because although >>> s is not final throughout the entire method, it's final where it >>> actually matters. >>> Namely, it is final from the point of capture to the end of the >>> method, and that's the only condition we need to avoid those annoying questions. >>> What do we gain by allowing the code above? Well, if we don't allow >>> it, how can the code above be fixed? We would have to introduce a new local variable. >>> That would actually be fine, except for another rule Java has, also >>> for a good >>> reason: one local variable name can NOT "shadow" another: all local >>> variables must have distinct names. >>> That is, we can do something like this: String s = "hello"; String s >>> = s.trim(); So we need to come up with a new name, and this has two costs: >>> First, coming up with good names is hard, and coming up with two >>> good names for what is basically the same thing is harder. >>> Second, suppose that when we first wrote the method, the variable >>> really was effectively final, and we needed to change it many months/years/decades later. >>> We now need to update the appropriate usages to the new name. This >>> tends to clutter line-based diffs, creating more work for reviewers >>> during pull requests, and also for code archeologists. >>> Third (did I say two?): we must spend mental bandwidth deciding how >>> to accomplish renaming things. In the example above we have at least two options: >>> Runnable f(String t) {// option 1: rename original >>> String s = normalize(t); >>> return () -> println(s); } Runnable f(String s) {// >>> option 2: keep original >>> String t = normalize(s); >>> return () -> println(t); } Deciding which option is >>> better might actually involve non-trivial tradeoffs. >>> Perhaps option 1 leads to a smaller diff, but option 2 leads to a >>> better parameter name for the method signature. >>> How important are good parameter names? What if it's a private >>> method with only one caller? Etc. >>> It seems that all this nuisance would go away almost for free if we >>> just weaken the restriction to "effectively final from point of capture". >>> The only possible downside I can see is that this would be a bit >>> more annoying to properly specify in the language spec. >>> So... opinions? Good idea? Bad idea? >>> 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: >>> https://clicktime.symantec.com/3Tkosemgs26WYCPSDAk2JqL6H2?u=www.barclays.com%2Femaildisclaimer. >>> For important disclosures, please see: >>> https://clicktime.symantec.com/3NjHsmWQRPyUoRU5NWeBWY66H2?u=www.barc >>> lays.com%2Fsalesandtradingdisclaimer regarding market commentary >>> from Barclays Sales and/or Trading, who are active market >>> participants; >>> https://clicktime.symantec.com/3DbDfoZBpbhGpNWA6fGnQRJ6H2?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/3WstoNBgC44ZMYiFozp7zBb6H2?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/3X9r5gJySmM7eDHfZpFzN5P6H2?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 forax at univ-mlv.fr Wed Oct 6 17:22:07 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 6 Oct 2021 19:22:07 +0200 (CEST) Subject: crazy idea: weaken the effectively final restriction In-Reply-To: References: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> <119650079.1802776.1633537437560.JavaMail.zimbra@u-pem.fr> Message-ID: <528458166.1814645.1633540927865.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "mark yagnatinsky" > To: "Remi Forax" , "Brian Goetz" > Cc: "raffaello giulietti" , "jdk-dev" > Sent: Mercredi 6 Octobre 2021 19:05:57 > Subject: RE: crazy idea: weaken the effectively final restriction > Re: guarded switch: I confess I have not been watching the latest developments > in pattern matching. (Enhanced instanceof is great though!) > If it turns out that effectively final makes sense there too, then I guess > that's another strike against my idea; might as well re-use the same concept > with lambdas too. > > Re: reading code too fast could result in overlooking an assignment: this has > recently become a "solved problem" for me, because IntelliJ by default > underlines local variables that are NOT effectively final. IDEs are marvelous but if an IDE is required to understand the semantics of the languages then something is very wrong. > > I do have one quibble with what you said though: my proposed semantics do NOT > behave differently in the two examples you listed. > In particular, neither example compiles, since there is an assignment to the > variable AFTER it was already captured. > Of course, your misunderstanding is also a strike against my idea: if I can't > even explain it to experts, what hope is there that mere mortals can keep this > straight? yes, the two lines should be swapped, for my defense, i typed that message at a swimming pool cheering for my daughter at the same time :) R?mi > > -----Original Message----- > From: Remi Forax > Sent: Wednesday, October 6, 2021 12:24 PM > To: Brian Goetz > Cc: raffaello giulietti ; Yagnatinsky, Mark : > Markets Pre Trade ; jdk-dev > > Subject: Re: crazy idea: weaken the effectively final restriction > > > CAUTION: This email originated from outside our organisation - forax at univ-mlv.fr > Do not click on links, open attachments, or respond unless you recognize the > sender and can validate the content is safe. > Hi Mark, > to complete Brian answer, > > - Reassigning a local variable without being inside a loop is usually seen as a > code smell, because when you read the code a little to fast you can miss the > second assignment thus believe that the code behave differently than what is > written. > > - The semantics you propose behave differently if the captured variable is > available outside the loop or not, so > Runnable r = () -> println(s); > s = normalize(s); > > will behave differently from > var s = > for(...) { > Runnable r = () -> println(s); > s = normalize(s); > } > ... s ... > > If you see the local variable in SSA form, the semantics depend if there is a > phi or not. > > - We also did not want to have a semantics depending on what you call "the point > of capture", i.e. we wanted to have a semantics that does not explicitly > specify when the lambda is created, this allows implementations/translation > strategies to create reusable lambda instance either lazily or eagerly. This is > something important because we can support both invokedynamic which does the > allocation as late as possible and GraalVM native image / AppCDS that may store > the lambda instance directly in the image. > > You may think that we are talking about capture here so a lambda instance can > not be reused but a captured value can be proved to be a constant by a > static/runtime analysis. > > - Effectively final is a semantics that is used not only for lambdas but also > for anonymous classes and recently for guarded patterns, for a pattern the "the > point of capture" is not clearly defined. Is it when you want to evaluate the > switch ? or when you evaluate the guard of the pattern ? > > > So yes, we can try to tweak that rule but as Brian said, it just doesn?t seem > worth the complexity. > > regards, > R?mi > > > ----- Original Message ----- >> From: "Brian Goetz" >> To: "raffaello giulietti" >> Cc: "mark yagnatinsky" , "jdk-dev" >> >> Sent: Mercredi 6 Octobre 2021 17:12:18 >> Subject: Re: crazy idea: weaken the effectively final restriction > >> A good way to think about this is to zoom out and realize that there >> is a spectrum, with trade-offs. At one end of the spectrum is ?no >> capture at all?, which is simple and easy to reason about, but ? >> unsatisfying. At the other end is that we close over variables rather >> than values, which some languages do, which is defensible but leads to >> surprising bugs. In the middle are options like ?capture final >> variables only?, ?capture effectively final variables only?, etc. Your option >> is somewhat to the ?right? of ?effectively final.? >> >> What you?re saying is that we could capture things that are not >> effectively final, if we can prove that all writes happen before the >> capture point in the execution order. Java does flow analysis to >> determine definite assignment, so such an enhanced flow analysis is imaginable. >> >> The way to think about this is whether the incremental expressiveness >> warrants the incremental complexity. Yes, there are a small number of >> cases where the more refined analysis would make a difference, but it?s really >> not that many. >> On the other side, ?effectively final? is an easier concept to explain >> to developers; there is definitely incremental complexity in the user model >> here. >> Is the trade worth it? My sense: meh. I don?t see a huge degree of >> leverage here. >> >> A similar example where we chose a simpler rule than necessary was in `var`. >> The intent is that local variable type inference is for >> implementation, not for API. So you can use it for locals, but not >> for, say, method returns, because that?s API, not just implementation. >> Invariably, some slightly-too-clever person asks ?but, then why can?t >> I use it for the return of a *private* method? That?s not API. AHA! Gotcha!? >> >> The answer is of course simple; we could make the boundary of the >> feature arbitrarily complex, but if the incremental complexity makes >> it harder for people to reason about when they can use var and when >> not, then we?re not necessarily helping by making it incrementally >> more expressive. A simple rule that is easy to reason about is often >> better than a fractally complex one that is slightly more powerful. >> >> So, to summarize, the idea isn?t crazy, it just doesn?t seem worth it in the >> balance between complexity and expressiveness. I?d rather spend that >> complexity budget on something with more leverage. >> >> Cheers, >> -Brian >> >>> On Oct 6, 2021, at 8:51 AM, Raffaello Giulietti >>> >>> wrote: >>> >>> Hi, >>> >>> what if the variable is reassigned after the capture? >>> >>> Runnable f(String s) { >>> Runnable r = () -> println(s); >>> s = normalize(s); // perfectly useless assignment >>> return r; >>> } >>> >>> It would not be "effectively final from point of capture", so would >>> this lead to a compilation error? >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: >>>> I'm not sure if this is the right list for this; if not I hope >>>> someone can redirect me. >>>> Java requires that local variables that are captured by a lambda >>>> must be effectively final. >>>> This restriction has the benefit that no one needs to worry about >>>> annoying questions such as "what are the semantics of a data race on a local >>>> variable" >>>> and other such horrors. >>>> But this benefit can still be obtained by a weaker restriction. For >>>> instance, consider this code, which currently does not compile: >>>> Runnable f(String s) { >>>> s = normalize(s); >>>> return () -> println(s); // no can do: s is not >>>> effectively final } However, this seems a bit silly because although >>>> s is not final throughout the entire method, it's final where it >>>> actually matters. >>>> Namely, it is final from the point of capture to the end of the >>>> method, and that's the only condition we need to avoid those annoying questions. >>>> What do we gain by allowing the code above? Well, if we don't allow >>>> it, how can the code above be fixed? We would have to introduce a new local >>>> variable. >>>> That would actually be fine, except for another rule Java has, also >>>> for a good >>>> reason: one local variable name can NOT "shadow" another: all local >>>> variables must have distinct names. >>>> That is, we can do something like this: String s = "hello"; String s >>>> = s.trim(); So we need to come up with a new name, and this has two costs: >>>> First, coming up with good names is hard, and coming up with two >>>> good names for what is basically the same thing is harder. >>>> Second, suppose that when we first wrote the method, the variable >>>> really was effectively final, and we needed to change it many >>>> months/years/decades later. >>>> We now need to update the appropriate usages to the new name. This >>>> tends to clutter line-based diffs, creating more work for reviewers >>>> during pull requests, and also for code archeologists. >>>> Third (did I say two?): we must spend mental bandwidth deciding how >>>> to accomplish renaming things. In the example above we have at least two >>>> options: >>>> Runnable f(String t) {// option 1: rename original >>>> String s = normalize(t); >>>> return () -> println(s); } Runnable f(String s) {// >>>> option 2: keep original >>>> String t = normalize(s); >>>> return () -> println(t); } Deciding which option is >>>> better might actually involve non-trivial tradeoffs. >>>> Perhaps option 1 leads to a smaller diff, but option 2 leads to a >>>> better parameter name for the method signature. >>>> How important are good parameter names? What if it's a private >>>> method with only one caller? Etc. >>>> It seems that all this nuisance would go away almost for free if we >>>> just weaken the restriction to "effectively final from point of capture". >>>> The only possible downside I can see is that this would be a bit >>>> more annoying to properly specify in the language spec. >>>> So... opinions? Good idea? Bad idea? >>>> 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: >>>> https://clicktime.symantec.com/3Tkosemgs26WYCPSDAk2JqL6H2?u=www.barclays.com%2Femaildisclaimer. >>>> For important disclosures, please see: >>>> https://clicktime.symantec.com/3NjHsmWQRPyUoRU5NWeBWY66H2?u=www.barc >>>> lays.com%2Fsalesandtradingdisclaimer regarding market commentary >>>> from Barclays Sales and/or Trading, who are active market >>>> participants; >>>> https://clicktime.symantec.com/3DbDfoZBpbhGpNWA6fGnQRJ6H2?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/3WstoNBgC44ZMYiFozp7zBb6H2?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/3X9r5gJySmM7eDHfZpFzN5P6H2?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 zjx001202 at gmail.com Wed Oct 6 17:24:44 2021 From: zjx001202 at gmail.com (Glavo) Date: Thu, 7 Oct 2021 01:24:44 +0800 Subject: Alternative to fatJar - modular solution? Message-ID: For a long time, unpacking and repackaging all dependencies into a file called fatJar was the first choice for single file distribution of Java programs. However, the compatibility of this solution with JPMS is very poor - it breaks up all the modules and works with classpath. I think many programmers may expect JDK to provide a native lightweight solution that bundles multiple modules into a single file. From users' enthusiasm for fatjar, we can see that they have a keen demand for such a format. jlink and jpackage cannot solve the problem that fatjar wants to solve. We now have the jimage file format, but it seems that it is only the internal format of JDK and is only used in the modules file. The lack of such a solution has caused us some trouble about whether to modularize. So I earnestly request JDK to add support for such a file format: 1. It can bundle multiple modules in one file (It may be based on jimage or other compression/archive format). 2. It should only bundle application dependencies without carrying JDK standard library or even complete JRE. 3. It should have a manifest file like the MANIFEST.MF for jar, allows we to add descriptions of entry points, Add-Opens, module path, and so on. 4. Allows simple execution, such as `java -jimage foo.jimage`. In this case, use the contents described in the above manifest file. 5. Associate this file format during JDK/JRE installation, and execute it in the above manner when double clicking it. 6. Like the ZIP (JAR) format, allow other content to be appended before its content. This makes it easy to attach a launcher (usually exe or bash) before its content. From mark.yagnatinsky at barclays.com Wed Oct 6 17:39:38 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Wed, 6 Oct 2021 17:39:38 +0000 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: <528458166.1814645.1633540927865.JavaMail.zimbra@u-pem.fr> References: <49dc9819-b9fe-4590-a398-610db21dbc82@gmail.com> <33A53613-9032-4D0B-A9FD-2D46BC481FF8@oracle.com> <119650079.1802776.1633537437560.JavaMail.zimbra@u-pem.fr> <528458166.1814645.1633540927865.JavaMail.zimbra@u-pem.fr> Message-ID: Oh yeah, if you swap the lines, then one compiles and the other doesn't. Not nice I admit. Not nice at all. -----Original Message----- From: forax at univ-mlv.fr Sent: Wednesday, October 6, 2021 1:22 PM To: Yagnatinsky, Mark : Markets Pre Trade Cc: Brian Goetz ; raffaello giulietti ; jdk-dev Subject: Re: crazy idea: weaken the effectively final restriction CAUTION: This email originated from outside our organisation - forax at univ-mlv.fr Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. ----- Original Message ----- > From: "mark yagnatinsky" > To: "Remi Forax" , "Brian Goetz" > > Cc: "raffaello giulietti" , "jdk-dev" > > Sent: Mercredi 6 Octobre 2021 19:05:57 > Subject: RE: crazy idea: weaken the effectively final restriction > Re: guarded switch: I confess I have not been watching the latest > developments in pattern matching. (Enhanced instanceof is great > though!) If it turns out that effectively final makes sense there too, > then I guess that's another strike against my idea; might as well > re-use the same concept with lambdas too. > > Re: reading code too fast could result in overlooking an assignment: > this has recently become a "solved problem" for me, because IntelliJ > by default underlines local variables that are NOT effectively final. IDEs are marvelous but if an IDE is required to understand the semantics of the languages then something is very wrong. > > I do have one quibble with what you said though: my proposed semantics > do NOT behave differently in the two examples you listed. > In particular, neither example compiles, since there is an assignment > to the variable AFTER it was already captured. > Of course, your misunderstanding is also a strike against my idea: if > I can't even explain it to experts, what hope is there that mere > mortals can keep this straight? yes, the two lines should be swapped, for my defense, i typed that message at a swimming pool cheering for my daughter at the same time :) R??mi > > -----Original Message----- > From: Remi Forax > Sent: Wednesday, October 6, 2021 12:24 PM > To: Brian Goetz > Cc: raffaello giulietti ; Yagnatinsky, Mark : > Markets Pre Trade ; jdk-dev > > Subject: Re: crazy idea: weaken the effectively final restriction > > > CAUTION: This email originated from outside our organisation - > forax at univ-mlv.fr Do not click on links, open attachments, or respond > unless you recognize the sender and can validate the content is safe. > Hi Mark, > to complete Brian answer, > > - Reassigning a local variable without being inside a loop is usually > seen as a code smell, because when you read the code a little to fast > you can miss the second assignment thus believe that the code behave > differently than what is written. > > - The semantics you propose behave differently if the captured > variable is available outside the loop or not, so Runnable r = () -> > println(s); s = normalize(s); > > will behave differently from > var s = > for(...) { > Runnable r = () -> println(s); > s = normalize(s); > } > ... s ... > > If you see the local variable in SSA form, the semantics depend if > there is a phi or not. > > - We also did not want to have a semantics depending on what you call > "the point of capture", i.e. we wanted to have a semantics that does > not explicitly specify when the lambda is created, this allows > implementations/translation strategies to create reusable lambda > instance either lazily or eagerly. This is something important because > we can support both invokedynamic which does the allocation as late as > possible and GraalVM native image / AppCDS that may store the lambda instance directly in the image. > > You may think that we are talking about capture here so a lambda > instance can not be reused but a captured value can be proved to be a > constant by a static/runtime analysis. > > - Effectively final is a semantics that is used not only for lambdas > but also for anonymous classes and recently for guarded patterns, for > a pattern the "the point of capture" is not clearly defined. Is it > when you want to evaluate the switch ? or when you evaluate the guard of the pattern ? > > > So yes, we can try to tweak that rule but as Brian said, it just > doesn???t seem worth the complexity. > > regards, > R??mi > > > ----- Original Message ----- >> From: "Brian Goetz" >> To: "raffaello giulietti" >> Cc: "mark yagnatinsky" , "jdk-dev" >> >> Sent: Mercredi 6 Octobre 2021 17:12:18 >> Subject: Re: crazy idea: weaken the effectively final restriction > >> A good way to think about this is to zoom out and realize that there >> is a spectrum, with trade-offs. At one end of the spectrum is ???no >> capture at all???, which is simple and easy to reason about, but ??? >> unsatisfying. At the other end is that we close over variables >> rather than values, which some languages do, which is defensible but >> leads to surprising bugs. In the middle are options like ???capture >> final variables only???, ???capture effectively final variables only???, >> etc. Your option is somewhat to the ???right??? of ???effectively final.??? >> >> What you???re saying is that we could capture things that are not >> effectively final, if we can prove that all writes happen before the >> capture point in the execution order. Java does flow analysis to >> determine definite assignment, so such an enhanced flow analysis is imaginable. >> >> The way to think about this is whether the incremental expressiveness >> warrants the incremental complexity. Yes, there are a small number >> of cases where the more refined analysis would make a difference, but >> it???s really not that many. >> On the other side, ???effectively final??? is an easier concept to >> explain to developers; there is definitely incremental complexity in >> the user model here. >> Is the trade worth it? My sense: meh. I don???t see a huge degree of >> leverage here. >> >> A similar example where we chose a simpler rule than necessary was in `var`. >> The intent is that local variable type inference is for >> implementation, not for API. So you can use it for locals, but not >> for, say, method returns, because that???s API, not just implementation. >> Invariably, some slightly-too-clever person asks ???but, then why can???t >> I use it for the return of a *private* method? That???s not API. AHA! Gotcha!??? >> >> The answer is of course simple; we could make the boundary of the >> feature arbitrarily complex, but if the incremental complexity makes >> it harder for people to reason about when they can use var and when >> not, then we???re not necessarily helping by making it incrementally >> more expressive. A simple rule that is easy to reason about is often >> better than a fractally complex one that is slightly more powerful. >> >> So, to summarize, the idea isn???t crazy, it just doesn???t seem worth it in the >> balance between complexity and expressiveness. I???d rather spend that >> complexity budget on something with more leverage. >> >> Cheers, >> -Brian >> >>> On Oct 6, 2021, at 8:51 AM, Raffaello Giulietti >>> >>> wrote: >>> >>> Hi, >>> >>> what if the variable is reassigned after the capture? >>> >>> Runnable f(String s) { >>> Runnable r = () -> println(s); >>> s = normalize(s); // perfectly useless assignment >>> return r; >>> } >>> >>> It would not be "effectively final from point of capture", so would >>> this lead to a compilation error? >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> On 2021-10-05 23:55, mark.yagnatinsky at barclays.com wrote: >>>> I'm not sure if this is the right list for this; if not I hope >>>> someone can redirect me. >>>> Java requires that local variables that are captured by a lambda >>>> must be effectively final. >>>> This restriction has the benefit that no one needs to worry about >>>> annoying questions such as "what are the semantics of a data race >>>> on a local variable" >>>> and other such horrors. >>>> But this benefit can still be obtained by a weaker restriction. >>>> For instance, consider this code, which currently does not compile: >>>> Runnable f(String s) { >>>> s = normalize(s); >>>> return () -> println(s); // no can do: s is not >>>> effectively final } However, this seems a bit silly because >>>> although s is not final throughout the entire method, it's final >>>> where it actually matters. >>>> Namely, it is final from the point of capture to the end of the >>>> method, and that's the only condition we need to avoid those annoying questions. >>>> What do we gain by allowing the code above? Well, if we don't >>>> allow it, how can the code above be fixed? We would have to >>>> introduce a new local variable. >>>> That would actually be fine, except for another rule Java has, also >>>> for a good >>>> reason: one local variable name can NOT "shadow" another: all local >>>> variables must have distinct names. >>>> That is, we can do something like this: String s = "hello"; String >>>> s = s.trim(); So we need to come up with a new name, and this has two costs: >>>> First, coming up with good names is hard, and coming up with two >>>> good names for what is basically the same thing is harder. >>>> Second, suppose that when we first wrote the method, the variable >>>> really was effectively final, and we needed to change it many >>>> months/years/decades later. >>>> We now need to update the appropriate usages to the new name. This >>>> tends to clutter line-based diffs, creating more work for reviewers >>>> during pull requests, and also for code archeologists. >>>> Third (did I say two?): we must spend mental bandwidth deciding how >>>> to accomplish renaming things. In the example above we have at >>>> least two >>>> options: >>>> Runnable f(String t) {// option 1: rename original >>>> String s = normalize(t); >>>> return () -> println(s); } Runnable f(String s) {// >>>> option 2: keep original >>>> String t = normalize(s); >>>> return () -> println(t); } Deciding which option is >>>> better might actually involve non-trivial tradeoffs. >>>> Perhaps option 1 leads to a smaller diff, but option 2 leads to a >>>> better parameter name for the method signature. >>>> How important are good parameter names? What if it's a private >>>> method with only one caller? Etc. >>>> It seems that all this nuisance would go away almost for free if we >>>> just weaken the restriction to "effectively final from point of capture". >>>> The only possible downside I can see is that this would be a bit >>>> more annoying to properly specify in the language spec. >>>> So... opinions? Good idea? Bad idea? >>>> 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: >>>> https://clicktime.symantec.com/3Tkosemgs26WYCPSDAk2JqL6H2?u=www.barclays.com%2Femaildisclaimer. >>>> For important disclosures, please see: >>>> https://clicktime.symantec.com/3NjHsmWQRPyUoRU5NWeBWY66H2?u=www.bar >>>> c lays.com%2Fsalesandtradingdisclaimer regarding market commentary >>>> from Barclays Sales and/or Trading, who are active market >>>> participants; >>>> https://clicktime.symantec.com/3DbDfoZBpbhGpNWA6fGnQRJ6H2?u=https%3 >>>> A >>>> %2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fbarclays-glob >>>> a 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/3WstoNBgC44ZMYiFozp7zBb6H2?u=https%3 >>>> A >>>> %2F%2Fwww.home.barclays%2Fdisclosures%2Fimportantapacdisclosures.ht >>>> ml for important disclosure. >>>> ___________________________________________________________________ >>>> _ >>>> ___________________________________________________________________ >>>> _ >>>> ___________________________________________________________________ >>>> _ _____________________ How we use personal information see our >>>> privacy notice >>>> https://clicktime.symantec.com/3X9r5gJySmM7eDHfZpFzN5P6H2?u=https%3 >>>> A >>>> %2F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fpersonalinfor >>>> m >>>> 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: > https://clicktime.symantec.com/3XT8ehetuoxtQEkcTUqpbob6H2?u=www.barclays.com%2Femaildisclaimer. > > For important disclosures, please see: > https://clicktime.symantec.com/392UfTRFtZDxbRCvcsExYgW6H2?u=www.barcla > ys.com%2Fsalesandtradingdisclaimer regarding market commentary from > Barclays Sales and/or Trading, who are active market participants; > https://clicktime.symantec.com/3N4wDWQ9Rcz7PkpigmKDo476H2?u=https%3A%2 > F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fbarclays-global-ma > rkets-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/3FRNh8HbmaCZ8L95qUTWcdc6H2?u=https%3A%2 > F%2Fwww.home.barclays%2Fdisclosures%2Fimportantapacdisclosures.html for important disclosure. > ______________________________________________________________________ > ______________________________________________________________________ > ______________________________________________________________________ > _______________ How we use personal information see our privacy > notice > https://clicktime.symantec.com/3TMNDCkH4qP9QMYmh4w4qV66H2?u=https%3A%2 > F%2Fwww.investmentbank.barclays.com%2Fdisclosures%2Fpersonalinformatio > nuse.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 john.r.rose at oracle.com Wed Oct 6 17:56:43 2021 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Oct 2021 17:56:43 +0000 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: References: Message-ID: On Oct 5, 2021, at 2:55 PM, mark.yagnatinsky at barclays.com wrote: Runnable f(String s) { s = normalize(s); return () -> println(s); // no can do: s is not effectively final } However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. As the experts have said, it is by design that the finality can be applied to the declaration *regardless of use*. This yields a language that is easier to reason about. (Yes, we did spend a lot of complexity budget elsewhere on lambdas as poly expressions, which nobody understands. To excuse that, that bit of magic happens during overload resolution, which nobody understood anyway.) Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. I have wanted this feature from time to time, but here?s another indication that it won?t pull its weight (of complexity): You can easily, even automatically (with IDE help) work around the limitation, simply by rebinding the variable you intend to capture. That?s the cost of using the simpler (more reusable) semantics of effectively final variables: Sometimes you need a second binding if the system cannot read your mind about how you are using the first binding. Runnable f(String s) { s = normalize(s); var s1 = s; return () -> println(s1); // fixed it for you! } Something?s gotta give: Either more mind-reading rules for bindings, or more bindings. This is arguably the more Java-like approach. Note also that the worst kind of mind-reading can happen when a maintainer reads your code. In that case, the maintainer will surely prefer the more transparent (though ceremonious) formulation with s1. Full disclosure: As a coder I grumble every time I have to write an ?s1?. But as a reader of code I don?t mind them so much. HTH From mark.yagnatinsky at barclays.com Wed Oct 6 18:08:34 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Wed, 6 Oct 2021 18:08:34 +0000 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: References: Message-ID: Thank you. I agree with most of that. Except maybe the part that this is a greater burden on writers than readers. Like you said, with IDE help, the burden on writers can be quite small. (Except that you still need to choose a name.) Agree that current way is more Java-like. I guess my proposal is a bit more Perl-like: ???please just do what I obviously mean???. But yeah, it is hard to explain, even at the semi-formal level of detail most tutorials go for, let alone at the textbook or language spec level. From: John Rose Sent: Wednesday, October 6, 2021 1:57 PM To: Yagnatinsky, Mark : Markets Pre Trade Cc: jdk-dev at openjdk.java.net Subject: Re: crazy idea: weaken the effectively final restriction CAUTION: This email originated from outside our organisation - john.r.rose at oracle.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. On Oct 5, 2021, at 2:55 PM, mark.yagnatinsky at barclays.com wrote: Runnable f(String s) { s = normalize(s); return () -> println(s); // no can do: s is not effectively final } However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. As the experts have said, it is by design that the finality can be applied to the declaration *regardless of use*. This yields a language that is easier to reason about. (Yes, we did spend a lot of complexity budget elsewhere on lambdas as poly expressions, which nobody understands. To excuse that, that bit of magic happens during overload resolution, which nobody understood anyway.) Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. I have wanted this feature from time to time, but here???s another indication that it won???t pull its weight (of complexity): You can easily, even automatically (with IDE help) work around the limitation, simply by rebinding the variable you intend to capture. That???s the cost of using the simpler (more reusable) semantics of effectively final variables: Sometimes you need a second binding if the system cannot read your mind about how you are using the first binding. Runnable f(String s) { s = normalize(s); var s1 = s; return () -> println(s1); // fixed it for you! } Something???s gotta give: Either more mind-reading rules for bindings, or more bindings. This is arguably the more Java-like approach. Note also that the worst kind of mind-reading can happen when a maintainer reads your code. In that case, the maintainer will surely prefer the more transparent (though ceremonious) formulation with s1. Full disclosure: As a coder I grumble every time I have to write an ???s1???. But as a reader of code I don???t mind them so much. HTH _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?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 Wed Oct 6 18:30:10 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 6 Oct 2021 11:30:10 -0700 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: References: Message-ID: <42C32DE8-0970-4403-967A-73039A6E3F3C@cbfiddle.com> I also grumble when I have to introduce an unnecessary variable to keep the compiler happy. But I don?t see any problem reading and understanding the original code. What problem do you think the maintainer will have with the original code? Only compiler writers need to understand the rules. For a programmer, if it compiles, it is OK; if it doesn?t, grumble and add a variable. The ?Java way? may not be the best way. Alan > On Oct 6, 2021, at 10:56 AM, John Rose wrote: > > On Oct 5, 2021, at 2:55 PM, mark.yagnatinsky at barclays.com wrote: > > Runnable f(String s) { > s = normalize(s); > return () -> println(s); // no can do: s is not effectively final > } > > However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. > > As the experts have said, it is by design that the > finality can be applied to the declaration *regardless > of use*. This yields a language that is easier to > reason about. (Yes, we did spend a lot of complexity > budget elsewhere on lambdas as poly expressions, > which nobody understands. To excuse that, that > bit of magic happens during overload resolution, > which nobody understood anyway.) > > Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. > > I have wanted this feature from time to time, but > here?s another indication that it won?t pull its > weight (of complexity): You can easily, even > automatically (with IDE help) work around the > limitation, simply by rebinding the variable > you intend to capture. That?s the cost of > using the simpler (more reusable) semantics > of effectively final variables: Sometimes > you need a second binding if the system > cannot read your mind about how you > are using the first binding. > > Runnable f(String s) { > s = normalize(s); > var s1 = s; > return () -> println(s1); // fixed it for you! > } > > Something?s gotta give: Either more mind-reading > rules for bindings, or more bindings. This is arguably > the more Java-like approach. > > Note also that the worst kind of mind-reading can > happen when a maintainer reads your code. In that > case, the maintainer will surely prefer the more > transparent (though ceremonious) formulation > with s1. > > Full disclosure: As a coder I grumble every time > I have to write an ?s1?. But as a reader of code I > don?t mind them so much. > > HTH > > From john.r.rose at oracle.com Wed Oct 6 19:04:58 2021 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Oct 2021 19:04:58 +0000 Subject: [External] : Re: crazy idea: weaken the effectively final restriction In-Reply-To: <42C32DE8-0970-4403-967A-73039A6E3F3C@cbfiddle.com> References: <42C32DE8-0970-4403-967A-73039A6E3F3C@cbfiddle.com> Message-ID: <4D5B9338-56B9-4AA8-90F9-7A4E793AAA24@oracle.com> On Oct 6, 2021, at 11:30 AM, Alan Snyder > wrote: But I don?t see any problem reading and understanding the original code. You prove my point. Problems you (as maintainer) don?t see can be the hardest kind of problem to deal with, right? What problem do you think the maintainer will have with the original code? I?m referring to problem already mentioned on this thread, notably confusion among multiple values of a variable which is multiply assigned. From zjx001202 at gmail.com Wed Oct 6 19:45:17 2021 From: zjx001202 at gmail.com (Glavo) Date: Thu, 7 Oct 2021 03:45:17 +0800 Subject: Alternative to fatJar - modular solution? In-Reply-To: <59371073-F718-4A60-BD94-08A22D1CAACF@gmail.com> References: <59371073-F718-4A60-BD94-08A22D1CAACF@gmail.com> Message-ID: > > I know this doesn't remotely satisfy all your requirements, but are you > aware you can jpackage an app *without* bundling a JRE? > Ah, this is what I missed, but it won't solve any of my problems, otherwise I have implemented a similar function by myself. Sebastian Stenzel ?2021?10?7??? ??2:06??? > Interesting topic and I'm keen to know what is the answer to the general > problem of modular fat or shaded jars. > > I know this doesn't remotely satisfy all your requirements, but are you > aware you can jpackage an app *without* bundling a JRE? > > > Am 06.10.2021 um 19:25 schrieb Glavo : > > > > ?For a long time, unpacking and repackaging all dependencies into a file > > called fatJar was the first choice for single file distribution of Java > > programs. However, the compatibility of this solution with JPMS is very > > poor - it breaks up all the modules and works with classpath. > > > > I think many programmers may expect JDK to provide a native lightweight > > solution that bundles multiple modules into a single file. From users' > > enthusiasm for fatjar, we can see that they have a keen demand for such > > a format. jlink and jpackage cannot solve the problem that fatjar wants > > to solve. We now have the jimage file format, but it seems that it is > > only the internal format of JDK and is only used in the modules file. > > > > The lack of such a solution has caused us some trouble about whether to > > modularize. So I earnestly request JDK to add support for such a file > > format: > > > > 1. It can bundle multiple modules in one file (It may be based on jimage > > or other compression/archive format). > > > > 2. It should only bundle application dependencies without carrying JDK > > standard library or even complete JRE. > > > > 3. It should have a manifest file like the MANIFEST.MF for jar, > > allows we to add descriptions of entry points, Add-Opens, module path, > > and so on. > > > > 4. Allows simple execution, such as `java -jimage foo.jimage`. In > > this case, use the contents described in the above manifest file. > > > > 5. Associate this file format during JDK/JRE installation, and > > execute it in the above manner when double clicking it. > > > > 6. Like the ZIP (JAR) format, allow other content to be appended > > before its content. This makes it easy to attach a launcher (usually > > exe or bash) before its content. > From szegedia at gmail.com Wed Oct 6 19:45:32 2021 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 6 Oct 2021 21:45:32 +0200 Subject: crazy idea: weaken the effectively final restriction In-Reply-To: References: Message-ID: <28ABA287-17A7-4B3F-92AF-03B1F6A16AEB@gmail.com> My personal code style is so far on the other end of this spectrum that I wouldn?t ever want this feature. I notoriously single-assign all my local variables to the point of spelling out ?final var? just to make sure the compiler catches me if I deviate from it. Very rarely I?ll settle for reassignment (mostly in a loop that accumulates a value. I could do away with most of those too if I could tell the Java compiler to transform tail recursive methods into loops.) Ultimately, I?d never reassign a method parameter. Yes, I declare those as ?final? too; my Java code is full of ?final? keywords but what can I do when immutability ain?t the default? I?m not trying to look down from a high horse and champion this as the ultimate style everyone should adopt, but it works for me. Gives me a peace of mind when my variables don?t vary much. It sure is easier for me to read and reason about my code when I revisit it after some time if I don?t have to worry about a variable changing further down the method once I understood the first and only expression that computes its value. Attila. > On 2021. Oct 6., at 19:56, John Rose wrote: > > On Oct 5, 2021, at 2:55 PM, mark.yagnatinsky at barclays.com wrote: > > Runnable f(String s) { > s = normalize(s); > return () -> println(s); // no can do: s is not effectively final > } > > However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters. > > As the experts have said, it is by design that the > finality can be applied to the declaration *regardless > of use*. This yields a language that is easier to > reason about. (Yes, we did spend a lot of complexity > budget elsewhere on lambdas as poly expressions, > which nobody understands. To excuse that, that > bit of magic happens during overload resolution, > which nobody understood anyway.) > > Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions. > > I have wanted this feature from time to time, but > here?s another indication that it won?t pull its > weight (of complexity): You can easily, even > automatically (with IDE help) work around the > limitation, simply by rebinding the variable > you intend to capture. That?s the cost of > using the simpler (more reusable) semantics > of effectively final variables: Sometimes > you need a second binding if the system > cannot read your mind about how you > are using the first binding. > > Runnable f(String s) { > s = normalize(s); > var s1 = s; > return () -> println(s1); // fixed it for you! > } > > Something?s gotta give: Either more mind-reading > rules for bindings, or more bindings. This is arguably > the more Java-like approach. > > Note also that the worst kind of mind-reading can > happen when a maintainer reads your code. In that > case, the maintainer will surely prefer the more > transparent (though ceremonious) formulation > with s1. > > Full disclosure: As a coder I grumble every time > I have to write an ?s1?. But as a reader of code I > don?t mind them so much. > > HTH > > From javalists at cbfiddle.com Wed Oct 6 21:50:46 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 6 Oct 2021 14:50:46 -0700 Subject: [External] : Re: crazy idea: weaken the effectively final restriction In-Reply-To: <4D5B9338-56B9-4AA8-90F9-7A4E793AAA24@oracle.com> References: <42C32DE8-0970-4403-967A-73039A6E3F3C@cbfiddle.com> <4D5B9338-56B9-4AA8-90F9-7A4E793AAA24@oracle.com> Message-ID: <93CB99A3-BE86-435A-A948-1492E496A756@cbfiddle.com> I was referring to the the example in *your* message, which does not have multiple assignments. Runnable f(String s) { s = normalize(s); return () -> println(s); // no can do: s is not effectively final } Seems pretty clear to me. > On Oct 6, 2021, at 12:04 PM, John Rose wrote: > > > On Oct 6, 2021, at 11:30 AM, Alan Snyder > wrote: > > But I don?t see any problem reading and understanding the original code. > > You prove my point. Problems you (as maintainer) don?t see can > be the hardest kind of problem to deal with, right? > > What problem do you think the maintainer will have with the original code? > > I?m referring to problem already mentioned on this thread, > notably confusion among multiple values of a variable > which is multiply assigned. > From ioi.lam at oracle.com Thu Oct 7 00:36:42 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 6 Oct 2021 17:36:42 -0700 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <59371073-F718-4A60-BD94-08A22D1CAACF@gmail.com> Message-ID: <372fce38-48cd-461a-4e70-58345119ff6d@oracle.com> On 10/6/21 12:45 PM, Glavo wrote: >> I know this doesn't remotely satisfy all your requirements, but are you >> aware you can jpackage an app *without* bundling a JRE? >> > Ah, this is what I missed, but it won't solve any of my problems, otherwise > I have implemented a similar function by myself. Doesn't jpackage always bundle a Java runtime with the app? From the docs: https://docs.oracle.com/en/java/javase/17/jpackage/packaging-overview.html "To eliminate the need for users to install a Java runtime, one is packaged with your applications. The packaging tool generates a runtime image based on the packages or modules that your application needs. If no Java runtime image is passed to the packaging tool, then jpackage uses the jlink tool to create a runtime for the application." Thanks - Ioi > Sebastian Stenzel ?2021?10?7??? ??2:06??? > >> Interesting topic and I'm keen to know what is the answer to the general >> problem of modular fat or shaded jars. >> >> I know this doesn't remotely satisfy all your requirements, but are you >> aware you can jpackage an app *without* bundling a JRE? >> >>> Am 06.10.2021 um 19:25 schrieb Glavo : >>> >>> ?For a long time, unpacking and repackaging all dependencies into a file >>> called fatJar was the first choice for single file distribution of Java >>> programs. However, the compatibility of this solution with JPMS is very >>> poor - it breaks up all the modules and works with classpath. >>> >>> I think many programmers may expect JDK to provide a native lightweight >>> solution that bundles multiple modules into a single file. From users' >>> enthusiasm for fatjar, we can see that they have a keen demand for such >>> a format. jlink and jpackage cannot solve the problem that fatjar wants >>> to solve. We now have the jimage file format, but it seems that it is >>> only the internal format of JDK and is only used in the modules file. >>> >>> The lack of such a solution has caused us some trouble about whether to >>> modularize. So I earnestly request JDK to add support for such a file >>> format: >>> >>> 1. It can bundle multiple modules in one file (It may be based on jimage >>> or other compression/archive format). >>> >>> 2. It should only bundle application dependencies without carrying JDK >>> standard library or even complete JRE. >>> >>> 3. It should have a manifest file like the MANIFEST.MF for jar, >>> allows we to add descriptions of entry points, Add-Opens, module path, >>> and so on. >>> >>> 4. Allows simple execution, such as `java -jimage foo.jimage`. In >>> this case, use the contents described in the above manifest file. >>> >>> 5. Associate this file format during JDK/JRE installation, and >>> execute it in the above manner when double clicking it. >>> >>> 6. Like the ZIP (JAR) format, allow other content to be appended >>> before its content. This makes it easy to attach a launcher (usually >>> exe or bash) before its content. From zjx001202 at gmail.com Thu Oct 7 01:38:12 2021 From: zjx001202 at gmail.com (Glavo) Date: Thu, 7 Oct 2021 09:38:12 +0800 Subject: Alternative to fatJar - modular solution? In-Reply-To: <372fce38-48cd-461a-4e70-58345119ff6d@oracle.com> References: <59371073-F718-4A60-BD94-08A22D1CAACF@gmail.com> <372fce38-48cd-461a-4e70-58345119ff6d@oracle.com> Message-ID: Emmm... My words caused some misunderstanding. I should say that jpackage is good, but without it, we can easily achieve the same function in other ways, so it doesn't cause real trouble. What really causes trouble and needs to be solved by fatjar is a different problem. It is difficult for me to achieve close results by third-party means (e.g., let's bundle program jars in lancher jar, decompress them to a temporary location at runtime and load them dynamically. But compared with this scheme, I would rather give up JPMS and go back to fatJar). Ioi Lam ?2021?10?7??? ??8:36??? > > > On 10/6/21 12:45 PM, Glavo wrote: > >> I know this doesn't remotely satisfy all your requirements, but are you > >> aware you can jpackage an app *without* bundling a JRE? > >> > > Ah, this is what I missed, but it won't solve any of my problems, > otherwise > > I have implemented a similar function by myself. > > Doesn't jpackage always bundle a Java runtime with the app? From the docs: > > https://docs.oracle.com/en/java/javase/17/jpackage/packaging-overview.html > > "To eliminate the need for users to install a Java runtime, one is > packaged with your applications. The packaging tool generates a runtime > image based on the packages or modules that your application needs. > > If no Java runtime image is passed to the packaging tool, then jpackage > uses the jlink tool to create a runtime for the application." > > Thanks > - Ioi > > > Sebastian Stenzel ?2021?10?7??? ??2:06??? > > > >> Interesting topic and I'm keen to know what is the answer to the general > >> problem of modular fat or shaded jars. > >> > >> I know this doesn't remotely satisfy all your requirements, but are you > >> aware you can jpackage an app *without* bundling a JRE? > >> > >>> Am 06.10.2021 um 19:25 schrieb Glavo : > >>> > >>> ?For a long time, unpacking and repackaging all dependencies into a > file > >>> called fatJar was the first choice for single file distribution of Java > >>> programs. However, the compatibility of this solution with JPMS is very > >>> poor - it breaks up all the modules and works with classpath. > >>> > >>> I think many programmers may expect JDK to provide a native lightweight > >>> solution that bundles multiple modules into a single file. From users' > >>> enthusiasm for fatjar, we can see that they have a keen demand for such > >>> a format. jlink and jpackage cannot solve the problem that fatjar wants > >>> to solve. We now have the jimage file format, but it seems that it is > >>> only the internal format of JDK and is only used in the modules file. > >>> > >>> The lack of such a solution has caused us some trouble about whether to > >>> modularize. So I earnestly request JDK to add support for such a file > >>> format: > >>> > >>> 1. It can bundle multiple modules in one file (It may be based on > jimage > >>> or other compression/archive format). > >>> > >>> 2. It should only bundle application dependencies without carrying > JDK > >>> standard library or even complete JRE. > >>> > >>> 3. It should have a manifest file like the MANIFEST.MF for jar, > >>> allows we to add descriptions of entry points, Add-Opens, module > path, > >>> and so on. > >>> > >>> 4. Allows simple execution, such as `java -jimage foo.jimage`. In > >>> this case, use the contents described in the above manifest file. > >>> > >>> 5. Associate this file format during JDK/JRE installation, and > >>> execute it in the above manner when double clicking it. > >>> > >>> 6. Like the ZIP (JAR) format, allow other content to be appended > >>> before its content. This makes it easy to attach a launcher (usually > >>> exe or bash) before its content. > > From goetz.lindenmaier at sap.com Thu Oct 7 07:00:32 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Oct 2021 07:00:32 +0000 Subject: Result: New JDK Reviewer: Ralf Schmelter Message-ID: Voting for Ralf Schmelter [1] is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Goetz Lindenmaier [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/006071.html http://mail.openjdk.java.net/pipermail/jdk-dev/2021-October/006101.html From mgridinas at gmail.com Thu Oct 7 07:35:33 2021 From: mgridinas at gmail.com (Mantas Gridinas) Date: Thu, 7 Oct 2021 10:35:33 +0300 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <59371073-F718-4A60-BD94-08A22D1CAACF@gmail.com> <372fce38-48cd-461a-4e70-58345119ff6d@oracle.com> Message-ID: I am a tad bit confused. How come packaging everything into a regular zip file and extracting it during deployment is not feasable solution? If anything, you retain ability to do partial updates to your deployments. Such approach also removes the need for special classloader that is capable of loading nested jars. This in turn makes packaging and runtime much simpler too, as you dont need to repackage the runtime jar. On Thu, Oct 7, 2021, 06:57 Glavo wrote: > Emmm... My words caused some misunderstanding. I should say that jpackage > is good, but without it, we can easily achieve the same function in > other ways, so it doesn't cause real trouble. What really causes trouble > and needs to be solved by fatjar is a different problem. It is difficult > for me to achieve close results by third-party means (e.g., let's bundle > program jars in lancher jar, decompress them to a temporary location > at runtime and load them dynamically. But compared with this scheme, > I would rather give up JPMS and go back to fatJar). > > Ioi Lam ?2021?10?7??? ??8:36??? > > > > > > > On 10/6/21 12:45 PM, Glavo wrote: > > >> I know this doesn't remotely satisfy all your requirements, but are > you > > >> aware you can jpackage an app *without* bundling a JRE? > > >> > > > Ah, this is what I missed, but it won't solve any of my problems, > > otherwise > > > I have implemented a similar function by myself. > > > > Doesn't jpackage always bundle a Java runtime with the app? From the > docs: > > > > > https://docs.oracle.com/en/java/javase/17/jpackage/packaging-overview.html > > > > "To eliminate the need for users to install a Java runtime, one is > > packaged with your applications. The packaging tool generates a runtime > > image based on the packages or modules that your application needs. > > > > If no Java runtime image is passed to the packaging tool, then jpackage > > uses the jlink tool to create a runtime for the application." > > > > Thanks > > - Ioi > > > > > Sebastian Stenzel ?2021?10?7??? > ??2:06??? > > > > > >> Interesting topic and I'm keen to know what is the answer to the > general > > >> problem of modular fat or shaded jars. > > >> > > >> I know this doesn't remotely satisfy all your requirements, but are > you > > >> aware you can jpackage an app *without* bundling a JRE? > > >> > > >>> Am 06.10.2021 um 19:25 schrieb Glavo : > > >>> > > >>> ?For a long time, unpacking and repackaging all dependencies into a > > file > > >>> called fatJar was the first choice for single file distribution of > Java > > >>> programs. However, the compatibility of this solution with JPMS is > very > > >>> poor - it breaks up all the modules and works with classpath. > > >>> > > >>> I think many programmers may expect JDK to provide a native > lightweight > > >>> solution that bundles multiple modules into a single file. From > users' > > >>> enthusiasm for fatjar, we can see that they have a keen demand for > such > > >>> a format. jlink and jpackage cannot solve the problem that fatjar > wants > > >>> to solve. We now have the jimage file format, but it seems that it is > > >>> only the internal format of JDK and is only used in the modules file. > > >>> > > >>> The lack of such a solution has caused us some trouble about whether > to > > >>> modularize. So I earnestly request JDK to add support for such a file > > >>> format: > > >>> > > >>> 1. It can bundle multiple modules in one file (It may be based on > > jimage > > >>> or other compression/archive format). > > >>> > > >>> 2. It should only bundle application dependencies without carrying > > JDK > > >>> standard library or even complete JRE. > > >>> > > >>> 3. It should have a manifest file like the MANIFEST.MF for jar, > > >>> allows we to add descriptions of entry points, Add-Opens, module > > path, > > >>> and so on. > > >>> > > >>> 4. Allows simple execution, such as `java -jimage foo.jimage`. In > > >>> this case, use the contents described in the above manifest file. > > >>> > > >>> 5. Associate this file format during JDK/JRE installation, and > > >>> execute it in the above manner when double clicking it. > > >>> > > >>> 6. Like the ZIP (JAR) format, allow other content to be appended > > >>> before its content. This makes it easy to attach a launcher > (usually > > >>> exe or bash) before its content. > > > > > From zjx001202 at gmail.com Thu Oct 7 08:04:17 2021 From: zjx001202 at gmail.com (Glavo) Date: Thu, 7 Oct 2021 16:04:17 +0800 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <59371073-F718-4A60-BD94-08A22D1CAACF@gmail.com> <372fce38-48cd-461a-4e70-58345119ff6d@oracle.com> Message-ID: Of course, this is feasible and will not introduce many new problems like jlink. It's just not that convenient. It just introduces some additional deployment steps, which is not so convenient. I believe that it is very attractive to only distribute and deploy a single file, which is proved by the popularity of fatJar and Golang. Mantas Gridinas ?2021?10?7??? ??3:35??? > I am a tad bit confused. How come packaging everything into a regular zip > file and extracting it during deployment is not feasable solution? If > anything, you retain ability to do partial updates to your deployments. > Such approach also removes the need for special classloader that is capable > of loading nested jars. This in turn makes packaging and runtime much > simpler too, as you dont need to repackage the runtime jar. > > On Thu, Oct 7, 2021, 06:57 Glavo wrote: > >> Emmm... My words caused some misunderstanding. I should say that jpackage >> is good, but without it, we can easily achieve the same function in >> other ways, so it doesn't cause real trouble. What really causes trouble >> and needs to be solved by fatjar is a different problem. It is difficult >> for me to achieve close results by third-party means (e.g., let's bundle >> program jars in lancher jar, decompress them to a temporary location >> at runtime and load them dynamically. But compared with this scheme, >> I would rather give up JPMS and go back to fatJar). >> >> Ioi Lam ?2021?10?7??? ??8:36??? >> >> > >> > >> > On 10/6/21 12:45 PM, Glavo wrote: >> > >> I know this doesn't remotely satisfy all your requirements, but are >> you >> > >> aware you can jpackage an app *without* bundling a JRE? >> > >> >> > > Ah, this is what I missed, but it won't solve any of my problems, >> > otherwise >> > > I have implemented a similar function by myself. >> > >> > Doesn't jpackage always bundle a Java runtime with the app? From the >> docs: >> > >> > >> https://docs.oracle.com/en/java/javase/17/jpackage/packaging-overview.html >> > >> > "To eliminate the need for users to install a Java runtime, one is >> > packaged with your applications. The packaging tool generates a runtime >> > image based on the packages or modules that your application needs. >> > >> > If no Java runtime image is passed to the packaging tool, then jpackage >> > uses the jlink tool to create a runtime for the application." >> > >> > Thanks >> > - Ioi >> > >> > > Sebastian Stenzel ?2021?10?7??? >> ??2:06??? >> > > >> > >> Interesting topic and I'm keen to know what is the answer to the >> general >> > >> problem of modular fat or shaded jars. >> > >> >> > >> I know this doesn't remotely satisfy all your requirements, but are >> you >> > >> aware you can jpackage an app *without* bundling a JRE? >> > >> >> > >>> Am 06.10.2021 um 19:25 schrieb Glavo : >> > >>> >> > >>> ?For a long time, unpacking and repackaging all dependencies into a >> > file >> > >>> called fatJar was the first choice for single file distribution of >> Java >> > >>> programs. However, the compatibility of this solution with JPMS is >> very >> > >>> poor - it breaks up all the modules and works with classpath. >> > >>> >> > >>> I think many programmers may expect JDK to provide a native >> lightweight >> > >>> solution that bundles multiple modules into a single file. From >> users' >> > >>> enthusiasm for fatjar, we can see that they have a keen demand for >> such >> > >>> a format. jlink and jpackage cannot solve the problem that fatjar >> wants >> > >>> to solve. We now have the jimage file format, but it seems that it >> is >> > >>> only the internal format of JDK and is only used in the modules >> file. >> > >>> >> > >>> The lack of such a solution has caused us some trouble about >> whether to >> > >>> modularize. So I earnestly request JDK to add support for such a >> file >> > >>> format: >> > >>> >> > >>> 1. It can bundle multiple modules in one file (It may be based on >> > jimage >> > >>> or other compression/archive format). >> > >>> >> > >>> 2. It should only bundle application dependencies without carrying >> > JDK >> > >>> standard library or even complete JRE. >> > >>> >> > >>> 3. It should have a manifest file like the MANIFEST.MF for jar, >> > >>> allows we to add descriptions of entry points, Add-Opens, module >> > path, >> > >>> and so on. >> > >>> >> > >>> 4. Allows simple execution, such as `java -jimage foo.jimage`. In >> > >>> this case, use the contents described in the above manifest file. >> > >>> >> > >>> 5. Associate this file format during JDK/JRE installation, and >> > >>> execute it in the above manner when double clicking it. >> > >>> >> > >>> 6. Like the ZIP (JAR) format, allow other content to be appended >> > >>> before its content. This makes it easy to attach a launcher >> (usually >> > >>> exe or bash) before its content. >> > >> > >> > From xenoamess at gmail.com Thu Oct 7 19:33:36 2021 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 8 Oct 2021 03:33:36 +0800 Subject: Just wonder why there be inconsistency in InputStream and Reader, in function skip(long) Message-ID: Hi. For input number who < 0, InputStream#skip returns 0 and Reader throws an IllegalArgumentException. That just... be really weird if come to think of it From xenoamess at gmail.com Thu Oct 7 21:26:07 2021 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 8 Oct 2021 05:26:07 +0800 Subject: ideas about making static shared pool for skip buffers for InputStream and Reader Message-ID: Hi. I just wonder, if it worthy to create static shared pools for skip buffers for InputStream and Reader, instead of create one for each instance. I do think it worthy a try. pr at https://github.com/openjdk/jdk/pull/5855 What the next step should I do? From brian.burkhalter at oracle.com Thu Oct 7 21:37:48 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Oct 2021 21:37:48 +0000 Subject: ideas about making static shared pool for skip buffers for InputStream and Reader In-Reply-To: References: Message-ID: Re-directing to the appropriate mailing list, core-libs-dev; please exclude jdk-dev from any reply. How can they be shared when they are different data types, viz., byte vs. char? On Oct 7, 2021, at 2:26 PM, Xeno Amess > wrote: I just wonder, if it worthy to create static shared pools for skip buffers for InputStream and Reader, instead of create one for each instance. I do think it worthy a try. pr at https://github.com/openjdk/jdk/pull/5855 What the next step should I do? From mark.reinhold at oracle.com Thu Oct 7 22:07:02 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 7 Oct 2021 15:07:02 -0700 (PDT) Subject: JEP proposed to target JDK 18: 408: Simple Web Server Message-ID: <20211007220702.5F9264C384E@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 408: Simple Web Server https://openjdk.java.net/jeps/408 Summary: Provide a command-line tool to start a minimal web server that serves static files in the current directory. This low-threshold utility will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts. 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, 14 October, 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 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From ebresie at gmail.com Sat Oct 9 14:12:38 2021 From: ebresie at gmail.com (Eric Bresie) Date: Sat, 9 Oct 2021 09:12:38 -0500 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: <20211007220702.5F9264C384E@eggemoggin.niobe.net> References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> Message-ID: Given more emphasis on security in recent years, would https support be worth including as well? Or is this intentionally out of scope and adds unwanted complexity to the ?Simple Web Server? intent of the JEP? Does this overlap/depend on changes to recent JEP-321 ( https://openjdk.java.net/jeps/321 ) changes? As an aspiring JDK committee/reviewer, I know I don?t yet meet the ?Committers or Reviewer? critters but was hoping the input is still valid. If this is not the place to provide such input I would welcome know where to do so.. Eric Bresie On Thu, Oct 7, 2021 at 5:07 PM wrote: > The following JEP is proposed to target JDK 18: > > 408: Simple Web Server > https://openjdk.java.net/jeps/408 > > Summary: Provide a command-line tool to start a minimal web server > that serves static files in the current directory. This low-threshold > utility will be useful for prototyping, ad-hoc coding, and testing > purposes, particularly in educational contexts. > > 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, 14 October, 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 18. > > - Mark > > > [1] https://openjdk.java.net/census#jdk > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > -- Eric Bresie ebresie at gmail.com From simone.bordet at gmail.com Sat Oct 9 16:32:08 2021 From: simone.bordet at gmail.com (Simone Bordet) Date: Sat, 9 Oct 2021 18:32:08 +0200 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: <20211007220702.5F9264C384E@eggemoggin.niobe.net> References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> Message-ID: Hi, On Fri, Oct 8, 2021 at 12:07 AM wrote: > > The following JEP is proposed to target JDK 18: > > 408: Simple Web Server > https://openjdk.java.net/jeps/408 > > Summary: Provide a command-line tool to start a minimal web server > that serves static files in the current directory. This low-threshold > utility will be useful for prototyping, ad-hoc coding, and testing > purposes, particularly in educational contexts. As a Jetty Project co-lead, and having witnessed: * the number of perils in URL parsing * the number of perils in URL decoding * the number of perils in URL to file-system Path conversions, which are file-system/os dependent * the number of perils in file-system aliasing, also file-system/os dependent I really wonder if this JEP is going to be an OpenJDK liability, also considering that there are quite a few (and many open source) choices out there that allow setting up a file server in less than 10 lines of code, and that are already widely used in testing and educational contexts, and battle tested over the course of decades. I am not sure what this JEP proposes is really needed, as there are plenty of other options outside the JDK. For example, using Jetty in code: Server server = new Server(8080); ResourceHandler resourceHandler = new ResourceHandler(); resourceHandler.setBaseResource(new PathResource("/var/www")); server.setHandler(resourceHandler); server.start(); I'm pretty sure someone has wrapped the Jetty APIs into builder-style APIs and the above can probably be folded in a single line. I'm sure Tomcat, Undertow, etc. provide equally small snippets to do the same. Also worth consideration is that penetration testing companies and tools (and not only) will target what's proposed by this JEP with special persistence, and each vulnerability discovered will be an OpenJDK security issue that will need to be handled for the current Java version and backported to all previous Java versions that apply. For example, even the venerable Apache HTTPD has disclosed a path traversal vulnerability just a few days ago, to say that no matter the amount of experience and battle testing a vulnerability is always behind the corner. FWIW -- I'm an OpenJDK author, but not a committer -- my suggestion is to dismiss this JEP and leave it to existing, decades old, proven, feature-packed, open source projects out there. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From liangchenblue at gmail.com Sun Oct 10 23:39:21 2021 From: liangchenblue at gmail.com (-) Date: Sun, 10 Oct 2021 18:39:21 -0500 Subject: Optimizing InputStream.skip(long) Message-ID: On GitHub, xenoamess sent a pull request [1] that optimizes skipBuffer array used by InputStream.skip by caching one for each InputStream instance (static ones are unsafe per bug 7000600) like the java.io.Reader class does (the reader one is behind a lock, while this one is possibly concurrent). Pros: Input streams that inherit the default skip logic can reduce buffer array creation by reusing the compatible old array when the skip method is called multiple times. Cons: This adds a field to InputStream; the array cannot be GC'd until the InputStream is GC'd. (But it has a length limit and the impact is less) Additional Info: Most JDK InputStream implementations already overrides this method to offer a more efficient implementation as suggested in the Javadocs. Reader.skip(long) calls Reader.read(char[], int, int), and this change doesn't affect the Reader class. I wonder if this idea is worthy of a JDK issue so this patch may eventually be accepted. Feel free to post any feedback, too! [1]: https://git.openjdk.java.net/jdk/pull/5872 From david.holmes at oracle.com Sun Oct 10 23:52:16 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Oct 2021 09:52:16 +1000 Subject: Optimizing InputStream.skip(long) In-Reply-To: References: Message-ID: <66692be7-c0dd-48a5-0c4f-31cf625cdb5c@oracle.com> Hi, This belongs on core-libs-dev at openjdk.java.net Thanks, David On 11/10/2021 9:39 am, - wrote: > On GitHub, xenoamess sent a pull request [1] that optimizes skipBuffer > array used by InputStream.skip by caching one for each InputStream > instance (static ones are unsafe per bug 7000600) like the > java.io.Reader class does (the reader one is behind a lock, while this > one is possibly concurrent). > > Pros: Input streams that inherit the default skip logic can reduce > buffer array creation by reusing the compatible old array when the > skip method is called multiple times. > > Cons: This adds a field to InputStream; the array cannot be GC'd until > the InputStream is GC'd. (But it has a length limit and the impact is > less) > > Additional Info: Most JDK InputStream implementations already > overrides this method to offer a more efficient implementation as > suggested in the Javadocs. Reader.skip(long) calls Reader.read(char[], > int, int), and this change doesn't affect the Reader class. > > I wonder if this idea is worthy of a JDK issue so this patch may > eventually be accepted. Feel free to post any feedback, too! > > [1]: https://git.openjdk.java.net/jdk/pull/5872 > From julia.boes at oracle.com Mon Oct 11 12:47:57 2021 From: julia.boes at oracle.com (Julia Boes) Date: Mon, 11 Oct 2021 13:47:57 +0100 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> Message-ID: <0aa23d6a-dc86-e743-8ce0-035ca8211889@oracle.com> Hi Eric, On 09/10/2021 15:12, Eric Bresie wrote: > Given more emphasis on security in recent years, would https support be > worth including as well? Or is this intentionally out of scope and adds > unwanted complexity to the ?Simple Web Server? intent of the JEP? That?s right, HTTPS support is out of the scope of this JEP. If secure communication with SSL is required, the Simple Web Server is not the right choice, and we don?t want to give the impression that it is. This being said, the com.sun.net.httpserver package offers support for HTTPS. We?re planning to publish an article on how to set up a HTTPS server that uses the Simple Web Server?s file handler. > Does this overlap/depend on changes to recent JEP-321 ( > https://openjdk.java.net/jeps/321 ) changes? This JEP does not depend on JEP 321: HttpClient. The functionality is server-side only and based on the web server implementation in the com.sun.net.httpserver package, which has been included in the JDK since 2006. The package is officially supported, and all we do is extend it with APIs to simplify server creation and enhance request handling. > As an aspiring JDK committee/reviewer, I know I don?t yet meet the > ?Committers or Reviewer? critters but was hoping the input is still valid. > If this is not the place to provide such input I would welcome know where > to do so.. Input is always welcome, and the mailing lists are exactly the right place to share it. Regards, Julia From zjx001202 at gmail.com Mon Oct 11 14:09:34 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 11 Oct 2021 22:09:34 +0800 Subject: Alternative to fatJar - modular solution? In-Reply-To: <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> References: <197339BF-C018-4DA3-B3A7-0CBCBE9B983C@cox.net> <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> Message-ID: I think this is a great prototype. Based on it, I think such requirements can also be realized by enhancing jar in these aspects: 1. Nested jar file system (The ujar file system seems unnecessary. I never understand why jar file systems cannot be nested.) 2. Enhanced manifest to support Module-Path entries. 3. Allow Class-Path and Module-Path in manifest to include jars embedded in jars. (I saw a lot of complaints about it a long time ago. The absence of this function seems to be the main factor in the emergence of farjar) Ioi Lam ?2021?10?9??? ??9:21??? > As a proof of concept, I wrote a quick-and-dirty demo that can load > Jigsaw modules from a Uber-JAR file: > > https://github.com/iklam/tools/tree/main/jigsaw/uberjar > > Glavo, would something like this fit your needs? > > I think something like this could be done outside the JDK (in frameworks > like SpringBoot) or inside the JDK (as some sort of extension to "java > -jar", for example). > > As the demo shows, we already have the core API support to enable this. > I would encourage other member of the Java community to experiment with > it and see if we should proceed further in this direction. > > Thanks > - Ioi > > On 10/7/21 9:31 PM, Ioi Lam wrote: > > I am wondering if there are 3rd party solutions that support loading > > Jigsaw modules from uber jars. The JDK should have all the APIs to > > support such a solution. > > > > E.g., I looked at SpringBoot, which has uber jar support, but it > > doesn't seem to support modules ("java.lang.module" doesn't appear in > > any of the source files). > > > > Thanks > > - Ioi > > > > On 10/7/21 6:43 AM, Gregg Wonderly wrote: > >> The URL class loader is the easiest way to solve conditional > >> loading. In Jini, now Apache River, we?ve long used this mechanism > >> to ?get? the implementation of all interfaces that a remote client > >> application needed to talk to a particular server (versioning makes > >> this necessary and powerfully easy as a solution). But the security > >> manager didn?t seem useful as of late and the removal of the security > >> manager support for managing per jar security is a bit problematic > >> for this kind of mobile code use in Java. Yet, this is the primary > >> way that javascript works in the web browser as the mobile code > >> interface to remote services. It really feels like Oracle and the > >> Java team have no interest in what the desktop environment represents? > >> > >> Gregg Wonderly > >> > >>> On Oct 7, 2021, at 7:41 AM, Glavo wrote: > >>> > >>>> *Bandwidth optimization and rare machines.* This is interesting > >>>> because > >>>> it's a requirement that feels like it may be more common in China than > >>>> elsewhere. I'd be keen to learn more about your bandwidth constraints, > >>>> unless this is more of a theoretical concern? > >>> > >>> Ah, in fact, in Chinese mainland, server bandwidth is a very real > >>> problem. In China, many websites such as GitHub and cloudflare cannot > >>> provide services normally. The cost of civil broadband is low, but > >>> commercial bandwidth is more expensive, which costs several times or > >>> even more than ten times higher than other parts of the world. > >>> Our average income level also lags behind that of developed countries, > >>> so we will pay more attention to the cost of bandwidth. > >>> > >>> Mike Hearn ?2021?10?7??? ??7:31??? > >>> > >>>> Thanks for your insightful reply, Glavo. Here are some thoughts. I > >>>> should > >>>> note that I don't work for Oracle or on OpenJDK, in case that wasn't > >>>> already clear. > >>>> > >>>> *Forum.* Although it's logical that you ended up on this list, > >>>> realistically the JPMS is "done" and not being worked on since Java > >>>> 9. Any > >>>> solutions or improvements have to come from the user community so > >>>> it may > >>>> make more sense to have this discussion on Reddit, or some other > >>>> Java forum. > >>>> > >>>> *Alternative approach. *Given this constraint, it can make sense to > >>>> think > >>>> wider or bigger than just updating previous approaches. Would your > >>>> needs be > >>>> met or even met better by a re-imagining of Web Start, but one > >>>> suitable for > >>>> servers and the CLI? For example: > >>>> > >>>> $ alias glavos="jrun glavos-cool-app.com" > >>>> $ glavos --flag --another-flag > >>>> > >>>> Here an imaginary "jrun" command (re)downloads an app and stores it > >>>> to a > >>>> local cache, perhaps downloading an appropriate JVM/jlinked image > >>>> alongside > >>>> it if none is available already locally. It's given a URL but in a > >>>> convenient form for typing, e.g. with assumed protocols and paths > >>>> if only a > >>>> domain name is specified. The tool would occasionally check for > >>>> updates and > >>>> run from the cache the rest of the time. This doesn't make apps into a > >>>> single file but it tackles other problems you mention having to > >>>> roll your > >>>> own solutions for, like writing your own update checker and asking > >>>> users to > >>>> download the right file. Unlike tools like apt-get or brew there > >>>> would be > >>>> no notion of adding a repository beforehand, so for CLI / server > >>>> apps, it > >>>> retains its usability. > >>>> > >>>> For desktop apps a simple .jrun file association could be used to > >>>> do the > >>>> same thing. > >>>> > >>>> For building Docker images you could have: > >>>> > >>>> $ jrun --cache-only glavos-cool-app.com > >>>> > >>>> which would populate a cache during the docker build, but not run the > >>>> program itself. > >>>> > >>>> I've often wished for such a tool. At one point I built one that > >>>> did Maven > >>>> resolution, but it for GUI apps. Although my new venture is about > >>>> self-updating desktop/server app packages, I've been planning an > >>>> extension > >>>> in this direction later because once you can distribute a generic > >>>> runtime > >>>> as a self-updating "app" you can easily bring back the JRE model > >>>> for those > >>>> who want it. > >>>> > >>>> *Jimage.* In your first mail you proposed a new kind of fat-jar > >>>> based on > >>>> the jimage format the modules file uses. JImage isn't a documented > >>>> format, > >>>> or rather, it's documented only in the source code, but it has quite a > >>>> clever design. The upside is that it's highly optimized. The > >>>> downsides are: > >>>> > >>>> 1. Write only. ZIPs have some basic support for editing but jimage > >>>> doesn't. This is a pain for things like config files, where you may > >>>> want to > >>>> make specialized versions of an app by adjusting the internal > >>>> files. It can > >>>> be easily fixed using a classloader that checks local disk for > >>>> resources > >>>> first. > >>>> > >>>> 2. No built-in support for native code libraries. There was a related > >>>> discussion of this problem a week or so ago on this list. Of > >>>> course, JARs > >>>> have the same problem. > >>>> > >>>> 3. No support for multiple versions of the same JAR in the same > >>>> file, even > >>>> though the core JPMS *can* support this via the > >>>> defineModulesWithManyLoaders API, and even though this would be a very > >>>> useful thing to support. Fat JARs have the same problem so this is > >>>> not a > >>>> downside compared to the status quo. > >>>> > >>>> 4. The format is deliberately undocumented so it can be changed in > >>>> future > >>>> JVM versions. Thus using it would actually mean cloning it, and/or > >>>> rewriting parts of the code because otherwise the GPL2 might kick in. > >>>> > >>>> Overall, the downsides are not that big! The worst is the need to > >>>> clone > >>>> the format to avoid depending on JVM internals. On the other hand, > >>>> ZIPs > >>>> work well enough and don't require writing any new code except a > >>>> little > >>>> stub entry point that uses custom classloaders. > >>>> > >>>> *Bandwidth optimization and rare machines.* This is interesting > >>>> because > >>>> it's a requirement that feels like it may be more common in China than > >>>> elsewhere. I'd be keen to learn more about your bandwidth constraints, > >>>> unless this is more of a theoretical concern? > >>>> > >>>> You mention you actually have users on LoongArch64 for example. > >>>> Indeed, > >>>> the chances that non-Chinese developers will produce jlinked images > >>>> for > >>>> this CPU any time soon is very low. > >>>> > >>>> *Product potential.* As mentioned, I'm setting up a new venture > >>>> that is > >>>> starting with app distribution, and particularly distribution for > >>>> the JVM > >>>> world. JPackage is good as far as it goes, but it doesn't solve all > >>>> the > >>>> problems developers face. Given your list of target machines it > >>>> feels like > >>>> you're probably a commercial organization with a wide customer > >>>> base. If > >>>> you're in the market for better approaches please send an email to > >>>> mike at hydraulic.software and maybe your needs can influence our > product > >>>> direction. > >>>> > >>>> > >>>> > > > > From julia.boes at oracle.com Mon Oct 11 17:18:06 2021 From: julia.boes at oracle.com (Julia Boes) Date: Mon, 11 Oct 2021 18:18:06 +0100 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> Message-ID: <8caa3408-4586-6efd-b421-786e697bf948@oracle.com> Hi Simone, On 09/10/2021 17:32, Simone Bordet wrote:> As a Jetty Project co-lead, and having witnessed: > > * the number of perils in URL parsing > * the number of perils in URL decoding > * the number of perils in URL to file-system Path conversions, which > are file-system/os dependent > * the number of perils in file-system aliasing, also file-system/os dependent > > I really wonder if this JEP is going to be an OpenJDK liability, also Let me start by saying that this JEP does not add new functionality, but rather exposes existing implementations. The Simple Web Server is located in jdk.httpserver/com.sun.net.httpserver, a package that has been there since 2006 (JDK 1.6) and that is officially supported. The original motivation for the jdk.httpserver module was to support web services callbacks, which can indeed get dangerous quite quickly. The Simple Web Server however is very different, it only serves static files and only supports the idempotent GET and HEAD requests. As such it is much easier to secure. With regard to the security considerations, let me summarize the central points from the JEP, which in their sum help us be confident about this enhancement. *Server Configuration* When started on the command-line, the server binds to the loopback address by default. This prevents accidental exposure on the network; any other bind address has to be explicitly specified, e.g. all interfaces. The server uses a single thread, the HttpServer's default configuration. This limits the risk of the server compromising machine performance. For similar reasons, the server uses a backlog value of 50, the maximum number of incoming TCP connections the system will queue internally. *Request Handling* The server only supports the idempotent GET and HEAD requests. Any other requests receive a 501 - Not Implemented or a 405 - Not Allowed response. *File System Access* Server creation only succeeds if the root directory to be served (root path) passes all of the following checks: Path.isAbsolute, Files.exists, Files.isDirectory, Files.isReadable. Upon server creation, a file server handler is created with the root path, and is mapped to the root URI path "/" in the form of a context. This is the single context of the server, so all requests are mapped to the file server handler. When a request is received, the handler retrieves a file system path (resource path) by resolving the request path against the root path, ensuring that neither the root path nor the context path are escaped. The server strictly serves files from the root directory and its subdirectories only, no other files from the file system are served. If a resource path is retrieved, the following checks are applied to itself and all its segments: Files.exists, !Files.isHidden, !Files.isSymlink, Files.isReadable. A 404 - Not Found response is sent if any of the above checks fail. The requested resource is either a file, in which case its content is served, or a directory, in which case the files in the directory are listed in HTML. In the case of listing of directory content, a file is not included if it is either hidden or a symlink. *Sanitize Request URI* The request URI that is reflected back in the response body is sanitized so that special characters are replaced with their HTML encoded equivalents. *Developer Perspective* The server is a plain HTTP server (no authentication, access control, encryption with SSL). The API doc underlines that the server is "intended for testing, development and debugging purposes only". With this, developers are informed about the minimal scope of the server. When running the server on the command line, information is printed to about the server and each exchange. This allows the developer to check that server configuration and file system access are as expected. Upon start up, information about the server is printed to the command line (in particular the local address and the absolute path of the directory served). Additionally information is printed for each exchange (in particular the absolute path of the requested resource). > I am not sure what this JEP proposes is really needed, as there are > plenty of other options outside the JDK. It is true that plenty of alternatives exist, I mention some of them in the JEP. While that can be an argument for not "reinventing the wheel", it can also be an argument for the opposite: The variety of existing choices is a testament to the recognized need and usefulness of such a tool. If such a static server is commonly used in a variety of scenarios, why should it not be in the JDK, particularly if it's merely an extension of the existing server implementation in com.sun.net.httpserver? One of the goals of this JEP is to "Reduce developer activation energy and make the JDK more approachable". We think a low-theshold tool that provides tried-and-tested minimal functionality is a good way to achieve this. It can appeal to a new generation of developers and keeps Java attractive. Cheers, Julia From Alan.Bateman at oracle.com Mon Oct 11 18:57:47 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Oct 2021 19:57:47 +0100 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <197339BF-C018-4DA3-B3A7-0CBCBE9B983C@cox.net> <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> Message-ID: On 11/10/2021 15:09, Glavo wrote: > I think this is a great prototype. Based on it, I think such requirements > can also be realized by enhancing jar in these aspects: > > 1. Nested jar file system (The ujar file system seems unnecessary. > I never understand why jar file systems cannot be nested.) This was fixed in JDK 12, are you seeing issues with release recent releases? If so then would it be possible to submit a bug with a test case or bring the issue to core-libs-dev? -Alan From simone.bordet at gmail.com Mon Oct 11 20:10:30 2021 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 11 Oct 2021 22:10:30 +0200 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: <8caa3408-4586-6efd-b421-786e697bf948@oracle.com> References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> <8caa3408-4586-6efd-b421-786e697bf948@oracle.com> Message-ID: Hi, On Mon, Oct 11, 2021 at 7:18 PM Julia Boes wrote: > > Hi Simone, > > On 09/10/2021 17:32, Simone Bordet wrote:> As a Jetty Project co-lead, and > having witnessed: > > > > * the number of perils in URL parsing > > * the number of perils in URL decoding > > * the number of perils in URL to file-system Path conversions, which > > are file-system/os dependent > > * the number of perils in file-system aliasing, also file-system/os dependent > > > > I really wonder if this JEP is going to be an OpenJDK liability, also > > Let me start by saying that this JEP does not add new functionality, but rather > exposes existing implementations. The Simple Web Server is located in > jdk.httpserver/com.sun.net.httpserver, a package that has been there since 2006 > (JDK 1.6) and that is officially supported. Sorry, but considering that truly official java.* APIs are being removed, I fail to understand how classes in jdk.* or com.sun.* are "officially supported", when it was made very clear that developers should not depend on those because they can change without any advice, etc. Can you clarify what you mean here? > The original motivation for the jdk.httpserver module was to support web > services callbacks, which can indeed get dangerous quite quickly. The Simple Web > Server however is very different, it only serves static files and only supports > the idempotent GET and HEAD requests. As such it is much easier to secure. Now I am really confused. If the original motivation was to support web services callbacks, but now it doesn't, then it seems that serving files is a use case that nobody asked for? I may be too old to understand what "developer activation energy" means -- but to me feels too weak to justify this JEP. > With regard to the security considerations, let me summarize the central points > from the JEP, which in their sum help us be confident about this enhancement. [snip] Your list is fine, but my experience and that of other major server developers was the same: we were confident, but got CVEs. > It is true that plenty of alternatives exist, I mention some of them in the JEP. > While that can be an argument for not "reinventing the wheel", it can also be an > argument for the opposite: The variety of existing choices is a testament to the > recognized need and usefulness of such a tool. If such a static server is > commonly used in a variety of scenarios, why should it not be in the JDK, > particularly if it's merely an extension of the existing server implementation > in com.sun.net.httpserver? Sorry, but the list of tools for which "The variety of existing choices is a testament to the recognized need and usefulness of such a tool" and therefore needs to be included in OpenJDK is quite long, and I can think of many that would be more relevant than this JEP. Anyway, I said mine about this JEP :) Thanks! Regards -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From mchung at openjdk.java.net Mon Oct 11 21:04:15 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 11 Oct 2021 21:04:15 GMT Subject: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Message-ID: Classes compiled prior to the nestmate support will generate `REF_invokeSpecial` if the implementation method is a private instance method. Since a lambda proxy class is a hidden class, a nestmate of the host class, it can invoke the private implementation method but it has to use `REF_invokeVirtual` or `REF_invokeInterface`. In order to support the old classes running on the new runtime, LMF implementation adjusts the reference kind from `REF_invokeSpecial` to `REF_invokeVirtual/REF_invokeInterface`. This PR fixes the check properly to ensure the adjustment is only made if the implementation method is private method in the host class. ------------- Commit messages: - JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Changes: https://git.openjdk.java.net/jdk/pull/5901/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5901&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274848 Stats: 379 lines in 4 files changed: 378 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5901/head:pull/5901 PR: https://git.openjdk.java.net/jdk/pull/5901 From joe.darcy at oracle.com Mon Oct 11 21:54:33 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 11 Oct 2021 14:54:33 -0700 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> <8caa3408-4586-6efd-b421-786e697bf948@oracle.com> Message-ID: On 10/11/2021 1:10 PM, Simone Bordet wrote: > Hi, > > On Mon, Oct 11, 2021 at 7:18 PM Julia Boes wrote: >> Hi Simone, >> >> On 09/10/2021 17:32, Simone Bordet wrote:> As a Jetty Project co-lead, and >> having witnessed: >>> * the number of perils in URL parsing >>> * the number of perils in URL decoding >>> * the number of perils in URL to file-system Path conversions, which >>> are file-system/os dependent >>> * the number of perils in file-system aliasing, also file-system/os dependent >>> >>> I really wonder if this JEP is going to be an OpenJDK liability, also >> Let me start by saying that this JEP does not add new functionality, but rather >> exposes existing implementations. The Simple Web Server is located in >> jdk.httpserver/com.sun.net.httpserver, a package that has been there since 2006 >> (JDK 1.6) and that is officially supported. > Sorry, but considering that truly official java.* APIs are being > removed, I fail to understand how classes in jdk.* or com.sun.* are > "officially supported", when it was made very clear that developers > should not depend on those because they can change without any advice, > etc. > Can you clarify what you mean here? There are distinct evolution and compatibility policies for several categories of APIs associated with the JDK, several broad buckets: * Java SE APIs (approximately public and protected elements of the java.* modules, which include the java.* and javax.* packages): These APIs have a strong compatibility policy, but can be removed from the platform after going through the deprecation-for-removal process. * official JDK APIs (approximately public and protected elements of the jdk.* modules): similar compatibility policy to Java SE APIs, but there is more leeway on the timing and size of changes. For example, it is more likely to have API changes to JDK APIs in an update release (rather than a feature release) compared to changes in Java SE APIs (since changing a Java SE in a maintenance release would require a maintenance review of the platform specification). One example of an official JDK API is the tree api, com.sun.source.tree, which is in part a supplement of sorts to the javax.lang.model Java SE API. * unofficial / accidental JDK APIs: Going back multiple decades (https://web.archive.org/web/19980215011039/http://java.sun.com/products/jdk/faq/faq-sun-packages.html) and continuing to today (https://www.oracle.com/java/technologies/faq-sun-packages.html), the sun.* APIs are *not* part of the JDK's official API and should *not* be relied on by code outside of the JDK. In early years, this policy lacked enforcement mechanisms. Start in JDK 6, javac started warning about uses of such classes and modularity in JDK 9 added further mechanisms. Selected portions of sun.*, in particular sun.misc.Unsafe, do get special handling. To emphasize, APIs in a sun.* namespace are regarded differently than either APIs in a com.sun.* or jdk.* namespace or a java.* or java.* namespace. Changes to Java SE APIs and JDK API go through the CSR process (https://wiki.openjdk.java.net/display/csr) which provides compatibility and specification review. HTH, -Joe From mark.reinhold at oracle.com Mon Oct 11 22:41:15 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Oct 2021 15:41:15 -0700 (PDT) Subject: New candidate JEP: 419: Foreign Function & Memory API (Second Incubator) Message-ID: <20211011224115.BCE714C3D63@eggemoggin.niobe.net> https://openjdk.java.net/jeps/419 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 zjx001202 at gmail.com Mon Oct 11 22:48:42 2021 From: zjx001202 at gmail.com (Glavo) Date: Tue, 12 Oct 2021 06:48:42 +0800 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <197339BF-C018-4DA3-B3A7-0CBCBE9B983C@cox.net> <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> Message-ID: I mistakenly believe that the implementation of the filesystem corresponds exactly to the URL. The problem I really want to express is that JDK does not support URLs of nested jar file systems. It seems that this problem still exists in JDK 17. To make matters worse, we can use toUri() to convert the path of the file in the nested jar into a URI, but this URI is neither accepted by Paths.get (java.lang.IllegalArgumentException? URI does not contain path info ex. jar:file:/c:/foo.zip!/BAR) nor converted into a URL (java.net.MalformedURLException: Nested JAR URLs are not supported). Is this a bug or an expected behavior? Alan Bateman ?2021?10?12??? ??2:58??? > On 11/10/2021 15:09, Glavo wrote: > > I think this is a great prototype. Based on it, I think such requirements > > can also be realized by enhancing jar in these aspects: > > > > 1. Nested jar file system (The ujar file system seems unnecessary. > > I never understand why jar file systems cannot be nested.) > > This was fixed in JDK 12, are you seeing issues with release recent > releases? If so then would it be possible to submit a bug with a test > case or bring the issue to core-libs-dev? > > -Alan > From jianglizhou at google.com Mon Oct 11 23:34:11 2021 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 11 Oct 2021 16:34:11 -0700 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <59371073-F718-4A60-BD94-08A22D1CAACF@gmail.com> <372fce38-48cd-461a-4e70-58345119ff6d@oracle.com> Message-ID: Hi, This discussion caught my eye as we are currently experimenting in this area as well. Packaging everything into a JAR file, including the JDK for easier deployment is a fine idea. In fact, we are also trying to move towards this direction. Runtime extraction is a less ideal solution for production (with diskless environments) based on valuable experiences from Python that utilized this strategy in the past. There were many edge cases that needed to be addressed and made the solution less attractive. Following are a couple example issues that passed to me from Python experts: - Need to manage tmpfs space - Extraction conflicts I recently prototyped a solution for self-contained JAR executable with execution in place. It requires the support for dlopen at non-zero file offset. However, that feature (https://sourceware.org/bugzilla/show_bug.cgi?id=11767) is unlikely going to land in glibc. best, Jiangli On Thu, Oct 7, 2021 at 12:36 AM Mantas Gridinas wrote: > > I am a tad bit confused. How come packaging everything into a regular zip > file and extracting it during deployment is not feasable solution? If > anything, you retain ability to do partial updates to your deployments. > Such approach also removes the need for special classloader that is capable > of loading nested jars. This in turn makes packaging and runtime much > simpler too, as you dont need to repackage the runtime jar. > > On Thu, Oct 7, 2021, 06:57 Glavo wrote: > > > Emmm... My words caused some misunderstanding. I should say that jpackage > > is good, but without it, we can easily achieve the same function in > > other ways, so it doesn't cause real trouble. What really causes trouble > > and needs to be solved by fatjar is a different problem. It is difficult > > for me to achieve close results by third-party means (e.g., let's bundle > > program jars in lancher jar, decompress them to a temporary location > > at runtime and load them dynamically. But compared with this scheme, > > I would rather give up JPMS and go back to fatJar). > > > > Ioi Lam ?2021?10?7??? ??8:36??? > > > > > > > > > > > On 10/6/21 12:45 PM, Glavo wrote: > > > >> I know this doesn't remotely satisfy all your requirements, but are > > you > > > >> aware you can jpackage an app *without* bundling a JRE? > > > >> > > > > Ah, this is what I missed, but it won't solve any of my problems, > > > otherwise > > > > I have implemented a similar function by myself. > > > > > > Doesn't jpackage always bundle a Java runtime with the app? From the > > docs: > > > > > > > > https://docs.oracle.com/en/java/javase/17/jpackage/packaging-overview.html > > > > > > "To eliminate the need for users to install a Java runtime, one is > > > packaged with your applications. The packaging tool generates a runtime > > > image based on the packages or modules that your application needs. > > > > > > If no Java runtime image is passed to the packaging tool, then jpackage > > > uses the jlink tool to create a runtime for the application." > > > > > > Thanks > > > - Ioi > > > > > > > Sebastian Stenzel ?2021?10?7??? > > ??2:06??? > > > > > > > >> Interesting topic and I'm keen to know what is the answer to the > > general > > > >> problem of modular fat or shaded jars. > > > >> > > > >> I know this doesn't remotely satisfy all your requirements, but are > > you > > > >> aware you can jpackage an app *without* bundling a JRE? > > > >> > > > >>> Am 06.10.2021 um 19:25 schrieb Glavo : > > > >>> > > > >>> ?For a long time, unpacking and repackaging all dependencies into a > > > file > > > >>> called fatJar was the first choice for single file distribution of > > Java > > > >>> programs. However, the compatibility of this solution with JPMS is > > very > > > >>> poor - it breaks up all the modules and works with classpath. > > > >>> > > > >>> I think many programmers may expect JDK to provide a native > > lightweight > > > >>> solution that bundles multiple modules into a single file. From > > users' > > > >>> enthusiasm for fatjar, we can see that they have a keen demand for > > such > > > >>> a format. jlink and jpackage cannot solve the problem that fatjar > > wants > > > >>> to solve. We now have the jimage file format, but it seems that it is > > > >>> only the internal format of JDK and is only used in the modules file. > > > >>> > > > >>> The lack of such a solution has caused us some trouble about whether > > to > > > >>> modularize. So I earnestly request JDK to add support for such a file > > > >>> format: > > > >>> > > > >>> 1. It can bundle multiple modules in one file (It may be based on > > > jimage > > > >>> or other compression/archive format). > > > >>> > > > >>> 2. It should only bundle application dependencies without carrying > > > JDK > > > >>> standard library or even complete JRE. > > > >>> > > > >>> 3. It should have a manifest file like the MANIFEST.MF for jar, > > > >>> allows we to add descriptions of entry points, Add-Opens, module > > > path, > > > >>> and so on. > > > >>> > > > >>> 4. Allows simple execution, such as `java -jimage foo.jimage`. In > > > >>> this case, use the contents described in the above manifest file. > > > >>> > > > >>> 5. Associate this file format during JDK/JRE installation, and > > > >>> execute it in the above manner when double clicking it. > > > >>> > > > >>> 6. Like the ZIP (JAR) format, allow other content to be appended > > > >>> before its content. This makes it easy to attach a launcher > > (usually > > > >>> exe or bash) before its content. > > > > > > > > From Alan.Bateman at oracle.com Tue Oct 12 07:52:01 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Oct 2021 08:52:01 +0100 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> <8caa3408-4586-6efd-b421-786e697bf948@oracle.com> Message-ID: On 11/10/2021 22:54, Joe Darcy wrote: > > There are distinct evolution and compatibility policies for several > categories of APIs associated with the JDK, several broad buckets: > > * Java SE APIs (approximately public and protected elements of the > java.* modules, which include the java.* and javax.* packages): These > APIs have a strong compatibility policy, but can be removed from the > platform after going through the deprecation-for-removal process. > > * official JDK APIs (approximately public and protected elements of > the jdk.* modules): similar compatibility policy to Java SE APIs, but > there is more leeway on the timing and size of changes. For example, > it is more likely to have API changes to JDK APIs in an update release > (rather than a feature release) compared to changes in Java SE APIs > (since changing a Java SE in a maintenance release would require a > maintenance review of the platform specification). Just to add to Joe's mail is that moving to a modular platform in Java 9 has eliminated a lot of the historical confusion over JDK-specific APIs. In particular, the javadoc, e.g. Java 17 [1], you can quickly see the JDK-specific modules and the API packages that they export. In the case of the HTTP server the module is jdk.httpserver. The API packages that is exported have been documented/supported APIs since JDK 6. One of those API packages is the SPI for developing alternative implementation and it look like Jetty has had an implementation of that SPI for several releases so I suspect Jetty has been compiling against this API for a long time. -Alan [1] https://docs.oracle.com/en/java/javase/17/docs/api/index.html From zjx001202 at gmail.com Tue Oct 12 08:14:45 2021 From: zjx001202 at gmail.com (Glavo) Date: Tue, 12 Oct 2021 16:14:45 +0800 Subject: Allow new language features on older version targets? Message-ID: Starting from Java 9, Java began to iterate rapidly and introduced many new features, which made Java more expressive and modern. However, upgrading Java is always difficult and painful. It needs to go through a series of cumbersome upgrade and migration processes. In these steps, the transplantation at the syntax level is often easy, because Java maintains good compatibility. However, due to subtle changes in the behavior of the JVM and the standard library, it is relatively difficult to upgrade the version of the java runtime. At the same time, for client applications, upgrading the development environment is much easier than upgrading the Java version of the deployment environment (e.g., only Java 8 is currently available on MIPS64el). For various reasons, a large number of users stay on the old java version. According to the statistical report of JetBrains, 71% of users still regularly use Java 8.0 in 2021. The most affected people are the developers of libraries. In order to make the library more widely used, most library authors always need to make their libraries use the lowest java version possible. This makes it difficult for them to enjoy the expression upgrade brought by Java update. This pain is not necessary. Although some language features of Java require the cooperation of JVM and standard library, e.g. Record, but this is not necessary for more features. At present, we can specify the source version and target version respectively, but we can't make the source version higher than the target version. I think this artificial additional restriction can be removed after careful consideration, so that more developers can enjoy the improvement of expression ability brought by Java's new language features. These features are pure language features that can be easily compiled into older versions of Java bytecode: * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance methods; Allow effectively-final variables to be used as resources in the try-with-resources statement;Allow diamond with anonymous classes if the argument type of the inferred type is denotable. * Local-Variable Type Inference (JEP 286) * Local-Variable Syntax for Lambda Parameters (JEP 323) * Switch Expressions (JEP 361) * Text Blocks (JEP 378) * Pattern Matching for instanceof (JEP 394) * Pattern Matching for switch (JEP 406) * Record Patterns & Array Patterns (JEP 405) These characteristics cannot be directly desugared, but can be accepted by the old runtime: * module-info.java (JEP 261): At present, it is a popular practice to use Java 8 compilation library and add module info to it. However, this practice has not been well supported by the official. Even with a build tool like gradle, it needs to be implemented by special means. If javac can accept module info when the target version is less than 9 and compile it to Java 9, it is very helpful to simplify modular existing code. * Allow interface methods to be private (JDK-8071453): This seems to be allowed in jvmls 8, but it was not until Java 9 that it was introduced into the Java language. * Sealed Classes (JEP 409): Javac generates PermittedSubclasses_attribute for sealed classes. This attribute will be ignored on the old runtime and will not destroy the program. Even if it cannot be guaranteed by the runtime before JDK 15, it can enhance the expressiveness of the language and make the code more compatible with the higher version runtime. * Universal Generics (JDK-8261529): Universal generics seem to compile well into bytecode compatible with older Java version. I think it is particularly important to allow use of universal generic in older bytecodes. This allows the library to adapt it without compromising compatibility with older Java versions. This can erase many obstacles to Valhalla's promotion. Now we can use some hacks to do similar things, like https://github.com/bsideup/jabel But this is just hack. It is unofficial and non-standard. At the same time, it also lacks tool support. We can also choose to switch to kotlin or Scala, both of them can emit Java 8 bytecode. In fact, because of the need for compatibility, the new language features of Java can't bring us more attraction because we can't use it most of the time. Over time, kotlin and Scala, which can have more language features on Java 8, have attracted us more and more. These problems are not just in the Java 8 era. The need to be compatible with old Java versions always exists, which makes it difficult for many people to put new features of the Java language into production for a long time. This will make Java less competitive with other JVM languages. From maurizio.cimadamore at oracle.com Tue Oct 12 10:03:05 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 12 Oct 2021 11:03:05 +0100 Subject: New candidate JEP: 419: Foreign Function & Memory API (Second Incubator) In-Reply-To: <34D186B3-DA93-43A4-9EC8-63FFC14828E7@gmail.com> References: <20211011224115.BCE714C3D63@eggemoggin.niobe.net> <34D186B3-DA93-43A4-9EC8-63FFC14828E7@gmail.com> Message-ID: On 12/10/2021 07:00, Sebastian Stenzel wrote: > I looked at these two lines from the example on the JEP page: > > MemorySegment cString = MemorySegment.allocateNative(javaStrings[i].length + 1, ...); > cString.setUtf8String(0, javaStrings[i]); > > Just looking at the code, I have to guess, where exactly null-termination happens. There are two options: > > * Either `allocateNative` fills the allocated memory with zeros - while inefficient, this might be a legitimate assumption for people only knowing Java allocateNative does zero-init the memory. > * Or `setUtf8String` adds a null byte - which should then be documented somewhere That too. > > So I looked at the JavaDoc and I believe the documentation can be improved for both methods: I agree javadoc should be improved. > > First of all, regarding `allocateNative`, I think it should be explicitly stated that allocation does not mean initialization. While this might be obvious for most people here, we should keep in mind that by making the non-Java world more accessible for Java developers, we should do our best to warn those people about the different laws of nature they need to obey when entering this world. Except that allocateNative does zero the memory :-) There are some obscure flags by which you can disable this, but in general that's the lay of the land. If a more optimized allocator is needed, a SegmentAllocator is probably the way to go, in which there's more freedom as to how memory is actually allocated/inited. Note that ByteBuffer.allocateDirect also does memory zeroing. > > > Furthermore, here are my two cents about the `setUtf8String` JavaDoc. Currently it says: > >> Writes a UTF-8 encoded, null-terminated string into this segment at given offset. > ... which, being nit-picky, I read as "please pass a UTF-8 encoded, null terminated string to this method". Instead, I'd suggest: > >> Writes the given string into this segment at given offset, converting it to a null-terminated byte sequence using UTF-8 encoding. Sounds good. > > Last but not least, I'd like to note that the size of the allocated segment in the aforementioned example depends on the string length (should be `length()`), which is inaccurate when using multi-byte unicode code points. Just thought, I'd mention it, as people may copy this code. This is all true but.... let me put the example in context: * that's the first example in the JEP * the goal of that example is to give a "feel" of what the API can do (you will see there's a lot of sections with "..." in them) - copy and paste won't work * in principle, it's easier to just use an allocator to allocate AND initialize a Utf8 native string with null termination; but allocators felt too much for this first example * if you scroll down, there's a more detailed example on how to call strlen - and that does use an implicitAllocator The alternative is to replace the snippet with: implicitAllocator().allocateUtf8String(javaStrings[i]); Perhaps we might just do that (in the earlier iteration we did not have a constant for that allocator). Maurizio > > >> On 12. Oct 2021, at 00:41, mark.reinhold at oracle.com wrote: >> >> https://openjdk.java.net/jeps/419 >> >> 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 forax at univ-mlv.fr Tue Oct 12 14:25:56 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Oct 2021 16:25:56 +0200 (CEST) Subject: Allow new language features on older version targets? In-Reply-To: References: Message-ID: <1759836117.1029337.1634048756575.JavaMail.zimbra@u-pem.fr> Hi, Java 9 can be a hard pill to swallow, part of the issues is that all dependencies need to be updated before moving to 11, slowing down the adoption of Java 11. I think your proposal does not help. You have forgotten the fact that the bytecode is not only consumed by the VM but by a lot of languages, tools, frameworks and libraries. Gradle, ErrorProne, FindBugs, Spring, Hibernate just to cite a few may/will choke if there are known new bytecode attributes but in older classfile versions. So nestmates, records and sealed classes, all introduce new attributes thus can not be backported as is. Records and switch on types both require special bootstrap methods, which did not exist in older JDK thus it can not be backported as is. For switch expression, the structure of the generated bytecode is quite unusual, a value stay on stack before the goto at the end of each case, again, it can trouble some static analysis, so it can not be backported as is. For me, the cost of having to test and maintain all combinations of the new feature with the old bytecodes for every existing software that consume bytecodes clearly outweigh what you think could be a nice feature to have. regards, R?mi PS: i'm currently playing with Scala 3 and i really hope that a lot of people will use it, there are some really great features in Scala 3, and i'm curious how people will use them. > From: "Glavo" > To: "compiler-dev" , "jdk-dev" > > Sent: Mardi 12 Octobre 2021 10:14:45 > Subject: Allow new language features on older version targets? > Starting from Java 9, Java began to iterate rapidly and introduced > many new features, which made Java more expressive and modern. > However, upgrading Java is always difficult and painful. It needs to > go through a series of cumbersome upgrade and migration processes. > In these steps, the transplantation at the syntax level is often easy, > because Java maintains good compatibility. However, due to subtle > changes in the behavior of the JVM and the standard library, it is > relatively difficult to upgrade the version of the java runtime. > At the same time, for client applications, upgrading the development > environment is much easier than upgrading the Java version of the > deployment environment (e.g., only Java 8 is currently available on > MIPS64el). For various reasons, a large number of users stay on the > old java version. According to the statistical report of JetBrains, > 71% of users still regularly use Java 8.0 in 2021. > The most affected people are the developers of libraries. In order to > make the library more widely used, most library authors always need to > make their libraries use the lowest java version possible. This makes > it difficult for them to enjoy the expression upgrade brought by Java > update. > This pain is not necessary. Although some language features of Java > require the cooperation of JVM and standard library, e.g. Record, but > this is not necessary for more features. At present, we can specify > the source version and target version respectively, but we can't make > the source version higher than the target version. I think this > artificial additional restriction can be removed after careful > consideration, so that more developers can enjoy the improvement of > expression ability brought by Java's new language features. > These features are pure language features that can be easily compiled > into older versions of Java bytecode: > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > methods; Allow effectively-final variables to be used as resources > in the try-with-resources statement;Allow diamond with anonymous > classes if the argument type of the inferred type is denotable. > * Local-Variable Type Inference (JEP 286) > * Local-Variable Syntax for Lambda Parameters (JEP 323) > * Switch Expressions (JEP 361) > * Text Blocks (JEP 378) > * Pattern Matching for instanceof (JEP 394) > * Pattern Matching for switch (JEP 406) > * Record Patterns & Array Patterns (JEP 405) > These characteristics cannot be directly desugared, but can be accepted > by the old runtime: > * module-info.java (JEP 261): At present, it is a popular practice to > use Java 8 compilation library and add module info to it. However, > this practice has not been well supported by the official. Even > with a build tool like gradle, it needs to be implemented by > special means. If javac can accept module info when the target > version is less than 9 and compile it to Java 9, it is very helpful > to simplify modular existing code. > * Allow interface methods to be private (JDK-8071453): This seems to > be allowed in jvmls 8, but it was not until Java 9 that it was > introduced into the Java language. > * Sealed Classes (JEP 409): Javac generates PermittedSubclasses_attribute > for sealed classes. This attribute will be ignored on the old > runtime and will not destroy the program. Even if it cannot be > guaranteed by the runtime before JDK 15, it can enhance the > expressiveness of the language and make the code more compatible > with the higher version runtime. > * Universal Generics (JDK-8261529): Universal generics seem to > compile well into bytecode compatible with older Java version. > I think it is particularly important to allow use of universal > generic in older bytecodes. This allows the library to adapt it > without compromising compatibility with older Java versions. This > can erase many obstacles to Valhalla's promotion. > Now we can use some hacks to do similar things, like > [ https://github.com/bsideup/jabel | https://github.com/bsideup/jabel ] > But this is just hack. It is unofficial and non-standard. At the same > time, it also lacks tool support. > We can also choose to switch to kotlin or Scala, both of them can emit > Java 8 bytecode. In fact, because of the need for compatibility, the > new language features of Java can't bring us more attraction because > we can't use it most of the time. Over time, kotlin and Scala, which > can have more language features on Java 8, have attracted us more and > more. These problems are not just in the Java 8 era. The need to be > compatible with old Java versions always exists, which makes it difficult > for many people to put new features of the Java language into production > for a long time. This will make Java less competitive with other JVM > languages. From dalibor.topic at oracle.com Tue Oct 12 15:24:37 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 12 Oct 2021 17:24:37 +0200 Subject: Allow new language features on older version targets? In-Reply-To: References: Message-ID: <653a9927-b857-3194-4042-8b621a6d1604@oracle.com> On 12.10.2021 10:14, Glavo wrote: > This pain is not necessary. Although some language features of Java > require the cooperation of JVM and standard library, e.g. Record, but > this is not necessary for more features. At present, we can specify > the source version and target version respectively, but we can't make > the source version higher than the target version. I think this > artificial additional restriction can be removed after careful > consideration, so that more developers can enjoy the improvement of > expression ability brought by Java's new language features. Unfortunately, it's not an artificial restriction. Java SE 8 is already specified, i.e. it was done in 2014. Any further changes to its specification would require a maintenance release of the specification. But new language features are not in scope for maintenance releases: "Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements." per JCP 2.11, which is in use for Java SE 8. So there is no path forward where a revised Java SE 8 with new language features would be possible. 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 ron.pressler at oracle.com Tue Oct 12 16:44:41 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 12 Oct 2021 16:44:41 +0000 Subject: Allow new language features on older version targets? In-Reply-To: References: Message-ID: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> That many people still use Java 8 (often alongside newer versions) doesn't mean that those applications are under heavy development and can benefit from new language features, or from new library features, as much as more active codebases. In any event, you're proposing that we divert resources away from making new versions more attractive toward making older versions more attractive. I don't think this is a good strategy. The portion of people using alternative languages on the Java platform has remained more-or-less constant for many years, and I, for one, am happy that the platform caters to people with different programming tastes. Java's competitive focus is elsewhere. -- Ron > On 12 Oct 2021, at 09:14, Glavo wrote: > > Starting from Java 9, Java began to iterate rapidly and introduced > many new features, which made Java more expressive and modern. > > However, upgrading Java is always difficult and painful. It needs to > go through a series of cumbersome upgrade and migration processes. > In these steps, the transplantation at the syntax level is often easy, > because Java maintains good compatibility. However, due to subtle > changes in the behavior of the JVM and the standard library, it is > relatively difficult to upgrade the version of the java runtime. > At the same time, for client applications, upgrading the development > environment is much easier than upgrading the Java version of the > deployment environment (e.g., only Java 8 is currently available on > MIPS64el). For various reasons, a large number of users stay on the > old java version. According to the statistical report of JetBrains, > 71% of users still regularly use Java 8.0 in 2021. > > The most affected people are the developers of libraries. In order to > make the library more widely used, most library authors always need to > make their libraries use the lowest java version possible. This makes > it difficult for them to enjoy the expression upgrade brought by Java > update. > > This pain is not necessary. Although some language features of Java > require the cooperation of JVM and standard library, e.g. Record, but > this is not necessary for more features. At present, we can specify > the source version and target version respectively, but we can't make > the source version higher than the target version. I think this > artificial additional restriction can be removed after careful > consideration, so that more developers can enjoy the improvement of > expression ability brought by Java's new language features. > > > These features are pure language features that can be easily compiled > into older versions of Java bytecode: > > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > methods; Allow effectively-final variables to be used as resources > in the try-with-resources statement;Allow diamond with anonymous > classes if the argument type of the inferred type is denotable. > > * Local-Variable Type Inference (JEP 286) > * Local-Variable Syntax for Lambda Parameters (JEP 323) > * Switch Expressions (JEP 361) > * Text Blocks (JEP 378) > * Pattern Matching for instanceof (JEP 394) > * Pattern Matching for switch (JEP 406) > * Record Patterns & Array Patterns (JEP 405) > > > These characteristics cannot be directly desugared, but can be accepted > by the old runtime: > > * module-info.java (JEP 261): At present, it is a popular practice to > use Java 8 compilation library and add module info to it. However, > this practice has not been well supported by the official. Even > with a build tool like gradle, it needs to be implemented by > special means. If javac can accept module info when the target > version is less than 9 and compile it to Java 9, it is very helpful > to simplify modular existing code. > > * Allow interface methods to be private (JDK-8071453): This seems to > be allowed in jvmls 8, but it was not until Java 9 that it was > introduced into the Java language. > > * Sealed Classes (JEP 409): Javac generates PermittedSubclasses_attribute > for sealed classes. This attribute will be ignored on the old > runtime and will not destroy the program. Even if it cannot be > guaranteed by the runtime before JDK 15, it can enhance the > expressiveness of the language and make the code more compatible > with the higher version runtime. > > * Universal Generics (JDK-8261529): Universal generics seem to > compile well into bytecode compatible with older Java version. > I think it is particularly important to allow use of universal > generic in older bytecodes. This allows the library to adapt it > without compromising compatibility with older Java versions. This > can erase many obstacles to Valhalla's promotion. > > > Now we can use some hacks to do similar things, like > > https://github.com/bsideup/jabel > > But this is just hack. It is unofficial and non-standard. At the same > time, it also lacks tool support. > > We can also choose to switch to kotlin or Scala, both of them can emit > Java 8 bytecode. In fact, because of the need for compatibility, the > new language features of Java can't bring us more attraction because > we can't use it most of the time. Over time, kotlin and Scala, which > can have more language features on Java 8, have attracted us more and > more. These problems are not just in the Java 8 era. The need to be > compatible with old Java versions always exists, which makes it difficult > for many people to put new features of the Java language into production > for a long time. This will make Java less competitive with other JVM > languages. From mgridinas at gmail.com Tue Oct 12 18:03:19 2021 From: mgridinas at gmail.com (Mantas Gridinas) Date: Tue, 12 Oct 2021 18:03:19 +0000 Subject: Allow new language features on older version targets? In-Reply-To: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> References: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> Message-ID: I agree with Ron's sentiment. Anecdotal, but back when I had to migrate an application from 8 to 11, it was much simpler to drop 8 support (and 8 runtime altogether) rather than maintain two codebases (and runtimes). The tipping point was cold startup performance increment from 5 minutes to 1 minute solely because we upgraded to Java 11. On Tue, Oct 12, 2021 at 4:45 PM Ron Pressler wrote: > That many people still use Java 8 (often alongside newer versions) doesn't > mean that those applications are under heavy development and can benefit > from > new language features, or from new library features, as much as more active > codebases. > > In any event, you're proposing that we divert resources away from making > new > versions more attractive toward making older versions more attractive. I > don't > think this is a good strategy. The portion of people using alternative > languages on the Java platform has remained more-or-less constant for many > years, and I, for one, am happy that the platform caters to people with > different programming tastes. Java's competitive focus is elsewhere. > > -- Ron > > > On 12 Oct 2021, at 09:14, Glavo wrote: > > > > Starting from Java 9, Java began to iterate rapidly and introduced > > many new features, which made Java more expressive and modern. > > > > However, upgrading Java is always difficult and painful. It needs to > > go through a series of cumbersome upgrade and migration processes. > > In these steps, the transplantation at the syntax level is often easy, > > because Java maintains good compatibility. However, due to subtle > > changes in the behavior of the JVM and the standard library, it is > > relatively difficult to upgrade the version of the java runtime. > > At the same time, for client applications, upgrading the development > > environment is much easier than upgrading the Java version of the > > deployment environment (e.g., only Java 8 is currently available on > > MIPS64el). For various reasons, a large number of users stay on the > > old java version. According to the statistical report of JetBrains, > > 71% of users still regularly use Java 8.0 in 2021. > > > > The most affected people are the developers of libraries. In order to > > make the library more widely used, most library authors always need to > > make their libraries use the lowest java version possible. This makes > > it difficult for them to enjoy the expression upgrade brought by Java > > update. > > > > This pain is not necessary. Although some language features of Java > > require the cooperation of JVM and standard library, e.g. Record, but > > this is not necessary for more features. At present, we can specify > > the source version and target version respectively, but we can't make > > the source version higher than the target version. I think this > > artificial additional restriction can be removed after careful > > consideration, so that more developers can enjoy the improvement of > > expression ability brought by Java's new language features. > > > > > > These features are pure language features that can be easily compiled > > into older versions of Java bytecode: > > > > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > > methods; Allow effectively-final variables to be used as resources > > in the try-with-resources statement;Allow diamond with anonymous > > classes if the argument type of the inferred type is denotable. > > > > * Local-Variable Type Inference (JEP 286) > > * Local-Variable Syntax for Lambda Parameters (JEP 323) > > * Switch Expressions (JEP 361) > > * Text Blocks (JEP 378) > > * Pattern Matching for instanceof (JEP 394) > > * Pattern Matching for switch (JEP 406) > > * Record Patterns & Array Patterns (JEP 405) > > > > > > These characteristics cannot be directly desugared, but can be accepted > > by the old runtime: > > > > * module-info.java (JEP 261): At present, it is a popular practice to > > use Java 8 compilation library and add module info to it. However, > > this practice has not been well supported by the official. Even > > with a build tool like gradle, it needs to be implemented by > > special means. If javac can accept module info when the target > > version is less than 9 and compile it to Java 9, it is very helpful > > to simplify modular existing code. > > > > * Allow interface methods to be private (JDK-8071453): This seems to > > be allowed in jvmls 8, but it was not until Java 9 that it was > > introduced into the Java language. > > > > * Sealed Classes (JEP 409): Javac generates > PermittedSubclasses_attribute > > for sealed classes. This attribute will be ignored on the old > > runtime and will not destroy the program. Even if it cannot be > > guaranteed by the runtime before JDK 15, it can enhance the > > expressiveness of the language and make the code more compatible > > with the higher version runtime. > > > > * Universal Generics (JDK-8261529): Universal generics seem to > > compile well into bytecode compatible with older Java version. > > I think it is particularly important to allow use of universal > > generic in older bytecodes. This allows the library to adapt it > > without compromising compatibility with older Java versions. This > > can erase many obstacles to Valhalla's promotion. > > > > > > Now we can use some hacks to do similar things, like > > > > https://github.com/bsideup/jabel > > > > But this is just hack. It is unofficial and non-standard. At the same > > time, it also lacks tool support. > > > > We can also choose to switch to kotlin or Scala, both of them can emit > > Java 8 bytecode. In fact, because of the need for compatibility, the > > new language features of Java can't bring us more attraction because > > we can't use it most of the time. Over time, kotlin and Scala, which > > can have more language features on Java 8, have attracted us more and > > more. These problems are not just in the Java 8 era. The need to be > > compatible with old Java versions always exists, which makes it difficult > > for many people to put new features of the Java language into production > > for a long time. This will make Java less competitive with other JVM > > languages. > > -- // Mantas From zjx001202 at gmail.com Wed Oct 13 01:16:17 2021 From: zjx001202 at gmail.com (Glavo) Date: Wed, 13 Oct 2021 09:16:17 +0800 Subject: Allow new language features on older version targets? In-Reply-To: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> References: <6AD79BB5-472C-473C-B825-0B0DBC944629@oracle.com> Message-ID: > > That many people still use Java 8 (often alongside newer versions) doesn't > mean that those applications are under heavy development and can benefit > from > new language features, or from new library features, as much as more active > codebases. > I agree that this is the case for program developers, but the focus of the problem is not on them. The main problem is the developers of the libraries. As developers of the library, we need to choose the lower java version as possible and stay here for a long time. Every time we update Java, we are abandoning a group of users and splitting the user group. This doesn't mean that we don't pursue new technologies. I always install the latest JDK on my computer and use it to compile Java 8 compatible code. I will solve the problem of porting with all Java versions, but I can't choose to give up users of the old version of Java, so I can only use Java 8 to develop class libraries forever. I believe that making class libraries compatible with both new and old versions of Java is a very common requirement. A considerable number of these users can benefit from the new language features, but they have to stay in the old version for more users. This problem can be seen from the fact that many class libraries are compiled with Java 8 but carry module-info.class. This problem will also become more prominent because Valhalla refuses us to provide class libraries that work well on both old and new versions, even features such as Universal Generics that should work on old Java. The portion of people using alternative languages on the Java platform has > remained more-or-less constant for many years... > Are you sure? It's not what I know. In my opinion, more and more users are choosing Kotlin instead of Java -- and most of them choose Java 8 or 6 as the target version. I just hate developing class libraries with kotlin or Scala. Their interaction with Java is not as good as using java directly. Moreover, Scala 3 contains too many bugs and introduces features I hate very much. So I've been enduring the syntax of Java 8. So I have been enduring the syntax of Java 8, so that I have begun to develop a compiler compatible with the latest Java syntax and can take Java 8 as the compilation target. But this will take a long time and will cost me a lot of energy to maintain, so I am eager for an official solution. Ron Pressler ?2021?10?13??? ??12:44??? > That many people still use Java 8 (often alongside newer versions) doesn't > mean that those applications are under heavy development and can benefit > from > new language features, or from new library features, as much as more active > codebases. > > In any event, you're proposing that we divert resources away from making > new > versions more attractive toward making older versions more attractive. I > don't > think this is a good strategy. The portion of people using alternative > languages on the Java platform has remained more-or-less constant for many > years, and I, for one, am happy that the platform caters to people with > different programming tastes. Java's competitive focus is elsewhere. > > -- Ron > > > On 12 Oct 2021, at 09:14, Glavo wrote: > > > > Starting from Java 9, Java began to iterate rapidly and introduced > > many new features, which made Java more expressive and modern. > > > > However, upgrading Java is always difficult and painful. It needs to > > go through a series of cumbersome upgrade and migration processes. > > In these steps, the transplantation at the syntax level is often easy, > > because Java maintains good compatibility. However, due to subtle > > changes in the behavior of the JVM and the standard library, it is > > relatively difficult to upgrade the version of the java runtime. > > At the same time, for client applications, upgrading the development > > environment is much easier than upgrading the Java version of the > > deployment environment (e.g., only Java 8 is currently available on > > MIPS64el). For various reasons, a large number of users stay on the > > old java version. According to the statistical report of JetBrains, > > 71% of users still regularly use Java 8.0 in 2021. > > > > The most affected people are the developers of libraries. In order to > > make the library more widely used, most library authors always need to > > make their libraries use the lowest java version possible. This makes > > it difficult for them to enjoy the expression upgrade brought by Java > > update. > > > > This pain is not necessary. Although some language features of Java > > require the cooperation of JVM and standard library, e.g. Record, but > > this is not necessary for more features. At present, we can specify > > the source version and target version respectively, but we can't make > > the source version higher than the target version. I think this > > artificial additional restriction can be removed after careful > > consideration, so that more developers can enjoy the improvement of > > expression ability brought by Java's new language features. > > > > > > These features are pure language features that can be easily compiled > > into older versions of Java bytecode: > > > > * Milling Project Coin (JEP 213): Allow @SafeVargs on private instance > > methods; Allow effectively-final variables to be used as resources > > in the try-with-resources statement;Allow diamond with anonymous > > classes if the argument type of the inferred type is denotable. > > > > * Local-Variable Type Inference (JEP 286) > > * Local-Variable Syntax for Lambda Parameters (JEP 323) > > * Switch Expressions (JEP 361) > > * Text Blocks (JEP 378) > > * Pattern Matching for instanceof (JEP 394) > > * Pattern Matching for switch (JEP 406) > > * Record Patterns & Array Patterns (JEP 405) > > > > > > These characteristics cannot be directly desugared, but can be accepted > > by the old runtime: > > > > * module-info.java (JEP 261): At present, it is a popular practice to > > use Java 8 compilation library and add module info to it. However, > > this practice has not been well supported by the official. Even > > with a build tool like gradle, it needs to be implemented by > > special means. If javac can accept module info when the target > > version is less than 9 and compile it to Java 9, it is very helpful > > to simplify modular existing code. > > > > * Allow interface methods to be private (JDK-8071453): This seems to > > be allowed in jvmls 8, but it was not until Java 9 that it was > > introduced into the Java language. > > > > * Sealed Classes (JEP 409): Javac generates > PermittedSubclasses_attribute > > for sealed classes. This attribute will be ignored on the old > > runtime and will not destroy the program. Even if it cannot be > > guaranteed by the runtime before JDK 15, it can enhance the > > expressiveness of the language and make the code more compatible > > with the higher version runtime. > > > > * Universal Generics (JDK-8261529): Universal generics seem to > > compile well into bytecode compatible with older Java version. > > I think it is particularly important to allow use of universal > > generic in older bytecodes. This allows the library to adapt it > > without compromising compatibility with older Java versions. This > > can erase many obstacles to Valhalla's promotion. > > > > > > Now we can use some hacks to do similar things, like > > > > https://github.com/bsideup/jabel > > > > But this is just hack. It is unofficial and non-standard. At the same > > time, it also lacks tool support. > > > > We can also choose to switch to kotlin or Scala, both of them can emit > > Java 8 bytecode. In fact, because of the need for compatibility, the > > new language features of Java can't bring us more attraction because > > we can't use it most of the time. Over time, kotlin and Scala, which > > can have more language features on Java 8, have attracted us more and > > more. These problems are not just in the Java 8 era. The need to be > > compatible with old Java versions always exists, which makes it difficult > > for many people to put new features of the Java language into production > > for a long time. This will make Java less competitive with other JVM > > languages. > > From ioi.lam at oracle.com Thu Oct 14 00:56:05 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 13 Oct 2021 17:56:05 -0700 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <197339BF-C018-4DA3-B3A7-0CBCBE9B983C@cox.net> <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> Message-ID: <6f609cbb-dc6e-3f4d-d635-75ed43b7e429@oracle.com> Hi Glavo, I have simplified my prototype so now there's no need to implement new URL handlers. ??? https://github.com/iklam/tools/tree/main/jigsaw/uberjar Please see the "Super-JAR Demo" section. The new demo uses standard features supported by the JDK's built-in "jar:" URL handler. The only difference with my previous demo is that we store the "exploded" version of the modules. I.e., the JAR file looks like this: ??? modules/com.lib/com/lib/Lib.class ??? modules/com.lib/module-info.class ??? ... ??? modules/com.simple/com/simple/Simple.class ??? modules/com.simple/com/simple/Simple$Foo.class ??? modules/com.simple/module-info.class All the modules are loaded from the /modules directories in the JAR file. The URI for a class looks like this: jar:file:///tmp/apps/super-launcher.jar!/modules/com.lib/com/lib/Lib.class For modularized apps, I think this is a much better approach than the traditional Uber-JARs that store JAR files inside a JAR file, which will require more complex decompression. In fact, I don't understand why people started packing JAR files inside JAR files. Maybe there were some esoteric reasons (related to Class-Path: attribute in manifest files???). But, whatever reason they had would not apply to a modular application, where every component is already in a Jigsaw module. Packing the exploded image into a JAR file will be good enough. ********************** Going forward, I would suggest -- [1] Frameworks such as SpringBoot can consider the idea in this demo for a possible solution for packaging modules [2] For the JDK, we should investigate supporting a single-file packaging format for modules. E.g. extend the --module-path command-line option to support modules that are stored in a single file (either a JAR file or an image file produced by jlink). ??? java --module-path=super-jar.jar -m com.simple or ??? java --module-path=super-jar.jar -m com.simple Or even this (with appropriate attributes in the JAR manifest): ?? java -jar super-jar.jar I believe [2] is doable as the underpinning support is already in the JDK. We need to decide what format to support, how to specify the location of the modules directory inside a JAR file, etc. As always, since the Oracle Java team has limited resources, participation from the Java community is very much appreciated and encouraged :-) Thanks - Ioi On 10/11/21 3:48 PM, Glavo wrote: > I mistakenly believe that the implementation of the filesystem corresponds > exactly to the URL. The problem I really want to express is that JDK > does not support URLs of nested jar file systems. It seems that this > problem still exists in JDK 17. To make matters worse, we can use toUri() > to convert the path of the file in the nested jar into a URI, but this > URI is neither accepted by Paths.get (java.lang.IllegalArgumentException? > URI does not contain path info ex. jar:file:/c:/foo.zip!/BAR) nor > converted into a URL (java.net.MalformedURLException: Nested JAR URLs > are not supported). Is this a bug or an expected behavior? > > Alan Bateman ?2021?10?12??? ??2:58??? > >> On 11/10/2021 15:09, Glavo wrote: >>> I think this is a great prototype. Based on it, I think such requirements >>> can also be realized by enhancing jar in these aspects: >>> >>> 1. Nested jar file system (The ujar file system seems unnecessary. >>> I never understand why jar file systems cannot be nested.) >> This was fixed in JDK 12, are you seeing issues with release recent >> releases? If so then would it be possible to submit a bug with a test >> case or bring the issue to core-libs-dev? >> >> -Alan >> From ioi.lam at oracle.com Thu Oct 14 00:57:53 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 13 Oct 2021 17:57:53 -0700 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <197339BF-C018-4DA3-B3A7-0CBCBE9B983C@cox.net> <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> Message-ID: <86c3f360-e6f2-8b36-5b31-e2b5344e88bc@oracle.com> Hi Glavo, I have simplified my prototype so now there's no need to implement new URL handlers. ??? https://github.com/iklam/tools/tree/main/jigsaw/uberjar Please see the "Super-JAR Demo" section. The new demo uses standard features supported by the JDK's built-in "jar:" URL handler. The only difference with my previous demo is that we store the "exploded" version of the modules. I.e., the JAR file looks like this: ??? modules/com.lib/com/lib/Lib.class ??? modules/com.lib/module-info.class ??? ... ??? modules/com.simple/com/simple/Simple.class ??? modules/com.simple/com/simple/Simple$Foo.class ??? modules/com.simple/module-info.class All the modules are loaded from the /modules directories in the JAR file. The URI for a class looks like this: jar:file:///tmp/apps/super-launcher.jar!/modules/com.lib/com/lib/Lib.class For modularized apps, I think this is a much better approach than the traditional Uber-JARs that store JAR files inside a JAR file, which will require more complex decompression. In fact, I don't understand why people started packing JAR files inside JAR files. Maybe there were some esoteric reasons (related to Class-Path: attribute in manifest files???). But, whatever reason they had would not apply to a modular application, where every component is already in a Jigsaw module. Packing the exploded image into a JAR file will be good enough. ********************** Going forward, I would suggest -- [1] Frameworks such as SpringBoot can consider the idea in this demo for a possible solution for packaging modules [2] For the JDK, we should investigate supporting a single-file packaging format for modules. E.g. extend the --module-path command-line option to support modules that are stored in a single file (either a JAR file or an image file produced by jlink). ??? java --module-path=super-jar.jar -m com.simple or ??? java --module-path=super-jar.jar -m com.simple Or even this (with appropriate attributes in the JAR manifest): ?? java -jar super-jar.jar I believe [2] is doable as the underpinning support is already in the JDK. We need to decide what format to support, how to specify the location of the modules directory inside a JAR file, etc. As always, since the Oracle Java team has limited resources, participation from the Java community is very much appreciated and encouraged :-) Thanks - Ioi On 10/11/21 3:48 PM, Glavo wrote: > I mistakenly believe that the implementation of the filesystem corresponds > exactly to the URL. The problem I really want to express is that JDK > does not support URLs of nested jar file systems. It seems that this > problem still exists in JDK 17. To make matters worse, we can use toUri() > to convert the path of the file in the nested jar into a URI, but this > URI is neither accepted by Paths.get (java.lang.IllegalArgumentException? > URI does not contain path info ex. jar:file:/c:/foo.zip!/BAR) nor > converted into a URL (java.net.MalformedURLException: Nested JAR URLs > are not supported). Is this a bug or an expected behavior? > > Alan Bateman ?2021?10?12??? ??2:58??? > >> On 11/10/2021 15:09, Glavo wrote: >>> I think this is a great prototype. Based on it, I think such >>> requirements >>> can also be realized by enhancing jar in these aspects: >>> >>> 1. Nested jar file system (The ujar file system seems unnecessary. >>> I never understand why jar file systems cannot be nested.) >> This was fixed in JDK 12, are you seeing issues with release recent >> releases? If so then would it be possible to submit a bug with a test >> case or bring the issue to core-libs-dev? >> >> -Alan >> From zjx001202 at gmail.com Thu Oct 14 15:29:27 2021 From: zjx001202 at gmail.com (Glavo) Date: Thu, 14 Oct 2021 23:29:27 +0800 Subject: Alternative to fatJar - modular solution? In-Reply-To: <6f609cbb-dc6e-3f4d-d635-75ed43b7e429@oracle.com> References: <197339BF-C018-4DA3-B3A7-0CBCBE9B983C@cox.net> <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> <6f609cbb-dc6e-3f4d-d635-75ed43b7e429@oracle.com> Message-ID: > > In fact, I don't understand why people started packing JAR files inside > JAR files. Maybe there were some esoteric reasons (related to > Class-Path: attribute in manifest files???). > Sometimes it's necessary to keep jars intact and distribute them as they are. In fact, a program I just developed today is not compatible with your solution: It uses cls.getProtectionDomain().getCodeSource().getLocation() find its place, create a zip file system and traverse some of its folders. We also have some strange use cases that require additional data to be appended before the jar content. Dismantling the jar will destroy the data. Ioi Lam ?2021?10?14??? ??8:57??? > Hi Glavo, > > I have simplified my prototype so now there's no need to implement new > URL handlers. > > https://github.com/iklam/tools/tree/main/jigsaw/uberjar > > Please see the "Super-JAR Demo" section. > > The new demo uses standard features supported by the JDK's built-in > "jar:" URL handler. The only difference with my previous demo is that we > store the "exploded" version of the modules. I.e., the JAR file looks > like this: > > modules/com.lib/com/lib/Lib.class > modules/com.lib/module-info.class > ... > modules/com.simple/com/simple/Simple.class > modules/com.simple/com/simple/Simple$Foo.class > modules/com.simple/module-info.class > > All the modules are loaded from the /modules directories in the JAR file. > > The URI for a class looks like this: > > jar:file:///tmp/apps/super-launcher.jar!/modules/com.lib/com/lib/Lib.class > > For modularized apps, I think this is a much better approach than the > traditional Uber-JARs that store JAR files inside a JAR file, which will > require more complex decompression. > > In fact, I don't understand why people started packing JAR files inside > JAR files. Maybe there were some esoteric reasons (related to > Class-Path: attribute in manifest files???). > > But, whatever reason they had would not apply to a modular application, > where every component is already in a Jigsaw module. Packing the > exploded image into a JAR file will be good enough. > > ********************** > > Going forward, I would suggest -- > > [1] Frameworks such as SpringBoot can consider the idea in this demo for > a possible solution for packaging modules > > [2] For the JDK, we should investigate supporting a single-file > packaging format for modules. E.g. extend the --module-path command-line > option to support modules that are stored in a single file (either a JAR > file or an image file produced by jlink). > > java --module-path=super-jar.jar -m com.simple > or > java --module-path=super-jar.jar -m com.simple > > Or even this (with appropriate attributes in the JAR manifest): > > java -jar super-jar.jar > > I believe [2] is doable as the underpinning support is already in the > JDK. We need to decide what format to support, how to specify the > location of the modules directory inside a JAR file, etc. > > As always, since the Oracle Java team has limited resources, > participation from the Java community is very much appreciated and > encouraged :-) > > Thanks > - Ioi > > > > On 10/11/21 3:48 PM, Glavo wrote: > > I mistakenly believe that the implementation of the filesystem > corresponds > > exactly to the URL. The problem I really want to express is that JDK > > does not support URLs of nested jar file systems. It seems that this > > problem still exists in JDK 17. To make matters worse, we can use toUri() > > to convert the path of the file in the nested jar into a URI, but this > > URI is neither accepted by Paths.get (java.lang.IllegalArgumentException? > > URI does not contain path info ex. jar:file:/c:/foo.zip!/BAR) nor > > converted into a URL (java.net.MalformedURLException: Nested JAR URLs > > are not supported). Is this a bug or an expected behavior? > > > > Alan Bateman ?2021?10?12??? ??2:58??? > > > >> On 11/10/2021 15:09, Glavo wrote: > >>> I think this is a great prototype. Based on it, I think such > requirements > >>> can also be realized by enhancing jar in these aspects: > >>> > >>> 1. Nested jar file system (The ujar file system seems unnecessary. > >>> I never understand why jar file systems cannot be nested.) > >> This was fixed in JDK 12, are you seeing issues with release recent > >> releases? If so then would it be possible to submit a bug with a test > >> case or bring the issue to core-libs-dev? > >> > >> -Alan > >> > > From ioi.lam at oracle.com Thu Oct 14 16:06:40 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 14 Oct 2021 09:06:40 -0700 Subject: Alternative to fatJar - modular solution? In-Reply-To: References: <197339BF-C018-4DA3-B3A7-0CBCBE9B983C@cox.net> <9b0a09c2-6249-314c-e188-5af5d6b4baaf@oracle.com> <6f609cbb-dc6e-3f4d-d635-75ed43b7e429@oracle.com> Message-ID: <20542e59-6354-726e-c038-1f53130ea300@oracle.com> On 10/14/21 8:29 AM, Glavo wrote: > > In fact, I don't understand why people started packing JAR files > inside > JAR files. Maybe there were some esoteric reasons (related to > Class-Path: attribute in manifest files???). > > > ?Sometimes it's necessary to keep jars intact and distribute them as > they are. In fact, a program I just developed today is not compatible > with your solution: It uses > cls.getProtectionDomain().getCodeSource().getLocation() > find its place, create a zip file system and traverse some of its folders. > Since we are discussing about a solution for storing modules in a single file, there's an API to list all the contents of a module -- java.lang.module.ModuleReader::list(). Here's an example: import java.lang.module.*; public class FindAllInModule { ??? public static void main(String args[]) throws Exception { ??????? Module module = java.lang.Object.class.getModule(); ??????? ModuleReference mref = module.getLayer().configuration() ??????????????? .findModule(module.getName()) ??????????????? .orElseThrow(() -> new RuntimeException()) ??????????????? .reference(); ??????? try (ModuleReader reader = mref.open()) { ???????????? reader.list().forEach(n -> System.out.println(n)); ??????? } ??? } } There's no requirements that a module must be stored in a JAR file. In fact, your program will not work if it was packaged into an image produced by jlink. That's why we have the ModuleReader::list() API. > We also have some strange use cases that require additional data to be > appended before the jar content. Dismantling the jar will destroy the > data. Could you explain what the actual scenario is? Is it for patching the contents of a module (similar to --patch-module)? Thanks - Ioi > Ioi Lam > > ?2021?10?14??? ??8:57??? > > Hi Glavo, > > I have simplified my prototype so now there's no need to implement > new > URL handlers. > > https://github.com/iklam/tools/tree/main/jigsaw/uberjar > > > Please see the "Super-JAR Demo" section. > > The new demo uses standard features supported by the JDK's built-in > "jar:" URL handler. The only difference with my previous demo is > that we > store the "exploded" version of the modules. I.e., the JAR file looks > like this: > > ???? modules/com.lib/com/lib/Lib.class > ???? modules/com.lib/module-info.class > ???? ... > ???? modules/com.simple/com/simple/Simple.class > ???? modules/com.simple/com/simple/Simple$Foo.class > ???? modules/com.simple/module-info.class > > All the modules are loaded from the /modules directories in the > JAR file. > > The URI for a class looks like this: > > jar:file:///tmp/apps/super-launcher.jar!/modules/com.lib/com/lib/Lib.class > > For modularized apps, I think this is a much better approach than the > traditional Uber-JARs that store JAR files inside a JAR file, > which will > require more complex decompression. > > In fact, I don't understand why people started packing JAR files > inside > JAR files. Maybe there were some esoteric reasons (related to > Class-Path: attribute in manifest files???). > > But, whatever reason they had would not apply to a modular > application, > where every component is already in a Jigsaw module. Packing the > exploded image into a JAR file will be good enough. > > ********************** > > Going forward, I would suggest -- > > [1] Frameworks such as SpringBoot can consider the idea in this > demo for > a possible solution for packaging modules > > [2] For the JDK, we should investigate supporting a single-file > packaging format for modules. E.g. extend the --module-path > command-line > option to support modules that are stored in a single file (either > a JAR > file or an image file produced by jlink). > > ???? java --module-path=super-jar.jar -m com.simple > or > ???? java --module-path=super-jar.jar -m com.simple > > Or even this (with appropriate attributes in the JAR manifest): > > ??? java -jar super-jar.jar > > I believe [2] is doable as the underpinning support is already in the > JDK. We need to decide what format to support, how to specify the > location of the modules directory inside a JAR file, etc. > > As always, since the Oracle Java team has limited resources, > participation from the Java community is very much appreciated and > encouraged :-) > > Thanks > - Ioi > > > > On 10/11/21 3:48 PM, Glavo wrote: > > I mistakenly believe that the implementation of the filesystem > corresponds > > exactly to the URL. The problem I really want to express is that JDK > > does not support URLs of nested jar file systems. It seems that this > > problem still exists in JDK 17. To make matters worse, we can > use toUri() > > to convert the path of the file in the nested jar into a URI, > but this > > URI is neither accepted by Paths.get > (java.lang.IllegalArgumentException? > > URI does not contain path info ex. jar:file:/c:/foo.zip!/BAR) nor > > converted into a URL (java.net > .MalformedURLException: > Nested JAR URLs > > are not supported). Is this a bug or an expected behavior? > > > > Alan Bateman > ?2021?10?12??? ??2:58??? > > > >> On 11/10/2021 15:09, Glavo wrote: > >>> I think this is a great prototype. Based on it, I think such > requirements > >>> can also be realized by enhancing jar in these aspects: > >>> > >>>? ? ?1. Nested jar file system (The ujar file system seems > unnecessary. > >>>? ? ? ? I never understand why jar file systems cannot be nested.) > >> This was fixed in JDK 12, are you seeing issues with release recent > >> releases? If so then would it be possible to submit a bug with > a test > >> case or bring the issue to core-libs-dev? > >> > >> -Alan > >> > From xcheng.dev at gmail.com Thu Oct 14 23:52:14 2021 From: xcheng.dev at gmail.com (Xi Cheng) Date: Thu, 14 Oct 2021 16:52:14 -0700 Subject: JDK/JRE 11.0.12+7-0ubuntu3 ARM64 Debian package has not been released Message-ID: hi, it seems that JDK/JRE 11.0.12+7 debian package has been released for AMD64: https://packages.ubuntu.com/impish/amd64/openjdk-11-jre-headless/download but not for ARM64: https://packages.ubuntu.com/impish/arm64/openjdk-11-jre-headless/download What is the main reason for this discrepancy and are there any timelines for releasing the ARM64 distribution? Thanks. Regards From nick.gasson at arm.com Fri Oct 15 01:43:12 2021 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 15 Oct 2021 09:43:12 +0800 Subject: JDK/JRE 11.0.12+7-0ubuntu3 ARM64 Debian package has not been released In-Reply-To: References: Message-ID: <85k0ift64v.fsf@arm.com> Hi, On 15/10/21 07:52 am, Xi Cheng wrote: > hi, it seems that JDK/JRE 11.0.12+7 debian package has been released for > AMD64: > https://packages.ubuntu.com/impish/amd64/openjdk-11-jre-headless/download > but not for ARM64: > https://packages.ubuntu.com/impish/arm64/openjdk-11-jre-headless/download > > What is the main reason for this discrepancy and are there any timelines > for releasing the ARM64 distribution? > You need to report that to Ubuntu rather than here. The OpenJDK project isn't involved with downstream packaging. -- Thanks, Nick From dalibor.topic at oracle.com Fri Oct 15 13:41:25 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 15 Oct 2021 15:41:25 +0200 Subject: JDK/JRE 11.0.12+7-0ubuntu3 ARM64 Debian package has not been released In-Reply-To: <85k0ift64v.fsf@arm.com> References: <85k0ift64v.fsf@arm.com> Message-ID: <8afe1916-0f26-2e90-9a82-85b34976f715@oracle.com> BCC:ing jdk-dev. Bug reports for Ubuntu packages of OpenJDK LTS releases should be filed here: https://launchpad.net/ubuntu/+source/openjdk-lts/+bugs cheers, dalibor topic On 15.10.2021 03:43, Nick Gasson wrote: > Hi, > > On 15/10/21 07:52 am, Xi Cheng wrote: >> hi, it seems that JDK/JRE 11.0.12+7 debian package has been released for >> AMD64: >> https://packages.ubuntu.com/impish/amd64/openjdk-11-jre-headless/download >> but not for ARM64: >> https://packages.ubuntu.com/impish/arm64/openjdk-11-jre-headless/download >> >> What is the main reason for this discrepancy and are there any timelines >> for releasing the ARM64 distribution? >> > > You need to report that to Ubuntu rather than here. The OpenJDK project > isn't involved with downstream packaging. > > -- > Thanks, > Nick > -- 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 Fri Oct 15 17:33:46 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Oct 2021 10:33:46 -0700 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: <20211007220702.5F9264C384E@eggemoggin.niobe.net> References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> Message-ID: <20211015103346.581821987@eggemoggin.niobe.net> 2021/10/7 15:07:02 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 18: > > 408: Simple Web Server > https://openjdk.java.net/jeps/408 > > Summary: Provide a command-line tool to start a minimal web server > that serves static files in the current directory. This low-threshold > utility will be useful for prototyping, ad-hoc coding, and testing > purposes, particularly in educational contexts. > > 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, 14 October, 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 18. One objection to this JEP was raised by Simone Bordet (not a Committer), but it was satisfactorily answered. I?ve targeted this JEP to JDK 18. - Mark From mark.reinhold at oracle.com Fri Oct 15 17:35:18 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Oct 2021 10:35:18 -0700 Subject: JEP proposed to target JDK 18: 408: Simple Web Server In-Reply-To: <20211007220702.5F9264C384E@eggemoggin.niobe.net> References: <20211007220702.5F9264C384E@eggemoggin.niobe.net> Message-ID: <20211015103518.381981556@eggemoggin.niobe.net> 2021/10/7 15:07:02 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 18: > > 408: Simple Web Server > https://openjdk.java.net/jeps/408 > > Summary: Provide a command-line tool to start a minimal web server > that serves static files in the current directory. This low-threshold > utility will be useful for prototyping, ad-hoc coding, and testing > purposes, particularly in educational contexts. > > 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, 14 October, 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 18. One objection to this JEP was raised by Simone Bordet (not a Committer), but it was satisfactorily answered. I?ve targeted this JEP to JDK 18. - Mark From alxegod at gmail.com Sat Oct 16 17:08:27 2021 From: alxegod at gmail.com (Alejandro) Date: Sat, 16 Oct 2021 19:08:27 +0200 Subject: Some observations on JEP draft of Templated Strings and Policies Message-ID: Hello, For some context, I am a simple fan of Java, as I don't even use it on my daily job, and have just recently started being an observer of it's development. Now, while browsing Reddit's r/java, I saw that JDK-8273943, Templated Strings and Template Policies (Preview), had been updated. I previously knew about the feature from, possibly, some posts in either GitHub or inside.java, but didn't know as many details until I read the JEP draft. Overall, I like the additions quite a lot and want to congratulate everyone's effort, but I had one observation, in particular with the usage of java.util.List. Let me quote the observations I posted on the Reddit thread: > I don't like the idea of TemplatedString having a dependency on java.util.List, as it means that the latter would now be hard-coded into the language. > A more sensible solution would be any java.lang.Iterable, which is already hard-coded into the language due to it's usage in for-each loops. > This one, as oposed to java.util.List is a very simple and concise interface. > > From an implementor's point of view, they could continue using List::of. > From a consumer's point of view, they could still make use of for-each loops, or construct a List easily, e.g. ts.values().forEach(myList::add). I am pretty sure that you've considered or discussed this topic before, but nonetheless I wanted to bring this into the mailing list. My reasoning is so that I can be directed to some past discussion on this, or to bring up the discussion if it hadn't popped up before. As for current reasoning, I think this is to possibly have "mutable" TemplatedStrings, such as replacing one element of values(), but this is just an idea and doesn't align with the current example in the JEP. Best Regards, Alejandro From forax at univ-mlv.fr Sat Oct 16 22:57:51 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 17 Oct 2021 00:57:51 +0200 (CEST) Subject: Some observations on JEP draft of Templated Strings and Policies In-Reply-To: References: Message-ID: <2037412361.2893611.1634425071104.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Alejandro" > To: "jdk-dev" > Sent: Samedi 16 Octobre 2021 19:08:27 > Subject: Some observations on JEP draft of Templated Strings and Policies > Hello, > Hi, > For some context, I am a simple fan of Java, as I don't even use it on > my daily job, and have just recently started being an observer of it's > development. > > Now, while browsing Reddit's r/java, I saw that JDK-8273943, Templated > Strings and Template Policies (Preview), had been updated. > I previously knew about the feature from, possibly, some posts in > either GitHub or inside.java, but didn't know as many details until I > read the JEP draft. > > Overall, I like the additions quite a lot and want to congratulate > everyone's effort, but I had one observation, in particular with the > usage of java.util.List. > Let me quote the observations I posted on the Reddit thread: > >> I don't like the idea of TemplatedString having a dependency on java.util.List, >> as it means that the latter would now be hard-coded into the language. >> A more sensible solution would be any java.lang.Iterable, which is already >> hard-coded into the language due to it's usage in for-each loops. >> This one, as oposed to java.util.List is a very simple and concise interface. >> >> From an implementor's point of view, they could continue using List::of. >> From a consumer's point of view, they could still make use of for-each loops, or >> construct a List easily, e.g. ts.values().forEach(myList::add). > > I am pretty sure that you've considered or discussed this topic > before, but nonetheless I wanted to bring this into the mailing list. > My reasoning is so that I can be directed to some past discussion on > this, or to bring up the discussion if it hadn't popped up before. This API is still in flux :) Yes, it will be new for a class of java.lang to have an API dependency on java.util.List. java.lang.String or java.lang.Throwable already have an implementation dependency (not an API dependency) on java.util.List and java.lang.invoke.MethodType has an API dependency on java.util.List. So i'm not sure there is a sacred line drawn in the sand since we have modules and java.lang and java.util are both inside the module java.base When you write a template policy, you usually want to be able to rapidly checks if the number of arguments and the number of holes match. There is not size() on Iterable. We can use an array instead, but it means a bunch of defensive copies will fly around. Another solution is to not expose TemplatedString in the language and only be able to access it when you write a template policy, in that case, TemplatedString can be moved into another package like java.lang.runtime. [...] > > Best Regards, > Alejandro regards, R?mi From attila.kelemen85 at gmail.com Tue Oct 19 17:26:54 2021 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Tue, 19 Oct 2021 19:26:54 +0200 Subject: HttpServer API input validation issue Message-ID: Hi, I was looking at the code of the new HttpServer API, and stumbled across the BasicAuthenticator class. As is currently, the "realm" field is neither validated, nor escaped before being put into the http header. I know that the risk that this will end up as a security problem is low (especially since this API is not supposed to be used in production), but I believe it would be best if this is addressed before release. Regards, Attila Kelemen From daniel.fuchs at oracle.com Tue Oct 19 18:14:22 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Oct 2021 19:14:22 +0100 Subject: HttpServer API input validation issue In-Reply-To: References: Message-ID: <08ef7f6e-49fb-71ac-5759-ee4376164310@oracle.com> Hi Attila, Right - thanks. If realm contains a double quote that quote should probably be quoted. This is a functional bug. BasicAuthenticator has been in the JDK since JDK 6. I have logged https://bugs.openjdk.java.net/browse/JDK-8275534 best regards, -- daniel On 19/10/2021 18:26, Attila Kelemen wrote: > Hi, > > I was looking at the code of the new HttpServer API, and stumbled across > the BasicAuthenticator class. As is currently, the "realm" field is neither > validated, nor escaped before being put into the http header. I know that > the risk that this will end up as a security problem is low (especially > since this API is not supposed to be used in production), but I believe it > would be best if this is addressed before release. > > Regards, > Attila Kelemen > From mark.reinhold at oracle.com Tue Oct 19 18:51:24 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 19 Oct 2021 11:51:24 -0700 (PDT) Subject: JEP proposed to target JDK 18: 416: Reimplement Core Reflection with Method Handles Message-ID: <20211019185124.B51244C4E26@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 416: Reimplement Core Reflection with Method Handles https://openjdk.java.net/jeps/416 Summary: Reimplement java.lang.reflect.Method, Constructor, and Field on top of java.lang.invoke method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the java.lang.reflect and java.lang.invoke APIs. 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 Tuesday, 26 October, 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 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Tue Oct 19 19:10:31 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 19 Oct 2021 12:10:31 -0700 (PDT) Subject: New candidate JEP: 420: Pattern Matching for switch (Second Preview) Message-ID: <20211019191031.41E414C4E31@eggemoggin.niobe.net> https://openjdk.java.net/jeps/420 Summary: Enhance the Java programming language with pattern matching for switch expressions and statements, along with extensions to the language of patterns. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely. - Mark From stuart.marks at oracle.com Wed Oct 20 23:06:48 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 20 Oct 2021 16:06:48 -0700 Subject: Some observations on JEP draft of Templated Strings and Policies In-Reply-To: <2037412361.2893611.1634425071104.JavaMail.zimbra@u-pem.fr> References: <2037412361.2893611.1634425071104.JavaMail.zimbra@u-pem.fr> Message-ID: <4be53ab0-22f0-6a8f-85fc-e4a249d38aa9@oracle.com> > I don't like the idea of TemplatedString having a dependency on java.util.List, as it means that the latter would now be hard-coded into the language. > A more sensible solution would be any java.lang.Iterable, which is already hard-coded into the language due to it's usage in for-each loops. > This one, as oposed to java.util.List is a very simple and concise interface. > Yes, it will be new for a class of java.lang to have an API dependency on java.util.List. > > java.lang.String or java.lang.Throwable already have an implementation dependency (not an API dependency) on java.util.List and java.lang.invoke.MethodType has an API dependency on java.util.List. So i'm not sure there is a sacred line drawn in the sand since we have modules and java.lang and java.util are both inside the module java.base There are several things in java.lang that already use java.util.List, and many more in "sub-packages" java.lang.constant, java.lang.invoke, java.lang.management, and java.lang.module. See https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/class-use/List.html#java.lang A few uses of Collection, Set, and Map have also crept in. But it turns out that we crossed this bridge a long time ago; System::getenv has returned a Map since JDK 1.5: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#getenv() That said, we do want to keep the language at "arm's length" from the collection libraries. We don't want to have a system where everything can depend on everything else. (That was sort-of the case prior to Java 9. Much of the groundwork for modularizing the JDK was breaking these dependencies.) Unfortunately the Java language (separate from the library) has only two means of expressing aggregations: arrays and classes. Arrays have the unfortunate property of being mutable. If you look at the values() method of any enum, for example, they all return arrays. This is sort-of ok from an API standpoint, but since arrays are mutable, it requires every call to the values() method to make a defensive copy. As a result, every library that wants to iterate an enum gets the values() array once and caches it. To avoid issues like this, TemplatedString might create a bespoke class within java.lang (possibly a nested class) to represent its values and segments. But to be usable, this class would need to have convertors to and from collections, and it would have to have methods to access elements, etc. At a certain point, one would ask, "Why isn't this just a List?" It's true that Iterable is a simple and concise interface, and it's already a dependency of the language on the library. But it's underpowered: the only thing you can do is iterate it. For this reason, from time to time there are proposals to add various operations to Iterable. But these end up with a half-complete version of Collection, when what you really want is Collection. (Or possibly List.) Finally, if we admit to ourselves that LinkedList is an outlier, the main useful implementations of List are actually wrappers around arrays. And it turns out that a List is a pretty decent way to represent a read-only array. s'marks From joe.darcy at oracle.com Wed Oct 20 23:15:08 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 20 Oct 2021 16:15:08 -0700 Subject: FYI, augmented javac -Xlint:serial checks coming soon to JDK 18 Message-ID: <23a4196a-708a-c269-37b3-9420003ba6d7@oracle.com> Hello, At present, the -Xlint:serial checks done by javac check that a serializable class has a serialVersionUID field and that the field is properly declared, with type long and modifiers static and final, etc. Besides serialVersionUID, the serialization mechanism recognizes and can also use one other field (serialPersistentFields) and five methods (writeObject, writeReplace, readObject, readObjectNoData, and readResolve). These other entities need to be declared properly to be used by serialization as well, but -Xlint:serial does no checks on them. Changes currently out for review [1] will augment javac's -Xlint:serial checking to cover the other field and five methods, along with related changes. The overall objective of the expanded serial checks is to warn for cases where declarations would cause the runtime serialization mechanism to silently ignore a mis-declared entity, rendering it ineffectual. Also, the checks include several compile-time patterns that could lead to runtime failures. One of those patterns concerns the types of instance fields of serializable classes. In summary, if a non-transient instance field of a serializable class is declared to have a non-serializable type, it may indicate a problem since a serialization attempt could fail at runtime. Since enum classes and record classes have specialized serialization handling, those kinds of classes have customized lint checks compared to general classes. The details of the checks are given in a pair of CSRs. [2] The JDK build enables the serial lint check, among other lint checks, so to keep the build working with the warning enabled, the code in the JDK must pass the new checks no later than when the augmented checks are integrated. The recent subtasks of JDK-8231641 have been updating the JDK libraries to comply with the checks for fields with non-serializable types in serializable classes. Previous passes over serialization-related declarations in the JDK had identified and addressed the other categories of warnings (JDK-8207751, JDK-8207816, JDK-8203263, JDK-8208060, JDK- 8208782 , ?) and no other instances of those were introduced in the interim. As with the existing serial warnings, the new warnings can be suppressed using a @SuppressWarnings("serial") annotation. Cheers, -Joe [1] https://github.com/openjdk/jdk/pull/5709 [2] https://bugs.openjdk.java.net/browse/JDK-8274335 https://bugs.openjdk.java.net/browse/JDK-8274336 From coleen.phillimore at oracle.com Thu Oct 21 20:17:40 2021 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 21 Oct 2021 16:17:40 -0400 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo Message-ID: I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. Votes are due by 4:30PM ET on Thursday, November 4th, 2021. Only current OpenJDK Reviewers (and above) [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]. Thanks! Coleen Phillimore [0] https://openjdk.java.net/census#pchilanomate [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#reviewer-vote From erik.osterlund at oracle.com Thu Oct 21 20:19:51 2021 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 21 Oct 2021 20:19:51 +0000 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes /Erik > On 21 Oct 2021, at 22:17, coleen.phillimore at oracle.com wrote: > > ?I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From harold.seigel at oracle.com Thu Oct 21 20:23:58 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 21 Oct 2021 16:23:58 -0400 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <1e0e46bb-cd52-2576-c898-04387e2fcf64@oracle.com> Vote: YES Harold On 10/21/2021 4:17 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help > and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From jesper.wilhelmsson at oracle.com Thu Oct 21 20:24:48 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Oct 2021 20:24:48 +0000 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: Yes /Jesper > 21 okt. 2021 kl. 22:17 skrev coleen.phillimore at oracle.com: > > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From martin.doerr at sap.com Thu Oct 21 20:27:19 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 21 Oct 2021 20:27:19 +0000 Subject: AW: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes /Martin Von: jdk-dev im Auftrag von coleen.phillimore at oracle.com Datum: Donnerstag, 21. Oktober 2021 um 22:18 An: jdk-dev at openjdk.java.net Betreff: CFV: New JDK Reviewer: Patricio Chilano Mateo I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. Votes are due by 4:30PM ET on Thursday, November 4th, 2021. Only current OpenJDK Reviewers (and above) [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]. Thanks! Coleen Phillimore [0] https://openjdk.java.net/census#pchilanomate [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#reviewer-vote From coleen.phillimore at oracle.com Thu Oct 21 20:31:47 2021 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 21 Oct 2021 16:31:47 -0400 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <8e568bf9-210d-cfcc-3f16-4266b18ed9da@oracle.com> Vote: yes On 10/21/21 4:17 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help > and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From zgu at redhat.com Thu Oct 21 20:35:47 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 21 Oct 2021 16:35:47 -0400 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <634de1ff-aa8d-4e04-e42f-1c551fdc46ff@redhat.com> Vote: yes -Zhengyu On 10/21/21 16:17, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help and > expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote > From calvin.cheung at oracle.com Thu Oct 21 21:01:31 2021 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Thu, 21 Oct 2021 14:01:31 -0700 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <4e2d69b0-2fec-49d7-60e6-91231976cbe4@oracle.com> Vote: yes On 10/21/21 1:17 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help > and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From mikael.vidstedt at oracle.com Thu Oct 21 21:51:57 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 21 Oct 2021 21:51:57 +0000 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes (Assuming this is for the ?JDK? project) Cheers, Mikael > On Oct 21, 2021, at 1:17 PM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From erik.gahlin at oracle.com Thu Oct 21 22:34:05 2021 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 21 Oct 2021 22:34:05 +0000 Subject: New JDK Reviewer: Patricio Chilano Mateo Message-ID: Vote: yes Erik ?On 10/21/21, 10:17 PM, "jdk-dev on behalf of coleen.phillimore at oracle.com" wrote: I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. Votes are due by 4:30PM ET on Thursday, November 4th, 2021. Only current OpenJDK Reviewers (and above) [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]. Thanks! Coleen Phillimore [0] https://openjdk.java.net/census#pchilanomate [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#reviewer-vote From Alan.Bateman at oracle.com Fri Oct 22 06:23:12 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Oct 2021 07:23:12 +0100 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <90a4ed64-75d8-1525-d7ce-92590a93b99f@oracle.com> Vote: yes From stefan.karlsson at oracle.com Fri Oct 22 08:17:13 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 22 Oct 2021 10:17:13 +0200 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <458cafd0-c00c-a7cb-a2ff-c20703032832@oracle.com> Vote: yes StefanK On 2021-10-21 22:17, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help > and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From adinn at redhat.com Fri Oct 22 09:07:39 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 22 Oct 2021 10:07:39 +0100 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <928698f5-53ba-df96-4592-a136c36da567@redhat.com> Vote: yes On 21/10/2021 21:17, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help and > expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] 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 thomas.stuefe at gmail.com Fri Oct 22 09:15:19 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 22 Oct 2021 11:15:19 +0200 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes On Thu, Oct 21, 2021 at 10:18 PM wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help and > expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote > From markus.gronlund at oracle.com Fri Oct 22 09:45:36 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 22 Oct 2021 09:45:36 +0000 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes Thanks Markus -----Original Message----- From: jdk-dev On Behalf Of coleen.phillimore at oracle.com Sent: den 21 oktober 2021 22:18 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. Votes are due by 4:30PM ET on Thursday, November 4th, 2021. Only current OpenJDK Reviewers (and above) [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]. Thanks! Coleen Phillimore [0] https://openjdk.java.net/census#pchilanomate [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#reviewer-vote From lois.foltan at oracle.com Fri Oct 22 12:07:25 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 22 Oct 2021 08:07:25 -0400 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes Lois On 10/21/2021 4:17 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help > and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From roger.riggs at oracle.com Fri Oct 22 14:05:35 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 22 Oct 2021 10:05:35 -0400 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: Yes On 10/21/21 4:17 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. From richard.reingruber at sap.com Fri Oct 22 14:37:03 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 22 Oct 2021 14:37:03 +0000 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes Richard. -----Original Message----- From: jdk-dev On Behalf Of coleen.phillimore at oracle.com Sent: Donnerstag, 21. Oktober 2021 22:18 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. Votes are due by 4:30PM ET on Thursday, November 4th, 2021. Only current OpenJDK Reviewers (and above) [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]. Thanks! Coleen Phillimore [0] https://openjdk.java.net/census#pchilanomate [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#reviewer-vote From mandy.chung at oracle.com Fri Oct 22 16:11:07 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Oct 2021 09:11:07 -0700 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <7cdb696e-b44f-86d4-503d-e2d3663bbacf@oracle.com> Vote: yes Mandy On 10/21/21 1:17 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help > and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From jincheng at ca.ibm.com Fri Oct 22 20:59:07 2021 From: jincheng at ca.ibm.com (Cheng Jin) Date: Fri, 22 Oct 2021 16:59:07 -0400 Subject: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java Message-ID: Hi there, The code in compile(InputSource input, String name) at https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java seems incorrect as follows: public boolean compile(InputSource input, String name) { try { // Reset globals in case we're called by compile(ArrayList v); reset(); // The systemId may not be set, so we'll have to check the URL String systemId = null; if (input != null) { systemId = input.getSystemId(); } // Set the translet class name if not already set if (_className == null) { if (name != null) { setClassName(name); } else if (systemId != null && !systemId.equals("")) { setClassName(Util.baseName(systemId)); <------- incorrect here } // Ensure we have a non-empty class name at this point if (_className == null || _className.length() == 0) { setClassName("GregorSamsa"); // default translet name } } ... Specifically, the code above assumes that systemId is something like "xxx:yyyy" in which case the class name (_className) is "die.verwandlung.yyy" ("die.verwandlung." is the default package name since Java11) However,Util.baseName(systemId) returns null when systemId is something like "xxx:" (empty after ":"), in which case the class name (_className) ends up with "die.verwandlung." (an invalid class name inserted in the constant pool of the generated bytecode). In terms of robustness, the code above should be updated to handle the situation. e.g. else if (systemId != null && !systemId.equals("")) { String baseName = Util.baseName(systemId); if ((baseName != null) && (baseName.length() > 0)) { <------ setClassName(baseName); } which means it should check whether the returned base name from Util.baseName(systemId) is empty at first before setting the class name; otherwise, it should use the default class name ("GregorSamsa"). Let me know if any other concern on this fix. Thanks and Best Regards Cheng Jin jincheng at ca.ibm.com From Alan.Bateman at oracle.com Sat Oct 23 06:17:40 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Oct 2021 07:17:40 +0100 Subject: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java In-Reply-To: References: Message-ID: On 22/10/2021 21:59, Cheng Jin wrote: > > Hi there, > > The code in compile(InputSource input, String name) at > https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java > seems incorrect as follows: > > public boolean compile(InputSource input, String name) { > try { > // Reset globals in case we're called by compile(ArrayList v); > reset(); > > // The systemId may not be set, so we'll have to check the URL > String systemId = null; > if (input != null) { > systemId = input.getSystemId(); > } > > // Set the translet class name if not already set > if (_className == null) { > if (name != null) { > setClassName(name); > } > else if (systemId != null && !systemId.equals("")) { > setClassName(Util.baseName(systemId)); <------- > incorrect here > } > > // Ensure we have a non-empty class name at this point > if (_className == null || _className.length() == 0) { > setClassName("GregorSamsa"); // default translet name > } > } > ... > > Specifically, the code above assumes that systemId is something like > "xxx:yyyy" in which case the class name (_className) is > "die.verwandlung.yyy" ("die.verwandlung." is the default package name since > Java11) However,Util.baseName(systemId) returns null when systemId is > something like "xxx:" (empty after ":"), in which case the class name > (_className) ends up with "die.verwandlung." (an invalid class name > inserted in the constant pool of the generated bytecode). Can you bring this to the core-libs-dev mailing list? This is where XML issues and issues with the XSLT compiler are usually discussed/reviewed. -Alan. From jincheng at ca.ibm.com Sat Oct 23 14:52:25 2021 From: jincheng at ca.ibm.com (Cheng Jin) Date: Sat, 23 Oct 2021 10:52:25 -0400 Subject: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java In-Reply-To: References: Message-ID: Many thanks for reminder. Will bring this up in there. Thanks and Best Regards Cheng Jin jincheng at ca.ibm.com From: "Alan Bateman" To: "Cheng Jin" , jdk-dev at openjdk.java.net Date: 2021-10-23 02:17 AM Subject: [EXTERNAL] Re: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java On 22/10/2021 21:59, Cheng Jin wrote: > > Hi there, > > The code in compile(InputSource input, String name) at > https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java > seems incorrect as follows: > > public boolean compile(InputSource input, String name) { > try { > // Reset globals in case we're called by compile(ArrayList v); > reset(); > > // The systemId may not be set, so we'll have to check the URL > String systemId = null; > if (input != null) { > systemId = input.getSystemId(); > } > > // Set the translet class name if not already set > if (_className == null) { > if (name != null) { > setClassName(name); > } > else if (systemId != null && !systemId.equals("")) { > setClassName(Util.baseName(systemId)); <------- > incorrect here > } > > // Ensure we have a non-empty class name at this point > if (_className == null || _className.length() == 0) { > setClassName("GregorSamsa"); // default translet name > } > } > ... > > Specifically, the code above assumes that systemId is something like > "xxx:yyyy" in which case the class name (_className) is > "die.verwandlung.yyy" ("die.verwandlung." is the default package name since > Java11) However,Util.baseName(systemId) returns null when systemId is > something like "xxx:" (empty after ":"), in which case the class name > (_className) ends up with "die.verwandlung." (an invalid class name > inserted in the constant pool of the generated bytecode). Can you bring this to the core-libs-dev mailing list? This is where XML issues and issues with the XSLT compiler are usually discussed/reviewed. -Alan. From jianglizhou at google.com Sun Oct 24 03:46:24 2021 From: jianglizhou at google.com (Jiangli Zhou) Date: Sat, 23 Oct 2021 20:46:24 -0700 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: <7cdb696e-b44f-86d4-503d-e2d3663bbacf@oracle.com> References: <7cdb696e-b44f-86d4-503d-e2d3663bbacf@oracle.com> Message-ID: Vote: yes Best, Jiangli On Fri, Oct 22, 2021 at 9:11 AM Mandy Chung wrote: > > Vote: yes > > Mandy > > On 10/21/21 1:17 PM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > > > Patricio is currently a JDK Committer and a member of the Oracle JVM > > Runtime team. He has 56 commits[1], mainly in the areas of locking, > > safepoint synchronization, thread state transition, and handshakes. He > > works closely with other members of the runtime team to provide help > > and expertise in these areas. > > > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > > > Only current OpenJDK Reviewers (and above) [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]. > > > > Thanks! > > > > Coleen Phillimore > > > > [0] https://openjdk.java.net/census#pchilanomate > > [1] > > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > > > [2] https://openjdk.java.net/census#jdk > > [3] http://openjdk.java.net/projects/#reviewer-vote From david.holmes at oracle.com Sun Oct 24 13:19:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Oct 2021 23:19:02 +1000 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes David On 22/10/2021 6:17 am, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help and > expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From kim.barrett at oracle.com Sun Oct 24 23:45:21 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 24 Oct 2021 23:45:21 +0000 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <90A8FE4C-FB0B-4A90-ACDE-A904E5B4A7AC@oracle.com> vote: yes > On Oct 21, 2021, at 4:17 PM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From per.liden at oracle.com Mon Oct 25 09:49:26 2021 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Oct 2021 11:49:26 +0200 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes /Per On 10/21/21 22:17, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help and > expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From leo.korinth at oracle.com Mon Oct 25 15:51:58 2021 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 25 Oct 2021 17:51:58 +0200 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: Vote: yes /Leo On 21/10/2021 22:17, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help and > expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From lutz.schmidt at sap.com Mon Oct 25 19:53:59 2021 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 25 Oct 2021 19:53:59 +0000 Subject: New JDK Reviewer: Patricio Chilano Mateo Message-ID: <0350D7A0-F187-42E0-8B3C-969B48F99A3D@sap.com> Vote: Yes. Best, Lutz ?On 21.10.21, 22:17, "jdk-dev on behalf of coleen.phillimore at oracle.com" wrote: I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. Patricio is currently a JDK Committer and a member of the Oracle JVM Runtime team. He has 56 commits[1], mainly in the areas of locking, safepoint synchronization, thread state transition, and handshakes. He works closely with other members of the runtime team to provide help and expertise in these areas. Votes are due by 4:30PM ET on Thursday, November 4th, 2021. Only current OpenJDK Reviewers (and above) [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]. Thanks! Coleen Phillimore [0] https://openjdk.java.net/census#pchilanomate [1] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits [2] https://openjdk.java.net/census#jdk [3] http://openjdk.java.net/projects/#reviewer-vote From daniel.daugherty at oracle.com Mon Oct 25 20:02:28 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 25 Oct 2021 16:02:28 -0400 Subject: CFV: New JDK Reviewer: Patricio Chilano Mateo In-Reply-To: References: Message-ID: <81ebaf35-3484-0896-a98c-6111433cdb20@oracle.com> Vote: yes Dan On 10/21/21 4:17 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Patricio Chilano Mateo [0] to OpenJDK Reviewer. > > Patricio is currently a JDK Committer and a member of the Oracle JVM > Runtime team. He has 56 commits[1], mainly in the areas of locking, > safepoint synchronization, thread state transition, and handshakes. He > works closely with other members of the runtime team to provide help > and expertise in these areas. > > Votes are due by 4:30PM ET on Thursday, November 4th, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Thanks! > > Coleen Phillimore > > [0] https://openjdk.java.net/census#pchilanomate > [1] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Patricio+Chilano+Mateo%22&type=commits > > [2] https://openjdk.java.net/census#jdk > [3] http://openjdk.java.net/projects/#reviewer-vote From mark.reinhold at oracle.com Thu Oct 28 18:13:57 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 28 Oct 2021 11:13:57 -0700 Subject: JEP proposed to target JDK 18: 416: Reimplement Core Reflection with Method Handles In-Reply-To: <20211019185124.B51244C4E26@eggemoggin.niobe.net> References: <20211019185124.B51244C4E26@eggemoggin.niobe.net> Message-ID: <20211028111357.525608692@eggemoggin.niobe.net> 2021/10/19 11:51:24 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 18: > > 416: Reimplement Core Reflection with Method Handles > https://openjdk.java.net/jeps/416 > > Summary: Reimplement java.lang.reflect.Method, Constructor, and Field > on top of java.lang.invoke method handles. Making method handles the > underlying mechanism for reflection will reduce the maintenance and > development cost of both the java.lang.reflect and java.lang.invoke > APIs. > > 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 Tuesday, 26 October, 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 18. Hearing no objections, I?ve targeted this JEP to JDK 18. - Mark From mark.reinhold at oracle.com Thu Oct 28 20:44:45 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 28 Oct 2021 13:44:45 -0700 (PDT) Subject: JEP proposed to target JDK 18: 418: Internet-Address Resolution SPI Message-ID: <20211028204445.CADA14C5BDF@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 418: Internet-Address Resolution SPI https://openjdk.java.net/jeps/418 Summary: Define a service-provider interface (SPI) for host name and address resolution, so that java.net.InetAddress can make use of resolvers other than the platform's built-in resolver. 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, 4 November, 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 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html