From jlahoda at openjdk.org Mon Sep 4 08:39:47 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 4 Sep 2023 08:39:47 GMT Subject: Integrated: 8314662: jshell shows duplicated signatures of javap In-Reply-To: References: Message-ID: <2jcAlPR3iwTB0VuXqnCjVjzQI6DfWPx5gT20OHYNP5Y=.4e11dd9a-1008-4c86-958b-af59f2842bdc@github.com> On Wed, 30 Aug 2023 10:53:15 GMT, Jan Lahoda wrote: > The Scope may contain duplicated entries (e.g. for duplicated static imports, as in this case), which may then show as duplicate signatures in JShell. > > The proposal here is to avoid using the duplicates, by using `LinkedHashSet`. This pull request has now been integrated. Changeset: 3094fd1a Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/3094fd1ac5153289434515d9b718bc5d6885b7dc Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod 8314662: jshell shows duplicated signatures of javap Reviewed-by: asotona, cstein ------------- PR: https://git.openjdk.org/jdk/pull/15489 From acobbs at openjdk.org Thu Sep 7 00:29:11 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 7 Sep 2023 00:29:11 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v12] In-Reply-To: References: Message-ID: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'master' into SuperInit - Eliminate "isSelfCall" flag, which is now made obsolete by "ctorPrologue". - Merge branch 'master' into SuperInit - Create and cache a single instance of the oft-used SuperThisChecker. - Add unit test verifying super() can't appear inside a lambda. - Use TreeInfo.isConstructor() for detecting constructors. - Merge branch 'master' into SuperInit - Fix mistake in previous merge commit 80ba6be4. - Merge branch 'master' into SuperInit - Rename unit test to be consistent with other feature exampless. - ... and 21 more: https://git.openjdk.org/jdk/compare/5cbff246...4ff4c5c5 ------------- Changes: https://git.openjdk.org/jdk/pull/13656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=11 Stats: 1500 lines in 27 files changed: 1174 ins; 214 del; 112 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From acobbs at openjdk.org Thu Sep 7 00:31:47 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 7 Sep 2023 00:31:47 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v11] In-Reply-To: References:

Message-ID: On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs wrote: >> This is a first draft of a patch for JEP 447. >> >> Summary of changes: >> >> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` >> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context >> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` >> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement >> >> The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. >> >> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Merge branch 'master' into SuperInit > - Create and cache a single instance of the oft-used SuperThisChecker. > - Add unit test verifying super() can't appear inside a lambda. > - Use TreeInfo.isConstructor() for detecting constructors. > - Merge branch 'master' into SuperInit > - Fix mistake in previous merge commit 80ba6be4. > - Merge branch 'master' into SuperInit > - Rename unit test to be consistent with other feature exampless. > - Update unit test after merged-in commit eaa80ad08. > - Add unit tests with local class decl's prior to super(). > - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137 Regarding the latest update: In some cases the compiler was treating code before `super()` differently from code inside `super()` parameter expressions, although they should be exactly the same (the constructor "prologue" rules apply to both). This is fixed by removing some leftover/redundant code. In summary, the `isSelfCall` flag is made obsolete by the newer, more general flag `ctorPrologue`, so it can be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1709294538 From jlu at openjdk.org Tue Sep 12 22:04:12 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 12 Sep 2023 22:04:12 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native Message-ID: JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). ------------- Commit messages: - Update header / copyright for CurrencyFormat - Adjust CurrencyFormat test to read in .properties with UTF-8 - Convert unicode escape sequences to native - Add clarifying comment in Bug6204853 for lack of conversion - Read JDK properties files in UTF-8 during build process for LRB Changes: https://git.openjdk.org/jdk/pull/15694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301991 Stats: 28966 lines in 488 files changed: 14 ins; 0 del; 28952 mod Patch: https://git.openjdk.org/jdk/pull/15694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694 PR: https://git.openjdk.org/jdk/pull/15694 From liach at openjdk.org Tue Sep 12 23:16:40 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 12 Sep 2023 23:16:40 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu wrote: > JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 227: > 225: try (FileInputStream input = new FileInputStream(propertiesPath); > 226: // Read in JDK .properties files in UTF-8 > 227: InputStreamReader streamReader = new InputStreamReader(input, StandardCharsets.UTF_8) Can we just uses `Files.newBufferedReader(Path.of(propertiesPath))` instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1323716978 From jlu at openjdk.org Wed Sep 13 17:38:28 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 13 Sep 2023 17:38:28 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: > JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Replace InputStreamReader with BufferedReader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15694/files - new: https://git.openjdk.org/jdk/pull/15694/files/0f3698a5..ceb48bbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00-01 Stats: 18 lines in 2 files changed: 6 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694 PR: https://git.openjdk.org/jdk/pull/15694 From naoto at openjdk.org Wed Sep 13 18:14:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 13 Sep 2023 18:14:41 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References:

Message-ID: On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. >> >> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. >> >> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) >> >> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. >> >> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Replace InputStreamReader with BufferedReader Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15694#pullrequestreview-1625154951 From jlu at openjdk.org Wed Sep 13 18:46:38 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 13 Sep 2023 18:46:38 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References:

Message-ID: On Wed, 13 Sep 2023 18:12:15 GMT, Naoto Sato wrote: > Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion. Thanks for the review; (In addition to testing), I ran a script to verify only white space escape sequences exist in JDK .properties files. (Excluding escape sequences in test files that should remain as is for the purpose of the test) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-1718139807 From acobbs at openjdk.org Thu Sep 14 01:02:50 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 14 Sep 2023 01:02:50 GMT Subject: RFR: 8314327: Issues with JShell when using "local" execution engine In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 14:55:54 GMT, Archie Cobbs wrote: > There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control. > > **Background** > > JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely. > > For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input. > > Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function). > > **Issue 1** > > The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine. As a result, it's impossible to resolve any of these classes. > > **Issue 2** > > JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option". > > However, the "local" execution engine ignores the remote VM options. > > Here's a simple demonstration: > > > $ ls classes/test/Foo.class > classes/test/Foo.class > $ jshell --execution=local --class-path classes > | Welcome to JShell -- Version 20.0.1 > | For an introduction type: /help intro > > jshell> Class.forName("test.Foo"); > | Exception java.lang.ClassNotFoundException: test.Foo > | at URLClassLoader.findClass (URLClassLoader.java:445) > | at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154) > | at ... @lahodaj would you mind reviewing the CSR? [JDK-8314328](https://bugs.openjdk.org/browse/JDK-8314328) Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15311#issuecomment-1718501303 From jlu at openjdk.org Thu Sep 14 22:22:50 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 14 Sep 2023 22:22:50 GMT Subject: Integrated: 8301991: Convert l10n properties resource bundles to UTF-8 native In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu wrote: > JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. > > This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. > > The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) > > The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. > > If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). This pull request has now been integrated. Changeset: b55e418a Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/b55e418a077791b39992042411cde97f68dc39fe Stats: 28964 lines in 488 files changed: 12 ins; 0 del; 28952 mod 8301991: Convert l10n properties resource bundles to UTF-8 native Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/15694 From abimpoudis at openjdk.org Fri Sep 15 15:46:04 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 15 Sep 2023 15:46:04 GMT Subject: RFR: 8315588: JShell does not accept underscore from JEP 443 even with --enable-preview Message-ID: The current status is that we get an `UNKNOWN` status for those incomplete snippets that involve underscore declaring local variables or patterns. Those should have been classified as `DEFINITELY_INCOMPLETE`. This process takes place in `SourceCodeAnalysisImpl` and `CompletenessAnalyzer` and the processing that takes place regarded `_` as a location of kind `XERR0`. It would be correct now to classify it with `XDECL1`?. ------------- Commit messages: - 8315588: JShell does not accept underscore from JEP 443 even with --enable-preview Changes: https://git.openjdk.org/jdk/pull/15765/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15765&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315588 Stats: 80 lines in 2 files changed: 78 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15765.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15765/head:pull/15765 PR: https://git.openjdk.org/jdk/pull/15765 From acobbs at openjdk.org Sat Sep 16 21:52:14 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 16 Sep 2023 21:52:14 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v13] In-Reply-To: References: Message-ID: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Change the error message to match the applicable spec rule. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13656/files - new: https://git.openjdk.org/jdk/pull/13656/files/4ff4c5c5..a5510b79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=11-12 Stats: 13 lines in 3 files changed: 0 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From acobbs at openjdk.org Fri Sep 22 22:02:04 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 22 Sep 2023 22:02:04 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References: Message-ID: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove obsolete flag "constructorArgs". ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13656/files - new: https://git.openjdk.org/jdk/pull/13656/files/a5510b79..599cf0e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=12-13 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From liach at openjdk.org Sat Sep 23 02:02:24 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 23 Sep 2023 02:02:24 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

Message-ID: On Sat, 23 Sep 2023 01:59:27 GMT, Chen Liang wrote: > Should we make pre-initialization local classes static to ease the compiler implementation for "regulated Constructors" in the future? I could be missing something but I don't see a potential problem. All of the actions that would be prohibited in regulated constructors will be prohibited in a pre-construction context, so the compiler should already be doing the right thing. If I understand your question, the particular action you're worried about is "Construction of an inner class with this as an implicit enclosing instance". But that can't happen in a pre-construction context - you can _declare_ a local class in a pre-construction context, you just can't _instantiate_ it. Here's an example: public class Test { public int x; public Test() { class Local { { System.out.println(x); } } //new Local(); // would be illegal super(); new Local(); // this is ok! } } Note, this is a subtlety that didn't exist before, because there was no way to declare a local class that required an outer instance before `super()` and then instantiate it after `super()`. Therefore, there was no reason to allow even the declaration such a class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732194677 From liach at openjdk.org Sat Sep 23 07:01:23 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 23 Sep 2023 07:01:23 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

Message-ID: On Sat, 23 Sep 2023 06:57:30 GMT, Chen Liang wrote: > I understand what you mean, since you've clarified long ago. Instead, I mean this from JEP 401: > > > Local and anonymous classes may be declared, but (as in a static context) they have no enclosing instance. > > Currently local classes declared in pre-construction context have an enclosing instance, and I wonder if we can make them not require enclosing instances like in a static context. Local classes declared after the super/this delegate constructor call in source code will still have an enclosing instance. The problem is that this is not how the compiler currently behaves. Consider this class: public class Test { public Test(int x) { } public Test() { this(switch (0) { default -> { class Local { } yield 0; } }); } } According to JLS 21 ?15.9.2, class `Local` does not have an enclosing instance. Yet here is what's actually emitted by the compiler: $ javap -classpath classes -c Test$1Local Compiled from "Test.java" class Test$1Local { final Test this$0; Test$1Local(Test); Code: 0: aload_0 1: aload_1 2: putfield #1 // Field this$0:LTest; 5: aload_0 6: invokespecial #7 // Method java/lang/Object."":()V 9: return } An explicit goal of JEP 447 is **any existing program must compile to the same bytecode**. So if we adhere to that goal, local classes declared in pre-construction contexts must have outer instances. I think this is the most natural behavior anyway. Anonymous classes, with their "immediate enclosing instance with respect to superclass S", and their declare-and-instantiate-all-at-once property, are the oddballs. It's appropriate for them to have a special rule where their implicit outer instance "disappears" in a pre-construction context because it would never be possible to provide one. So my suggestion is to alter this wording in JEP 401: > Local and anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error. > > These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields. To this: > Local classes may be declared, but since they require an enclosing instance, they can't be instantiated. Anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error. > > These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields. Also: > I think there are already similar rules implemented for anonymous classes before this JEP, where the anonymous `Cat$1` (printing "Running") does not require an implicit `Cat` for its constructor while `Cat$2` (printing "Meow") does after compilation: As remarked above, anonymous classes are different. It's not possible to declare them in one place and instantiate them in another place, so they indeed will not have enclosing instances when declared in a pre-construction context but will have them otherwise, and this behavior is not changing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732340240 From liach at openjdk.org Sat Sep 23 15:30:12 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 23 Sep 2023 15:30:12 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

Message-ID: On Fri, 22 Sep 2023 22:02:04 GMT, Archie Cobbs wrote: >> This is a first draft of a patch for JEP 447. >> >> Summary of changes: >> >> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` >> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context >> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` >> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement >> >> The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. >> >> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete flag "constructorArgs". src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 485: > 483: // Do something with all static or non-static field initializers and initialization blocks. > 484: // Note: This method also sends nested class definitions to the handler. > 485: protected void forEachInitializer(JCClassDecl classDef, boolean statik, Consumer handler) { Suggestion: protected void forEachInitializer(JCClassDecl classDef, boolean isStatic, Consumer handler) { src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4613: > 4611: * early accesses within a constructor prologue. > 4612: */ > 4613: class RefBeforeCtorCalledError extends InvalidSymbolError { Why doesn't this subclass StaticError? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335582828 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335580983 From acobbs at openjdk.org Mon Sep 25 13:35:11 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 13:35:11 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v15] In-Reply-To: References: Message-ID: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Change variable name "statik" -> "isStatic" per review recommendation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13656/files - new: https://git.openjdk.org/jdk/pull/13656/files/599cf0e5..150d794c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=13-14 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From acobbs at openjdk.org Mon Sep 25 13:35:15 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 13:35:15 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 08:50:03 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove obsolete flag "constructorArgs". > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 485: > >> 483: // Do something with all static or non-static field initializers and initialization blocks. >> 484: // Note: This method also sends nested class definitions to the handler. >> 485: protected void forEachInitializer(JCClassDecl classDef, boolean statik, Consumer handler) { > > Suggestion: > > protected void forEachInitializer(JCClassDecl classDef, boolean isStatic, Consumer handler) { Fixed in 150d794c1e6, thanks. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4613: > >> 4611: * early accesses within a constructor prologue. >> 4612: */ >> 4613: class RefBeforeCtorCalledError extends InvalidSymbolError { > > Why doesn't this subclass StaticError? In the new specification, constructor prologues are no longer considered a static context. Instead they're a pre-construction context (new concept). So emitting an error that says something "cannot be referenced from a static context" would be wrong. The new exception class `RefBeforeCtorCalledError` is intended to be the pre-construction context analogue of `StaticError`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335890156 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335887916 From abimpoudis at openjdk.org Mon Sep 25 13:40:07 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 25 Sep 2023 13:40:07 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) Message-ID: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html ------------- Commit messages: - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303374 Stats: 2293 lines in 29 files changed: 2186 ins; 16 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From mcimadamore at openjdk.org Mon Sep 25 13:50:27 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 13:50:27 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 13:25:33 GMT, Archie Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4613: >> >>> 4611: * early accesses within a constructor prologue. >>> 4612: */ >>> 4613: class RefBeforeCtorCalledError extends InvalidSymbolError { >> >> Why doesn't this subclass StaticError? > > In the new specification, constructor prologues are no longer considered a static context. Instead they're a pre-construction context (new concept). So emitting an error that says something "cannot be referenced from a static context" would be wrong. The new exception class `RefBeforeCtorCalledError` is intended to be the pre-construction context analogue of `StaticError`. I'm aware of that - but I note that the implementation uses a STATIC_ERR under the hood. Hence my comment on using a custom static error with a custom diagnostic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335916998 From acobbs at openjdk.org Mon Sep 25 13:58:17 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 13:58:17 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

Message-ID: <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com> On Mon, 25 Sep 2023 13:47:48 GMT, Maurizio Cimadamore wrote: >> In the new specification, constructor prologues are no longer considered a static context. Instead they're a pre-construction context (new concept). So emitting an error that says something "cannot be referenced from a static context" would be wrong. The new exception class `RefBeforeCtorCalledError` is intended to be the pre-construction context analogue of `StaticError`. > > I'm aware of that - but I note that the implementation uses a STATIC_ERR under the hood. Hence my comment on using a custom static error with a custom diagnostic. Oh I see. Hmm, I'll admit ignorance on how exactly these `Kind` enum error values like `STATICERR`, `HIDDEN`, etc. are used. Is there a better `Kind` choice for this error? Or does this warrant a new `Kind` value? In the latter case, there is a scary warning about ordering of the enum values so any advice appreciated. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335927718 From mcimadamore at openjdk.org Mon Sep 25 14:06:15 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 14:06:15 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com> References:

<8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com> Message-ID: On Mon, 25 Sep 2023 13:55:44 GMT, Archie Cobbs wrote: >> I'm aware of that - but I note that the implementation uses a STATIC_ERR under the hood. Hence my comment on using a custom static error with a custom diagnostic. > > Oh I see. Hmm, I'll admit ignorance on how exactly these `Kind` enum error values like `STATICERR`, `HIDDEN`, etc. are used. Is there a better `Kind` choice for this error? Or does this warrant a new `Kind` value? In the latter case, there is a scary warning about ordering of the enum values so any advice appreciated. Thanks. The kind is used in some other parts of Resolve to determine whether some errors should be skipped in some places, or recovered from. I'd advise against creating a new error kind, which might end up invalidating some existing check which depend on STATICERR. E.g.: final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) { return phase.ordinal() > maxPhase.ordinal() || !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS || sym.kind == STATICERR; } E.g. you don't want overload resolution to try new candidates because you tried to call a method and you don't have a `this` - e.g. the compiler behavior should be similar as to when an instance method is called and no `this` is available (meaning: the found method is correct, and the error should be reported, no attempt should be made at recovery). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335937230 From acobbs at openjdk.org Mon Sep 25 14:30:20 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 14:30:20 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

<8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com> Message-ID: <_ovfBS7NlI8s2JxQlQtchzHzbg5VNyfyV-6qmyvGY84=.c3e7ef1a-525f-4b6b-995e-3da3c3b61f67@github.com> On Mon, 25 Sep 2023 14:02:53 GMT, Maurizio Cimadamore wrote: >> Oh I see. Hmm, I'll admit ignorance on how exactly these `Kind` enum error values like `STATICERR`, `HIDDEN`, etc. are used. Is there a better `Kind` choice for this error? Or does this warrant a new `Kind` value? In the latter case, there is a scary warning about ordering of the enum values so any advice appreciated. Thanks. > > The kind is used in some other parts of Resolve to determine whether some errors should be skipped in some places, or recovered from. I'd advise against creating a new error kind, which might end up invalidating some existing check which depend on STATICERR. E.g.: > > > final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) { > return phase.ordinal() > maxPhase.ordinal() || > !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS || sym.kind == STATICERR; > } > > > E.g. you don't want overload resolution to try new candidates because you tried to call a method and you don't have a `this` - e.g. the compiler behavior should be similar as to when an instance method is called and no `this` is available (meaning: the found method is correct, and the error should be reported, no attempt should be made at recovery). OK got it. So what if we did this instead? diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java index 295bb192a42..4c7c177163f 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java @@ -4576,7 +4587,11 @@ JCDiagnostic inaccessiblePackageReason(Env env, PackageSymbol sym) class StaticError extends InvalidSymbolError { StaticError(Symbol sym) { - super(STATICERR, sym, "static error"); + this(sym, "static error"); + } + + StaticError(Symbol sym, String debugName) { + super(STATICERR, sym, debugName); } @Override @@ -4595,6 +4610,32 @@ JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind, } } + /** + * Specialization of {@link InvalidSymbolError} for illegal + * early accesses within a constructor prologue. + */ + class RefBeforeCtorCalledError extends StaticError { + + RefBeforeCtorCalledError(Symbol sym) { + super(sym, "prologue error"); + } + + @Override + JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind, + DiagnosticPosition pos, + Symbol location, + Type site, + Name name, + List argtypes, + List typeargtypes) { + Symbol errSym = ((sym.kind == TYP && sym.type.hasTag(CLASS)) + ? types.erasure(sym.type).tsym + : sym); + return diags.create(dkind, log.currentSource(), pos, + "cant.ref.before.ctor.called", errSym); + } + } + /** * InvalidSymbolError error class indicating that a pair of symbols * (either methods, constructors or operands) are ambiguous @@ -4708,7 +4749,7 @@ class BadMethodReferenceError extends StaticError { boolean unboundLookup; public BadMethodReferenceError(Symbol sym, boolean unboundLookup) { - super(sym); + super(sym, "bad method ref error"); this.unboundLookup = unboundLookup; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335969649 From mcimadamore at openjdk.org Mon Sep 25 15:10:19 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 15:10:19 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: <_ovfBS7NlI8s2JxQlQtchzHzbg5VNyfyV-6qmyvGY84=.c3e7ef1a-525f-4b6b-995e-3da3c3b61f67@github.com> References:

<8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com> <_ovfBS7NlI8s2JxQlQtchzHzbg5VNyfyV-6qmyvGY84=.c3e7ef1a-525f-4b6b-995e-3da3c3b61f67@github.com> Message-ID: On Mon, 25 Sep 2023 14:27:04 GMT, Archie Cobbs wrote: >> The kind is used in some other parts of Resolve to determine whether some errors should be skipped in some places, or recovered from. I'd advise against creating a new error kind, which might end up invalidating some existing check which depend on STATICERR. E.g.: >> >> >> final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) { >> return phase.ordinal() > maxPhase.ordinal() || >> !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS || sym.kind == STATICERR; >> } >> >> >> E.g. you don't want overload resolution to try new candidates because you tried to call a method and you don't have a `this` - e.g. the compiler behavior should be similar as to when an instance method is called and no `this` is available (meaning: the found method is correct, and the error should be reported, no attempt should be made at recovery). > > OK got it. So what if we did this instead? > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > index 295bb192a42..4c7c177163f 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > @@ -4576,7 +4587,11 @@ JCDiagnostic inaccessiblePackageReason(Env env, PackageSymbol sym) > class StaticError extends InvalidSymbolError { > > StaticError(Symbol sym) { > - super(STATICERR, sym, "static error"); > + this(sym, "static error"); > + } > + > + StaticError(Symbol sym, String debugName) { > + super(STATICERR, sym, debugName); > } > > @Override > @@ -4595,6 +4610,32 @@ JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind, > } > } > > + /** > + * Specialization of {@link InvalidSymbolError} for illegal > + * early accesses within a constructor prologue. > + */ > + class RefBeforeCtorCalledError extends StaticError { > + > + RefBeforeCtorCalledError(Symbol sym) { > + super(sym, "prologue error"); > + } > + > + @Override > + JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind, > + DiagnosticPosition pos, > + Symbol location, > + Type site, > + Name name, > + List argtypes, > + List typeargtypes) { > + Symbol errSym = ((sym.kind == TYP && sym.type.hasTag(CLASS)) > + ? types.erasure(sym.type).tsym > + : sym); > + return diags.create(dkind, log.currentSource(), pos, > + "cant.ref.before.ctor.called", errSym); > + } > + } > + > /** > * InvalidSymbolError error class indicating that a pair of symbols > * (either methods, constructors or operands) are ambiguous > @@ -4708,7 +4749,7 @@ class BadMethodReferenceError extends StaticError { > boolean unboundLookup; > > public BadMethodReferenceError(Symbol sym, boolean unboundLookup) { > - super(sym); > + super(sym, "bad method ref error"); > this.unboundLookup = unboundLookup; > } Yes, I think that is what I was referring to. Thanks for the patience. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336028332 From acobbs at openjdk.org Mon Sep 25 16:04:09 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 16:04:09 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References: Message-ID: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Have RefBeforeCtorCalledError extend StaticError and customize debug strings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13656/files - new: https://git.openjdk.org/jdk/pull/13656/files/150d794c..3e75e19e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=14-15 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From acobbs at openjdk.org Mon Sep 25 16:04:12 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 16:04:12 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

Message-ID: <22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com> Hi Archie, Anything concerning the science of when nested classes have enclosing instances is pretty scary, so I'd like to make sure we're all heading in the same direction. On 9/23/2023 8:19 AM, Archie Cobbs wrote: > public class Test { > public Test(int x) { > } > > public Test() { > this(switch (0) { > default -> { > class Local { > } > yield 0; > } > }); > } > } > > According to JLS 21 ?15.9.2, class `Local` does not have an enclosing instance. > > Yet here is what's actually emitted by the compiler: > > $ javap -classpath classes -c Test$1Local > Compiled from "Test.java" > class Test$1Local { > final Test this$0; > > Test$1Local(Test); > Code: > 0: aload_0 > 1: aload_1 > 2: putfield #1 // Field this$0:LTest; > 5: aload_0 > 6: invokespecial #7 // Method java/lang/Object."":()V > 9: return > } JLS 15.9.2 says what happens when an inner local class is instantiated, but does not determine whether Local is declared as inner in the first place. JLS 8.1.3 is where we find that Local is specified to be inner (because it is not implicitly static). So, javac's emission of Test$1Local is in line with the JLS -- great! > An explicit goal of JEP 447 is **any existing program must compile to > the same bytecode**. So if we adhere to that goal, local classes > declared in pre-construction contexts must have outer instances. I don't see this explicit goal stated in JEP 447. There's a sentence about compilation in Testing -- "We will compile all JDK classes using the previous and new versions of the compiler and verify that the resulting bytecode is identical." -- but that sounds merely like a nice-to-have property, and one which holds only for JDK classes. If 100% class file compatibility for all existing source code is a goal, then please say that in the Goals and give an example in the Description. ("compiles to same bytecode" is actually a higher bar than binary compatibility, which is why I didn't say "100% binary compatibility".) > I think this is the most natural behavior anyway. Anonymous classes, > with their "immediate enclosing instance with respect to superclass S", > and their declare-and-instantiate-all-at-once property, are the > oddballs. It's appropriate for them to have a special rule where their > implicit outer instance "disappears" in a pre-construction context > because it would never be possible to provide one. I'm not, per se, disagreeing with specifying that local classes declared in a pre-construction context are inner. It's certainly attractive from a compatibility POV to be able to move a local class declaration around within a constructor body (maybe before super(..)/this(..), maybe after) and observe no class file change because the local class is always inner (unless it's a local enum class or local record class of course). On the other hand, we have to guarantee that no instantiation of the local class is possible before super(..)/this(..) has completed normally. Here's a program that tries to instantiate a Local which observes x with a value other than 5. What does the JLS say about the program? What does javac do? public class Test { public int x = 5; public Test(int i) {} public Test() { class Local { { System.out.println(x); } } try { this(switch (0) { default -> throw new Exception(); }); } finally { new Local(); // Legal or illegal? } } } Don't worry about JEP 401 until JEP 447 has thoroughly clarified the matter of whether such local classes are inner or not. Alex > So my suggestion is to alter this wording in JEP 401: > >> Local and anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error. >> >> These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields. > > To this: > >> Local classes may be declared, but since they require an enclosing instance, they can't be instantiated. Anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error. >> >> These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields. > > Also: > >> I think there are already similar rules implemented for anonymous classes before this JEP, where the anonymous `Cat$1` (printing "Running") does not require an implicit `Cat` for its constructor while `Cat$2` (printing "Meow") does after compilation: > > As remarked above, anonymous classes are different. It's not possible to declare them in one place and instantiate them in another place, so they indeed will not have enclosing instances when declared in a pre-construction context but will have them otherwise, and this behavior is not changing. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732340240 From mcimadamore at openjdk.org Mon Sep 25 16:53:22 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 16:53:22 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v7] In-Reply-To: References:

Message-ID: On Fri, 7 Jul 2023 18:32:36 GMT, Vicente Romero wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into SuperInit >> - Fix mistake in previous merge commit 80ba6be4. >> - Merge branch 'master' into SuperInit >> - Rename unit test to be consistent with other feature exampless. >> - Update unit test after merged-in commit eaa80ad08. >> - Add unit tests with local class decl's prior to super(). >> - Merge branch 'master' into SuperInit >> - Use @enablePreview in tests in preference to explicit command line flags. >> - Make "statements before super()" support a preview feature. >> >> Thanks to Jim Laskey for help with preview logic. >> - Small refactoring to avoid redundant test. >> - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3975: > >> 3973: } >> 3974: >> 3975: private class SuperThisChecker extends TreeScanner { > > we usually create only one instance of these type of visitors that will be used very often and reuse it whenever necessary Actually, I disagree a bit with the direction here. Having more mutable state is, I believe, not great. In this case the state has to be discarded after a call to `check`, so IMHO having mutable state lying around is a smell. What do you think @vicente-romero-oracle ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336156335 From mcimadamore at openjdk.org Mon Sep 25 17:02:17 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 17:02:17 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 16:04:09 GMT, Archie Cobbs wrote: >> This is a first draft of a patch for JEP 447. >> >> Summary of changes: >> >> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` >> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context >> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` >> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement >> >> The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. >> >> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Have RefBeforeCtorCalledError extend StaticError and customize debug strings. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3971: > 3969: > 3970: // Match this scan stack: 1=JCMethodDecl, 2=JCExpressionStatement, 3=JCMethodInvocation > 3971: private static final int MATCH_SCAN_DEPTH = 3; This logic seems a bit fragile in that it relies on the shape of the AST. Also, in principle you can create something that will overflow the int, and will cause the check to spuriously pass for a very very very large number of nested expressions :-) That said, I understand that, in order to make this code "tighter", you would need to override al visitors that can "nest" code inside other code, which is also not great. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336166162 From mcimadamore at openjdk.org Mon Sep 25 17:07:17 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 17:07:17 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 16:04:09 GMT, Archie Cobbs wrote: >> This is a first draft of a patch for JEP 447. >> >> Summary of changes: >> >> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` >> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context >> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` >> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement >> >> The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. >> >> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Have RefBeforeCtorCalledError extend StaticError and customize debug strings. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1511: > 1509: if (staticOnly) > 1510: return new StaticError(sym); > 1511: if (env1.info.ctorPrologue && (sym.flags_field & SYNTHETIC) == 0) where does the SYNTHETIC check comes from? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2016: > 2014: if (staticOnly) > 2015: return new StaticError(sym); > 2016: if (env1.info.ctorPrologue && env1 == env) where does `env1 == env` come from? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336170440 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336170745 From archie.cobbs at gmail.com Mon Sep 25 17:13:10 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 25 Sep 2023 12:13:10 -0500 Subject: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: <22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com> References:

<22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com> Message-ID: Hi Alex, > > An explicit goal of JEP 447 is **any existing program must compile to > > the same bytecode**. So if we adhere to that goal, local classes > > declared in pre-construction contexts must have outer instances. > I don't see this explicit goal stated in JEP 447. There's a sentence > about compilation in Testing -- "We will compile all JDK classes using > the previous and new versions of the compiler and verify that the > resulting bytecode is identical." -- but that sounds merely like a > nice-to-have property, and one which holds only for JDK classes. > You're right.. the stated goal is actually "Do not change the behavior of any existing program." Making sure the emitted bytecode matches is just one way to accomplish that goal (and possibly overkill). > I think this is the most natural behavior anyway. Anonymous classes, > > with their "immediate enclosing instance with respect to superclass S", > > and their declare-and-instantiate-all-at-once property, are the > > oddballs. It's appropriate for them to have a special rule where their > > implicit outer instance "disappears" in a pre-construction context > > because it would never be possible to provide one. > > I'm not, per se, disagreeing with specifying that local classes declared > in a pre-construction context are inner. It's certainly attractive from > a compatibility POV to be able to move a local class declaration around > within a constructor body (maybe before super(..)/this(..), maybe after) > and observe no class file change because the local class is always inner > (unless it's a local enum class or local record class of course). Agreed. > On the other hand, we have to guarantee that no instantiation of the local > class is possible before super(..)/this(..) has completed normally. > Yes.. and same thing for non-static member classes, so this is not special to local classes. Don't worry about JEP 401 until JEP 447 has thoroughly clarified the > matter of whether such local classes are inner or not. > Thanks - so yes that central question remains... how should we treat local classes in pre-construction contexts? The current implementation answers this question "they are inner classes with outer instances just like they would be in any other non-static location". Admittedly that answer was chosen in part because it is the most conservative change (in particular, it produces the same bytecode). But OK let's be a little bolder and ask what would be the BEST change? My latest thinking is we should just allow local classes to be declared "static". Then "class Local" gives the current behavior (always having an outer instance in a non-static context), while "static class Local" gives the same behavior as a static member class. You could then declare AND instantiate a static local class in a pre-construction context - might be handy for doing pre-construction "housekeeping". Plus, this simplifies a developer's mental model for the various types of classes, because now local classes and member classes are the same, except of course for their lexical location and scope. This would be the best of both worlds... ? Here's a program that tries to instantiate a Local which observes x with > a value other than 5. What does the JLS say about the program? JLS says this()/super() have to be "top level", so they can't be inside a try { } block. > What does javac do? > Test.java:10: error: switch expression does not have any result expressions this(switch (0) { default -> throw new Exception(); }); ^ Test.java:12: error: cannot reference this before supertype constructor has been called new Local(); // Legal or illegal? ^ Test.java:10: error: calls to this() not allowed here this(switch (0) { default -> throw new Exception(); }); ^ 3 errors (The first error can be worked around by inserting case 1 -> 2; of course). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From vromero at openjdk.org Mon Sep 25 17:23:15 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 25 Sep 2023 17:23:15 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v7] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 16:50:00 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3975: >> >>> 3973: } >>> 3974: >>> 3975: private class SuperThisChecker extends TreeScanner { >> >> we usually create only one instance of these type of visitors that will be used very often and reuse it whenever necessary > > Actually, I disagree a bit with the direction here. Having more mutable state is, I believe, not great. In this case the state has to be discarded after a call to `check`, so IMHO having mutable state lying around is a smell. What do you think @vicente-romero-oracle ? yes @mcimadamore I see your point. And after my comments I think we discussed a similar issue in another bug and we went for the non-mutable state. After revisiting the code I agree that in this case it could be better to avoid having mutable state. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336185385 From mcimadamore at openjdk.org Mon Sep 25 17:23:18 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 17:23:18 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 17:04:39 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Have RefBeforeCtorCalledError extend StaticError and customize debug strings. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2016: > >> 2014: if (staticOnly) >> 2015: return new StaticError(sym); >> 2016: if (env1.info.ctorPrologue && env1 == env) > > where does `env1 == env` come from? Should this work? class Test { String s = "Hello"; void m() { System.out.println("Hello"); } class Inner { Inner() { m(); super(); } } public static void main(String[] args) { new Test().new Inner(); } } The proposed changes accept this program. But I can't find supporting text in the JLS changes: https://cr.openjdk.org/~gbierman/jep447/jep447-20230620/specs/statements-before-super-jls.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336182611 From mcimadamore at openjdk.org Mon Sep 25 17:40:24 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 17:40:24 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 17:17:17 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2016: >> >>> 2014: if (staticOnly) >>> 2015: return new StaticError(sym); >>> 2016: if (env1.info.ctorPrologue && env1 == env) >> >> where does `env1 == env` come from? > > Should this work? > > class Test { > String s = "Hello"; > > void m() { > System.out.println("Hello"); > } > > class Inner { > Inner() { > m(); > super(); > } > } > > public static void main(String[] args) { > new Test().new Inner(); > } > } > > The proposed changes accept this program. But I can't find supporting text in the JLS changes: > https://cr.openjdk.org/~gbierman/jep447/jep447-20230620/specs/statements-before-super-jls.html After some internal discussion, it is good for javac to accept this, as this case can be supported using the `this$0` parameter that is passed into the constructor of `Inner` (no `this` reference is strictly required). But the JLS text supporting this seems ambiguous: The pre-construction context includes the prologue of the constructor 8.8.7 and the explicit constructor invocation itself. Within a pre-construction context, constructs that refer explicitly or implicitly to the current object are disallowed. It is not clear to me as to whether `m()` refers to the current object or not - as it seems one would have to have intimate knowledge of how the compiler translates the code in order to answer that question. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336196630 From acobbs at openjdk.org Mon Sep 25 17:56:23 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 17:56:23 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

Message-ID: On Mon, 25 Sep 2023 16:59:43 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Have RefBeforeCtorCalledError extend StaticError and customize debug strings. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3971: > >> 3969: >> 3970: // Match this scan stack: 1=JCMethodDecl, 2=JCExpressionStatement, 3=JCMethodInvocation >> 3971: private static final int MATCH_SCAN_DEPTH = 3; > > This logic seems a bit fragile in that it relies on the shape of the AST. Also, in principle you can create something that will overflow the int, and will cause the check to spuriously pass for a very very very large number of nested expressions :-) > > That said, I understand that, in order to make this code "tighter", you would need to override al visitors that can "nest" code inside other code, which is also not great. Agree about this appearing fragile. The thinking was that, well, the JLS rule for this is simply: > _ConstructorBody:_ > { [_BlockStatements_] } > { [_BlockStatements_] _ExplicitConstructorInvocation_ [_BlockStatements_] } So this tries to mirror exactly that in the most direct way. The fragility comes from the possibility of some unexpected change to the AST class model... but at least if that ever did happen, you would probably get a clear warning when a bunch of JDK code stopped compiling :) > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1511: > >> 1509: if (staticOnly) >> 1510: return new StaticError(sym); >> 1511: if (env1.info.ctorPrologue && (sym.flags_field & SYNTHETIC) == 0) > > where does the SYNTHETIC check comes from? This is related to the previous question... some generated classes contain constructors with extra blocks, and these fail the `JCMethodDecl, JCExpressionStatement, JCMethodInvocation` stack check test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336205773 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336205806 From mcimadamore at openjdk.org Mon Sep 25 17:56:19 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 17:56:19 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

Message-ID: <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> On Mon, 25 Sep 2023 16:04:09 GMT, Archie Cobbs wrote: >> This is a first draft of a patch for JEP 447. >> >> Summary of changes: >> >> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` >> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context >> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` >> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement >> >> The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. >> >> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Have RefBeforeCtorCalledError extend StaticError and customize debug strings. Overall, this is a very good patch. Not only it adds a new feature (which I found myself reaching for several times), but it also does so by consolidating a bunch of logic in the compiler code. Well done! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 238: > 236: # 0: name > 237: compiler.err.call.must.only.appear.in.ctor=\ > 238: calls to {0}() may only appear within constructors Note that super()/this() in the JLS lingo is called "explicit constructor invocation". src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 245: > 243: > 244: # 0: name > 245: compiler.err.calls.not.allowed.here=\ The compiler message key seems overly general. maybe `constructor.call.not.allowed.here` ? src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 250: > 248: # 0: name > 249: compiler.err.return.before.superclass.initialized=\ > 250: ''return'' not allowed prior to {0}() We have no other match in this file for `prior to`, but we do have matches for `before`. I suggest using the latter for a more consistent style. ------------- PR Review: https://git.openjdk.org/jdk/pull/13656#pullrequestreview-1642717335 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336211699 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336213538 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336214539 From mcimadamore at openjdk.org Mon Sep 25 17:56:24 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 17:56:24 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> References:

<-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> Message-ID: <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com> On Mon, 25 Sep 2023 17:47:56 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Have RefBeforeCtorCalledError extend StaticError and customize debug strings. > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 238: > >> 236: # 0: name >> 237: compiler.err.call.must.only.appear.in.ctor=\ >> 238: calls to {0}() may only appear within constructors > > Note that super()/this() in the JLS lingo is called "explicit constructor invocation". @GavinBierman do you think the compiler message should mention the official JLS terminology? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336212292 From mcimadamore at openjdk.org Mon Sep 25 17:56:25 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 17:56:25 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com> References:

Message-ID: On Mon, 25 Sep 2023 17:31:57 GMT, Maurizio Cimadamore wrote: >> Should this work? >> >> class Test { >> String s = "Hello"; >> >> void m() { >> System.out.println("Hello"); >> } >> >> class Inner { >> Inner() { >> m(); >> super(); >> } >> } >> >> public static void main(String[] args) { >> new Test().new Inner(); >> } >> } >> >> The proposed changes accept this program. But I can't find supporting text in the JLS changes: >> https://cr.openjdk.org/~gbierman/jep447/jep447-20230620/specs/statements-before-super-jls.html > > After some internal discussion, it is good for javac to accept this, as this case can be supported using the `this$0` parameter that is passed into the constructor of `Inner` (no `this` reference is strictly required). But the JLS text supporting this seems ambiguous: > > > The pre-construction context includes the prologue of the constructor 8.8.7 and the explicit constructor invocation itself. Within a pre-construction context, constructs that refer explicitly or implicitly to the current object are disallowed. > > > It is not clear to me as to whether `m()` refers to the current object or not - as it seems one would have to have intimate knowledge of how the compiler translates the code in order to answer that question. > where does env1 == env come from? To be honest I can't remember. At some point it was needed to make something compile, but I can't come up with an example anymore (if you can, I'll tell you why it was there :) The thinking must have been: "It can't possibly matter if the AST 'cursor' is in the pre-construction context of an outer instance class; it only matters if we are in the pre-construction context of the class under construction." > The proposed changes accept this program. But I can't find supporting text in the JLS changes The spec is still being finalized ([here's the latest version](https://cr.openjdk.org/~gbierman/jep447/jep447-20230905/specs/statements-before-super-jls.html#jls-8.8)). The newer ?15.12.3 should allow this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336237288 From alex.buckley at oracle.com Mon Sep 25 18:25:52 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 25 Sep 2023 11:25:52 -0700 Subject: [External] : Re: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: References:

<22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com> Message-ID: <096d6e1e-6daf-4658-a1e5-86581d5f3be2@oracle.com> On 9/25/2023 10:13 AM, Archie Cobbs wrote: > > An explicit goal of JEP 447 is **any existing program must compile to > > the same bytecode**. So if we adhere to that goal, local classes > > declared in pre-construction contexts must have outer instances. > I don't see this explicit goal stated in JEP 447. There's a sentence > about compilation in Testing -- "We will compile all JDK classes using > the previous and new versions of the compiler and verify that the > resulting bytecode is identical." -- but that sounds merely like a > nice-to-have property, and one which holds only for JDK classes. > > You're right.. the stated goal is actually "Do not change the behavior > of any existing program." > > Making sure the emitted bytecode matches is just one way to accomplish > that goal (and possibly overkill). Goals: (always the hardest single section of a JEP to write, BTW) - Re: "In constructors, allow statements that do not access ..." -- this Goal basically repeats the Summary in stating the solution. That's not quite what a Goal is meant to do. The term "initialization logic" is also a bit wonky because it can be read as dealing with initialization of the current instance, which is the one thing you can't do before super/this. The Goal should be: "Give developers greater freedom in expressing the behavior of a constructor, allowing more natural placement of logic that currently must be factored into static methods or into arguments to super(..)." I am not sure that statements-before-super allow logic which previously was "simply impossible to express." - Drop "Correct an error in the specification which defines constructor invocations as a static context." Spec issues don't drive features. - Re: "Preserve existing safety and initialization guarantees for constructors." -- This sounds good but I bet 99% of readers couldn't enumerate an "existing safety guarantee" if you demanded one from them. Please spell out if this is about, say, guaranteeing that constructors still run in top-down order. Also, please also avoid "initialization", because you are not talking about the initialization of a class (see JLS 12.4) but rather the instantiation of a class. - Re: "Do not change the behavior of any existing program." -- stated more fully, this goal is "Perfect source compatibility: Any existing source code, if recompiled, is legal and has unchanged behavior." However, that could be a goal of almost any new language feature, so we don't usually state it. And if we cast things in terms of bytecode -- "Do not change how existing source code is compiled to a class file" -- then it sounds pretty esoteric. I'd drop this goal. > Thanks - so yes that central question remains... how should we treat > local classes in pre-construction contexts? > > The current implementation answers this question "they are inner classes > with outer instances just like they would be in any other non-static > location". > > Admittedly that answer was chosen in part because it is the most > conservative change (in particular, it produces the same bytecode). > > But OK let's be a little bolder and ask what would be the BEST change? > > My latest thinking is we should just allow local classes to be declared > "static". > > Then "class Local" gives the current behavior (always having an outer > instance in a non-static context), while "static class Local" gives the > same behavior as a static member class. This is a big language change that I'm not going to comment on. You should review the discussion around JEP 384 about how local record classes were made implicitly static, never explicitly static. > Here's a program that tries to instantiate a Local which observes x > with > a value other than 5. What does the JLS say about the program? > > > JLS says this()/super() have to be "top level", so they can't be inside > a try { } block. > > What does javac do? > > > Test.java:10: error: switch expression does not have any result expressions > ? ? ? ? ? ? ?this(switch (0) { default -> throw new Exception(); }); > ? ? ? ? ? ? ? ? ? ^ > Test.java:12: error: cannot reference this before supertype constructor > has been called > ? ? ? ? ? ? ?new Local(); ?// Legal or illegal? > ? ? ? ? ? ? ?^ > Test.java:10: error: calls to this() not allowed here > ? ? ? ? ? ? ?this(switch (0) { default -> throw new Exception(); }); > ? ? ? ? ? ? ? ? ?^ > 3 errors Oops, yes. So, can you guarantee, in the JEP, that a non-static local class declared in the pre-construction context can never access enclosing state? Alex From acobbs at openjdk.org Mon Sep 25 19:25:19 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 19:25:19 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> References:

<-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> Message-ID: On Mon, 25 Sep 2023 17:49:52 GMT, Maurizio Cimadamore wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Have RefBeforeCtorCalledError extend StaticError and customize debug strings. > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 245: > >> 243: >> 244: # 0: name >> 245: compiler.err.calls.not.allowed.here=\ > > The compiler message key seems overly general. maybe `constructor.call.not.allowed.here` ? Agreed - will fix. > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 250: > >> 248: # 0: name >> 249: compiler.err.return.before.superclass.initialized=\ >> 250: ''return'' not allowed prior to {0}() > > We have no other match in this file for `prior to`, but we do have matches for `before`. I suggest using the latter for a more consistent style. Agreed - will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336299193 PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336299902 From acobbs at openjdk.org Mon Sep 25 19:35:19 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 19:35:19 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v7] In-Reply-To: References:

Message-ID: <_grq2ClX4RUA4Bf3zTZAeQ3UuJyB8CwgeRMJW2TnD64=.8ce11d7e-a7ec-4991-b713-ffb3862ddb33@github.com> On Mon, 25 Sep 2023 17:20:04 GMT, Vicente Romero wrote: >> Actually, I disagree a bit with the direction here. Having more mutable state is, I believe, not great. In this case the state has to be discarded after a call to `check`, so IMHO having mutable state lying around is a smell. What do you think @vicente-romero-oracle ? > > yes @mcimadamore I see your point. And after my comments I think we discussed a similar issue in another bug and we went for the non-mutable state. After revisiting the code I agree that in this case it could be better to avoid having mutable state. I agree with you both, and will revert this back to creating a new instance each time. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336308671 From archie.cobbs at gmail.com Mon Sep 25 19:45:55 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 25 Sep 2023 14:45:55 -0500 Subject: [External] : Re: RFR: 8194743: Compiler implementation for Statements before super() [v14] In-Reply-To: <096d6e1e-6daf-4658-a1e5-86581d5f3be2@oracle.com> References:

<22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com> <096d6e1e-6daf-4658-a1e5-86581d5f3be2@oracle.com> Message-ID: Hi Alex, Thanks for the JEP comments, I will get with Gavin (who is managing the drafts) on these. On Mon, Sep 25, 2023 at 1:25?PM Alex Buckley wrote: > > > Test.java:12: error: cannot reference this before supertype constructor > > has been called > > new Local(); // Legal or illegal? > > ^ > > Test.java:10: error: calls to this() not allowed here > > this(switch (0) { default -> throw new Exception(); }); > > ^ > > 3 errors > > Oops, yes. So, can you guarantee, in the JEP, that a non-static local > class declared in the pre-construction context can never access > enclosing state? > Reading that literally, no that's not guaranteed at all. You are allowed to declare a (non-static) local class in a pre-construction context and then instantiate it later, after super(), and access enclosing state. What you can't do is instantiate it before super(). That's enforced by this new line in ?15.9.2: > If the class instance creation expression occurs in the pre-construction > context of class *K* (8.8.7.1 > ) > and the immediately enclosing instance is also an instance of *K* then a > compile-time error occurs. > Note this language applies to both local classes and member classes. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From acobbs at openjdk.org Mon Sep 25 20:44:03 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 25 Sep 2023 20:44:03 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v17] In-Reply-To: References: Message-ID: <80Oc_vicOqg_RBKD3xZWf2GTY8u6WBk7E26zFfEoPrQ=.18e552b7-e1ff-455d-bd1c-b12effcc00d5@github.com> > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: - After further review, revert 599d761 to avoid mutable state lying around. - Address review comments relating to error messages. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13656/files - new: https://git.openjdk.org/jdk/pull/13656/files/3e75e19e..2356ac6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=15-16 Stats: 20 lines in 4 files changed: 0 ins; 13 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From mcimadamore at openjdk.org Mon Sep 25 20:49:15 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Sep 2023 20:49:15 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v7] In-Reply-To: <_grq2ClX4RUA4Bf3zTZAeQ3UuJyB8CwgeRMJW2TnD64=.8ce11d7e-a7ec-4991-b713-ffb3862ddb33@github.com> References:

<_grq2ClX4RUA4Bf3zTZAeQ3UuJyB8CwgeRMJW2TnD64=.8ce11d7e-a7ec-4991-b713-ffb3862ddb33@github.com> Message-ID: On Mon, 25 Sep 2023 19:32:00 GMT, Archie Cobbs wrote: >> yes @mcimadamore I see your point. And after my comment above I think we discussed a similar issue in another bug and we went for the non-mutable state. After revisiting the code here I agree that in this case it could be better to avoid having mutable state. > > I agree with you both, and will revert this back to creating a new instance each time. Thanks. Thanks, and sorry for being late to the party! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336372248 From asotona at openjdk.org Tue Sep 26 09:40:26 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 26 Sep 2023 09:40:26 GMT Subject: RFR: 8308753: Class-File API transition to Preview Message-ID: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. It repackages all uses across JDK and tests and adds lots of missing Javadoc. This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). Online javadoc is available at:? https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html In addition to the primary transition to preview, this pull request also includes: - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). - A new preview feature, `CLASSFILE_API`, has been added. - Buildsystem tool required a little patch to support annotated modules. - All JDK modules using the Classfile API are newly participating in the preview. - All tests that use the Classfile API now have preview enabled. - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. Please review this pull request to help the Classfile API turn into a preview. Any comments are welcome. Thanks, Adam ------------- Commit messages: - fixed tests - rename of Classfile* to ClassFile* - fixed javac tests - temporary reverted conversion of tests to Classfile API due incompatibility with enabled preview - build and tests fixes - Merge branch 'master' into JDK-8308753-preview - added jvms link to DynamicConstantPoolEntry - fixed EnclosingMethodAttribute javadoc - documented constraints of builder and factory methods - added package info paragraph "Consistency checks, syntax checks and verification" - ... and 310 more: https://git.openjdk.org/jdk/compare/913e43fe...6594ee74 Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308753 Stats: 28985 lines in 760 files changed: 12993 ins; 12505 del; 3487 mod Patch: https://git.openjdk.org/jdk/pull/15706.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706 PR: https://git.openjdk.org/jdk/pull/15706 From ihse at openjdk.org Tue Sep 26 09:57:25 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Sep 2023 09:57:25 GMT Subject: RFR: 8308753: Class-File API transition to Preview In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <9Mzvela_6bk-RbrzuwgtAh8YBykhV8Gso6Lg2oX37qY=.1fd2a73f-9272-497c-814e-9ba690feb147@github.com> On Wed, 13 Sep 2023 09:48:00 GMT, Adam Sotona wrote: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Build changes trivially good. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1643863419 From asotona at openjdk.org Tue Sep 26 12:32:37 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 26 Sep 2023 12:32:37 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v2] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: PreviewFeature annotated with JEP 457 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/6594ee74..77631a78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15706.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706 PR: https://git.openjdk.org/jdk/pull/15706 From liach at openjdk.org Tue Sep 26 13:13:24 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 26 Sep 2023 13:13:24 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v2] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > PreviewFeature annotated with JEP 457 src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82: > 80: STRUCTURED_CONCURRENCY, > 81: @JEP(number=457, title="ClassFile API", status="Preview") > 82: CLASSFILE_API, Since `Classfile` gets renamed to `ClassFile`, do we rename the title to `Class-File API` and constant to `CLASS_FILE_API`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1337183618 From asotona at openjdk.org Tue Sep 26 13:40:25 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 26 Sep 2023 13:40:25 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v2] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>

Message-ID: On Tue, 26 Sep 2023 13:10:15 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> PreviewFeature annotated with JEP 457 > > src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82: > >> 80: STRUCTURED_CONCURRENCY, >> 81: @JEP(number=457, title="ClassFile API", status="Preview") >> 82: CLASSFILE_API, > > Since `Classfile` gets renamed to `ClassFile`, do we rename the title to `Class-File API` and constant to `CLASS_FILE_API`? Rename of classes and interfaces from `Classfile` to `ClassFile` is significant for the API. `ClassFile` and `Class-File` are considered equal in text. Internal name of the preview feature is temporary and invisible in the API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1337223631 From rgiulietti at openjdk.org Tue Sep 26 14:16:26 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 26 Sep 2023 14:16:26 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: On Fri, 8 Sep 2023 14:17:29 GMT, Aggelos Biboudis wrote: > This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 45: > 43: * > 44: * */ > 45: public static boolean byte_char(byte n) {return n == (char) n;} This method doesn't buy you anything more than `int_char(int)`, so I wonder if it is useful. (The bytecode instructions are exactly the same.) src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 53: > 51: * > 52: * */ > 53: public static boolean short_byte(short n) {return n == (short)(byte)(n);} Here, too, I wonder if this method is useful, given that `int_byte(int)` gives the same outcomes and its bytecode is one instruction shorter. src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 61: > 59: * > 60: * */ > 61: public static boolean short_char(short n) {return n == (char)(n);} Similarly, usages can be replaced by `int_char(int)`. src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 69: > 67: * > 68: * */ > 69: public static boolean char_byte(char n) {return n == (byte)(n);} Usages can be replaced by `int_byte(int)`. src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 77: > 75: * > 76: * */ > 77: public static boolean char_short(char n) {return n == (short)(n);} Can be replaced by `int_short(int)`. src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 85: > 83: * > 84: * */ > 85: public static boolean int_byte(int n) {return n == (int)(byte)(n);} Suggestion: public static boolean int_byte(int n) {return n == (int)(byte)n;} Just for consistency with other methods. src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 93: > 91: * > 92: * */ > 93: public static boolean int_short(int n) {return n == (int)(short)(n);} Suggestion: public static boolean int_short(int n) {return n == (int)(short)n;} src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 101: > 99: * > 100: * */ > 101: public static boolean int_char(int n) {return n == (char)(n);} Suggestion: public static boolean int_char(int n) {return n == (int)(char)n;} src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 117: > 115: * > 116: * */ > 117: public static boolean long_byte(long n) {return n == (long)(byte)(n);} Suggestion: public static boolean long_byte(long n) {return n == (long)(byte)n;} src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 125: > 123: * > 124: * */ > 125: public static boolean long_short(long n) {return n == (long)(short)(n);} Suggestion: public static boolean long_short(long n) {return n == (long)(short)n;} src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 133: > 131: * > 132: * */ > 133: public static boolean long_char(long n) {return n == (char)(n);} Suggestion: public static boolean long_char(long n) {return n == (long)(char)n;} for consistency. src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 141: > 139: * > 140: * */ > 141: public static boolean long_int(long n) {return n == (long)(int)(n);} Suggestion: public static boolean long_int(long n) {return n == (long)(int)n;} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337239197 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337251147 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337257370 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337259180 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337221803 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337221156 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337220474 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337219930 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337217930 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337217515 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337216448 PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337268643 From gbierman at openjdk.org Thu Sep 28 10:16:31 2023 From: gbierman at openjdk.org (Gavin Bierman) Date: Thu, 28 Sep 2023 10:16:31 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

