From bburd at drew.edu Mon Jul 1 16:41:29 2024 From: bburd at drew.edu (Barry Burd) Date: Mon, 1 Jul 2024 12:41:29 -0400 Subject: JEP 477 Questions Message-ID: <3f5aab65-cf67-4180-93e0-d778d8dfd01f@drew.edu> Is there any possibility of having read methods for the primitive types (readInt, readDouble, and so on) in java.io.IO? Thanks. -Barry From amaembo at gmail.com Thu Jul 4 12:55:24 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 4 Jul 2024 14:55:24 +0200 Subject: Suppressing warnings for implicit class Message-ID: Hello! Do I understand correctly that it's not possible to suppress a warning (e.g., unchecked) for the whole implicit class at once? Only for individual members, right? With best regards, Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Jul 4 13:01:23 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 4 Jul 2024 15:01:23 +0200 (CEST) Subject: Suppressing warnings for implicit class In-Reply-To: References: Message-ID: <825434033.66764964.1720098083614.JavaMail.zimbra@univ-eiffel.fr> > From: "Tagir Valeev" > To: "amber-spec-experts" > Sent: Thursday, July 4, 2024 2:55:24 PM > Subject: Suppressing warnings for implicit class > Hello! > Do I understand correctly that it's not possible to suppress a warning (e.g., > unchecked) for the whole implicit class at once? Only for individual members, > right? Right, you can not suppress it at class level becaiuse there is no class declaration and you can not suppress it at package level given that an implicit class has no package. > With best regards, > Tagir Valeev regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Fri Jul 5 15:05:16 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 5 Jul 2024 17:05:16 +0200 Subject: Instance main method and vararg constructor Message-ID: Hello! I wonder if we should enable instance main method if the class has only vararg constructor: class Test { Test(String... data) { } void main() { System.out.println("Hello World!"); } } Java 22 doesn't like it: > \jdks\jdk-22\bin\java.exe --enable-preview Test.java error: can't find no argument constructor in class: Test However, in other contexts, such a class is considered as a class that has no-arg constructor. E.g., we can subclass it without explicit super-constructor invocation: class Test { Test(String... data) { } static class Use extends Test {} } Would it be consistent to allow launching such classes? With best regards, Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Fri Jul 5 15:14:34 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 5 Jul 2024 15:14:34 +0000 Subject: Instance main method and vararg constructor In-Reply-To: References: Message-ID: It is reasonable to infer the semantics of a no-arg constructor as ?give me a default-configured instance of this class?, where default-configured is controlled by the class. This is done by Javabeans, serialization, test frameworks, and other frameworks. But once a constructor has arguments, those arguments have semantics. Can we really assume that a `String?` constructor is intended to be used with command-line-argument strings? That seems more of a leap. We do so with `main` because by longstanding convention, `main` functions/methods (going back to C) have been associated with the interface from the OS launcher to the program. But I think that?s as far as we should take it? > On Jul 5, 2024, at 11:05 AM, Tagir Valeev wrote: > > Hello! > > I wonder if we should enable instance main method if the class has only vararg constructor: > > class Test { > Test(String... data) { > } > > void main() { > System.out.println("Hello World!"); > } > } > > Java 22 doesn't like it: > > \jdks\jdk-22\bin\java.exe --enable-preview Test.java > error: can't find no argument constructor in class: Test > > However, in other contexts, such a class is considered as a class that has no-arg constructor. E.g., we can subclass it without explicit super-constructor invocation: > > class Test { > Test(String... data) { > } > > static class Use extends Test {} > } > > Would it be consistent to allow launching such classes? > > With best regards, > Tagir Valeev From amaembo at gmail.com Fri Jul 5 15:20:41 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 5 Jul 2024 17:20:41 +0200 Subject: Instance main method and vararg constructor In-Reply-To: References:

Message-ID: Hello! No, I don't think that we should assume any semantics there. Just pass empty array always. Arguments can be passed to main() method if String[] args parameter is present, like always. On Fri, Jul 5, 2024, 17:14 Brian Goetz wrote: > It is reasonable to infer the semantics of a no-arg constructor as ?give > me a default-configured instance of this class?, where default-configured > is controlled by the class. This is done by Javabeans, serialization, test > frameworks, and other frameworks. But once a constructor has arguments, > those arguments have semantics. Can we really assume that a `String?` > constructor is intended to be used with command-line-argument strings? > That seems more of a leap. > > We do so with `main` because by longstanding convention, `main` > functions/methods (going back to C) have been associated with the interface > from the OS launcher to the program. But I think that?s as far as we > should take it? > > > On Jul 5, 2024, at 11:05 AM, Tagir Valeev wrote: > > > > Hello! > > > > I wonder if we should enable instance main method if the class has only > vararg constructor: > > > > class Test { > > Test(String... data) { > > } > > > > void main() { > > System.out.println("Hello World!"); > > } > > } > > > > Java 22 doesn't like it: > > > \jdks\jdk-22\bin\java.exe --enable-preview Test.java > > error: can't find no argument constructor in class: Test > > > > However, in other contexts, such a class is considered as a class that > has no-arg constructor. E.g., we can subclass it without explicit > super-constructor invocation: > > > > class Test { > > Test(String... data) { > > } > > > > static class Use extends Test {} > > } > > > > Would it be consistent to allow launching such classes? > > > > With best regards, > > Tagir Valeev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.herrmann at berlin.de Thu Jul 11 11:01:14 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Thu, 11 Jul 2024 13:01:14 +0200 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de>

