From gavin.bierman at oracle.com Tue Sep 3 14:50:43 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 3 Sep 2024 14:50:43 +0000 Subject: Project Amber: Draft JEPs for JDK 24 Message-ID: <268AC9C7-B466-455D-A44D-53E5C0B5D2CB@oracle.com> Dear all, I have prepared draft JEPs for the following features from Project Amber that we propose to preview in JDK 24: - Flexible Constructor Bodies (Third Preview) https://openjdk.org/jeps/8338287 - Implicitly Declared Classes and Instance Main Methods (Fourth Preview) https://openjdk.org/jeps/8335984 - Module Import Declarations (Second Preview) https://openjdk.org/jeps/8335987 I emphasise that these are all drafts, but please send any feedback/comments to this list or direct to me. Many thanks, Gavin PS: Aggelos has already announced the draft JEP for a further Project Amber feature: Primitive Types in Patterns, instanceof, and switch (Second Preview) https://openjdk.org/jeps/8335876 From archie.cobbs at gmail.com Tue Sep 10 23:23:15 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 10 Sep 2024 18:23:15 -0500 Subject: JDK-8300691 - final variables in for loop headers should accept updates Message-ID: I'm curious about this possible future language tweak and have been looking at it more closely: https://bugs.openjdk.org/browse/JDK-8300691 I think this would be a nice practical change that fits well within the Amber ambit. However, I'm stuck on one question. To summarize, there are two independent changes being proposed: 1. Prevent statements in for() loop steps from causing for() loop variables to lose their "effectively final" status 2. Allow final for() loop variables to be mutated in the for() step (but not the for() body) Change #1 would allow code like this: for (int i = 0; i < 10; i++) { Runnable r = () -> System.out.println(i); // hooray, "i" is effectively final } Change #2 would allow code like this: for (final int i = 0; i < 10; i++) { System.out.println(i); // we can rest assured "i" can't change in here } Change #1 is straightforward but Change #2 raises an issue. A final initialized variable is not only immutable but also can be a constant expression, and this affects reachability analysis. For example, these two examples do not compile: final int x = 0; while (x != 0) System.out.println(x); // error: unreachable statement System.out.println("done"); final int x = 0; while (x == 0) System.out.println(x); System.out.println("done"); // error: unreachable statement We shouldn't expect the equivalent for() statements to compile either, and in fact today they don't: for (final int x = 0; x != 0; ) System.out.println(x); // error: unreachable statement System.out.println("done"); for (final int x = 0; x == 0; ) System.out.println(x); System.out.println("done"); // error: unreachable statement But now suppose we add a step, which Change #2 would newly allow: for (final int x = 0; x != 0; x++) System.out.println(x); // error: unreachable statement... ? System.out.println("done"); for (final int x = 0; x == 0; x++) System.out.println(x); System.out.println("done"); // NOT an unreachable statement In the first example, the inner statement is still unreachable, so it's OK for the compiler to still report that error, but in the second example, the final statement is now obviously reachable, so the compiler must do something different. Moreover it would be doing something different based on inspection of the step for mutations to "x", which seems like "spooky action at a distance" and could be spec-challenging. Alternatively, the compiler could change its behavior to never consider final loop variables as constant expressions, but this could break existing code. Of course, if Change #2 had too many issues, Change #1 would still be useful on its own. Thoughts? Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Wed Sep 11 04:22:27 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 11 Sep 2024 06:22:27 +0200 Subject: JDK-8300691 - final variables in for loop headers should accept updates In-Reply-To: References: Message-ID: Hello! I think that both changes would be extremely confusing. What Java really needs is ranges as first-class citizens. In this case, nobody would need ugly and error-prone classic for loop, and the problem will go away. Instead for(int i=0; i<10; i++) people will use enhanced for syntax: for(int i: 0..9) or something like this. In fact, even today one can easily declare a static method like range(from, to) which returns an Iterable, and modern C2 eliminates boxing quite efficiently in this case. So probably we should simply write our code this way? for(int i: range(0, 10)) Tagir. On Wed, Sep 11, 2024, 03:16 Archie Cobbs wrote: > I'm curious about this possible future language tweak and have been > looking at it more closely: https://bugs.openjdk.org/browse/JDK-8300691 > > I think this would be a nice practical change that fits well within the > Amber ambit. However, I'm stuck on one question. > > To summarize, there are two independent changes being proposed: > > 1. Prevent statements in for() loop steps from causing for() loop > variables to lose their "effectively final" status > 2. Allow final for() loop variables to be mutated in the for() step > (but not the for() body) > > Change #1 would allow code like this: > > for (int i = 0; i < 10; i++) { > Runnable r = () -> System.out.println(i); // hooray, "i" is > effectively final > } > > Change #2 would allow code like this: > > for (final int i = 0; i < 10; i++) { > System.out.println(i); // we can rest assured "i" can't > change in here > } > > Change #1 is straightforward but Change #2 raises an issue. A final > initialized variable is not only immutable but also can be a constant > expression, and this affects reachability analysis. > > For example, these two examples do not compile: > > final int x = 0; > while (x != 0) > System.out.println(x); // error: unreachable statement > System.out.println("done"); > > final int x = 0; > while (x == 0) > System.out.println(x); > System.out.println("done"); // error: unreachable statement > > We shouldn't expect the equivalent for() statements to compile either, and > in fact today they don't: > > for (final int x = 0; x != 0; ) > System.out.println(x); // error: unreachable statement > System.out.println("done"); > > for (final int x = 0; x == 0; ) > System.out.println(x); > System.out.println("done"); // error: unreachable statement > > But now suppose we add a step, which Change #2 would newly allow: > > for (final int x = 0; x != 0; x++) > System.out.println(x); // error: unreachable statement... ? > System.out.println("done"); > > for (final int x = 0; x == 0; x++) > System.out.println(x); > System.out.println("done"); // NOT an unreachable statement > > In the first example, the inner statement is still unreachable, so it's OK > for the compiler to still report that error, but in the second example, the > final statement is now obviously reachable, so the compiler must do > something different. Moreover it would be doing something different based > on inspection of the step for mutations to "x", which seems like "spooky > action at a distance" and could be spec-challenging. > > Alternatively, the compiler could change its behavior to never consider > final loop variables as constant expressions, but this could break existing > code. > > Of course, if Change #2 had too many issues, Change #1 would still be > useful on its own. > > Thoughts? > > Thanks, > -Archie > > -- > Archie L. Cobbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbepincket at live.be Wed Sep 11 05:09:10 2024 From: robbepincket at live.be (Robbe Pincket) Date: Wed, 11 Sep 2024 05:09:10 +0000 Subject: JDK-8300691 - final variables in for loop headers should accept updates In-Reply-To: References: Message-ID: Hi Reading the proposal, it seems John is suggesting to use a translation step, so for (final int x = 0; x != 0; x++) System.out.println(x); System.out.println("done"); Would turn into for (int x$synthetic = 0; x$synthetic != 0; x$synthetic++) { final int x = x$synthetic; System.out.println(x); } System.out.println("done"); Which solves your issue. However, it doesn't feel like the extra variable is needed? If we just add a clause in 4.12.4 that says that if the variable is declared in a for loop header and appears as the left side of an assignment or compound assignment or as the argument of a postfix/prefix increment/decrement operator, it isn't considered to be a constant variable. I don't think that this breaks any existing code. As (non-blank) final variables can't appear in those locations. Greetings Robbe Pincket Sent from Outlook for Android ________________________________ From: amber-dev on behalf of Archie Cobbs Sent: Wednesday, September 11, 2024 1:23:15 AM To: amber-dev Subject: JDK-8300691 - final variables in for loop headers should accept updates I'm curious about this possible future language tweak and have been looking at it more closely: https://bugs.openjdk.org/browse/JDK-8300691 I think this would be a nice practical change that fits well within the Amber ambit. However, I'm stuck on one question. To summarize, there are two independent changes being proposed: 1. Prevent statements in for() loop steps from causing for() loop variables to lose their "effectively final" status 2. Allow final for() loop variables to be mutated in the for() step (but not the for() body) Change #1 would allow code like this: for (int i = 0; i < 10; i++) { Runnable r = () -> System.out.println(i); // hooray, "i" is effectively final } Change #2 would allow code like this: for (final int i = 0; i < 10; i++) { System.out.println(i); // we can rest assured "i" can't change in here } Change #1 is straightforward but Change #2 raises an issue. A final initialized variable is not only immutable but also can be a constant expression, and this affects reachability analysis. For example, these two examples do not compile: final int x = 0; while (x != 0) System.out.println(x); // error: unreachable statement System.out.println("done"); final int x = 0; while (x == 0) System.out.println(x); System.out.println("done"); // error: unreachable statement We shouldn't expect the equivalent for() statements to compile either, and in fact today they don't: for (final int x = 0; x != 0; ) System.out.println(x); // error: unreachable statement System.out.println("done"); for (final int x = 0; x == 0; ) System.out.println(x); System.out.println("done"); // error: unreachable statement But now suppose we add a step, which Change #2 would newly allow: for (final int x = 0; x != 0; x++) System.out.println(x); // error: unreachable statement... ? System.out.println("done"); for (final int x = 0; x == 0; x++) System.out.println(x); System.out.println("done"); // NOT an unreachable statement In the first example, the inner statement is still unreachable, so it's OK for the compiler to still report that error, but in the second example, the final statement is now obviously reachable, so the compiler must do something different. Moreover it would be doing something different based on inspection of the step for mutations to "x", which seems like "spooky action at a distance" and could be spec-challenging. Alternatively, the compiler could change its behavior to never consider final loop variables as constant expressions, but this could break existing code. Of course, if Change #2 had too many issues, Change #1 would still be useful on its own. Thoughts? Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Wed Sep 11 15:05:05 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 11 Sep 2024 10:05:05 -0500 Subject: JDK-8300691 - final variables in for loop headers should accept updates In-Reply-To: References: Message-ID: Hi Robbe, On Wed, Sep 11, 2024 at 12:09?AM Robbe Pincket wrote: > If we just add a clause in 4.12.4 that says that if the variable is > declared in a for loop header and appears as the left side of an assignment > or compound assignment or as the argument of a postfix/prefix > increment/decrement operator, it isn't considered to be a constant variable. > > I don't think that this breaks any existing code. As (non-blank) final > variables can't appear in those locations. > Agreed... that's what I'm calling the "spooky action at a distance" approach. Although it's less graceful from a spec point of view, practically speaking it's probably the only acceptable solution because the alternative would break existing code (in a very narrow corner case). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Thu Sep 12 22:29:37 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 12 Sep 2024 17:29:37 -0500 Subject: JDK-8300691 - final variables in for loop headers should accept updates In-Reply-To: References: Message-ID: FYI, I've created a draft PR prototyping this, using the "spooky action at a distance" approach. https://github.com/openjdk/jdk/pull/20976 -Archie On Wed, Sep 11, 2024 at 10:05?AM Archie Cobbs wrote: > Hi Robbe, > > On Wed, Sep 11, 2024 at 12:09?AM Robbe Pincket > wrote: > >> If we just add a clause in 4.12.4 that says that if the variable is >> declared in a for loop header and appears as the left side of an assignment >> or compound assignment or as the argument of a postfix/prefix >> increment/decrement operator, it isn't considered to be a constant variable. >> >> I don't think that this breaks any existing code. As (non-blank) final >> variables can't appear in those locations. >> > > Agreed... that's what I'm calling the "spooky action at a distance" > approach. > > Although it's less graceful from a spec point of view, practically > speaking it's probably the only acceptable solution because the alternative > would break existing code (in a very narrow corner case). > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From thihup at gmail.com Fri Sep 13 12:00:50 2024 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Fri, 13 Sep 2024 09:00:50 -0300 Subject: JEP 476: Clarification on Package Export Behavior in Java Modules Message-ID: Dear Amber Team, I hope you're doing well. I?ve encountered a behavior related to JEP 476: Module Import Declarations and wanted to ask for clarification. I?m working with a module setup where two packages are defined but not initially exported: module my.nice.project { //exports my.nice.project.pkg.a to my.nice.project; //exports my.nice.project.pkg.b to my.nice.project; } Here?s a simplified version of the code structure: package my.nice.project; import module my.nice.project; public class Main { public static void main(String[] args) { SomeInterface someInterface = new SomeInterface() { @Override public SomeRecord someMethod() { return new SomeRecord(); } }; } } package my.nice.project.pkg.a;import module my.nice.project; public interface SomeInterface { public SomeRecord someMethod(); } package my.nice.project.pkg.b;public record SomeRecord() {} When attempting to compile this code with the exports commented out, I received several "cannot find symbol" errors. However, after uncommenting the exports: exports my.nice.project.pkg.a to my.nice.project;exports my.nice.project.pkg.b to my.nice.project; The code compiled and ran as expected. Given this behavior, I wanted to confirm if this restriction on package visibility within a module is the intended design under the Amber project and the module system, or if there?s another approach or best practice I might be overlooking in terms of package exports. Thank you for your time and insight. Best regards, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Sep 13 15:41:46 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 13 Sep 2024 08:41:46 -0700 Subject: JEP 476: Clarification on Package Export Behavior in Java Modules In-Reply-To: References: Message-ID: I assume that the package my.nice.project is colocated with the other two packages -- my.nice.project.pkg.{a,b} -- in the module my.nice.project. If so, then all three packages should be able to access each others' public types (SomeInterface, SomeRecord) without error. The fact that you're getting an error looks like a javac bug. You don't need to `import module my.nice.project` in the source files of that module. Try removing those imports and see if my.nice.project.Main compiles (it should). Alex On 9/13/2024 5:00 AM, Thiago Henrique Hupner wrote: > Dear Amber Team, > > I hope you're doing well. I?ve encountered a behavior related to JEP > 476: Module Import Declarations and wanted to ask for clarification. > > I?m working with a module setup where two packages are defined but not > initially exported: > > |module my.nice.project { //exports my.nice.project.pkg.a to > my.nice.project; //exports my.nice.project.pkg.b to my.nice.project; } | > > Here?s a simplified version of the code structure: > > > |package my.nice.project; > | > | > |import module my.nice.project;| > > | > |public class Main { public static void main(String[] args) > { SomeInterface someInterface = new SomeInterface() { @Override public > SomeRecord someMethod() { return new SomeRecord(); } }; } }| > > | > | > |package my.nice.project.pkg.a; import module my.nice.project;| > | > | > |public interface SomeInterface { public SomeRecord someMethod(); }| > > |package my.nice.project.pkg.b; public record SomeRecord() {} | > > When attempting to compile this code with the exports commented out, I > received several "cannot find symbol" errors. However, after > uncommenting the exports: > > > |exports my.nice.project.pkg.a to my.nice.project; exports > my.nice.project.pkg.b to my.nice.project; | > > The code compiled and ran as expected. > > Given this behavior, I wanted to confirm if this restriction on package > visibility within a module is the intended design under the Amber > project and the module system, or if there?s another approach or best > practice I might be overlooking in terms of package exports. > > Thank you for your time and insight. > > Best regards, > > Thiago > From thihup at gmail.com Fri Sep 13 16:41:54 2024 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Fri, 13 Sep 2024 13:41:54 -0300 Subject: JEP 476: Clarification on Package Export Behavior in Java Modules In-Reply-To: References: Message-ID: Removing the imports still doesn't fix the errors. I've create a Github repo with the reproducer: https://github.com/Thihup/module-import-bug Best regards, Thiago Em sex., 13 de set. de 2024 ?s 12:41, Alex Buckley escreveu: > I assume that the package my.nice.project is colocated with the other > two packages -- my.nice.project.pkg.{a,b} -- in the module my.nice.project. > > If so, then all three packages should be able to access each others' > public types (SomeInterface, SomeRecord) without error. > > The fact that you're getting an error looks like a javac bug. > > You don't need to `import module my.nice.project` in the source files of > that module. Try removing those imports and see if my.nice.project.Main > compiles (it should). > > Alex > > On 9/13/2024 5:00 AM, Thiago Henrique Hupner wrote: > > Dear Amber Team, > > > > I hope you're doing well. I?ve encountered a behavior related to JEP > > 476: Module Import Declarations and wanted to ask for clarification. > > > > I?m working with a module setup where two packages are defined but not > > initially exported: > > > > |module my.nice.project { //exports my.nice.project.pkg.a to > > my.nice.project; //exports my.nice.project.pkg.b to my.nice.project; } | > > > > Here?s a simplified version of the code structure: > > > > > > |package my.nice.project; > > | > > | > > |import module my.nice.project;| > > > > | > > |public class Main { public static void main(String[] args) > > { SomeInterface someInterface = new SomeInterface() { @Override public > > SomeRecord someMethod() { return new SomeRecord(); } }; } }| > > > > | > > | > > |package my.nice.project.pkg.a; import module my.nice.project;| > > | > > | > > |public interface SomeInterface { public SomeRecord someMethod(); }| > > > > |package my.nice.project.pkg.b; public record SomeRecord() {} | > > > > When attempting to compile this code with the exports commented out, I > > received several "cannot find symbol" errors. However, after > > uncommenting the exports: > > > > > > |exports my.nice.project.pkg.a to my.nice.project; exports > > my.nice.project.pkg.b to my.nice.project; | > > > > The code compiled and ran as expected. > > > > Given this behavior, I wanted to confirm if this restriction on package > > visibility within a module is the intended design under the Amber > > project and the module system, or if there?s another approach or best > > practice I might be overlooking in terms of package exports. > > > > Thank you for your time and insight. > > > > Best regards, > > > > Thiago > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Sep 13 18:53:20 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 13 Sep 2024 11:53:20 -0700 Subject: [External] : Re: JEP 476: Clarification on Package Export Behavior in Java Modules In-Reply-To: References: Message-ID: <8c51c782-a8b2-4ec8-9238-f4ae0eb8345d@oracle.com> If removing the imports doesn't fix the errors, then I'm suspicious of your compiler setup. Please describe on this mailing list the commands you're using and the actual javac errors that you see. Alex On 9/13/2024 9:41 AM, Thiago Henrique Hupner wrote: > Removing the imports still doesn't fix the errors. > > I've create a Github repo with the reproducer: https://github.com/ > Thihup/module-import-bug > > Best regards, > > Thiago > > > Em sex., 13 de set. de 2024 ?s 12:41, Alex Buckley > > escreveu: > > I assume that the package my.nice.project is colocated with the other > two packages -- my.nice.project.pkg.{a,b} -- in the module > my.nice.project. > > If so, then all three packages should be able to access each others' > public types (SomeInterface, SomeRecord) without error. > > The fact that you're getting an error looks like a javac bug. > > You don't need to `import module my.nice.project` in the source > files of > that module. Try removing those imports and see if my.nice.project.Main > compiles (it should). > > Alex > > On 9/13/2024 5:00 AM, Thiago Henrique Hupner wrote: > > Dear Amber Team, > > > > I hope you're doing well. I?ve encountered a behavior related to JEP > > 476: Module Import Declarations and wanted to ask for clarification. > > > > I?m working with a module setup where two packages are defined > but not > > initially exported: > > > > |module my.nice.project { //exports my.nice.project.pkg.a to > > my.nice.project; //exports my.nice.project.pkg.b to > my.nice.project; } | > > > > Here?s a simplified version of the code structure: > > > > > > |package my.nice.project; > > | > > | > > |import module my.nice.project;| > > > > | > > |public class Main { public static void main(String[] args) > > { SomeInterface someInterface = new SomeInterface() { @Override > public > > SomeRecord someMethod() { return new SomeRecord(); } }; } }| > > > > | > > | > > |package my.nice.project.pkg.a; import module my.nice.project;| > > | > > | > > |public interface SomeInterface { public SomeRecord someMethod(); }| > > > > |package my.nice.project.pkg.b; public record SomeRecord() {} | > > > > When attempting to compile this code with the exports commented > out, I > > received several "cannot find symbol" errors. However, after > > uncommenting the exports: > > > > > > |exports my.nice.project.pkg.a to my.nice.project; exports > > my.nice.project.pkg.b to my.nice.project; | > > > > The code compiled and ran as expected. > > > > Given this behavior, I wanted to confirm if this restriction on > package > > visibility within a module is the intended design under the Amber > > project and the module system, or if there?s another approach or > best > > practice I might be overlooking in terms of package exports. > > > > Thank you for your time and insight. > > > > Best regards, > > > > Thiago > > > From thihup at gmail.com Fri Sep 13 19:28:27 2024 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Fri, 13 Sep 2024 16:28:27 -0300 Subject: [External] : Re: JEP 476: Clarification on Package Export Behavior in Java Modules In-Reply-To: <8c51c782-a8b2-4ec8-9238-f4ae0eb8345d@oracle.com> References: <8c51c782-a8b2-4ec8-9238-f4ae0eb8345d@oracle.com> Message-ID: Source structure: src | module-info.java \---my \---nice \---project | Main.java \---pkg +---a | SomeInterface.java \---b SomeRecord.java I've tried both commands with and without the module import and they both fail: java --enable-preview src/my/nice/project/Main.java javac --release 23 --enable-preview -d ./mod ./src/module-info.java ./src/my/nice/project/Main.java ./src/my/nice/project/pkg/a/SomeInterface.java ./src/my/nice/project/pkg/b/SomeRecord.java However, exporting a package to the my.nice.project module and including the module import both commands work. .\src\my\nice\project\pkg\a\SomeInterface.java:7: error: cannot find symbol public SomeRecord someMethod(); ^ symbol: class SomeRecord location: interface SomeInterface .\src\my\nice\project\Main.java:7: error: cannot find symbol SomeInterface someInterface = new SomeInterface() { ^ symbol: class SomeInterface location: class Main .\src\my\nice\project\Main.java:7: error: cannot find symbol SomeInterface someInterface = new SomeInterface() { ^ symbol: class SomeInterface location: class Main .\src\my\nice\project\Main.java:9: error: cannot find symbol public SomeRecord someMethod() { ^ symbol: class SomeRecord .\src\my\nice\project\Main.java:8: error: method does not override or implement a method from a supertype @Override ^ .\src\my\nice\project\Main.java:10: error: cannot find symbol return new SomeRecord(); ^ symbol: class SomeRecord 6 errors Best regards, Thiago Em sex., 13 de set. de 2024 ?s 15:53, Alex Buckley escreveu: > If removing the imports doesn't fix the errors, then I'm suspicious of > your compiler setup. > > Please describe on this mailing list the commands you're using and the > actual javac errors that you see. > > Alex > > On 9/13/2024 9:41 AM, Thiago Henrique Hupner wrote: > > Removing the imports still doesn't fix the errors. > > > > I've create a Github repo with the reproducer: https://github.com/ > > Thihup/module-import-bug > > > > Best regards, > > > > Thiago > > > > > > Em sex., 13 de set. de 2024 ?s 12:41, Alex Buckley > > > escreveu: > > > > I assume that the package my.nice.project is colocated with the other > > two packages -- my.nice.project.pkg.{a,b} -- in the module > > my.nice.project. > > > > If so, then all three packages should be able to access each others' > > public types (SomeInterface, SomeRecord) without error. > > > > The fact that you're getting an error looks like a javac bug. > > > > You don't need to `import module my.nice.project` in the source > > files of > > that module. Try removing those imports and see if > my.nice.project.Main > > compiles (it should). > > > > Alex > > > > On 9/13/2024 5:00 AM, Thiago Henrique Hupner wrote: > > > Dear Amber Team, > > > > > > I hope you're doing well. I?ve encountered a behavior related to > JEP > > > 476: Module Import Declarations and wanted to ask for > clarification. > > > > > > I?m working with a module setup where two packages are defined > > but not > > > initially exported: > > > > > > |module my.nice.project { //exports my.nice.project.pkg.a to > > > my.nice.project; //exports my.nice.project.pkg.b to > > my.nice.project; } | > > > > > > Here?s a simplified version of the code structure: > > > > > > > > > |package my.nice.project; > > > | > > > | > > > |import module my.nice.project;| > > > > > > | > > > |public class Main { public static void main(String[] args) > > > { SomeInterface someInterface = new SomeInterface() { @Override > > public > > > SomeRecord someMethod() { return new SomeRecord(); } }; } }| > > > > > > | > > > | > > > |package my.nice.project.pkg.a; import module my.nice.project;| > > > | > > > | > > > |public interface SomeInterface { public SomeRecord someMethod(); > }| > > > > > > |package my.nice.project.pkg.b; public record SomeRecord() {} | > > > > > > When attempting to compile this code with the exports commented > > out, I > > > received several "cannot find symbol" errors. However, after > > > uncommenting the exports: > > > > > > > > > |exports my.nice.project.pkg.a to my.nice.project; exports > > > my.nice.project.pkg.b to my.nice.project; | > > > > > > The code compiled and ran as expected. > > > > > > Given this behavior, I wanted to confirm if this restriction on > > package > > > visibility within a module is the intended design under the Amber > > > project and the module system, or if there?s another approach or > > best > > > practice I might be overlooking in terms of package exports. > > > > > > Thank you for your time and insight. > > > > > > Best regards, > > > > > > Thiago > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Sep 13 19:44:18 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 13 Sep 2024 12:44:18 -0700 Subject: [External] : Re: JEP 476: Clarification on Package Export Behavior in Java Modules In-Reply-To: References: <8c51c782-a8b2-4ec8-9238-f4ae0eb8345d@oracle.com> Message-ID: <1899f732-7ee7-4e84-b4b2-8b0201a6f93f@oracle.com> You're not importing the my.nice.project.pkg.{a,b} packages at all, so the names SomeRecord and SomeInterface are unknown. `import module ...` will only import the packages exported from the module. If the my.nice.project module doesn't export anything, then `import module my.nice.project` is not a substitute for on-demand/single-type imports. If the my.nice.project module exports the two packages to itself, then `import module my.nice.project` from within the module should work as a substitute for on-demand/single-type imports. Alex On 9/13/2024 12:28 PM, Thiago Henrique Hupner wrote: > Source structure: > > src > ? ? | ? module-info.java > ? ? \---my > ? ? ? ? \---nice > ? ? ? ? ? ? \---project > ? ? ? ? ? ? ? ? | ? Main.java > ? ? ? ? ? ? ? ? \---pkg > ? ? ? ? ? ? ? ? ? ? +---a > ? ? ? ? ? ? ? ? ? ? | ? ? ? SomeInterface.java > ? ? ? ? ? ? ? ? ? ? \---b > ? ? ? ? ? ? ? ? ? ? ? ? ? ? SomeRecord.java > > I've tried both commands with and without the module import and they > both fail: > > java --enable-preview src/my/nice/project/Main.java > > > javac --release 23 --enable-preview -d ./mod ./src/module-info.java ./ > src/my/nice/project/Main.java ./src/my/nice/project/pkg/a/ > SomeInterface.java ./src/my/nice/project/pkg/b/SomeRecord.java > > However, exporting a package to the my.nice.project module and including > the module import both commands work. > > > .\src\my\nice\project\pkg\a\SomeInterface.java:7: error: cannot find symbol > ? ? public SomeRecord someMethod(); > ? ? ? ? ? ?^ > ? symbol: ? class SomeRecord > ? location: interface SomeInterface > .\src\my\nice\project\Main.java:7: error: cannot find symbol > ? ? ? ? SomeInterface someInterface = new SomeInterface() { > ? ? ? ? ^ > ? symbol: ? class SomeInterface > ? location: class Main > .\src\my\nice\project\Main.java:7: error: cannot find symbol > ? ? ? ? SomeInterface someInterface = new SomeInterface() { > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ > ? symbol: ? class SomeInterface > ? location: class Main > .\src\my\nice\project\Main.java:9: error: cannot find symbol > ? ? ? ? ? ? public SomeRecord someMethod() { > ? ? ? ? ? ? ? ? ? ?^ > ? symbol: class SomeRecord > .\src\my\nice\project\Main.java:8: error: method does not override or > implement a method from a supertype > ? ? ? ? ? ? @Override > ? ? ? ? ? ? ^ > .\src\my\nice\project\Main.java:10: error: cannot find symbol > ? ? ? ? ? ? ? ? return new SomeRecord(); > ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > ? symbol: class SomeRecord > 6 errors > > > Best regards, > > Thiago > > Em sex., 13 de set. de 2024 ?s 15:53, Alex Buckley > > escreveu: > > If removing the imports doesn't fix the errors, then I'm suspicious of > your compiler setup. > > Please describe on this mailing list the commands you're using and the > actual javac errors that you see. > > Alex > > On 9/13/2024 9:41 AM, Thiago Henrique Hupner wrote: > > Removing the imports still doesn't fix the errors. > > > > I've create a Github repo with the reproducer: https:// > github.com/ ACWV5N9M2RV99hQ!I4FDC_5bZkrDbMH-KZS-5Acu- > JIodeUAiW82iZl2Ozjm04tx6e3VXy1ug49pGDiAOGAKVnPCOoj1tF9KrA$> > > Thihup/module-import-bug > > > > Best regards, > > > > Thiago > > > > > > Em sex., 13 de set. de 2024 ?s 12:41, Alex Buckley > > > >> > escreveu: > > > >? ? ?I assume that the package my.nice.project is colocated with > the other > >? ? ?two packages -- my.nice.project.pkg.{a,b} -- in the module > >? ? ?my.nice.project. > > > >? ? ?If so, then all three packages should be able to access each > others' > >? ? ?public types (SomeInterface, SomeRecord) without error. > > > >? ? ?The fact that you're getting an error looks like a javac bug. > > > >? ? ?You don't need to `import module my.nice.project` in the source > >? ? ?files of > >? ? ?that module. Try removing those imports and see if > my.nice.project.Main > >? ? ?compiles (it should). > > > >? ? ?Alex > > > >? ? ?On 9/13/2024 5:00 AM, Thiago Henrique Hupner wrote: > >? ? ? > Dear Amber Team, > >? ? ? > > >? ? ? > I hope you're doing well. I?ve encountered a behavior > related to JEP > >? ? ? > 476: Module Import Declarations and wanted to ask for > clarification. > >? ? ? > > >? ? ? > I?m working with a module setup where two packages are defined > >? ? ?but not > >? ? ? > initially exported: > >? ? ? > > >? ? ? > |module my.nice.project { //exports my.nice.project.pkg.a to > >? ? ? > my.nice.project; //exports my.nice.project.pkg.b to > >? ? ?my.nice.project; } | > >? ? ? > > >? ? ? > Here?s a simplified version of the code structure: > >? ? ? > > >? ? ? > > >? ? ? > |package my.nice.project; > >? ? ? > | > >? ? ? > | > >? ? ? > |import module my.nice.project;| > >? ? ? > > >? ? ? > | > >? ? ? > |public class Main { public static void main(String[] args) > >? ? ? > { SomeInterface someInterface = new SomeInterface() > { @Override > >? ? ?public > >? ? ? > SomeRecord someMethod() { return new SomeRecord(); } }; } }| > >? ? ? > > >? ? ? > | > >? ? ? > | > >? ? ? > |package my.nice.project.pkg.a; import module > my.nice.project;| > >? ? ? > | > >? ? ? > | > >? ? ? > |public interface SomeInterface { public SomeRecord > someMethod(); }| > >? ? ? > > >? ? ? > |package my.nice.project.pkg.b; public record SomeRecord() > {} | > >? ? ? > > >? ? ? > When attempting to compile this code with the exports > commented > >? ? ?out, I > >? ? ? > received several "cannot find symbol" errors. However, after > >? ? ? > uncommenting the exports: > >? ? ? > > >? ? ? > > >? ? ? > |exports my.nice.project.pkg.a to my.nice.project; exports > >? ? ? > my.nice.project.pkg.b to my.nice.project; | > >? ? ? > > >? ? ? > The code compiled and ran as expected. > >? ? ? > > >? ? ? > Given this behavior, I wanted to confirm if this > restriction on > >? ? ?package > >? ? ? > visibility within a module is the intended design under > the Amber > >? ? ? > project and the module system, or if there?s another > approach or > >? ? ?best > >? ? ? > practice I might be overlooking in terms of package exports. > >? ? ? > > >? ? ? > Thank you for your time and insight. > >? ? ? > > >? ? ? > Best regards, > >? ? ? > > >? ? ? > Thiago > >? ? ? > > > > From adam.sotona at oracle.com Mon Sep 23 05:42:52 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 23 Sep 2024 05:42:52 +0000 Subject: JEP 477: println blocking Message-ID: Hi, I?m updating my classroom examples to run on JDK 23 and with IO.println I experience different behavior than with System.out.println. Following example explains the issue. Thank you, Adam static void doSomething() { try { Thread.sleep(1000); } catch (InterruptedException ignore) {} } void main() { Thread.ofVirtual().start(() -> { while (true) { doSomething(); System.out.println("I do something until you press Enter"); } }); Thread.ofVirtual().start(() -> { while (true) { doSomething(); println("I'm blocked until you press Enter"); } }); readln(""); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Mon Sep 23 06:06:51 2024 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 23 Sep 2024 07:06:51 +0100 Subject: JEP 477: println blocking In-Reply-To: References: Message-ID: <6fce9ea7-c2c6-4599-aba5-bedbb3327263@oracle.com> On 23/09/2024 06:42, Adam Sotona wrote: > > Hi, > > I?m updating my classroom examples to run on JDK 23 and with > IO.println I experience different behavior than with > System.out.println. Following example explains the issue. > > Thank you, > > Adam > > staticvoid*/doSomething/*() { > > try{ > > Thread./sleep/(1000); > > } catch(InterruptedException ignore) {} > > } > > void*main*() { > > Thread./ofVirtual/().start(() -> { > > while(true) { > > /doSomething/(); > > System./out/.println("I do something until you press Enter"); > > } > > }); > > Thread./ofVirtual/().start(() -> { > > while(true) { > > /doSomething/(); > > /println/("I'm blocked until you press Enter"); > > } > > }); > > /readln/(""); > > } > IO uses Console which has its own read + write locks to coordinate input and output from concurrent threads. The readln is both output (for the prompt) and input and it seems to hold both locks when waiting for input.?? System.out has its own route to print the output, doesn't coordinate with Console, so isn't locked out by readln(prompt). It's always been possible to mix Console and System.in/out, but maybe time to re-examine to avoid puzzlers when mixing uses of the new textual I/O methods with code copied from a book or online resource that uses System.out. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Wed Sep 25 09:30:18 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Wed, 25 Sep 2024 09:30:18 +0000 Subject: [module-import] Modules transitively requiring module java.base Message-ID: Dear all, People playing with JEP 476 - Module Import Declarations - have been surprised when importing an aggregator module such as `java.se`, that they also needed to `import module java.base`. This is because the `java.se` module which, as an aggregator module, consists of only `requires transitive` directives, does not contain the directive `requires transitive java.base`. Currently Java forbids any module declaring a transitive dependence on the `java.base` module. This restriction was sensible in the original module system design as all modules have an implicit dependence on `java.base`, and so such a directive was pointless. But with the module import feature where module declarations are used to derive a set of packages to be imported, this directive is useful and so should be allowed. We propose in the next preview of this feature to lift the language restriction on `requires transitive java.base`, and also to change the implementation of the `java.se` module so that it `requires transitive java.base`. (I have updated the draft JEP: https://openjdk.org/jeps/8335987) Let me know your thoughts on this proposal either on this list, or direct to me. Thanks, Gavin From amaembo at gmail.com Wed Sep 25 09:44:12 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 25 Sep 2024 11:44:12 +0200 Subject: [module-import] Modules transitively requiring module java.base In-Reply-To: References: Message-ID: I support this change, thank you! Tagir On Wed, Sep 25, 2024, 11:30 Gavin Bierman wrote: > Dear all, > > People playing with JEP 476 - Module Import Declarations - have been > surprised when importing an aggregator module such as `java.se`, that > they also needed to `import module java.base`. This is because the ` > java.se` module which, as an aggregator module, consists of only > `requires transitive` directives, does not contain the directive `requires > transitive java.base`. Currently Java forbids any module declaring a > transitive dependence on the `java.base` module. > > This restriction was sensible in the original module system design as all > modules have an implicit dependence on `java.base`, and so such a directive > was pointless. But with the module import feature where module declarations > are used to derive a set of packages to be imported, this directive is > useful and so should be allowed. > > We propose in the next preview of this feature to lift the language > restriction on `requires transitive java.base`, and also to change the > implementation of the `java.se` module so that it `requires transitive > java.base`. (I have updated the draft JEP: > https://openjdk.org/jeps/8335987) > > Let me know your thoughts on this proposal either on this list, or direct > to me. > > Thanks, > Gavin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Sep 25 10:25:48 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 Sep 2024 12:25:48 +0200 (CEST) Subject: [module-import] Modules transitively requiring module java.base In-Reply-To: References: Message-ID: <240758622.16581452.1727259948693.JavaMail.zimbra@univ-eiffel.fr> > From: "Tagir Valeev" > To: "Gavin Bierman" > Cc: "amber-dev" , "amber-spec-experts" > > Sent: Wednesday, September 25, 2024 11:44:12 AM > Subject: Re: [module-import] Modules transitively requiring module java.base > I support this change, thank you! > Tagir I agree, this is a useful addition. R?mi > On Wed, Sep 25, 2024, 11:30 Gavin Bierman < [ mailto:gavin.bierman at oracle.com | > gavin.bierman at oracle.com ] > wrote: >> Dear all, >> People playing with JEP 476 - Module Import Declarations - have been surprised >> when importing an aggregator module such as ` [ http://java.se/ | java.se ] `, >> that they also needed to `import module java.base`. This is because the ` [ >> http://java.se/ | java.se ] ` module which, as an aggregator module, consists >> of only `requires transitive` directives, does not contain the directive >> `requires transitive java.base`. Currently Java forbids any module declaring a >> transitive dependence on the `java.base` module. >> This restriction was sensible in the original module system design as all >> modules have an implicit dependence on `java.base`, and so such a directive was >> pointless. But with the module import feature where module declarations are >> used to derive a set of packages to be imported, this directive is useful and >> so should be allowed. >> We propose in the next preview of this feature to lift the language restriction >> on `requires transitive java.base`, and also to change the implementation of >> the ` [ http://java.se/ | java.se ] ` module so that it `requires transitive >> java.base`. (I have updated the draft JEP: [ https://openjdk.org/jeps/8335987 | >> https://openjdk.org/jeps/8335987 ] ) >> Let me know your thoughts on this proposal either on this list, or direct to me. >> Thanks, >> Gavin -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Sep 27 14:13:21 2024 From: duke at openjdk.org (duke) Date: Fri, 27 Sep 2024 14:13:21 GMT Subject: git: openjdk/amber-docs: Updated JEP list for JDK 23 Message-ID: Changeset: 5aa5326c Branch: master Author: Gavin Bierman Date: 2024-09-27 15:10:42 +0000 URL: https://git.openjdk.org/amber-docs/commit/5aa5326c96a1252b232fb50e651ad40937443288 Updated JEP list for JDK 23 ! site/_index.md From mark.reinhold at oracle.com Mon Sep 30 20:03:36 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 30 Sep 2024 20:03:36 +0000 Subject: New candidate JEP: 488: Primitive Types in Patterns, instanceof, and switch (Second Preview) Message-ID: <20240930200335.1ECAC77CADA@eggemoggin.niobe.net> https://openjdk.org/jeps/488 Summary: Enhance pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature. - Mark