<-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com> Message-ID: On Mon, 25 Sep 2023 17:52:58 GMT, Maurizio Cimadamore wrote: >> @GavinBierman do you think the compiler message should mention the official JLS terminology? > > For instance: > > > explicit constructor invocation may only appear within constructors > > > > redundant explicit constructor invocation > > > > explicit constructor invocation not allowed here > > > > 'return'' not allowed before explicit constructor invocation @mcimadamore Yes, I like the first. Something like "explicit constructor invocation may only appear within a constructor body" is good. (The JLS actually says that an (explicit) constructor invocation, i.e. this(...) or super(...), is not a statement, but just a thing that can appear in a constructor body.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1339876223 From jjg at openjdk.org Thu Sep 28 16:05:38 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 28 Sep 2023 16:05:38 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v2] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > PreviewFeature annotated with JEP 457 I don't see anything specific to `javadoc` ------------- PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1649221047 From acobbs at openjdk.org Thu Sep 28 16:19:08 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 28 Sep 2023 16:19:08 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v18] In-Reply-To: References: Message-ID: > This is a first draft of a patch for JEP 447. > > Summary of changes: > > 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue` > 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context > 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()` > 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement > > The changes in `Flow.java` are an example of #4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called. > > Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Reword new errors to use the JLS term for "explicit constructor invocation". ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13656/files - new: https://git.openjdk.org/jdk/pull/13656/files/2356ac6f..738c10a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=16-17 Stats: 22 lines in 3 files changed: 0 ins; 4 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/13656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656 PR: https://git.openjdk.org/jdk/pull/13656 From acobbs at openjdk.org Thu Sep 28 16:19:10 2023 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 28 Sep 2023 16:19:10 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