Message-ID: <893abb4e-f277-4688-98b5-faefd409925a@berlin.de> I played a bit with Dan's example: Am 30.05.24 um 06:39 schrieb Dan Smith: > [...] > To clarify the model: yes, this rule was intentionally removed. It becomes very > complicated if you want to make rules about which enclosing instances exist or > don't exist based on positioning within a constructor. Example: > > class C1 { > ? ? C1() { > ? ? ? ? super(); > ? ? ? ? class C2 { // not early for C1 > ? ? ? ? ? ? C2() { > ? ? ? ? ? ? ? ? class C3 { // early for C2 > ? ? ? ? ? ? ? ? ? ? C3() { > ? ? ? ? ? ? ? ? ? ? ? ? super(); > ? ? ? ? ? ? ? ? ? ? ? ? class C4 { // not early for C3 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ... > ? ? ? ? ? ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? ? super(); > ? ? ? ? ? ? } > ? ? ? ? } > ? ? } > } > > Does C4 have a 1st enclosing instance? Yep. 2nd? Maybe no? 3rd? It better... I slightly extended it to this to make it testable: class C1 { String f1 = "f1"; C1() { super(); System.out.print(f1); class C2 { // not early for C1 C2() { System.out.print(f1); class C3 { // early for C2 String f3 = "f3"; C3() { super(); System.out.print(f1); class C4 { // not early for C3 C4() { System.out.print(f3); // System.out.print(f1); } } new C4(); } } super(); new C3(); } } new C2(); } public static void main(String... args) { new C1(); } } Using javac from build 23-ea+30-2323 this compiles fine and prints "f1f1f1f3". When, however, I enable the innermost access to f1, javac complains: error: no enclosing instance of type C1 is in scope Is this a bug, or am I missing some subtlety from the spec? Please see that field f1 is accessible at all levels of nesting (because C1.this is fully initialized), so why should a class even in the *epilogue* of C3() not be able to read this field, when right before the class declaration it was accessible? thanks, Stephan From archie.cobbs at gmail.com Thu Jul 11 13:56:09 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 11 Jul 2024 08:56:09 -0500 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: <893abb4e-f277-4688-98b5-faefd409925a@berlin.de> References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de>

<893abb4e-f277-4688-98b5-faefd409925a@berlin.de> Message-ID: On Thu, Jul 11, 2024 at 6:01?AM Stephan Herrmann wrote: > Using javac from build 23-ea+30-2323 this compiles fine and prints > "f1f1f1f3". > > When, however, I enable the innermost access to f1, javac complains: > > error: no enclosing instance of type C1 is in scope > > Is this a bug, or am I missing some subtlety from the spec? > You're right, I think that's a bug - thanks. https://bugs.openjdk.org/browse/JDK-8336255 -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Fri Jul 12 01:09:29 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 11 Jul 2024 20:09:29 -0500 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de>

<893abb4e-f277-4688-98b5-faefd409925a@berlin.de> Message-ID: Hi Stephan, It turns out that this bug is already fixed, but this fix is still waiting in the PR hopper... I've resolved it as a duplicate of JDK-8334248 . FYI here is the list of bugs related to this early initialization stuff . -Archie On Thu, Jul 11, 2024 at 8:56?AM Archie Cobbs wrote: > On Thu, Jul 11, 2024 at 6:01?AM Stephan Herrmann < > stephan.herrmann at berlin.de> wrote: > >> Using javac from build 23-ea+30-2323 this compiles fine and prints >> "f1f1f1f3". >> >> When, however, I enable the innermost access to f1, javac complains: >> >> error: no enclosing instance of type C1 is in scope >> >> Is this a bug, or am I missing some subtlety from the spec? >> > > You're right, I think that's a bug - thanks. > > https://bugs.openjdk.org/browse/JDK-8336255 > > -Archie > > -- > Archie L. Cobbs > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Fri Jul 12 12:27:38 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 12 Jul 2024 14:27:38 +0200 Subject: [module-imports] Importing java.se? Message-ID: Hello! I'm playing with module imports and tried to import java.se module: import module java.se; class Test { void main() { ArrayList list; } } Building (23-ea+31-2337) yields the following errors: >\jdks\jdk-23\bin\java.exe --enable-preview --source=23 Test.java Test.java:1: error: unnamed module does not read: java.se import module java.se; ^ Test.java:5: error: cannot find symbol ArrayList list; ^ symbol: class ArrayList location: class Test 2 errors error: compilation failed I'm not sure I understand the first error "unnamed module does not read". Importing java.se is described in JEP 476 text [1], so I assume that it's something allowed. Is the current behavior intended? If yes, then the JEP text should probably not mention java.se as an allowed example to import. The second error is caused by the fact that java.se does not declare explicitly that it transitively requires java.base. It's assumed that any module requires java.base implicitly, and requires transitive java.base declaration is not allowed. However, this looks strange with java.se specifically: we can import the whole Java SE platform via a single import declaration _except_ the java.base module. Contrary, running jshell JAVASE imports the whole Java SE platform including the java.base module. This looks inconsistent to me. So the question is: is it actually allowed to import java.se, and should it import java.base automatically? With best regards, Tagir Valeev [1] https://openjdk.org/jeps/476 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Jul 12 13:27:01 2024 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 12 Jul 2024 15:27:01 +0200 Subject: [module-imports] Importing java.se? In-Reply-To: References: Message-ID: <2b140d02-1b0e-4d72-a884-ea4ea34c6c3e@oracle.com> On the first error, as of JDK 11 (IIRC), the additional root modules for (the) unnamed module are system modules which have an unqualified exports (please see JDK-8197532 for more precise and exact details). So, when compiling code in the unnamed module, java.se, which does not have any exports, is usually not in the module graph, and hence is not read by the unnamed module. If java.se is added to the root modules using `--add-modules java.se` (for an unnamed module), or via a requires (in case of named modules), then it should be possible to "import module" from it. Jan On 12. 07. 24 14:27, Tagir Valeev wrote: > Hello! > > I'm playing with module imports and tried to import java.se > module: > > import module java.se ; > > class Test { > ? void main() { > ? ? ArrayList list; > ? } > } > > Building (23-ea+31-2337) yields the following errors: > > >\jdks\jdk-23\bin\java.exe --enable-preview --source=23 Test.java > Test.java:1: error: unnamed module does not read: java.se > import module java.se ; > ^ > Test.java:5: error: cannot find symbol > ? ? ArrayList list; > ? ? ^ > ? symbol: ? class ArrayList > ? location: class Test > 2 errors > error: compilation failed > > I'm not sure I understand the first error "unnamed module does not > read". Importing java.se is described in JEP 476 text > [1], so I assume that it's something allowed. Is?the current behavior > intended? If yes, then the JEP text should probably not mention > java.se as an allowed example to import. > > The second error is caused by the fact that java.se > does not declare explicitly that it transitively requires java.base. > It's assumed that any module requires java.base implicitly, and > requires transitive java.base declaration is not allowed. However, > this looks strange with java.se specifically: we can > import the whole Java SE platform via a single import declaration > _except_ the java.base module. Contrary, running jshell JAVASE imports > the whole Java SE platform including the java.base module. This looks > inconsistent to me. > > So the question is: is it actually allowed to import java.se > , and should it import java.base automatically? > > With best regards, > Tagir Valeev > > [1] https://openjdk.org/jeps/476 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.herrmann at berlin.de Sun Jul 14 17:43:33 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Sun, 14 Jul 2024 19:43:33 +0200 Subject: Field assignment in early construction context - details Message-ID: Dear experts, I'm observing some more differences between the JEP 482 spec [1] and javac [2], which may or may not be omissions in JLS: (1) ?6.5.6.1 regulates access to fields of C within an early construction context of C, but it does not mention any inheritance situations like this: class Super { int i; } public class Test extends Super { Test() { i = 13; super(); } } javac reports: error: cannot reference i before supertype constructor has been called i = 13; ^ First of all, do we have a relevant early construction context at all? - i is declared in Super - we are not in an early construction context of Super - should we consider i as an instance variable of Test? - should early construction context affect all super classes, too? Then if we had an early construction context affecting 'i', wouldn't the "assignment exception" apply, or should super fields be exempted from the exception? Most certainly, it is not intended to admit *reading* 'i' in an early construction context of 'Test', but I don't see anything in this direction in the spec. (2) ?15.8.3 admits 'this' in early construction context when "it appears as the qualifier of a field access expression appearing as the left-hand operand of a simple assignment expression". ?15.8.4 has no such exception for qualified this, even if the qualifier is redundant: public class Test { int j; Test() { Test.this.j = 15; super(); } } 'Test.this' clearly appears in an early construction context of 'Test'. Still javac accepts, and in this case I don't see any reason to reject. Is this an omission in ?15.8.4? thanks, Stephan [1] Latest as of https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-31/ [2] from build 23-ea+31-2337 From stephan.herrmann at berlin.de Sun Jul 14 19:49:46 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Sun, 14 Jul 2024 21:49:46 +0200 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de> References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de> Message-ID: <811acf95-ffe5-4256-b82f-f275a0fe3ff7@berlin.de> This part doesn't look fully resolved to me: Am 28.05.24 um 19:20 schrieb Stephan Herrmann: > [...] > In ?8.8.7.1 it says: > ????"References to instance variables of class C are disallowed ..." > which seems to disqualify the following code: > > public class C { > ????String name; > ????C(C other) { > ??????? System.out.println(other.name); > ??????? super(); > ????} > } > > I assume this paragraph in italics is not normative, right? Later paragraphs are > clear that this applies to single name references and this references, but still > the above sentence seems misleading. The same applies for the next two sentences > (regarding other.foo(), or new other.Inner()). > [...] While the detailed rules in 15.12.3 look good, the explanation in 8.8.7.1 still lacks precision. If that explanation is not meant to be precise, maybe it should indicate this :) The same problem also exists in the summary in 6.5.7.1 (which is not italics - explanatory): "The rules (15.12.3) also prohibit a reference to an instance method occurring in any one of the following: ... 3. an early construction context (8.8.7.1) of a class where the instance method is a member." Interestingly, 6.5.7.1 is more precise regarding qualified this expressions than what ?15.8.4 says about it (see my previous post). thanks, Stephan From archie.cobbs at gmail.com Sun Jul 14 20:14:11 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Sun, 14 Jul 2024 15:14:11 -0500 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: <811acf95-ffe5-4256-b82f-f275a0fe3ff7@berlin.de> References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de> <811acf95-ffe5-4256-b82f-f275a0fe3ff7@berlin.de> Message-ID: I think you are correct in that the spec needs further clarification on those two points. I can at least confirm that what the compiler currently implements is in fact the intended behavior: - Access to superclass instance fields by any means in an early construction context is not allowed - The rules for "foo", "this.foo", and "C.this.foo" (for the same "foo") in an early construction context should be the same -Archie On Sun, Jul 14, 2024 at 2:50?PM Stephan Herrmann wrote: > This part doesn't look fully resolved to me: > > Am 28.05.24 um 19:20 schrieb Stephan Herrmann: > > [...] > In ?8.8.7.1 it says: > > "References to instance variables of class C are disallowed ..." > > which seems to disqualify the following code: > > > > public class C { > > String name; > > C(C other) { > > System.out.println(other.name); > > super(); > > } > > } > > > > I assume this paragraph in italics is not normative, right? Later > paragraphs are > > clear that this applies to single name references and this references, > but still > > the above sentence seems misleading. The same applies for the next two > sentences > > (regarding other.foo(), or new other.Inner()). > > [...] > > > While the detailed rules in 15.12.3 look good, the explanation in 8.8.7.1 > still > lacks precision. If that explanation is not meant to be precise, maybe it > should > indicate this :) > > The same problem also exists in the summary in 6.5.7.1 (which is not > italics - > explanatory): > > "The rules (15.12.3) also prohibit a reference to an instance method > occurring > in any one of the following: > ... > 3. an early construction context (8.8.7.1) of a class where the instance > method > is a member." > > > Interestingly, 6.5.7.1 is more precise regarding qualified this > expressions than > what ?15.8.4 says about it (see my previous post). > > thanks, > Stephan > > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.herrmann at berlin.de Sun Jul 14 20:25:07 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Sun, 14 Jul 2024 22:25:07 +0200 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de> <811acf95-ffe5-4256-b82f-f275a0fe3ff7@berlin.de> Message-ID: <18827339-39f8-42dc-80cf-4d69e4f19559@berlin.de> This answers my other post "Field assignment in early construction context - details" right? :) Am 14.07.24 um 22:14 schrieb Archie Cobbs: > I think you are correct in that the spec needs further clarification on those > two points. > > I can at least confirm that what the compiler currently implements is in fact > the intended behavior: > > * Access to superclass instance fields by any means in an early construction > context is not allowed > * The rules for "foo", "this.foo", and "C.this.foo" (for the same "foo") in an > early construction context should be the same > > -Archie > > > On Sun, Jul 14, 2024 at 2:50?PM Stephan Herrmann > wrote: > > This part doesn't look fully resolved to me: > > Am 28.05.24 um 19:20 schrieb Stephan Herrmann: > > [...] > In ?8.8.7.1 it says: > >? ????"References to instance variables of class C are disallowed ..." > > which seems to disqualify the following code: > > > > public class C { > >? ????String name; > >? ????C(C other) { > >? ??????? System.out.println(other.name ); > >? ??????? super(); > >? ????} > > } > > > > I assume this paragraph in italics is not normative, right? Later > paragraphs are > > clear that this applies to single name references and this references, > but still > > the above sentence seems misleading. The same applies for the next two > sentences > > (regarding other.foo(), or new other.Inner()). > > [...] > > > While the detailed rules in 15.12.3 look good, the explanation in 8.8.7.1 still > lacks precision. If that explanation is not meant to be precise, maybe it > should > indicate this :) > > The same problem also exists in the summary in 6.5.7.1 (which is not italics - > explanatory): > > "The rules (15.12.3) also prohibit a reference to an instance method occurring > in any one of the following: > ... > 3. an early construction context (8.8.7.1) of a class where the instance method > is a member." > > > Interestingly, 6.5.7.1 is more precise regarding qualified this expressions > than > what ?15.8.4 says about it (see my previous post). > > thanks, > Stephan > > > > -- > Archie L. Cobbs From archie.cobbs at gmail.com Sun Jul 14 20:50:27 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Sun, 14 Jul 2024 15:50:27 -0500 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: <18827339-39f8-42dc-80cf-4d69e4f19559@berlin.de> References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de> <811acf95-ffe5-4256-b82f-f275a0fe3ff7@berlin.de> <18827339-39f8-42dc-80cf-4d69e4f19559@berlin.de> Message-ID: On Sun, Jul 14, 2024 at 3:25?PM Stephan Herrmann wrote: > This answers my other post > "Field assignment in early construction context - details" > right? :) > Oops, yes - sorry for replying in the wrong thread. In any case the same answer also applies to the "other.name" example, i.e., the compiler should currently be exhibiting the intended behavior (once PR's #19900 and #19904 are applied). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Tue Jul 16 09:32:16 2024 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 16 Jul 2024 09:32:16 +0000 Subject: Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482) In-Reply-To: References: <125ABABF-4D7C-4B57-B5D2-E81C3FC86FB1@oracle.com> <89c6e982-5129-47bf-950d-27b5ebe51eb6@berlin.de> <811acf95-ffe5-4256-b82f-f275a0fe3ff7@berlin.de> Message-ID: <7E15E1CB-24FA-45DD-9DAF-C7A893CE618A@oracle.com> On 14 Jul 2024, at 21:14, Archie Cobbs wrote: I think you are correct in that the spec needs further clarification on those two points. I can at least confirm that what the compiler currently implements is in fact the intended behavior: * Access to superclass instance fields by any means in an early construction context is not allowed * The rules for "foo", "this.foo", and "C.this.foo" (for the same "foo") in an early construction context should be the same -Archie Thanks Stephan. We had already spotted the inconsistency between this.foo and C.this.foo and filed a spec bug: https://bugs.openjdk.org/browse/JDK-8334163 I believe that there are other areas in the spec where they are not treated the same, so I had planned to do a more complete sweep through the spec to consider a more complete fix. Cheers, Gavin On Sun, Jul 14, 2024 at 2:50?PM Stephan Herrmann > wrote: This part doesn't look fully resolved to me: Am 28.05.24 um 19:20 schrieb Stephan Herrmann: > [...] > In ?8.8.7.1 it says: > "References to instance variables of class C are disallowed ..." > which seems to disqualify the following code: > > public class C { > String name; > C(C other) { > System.out.println(other.name); > super(); > } > } > > I assume this paragraph in italics is not normative, right? Later paragraphs are > clear that this applies to single name references and this references, but still > the above sentence seems misleading. The same applies for the next two sentences > (regarding other.foo(), or new other.Inner()). > [...] While the detailed rules in 15.12.3 look good, the explanation in 8.8.7.1 still lacks precision. If that explanation is not meant to be precise, maybe it should indicate this :) The same problem also exists in the summary in 6.5.7.1 (which is not italics - explanatory): "The rules (15.12.3) also prohibit a reference to an instance method occurring in any one of the following: ... 3. an early construction context (8.8.7.1) of a class where the instance method is a member." Interestingly, 6.5.7.1 is more precise regarding qualified this expressions than what ?15.8.4 says about it (see my previous post). thanks, Stephan -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Jul 17 00:06:09 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 16 Jul 2024 17:06:09 -0700 Subject: [module-imports] Importing java.se? In-Reply-To: References: Message-ID: On 7/12/2024 5:27 AM, Tagir Valeev wrote: > I'm playing with module imports and tried to import java.se module: > > import module java.se; > > class Test { > ? void main() { > ? ? ArrayList list; > ? } > } > > Building (23-ea+31-2337) yields the following errors: ... > > I'm not sure I understand the first error "unnamed module does not > read". Importing java.se is described in JEP 476 text [1], so I > assume that it's something allowed. Is the current behavior intended? > If yes, then the JEP text should probably not mention java.se as an > allowed example to import. As you say, the JEP uses java.se as the poster child for "aggregator" modules that have no packages of their own and exist solely to arrange access to packages in other modules. Unfortunately, we overlooked how java.se is no longer (since JDK 11) in the default set of root modules for the unnamed module. See https://bugs.openjdk.org/browse/JDK-8205169. This means that an implicitly declared class, being in the unnamed module, cannot refer to java.se in `import module ...`. (Bear in mind that `import module ...` is not another way of spelling `requires ...`. Every import declaration -- whether of com.foo.Type, or com.foo.*, or module com.foo -- operates in the environment set up by the module system. If your program has a module declaration, then the module system sets up the environment according to your `requires ...` directives. If your program is in the unnamed module, then its environment is the default set of root modules for the unnamed module. You can augment the default set with --add-modules, but that's not for beginners.) I confess to being a little sad about the inability to `import module java.se` in an implicitly declared class, because aggregator modules like java.se are the de facto solution for module renaming/refactoring. In the JEP, we should clarify the "It is sometimes useful ..." paragraph by adding: "Note that `import module java.se` is only possible in a compilation unit of a named module that already `requires java.se`. In a compilation unit of the unnamed module, such as one that implicitly declares a class, it is not possible to use `import module java.se`." > The second error is caused by the fact that java.se > does not declare explicitly that it transitively requires java.base. This is technically true, but it's missing the forest for the trees. The compilation unit that contains your implicitly declared class *already* has `import module java.base` at the top, per JEP 477. (And java.base is certainly in the default set of root modules for the unnamed module.) I think the trouble with java.se has led javac to forget that java.base (and hence ArrayList) is imported. Alex From amaembo at gmail.com Wed Jul 17 07:32:32 2024 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 17 Jul 2024 09:32:32 +0200 Subject: [module-imports] Importing java.se? In-Reply-To: References:

Message-ID: Hello! Thank you for the answer On Wed, Jul 17, 2024 at 2:06?AM Alex Buckley wrote: > > This is technically true, but it's missing the forest for the trees. The > compilation unit that contains your implicitly declared class *already* > has `import module java.base` at the top, per JEP 477. (And java.base is > certainly in the default set of root modules for the unnamed module.) I > think the trouble with java.se has led javac to forget that java.base > (and hence ArrayList) is imported. > In my sample, implicit class is not used. I think, at some point, beginners move away from implicit classes, and the question still remains, whether it's a reasonable idea to use `import module java.se`, or not. I find it strange that to import the whole Java SE API, one need to add two explicit imports (java.se and java.base) when not using implicit class. With best regards, Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Jul 17 18:08:33 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 17 Jul 2024 11:08:33 -0700 Subject: [External] : Re: [module-imports] Importing java.se? In-Reply-To: References:

Message-ID: On 7/17/2024 12:32 AM, Tagir Valeev wrote: > In my sample, implicit class is not used. I think, at some point, > beginners move away from implicit classes, and the question still > remains, whether it's a reasonable idea to use `import module java.se`, > or not. I find it strange that to import the whole Java SE API, one > need to add two explicit imports (java.se and java.base) when not > using implicit class. There are two problems: 1. A compilation unit in the unnamed module -- whether it has an implicitly declared class or an explicitly declared class -- cannot `import module java.se` or any other aggregator module. 2. A compilation unit in a named module (which implies an explicitly declared class) can `import module java.se` (provided of course that the named module `requires java.se`) ... but `import module java.se` does not have the effect of performing `import module java.base`, which needs to be done separately. Fixing #1 is hard because it requires a platform-wide change to the default set of root modules for the unnamed module. Fixing #2 so that `import module java.se` brings in java.base is also hard. A proposal is to allow `requires transitive java.base` so that the core modules of a framework, which never say `requires java.base` today, would say `requires transitive java.base` tomorrow. I don't like this proposal because every module in existence reads java.base already. It's a declaration-site approach that requires perfect awareness by module authors; we could achieve the same thing more straightforwardly at the use site, by decreeing that any use of `import module ...` implicitly performs `import module java.base` too. We'll discuss more when people get back from vacation. Alex From stephan.herrmann at berlin.de Wed Jul 17 18:28:01 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 17 Jul 2024 20:28:01 +0200 Subject: [module-imports] Importing java.se? In-Reply-To: References:

Message-ID: <0d6df64f-8ad7-4350-9252-ee47d65703a9@berlin.de> Hi Alex, On 17.07.24 02:06, Alex Buckley wrote: > Unfortunately, we overlooked how java.se is no longer (since JDK 11) > in the default set of root modules for the unnamed module. See > https://bugs.openjdk.org/browse/JDK-8205169. Which JEP brought that change? Where can we see the current state of those things that were specified directly in JEP 261? thanks, Stephan From alex.buckley at oracle.com Wed Jul 17 18:47:41 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 17 Jul 2024 11:47:41 -0700 Subject: [module-imports] Importing java.se? In-Reply-To: <0d6df64f-8ad7-4350-9252-ee47d65703a9@berlin.de> References:

<0d6df64f-8ad7-4350-9252-ee47d65703a9@berlin.de> Message-ID: <78a3467d-16bd-4082-a118-ae75e1b09894@oracle.com> On 7/17/2024 11:28 AM, Stephan Herrmann wrote: > On 17.07.24 02:06, Alex Buckley wrote: >> Unfortunately, we overlooked how java.se is no longer (since JDK 11) >> in the default set of root modules for the unnamed module. See >> https://bugs.openjdk.org/browse/JDK-8205169. > > Which JEP brought that change? > > Where can we see the current state of those things that were specified > directly in JEP 261? The change was made in 11 via the CSR that I linked (JDK-8205169). Although the change was documented in a release note, it is unfortunate that JEP 261 was not updated as a convenience for all the developers who we've pointed at 261 over the years. It will be updated soon. Alex From stephan.herrmann at berlin.de Wed Jul 17 20:01:21 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 17 Jul 2024 22:01:21 +0200 Subject: [module-imports] Importing java.se? In-Reply-To: <78a3467d-16bd-4082-a118-ae75e1b09894@oracle.com> References:

<0d6df64f-8ad7-4350-9252-ee47d65703a9@berlin.de> <78a3467d-16bd-4082-a118-ae75e1b09894@oracle.com> Message-ID: On 17.07.24 20:47, Alex Buckley wrote: > On 7/17/2024 11:28 AM, Stephan Herrmann wrote: >> On 17.07.24 02:06, Alex Buckley wrote: >>> Unfortunately, we overlooked how java.se is no longer (since JDK 11) >>> in the default set of root modules for the unnamed module. See >>> https://bugs.openjdk.org/browse/JDK-8205169. >> >> Which JEP brought that change? >> >> Where can we see the current state of those things that were >> specified directly in JEP 261? > > The change was made in 11 via the CSR that I linked (JDK-8205169). > > Although the change was documented in a release note, it is > unfortunate that JEP 261 was not updated as a convenience for all the > developers who we've pointed at 261 over the years. It will be updated > soon. That would be great! Where will the update be posted? Meanwhile I found this in the announcement on jigsaw-dev: ??? "As the policy is JDK-specific it means there aren't any specification changes." How does this match to the existence of a compiler that is not part of JDK? Should that compiler not implement the change? Stephan From alex.buckley at oracle.com Wed Jul 17 20:38:23 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 17 Jul 2024 13:38:23 -0700 Subject: [module-imports] Importing java.se? In-Reply-To: References:

<0d6df64f-8ad7-4350-9252-ee47d65703a9@berlin.de> <78a3467d-16bd-4082-a118-ae75e1b09894@oracle.com> Message-ID: <293ebacc-3d73-4984-9608-70ce181aecb4@oracle.com> On 7/17/2024 1:01 PM, Stephan Herrmann wrote: > Where will the update be posted? JEP 261 will be updated inline, in a way that distinguishes the original Java 9 rule from the Java 11 rule. > Meanwhile I found this in the announcement on jigsaw-dev: > ??? "As the policy is JDK-specific it means there aren't any > specification changes." > > How does this match to the existence of a compiler that is not part of > JDK? Should that compiler not implement the change? JEP 261 has scope SE, not scope JDK, so it was intended that the default set of root modules is a characteristic of the Java Platform, not just the OpenJDK implementation. We'll need to look into why java.lang.module says the default set of root modules is implementation specific, and why the CSR ended up with scope JDK. Alex From stephan.herrmann at berlin.de Wed Jul 17 21:32:49 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 17 Jul 2024 23:32:49 +0200 Subject: [module-imports] Importing java.se? In-Reply-To: <293ebacc-3d73-4984-9608-70ce181aecb4@oracle.com> References:

<0d6df64f-8ad7-4350-9252-ee47d65703a9@berlin.de> <78a3467d-16bd-4082-a118-ae75e1b09894@oracle.com> <293ebacc-3d73-4984-9608-70ce181aecb4@oracle.com> Message-ID: <27da41d0-c808-4cf7-8716-14cd9d6da23e@berlin.de> Thanks, Alex! On 17.07.24 22:38, Alex Buckley wrote: > On 7/17/2024 1:01 PM, Stephan Herrmann wrote: >> Where will the update be posted? > > JEP 261 will be updated inline, in a way that distinguishes the > original Java 9 rule from the Java 11 rule. > >> Meanwhile I found this in the announcement on jigsaw-dev: >> ???? "As the policy is JDK-specific it means there aren't any >> specification changes." >> >> How does this match to the existence of a compiler that is not part >> of JDK? Should that compiler not implement the change? > > JEP 261 has scope SE, not scope JDK, so it was intended that the > default set of root modules is a characteristic of the Java Platform, > not just the OpenJDK implementation. We'll need to look into why > java.lang.module says the default set of root modules is > implementation specific, and why the CSR ended up with scope JDK. > > Alex From stephan.herrmann at berlin.de Thu Jul 18 12:16:04 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Thu, 18 Jul 2024 14:16:04 +0200 Subject: More from the JEP 261 backlog Message-ID: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> In thread "[module-imports] Importing java.se" Alex mentioned a planned update to JEP 261. Now I wonder, if this is a suitable point in time to ask again about another specification issue in this area. JEP 261 lists among the new features a compiler option "--release", which was contributed by JEP 247. Now, JEP 261 is scope SE, but it "includes" JEP 247 which is declared as scope JDK. Similar to the discussion in the other thread, this does not answer, how a compiler which is not part of a JDK can possibly implement the "--release" option. Back at the time, we (Eclipse) had shyly asked for a specification of the format of file ct.sym. This specification was denied (it's internal, subject to change), and also the idea to provide an API instead didn't - to the best of my knowledge - bear any fruit. As a result the Eclipse compiler had to be based on reverse engineering of existing ct.sym files, and more than once the resulting heuristics were broken by changes in the file format. It seems that by now the file format has stabilized, so the easiest solution might be to + provide a specification of that format, and + provide information for which JDK versions this format can be assumed Please remember, that the Eclipse compiler must as best as possible be able to work with any released JDK out there, past and future. Most importantly, moving forward we'd appreciate some assurance that our implementation will not be broken again by future internal changes in OpenJDK. thanks, Stephan From jan.lahoda at oracle.com Thu Jul 18 13:12:54 2024 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 18 Jul 2024 15:12:54 +0200 Subject: More from the JEP 261 backlog In-Reply-To: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> References: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> Message-ID: <46c282bc-643b-4c7b-8cc6-cb0051cc4493@oracle.com> Hi Stephan, regarding ct.sym, my personal opinion: the format was never meant to be stable and publicly documented. The format is likely to change around JDK 36, if not earlier, when the current way to specify release version will run out. For having an API, there's this filled: https://bugs.openjdk.org/browse/JDK-8199521 It is likely possible to implement that, but I unfortunately can't promise it will be done in any specific release. In any case, it is not clear to me if using any of the above is necessarily reasonable for ecj. Wouldn't it be more appropriate to bundle the historical data with ecj? That would seem to improve predictability, as a given version of Eclipse would only have to worry about one specific (and known) format - instead of being at the mercy of whatever ct.sym happens to be defined in the JDK used to run Eclipse. Jan On 18. 07. 24 14:16, Stephan Herrmann wrote: > In thread "[module-imports] Importing java.se" Alex mentioned a > planned update to JEP 261. Now I wonder, if this is a suitable point > in time to ask again about another specification issue in this area. > > JEP 261 lists among the new features a compiler option "--release", > which was contributed by JEP 247. > > Now, JEP 261 is scope SE, but it "includes" JEP 247 which is declared > as scope JDK. > > Similar to the discussion in the other thread, this does not answer, > how a compiler which is not part of a JDK can possibly implement the > "--release" option. > > Back at the time, we (Eclipse) had shyly asked for a specification of > the format of file ct.sym. This specification was denied (it's > internal, subject to change), and also the idea to provide an API > instead didn't - to the best of my knowledge - bear any fruit. > > As a result the Eclipse compiler had to be based on reverse > engineering of existing ct.sym files, and more than once the resulting > heuristics were broken by changes in the file format. > > It seems that by now the file format has stabilized, so the easiest > solution might be to > + provide a specification of that format, and > + provide information for which JDK versions this format can be assumed > > Please remember, that the Eclipse compiler must as best as possible be > able to work with any released JDK out there, past and future. > > Most importantly, moving forward we'd appreciate some assurance that > our implementation will not be broken again by future internal changes > in OpenJDK. > > thanks, > Stephan From alex.buckley at oracle.com Thu Jul 18 17:01:38 2024 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 18 Jul 2024 10:01:38 -0700 Subject: More from the JEP 261 backlog In-Reply-To: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> References: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> Message-ID: <88c07996-53ef-4150-b45d-c97a28df7d88@oracle.com> On 7/18/2024 5:16 AM, Stephan Herrmann wrote: > JEP 261 lists among the new features a compiler option "--release", > which was contributed by JEP 247. > > Now, JEP 261 is scope SE, but it "includes" JEP 247 which is declared as > scope JDK. JEP 261 doesn't "include" JEP 247. JEP 261 merely refers to JEP 247 in the context of changes to JDK tools: ----- Finally, changes due to revisions to JDK-specific APIs and tools include: - The -Xbootclasspath and -Xbootclasspath/p options have been removed, as noted above. At compile time, the new --release option can be used to specify an alternate platform version (see JEP 247). At run time, the new --patch-module option, described above, can be used to inject content into system modules. ----- There is no implication here that --release is part of the Java Platform, or mandatory for all Java compilers. Nor is there any implication that javac's implementation of --release (including ct.sym) can be relied on by code outside the JDK. Alex From joe.darcy at oracle.com Tue Jul 23 04:13:38 2024 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 22 Jul 2024 21:13:38 -0700 Subject: More from the JEP 261 backlog In-Reply-To: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> References: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> Message-ID: <428971c0-d478-4384-a655-34eb3a277667@oracle.com> On 7/18/2024 5:16 AM, Stephan Herrmann wrote: > In thread "[module-imports] Importing java.se" Alex mentioned a > planned update to JEP 261. Now I wonder, if this is a suitable point > in time to ask again about another specification issue in this area. > > JEP 261 lists among the new features a compiler option "--release", > which was contributed by JEP 247. > > Now, JEP 261 is scope SE, but it "includes" JEP 247 which is declared > as scope JDK. > > Similar to the discussion in the other thread, this does not answer, > how a compiler which is not part of a JDK can possibly implement the > "--release" option. > > Back at the time, we (Eclipse) had shyly asked for a specification of > the format of file ct.sym. This specification was denied (it's > internal, subject to change), and also the idea to provide an API > instead didn't - to the best of my knowledge - bear any fruit. > > As a result the Eclipse compiler had to be based on reverse > engineering of existing ct.sym files, and more than once the resulting > heuristics were broken by changes in the file format. > > It seems that by now the file format has stabilized, so the easiest > solution might be to > + provide a specification of that format, and > + provide information for which JDK versions this format can be assumed > > Please remember, that the Eclipse compiler must as best as possible be > able to work with any released JDK out there, past and future. > > Most importantly, moving forward we'd appreciate some assurance that > our implementation will not be broken again by future internal changes > in OpenJDK. > So, to summarize, Eclipse knowingly used a non-documented JDK-internal interface and then had to be updated when the non-documented JDK-internal interface evolved. Presumably if one wanted to work only from specifications, the necessary Java SE API information could be extracted from the javadoc bundles for the Java SE platform releases, with some amount of effort. -Joe From joe.darcy at oracle.com Tue Jul 23 04:13:38 2024 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 22 Jul 2024 21:13:38 -0700 Subject: More from the JEP 261 backlog In-Reply-To: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> References: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> Message-ID: <428971c0-d478-4384-a655-34eb3a277667@oracle.com> On 7/18/2024 5:16 AM, Stephan Herrmann wrote: > In thread "[module-imports] Importing java.se" Alex mentioned a > planned update to JEP 261. Now I wonder, if this is a suitable point > in time to ask again about another specification issue in this area. > > JEP 261 lists among the new features a compiler option "--release", > which was contributed by JEP 247. > > Now, JEP 261 is scope SE, but it "includes" JEP 247 which is declared > as scope JDK. > > Similar to the discussion in the other thread, this does not answer, > how a compiler which is not part of a JDK can possibly implement the > "--release" option. > > Back at the time, we (Eclipse) had shyly asked for a specification of > the format of file ct.sym. This specification was denied (it's > internal, subject to change), and also the idea to provide an API > instead didn't - to the best of my knowledge - bear any fruit. > > As a result the Eclipse compiler had to be based on reverse > engineering of existing ct.sym files, and more than once the resulting > heuristics were broken by changes in the file format. > > It seems that by now the file format has stabilized, so the easiest > solution might be to > + provide a specification of that format, and > + provide information for which JDK versions this format can be assumed > > Please remember, that the Eclipse compiler must as best as possible be > able to work with any released JDK out there, past and future. > > Most importantly, moving forward we'd appreciate some assurance that > our implementation will not be broken again by future internal changes > in OpenJDK. > So, to summarize, Eclipse knowingly used a non-documented JDK-internal interface and then had to be updated when the non-documented JDK-internal interface evolved. Presumably if one wanted to work only from specifications, the necessary Java SE API information could be extracted from the javadoc bundles for the Java SE platform releases, with some amount of effort. -Joe From stephan.herrmann at berlin.de Tue Jul 23 13:30:23 2024 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 23 Jul 2024 15:30:23 +0200 Subject: More from the JEP 261 backlog In-Reply-To: <428971c0-d478-4384-a655-34eb3a277667@oracle.com> References: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> <428971c0-d478-4384-a655-34eb3a277667@oracle.com> Message-ID: <45063f61-5b0b-429f-b930-20b21a39ebb0@berlin.de> Alex, Joe, From both your answers I learned that I was working from assumptions that are not shared by Oracle. I apologize. Just to show where we are coming from, and to mention that all this was done in the best of intentions to help the Java community at large, some words of explanation: Back in the time of JEP 261, we - developers of the Eclipse compiler for Java, who are not laywers - believed that we were required to implement the --release option in order to claim support for Java 9. Within the existing architectural context, using information from ct.sym was literally the only possibility we saw. As of now the underlying problem remains, but we'll have to come back with a different set of questions. regards, Stephan From jonathan.gibbons at oracle.com Tue Jul 23 22:09:08 2024 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Jul 2024 15:09:08 -0700 Subject: More from the JEP 261 backlog In-Reply-To: <45063f61-5b0b-429f-b930-20b21a39ebb0@berlin.de> References: <3972cfbb-2261-4be0-a435-c3fd4c744641@berlin.de> <428971c0-d478-4384-a655-34eb3a277667@oracle.com> <45063f61-5b0b-429f-b930-20b21a39ebb0@berlin.de> Message-ID: Stephan, While the encoding used for `ct.sym` may be an internal implementation detail, the question you maybe should be asking is, "what is the content?" as in, "what are the modules (if any), classes, interfaces, and their members, that are deemed to be part of the "public" API for that release. If you start with modules (JDK 9 and later) beginning with `java.*` or `jdk.*` that do not include the word`internal`, and look for the public classes in the exported packages of those modules, you'll be off to a good start. Once you have the filter, at least for releases using modules, should be easy enough to write an annotation processor that can list the relevant API in any given release of JDK. For releases before JDK 9, the top-level filter may be a little more ad-hoc. -- Jon On 7/23/24 6:30 AM, Stephan Herrmann wrote: > Alex, Joe, > > From both your answers I learned that I was working from assumptions > that are not shared by Oracle. I apologize. > > Just to show where we are coming from, and to mention that all this > was done in the best of intentions to help the Java community at > large, some words of explanation: > > Back in the time of JEP 261, we - developers of the Eclipse compiler > for Java, who are not laywers - believed that we were required to > implement the --release option in order to claim support for Java 9. > Within the existing architectural context, using information from > ct.sym was literally the only possibility we saw. > > As of now the underlying problem remains, but we'll have to come back > with a different set of questions. > > regards, > Stephan >