<-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>

Message-ID: On Thu, 28 Sep 2023 10:13:19 GMT, Gavin Bierman wrote: >> For instance: >> >> >> explicit constructor invocation may only appear within constructors >> >> >> >> redundant explicit constructor invocation >> >> >> >> explicit constructor invocation not allowed here >> >> >> >> 'return'' not allowed before explicit constructor invocation > > @mcimadamore Yes, I like the first. Something like "explicit constructor invocation may only appear within a constructor body" is good. > > (The JLS actually says that an (explicit) constructor invocation, i.e. this(...) or super(...), is not a statement, but just a thing that can appear in a constructor body.) Updated error messages in 738c10a57de. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1340385904 From abimpoudis at openjdk.org Thu Sep 28 16:46:11 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 28 Sep 2023 16:46:11 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v2] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: > This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Raffaello Giulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/d354f7eb..1ae06ac8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From rgiulietti at openjdk.org Thu Sep 28 17:22:25 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 28 Sep 2023 17:22:25 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v2] In-Reply-To: References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis wrote: >> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). >> >> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Raffaello Giulietti There might be good reasons to have: - `byte_char()` and `short_char()` in addition to `int_char()` - `short_byte()` and `char_byte()` in addition to `int_byte()` - `char_short()` in addition to `int_short()` but I cannot see the rationale. Maybe due to the language rules? Or are they needed for the implementation of patterns, instanceof and switch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1739727897 From abimpoudis at openjdk.org Thu Sep 28 17:50:29 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 28 Sep 2023 17:50:29 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v2] In-Reply-To: References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis wrote: >> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). >> >> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Raffaello Giulietti At the moment the translation is uniform, (simply) computing the method name from the static types of the arguments and generating calls to those methods. This happens from two places, one from the `instanceof`: > https://github.com/openjdk/jdk/pull/15638/files#diff-bc0df6dce7f74078bfca1e90bec75d7bb3d8b338933be725da78f0a8a7a0c78dR2999 and one from the `SwitchBootstraps` for `switch` (open the SwitchBootstraps file to see the diff, Github doesn't open it automatically): > https://github.com/openjdk/jdk/pull/15638/files#diff-d71d82d68cc87a9c7179421f4a57eacdba822eb3e6a2b413ddb35f0b891a3764R246 I will try to find a good way to share code between the two places, by avoiding the further duplication of the code (@mcimadamore, @vicente-romero-oracle, @lahodaj any ideas?). In any case (with code duplication or not) maybe I can introduce a small table to "string intern" those names and avoid this computation altogether (including the map that you wrote above). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1739759884 From mcimadamore at openjdk.org Fri Sep 29 08:34:09 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 29 Sep 2023 08:34:09 GMT Subject: RFR: 8194743: Compiler implementation for Statements before super() [v16] In-Reply-To: References:

<-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com> <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>

Message-ID: <9QeWO6fjt111oX4GBEyDJ8qed34OmxB92KisUP8wQBw=.ceeb1d53-1c45-424a-9786-b27015daae6d@github.com> On Thu, 28 Sep 2023 16:11:39 GMT, Archie Cobbs wrote: >> @mcimadamore Yes, I like the first. Something like "explicit constructor invocation may only appear within a constructor body" is good. >> >> (The JLS actually says that an (explicit) constructor invocation, i.e. this(...) or super(...), is not a statement, but just a thing that can appear in a constructor body.) > > Updated error messages in 738c10a57de. Good job! I like the new messages. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1341070884 From abimpoudis at openjdk.org Fri Sep 29 14:57:51 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 29 Sep 2023 14:57:51 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v2] In-Reply-To: References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis wrote: >> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). >> >> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Raffaello Giulietti So, the following shows the changes in `Lower.java`. It removes the methods you propose at the cost of a little bit more indirection which is ok. However, there is a non-trivial amount of re-engineering needed to be done on the `SwitchBootstrap` to support this change. It is not a mere porting of the logic from `Lower` to `SwitchBootstrap`. This is easy (despite the duplication of the code which I am inviting recommendations on how to avoid ? ). What is more, is that the `selectorType` changes within `createRepeatIndexSwitch` and needs to change in various sites as well e.g., `createMethodHandleSwitch`. @lahodaj am I correct? (this is a footprint vs code uniformity question. If the bytecode instructions are exactly the same and in one occasion (`short_byte` -> `int_byte`) one bytecode instruction shorter, maybe code uniformity should win here?) Subject: [PATCH] [WIP] Implement type pairs to exactnessMethod name --- Index: src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java b/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java --- a/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java (revision 1ae06ac8f8cc0c0ce70920c2a62a7c13fdfc6f23) +++ b/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java (date 1695993935975) @@ -36,46 +36,6 @@ private ExactnessMethods() { } - /** Exactness method from byte to char - * - * @param n value - * @return true if the passed value can be converted exactly to the target type - * - * */ - public static boolean byte_char(byte n) {return n == (char) n;} - - /** Exactness method from short to byte - * - * @param n value - * @return true if the passed value can be converted exactly to the target type - * - * */ - public static boolean short_byte(short n) {return n == (short)(byte)(n);} - - /** Exactness method from short to char - * - * @param n value - * @return true if the passed value can be converted exactly to the target type - * - * */ - public static boolean short_char(short n) {return n == (char)(n);} - - /** Exactness method from char to byte - * - * @param n value - * @return true if the passed value can be converted exactly to the target type - * - * */ - public static boolean char_byte(char n) {return n == (byte)(n);} - - /** Exactness method from char to short - * - * @param n value - * @return true if the passed value can be converted exactly to the target type - * - * */ - public static boolean char_short(char n) {return n == (short)(n);} - /** Exactness method from int to byte * * @param n value Index: src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java (revision 1ae06ac8f8cc0c0ce70920c2a62a7c13fdfc6f23) +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java (date 1695992937983) @@ -103,6 +103,7 @@ private final PkgInfo pkginfoOpt; private final boolean optimizeOuterThis; private final boolean useMatchException; + private final HashMap typePairToName; @SuppressWarnings("this-escape") protected Lower(Context context) { @@ -134,6 +135,7 @@ Preview preview = Preview.instance(context); useMatchException = Feature.PATTERN_SWITCH.allowedInSource(source) && (preview.isEnabled() || !preview.isPreview(Feature.PATTERN_SWITCH)); + typePairToName = TypePairs.initialize(syms); } /** The currently enclosing class. @@ -2996,15 +2998,81 @@ } } + static class TypePairs { + public Type from, to; + + public static TypePairs of(Symtab syms, Type from, Type to) { + if (from == syms.byteType || from == syms.shortType || from == syms.charType) { + from = syms.intType; + } + return new TypePairs(from, to); + } + + private TypePairs(Type from, Type to) { + this.from = from; + this.to = to; + } + + public static HashMap initialize(Symtab syms) { + HashMap typePairToName = new HashMap<>(); + typePairToName.put(new TypePairs(syms.byteType, syms.charType), "int_char"); // redirected + typePairToName.put(new TypePairs(syms.shortType, syms.byteType), "int_byte"); // redirected + typePairToName.put(new TypePairs(syms.shortType, syms.charType), "int_char"); // redirected + typePairToName.put(new TypePairs(syms.charType, syms.byteType), "int_byte"); // redirected + typePairToName.put(new TypePairs(syms.charType, syms.shortType), "int_short"); // redirected + typePairToName.put(new TypePairs(syms.intType, syms.byteType), "int_byte"); + typePairToName.put(new TypePairs(syms.intType, syms.shortType), "int_short"); + typePairToName.put(new TypePairs(syms.intType, syms.charType), "int_char"); + typePairToName.put(new TypePairs(syms.intType, syms.floatType), "int_float"); + typePairToName.put(new TypePairs(syms.longType, syms.byteType), "long_byte"); + typePairToName.put(new TypePairs(syms.longType, syms.shortType), "long_short"); + typePairToName.put(new TypePairs(syms.longType, syms.charType), "long_char"); + typePairToName.put(new TypePairs(syms.longType, syms.intType), "long_int"); + typePairToName.put(new TypePairs(syms.longType, syms.floatType), "long_float"); + typePairToName.put(new TypePairs(syms.longType, syms.doubleType), "long_double"); + typePairToName.put(new TypePairs(syms.floatType, syms.byteType), "float_byte"); + typePairToName.put(new TypePairs(syms.floatType, syms.shortType), "float_short"); + typePairToName.put(new TypePairs(syms.floatType, syms.charType), "float_char"); + typePairToName.put(new TypePairs(syms.floatType, syms.intType), "float_int"); + typePairToName.put(new TypePairs(syms.floatType, syms.longType), "float_long"); + typePairToName.put(new TypePairs(syms.doubleType, syms.byteType), "double_byte"); + typePairToName.put(new TypePairs(syms.doubleType, syms.shortType), "double_short"); + typePairToName.put(new TypePairs(syms.doubleType, syms.charType), "double_char"); + typePairToName.put(new TypePairs(syms.doubleType, syms.intType), "double_int"); + typePairToName.put(new TypePairs(syms.doubleType, syms.longType), "double_long"); + typePairToName.put(new TypePairs(syms.doubleType, syms.floatType), "double_float"); + return typePairToName; + } + + @Override + public int hashCode() { + int code = 0; + code += from.tsym.hashCode(); + code += to.tsym.hashCode(); + return code; + } + + @Override + public boolean equals(Object testName) { + if ((!(testName instanceof TypePairs testNameAsName))) return false; + else { + return this.from.tsym.equals(testNameAsName.from.tsym) && + this.to.tsym.equals(testNameAsName.to.tsym); + } + } + } + private JCExpression getExactnessCheck(JCInstanceOf tree, JCExpression argument) { - Name exactnessFunction = names.fromString(types.unboxedTypeOrType(tree.expr.type).tsym.name.toString() + "_"+ tree.pattern.type.toString()); + TypePairs pair = TypePairs.of(syms, types.unboxedTypeOrType(tree.expr.type), tree.pattern.type); + + Name exactnessFunction = names.fromString(typePairToName.get(pair)); // Resolve the exactness method Symbol ecsym = rs.resolveQualifiedMethod(null, attrEnv, syms.exactnessMethodsType, exactnessFunction, - List.of(tree.expr.type), + List.of(pair.from), List.nil()); // Generate the method call ExactnessChecks.(); ------------- PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1741006395 From rgiulietti at openjdk.org Fri Sep 29 16:38:17 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 29 Sep 2023 16:38:17 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v2] In-Reply-To: References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis wrote: >> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview). >> >> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html > > Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Raffaello Giulietti I just had a reading at the `ExactnessMethods` class. From that limited perspective, the methods mentioned above seem redundant. But if their removal would make other parts more complex, that's a good reason to keep them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1741159978 From vromero at openjdk.org Fri Sep 29 23:36:48 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 29 Sep 2023 23:36:48 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v2] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com> On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > PreviewFeature annotated with JEP 457 make/jdk/src/classes/build/tools/module/GenModuleInfoSource.java line 476: > 474: throw parser.newError("is malformed"); > 475: } > 476: } else if (token.equals("import")) { why is this change necessary? src/java.base/share/classes/java/lang/classfile/AnnotationElement.java line 34: > 32: import jdk.internal.javac.PreviewFeature; > 33: > 34: /** shouldn't we have the preview header applied to all these compilation units?: {@preview Associated with pattern matching for instanceof, a preview feature of the Java language. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341847954 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341855569 From vromero at openjdk.org Sat Sep 30 04:36:55 2023 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 30 Sep 2023 04:36:55 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v2] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > PreviewFeature annotated with JEP 457 src/java.base/share/classes/java/lang/classfile/Attributes.java line 174: > 172: public static final String NAME_RUNTIME_INVISIBLE_ANNOTATIONS = "RuntimeInvisibleAnnotations"; > 173: > 174: /** RuntimeInvisibleTypeAnnotations */ this comment should probably be: RuntimeInvisibleParameterAnnotations ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341908521