From jjg at openjdk.java.net Fri Jan 1 02:24:56 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 1 Jan 2021 02:24:56 GMT Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone [v4] In-Reply-To: References: Message-ID: On Thu, 31 Dec 2020 16:50:22 GMT, Guoxiong Li wrote: >> Hi all, >> >> Currently, javac would emit duplicate pool entries when compiling array::clone. >> This patch fixes it by using a cached field `Map qualifiedSymbolCache;` and adds a corresponding test case. >> >> Thank you for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright. Adjust import statements. test/langtools/tools/javac/classfiles/T8255757/T8255757.java line 99: > 97: } > 98: if (num != 1) { > 99: throw new AssertionError("The number of the pool entries on array::clone is not right."); In any messages like this, in any test, it is good practice to display the expected value and the actual value. Tests are often/typically run in batch jobs on remote servers, and it can sometimes be difficult to recreate a failure, so always look to give as much helpful info as possible when any failure is detected. ------------- PR: https://git.openjdk.java.net/jdk/pull/1912 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 1 09:40:14 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 1 Jan 2021 09:40:14 GMT Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone [v5] In-Reply-To: References: Message-ID: > Hi all, > > Currently, javac would emit duplicate pool entries when compiling array::clone. > This patch fixes it by using a cached field `Map qualifiedSymbolCache;` and adds a corresponding test case. > > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Revise log and copyright. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1912/files - new: https://git.openjdk.java.net/jdk/pull/1912/files/3ecbe6f2..326b4893 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=03-04 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1912.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1912/head:pull/1912 PR: https://git.openjdk.java.net/jdk/pull/1912 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 1 09:40:15 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 1 Jan 2021 09:40:15 GMT Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone [v4] In-Reply-To: References: Message-ID: On Fri, 1 Jan 2021 02:22:19 GMT, Jonathan Gibbons wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright. Adjust import statements. > > test/langtools/tools/javac/classfiles/T8255757/T8255757.java line 99: > >> 97: } >> 98: if (num != 1) { >> 99: throw new AssertionError("The number of the pool entries on array::clone is not right."); > > In any messages like this, in any test, it is good practice to display the expected value and the actual value. Tests are often/typically run in batch jobs on remote servers, and it can sometimes be difficult to recreate a failure, so always look to give as much helpful info as possible when any failure is detected. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1912 From lgxbslgx at gmail.com Fri Jan 1 17:05:05 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 2 Jan 2021 01:05:05 +0800 Subject: Potential bugs when using the JavaCompiler API. In-Reply-To: <8e5d881e-c3ec-231e-a296-e3b906844ce8@oracle.com> References: <8e5d881e-c3ec-231e-a296-e3b906844ce8@oracle.com> Message-ID: Hi jon, Thank you for your comment. I have not forgotten this thread. I want to see some more opinions and do more investigation. I can't guarantee that I can solve the issue in the end. But the discussion about this issue is good for us. Best Regards. On Sat, Dec 19, 2020 at 6:17 AM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Hi, > > Thanks for your interest in this area. > > The bugs, such as they are, are more in the specification than the > implementation, and are somewhat tricky to fix as well as might be > expected. There is one task that is part bug, part enhancement, depending > on your point of view, and equally tricky to figure out, which is one of > the reasons it has not been done before now. > > Generally, you should not think of the `JavaFileManager` API and > `JavaCompiler.getTask` options as equivalent. The file manager is a lower > level abstraction than the compiler, and applicable in more contexts than > `javac`. By itself, it is not wrong for a file manager to have > combinations of locations set, because there may be situations (i.e. some > tools) where that is desirable and appropriate. And, incorrect settings for > a file manager are generally reported by throwing > `IllegalArgumentException` in preference to using a diagnostic listener. > And, while it does not make sense to allow conflicting options like > `--source-path` and `--module-source-path` on the javac command line, it > seemed better to permit file managers with both set and to figure a > reasonable policy to handle that situation. > > Also, note that when using the Compiler API and `JavaCompiler.getTask`, > the compiler has to be able to accept any suitable implementation of a file > manager, and not just the standard one returned by the JDK implementation > of `ToolProvider.getSystemJavaCompiler().getStandardJavaFileManager`. And, > for better or worse, there is no API on a file manager to determine if > errors have occurred, in a way that would be reasonable for the internals > of javac to detect and react to. > > Your comments related to your example with `task1` and `task2` are > somewhat reasonable. Although it is on one hand not surprising that options > to getTask affect the file manager, on the other, it would be nice if the > changes were transient. The general idea we have had in the past is to > create a temporary file manager inside the compiler that wraps and > delegates to the given file manager, except for the arguments given to the > options. However we have not thought through any detailed design to make > that happen. > > As for the specification, yes, the API in this area is somewhat > under-specified. Part of it is a general problem with JDK API > specifications: both JavaCompiler and JavaFileManager are service-provider > interfaces, and while it is easy enough to specify the common properties of > all implementations of these interfaces, there is not a good way/place to > specify the additional characteristics and properties of specific > implementations. For the JavaCompiler API, we want to allow other vendors > to provide alternate implementations of a Java Compiler (subject to all the > appropriate conformance rules), and so it is inappropriate in the Java SE > class `javax.tools.JavaCompiler` to give JDK-specific details of the JDK > implementation of that interface. And, for any implementations of > `JavaFileManager`, we don't want to over-specify it and so restrict the > kinds of implementations anyone can provide. The one thing of note is that > whereas there was no good solution to this specification problem in JDK 6, > since JDK 9, and the Java Platform Module System, we do have a reasonable > place to put some of this specification, and that is the module > documentation for the `jdk.compiler` module. In that module, we could write > paragraphs that give additional specification details for the > implementation of the `JavaCompiler` interface provided by the module, and > for the standard file manager returned by the `getStandardJavaFileManager` > method of that implementation. It's "not great" that the documentation with > be narrative paragraphs not directly linked into the shared documentation > in the `javax.tools` interface, but at least it would be somewhere, which > is better than now. > > -- Jon > On 12/18/20 6:38 AM, Guoxiong Li wrote: > > Hi all, > > When I was working on the JDK-8232939[1], I found some strange points and > suspicious bugs. The origin of the issues is the `Context` of > `StandardJavaFileManager`(eg: JavacFileManager) and the `Context` of > `CompilationTask`(eg: JavacTaskImpl) is not same. As we can see in class > `JavacTool`, the methods `getStandardFileManager` and `getTask` both create > its new `Context`. > > When creating its new `Context` to isolate. We can call it as the > *decoupled* part of `StandardJavaFileManager` and `CompilationTask`. > When using `getTask` with a file manager to get a `CompilationTask`, the > `getTask` will set some properties of the file manager. We can call it as > the *coupled* part of `StandardJavaFileManager` and `CompilationTask`. > > The decoupled and coupled part of `StandardJavaFileManager` and > `CompilationTask` are strange and both have suspicious bugs which are shown > below. > > 1. Bugs about the decoupled part. > The properties of `JavacFileManager`, especially `Log` and `Options`, > are not same as the corresponding items of `JavacTaskImpl`. Some issues > will occur. > > The first example is that the OptionGroup.FILEMANAGER options won't be > validated. This is a bug about the different `Options`. > As you can see the test code[2]. `--module-source-path` and > `--source-path` are both set. It is wrong because the man document states > that users can use only one of `--module-source-path` and `--source-path`, > and can't use both. These wrong code are accepted by the compiler now. > Because when using the compiler API, the options property of file manager > only contain the OptionGroup.FILEMANAGER options and the options property > of compiler task only contain the OptionGroup.BASIC options. When > validating options[3], only the options of compiler task will be validated. > That is said, the OptionGroup.FILEMANAGER options won't be validated. It is > unacceptable because the manner of compiler API is different from the > compiler command line. > > The second example is JDK-8232939[1]. It is a bug about the different > `Log.` > The file manager generates the errors during the parse stage and > reports the error by using its own `Log`. After the parse stage, the > compiler uses `stopIfError` to check if the errors occur and will stop the > later stages if any error occurs. Unfortunately, the method `stopIfError` > checks the `Log` of the compiler instead of the `Log` of the file manager > so that it can't find any error generated by the file manager. So the > compiler continues the later stages unexpectedly. > > These two bugs(one about `Options`, another about `Log`) show that > current decoupled way is not so good. If we deep into all the properties of > these two different context, some more bugs may be found. > > 2. Bugs about the coupled way. > This aspect are more important and more unacceptable. As you can see > the code snippet below. > ``` > var compiler = ToolProvider.getSystemJavaCompiler(); > var fm = compiler.getStandardFileManager(null, null, null); > var files = fm.getJavaFileObjects(Path.of("Test.java")); > JavaCompiler.CompilationTask task1 = compiler.getTask(null, fm, > null, List.of("-XDrawDiagnostics", "-encoding", "ASCII"), null, files); > JavaCompiler.CompilationTask task2 = compiler.getTask(null, fm, > null, List.of("-XDrawDiagnostics"/*some more options*/), null, files); > System.out.println(task1.call()); > System.out.println(task2.call()); > ``` > The OptionGroup.FILEMANAGER options of `task1`("-encoding", "ASCII") > will be taken to `task2` and vice versa. Because the options of file > manager won't be cleared. It required the users clear the options manually. > Unfortunately, the users, included me, use it incorrectly. The probably > correct usage is shown below: run the first task and clear the information > of previous task before getting another task. As you can see, the clear > work is hard because the users don't know the internal of the compiler. > Currently I can't find a good way to clear, too. > ``` > var compiler = ToolProvider.getSystemJavaCompiler(); > var fm = compiler.getStandardFileManager(null, null, null); > var files = fm.getJavaFileObjects(Path.of("Test.java")); > JavaCompiler.CompilationTask task1 = compiler.getTask(null, fm, > null, List.of("-XDrawDiagnostics", "-encoding", "ASCII"), null, files); > System.out.println(task1.call()); > // Do some clear work. Omit. > JavaCompiler.CompilationTask task2 = compiler.getTask(null, fm, > null, List.of("-XDrawDiagnostics"), null, files); > System.out.println(task2.call()); > ``` > As the document stated: > > The standard file manager serves two purposes: > > basic building block for customizing how a compiler reads and > writes files > > sharing between multiple compilation tasks > But the options and task's own individual other information perhaps > shouldn't be shared. > > > To solve the problem completely, we should find a better way to > decouple file manager and compilation task instead of using the new > `Context` directly and simply. > I have been thinking of a better solution these days but I can't find a > satisfying solution. I want to share the problem with you to see your > opinions. This is the reason of this email. > > Any opinion or idea are appreciated! > > [1] https://bugs.openjdk.java.net/browse/JDK-8232939 > [2] > https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/test/langtools/tools/javac/modules/AnnotationProcessing.java#L1607 > [3] > https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L409 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+13688759+lgxbslgx at openjdk.java.net Sat Jan 2 09:22:55 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 2 Jan 2021 09:22:55 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:34:59 GMT, Joel Borggr?n-Franck wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Objects::checkFromIndexSize > > I'd like to see some kind of evidence that performance was actually improved. I realise this might be hard to make a good standalone test for, but it should be doable as an experiment observing how many times write(int) is called for a huge file. As @jbf said: > I'd like to see some kind of evidence that performance was actually improved. But later @jbf said: > Ok, got it. So today, in case the stream has an efficient write of an array range it currently isn't called, but a 1-byte-at-a-time write inherited is called instead. This patch delegates to the out method (efficient or not) instead of choosing the inherited method (always inefficient). Currently, @jbf doesn't approve this patch. @jonathan-gibbons @jbf Should I submit more evidence? Or should I integrate this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Jan 2 12:39:01 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 2 Jan 2021 12:39:01 GMT Subject: RFR: 8259025: Record compact constructor using Objects.requireNonNull Message-ID: Hi all, Currently, the method `Attr::lambdaEnv` doesn't set the `lambdaEnv.info.isLambda` to `true` and lets the caller set it. But not all the callers remember to set it. In this bug, `DefferredAttr::attribSpeculativeLambda` uses `Attr::lambdaEnv` and doesn't set `lambdaEnv.info.isLambda` to `true`. So when `Attr::visitReturn` uses `!env.info.isLambda` to judge if it is in the lambda environment, it gets the wrong information and generates an error message. This patch moves `lambdaEnv.info.isLambda = true;` into `Attr::lambdaEnv` to solve the problem and adds a corresponding test case. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8259025: Record compact constructor using Objects.requireNonNull Changes: https://git.openjdk.java.net/jdk/pull/1917/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1917&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259025 Stats: 15 lines in 2 files changed: 11 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1917.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1917/head:pull/1917 PR: https://git.openjdk.java.net/jdk/pull/1917 From jjg at openjdk.java.net Sat Jan 2 22:31:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 2 Jan 2021 22:31:55 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:34:59 GMT, Joel Borggr?n-Franck wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Objects::checkFromIndexSize > > I'd like to see some kind of evidence that performance was actually improved. I realise this might be hard to make a good standalone test for, but it should be doable as an experiment observing how many times write(int) is called for a huge file. I read Joel's (@jbf) comment as understanding where you are coming from with the patch. Since the code now provides the recommended pattern, I don't think any more evidence is needed. I think you're OK to integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From jfranck at openjdk.java.net Sun Jan 3 10:07:58 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Sun, 3 Jan 2021 10:07:58 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: References: Message-ID: On Sat, 2 Jan 2021 22:29:08 GMT, Jonathan Gibbons wrote: >> I'd like to see some kind of evidence that performance was actually improved. I realise this might be hard to make a good standalone test for, but it should be doable as an experiment observing how many times write(int) is called for a huge file. > > I read Joel's (@jbf) comment as understanding where you are coming from with the patch. > > Since the code now provides the recommended pattern, I don't think any more evidence is needed. I think you're OK to integrate. Hi In general when closing a performance related issue it is good to provide some kind of evidence that performance has actually improved. Many times I have seen fixes that *should* have solved some performance issue that turned out to not do that. That is why I still like to see some kind of evidence that this fixes the reported issue. My second comment was about understanding how the code *could* solve the issue. After the explanation from @lgxbslgx I now believe this can be the case, it looks plausible that this will improve the buffering in writes. *However* the fact that I now think this could fix the issue isn't the proof I would look for when closing a performance bug. I would still like to see some kind of performance metric or benchmark that shows that buffering of writes actually occur, this doesn't need to be a repeatable test, but can be a report or summary from an instrumented test run or something similar. However I do *believe* this should fix the problem so I don't object to Jon sponsoring this if he is confident with the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From github.com+13688759+lgxbslgx at openjdk.java.net Sun Jan 3 13:47:54 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sun, 3 Jan 2021 13:47:54 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: References: Message-ID: On Sun, 3 Jan 2021 10:04:49 GMT, Joel Borggr?n-Franck wrote: > Many times I have seen fixes that should have solved some performance issue that turned out to not do that. @jbf I understand what you worried about now. The developers' intuition may sometimes be wrong. So we need unit tests, regression tests, micro tests and so on to verify our code is right. I agree with you that the evidence should be provided. I try to write a benchmark test locally now. I will share the result with you later. ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From jjg at openjdk.java.net Sun Jan 3 17:35:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sun, 3 Jan 2021 17:35:55 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: References: Message-ID: On Sun, 3 Jan 2021 10:04:49 GMT, Joel Borggr?n-Franck wrote: >> I read Joel's (@jbf) comment as understanding where you are coming from with the patch. >> >> Since the code now provides the recommended pattern, I don't think any more evidence is needed. I think you're OK to integrate. > > Hi > > In general when closing a performance related issue it is good to provide some kind of evidence that performance has actually improved. Many times I have seen fixes that *should* have solved some performance issue that turned out to not do that. That is why I still like to see some kind of evidence that this fixes the reported issue. > > My second comment was about understanding how the code *could* solve the issue. After the explanation from @lgxbslgx I now believe this can be the case, it looks plausible that this will improve the buffering in writes. *However* the fact that I now think this could fix the issue isn't the proof I would look for when closing a performance bug. > > I would still like to see some kind of performance metric or benchmark that shows that buffering of writes actually occur, this doesn't need to be a repeatable test, but can be a report or summary from an instrumented test run or something similar. However I do *believe* this should fix the problem so I don't object to Jon sponsoring this if he is confident with the change. In general, I agree with @jbf about validating performance improvements. However, I think that this change is as much about cleanup as it is about performance, especially since `FilterOutputStream` specifically recommends that this method _should_ be overridden: ` Note that this method does not call the write method of its underlying output stream with the same arguments. Subclasses of FilterOutputStream should provide a more efficient implementation of this method. ` It is not clear to be that we can write a reasonable performance test, since as has been noted, it depends on the underlying stream. But I do think that the proposed change makes the code cleaner and simpler, and in general will do no worse than before. ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From github.com+13688759+lgxbslgx at openjdk.java.net Sun Jan 3 17:35:57 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sun, 3 Jan 2021 17:35:57 GMT Subject: Integrated: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient In-Reply-To: References: Message-ID: <-Pyl5PWp0cTNW1XWjg9DEJjf9tPOpZ0LsDxoimEzoiA=.850df918-c792-433d-bd8e-bfbdd3f79cae@github.com> On Sun, 20 Dec 2020 17:29:59 GMT, Guoxiong Li wrote: > Hi all, > > `FilerOutputStream` extends `FilterOutputStream` without overwriting the method `write(byte b[], int off, int len)` which would suffer from the performance problem. > This patch fixes it and adds some `@Override` to polish the code. But I can't find a good way to write a corresponding test case. Maybe it doesn't need a test case. And all existing tests in `test/langtools/tools/javac` passed locally. > > Thank you for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: 526c0005 Author: Guoxiong Li Committer: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/526c0005 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From github.com+13688759+lgxbslgx at openjdk.java.net Sun Jan 3 18:56:56 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sun, 3 Jan 2021 18:56:56 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: References: Message-ID: <8R4Dnf3VOSaHScty2v2rYqvRe0II0ONdb_DNVutfANE=.098a3b55-d297-4032-861c-415596a912fd@github.com> On Sun, 3 Jan 2021 17:32:03 GMT, Jonathan Gibbons wrote: >> Hi >> >> In general when closing a performance related issue it is good to provide some kind of evidence that performance has actually improved. Many times I have seen fixes that *should* have solved some performance issue that turned out to not do that. That is why I still like to see some kind of evidence that this fixes the reported issue. >> >> My second comment was about understanding how the code *could* solve the issue. After the explanation from @lgxbslgx I now believe this can be the case, it looks plausible that this will improve the buffering in writes. *However* the fact that I now think this could fix the issue isn't the proof I would look for when closing a performance bug. >> >> I would still like to see some kind of performance metric or benchmark that shows that buffering of writes actually occur, this doesn't need to be a repeatable test, but can be a report or summary from an instrumented test run or something similar. However I do *believe* this should fix the problem so I don't object to Jon sponsoring this if he is confident with the change. > > In general, I agree with @jbf about validating performance improvements. However, I think that this change is as much about cleanup as it is about performance, especially since `FilterOutputStream` specifically recommends that this method _should_ be overridden: > > ` > Note that this method does not call the write method of its underlying output stream with the same arguments. > Subclasses of FilterOutputStream should provide a more efficient implementation of this method. > ` > > It is not clear to be that we can write a reasonable performance test, since as has been noted, it depends on the underlying stream. But I do think that the proposed change makes the code cleaner and simpler, and in general will do no worse than before. I write two tests(small and large file) by using the JMH to verify the performance. I push the test code to [JDK-8255729-Test](https://github.com/lgxbslgx/JDK-8255729-Test) for you to reproduce. --- **One is a large file.** - Using this patch. The result: Result "test.T8255729_Large.testWriteTime": 18043.388 ?(99.9%) 1696.325 us/op [Average] (min, avg, max) = (13011.716, 18043.388, 28295.985), stdev = 3426.661 CI (99.9%): [16347.063, 19739.714] (assumes normal distribution) - Using the master branch. The result: Result "test.T8255729_Large.testWriteTime": 157795.683 ?(99.9%) 2660.637 us/op [Average] (min, avg, max) = (151689.305, 157795.683, 183340.380), stdev = 5374.619 CI (99.9%): [155135.046, 160456.320] (assumes normal distribution) You can see that the average time of the master branch is about 8.7 times(157795.683/18043.388) that of this patch. --- **Another is a small file.** - Using this patch. The result: Result "test.T8255729_Small.testWriteTime": 13830.577 ?(99.9%) 1045.225 us/op [Average] (min, avg, max) = (11352.977, 13830.577, 20271.217), stdev = 2111.406 CI (99.9%): [12785.352, 14875.802] (assumes normal distribution) - Using the master branch. The result: Result "test.T8255729_Small.testWriteTime": 17166.427 ?(99.9%) 822.553 us/op [Average] (min, avg, max) = (14612.349, 17166.427, 22088.647), stdev = 1661.597 CI (99.9%): [16343.875, 17988.980] (assumes normal distribution) You can see that the average time of the master branch is about 1.2 times(17166.427/13830.577) that of this patch. The difference is little because it is a small file. --- And we can consider another aspect. - When the file becomes very large, the average time of this patch increases little(13830.577 -> 18043.388). - When the file becomes very large, the average time of the master branch increases a lot(17166.427 -> 157795.683). --- The concrete reports are shown below. [JDK-8255729.txt](https://github.com/openjdk/jdk/files/5762068/JDK-8255729.txt) [master.txt](https://github.com/openjdk/jdk/files/5762069/master.txt) ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From github.com+13688759+lgxbslgx at openjdk.java.net Sun Jan 3 19:10:55 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sun, 3 Jan 2021 19:10:55 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: <8R4Dnf3VOSaHScty2v2rYqvRe0II0ONdb_DNVutfANE=.098a3b55-d297-4032-861c-415596a912fd@github.com> References: <8R4Dnf3VOSaHScty2v2rYqvRe0II0ONdb_DNVutfANE=.098a3b55-d297-4032-861c-415596a912fd@github.com> Message-ID: On Sun, 3 Jan 2021 18:54:26 GMT, Guoxiong Li wrote: >> In general, I agree with @jbf about validating performance improvements. However, I think that this change is as much about cleanup as it is about performance, especially since `FilterOutputStream` specifically recommends that this method _should_ be overridden: >> >> ` >> Note that this method does not call the write method of its underlying output stream with the same arguments. >> Subclasses of FilterOutputStream should provide a more efficient implementation of this method. >> ` >> >> It is not clear to be that we can write a reasonable performance test, since as has been noted, it depends on the underlying stream. But I do think that the proposed change makes the code cleaner and simpler, and in general will do no worse than before. > > I write two tests(small and large file) by using the JMH to verify the performance. I push the test code to [JDK-8255729-Test](https://github.com/lgxbslgx/JDK-8255729-Test) for you to reproduce. > > --- > **One is a large file.** > - Using this patch. The result: > > Result "test.T8255729_Large.testWriteTime": > 18043.388 ?(99.9%) 1696.325 us/op [Average] > (min, avg, max) = (13011.716, 18043.388, 28295.985), stdev = 3426.661 > CI (99.9%): [16347.063, 19739.714] (assumes normal distribution) > > - Using the master branch. The result: > > Result "test.T8255729_Large.testWriteTime": > 157795.683 ?(99.9%) 2660.637 us/op [Average] > (min, avg, max) = (151689.305, 157795.683, 183340.380), stdev = 5374.619 > CI (99.9%): [155135.046, 160456.320] (assumes normal distribution) > > You can see that the average time of the master branch is about 8.7 times(157795.683/18043.388) that of this patch. > > --- > **Another is a small file.** > - Using this patch. The result: > > Result "test.T8255729_Small.testWriteTime": > 13830.577 ?(99.9%) 1045.225 us/op [Average] > (min, avg, max) = (11352.977, 13830.577, 20271.217), stdev = 2111.406 > CI (99.9%): [12785.352, 14875.802] (assumes normal distribution) > > - Using the master branch. The result: > > Result "test.T8255729_Small.testWriteTime": > 17166.427 ?(99.9%) 822.553 us/op [Average] > (min, avg, max) = (14612.349, 17166.427, 22088.647), stdev = 1661.597 > CI (99.9%): [16343.875, 17988.980] (assumes normal distribution) > > You can see that the average time of the master branch is about 1.2 times(17166.427/13830.577) that of this patch. The difference is little because it is a small file. > > --- > And we can consider another aspect. > - When the file becomes very large, the average time of this patch increases little(13830.577 -> 18043.388). > - When the file becomes very large, the average time of the master branch increases a lot(17166.427 -> 157795.683). > > --- > The concrete reports are shown below. > [JDK-8255729.txt](https://github.com/openjdk/jdk/files/5762068/JDK-8255729.txt) > [master.txt](https://github.com/openjdk/jdk/files/5762069/master.txt) And I think this is an issue about performance instead of cleanup. Whether it is about performance or cleanup, it may only affect the label of the bug, `noreg-cleanup` or `noreg-perf`. So I think we don't need to continue arguing about it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From jfranck at openjdk.java.net Mon Jan 4 10:31:55 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Mon, 4 Jan 2021 10:31:55 GMT Subject: RFR: 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient [v2] In-Reply-To: References: <8R4Dnf3VOSaHScty2v2rYqvRe0II0ONdb_DNVutfANE=.098a3b55-d297-4032-861c-415596a912fd@github.com> Message-ID: On Sun, 3 Jan 2021 19:07:14 GMT, Guoxiong Li wrote: >> I write two tests(small and large file) by using the JMH to verify the performance. I push the test code to [JDK-8255729-Test](https://github.com/lgxbslgx/JDK-8255729-Test) for you to reproduce. >> >> --- >> **One is a large file.** >> - Using this patch. The result: >> >> Result "test.T8255729_Large.testWriteTime": >> 18043.388 ?(99.9%) 1696.325 us/op [Average] >> (min, avg, max) = (13011.716, 18043.388, 28295.985), stdev = 3426.661 >> CI (99.9%): [16347.063, 19739.714] (assumes normal distribution) >> >> - Using the master branch. The result: >> >> Result "test.T8255729_Large.testWriteTime": >> 157795.683 ?(99.9%) 2660.637 us/op [Average] >> (min, avg, max) = (151689.305, 157795.683, 183340.380), stdev = 5374.619 >> CI (99.9%): [155135.046, 160456.320] (assumes normal distribution) >> >> You can see that the average time of the master branch is about 8.7 times(157795.683/18043.388) that of this patch. >> >> --- >> **Another is a small file.** >> - Using this patch. The result: >> >> Result "test.T8255729_Small.testWriteTime": >> 13830.577 ?(99.9%) 1045.225 us/op [Average] >> (min, avg, max) = (11352.977, 13830.577, 20271.217), stdev = 2111.406 >> CI (99.9%): [12785.352, 14875.802] (assumes normal distribution) >> >> - Using the master branch. The result: >> >> Result "test.T8255729_Small.testWriteTime": >> 17166.427 ?(99.9%) 822.553 us/op [Average] >> (min, avg, max) = (14612.349, 17166.427, 22088.647), stdev = 1661.597 >> CI (99.9%): [16343.875, 17988.980] (assumes normal distribution) >> >> You can see that the average time of the master branch is about 1.2 times(17166.427/13830.577) that of this patch. The difference is little because it is a small file. >> >> --- >> And we can consider another aspect. >> - When the file becomes very large, the average time of this patch increases little(13830.577 -> 18043.388). >> - When the file becomes very large, the average time of the master branch increases a lot(17166.427 -> 157795.683). >> >> --- >> The concrete reports are shown below. >> [JDK-8255729.txt](https://github.com/openjdk/jdk/files/5762068/JDK-8255729.txt) >> [master.txt](https://github.com/openjdk/jdk/files/5762069/master.txt) > > And I think this is an issue about performance instead of cleanup. > > Whether it is about performance or cleanup, it may only affect the label of the bug, `noreg-cleanup` or `noreg-perf`. So I think we don't need to continue arguing about it. @lgxbslgx thank you, this was exactly what I was looking for! ------------- PR: https://git.openjdk.java.net/jdk/pull/1854 From erikj at openjdk.java.net Mon Jan 4 15:32:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 4 Jan 2021 15:32:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - Step 2: Update references > - First stage, move actual data files Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlahoda at openjdk.java.net Mon Jan 4 15:55:07 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 4 Jan 2021 15:55:07 GMT Subject: [jdk16] RFR: 8256266: Binding variables don't correctly support declaration annotations and the final modifier Message-ID: [This is a copy of https://github.com/openjdk/jdk/pull/1192, but filled against the JDK 16 branch.] Basically, javac does not handle code like this properly: import java.lang.annotation.*; public class B { public void test(Object o) { if (o instanceof @A String s) {} } } @Target(ElementType.LOCAL_VARIABLE) @interface A {} The parser needs to allow declaration annotations on binding variables, see: http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1 ------------- Commit messages: - Removing forgotten debug call. - Reject final modifiers on non-pattern matching instanceof. - Fixing tests. - Merge branch 'JDK-8256266' of https://github.com/lahodaj/jdk into JDK-8256266 - Removing an extra whitespace. - The 'final' modifier should be allowed on binding variables. - Merge branch 'master' into JDK-8256266 - 8256266: Declaration annotations don't work properly for binding variables Changes: https://git.openjdk.java.net/jdk16/pull/78/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=78&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256266 Stats: 240 lines in 10 files changed: 228 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk16/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/78/head:pull/78 PR: https://git.openjdk.java.net/jdk16/pull/78 From mcimadamore at openjdk.java.net Mon Jan 4 16:19:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 16:19:58 GMT Subject: [jdk16] RFR: 8256266: Binding variables don't correctly support declaration annotations and the final modifier In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 15:50:27 GMT, Jan Lahoda wrote: > [This is a copy of https://github.com/openjdk/jdk/pull/1192, but filled against the JDK 16 branch.] > > Basically, javac does not handle code like this properly: > > import java.lang.annotation.*; > > public class B { > public void test(Object o) { > if (o instanceof @A String s) {} > } > } > > @Target(ElementType.LOCAL_VARIABLE) > @interface A {} > > The parser needs to allow declaration annotations on binding variables, see: > http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1 Changes look good (already reviewed in https://github.com/openjdk/jdk/pull/1192) ------------- PR: https://git.openjdk.java.net/jdk16/pull/78 From github.com+13688759+lgxbslgx at openjdk.java.net Mon Jan 4 17:44:07 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Mon, 4 Jan 2021 17:44:07 GMT Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering Message-ID: Hi all, This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8241187: ToolBox::grep should allow for negative filtering Changes: https://git.openjdk.java.net/jdk/pull/1934/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1934&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241187 Stats: 80 lines in 2 files changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1934/head:pull/1934 PR: https://git.openjdk.java.net/jdk/pull/1934 From jjg at openjdk.java.net Mon Jan 4 18:14:03 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 4 Jan 2021 18:14:03 GMT Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 17:17:58 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated. > > Thank you for taking the time to review. > > Best Regards. test/langtools/tools/lib/toolbox/ToolBox.java line 204: > 202: * @return the strings not matching the regular expression > 203: */ > 204: public List grepNotMatch(Pattern pattern, List lines) { Instead of new methods named `grepNotMatch` I suggest adding new overloads of `grep` that take an additional `boolean invert` parameter that is conceptually equivalent to the `grep` `-v` option. The existing `grep` methods can be updated to delegate to the new methods, passing `false` for the new parameter. ------------- PR: https://git.openjdk.java.net/jdk/pull/1934 From jlahoda at openjdk.java.net Mon Jan 4 21:21:00 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 4 Jan 2021 21:21:00 GMT Subject: [jdk16] RFR: 8213032: program fails with LambdaConversionException at execution time In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 23:41:00 GMT, Vicente Romero wrote: > Hi, > > Currently javac is accepting this code: > > import java.util.stream.*; > > public class Test { > interface I {} > static abstract class C { } > static class A extends C implements I { } > static class B extends C implements I { } > > static String f(I i) { return null; } > > public static void main(String[] args) { > Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); > } > } > > the line with the method reference can also be written using a lambda expression like in: > > Stream.of(new A(), new B()).map(i -> f(i)).forEach(System.out::println); > but the code with the method reference, is failing later at execution time with `LambdaConversionException`. Currently javac is desugaring the method reference to the equivalent lambda but the argument of generated lambda is: `Test$I` at the same time the target type of the method reference has argument with type `C & I` which will be desugared by the compiler to `C`. This is the reason for the runtime error. The right type for the argument of the desugared method generated by javac is `C` which is what this patch is doing. The change to method `ReferenceTranslationContext::bridgedRefSig` has been done in order to obtain a more exact version of the target type, as the current implementation is returning `Object` in most cases, which is OK, but I think that we could generate a better, more accurate, type. > > TIA for the review Looks reasonable. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/49 From prr at openjdk.java.net Mon Jan 4 21:24:14 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 4 Jan 2021 21:24:14 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - Step 2: Update references > - First stage, move actual data files Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlahoda at openjdk.java.net Mon Jan 4 21:32:59 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 4 Jan 2021 21:32:59 GMT Subject: [jdk16] RFR: 8258972: unexpected compilation error with generic sealed interface In-Reply-To: References: Message-ID: On Tue, 29 Dec 2020 19:04:16 GMT, Vicente Romero wrote: > Hi, > > Please review this fix to the implementation of section `5.1.6.1 Allowed Narrowing Reference Conversion` of the Sealed Classes spec [1](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html#jls-5.1.6.1). IMO the compiler was not implementing the spec to the letter in particular the inheritance relation between a sealed class and a subclass should be tested ignoring type arguments which is what this patch is doing. Comments? > > Thanks, > Vicente src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1670: > 1668: // where > 1669: private boolean areDisjoint(ClassSymbol ts, ClassSymbol ss) { > 1670: if (isSubtype(erasure(ts.type), erasure(ss.type))) { There is another `isSubtype` below - could you please check if it needs the same erasure handling? ------------- PR: https://git.openjdk.java.net/jdk16/pull/72 From vromero at openjdk.java.net Mon Jan 4 22:41:17 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 4 Jan 2021 22:41:17 GMT Subject: [jdk16] RFR: 8213032: program fails with LambdaConversionException at execution time [v2] In-Reply-To: References: Message-ID: <0a4I91uI_Zz5CPB2SUsOL_CzUs_UQNZHBoSXhpKw9dQ=.c33eb3d6-d2ad-4d39-95da-e218db45c79a@github.com> > Hi, > > Currently javac is accepting this code: > > import java.util.stream.*; > > public class Test { > interface I {} > static abstract class C { } > static class A extends C implements I { } > static class B extends C implements I { } > > static String f(I i) { return null; } > > public static void main(String[] args) { > Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); > } > } > > the line with the method reference can also be written using a lambda expression like in: > > Stream.of(new A(), new B()).map(i -> f(i)).forEach(System.out::println); > but the code with the method reference, is failing later at execution time with `LambdaConversionException`. Currently javac is desugaring the method reference to the equivalent lambda but the argument of generated lambda is: `Test$I` at the same time the target type of the method reference has argument with type `C & I` which will be desugared by the compiler to `C`. This is the reason for the runtime error. The right type for the argument of the desugared method generated by javac is `C` which is what this patch is doing. The change to method `ReferenceTranslationContext::bridgedRefSig` has been done in order to obtain a more exact version of the target type, as the current implementation is returning `Object` in most cases, which is OK, but I think that we could generate a better, more accurate, type. > > TIA for the review Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8213032 - 8213032: program fails with LambdaConversionException at execution time ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/49/files - new: https://git.openjdk.java.net/jdk16/pull/49/files/4d8ef5d8..1b4c3677 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=49&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=49&range=00-01 Stats: 2282 lines in 112 files changed: 1649 ins; 319 del; 314 mod Patch: https://git.openjdk.java.net/jdk16/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk16/pull/49 From mcimadamore at openjdk.java.net Tue Jan 5 11:19:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 11:19:58 GMT Subject: [jdk16] RFR: 8256266: Binding variables don't correctly support declaration annotations and the final modifier In-Reply-To: References: Message-ID: <31SjTkXcYNSF76brqAFy6zbHOfy9iv_oPrdCkaSm1ts=.df0b99e9-29b7-4914-8b64-9c0a9dc8e428@github.com> On Mon, 4 Jan 2021 15:50:27 GMT, Jan Lahoda wrote: > [This is a copy of https://github.com/openjdk/jdk/pull/1192, but filled against the JDK 16 branch.] > > Basically, javac does not handle code like this properly: > > import java.lang.annotation.*; > > public class B { > public void test(Object o) { > if (o instanceof @A String s) {} > } > } > > @Target(ElementType.LOCAL_VARIABLE) > @interface A {} > > The parser needs to allow declaration annotations on binding variables, see: > http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1 Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/78 From jlahoda at openjdk.java.net Tue Jan 5 11:43:00 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 5 Jan 2021 11:43:00 GMT Subject: [jdk16] Integrated: 8256266: Binding variables don't correctly support declaration annotations and the final modifier In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 15:50:27 GMT, Jan Lahoda wrote: > [This is a copy of https://github.com/openjdk/jdk/pull/1192, but filled against the JDK 16 branch.] > > Basically, javac does not handle code like this properly: > > import java.lang.annotation.*; > > public class B { > public void test(Object o) { > if (o instanceof @A String s) {} > } > } > > @Target(ElementType.LOCAL_VARIABLE) > @interface A {} > > The parser needs to allow declaration annotations on binding variables, see: > http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1 This pull request has now been integrated. Changeset: 4ffbe841 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk16/commit/4ffbe841 Stats: 240 lines in 10 files changed: 228 ins; 3 del; 9 mod 8256266: Binding variables don't correctly support declaration annotations and the final modifier Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk16/pull/78 From jlahoda at openjdk.java.net Tue Jan 5 11:55:06 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 5 Jan 2021 11:55:06 GMT Subject: RFR: 8256266: Binding variables don't correct support declaration annotations and the final modifier [v4] In-Reply-To: <_FJAmi9u-u6iV0YsbYoM4EY6x4Ho5e26SZSmduPQNhE=.b1549acd-f958-4315-a97e-3b6d9dbc5232@github.com> References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com> <8nXnKIH3Y5w6JWnqjB7lXJxMDr96cxejqW__x8h2DJc=.85e8deff-0b79-42a4-9d08-40b861393ce7@github.com> <_FJAmi9u-u6iV0YsbYoM4EY6x4Ho5e26SZSmduPQNhE=.b1549acd-f958-4315-a97e-3b6d9dbc5232@github.com> Message-ID: On Tue, 8 Dec 2020 12:44:44 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: >> >> - Removing forgotten debug call. >> - Reject final modifiers on non-pattern matching instanceof. > > Changes look good to me Has been integrated as: https://git.openjdk.java.net/jdk16/pull/78 ------------- PR: https://git.openjdk.java.net/jdk/pull/1192 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Jan 5 12:04:17 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 5 Jan 2021 12:04:17 GMT Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds two methods in `ToolBox` to do the negative filtering. Although the label `noreg-self` was added, I write a test for this enhancement to verify the code. And the method name `grepNotMatch` may need to be improved. Any idea is appreciated. > > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Revise method and test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1934/files - new: https://git.openjdk.java.net/jdk/pull/1934/files/26b1589d..f55e8a3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1934&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1934&range=00-01 Stats: 45 lines in 2 files changed: 27 ins; 2 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1934/head:pull/1934 PR: https://git.openjdk.java.net/jdk/pull/1934 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Jan 5 12:04:18 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 5 Jan 2021 12:04:18 GMT Subject: RFR: 8241187: ToolBox::grep should allow for negative filtering [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 18:11:14 GMT, Jonathan Gibbons wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise method and test. > > test/langtools/tools/lib/toolbox/ToolBox.java line 204: > >> 202: * @return the strings not matching the regular expression >> 203: */ >> 204: public List grepNotMatch(Pattern pattern, List lines) { > > Instead of new methods named `grepNotMatch` I suggest adding new overloads of `grep` that take an additional `boolean invert` parameter that is conceptually equivalent to the `grep` `-v` option. The existing `grep` methods can be updated to delegate to the new methods, passing `false` for the new parameter. @jonathan-gibbons Thank you for your suggestion. The code is updated now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1934 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Jan 5 14:27:56 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 5 Jan 2021 14:27:56 GMT Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone [v3] In-Reply-To: References: <1emE2SMPj-xOWirhYjekcvC90xjeXRnyGsPAWBXDDRc=.aecc36e2-71ff-4ef5-919e-bffd2926bf9a@github.com> Message-ID: On Thu, 31 Dec 2020 16:31:39 GMT, Vicente Romero wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Map::clear > > Marked as reviewed by vromero (Reviewer). @vicente-romero-oracle @jonathan-gibbons The code was updated. Could I get your help to re-review and sponsor? Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/1912 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Jan 5 14:31:57 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 5 Jan 2021 14:31:57 GMT Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3] In-Reply-To: References: <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com> Message-ID: On Tue, 29 Dec 2020 03:43:14 GMT, Jonathan Gibbons wrote: >> Any time that tests split a string into lines it is really important to ensure that it works on Windows as well as Linux/Mac platforms, because of the different line endings. >> >> The code looks OK. Alternatively, if you are not concerned to check for the exact line ending sequence, you can use `split("\\R")` to split on any line ending sequence. Either way, it's worth checking the test runs on platforms with both kinds of typical line ending. > > Given that the `langtools/tier1` pre-submit tests worked for Linux and Windows, you're OK on the "newline" front. @jonathan-gibbons I updated the code according to your comments. Thank you for taking the time to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1896 From jlahoda at openjdk.java.net Tue Jan 5 16:54:04 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 5 Jan 2021 16:54:04 GMT Subject: RFR: 8259235: javac crashes while attributing super method invocation Message-ID: Code like: public class SuperMethodCallBroken extends Undef implements I { public void test() { I.super.test(); } } interface I { public default void test() {} } crashes javac. The reason is that when `I.super` is being attributed, the interfaces of the enclosing class are pruned to remove subtypes - but `Undef` is erroneous and is a subtype of every type. So `I` is removed from the list of interfaces to check, and javac crashes then. The proposed fix is to ignore erroneous supertypes when looking for subtypes. ------------- Commit messages: - 8259235: javac crashes while attributing super method invocation Changes: https://git.openjdk.java.net/jdk/pull/1945/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1945&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259235 Stats: 18 lines in 3 files changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1945.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1945/head:pull/1945 PR: https://git.openjdk.java.net/jdk/pull/1945 From vromero at openjdk.java.net Tue Jan 5 17:59:13 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 5 Jan 2021 17:59:13 GMT Subject: [jdk16] RFR: 8213032: program fails with LambdaConversionException at execution time [v3] In-Reply-To: References: Message-ID: > Hi, > > Currently javac is accepting this code: > > import java.util.stream.*; > > public class Test { > interface I {} > static abstract class C { } > static class A extends C implements I { } > static class B extends C implements I { } > > static String f(I i) { return null; } > > public static void main(String[] args) { > Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); > } > } > > the line with the method reference can also be written using a lambda expression like in: > > Stream.of(new A(), new B()).map(i -> f(i)).forEach(System.out::println); > but the code with the method reference, is failing later at execution time with `LambdaConversionException`. Currently javac is desugaring the method reference to the equivalent lambda but the argument of generated lambda is: `Test$I` at the same time the target type of the method reference has argument with type `C & I` which will be desugared by the compiler to `C`. This is the reason for the runtime error. The right type for the argument of the desugared method generated by javac is `C` which is what this patch is doing. The change to method `ReferenceTranslationContext::bridgedRefSig` has been done in order to obtain a more exact version of the target type, as the current implementation is returning `Object` in most cases, which is OK, but I think that we could generate a better, more accurate, type. > > TIA for the review Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: restoring original implementation of method ReferenceTranslationContext::bridgedRefSig ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/49/files - new: https://git.openjdk.java.net/jdk16/pull/49/files/1b4c3677..a83e92c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=49&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=49&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk16/pull/49 From vromero at openjdk.java.net Tue Jan 5 20:28:12 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 5 Jan 2021 20:28:12 GMT Subject: [jdk16] RFR: 8258972: unexpected compilation error with generic sealed interface [v2] In-Reply-To: References: Message-ID: <4xInv4X_7p_4hjJ5wSN8m7_rQ2WhXOyn040rpfuAu-Y=.66e58357-67e6-4108-95a2-a5ef447daf15@github.com> > Hi, > > Please review this fix to the implementation of section `5.1.6.1 Allowed Narrowing Reference Conversion` of the Sealed Classes spec [1](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html#jls-5.1.6.1). IMO the compiler was not implementing the spec to the letter in particular the inheritance relation between a sealed class and a subclass should be tested ignoring type arguments which is what this patch is doing. Comments? > > Thanks, > Vicente Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8258972 - 8258972: unexpected compilation error with generic sealed interface ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/72/files - new: https://git.openjdk.java.net/jdk16/pull/72/files/91d25308..36017f21 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=72&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=72&range=00-01 Stats: 35 lines in 2 files changed: 31 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk16/pull/72.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/72/head:pull/72 PR: https://git.openjdk.java.net/jdk16/pull/72 From vromero at openjdk.java.net Tue Jan 5 20:32:11 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 5 Jan 2021 20:32:11 GMT Subject: [jdk16] RFR: 8258972: unexpected compilation error with generic sealed interface [v3] In-Reply-To: References: Message-ID: > Hi, > > Please review this fix to the implementation of section `5.1.6.1 Allowed Narrowing Reference Conversion` of the Sealed Classes spec [1](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html#jls-5.1.6.1). IMO the compiler was not implementing the spec to the letter in particular the inheritance relation between a sealed class and a subclass should be tested ignoring type arguments which is what this patch is doing. Comments? > > Thanks, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding missing calls to Types::erasure ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/72/files - new: https://git.openjdk.java.net/jdk16/pull/72/files/36017f21..60c60bd9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=72&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=72&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/72.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/72/head:pull/72 PR: https://git.openjdk.java.net/jdk16/pull/72 From vromero at openjdk.java.net Tue Jan 5 20:32:12 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 5 Jan 2021 20:32:12 GMT Subject: [jdk16] RFR: 8258972: unexpected compilation error with generic sealed interface [v3] In-Reply-To: References: Message-ID: On Mon, 4 Jan 2021 21:29:19 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> adding missing calls to Types::erasure > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1670: > >> 1668: // where >> 1669: private boolean areDisjoint(ClassSymbol ts, ClassSymbol ss) { >> 1670: if (isSubtype(erasure(ts.type), erasure(ss.type))) { > > There is another `isSubtype` below - could you please check if it needs the same erasure handling? I agree, done ------------- PR: https://git.openjdk.java.net/jdk16/pull/72 From vromero at openjdk.java.net Tue Jan 5 21:39:02 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 5 Jan 2021 21:39:02 GMT Subject: [jdk16] Integrated: 8213032: program fails with LambdaConversionException at execution time In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 23:41:00 GMT, Vicente Romero wrote: > Hi, > > Currently javac is accepting this code: > > import java.util.stream.*; > > public class Test { > interface I {} > static abstract class C { } > static class A extends C implements I { } > static class B extends C implements I { } > > static String f(I i) { return null; } > > public static void main(String[] args) { > Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); > } > } > > the line with the method reference can also be written using a lambda expression like in: > > Stream.of(new A(), new B()).map(i -> f(i)).forEach(System.out::println); > but the code with the method reference, is failing later at execution time with `LambdaConversionException`. Currently javac is desugaring the method reference to the equivalent lambda but the argument of generated lambda is: `Test$I` at the same time the target type of the method reference has argument with type `C & I` which will be desugared by the compiler to `C`. This is the reason for the runtime error. The right type for the argument of the desugared method generated by javac is `C` which is what this patch is doing. The change to method `ReferenceTranslationContext::bridgedRefSig` has been done in order to obtain a more exact version of the target type, as the current implementation is returning `Object` in most cases, which is OK, but I think that we could generate a better, more accurate, type. > > TIA for the review This pull request has now been integrated. Changeset: d5293067 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk16/commit/d5293067 Stats: 60 lines in 2 files changed: 54 ins; 4 del; 2 mod 8213032: program fails with LambdaConversionException at execution time Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk16/pull/49 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Jan 5 22:23:57 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 5 Jan 2021 22:23:57 GMT Subject: Integrated: 8255757: Javac emits duplicate pool entries on array::clone In-Reply-To: References: Message-ID: On Wed, 30 Dec 2020 17:55:48 GMT, Guoxiong Li wrote: > Hi all, > > Currently, javac would emit duplicate pool entries when compiling array::clone. > This patch fixes it by using a cached field `Map qualifiedSymbolCache;` and adds a corresponding test case. > > Thank you for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: 7d769663 Author: Guoxiong Li Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/7d769663 Stats: 120 lines in 2 files changed: 117 ins; 0 del; 3 mod 8255757: Javac emits duplicate pool entries on array::clone Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/1912 From darcy at openjdk.java.net Wed Jan 6 02:25:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Jan 2021 02:25:03 GMT Subject: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Message-ID: Updating to the symbol files for JDK 16 b30; change generated with the script make/scripts/generate-symbol-data.sh The change to the java.desktop module looks to be for JDK-8258373. ------------- Commit messages: - 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Changes: https://git.openjdk.java.net/jdk/pull/1954/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1954&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258143 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1954.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1954/head:pull/1954 PR: https://git.openjdk.java.net/jdk/pull/1954 From iris at openjdk.java.net Wed Jan 6 02:52:56 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 6 Jan 2021 02:52:56 GMT Subject: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1954 From bsrbnd at gmail.com Wed Jan 6 13:02:14 2021 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 6 Jan 2021 14:02:14 +0100 Subject: Records, Intersection type and lambda In-Reply-To: References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Vicente, I saw you've integrated the initial fix with no additional change which seems reasonable. However, did you also try the example I provided below as I'm not absolutely sure this works? Otherwise, you may look at the experimental fix I suggested. Thanks, Bernard On Sun, 27 Dec 2020 at 22:31, B. Blaser wrote: > > Hi Vicente, > > On Wed, 23 Dec 2020 at 04:29, Vicente Romero wrote: > > > > Hi Bernard, > > > > what side effects do you see? > > By tweaking Remi's example: > > public class RecLCE { > interface Foo { } > interface F { > void call(T t); > } > > record Bar1() implements Foo { } > record Bar2() implements Foo { } > record Pair

(P p1, P p2) { > > static

Pair

of(P p1, P p2) { > return new Pair

(p1, p2); > } > > void forEach(F

f) { > f.call(p1); > f.call(p2); > } > } > > static class Hello { > void m(Foo foo) { > System.out.println(foo.getClass()); > } > } > > public static void main(String[] args) { > var pair = Pair.of(new Bar1(), new Bar2()); > pair.forEach(new Hello()::m); > } > } > > The line you've added is causing the lambda to use the instantiated > type 'Record' which isn't a subtype of 'Foo', see javap's output: > Method arguments: > #57 (LRecLCE$Foo;)V > #58 REF_invokeStatic > RecLCE.lambda$main$0:(LRecLCE$Hello;Ljava/lang/Record;)V > #61 (Ljava/lang/Record;)V > > So, it should use the un-instantiated SAM parameter type 'Foo' instead > which my initial fix was suggesting: > Method arguments: > #57 (LRecLCE$Foo;)V > #58 REF_invokeStatic RecLCE.lambda$main$0:(LRecLCE$Hello;LRecLCE$Foo;)V > #61 (Ljava/lang/Record;)V > > Unfortunately, this very example reveals another issue as the > instantiated type 'Record' is still not convertible to 'Foo' although > all was working fine with Remis's initial example: > Method arguments: > #55 (Ljava/lang/Object;)V > #57 REF_invokeStatic > RecordIntersectionTypeAndLambda.lambda$main$0:(LRecordIntersectionTypeAndLambda$Hello;Ljava/lang/Object;)V > #60 (Ljava/lang/Record;)V > > Referring to 'LambdaMetafactory::metafactory', we see that > 'instantiatedMethodType' may be the same or a specialization of > 'samMethodType' suggesting to use the SAM type too when the > instantiated type is compound like in the experimental fix below > (langtools:tier1 is OK on jdk14u): > Method arguments: > #57 (LRecLCE$Foo;)V > #58 REF_invokeStatic RecLCE.lambda$main$0:(LRecLCE$Hello;LRecLCE$Foo;)V > #57 (LRecLCE$Foo;)V > > What do you think? > Bernard > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > @@ -438,6 +438,7 @@ > List indy_args = > translate(syntheticInits.toList(), localContext.prev); > > //convert to an invokedynamic call > + localContext.useSAM = tree.useSAM; > result = makeMetafactoryIndyCall(context, sym.asHandle(), indy_args); > } > > @@ -888,6 +889,7 @@ > private final ListBuffer params = new ListBuffer<>(); > > private JCExpression receiverExpression = null; > + private boolean useSAM = false; > > MemberReferenceToLambda(JCMemberReference tree, > ReferenceTranslationContext localContext, Symbol owner) { > this.tree = tree; > @@ -911,6 +913,7 @@ > slam.target = tree.target; > slam.type = tree.type; > slam.pos = tree.pos; > + slam.useSAM = useSAM; > return slam; > } finally { > make.at(prevPos); > @@ -954,6 +957,7 @@ > > // Failsafe -- assure match-up > boolean checkForIntersection = tree.varargsElement != > null || implSize == descPTypes.size(); > + useSAM = checkForIntersection && > localContext.interfaceParameterIsIntersectionOrUnionType(); > > // Use parameter types of the implementation method > unless the unerased > // SAM parameter type is an intersection type, in that case use the > @@ -963,18 +967,7 @@ > // are used as pointers to the current parameter type information > // and are thus not usable afterwards. > for (int i = 0; implPTypes.nonEmpty() && i < last; ++i) { > - // By default use the implementation method parmeter type > - Type parmType = implPTypes.head; > - // If the unerased parameter type is a type variable whose > - // bound is an intersection (eg. ) then > - // use the SAM parameter type > - if (checkForIntersection && descPTypes.head.getKind() > == TypeKind.TYPEVAR) { > - TypeVar tv = (TypeVar) descPTypes.head; > - if (tv.getUpperBound().getKind() == > TypeKind.INTERSECTION) { > - parmType = samPTypes.head; > - } > - } > - addParameter("x$" + i, parmType, true); > + addParameter("x$" + i, useSAM ? samPTypes.head : > implPTypes.head, true); > > // Advance to the next parameter > implPTypes = implPTypes.tail; > @@ -1094,7 +1087,7 @@ > List staticArgs = List.of( > typeToMethodType(samSym.type), > refSym.asHandle(), > - typeToMethodType(tree.getDescriptorType(types))); > + typeToMethodType(context.useSAM ? samSym.type : > tree.getDescriptorType(types))); > > //computed indy arg types > ListBuffer indy_args_types = new ListBuffer<>(); > @@ -1826,6 +1819,8 @@ > /** list of methods to be bridged by the meta-factory */ > final List bridges; > > + boolean useSAM = false; > + > TranslationContext(T tree) { > this.tree = tree; > this.owner = owner(true); > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java > @@ -1892,6 +1892,7 @@ > public JCTree body; > public boolean canCompleteNormally = true; > public ParameterKind paramKind; > + public boolean useSAM = false; > > public JCLambda(List params, > JCTree body) { From erikj at openjdk.java.net Wed Jan 6 13:22:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 6 Jan 2021 13:22:52 GMT Subject: RFR: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1954 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Jan 6 14:29:05 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 6 Jan 2021 14:29:05 GMT Subject: RFR: 8150303: Rewrite test/tools/javac/Paths/Diagnostics.sh Message-ID: Hi all, This patch rewrites Diagnostics.sh to java code by using ToolBox API. And I have a question: What does the `elts` mean in the following comments? Is it `elements`? I think that a meaningful name should be used. // Warn for missing elts in user-specified paths // No warning for missing elts in "system" paths Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8150303: Rewrite test/tools/javac/Paths/Diagnostics.sh Changes: https://git.openjdk.java.net/jdk/pull/1959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1959&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8150303 Stats: 520 lines in 2 files changed: 310 ins; 210 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1959/head:pull/1959 PR: https://git.openjdk.java.net/jdk/pull/1959 From jjg at openjdk.java.net Wed Jan 6 14:56:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 6 Jan 2021 14:56:55 GMT Subject: RFR: 8150303: Rewrite test/tools/javac/Paths/Diagnostics.sh In-Reply-To: References: Message-ID: <6MPitclYrzOynvD_qCe_lwnhxlRwTa7cfSy_H_ZJBbE=.9fc5bbae-1037-4049-ae03-38fe754a4e02@github.com> On Wed, 6 Jan 2021 14:18:49 GMT, Guoxiong Li wrote: > This patch rewrites Diagnostics.sh to java code by using ToolBox API. > And I have a question: What does the elts mean in the following comments? Is it elements? > I think that a meaningful name should be used. Brave person. There's a reason no one has converted this test so far. To answer your specific question: yes, `elts` should be read as an abbreviation for `elements` and yes, it would be good to clarify it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1959 From darcy at openjdk.java.net Wed Jan 6 16:29:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 6 Jan 2021 16:29:59 GMT Subject: Integrated: 8258143: Update --release 16 symbol information for JDK 16 build 30 or later In-Reply-To: References: Message-ID: On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote: > Updating to the symbol files for JDK 16 b30; change generated with the script > > make/scripts/generate-symbol-data.sh > > The change to the java.desktop module looks to be for JDK-8258373. This pull request has now been integrated. Changeset: d20d2fa9 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/d20d2fa9 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Reviewed-by: iris, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1954 From ysatowse at openjdk.java.net Wed Jan 6 22:51:02 2021 From: ysatowse at openjdk.java.net (Yoshiki Sato) Date: Wed, 6 Jan 2021 22:51:02 GMT Subject: Integrated: 8247957: remove doclint support for HTML 4 In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 03:26:16 GMT, Yoshiki Sato wrote: > HTML4 is no longer supported in javadoc. > > doclint needs to drop HTML4 support as well. > The changes consist of: > * Removing -Xhtmlversion option from doclint and --doclint-format from javac. > * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references. > * Updating makefile not to use removed option. > * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY) > * Fixing incorrect value checks for the id attribute. > * Modifying test code and expected outputs to be checked in HTML5 This pull request has now been integrated. Changeset: 28e1f4d9 Author: Yoshiki Sato Committer: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/28e1f4d9 Stats: 1499 lines in 60 files changed: 411 ins; 808 del; 280 mod 8247957: remove doclint support for HTML 4 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option 8258460: Remove --doclint-format option from javac 8256312: Valid anchor 'id' value not allowed Reviewed-by: jjg, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/893 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 7 10:15:17 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 7 Jan 2021 10:15:17 GMT Subject: RFR: 8150303: Rewrite test/tools/javac/Paths/Diagnostics.sh [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch rewrites Diagnostics.sh to java code by using ToolBox API. > And I have a question: What does the `elts` mean in the following comments? Is it `elements`? > I think that a meaningful name should be used. > > // Warn for missing elts in user-specified paths > // No warning for missing elts in "system" paths > > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Modify elts to elements. Use correct line separator. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1959/files - new: https://git.openjdk.java.net/jdk/pull/1959/files/7f2de0ff..ae0379b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1959&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1959&range=00-01 Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1959/head:pull/1959 PR: https://git.openjdk.java.net/jdk/pull/1959 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 7 10:38:53 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 7 Jan 2021 10:38:53 GMT Subject: RFR: 8150303: Rewrite test/tools/javac/Paths/Diagnostics.sh In-Reply-To: <6MPitclYrzOynvD_qCe_lwnhxlRwTa7cfSy_H_ZJBbE=.9fc5bbae-1037-4049-ae03-38fe754a4e02@github.com> References: <6MPitclYrzOynvD_qCe_lwnhxlRwTa7cfSy_H_ZJBbE=.9fc5bbae-1037-4049-ae03-38fe754a4e02@github.com> Message-ID: On Wed, 6 Jan 2021 14:54:13 GMT, Jonathan Gibbons wrote: >> Hi all, >> >> This patch rewrites Diagnostics.sh to java code by using ToolBox API. >> And I have a question: What does the `elts` mean in the following comments? Is it `elements`? >> I think that a meaningful name should be used. >> >> // Warn for missing elts in user-specified paths >> // No warning for missing elts in "system" paths >> >> Thank you for taking the time to review. >> >> Best Regards. > >> This patch rewrites Diagnostics.sh to java code by using ToolBox API. >> And I have a question: What does the elts mean in the following comments? Is it elements? >> I think that a meaningful name should be used. > > Brave person. There's a reason no one has converted this test so far. > > To answer your specific question: yes, `elts` should be read as an abbreviation for `elements` and yes, it would be good to clarify it. @jonathan-gibbons Thank you for your answer. I modify `elts` to `elements`. And I revise the test code about line separator because the test failed at windows in the pre-submit tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1959 From jlahoda at openjdk.java.net Thu Jan 7 15:05:37 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 7 Jan 2021 15:05:37 GMT Subject: [jdk16] RFR: 8258972: unexpected compilation error with generic sealed interface [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 20:32:11 GMT, Vicente Romero wrote: >> Hi, >> >> Please review this fix to the implementation of section `5.1.6.1 Allowed Narrowing Reference Conversion` of the Sealed Classes spec [1](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html#jls-5.1.6.1). IMO the compiler was not implementing the spec to the letter in particular the inheritance relation between a sealed class and a subclass should be tested ignoring type arguments which is what this patch is doing. Comments? >> >> Thanks, >> Vicente > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding missing calls to Types::erasure Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/72 From vromero at openjdk.java.net Thu Jan 7 16:42:00 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 7 Jan 2021 16:42:00 GMT Subject: [jdk16] Integrated: 8258972: unexpected compilation error with generic sealed interface In-Reply-To: References: Message-ID: On Tue, 29 Dec 2020 19:04:16 GMT, Vicente Romero wrote: > Hi, > > Please review this fix to the implementation of section `5.1.6.1 Allowed Narrowing Reference Conversion` of the Sealed Classes spec [1](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html#jls-5.1.6.1). IMO the compiler was not implementing the spec to the letter in particular the inheritance relation between a sealed class and a subclass should be tested ignoring type arguments which is what this patch is doing. Comments? > > Thanks, > Vicente This pull request has now been integrated. Changeset: acdd90b6 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk16/commit/acdd90b6 Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod 8258972: unexpected compilation error with generic sealed interface Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk16/pull/72 From vromero at openjdk.java.net Thu Jan 7 18:59:55 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 7 Jan 2021 18:59:55 GMT Subject: RFR: 8257740: Compiler crash when compiling type annotation on multicatch inside lambda [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 15:24:55 GMT, Guoxiong Li wrote: >> Hi all, >> >> When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data` of the new VarSymbol. Maybe it is because the field `data` is unused in later phase. >> >> Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`. >> >> It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`. >> >> This patch fixes it and adds corresponding test cases. >> In my patch, I only set the field ` data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used. >> >> Thank your for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix multi-catch test case. Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1648 From vromero at openjdk.java.net Thu Jan 7 18:59:56 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 7 Jan 2021 18:59:56 GMT Subject: RFR: 8257740: Compiler crash when compiling type annotation on multicatch inside lambda [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jan 2021 18:56:04 GMT, Vicente Romero wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix multi-catch test case. > > Marked as reviewed by vromero (Reviewer). looks good to me ------------- PR: https://git.openjdk.java.net/jdk/pull/1648 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 7 19:14:59 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 7 Jan 2021 19:14:59 GMT Subject: RFR: 8257740: Compiler crash when compiling type annotation on multicatch inside lambda [v2] In-Reply-To: References: Message-ID: <24MlZ9KKGUkrS0mLTtzrNLSBB1V9BQ6DbEtWy78Vs4A=.062f5c8a-1bc1-4570-9537-2e04cad74190@github.com> On Thu, 7 Jan 2021 18:56:55 GMT, Vicente Romero wrote: >> Marked as reviewed by vromero (Reviewer). > > looks good to me @vicente-romero-oracle Thank you for your review. Could I get your help to sponsor this patch? Thanks again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1648 From jlahoda at openjdk.java.net Thu Jan 7 20:23:16 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 7 Jan 2021 20:23:16 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: References: Message-ID: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Fixing tests after a merge. - Merging master into JDK-8250768 - Merging recent master changes into JDK-8250768 - Fixing navigator for the PREVIEW page. - Fixing typo. - Removing obsolette @PreviewFeature. - Merging master into JDK-8250768 - Removing unnecessary property keys. - Cleanup - removing unnecessary code. - Merging master into JDK-8250768-dev4 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde ------------- Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=12 Stats: 3719 lines in 134 files changed: 2724 ins; 695 del; 300 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Thu Jan 7 20:23:17 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 7 Jan 2021 20:23:17 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v12] In-Reply-To: References: Message-ID: <8Op-CSXTHItDGmtN_VyoyOdZe1WR9g4JkRe852pe274=.367211a5-5f71-473b-be53-ee3706e50786@github.com> On Wed, 9 Dec 2020 13:30:14 GMT, Magnus Ihse Bursie wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits: >> >> - Merging recent master changes into JDK-8250768 >> - Fixing navigator for the PREVIEW page. >> - Fixing typo. >> - Removing obsolette @PreviewFeature. >> - Merging master into JDK-8250768 >> - Removing unnecessary property keys. >> - Cleanup - removing unnecessary code. >> - Merging master into JDK-8250768-dev4 >> - Reflecting review comments. >> - Removing trailing whitespace. >> - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57 > > Build changes still good. I've merged the PR with the recent mainline, and I'd like to integrate sometime soon. Please let me know if there's any issue with that. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jwilhelm at openjdk.java.net Thu Jan 7 20:45:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 20:45:15 GMT Subject: RFR: Merge jdk16 Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description - 8251200: False positive messages about missing comments for serialization - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days - 8259075: Update the copyright notice in the files generated by CLDR Converter tool - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes - 8258558: Revert changes for JDK-8252505 and related issues - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition - 8259007: This test printed a blank page - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1989/files Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/1989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989 PR: https://git.openjdk.java.net/jdk/pull/1989 From vromero at openjdk.java.net Thu Jan 7 20:54:01 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 7 Jan 2021 20:54:01 GMT Subject: RFR: 8257740: Compiler crash when compiling type annotation on multicatch inside lambda [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 15:24:55 GMT, Guoxiong Li wrote: >> Hi all, >> >> When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data` of the new VarSymbol. Maybe it is because the field `data` is unused in later phase. >> >> Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`. >> >> It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`. >> >> This patch fixes it and adds corresponding test cases. >> In my patch, I only set the field ` data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used. >> >> Thank your for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix multi-catch test case. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 2073: > 2071: // com.sun.tools.javac.jvm.Code.fillLocalVarPosition would use it. > 2072: // See JDK-8257740 for more information. > 2073: if (((VarSymbol) sym).isExceptionParameter()) { another option could be to set the data to all VarSymbols instead of adding a special case for exception parameters. I'm OK with this solution, just that it could be that setting the data value for all VarSymbols could advert similar issues in the future ------------- PR: https://git.openjdk.java.net/jdk/pull/1648 From jwilhelm at openjdk.java.net Thu Jan 7 21:21:57 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 21:21:57 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com> Message-ID: On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 555641ed Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/555641ed Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1989 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 7 21:24:56 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 7 Jan 2021 21:24:56 GMT Subject: RFR: 8257740: Compiler crash when compiling type annotation on multicatch inside lambda [v2] In-Reply-To: <24MlZ9KKGUkrS0mLTtzrNLSBB1V9BQ6DbEtWy78Vs4A=.062f5c8a-1bc1-4570-9537-2e04cad74190@github.com> References: <24MlZ9KKGUkrS0mLTtzrNLSBB1V9BQ6DbEtWy78Vs4A=.062f5c8a-1bc1-4570-9537-2e04cad74190@github.com> Message-ID: On Thu, 7 Jan 2021 19:12:13 GMT, Guoxiong Li wrote: >> looks good to me > > @vicente-romero-oracle Thank you for your review. Could I get your help to sponsor this patch? Thanks again. Because `VarSymbol.data` is private, currently I need to do it as below. // way 1 if (((VarSymbol) sym).isExceptionParameter()) { ((VarSymbol) ret).setData(ElementKind.EXCEPTION_PARAMETER); } if (((VarSymbol) sym).isResourceVariable()) { ((VarSymbol) ret).setData(ElementKind.RESOURCE_VARIABLE); } If we revise `VarSymbol.data` to public, we can do it as below. // way 2 // class VarSymbol public Object data; // Usage ((VarSymbol) ret).data = ((VarSymbol) sym).data; Or we can provide a method to get `VarSymbol.data`, the corresponding code is shown below. // way 3 // class VarSymbol public Object getData() { return this.data; } // Usage ((VarSymbol) ret).setData(((VarSymbol) sym).getData()); In my opinion, way 3 is better. Which way do you think is the best way? ------------- PR: https://git.openjdk.java.net/jdk/pull/1648 From joe.darcy at oracle.com Thu Jan 7 22:48:02 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 7 Jan 2021 14:48:02 -0800 Subject: FYI, JSR 269 maintenance review for changes being made in 16 Message-ID: FYI, usual sorts of changes in the JSR 269 API (javax.annotation.processing and javax.lang.model.*) in 16 up for maintenance review: https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index10.html -Joe From jwilhelm at openjdk.java.net Thu Jan 7 23:56:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 23:56:15 GMT Subject: Integrated: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 - 8039278: console.sh failed Automatically with exit code 1 - 8258972: unexpected compilation error with generic sealed interface - 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check - 8258657: Doc build is broken by use of new language features - 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1994&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1994&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1994/files Stats: 198 lines in 15 files changed: 147 ins; 31 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1994.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1994/head:pull/1994 PR: https://git.openjdk.java.net/jdk/pull/1994 From jwilhelm at openjdk.java.net Thu Jan 7 23:56:17 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 7 Jan 2021 23:56:17 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <6YfMfrA9n62l9LpgHgzPt2twp3wBWzcnD9ZliipfNoE=.153e6add-6f3e-4fe5-948c-d20b4534412f@github.com> On Thu, 7 Jan 2021 23:46:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 56a354eb Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/56a354eb Stats: 198 lines in 15 files changed: 147 ins; 31 del; 20 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1994 From jjg at openjdk.java.net Fri Jan 8 02:01:06 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 8 Jan 2021 02:01:06 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> References: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> Message-ID: On Thu, 7 Jan 2021 20:23:16 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - Fixing tests after a merge. > - Merging master into JDK-8250768 > - Merging recent master changes into JDK-8250768 > - Fixing navigator for the PREVIEW page. > - Fixing typo. > - Removing obsolette @PreviewFeature. > - Merging master into JDK-8250768 > - Removing unnecessary property keys. > - Cleanup - removing unnecessary code. > - Merging master into JDK-8250768-dev4 > - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde I've looked at all the files that were marked as changed since I last looked at them. There's one suggested enhancement to reduce string bashing between `Utils` and `ClassWriterImpl` that could be done now or later. There's a pending conflict with a PR of mine to change to use a new type `HtmlId` for HTML ids. This JEP12 work has been in progress for a while, and so it would be good to get it in before the `HtmlId` work, and I'll deal with the merge conflict in due course. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 194: > 192: > 193: @Override @SuppressWarnings("preview") > 194: public void addClassSignature(String modifiers, Content classInfoTree) { It seems less than ideal for this method to take a `String` and to then have to take it apart and reassemble it. It looks like it should be possible (and conceptually better) to change the signature to `List` and to make the corresponding change to `utils.modifiersToString`, probably renaming it as `utils.modifiersToStrings` or something like that, and dropping the always-`true` argument for `trailingSpace`. But, the code is OK as is, and the suggestion is just for an enhancement, so is OK to defer it, if you would prefer. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 2: > 1: /* > 2: * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved. (minor) now 2021 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 61: > 59: public abstract class SummaryListWriter extends SubWriterHolderWriter { > 60: > 61: private String getAnchorName(SummaryElementKind kind) { Heads-up: at some point this will conflict with another change in progress/review, to introduce a new type `HtmlId` to use instead of `String` for ids. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java line 227: > 225: * @param contentTree the content tree to which the summary table will be added > 226: */ > 227: protected void addSummaryAPI(SortedSet apiList, String id, Heads-up, here's another occurrence of where there will be a conflict for ids. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 154: > 152: doclet.Errors=Errors > 153: doclet.Classes=Classes > 154: doclet.Records=Records I guess I'm mildly surprised to see all these items being removed... src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java line 2: > 1: /* > 2: * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved. Year test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved. 2021. I assume you will do a bulk update for affected files. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703 From jjg at openjdk.java.net Fri Jan 8 04:14:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 8 Jan 2021 04:14:04 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: References: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> Message-ID: On Fri, 8 Jan 2021 01:58:07 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - Fixing tests after a merge. >> - Merging master into JDK-8250768 >> - Merging recent master changes into JDK-8250768 >> - Fixing navigator for the PREVIEW page. >> - Fixing typo. >> - Removing obsolette @PreviewFeature. >> - Merging master into JDK-8250768 >> - Removing unnecessary property keys. >> - Cleanup - removing unnecessary code. >> - Merging master into JDK-8250768-dev4 >> - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde > > I've looked at all the files that were marked as changed since I last looked at them. > > There's one suggested enhancement to reduce string bashing between `Utils` and `ClassWriterImpl` that could be done now or later. > > There's a pending conflict with a PR of mine to change to use a new type `HtmlId` for HTML ids. This JEP12 work has been in progress for a while, and so it would be good to get it in before the `HtmlId` work, and I'll deal with the merge conflict in due course. +1 -- Jon On 1/7/21 12:19 PM, Jan Lahoda wrote: > > I've merged the PR with the recent mainline, and I'd like to integrate > sometime soon. Please let me know if there's any issue with that. Thanks! > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 8 08:17:04 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 8 Jan 2021 08:17:04 GMT Subject: RFR: 8203925: tools/javac/importscope/T8193717.java ran out of java heap Message-ID: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com> Hi all, Because [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) modified `T8193717.java`, changing `private static final int CLASSES = 500000;` to `private static final int CLASSES = 50000;`(500K -> 50K). The error, `out of java heap`, no longer occurs now. And the pre-submit tests of this patch passed. I think `tools/javac/importscope/T8193717.java` could be removed from `ProblemList.txt`. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8203925: tools/javac/importscope/T8193717.java ran out of java heap Changes: https://git.openjdk.java.net/jdk/pull/1998/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1998&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203925 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1998.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1998/head:pull/1998 PR: https://git.openjdk.java.net/jdk/pull/1998 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 8 13:38:03 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 8 Jan 2021 13:38:03 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window Message-ID: Hi all, The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below. @Override @DefinedBy(Api.COMPILER) public String getName() { return relativePath.resolveAgainst(userPackageRootDir).toString(); // <----------------- } And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException { String sep = directory.getFileSystem().getSeparator(); // <--------------------- return directory.resolve(path.replace("/", sep)); } We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected. This patch fixes the test by using the file system separator instead of operating system separator. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - Modify copyright - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window Changes: https://git.openjdk.java.net/jdk/pull/2004/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2004&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231179 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2004.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2004/head:pull/2004 PR: https://git.openjdk.java.net/jdk/pull/2004 From vromero at openjdk.java.net Fri Jan 8 13:58:54 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 8 Jan 2021 13:58:54 GMT Subject: RFR: 8257740: Compiler crash when compiling type annotation on multicatch inside lambda [v2] In-Reply-To: References: <24MlZ9KKGUkrS0mLTtzrNLSBB1V9BQ6DbEtWy78Vs4A=.062f5c8a-1bc1-4570-9537-2e04cad74190@github.com> Message-ID: On Thu, 7 Jan 2021 21:21:47 GMT, Guoxiong Li wrote: > Because `VarSymbol.data` is private, currently I need to do it as below. > > ``` > // way 1 > if (((VarSymbol) sym).isExceptionParameter()) { > ((VarSymbol) ret).setData(ElementKind.EXCEPTION_PARAMETER); > } > if (((VarSymbol) sym).isResourceVariable()) { > ((VarSymbol) ret).setData(ElementKind.RESOURCE_VARIABLE); > } > ``` > > If we revise `VarSymbol.data` to public, we can do it as below. > > ``` > // way 2 > // class VarSymbol > public Object data; > > // Usage > ((VarSymbol) ret).data = ((VarSymbol) sym).data; > ``` > > Or we can provide a method to get `VarSymbol.data`, the corresponding code is shown below. > > ``` > // way 3 > // class VarSymbol > public Object getData() { > return this.data; > } > > // Usage > ((VarSymbol) ret).setData(((VarSymbol) sym).getData()); > ``` > > In my opinion, way 3 is better. Which way do you think is the best way? NVM, what you already did is the best way for now, we prefer to keep the `data` field private, sorry for the noise and thanks again for the good job ------------- PR: https://git.openjdk.java.net/jdk/pull/1648 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 8 13:58:57 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 8 Jan 2021 13:58:57 GMT Subject: Integrated: 8257740: Compiler crash when compiling type annotation on multicatch inside lambda In-Reply-To: References: Message-ID: <5tvlTHeovh6UIpRP4NMBxq4R4RPmg-ni4T6IgE7z3M0=.5c45340b-aea4-4b7e-ac32-46c204350599@github.com> On Sun, 6 Dec 2020 08:17:29 GMT, Guoxiong Li wrote: > Hi all, > > When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data` of the new VarSymbol. Maybe it is because the field `data` is unused in later phase. > > Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`. > > It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`. > > This patch fixes it and adds corresponding test cases. > In my patch, I only set the field ` data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used. > > Thank your for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: 697bf7ab Author: Guoxiong Li Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/697bf7ab Stats: 106 lines in 3 files changed: 106 ins; 0 del; 0 mod 8257740: Compiler crash when compiling type annotation on multicatch inside lambda Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/1648 From jlahoda at openjdk.java.net Fri Jan 8 15:26:04 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 8 Jan 2021 15:26:04 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v13] In-Reply-To: References: <1Hv0w0gv07ik40DRi5JBB-G6opt0v3HjdbJc8Y-8kXs=.756df108-047c-414b-9e34-ca73ade932a4@github.com> Message-ID: On Fri, 8 Jan 2021 01:51:52 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - Fixing tests after a merge. >> - Merging master into JDK-8250768 >> - Merging recent master changes into JDK-8250768 >> - Fixing navigator for the PREVIEW page. >> - Fixing typo. >> - Removing obsolette @PreviewFeature. >> - Merging master into JDK-8250768 >> - Removing unnecessary property keys. >> - Cleanup - removing unnecessary code. >> - Merging master into JDK-8250768-dev4 >> - ... and 47 more: https://git.openjdk.java.net/jdk/compare/81c06242...a8046dde > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 154: > >> 152: doclet.Errors=Errors >> 153: doclet.Classes=Classes >> 154: doclet.Records=Records > > I guess I'm mildly surprised to see all these items being removed... These were used from DeprecatedListWriter.getSummaryKey which is removed by this patch (and is unused in the current mainline, as far as I know). ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Fri Jan 8 15:29:22 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 8 Jan 2021 15:29:22 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v14] In-Reply-To: References: Message-ID: <5yqRThkGhxW8tDtwfkBzOB8k6-CoWkengMWAgeGogr0=.fa0c0a28-abe8-47bb-86f8-cd18b1ed3aa0@github.com> > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updating copyright years. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/703/files - new: https://git.openjdk.java.net/jdk/pull/703/files/a8046dde..56371c47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=12-13 Stats: 103 lines in 103 files changed: 0 ins; 0 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Fri Jan 8 17:22:19 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 8 Jan 2021 17:22:19 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v15] In-Reply-To: References: Message-ID: <1l2ZGdCLlmLZ_hbqsEG0AnTrX7pob7FJ_kJ73_qLLu8=.a116a4b4-229e-41dc-ba22-d72f139ce2dd@github.com> > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits: - Merging master into JDK-8250768 - Updating copyright years. - Fixing tests after a merge. - Merging master into JDK-8250768 - Merging recent master changes into JDK-8250768 - Fixing navigator for the PREVIEW page. - Fixing typo. - Removing obsolette @PreviewFeature. - Merging master into JDK-8250768 - Removing unnecessary property keys. - ... and 49 more: https://git.openjdk.java.net/jdk/compare/090bd3af...4f654955 ------------- Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=14 Stats: 3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From darcy at openjdk.java.net Fri Jan 8 22:40:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 8 Jan 2021 22:40:03 GMT Subject: RFR: 8259512: Update --release 16 symbol information for JDK 16 build 31 Message-ID: Using the symbol updating script, update the symbol files for API changes in JDK 16 build 31. ------------- Commit messages: - 8259512: Update --release 16 symbol information for JDK 16 build 31 Changes: https://git.openjdk.java.net/jdk/pull/2010/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2010&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259512 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2010.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2010/head:pull/2010 PR: https://git.openjdk.java.net/jdk/pull/2010 From jjg at openjdk.java.net Fri Jan 8 23:56:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 8 Jan 2021 23:56:55 GMT Subject: RFR: 8259512: Update --release 16 symbol information for JDK 16 build 31 In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 22:36:01 GMT, Joe Darcy wrote: > Using the symbol updating script, update the symbol files for API changes in JDK 16 build 31. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2010 From darcy at openjdk.java.net Sat Jan 9 00:06:55 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 9 Jan 2021 00:06:55 GMT Subject: Integrated: 8259512: Update --release 16 symbol information for JDK 16 build 31 In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 22:36:01 GMT, Joe Darcy wrote: > Using the symbol updating script, update the symbol files for API changes in JDK 16 build 31. This pull request has now been integrated. Changeset: a6539282 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/a6539282 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8259512: Update --release 16 symbol information for JDK 16 build 31 Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/2010 From attila at openjdk.java.net Sun Jan 10 20:06:59 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 10 Jan 2021 20:06:59 GMT Subject: RFR: 8259025: Record compact constructor using Objects.requireNonNull In-Reply-To: References: Message-ID: On Sat, 2 Jan 2021 12:32:05 GMT, Guoxiong Li wrote: > Hi all, > > Currently, the method `Attr::lambdaEnv` doesn't set the `lambdaEnv.info.isLambda` to `true` and lets the caller set it. But not all the callers remember to set it. In this bug, `DefferredAttr::attribSpeculativeLambda` uses `Attr::lambdaEnv` and doesn't set `lambdaEnv.info.isLambda` to `true`. So when `Attr::visitReturn` uses `!env.info.isLambda` to judge if it is in the lambda environment, it gets the wrong information and generates an error message. > > This patch moves `lambdaEnv.info.isLambda = true;` into `Attr::lambdaEnv` to solve the problem and adds a corresponding test case. Thank you for taking the time to review. > > Best Regards. Looks good, thanks for fixing this! ------------- Marked as reviewed by attila (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1917 From github.com+13688759+lgxbslgx at openjdk.java.net Mon Jan 11 07:22:08 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Jan 2021 07:22:08 GMT Subject: RFR: 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash Message-ID: Hi all, Currently, javac doesn't attribute unexpected super constructor invocation qualifier. Please see the following code. public class SuperConstructorCallInErrorClass extends Undefined1 { public SuperConstructorCallInErrorClass(int i) { new Undefined2() { public void test(int i) { Undefined3 u; } }.super(); //<------------------- } } The code `new Undefined2() { public void test(int i) { Undefined3 u; } }` isn't attributed by javac. If we use options like `-XDshould-stop.at=FLOW -XDdev`, the compiler would crash. This patch fixes it and adds the corresponding test cases. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash Changes: https://git.openjdk.java.net/jdk/pull/2021/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2021&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259359 Stats: 104 lines in 2 files changed: 103 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2021.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2021/head:pull/2021 PR: https://git.openjdk.java.net/jdk/pull/2021 From ihse at openjdk.java.net Mon Jan 11 09:23:11 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 11 Jan 2021 09:23:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: Message-ID: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - Step 2: Update references >> - First stage, move actual data files > > Marked as reviewed by prr (Reviewer). This PR is not stale; it's just still waiting for input from @AlanBateman. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlahoda at openjdk.java.net Mon Jan 11 10:15:06 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 11 Jan 2021 10:15:06 GMT Subject: Integrated: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 This pull request has now been integrated. Changeset: 23548821 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/23548821 Stats: 3802 lines in 133 files changed: 2724 ins; 695 del; 383 mod 8250768: javac should be adapted to changes in JEP 12 Reviewed-by: mcimadamore, erikj, jjg, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From github.com+13688759+lgxbslgx at openjdk.java.net Mon Jan 11 13:53:59 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Mon, 11 Jan 2021 13:53:59 GMT Subject: Integrated: 8259025: Record compact constructor using Objects.requireNonNull In-Reply-To: References: Message-ID: On Sat, 2 Jan 2021 12:32:05 GMT, Guoxiong Li wrote: > Hi all, > > Currently, the method `Attr::lambdaEnv` doesn't set the `lambdaEnv.info.isLambda` to `true` and lets the caller set it. But not all the callers remember to set it. In this bug, `DefferredAttr::attribSpeculativeLambda` uses `Attr::lambdaEnv` and doesn't set `lambdaEnv.info.isLambda` to `true`. So when `Attr::visitReturn` uses `!env.info.isLambda` to judge if it is in the lambda environment, it gets the wrong information and generates an error message. > > This patch moves `lambdaEnv.info.isLambda = true;` into `Attr::lambdaEnv` to solve the problem and adds a corresponding test case. Thank you for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: 33fbc10c Author: Guoxiong Li Committer: Attila Szegedi URL: https://git.openjdk.java.net/jdk/commit/33fbc10c Stats: 14 lines in 2 files changed: 11 ins; 1 del; 2 mod 8259025: Record compact constructor using Objects.requireNonNull Reviewed-by: attila ------------- PR: https://git.openjdk.java.net/jdk/pull/1917 From hannesw at openjdk.java.net Mon Jan 11 15:06:02 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 11 Jan 2021 15:06:02 GMT Subject: [jdk16] RFR: JDK-8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing In-Reply-To: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> References: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> Message-ID: On Wed, 23 Dec 2020 00:01:11 GMT, Jonathan Gibbons wrote: > This PR improves the diagnostic when javac is run in an image that does not provide a service provider for DocLint. > > Instead of reporting messages about unsupported options, the following warning will be generated: > > ` > Warning: No service provider for doclint is available > ` > > In addition, as a minor cleanup, in the `jdk.javadoc` module, javadoc b bypasses the service loader to access `doclint` directly. Looks good! test/langtools/tools/javac/doclint/LimitedImage.java line 58: > 56: List actualOutput; > 57: List expectedOutput = List.of( > 58: "- compiler.warn.doclint.not.available", Why is the warning key printed instead of the warning message? Limited image breaks property lookup? test/langtools/tools/javac/doclint/LimitedImage.java line 62: > 60: ); > 61: > 62: //check proper diagnostics when zip/jar FS not present: Should be "doclint" or "javadoc" instead of "zip/jar FS" ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/60 From jjg at openjdk.java.net Mon Jan 11 16:47:59 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 11 Jan 2021 16:47:59 GMT Subject: [jdk16] RFR: JDK-8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing In-Reply-To: References: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> Message-ID: <5TiekMpkTCn2MxKgEZCzRzfBEgG7pz_ClLZpBLyb9yk=.d20caafc-7376-4469-b0de-dde0a5a62ad1@github.com> On Mon, 11 Jan 2021 14:58:29 GMT, Hannes Walln?fer wrote: >> This PR improves the diagnostic when javac is run in an image that does not provide a service provider for DocLint. >> >> Instead of reporting messages about unsupported options, the following warning will be generated: >> >> ` >> Warning: No service provider for doclint is available >> ` >> >> In addition, as a minor cleanup, in the `jdk.javadoc` module, javadoc b bypasses the service loader to access `doclint` directly. > > test/langtools/tools/javac/doclint/LimitedImage.java line 58: > >> 56: List actualOutput; >> 57: List expectedOutput = List.of( >> 58: "- compiler.warn.doclint.not.available", > > Why is the warning key printed instead of the warning message? Limited image breaks property lookup? It is common practice in jdk.compiler tests to use `-XDrawDiagnostics` which disables the use of resource files. The reason is to isolate the tests from the locale in which they may be executed, and from minor changes in the resources in the resource files, like spelling and grammar fixes, etc. ------------- PR: https://git.openjdk.java.net/jdk16/pull/60 From jjg at openjdk.java.net Mon Jan 11 16:53:00 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 11 Jan 2021 16:53:00 GMT Subject: [jdk16] RFR: JDK-8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing In-Reply-To: References: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> Message-ID: On Mon, 11 Jan 2021 15:02:31 GMT, Hannes Walln?fer wrote: >> This PR improves the diagnostic when javac is run in an image that does not provide a service provider for DocLint. >> >> Instead of reporting messages about unsupported options, the following warning will be generated: >> >> ` >> Warning: No service provider for doclint is available >> ` >> >> In addition, as a minor cleanup, in the `jdk.javadoc` module, javadoc b bypasses the service loader to access `doclint` directly. > > test/langtools/tools/javac/doclint/LimitedImage.java line 62: > >> 60: ); >> 61: >> 62: //check proper diagnostics when zip/jar FS not present: > > Should be "doclint" or "javadoc" instead of "zip/jar FS" I had to double check, but yes; thanks: good catch ------------- PR: https://git.openjdk.java.net/jdk16/pull/60 From jjg at openjdk.java.net Mon Jan 11 17:39:22 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 11 Jan 2021 17:39:22 GMT Subject: [jdk16] Integrated: JDK-8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing In-Reply-To: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> References: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> Message-ID: On Wed, 23 Dec 2020 00:01:11 GMT, Jonathan Gibbons wrote: > This PR improves the diagnostic when javac is run in an image that does not provide a service provider for DocLint. > > Instead of reporting messages about unsupported options, the following warning will be generated: > > ` > Warning: No service provider for doclint is available > ` > > In addition, as a minor cleanup, in the `jdk.javadoc` module, javadoc b bypasses the service loader to access `doclint` directly. This pull request has now been integrated. Changeset: 2cb271e6 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk16/commit/2cb271e6 Stats: 96 lines in 6 files changed: 88 ins; 1 del; 7 mod 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk16/pull/60 From jjg at openjdk.java.net Mon Jan 11 17:39:20 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 11 Jan 2021 17:39:20 GMT Subject: [jdk16] RFR: JDK-8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing [v2] In-Reply-To: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> References: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com> Message-ID: > This PR improves the diagnostic when javac is run in an image that does not provide a service provider for DocLint. > > Instead of reporting messages about unsupported options, the following warning will be generated: > > ` > Warning: No service provider for doclint is available > ` > > In addition, as a minor cleanup, in the `jdk.javadoc` module, javadoc b bypasses the service loader to access `doclint` directly. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fix comment - Merge remote-tracking branch 'upstream/master' into doclint.missing - JDK-8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/60/files - new: https://git.openjdk.java.net/jdk16/pull/60/files/f9aacd5c..595d31d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=60&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=60&range=00-01 Stats: 3646 lines in 117 files changed: 1146 ins; 2369 del; 131 mod Patch: https://git.openjdk.java.net/jdk16/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/60/head:pull/60 PR: https://git.openjdk.java.net/jdk16/pull/60 From jwilhelm at openjdk.java.net Mon Jan 11 22:10:14 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 11 Jan 2021 22:10:14 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing - 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl - 8259043: More Zero architectures need linkage with libatomic - 8259429: Update reference to README.md - 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win) The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2040/files Stats: 140 lines in 12 files changed: 117 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040 From jwilhelm at openjdk.java.net Tue Jan 12 00:59:20 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 12 Jan 2021 00:59:20 GMT Subject: RFR: Merge jdk16 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 16 -> JDK 17 Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Merge ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2040/files - new: https://git.openjdk.java.net/jdk/pull/2040/files/e55da33b..69dad8ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2040&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2040/head:pull/2040 PR: https://git.openjdk.java.net/jdk/pull/2040 From jwilhelm at openjdk.java.net Tue Jan 12 01:10:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 12 Jan 2021 01:10:59 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 22:04:16 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: b378f54d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/b378f54d Stats: 139 lines in 12 files changed: 116 ins; 2 del; 21 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2040 From vromero at openjdk.java.net Tue Jan 12 02:26:09 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 12 Jan 2021 02:26:09 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference Message-ID: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> This patch fixes the following issue, for code like: import java.util.function.*; public class Test { public String foo(Object o) { return "foo"; } public static String foo(String o) { return "bar"; } public void test() { Function f = Test::foo; } } javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: If the first search produces a most specific method that is static , and the set of applicable methods produced by the second search contains no non- static methods, then the compile-time declaration is the most specified method of the first search. Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. TIA ------------- Commit messages: - adding diagnostics tests - updating test - renaming test file - Merge branch 'master' into JDK-8231461 - Merge branch 'master' into JDK-8231461 - 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference Changes: https://git.openjdk.java.net/jdk16/pull/107/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=107&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231461 Stats: 300 lines in 8 files changed: 297 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/107.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/107/head:pull/107 PR: https://git.openjdk.java.net/jdk16/pull/107 From hchao at openjdk.java.net Tue Jan 12 03:39:22 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 12 Jan 2021 03:39:22 GMT Subject: RFR: 8259401: Add checking to jarsigner to warn weak algorithms used in =?UTF-8?B?c2nigKY=?= Message-ID: <65jfEfTSe5KTneSldz4rWNaQXy0dELDPLxmYck6pVHA=.cbc7f29c-5600-486d-ab70-42d92f4d9dce@github.com> The jarsigner tool currently provides warning associated with the signer?s cert when it uses weak algorithms, but not for the CA certs. This change is to process the signer?s cert chain to warn if CA certs use weak algorithms. ------------- Commit messages: - 8259401: Add checking to jarsigner to warn weak algorithms used in signer?s cert chain Changes: https://git.openjdk.java.net/jdk/pull/2042/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2042&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259401 Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2042/head:pull/2042 PR: https://git.openjdk.java.net/jdk/pull/2042 From sirinath1978m at gmail.com Tue Jan 12 06:20:44 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Tue, 12 Jan 2021 11:50:44 +0530 Subject: Compile Time Extraction of Line and Column Numbers, Class Name, Method Names as Opposed to Stack Walking Message-ID: Hello, With all the up coming changes in Java is it possible to give a way to extract static meta data in a program for logging like line numbers, method details, class name, etc. without resorting to stack walking. Also stack walking can be optimised to be more efficient. Suminda -------------- next part -------------- An HTML attachment was scrubbed... URL: From sirinath1978m at gmail.com Tue Jan 12 06:27:03 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Tue, 12 Jan 2021 11:57:03 +0530 Subject: Compile Time Evaluation: constexpr for Java Message-ID: Hello, Since the const keyword is not used in Java can this be operposed for compile time evaluation? Classes, interfaces, methods, fields marked with const will only be available at compile time and would be fully evaluated and replaced with the results in runtime bytecode. Suminda -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jan 12 08:24:35 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Jan 2021 09:24:35 +0100 (CET) Subject: Compile Time Extraction of Line and Column Numbers, Class Name, Method Names as Opposed to Stack Walking In-Reply-To: References: Message-ID: <1210009495.1232080.1610439875798.JavaMail.zimbra@u-pem.fr> > De: "Suminda Sirinath Salpitikorala Dharmasena" > ?: "compiler-dev" > Envoy?: Mardi 12 Janvier 2021 07:20:44 > Objet: Compile Time Extraction of Line and Column Numbers, Class Name, Method > Names as Opposed to Stack Walking > Hello, Hello > With all the up coming changes in Java is it possible to give a way to extract > static meta data in a program for logging like line numbers, method details, > class name, etc. without resorting to stack walking. > Also stack walking can be optimised to be more efficient. StackWalker is not that bad, especially if you call it once. Here is an example of how to extract all the stack information efficiently, by calling the StackWalker only once and caching the result. public class MetaDataTest { private static final MetaData META_DATA = MetaData.create(StackWalker.getInstance(), frames -> frames.findFirst().orElseThrow()); @Test public void create() { System.out.println(META_DATA.get()); // it's a constant for the JIT ! } } > Suminda regards, R?mi --- import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.lang.invoke.MutableCallSite; import java.lang.reflect.UndeclaredThrowableException; import java.util.Objects; import java.util.function.Function; import java.util.function.Supplier; import java.util.stream.Stream; @FunctionalInterface public interface MetaData { T get(); @SuppressWarnings("unchecked") static MetaData create(StackWalker stackWalker, Function, ? extends T> fun) { Objects.requireNonNull(stackWalker); Objects.requireNonNull(fun); var target = createMH(() -> stackWalker.walk(fun.compose(frames -> frames.skip(3)))); return () -> { try { return (T) target.invokeExact(); } catch (RuntimeException | Error e) { throw e; } catch(Throwable t) { throw new UndeclaredThrowableException(t); } }; } private static MethodHandle createMH(Supplier supplier) { return new MostlyConstant(supplier).dynamicInvoker(); } /*private*/ final class MostlyConstant extends MutableCallSite { private final Supplier supplier; private MostlyConstant(Supplier supplier) { super(MethodType.methodType(Object.class)); this.supplier = supplier; setTarget(FALLBACK.bindTo(this)); } private Object fallback() { var value = supplier.get(); setTarget(MethodHandles.constant(Object.class, value)); return value; } static final MethodHandle FALLBACK; static { var lookup = MethodHandles.lookup(); try { FALLBACK = lookup.findVirtual(MostlyConstant.class, "fallback", MethodType.methodType(Object.class)); } catch (NoSuchMethodException | IllegalAccessException e) { throw new AssertionError(e); } } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jan 12 08:35:04 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Jan 2021 09:35:04 +0100 (CET) Subject: Compile Time Evaluation: constexpr for Java In-Reply-To: References: Message-ID: <948082325.1242262.1610440504376.JavaMail.zimbra@u-pem.fr> > De: "Suminda Sirinath Salpitikorala Dharmasena" > ?: "compiler-dev" > Envoy?: Mardi 12 Janvier 2021 07:27:03 > Objet: Compile Time Evaluation: constexpr for Java > Hello, > Since the const keyword is not used in Java can this be operposed for compile > time evaluation? Classes, interfaces, methods, fields marked with const will > only be available at compile time and would be fully evaluated and replaced > with the results in runtime bytecode. Java and the JVM already has several kind of constants, you have the constant for the compiler, but you have also the constant for the interpreter and the constant for the JIT. Because you have separate compilation of classes in Java, compile time constants are not used a lot. We tend to use static final field which are constant for the JIT (or the compiler if it's a primitive or a String). If you want more exotic kind of constants, you can build a constant method handle tree (see the package java.lang.invoke) that let you define whatever you want as constant (see my answer to your other mail). The JVM has another kind of constants, constantdynamic, which are constant for the interpreter (and the JITs) but currently there is no way to express such kind of constants in Java. see https://bugs.openjdk.java.net/browse/JDK-8209964 > Suminda regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.java.net Tue Jan 12 10:37:56 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Jan 2021 10:37:56 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference In-Reply-To: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> Message-ID: <53a3ULCgag_4BYSDnIlFKUijT2y2ScaTfp4oLz_c98I=.fd7046d8-816b-4508-85b1-daa69bc255b8@github.com> On Tue, 12 Jan 2021 02:21:31 GMT, Vicente Romero wrote: > This patch fixes the following issue, for code like: > import java.util.function.*; > > public class Test { > public String foo(Object o) { return "foo"; } > public static String foo(String o) { return "bar"; } > > public void test() { > Function f = Test::foo; > } > } > javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: > > If the first search produces a most specific method that is static , and the set > of applicable methods produced by the second search contains no non- static > methods, then the compile-time declaration is the most specified method of > the first search. > > Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. > > TIA The debugging logic seems good, but I don't get how the fix is supposed to work, since it seems to replicate the behavior that's already there. I'm probably missing something. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3327: > 3325: @Override > 3326: ReferenceLookupResult unboundResult(ReferenceLookupResult boundRes, ReferenceLookupResult unboundRes) { > 3327: if (boundRes.isSuccess() && boundRes.sym.isStatic() && For consistency here I'd prefer to see `boundRes.hasKind(StaticKind.STATIC)` (which is set if the underlying symbol is static). E.g. I think the fix here is really adding the `isSuccess` part, not changing the static check. ------------- PR: https://git.openjdk.java.net/jdk16/pull/107 From mcimadamore at openjdk.java.net Tue Jan 12 10:37:57 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Jan 2021 10:37:57 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference In-Reply-To: <53a3ULCgag_4BYSDnIlFKUijT2y2ScaTfp4oLz_c98I=.fd7046d8-816b-4508-85b1-daa69bc255b8@github.com> References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> <53a3ULCgag_4BYSDnIlFKUijT2y2ScaTfp4oLz_c98I=.fd7046d8-816b-4508-85b1-daa69bc255b8@github.com> Message-ID: On Tue, 12 Jan 2021 10:24:50 GMT, Maurizio Cimadamore wrote: >> This patch fixes the following issue, for code like: >> import java.util.function.*; >> >> public class Test { >> public String foo(Object o) { return "foo"; } >> public static String foo(String o) { return "bar"; } >> >> public void test() { >> Function f = Test::foo; >> } >> } >> javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: >> >> If the first search produces a most specific method that is static , and the set >> of applicable methods produced by the second search contains no non- static >> methods, then the compile-time declaration is the most specified method of >> the first search. >> >> Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. >> >> TIA > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3327: > >> 3325: @Override >> 3326: ReferenceLookupResult unboundResult(ReferenceLookupResult boundRes, ReferenceLookupResult unboundRes) { >> 3327: if (boundRes.isSuccess() && boundRes.sym.isStatic() && > > For consistency here I'd prefer to see `boundRes.hasKind(StaticKind.STATIC)` (which is set if the underlying symbol is static). E.g. I think the fix here is really adding the `isSuccess` part, not changing the static check. That said - I'm having issue understanding how this has been fixed: if the fix search succeeds and the second search fails to produce a non-static method, then the first search should be preferred. It seems to me that the old code already covers that? Note that `isSuccess` is true whenever the kind != UNDEFINED, so if we check that kind should be STATIC, we already check that is a successful lookup and that the result is static. In other words, I don't see how the new code is different from the old? ------------- PR: https://git.openjdk.java.net/jdk16/pull/107 From vromero at openjdk.java.net Tue Jan 12 16:42:00 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 12 Jan 2021 16:42:00 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference In-Reply-To: References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> <53a3ULCgag_4BYSDnIlFKUijT2y2ScaTfp4oLz_c98I=.fd7046d8-816b-4508-85b1-daa69bc255b8@github.com> Message-ID: <-IybCFnWsNhVnnd3fz3M-8PnhiEB69STXHlhnNtIpJI=.2285668c-53a3-41f8-a9ed-98d917d1b399@github.com> On Tue, 12 Jan 2021 10:34:34 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3327: >> >>> 3325: @Override >>> 3326: ReferenceLookupResult unboundResult(ReferenceLookupResult boundRes, ReferenceLookupResult unboundRes) { >>> 3327: if (boundRes.isSuccess() && boundRes.sym.isStatic() && >> >> For consistency here I'd prefer to see `boundRes.hasKind(StaticKind.STATIC)` (which is set if the underlying symbol is static). E.g. I think the fix here is really adding the `isSuccess` part, not changing the static check. > > That said - I'm having issue understanding how this has been fixed: if the fix search succeeds and the second search fails to produce a non-static method, then the first search should be preferred. It seems to me that the old code already covers that? Note that `isSuccess` is true whenever the kind != UNDEFINED, so if we check that kind should be STATIC, we already check that is a successful lookup and that the result is static. In other words, I don't see how the new code is different from the old? I guess that the difference between the new code and the previous one was that in the old code when we check if `boundRes.hasKind(StaticKind.STATIC)` we are checking for a global property of all candidates, meaning that for the previous check to be true, all candidates have to be static. And this is not what the spec is saying, as the spec cares about the staticness, or lack of it, of the most specific method found in each search. Does this make sense? ------------- PR: https://git.openjdk.java.net/jdk16/pull/107 From jlahoda at openjdk.java.net Tue Jan 12 16:47:57 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 12 Jan 2021 16:47:57 GMT Subject: Withdrawn: 8256266: Binding variables don't correct support declaration annotations and the final modifier In-Reply-To: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com> References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com> Message-ID: On Thu, 12 Nov 2020 16:47:48 GMT, Jan Lahoda wrote: > Basically, javac does not handle code like this properly: > > import java.lang.annotation.*; > > public class B { > public void test(Object o) { > if (o instanceof @A String s) {} > } > } > > @Target(ElementType.LOCAL_VARIABLE) > @interface A {} > > The parser needs to allow declaration annotations on binding variables, see: > http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1192 From mcimadamore at openjdk.java.net Tue Jan 12 19:03:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Jan 2021 19:03:03 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference In-Reply-To: <-IybCFnWsNhVnnd3fz3M-8PnhiEB69STXHlhnNtIpJI=.2285668c-53a3-41f8-a9ed-98d917d1b399@github.com> References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> <53a3ULCgag_4BYSDnIlFKUijT2y2ScaTfp4oLz_c98I=.fd7046d8-816b-4508-85b1-daa69bc255b8@github.com> <-IybCFnWsNhVnnd3fz3M-8PnhiEB69STXHlhnNtIpJI=.2285668c-53a3-41f8-a9ed-98d917d1b399@github.com> Message-ID: On Tue, 12 Jan 2021 16:39:11 GMT, Vicente Romero wrote: >> That said - I'm having issue understanding how this has been fixed: if the fix search succeeds and the second search fails to produce a non-static method, then the first search should be preferred. It seems to me that the old code already covers that? Note that `isSuccess` is true whenever the kind != UNDEFINED, so if we check that kind should be STATIC, we already check that is a successful lookup and that the result is static. In other words, I don't see how the new code is different from the old? > > I guess that the difference between the new code and the previous one is that in the old code when we check if `boundRes.hasKind(StaticKind.STATIC)` we are checking for a global property of all candidates, meaning that for the previous check to be true, all candidates have to be static. And this is not what the spec is saying, as the spec cares about the staticness, or lack of it, of the most specific method found in each search. Does this make sense? Ok - I missed that both symbols are applicable in the first search. So while the most specific symbol is the static one, the StaticKind is set to BOTH, since one is static and the other is not. So, yes, using StaticKind for things like "the first/second search returned a static/non-static method" is incorrect. Your patch fixes that. I'm dubious as to whether isSuccess is correct though. E.g. isSuccess returns true whenever the StaticKind is != UNDEFINED - but that would also return true in cases where there's an ambiguity in the first search - which I would not describe as a success. Do you agree? If so, can we add a test for that case (e.g. a case where the first search has ambiguous result) and see what happens? ------------- PR: https://git.openjdk.java.net/jdk16/pull/107 From jjg at openjdk.java.net Tue Jan 12 19:54:06 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 12 Jan 2021 19:54:06 GMT Subject: [jdk16] RFR: JDK-8259645: Revert "8245956: JavaCompiler still uses File API instead of Path API in a specific case" Message-ID: This reverts commit 46c9a860b6516c119f11edee2deb3d9f62907323. The fix for 8245956 exposed a bug in the underlying URL API, regarding the encoding of non-ASCII characters in filenames. The fix is reverted until the underlying problem can be addressed. ------------- Commit messages: - Revert "8245956: JavaCompiler still uses File API instead of Path API in a specific case" Changes: https://git.openjdk.java.net/jdk16/pull/112/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=112&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259645 Stats: 71 lines in 2 files changed: 0 ins; 67 del; 4 mod Patch: https://git.openjdk.java.net/jdk16/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/112/head:pull/112 PR: https://git.openjdk.java.net/jdk16/pull/112 From chegar at openjdk.java.net Tue Jan 12 19:54:06 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 12 Jan 2021 19:54:06 GMT Subject: [jdk16] RFR: JDK-8259645: Revert "8245956: JavaCompiler still uses File API instead of Path API in a specific case" In-Reply-To: References: Message-ID: <-rlWNSRzXN5P-tj8Xe9EDo51SWI3okYoYvCy5rc1W2Q=.d9f01bb0-fc14-4ecd-9dbf-df34c61add10@github.com> On Tue, 12 Jan 2021 19:46:07 GMT, Jonathan Gibbons wrote: > This reverts commit 46c9a860b6516c119f11edee2deb3d9f62907323. > > The fix for 8245956 exposed a bug in the underlying URL API, regarding the encoding of non-ASCII characters in filenames. > The fix is reverted until the underlying problem can be addressed. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/112 From jjg at openjdk.java.net Tue Jan 12 19:59:59 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 12 Jan 2021 19:59:59 GMT Subject: [jdk16] Integrated: JDK-8259645: Revert JDK-8245956 JavaCompiler still uses File API instead of Path API in a specific case In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 19:46:07 GMT, Jonathan Gibbons wrote: > This reverts commit 46c9a860b6516c119f11edee2deb3d9f62907323. > > The fix for 8245956 exposed a bug in the underlying URL API, regarding the encoding of non-ASCII characters in filenames. > The fix is reverted until the underlying problem can be addressed. This pull request has now been integrated. Changeset: 5f9cd72c Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk16/commit/5f9cd72c Stats: 71 lines in 2 files changed: 0 ins; 67 del; 4 mod 8259645: Revert JDK-8245956 JavaCompiler still uses File API instead of Path API in a specific case Reviewed-by: chegar ------------- PR: https://git.openjdk.java.net/jdk16/pull/112 From vromero at openjdk.java.net Tue Jan 12 20:32:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 12 Jan 2021 20:32:23 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference [v2] In-Reply-To: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> Message-ID: > This patch fixes the following issue, for code like: > import java.util.function.*; > > public class Test { > public String foo(Object o) { return "foo"; } > public static String foo(String o) { return "bar"; } > > public void test() { > Function f = Test::foo; > } > } > javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: > > If the first search produces a most specific method that is static , and the set > of applicable methods produced by the second search contains no non- static > methods, then the compile-time declaration is the most specified method of > the first search. > > Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/107/files - new: https://git.openjdk.java.net/jdk16/pull/107/files/de508c1a..51a5b194 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=107&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=107&range=00-01 Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/107.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/107/head:pull/107 PR: https://git.openjdk.java.net/jdk16/pull/107 From vromero at openjdk.java.net Tue Jan 12 20:32:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 12 Jan 2021 20:32:23 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference [v2] In-Reply-To: References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> <53a3ULCgag_4BYSDnIlFKUijT2y2ScaTfp4oLz_c98I=.fd7046d8-816b-4508-85b1-daa69bc255b8@github.com> <-IybCFnWsNhVnnd3fz3M-8PnhiEB69STXHlhnNtIpJI=.2285668c-53a3-41f8-a9ed-98d917d1b399@github.com> Message-ID: On Tue, 12 Jan 2021 19:00:29 GMT, Maurizio Cimadamore wrote: >> I guess that the difference between the new code and the previous one is that in the old code when we check if `boundRes.hasKind(StaticKind.STATIC)` we are checking for a global property of all candidates, meaning that for the previous check to be true, all candidates have to be static. And this is not what the spec is saying, as the spec cares about the staticness, or lack of it, of the most specific method found in each search. Does this make sense? > > Ok - I missed that both symbols are applicable in the first search. So while the most specific symbol is the static one, the StaticKind is set to BOTH, since one is static and the other is not. So, yes, using StaticKind for things like "the first/second search returned a static/non-static method" is incorrect. Your patch fixes that. > > I'm dubious as to whether isSuccess is correct though. E.g. isSuccess returns true whenever the StaticKind is != UNDEFINED - but that would also return true in cases where there's an ambiguity in the first search - which I would not describe as a success. Do you agree? If so, can we add a test for that case (e.g. a case where the first search has ambiguous result) and see what happens? I have uploaded a new commit based on your comments and offline discussion, TIA ------------- PR: https://git.openjdk.java.net/jdk16/pull/107 From mcimadamore at openjdk.java.net Tue Jan 12 21:59:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Jan 2021 21:59:10 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference [v2] In-Reply-To: References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> Message-ID: On Tue, 12 Jan 2021 20:32:23 GMT, Vicente Romero wrote: >> This patch fixes the following issue, for code like: >> import java.util.function.*; >> >> public class Test { >> public String foo(Object o) { return "foo"; } >> public static String foo(String o) { return "bar"; } >> >> public void test() { >> Function f = Test::foo; >> } >> } >> javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: >> >> If the first search produces a most specific method that is static , and the set >> of applicable methods produced by the second search contains no non- static >> methods, then the compile-time declaration is the most specified method of >> the first search. >> >> Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/107 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Jan 13 12:52:05 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 13 Jan 2021 12:52:05 GMT Subject: RFR: 8236490: Compiler bug relating to @NonNull annotation Message-ID: Hi all, If the exception class index in constant pool exceeds 256, the `exception_index` in `TypeAnnotationPosition` will not work as expected. Please see the following code: public void setCatchInfo(final int catchType, final int startPos) { Assert.check(!hasExceptionIndex(), "exception_index is already set"); Assert.check(catchType >= 0, "Expected a valid catch type"); this.exception_index = -((catchType | startPos << 8) + 1); // <------------------------------ } If `catchType` > 256, which means the 8-15 bits is useful, the ` -((catchType | startPos << 8) + 1);` would override these bits. This patch separates the `startPos` into a new field `exceptionStartPos` to solve the bug. And a test case is added. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8236490: Compiler bug relating to @NonNull annotation Changes: https://git.openjdk.java.net/jdk/pull/2060/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2060&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236490 Stats: 117 lines in 2 files changed: 111 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2060.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2060/head:pull/2060 PR: https://git.openjdk.java.net/jdk/pull/2060 From vromero at openjdk.java.net Wed Jan 13 15:43:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 13 Jan 2021 15:43:23 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference [v3] In-Reply-To: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> Message-ID: > This patch fixes the following issue, for code like: > import java.util.function.*; > > public class Test { > public String foo(Object o) { return "foo"; } > public static String foo(String o) { return "bar"; } > > public void test() { > Function f = Test::foo; > } > } > javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: > > If the first search produces a most specific method that is static , and the set > of applicable methods produced by the second search contains no non- static > methods, then the compile-time declaration is the most specified method of > the first search. > > Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: restoring isSuccess implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/107/files - new: https://git.openjdk.java.net/jdk16/pull/107/files/51a5b194..6a09401b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=107&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=107&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/107.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/107/head:pull/107 PR: https://git.openjdk.java.net/jdk16/pull/107 From mcimadamore at openjdk.java.net Wed Jan 13 16:06:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Jan 2021 16:06:08 GMT Subject: [jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference [v3] In-Reply-To: References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> Message-ID: On Wed, 13 Jan 2021 15:43:23 GMT, Vicente Romero wrote: >> This patch fixes the following issue, for code like: >> import java.util.function.*; >> >> public class Test { >> public String foo(Object o) { return "foo"; } >> public static String foo(String o) { return "bar"; } >> >> public void test() { >> Function f = Test::foo; >> } >> } >> javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: >> >> If the first search produces a most specific method that is static , and the set >> of applicable methods produced by the second search contains no non- static >> methods, then the compile-time declaration is the most specified method of >> the first search. >> >> Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > restoring isSuccess implementation Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/107 From vromero at openjdk.java.net Wed Jan 13 17:30:04 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 13 Jan 2021 17:30:04 GMT Subject: [jdk16] Integrated: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference In-Reply-To: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> References: <-WR373HlzSnJFCEQeS0DQ6Qt_juWbLFERb0m_Kc4W5I=.567b4f32-2843-47f4-abdc-22fc9c82f2de@github.com> Message-ID: On Tue, 12 Jan 2021 02:21:31 GMT, Vicente Romero wrote: > This patch fixes the following issue, for code like: > import java.util.function.*; > > public class Test { > public String foo(Object o) { return "foo"; } > public static String foo(String o) { return "bar"; } > > public void test() { > Function f = Test::foo; > } > } > javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14: > > If the first search produces a most specific method that is static , and the set > of applicable methods produced by the second search contains no non- static > methods, then the compile-time declaration is the most specified method of > the first search. > > Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler. > > TIA This pull request has now been integrated. Changeset: ac4cd2e3 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk16/commit/ac4cd2e3 Stats: 317 lines in 8 files changed: 314 ins; 0 del; 3 mod 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk16/pull/107 From brian.goetz at oracle.com Wed Jan 13 21:56:44 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 13 Jan 2021 16:56:44 -0500 Subject: Compile Time Evaluation: constexpr for Java In-Reply-To: References: Message-ID: <9ef798aa-cd5d-85ae-2b0a-ceafe04afb4d@oracle.com> > Since the const keyword is not used in Java can this be operposed?for > compile time evaluation? Classes, interfaces, methods, fields marked > with const will only be available at compile time and would be fully > evaluated and replaced with the results in runtime bytecode. Better support for compile-time constant folding is a laudable goal (see https://www.youtube.com/watch?v=iSEjlLFCS3E for an exploration of just some of the issues involved).? But coming up with a useful, powerful, and consistent mechanism for exposing compile-time constant folding and propagation requires a lot more than "let's use keyword X."? I think if you try to flesh this out to the next few levels, you'll find that there are many possible paths here, and choosing between them is not trivial. Suffice it to say that we agree that there are opportunities to expose better constancy, but picking a keyword to slap on fields and methods is not the hard part. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilhelm at openjdk.java.net Thu Jan 14 01:25:23 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 14 Jan 2021 01:25:23 GMT Subject: RFR: Merge jdk16 Message-ID: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com> Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows - 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows - 8259722: ProblemList two jdk/jfr/startupargs tests on Windows - 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference - 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading - 8259657: typo in generated HELP page prevents localization - 8258272: LoadVectorMaskedNode can't be replaced by zero con - 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 - 8258985: Parallel WeakProcessor may use too few threads - ... and 11 more: https://git.openjdk.java.net/jdk/compare/c7e2174b...64cae854 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2072&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2072/files Stats: 991 lines in 48 files changed: 764 ins; 123 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/2072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2072/head:pull/2072 PR: https://git.openjdk.java.net/jdk/pull/2072 From jwilhelm at openjdk.java.net Thu Jan 14 01:33:06 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 14 Jan 2021 01:33:06 GMT Subject: Integrated: Merge jdk16 In-Reply-To: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com> References: <-aqBh7X3owjZhc7NJ9IadTg_pDoBEcSVULP6D9ZQlwc=.2f9552f6-95ee-4bdd-8591-e2fea0f2ee47@github.com> Message-ID: On Thu, 14 Jan 2021 01:20:13 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 51e14f2e Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/51e14f2e Stats: 991 lines in 48 files changed: 764 ins; 123 del; 104 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2072 From ljiang at openjdk.java.net Thu Jan 14 14:05:11 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 14:05:11 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 Message-ID: This is the changes for JDK 16 msg drop 10. ------------- Commit messages: - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 Changes: https://git.openjdk.java.net/jdk16/pull/123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259732 Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123 From ljiang at openjdk.java.net Thu Jan 14 14:13:02 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 14:13:02 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang wrote: > This is the changes for JDK 16 msg drop 10. [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From ljiang at openjdk.java.net Thu Jan 14 14:27:25 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 14:27:25 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: Message-ID: > This is the changes for JDK 16 msg drop 10. Leo Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into msgdrop - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/123/files - new: https://git.openjdk.java.net/jdk16/pull/123/files/230117b4..d72f444a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00-01 Stats: 718 lines in 32 files changed: 616 ins; 38 del; 64 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123 From ljiang at openjdk.java.net Thu Jan 14 15:38:09 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Thu, 14 Jan 2021 15:38:09 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:10:12 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) > > Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by `git webrev` and converted. Pls find this to help your review. @naotoj Would you have time to take a look at this change? Very appreciated! ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From naoto at openjdk.java.net Thu Jan 14 17:22:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 14 Jan 2021 17:22:09 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:27:25 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > Leo Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into msgdrop > - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518: > 516: doclet.footer_specified=\ > 517: The -footer option is no longer supported and will be ignored.\n\ > 518: It may be removed in a future release. I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this? ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From vromero at openjdk.java.net Thu Jan 14 18:14:01 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 14 Jan 2021 18:14:01 GMT Subject: RFR: 8236490: Compiler bug relating to @NonNull annotation In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 10:01:26 GMT, Guoxiong Li wrote: > Hi all, > > If the exception class index in constant pool exceeds 256, the `exception_index` in `TypeAnnotationPosition` will not work as expected. Please see the following code: > > public void setCatchInfo(final int catchType, final int startPos) { > Assert.check(!hasExceptionIndex(), > "exception_index is already set"); > Assert.check(catchType >= 0, "Expected a valid catch type"); > this.exception_index = -((catchType | startPos << 8) + 1); // <------------------------------ > } > > If `catchType` > 256, which means the 8-15 bits is useful, the ` -((catchType | startPos << 8) + 1);` would override these bits. > > This patch separates the `startPos` into a new field `exceptionStartPos` to solve the bug. And a test case is added. > > Thank you for taking the time to review. > > Best Regards. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2060 From vromero at openjdk.java.net Thu Jan 14 19:11:02 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 14 Jan 2021 19:11:02 GMT Subject: RFR: 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 07:17:47 GMT, Guoxiong Li wrote: > Hi all, > > Currently, javac doesn't attribute unexpected super constructor invocation qualifier. Please see the following code. > > public class SuperConstructorCallInErrorClass extends Undefined1 { > public SuperConstructorCallInErrorClass(int i) { > new Undefined2() { public void test(int i) { Undefined3 u; } }.super(); //<------------------- > } > } > > The code `new Undefined2() { public void test(int i) { Undefined3 u; } }` isn't attributed by javac. > If we use options like `-XDshould-stop.at=FLOW -XDdev`, the compiler would crash. > > This patch fixes it and adds the corresponding test cases. > > Thank you for taking the time to review. > > Best Regards. looks sensible, I like the fact that this new code is executed if the compiler has already detected an error, so we are already in recovery mode ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2021 From vromero at openjdk.java.net Thu Jan 14 21:18:04 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 14 Jan 2021 21:18:04 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window In-Reply-To: References: Message-ID: <3Q3nGvdUsOrd9z2yScMCrA2Q1Hp7Cps7IY--qvD9qyk=.ee70b1f3-17e7-4339-88ac-20dc00e6df02@github.com> On Fri, 8 Jan 2021 13:33:34 GMT, Guoxiong Li wrote: > Hi all, > > The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below. > > @Override @DefinedBy(Api.COMPILER) > public String getName() { > return relativePath.resolveAgainst(userPackageRootDir).toString(); // <----------------- > } > > And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below > > public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException { > String sep = directory.getFileSystem().getSeparator(); // <--------------------- > return directory.resolve(path.replace("/", sep)); > } > > We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected. > > This patch fixes the test by using the file system separator instead of operating system separator. > > Thank you for taking the time to review. > > Best Regards. test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java line 213: > 211: String sourcePath = file.getName(); > 212: // Here, we should use file system separator instead of the operating system separator. > 213: String fileSystemSep = ((PathFileObject) file).getPath().getFileSystem().getSeparator(); what about using: System.getProperty("file.separator")? ------------- PR: https://git.openjdk.java.net/jdk/pull/2004 From jjg at openjdk.java.net Thu Jan 14 21:29:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 14 Jan 2021 21:29:04 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window In-Reply-To: <3Q3nGvdUsOrd9z2yScMCrA2Q1Hp7Cps7IY--qvD9qyk=.ee70b1f3-17e7-4339-88ac-20dc00e6df02@github.com> References: <3Q3nGvdUsOrd9z2yScMCrA2Q1Hp7Cps7IY--qvD9qyk=.ee70b1f3-17e7-4339-88ac-20dc00e6df02@github.com> Message-ID: On Thu, 14 Jan 2021 21:14:40 GMT, Vicente Romero wrote: >> Hi all, >> >> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below. >> >> @Override @DefinedBy(Api.COMPILER) >> public String getName() { >> return relativePath.resolveAgainst(userPackageRootDir).toString(); // <----------------- >> } >> >> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below >> >> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException { >> String sep = directory.getFileSystem().getSeparator(); // <--------------------- >> return directory.resolve(path.replace("/", sep)); >> } >> >> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected. >> >> This patch fixes the test by using the file system separator instead of operating system separator. >> >> Thank you for taking the time to review. >> >> Best Regards. > > test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java line 213: > >> 211: String sourcePath = file.getName(); >> 212: // Here, we should use file system separator instead of the operating system separator. >> 213: String fileSystemSep = ((PathFileObject) file).getPath().getFileSystem().getSeparator(); > > what about using: System.getProperty("file.separator")? That would be incorrect. That system property is for the default file system, and may not be the correct separator for a user-defined file system, as is possible with `java.nio.file.FileSystem` ------------- PR: https://git.openjdk.java.net/jdk/pull/2004 From vromero at openjdk.java.net Thu Jan 14 21:29:06 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 14 Jan 2021 21:29:06 GMT Subject: RFR: 8203925: tools/javac/importscope/T8193717.java ran out of java heap In-Reply-To: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com> References: <1JXr4lZxAIVdzvun1QqH6qaHQM37WciEWCHmZ3XT-Os=.a2f7d741-a7a5-42bc-9cc5-13aaae9fa96f@github.com> Message-ID: On Fri, 8 Jan 2021 08:12:45 GMT, Guoxiong Li wrote: > Hi all, > > Because [JDK-8225054-PATCH](https://github.com/openjdk/jdk/commit/827e5e32264666639d36990edd5e7d0b7e7c78a9) modified `T8193717.java`, changing `private static final int CLASSES = 500000;` to `private static final int CLASSES = 50000;`(500K -> 50K). The error, `out of java heap`, no longer occurs now. And the pre-submit tests of this patch passed. I think `tools/javac/importscope/T8193717.java` could be removed from `ProblemList.txt`. > > Thank you for taking the time to review. > > Best Regards. test/langtools/ProblemList.txt line 52: > 50: tools/javac/warnings/suppress/TypeAnnotations.java 8057683 generic-all improve ordering of errors with type annotations > 51: tools/javac/modules/SourceInSymlinkTest.java 8180263 windows-all fails when run on a subst drive > 52: tools/javac/importscope/T8193717.java 8203925 generic-all the test requires too much memory I believe that we want to do some more research regarding why the test fails for a large number of imports ------------- PR: https://git.openjdk.java.net/jdk/pull/1998 From jjg at openjdk.java.net Thu Jan 14 21:36:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 14 Jan 2021 21:36:01 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 13:33:34 GMT, Guoxiong Li wrote: > Hi all, > > The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below. > > @Override @DefinedBy(Api.COMPILER) > public String getName() { > return relativePath.resolveAgainst(userPackageRootDir).toString(); // <----------------- > } > > And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below > > public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException { > String sep = directory.getFileSystem().getSeparator(); // <--------------------- > return directory.resolve(path.replace("/", sep)); > } > > We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected. > > This patch fixes the test by using the file system separator instead of operating system separator. > > Thank you for taking the time to review. > > Best Regards. Changes requested by jjg (Reviewer). test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java line 213: > 211: String sourcePath = file.getName(); > 212: // Here, we should use file system separator instead of the operating system separator. > 213: String fileSystemSep = ((PathFileObject) file).getPath().getFileSystem().getSeparator(); It should be possible to get the `Path` without having to cast to the internal `PathFileObject` type. See https://docs.oracle.com/en/java/javase/15/docs/api/java.compiler/javax/tools/StandardJavaFileManager.html#asPath(javax.tools.FileObject) ------------- PR: https://git.openjdk.java.net/jdk/pull/2004 From vicente.romero at oracle.com Thu Jan 14 21:37:36 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 14 Jan 2021 16:37:36 -0500 Subject: Records, Intersection type and lambda In-Reply-To: References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr> Message-ID: <83250674-fa48-27c0-446e-d484bee83d89@oracle.com> Hi Bernard, On 1/6/21 8:02 AM, B. Blaser wrote: > Hi Vicente, > > I saw you've integrated the initial fix with no additional change > which seems reasonable. > > However, did you also try the example I provided below no I didn't sorry, I think that we will have to file a follow-up issue > as I'm not > absolutely sure this works? > Otherwise, you may look at the experimental fix I suggested. > > Thanks, > Bernard Thanks, Vicente > > On Sun, 27 Dec 2020 at 22:31, B. Blaser wrote: >> Hi Vicente, >> >> On Wed, 23 Dec 2020 at 04:29, Vicente Romero wrote: >>> Hi Bernard, >>> >>> what side effects do you see? >> By tweaking Remi's example: >> >> public class RecLCE { >> interface Foo { } >> interface F { >> void call(T t); >> } >> >> record Bar1() implements Foo { } >> record Bar2() implements Foo { } >> record Pair

(P p1, P p2) { >> >> static

Pair

of(P p1, P p2) { >> return new Pair

(p1, p2); >> } >> >> void forEach(F

f) { >> f.call(p1); >> f.call(p2); >> } >> } >> >> static class Hello { >> void m(Foo foo) { >> System.out.println(foo.getClass()); >> } >> } >> >> public static void main(String[] args) { >> var pair = Pair.of(new Bar1(), new Bar2()); >> pair.forEach(new Hello()::m); >> } >> } >> >> The line you've added is causing the lambda to use the instantiated >> type 'Record' which isn't a subtype of 'Foo', see javap's output: >> Method arguments: >> #57 (LRecLCE$Foo;)V >> #58 REF_invokeStatic >> RecLCE.lambda$main$0:(LRecLCE$Hello;Ljava/lang/Record;)V >> #61 (Ljava/lang/Record;)V >> >> So, it should use the un-instantiated SAM parameter type 'Foo' instead >> which my initial fix was suggesting: >> Method arguments: >> #57 (LRecLCE$Foo;)V >> #58 REF_invokeStatic RecLCE.lambda$main$0:(LRecLCE$Hello;LRecLCE$Foo;)V >> #61 (Ljava/lang/Record;)V >> >> Unfortunately, this very example reveals another issue as the >> instantiated type 'Record' is still not convertible to 'Foo' although >> all was working fine with Remis's initial example: >> Method arguments: >> #55 (Ljava/lang/Object;)V >> #57 REF_invokeStatic >> RecordIntersectionTypeAndLambda.lambda$main$0:(LRecordIntersectionTypeAndLambda$Hello;Ljava/lang/Object;)V >> #60 (Ljava/lang/Record;)V >> >> Referring to 'LambdaMetafactory::metafactory', we see that >> 'instantiatedMethodType' may be the same or a specialization of >> 'samMethodType' suggesting to use the SAM type too when the >> instantiated type is compound like in the experimental fix below >> (langtools:tier1 is OK on jdk14u): >> Method arguments: >> #57 (LRecLCE$Foo;)V >> #58 REF_invokeStatic RecLCE.lambda$main$0:(LRecLCE$Hello;LRecLCE$Foo;)V >> #57 (LRecLCE$Foo;)V >> >> What do you think? >> Bernard >> >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >> @@ -438,6 +438,7 @@ >> List indy_args = >> translate(syntheticInits.toList(), localContext.prev); >> >> //convert to an invokedynamic call >> + localContext.useSAM = tree.useSAM; >> result = makeMetafactoryIndyCall(context, sym.asHandle(), indy_args); >> } >> >> @@ -888,6 +889,7 @@ >> private final ListBuffer params = new ListBuffer<>(); >> >> private JCExpression receiverExpression = null; >> + private boolean useSAM = false; >> >> MemberReferenceToLambda(JCMemberReference tree, >> ReferenceTranslationContext localContext, Symbol owner) { >> this.tree = tree; >> @@ -911,6 +913,7 @@ >> slam.target = tree.target; >> slam.type = tree.type; >> slam.pos = tree.pos; >> + slam.useSAM = useSAM; >> return slam; >> } finally { >> make.at(prevPos); >> @@ -954,6 +957,7 @@ >> >> // Failsafe -- assure match-up >> boolean checkForIntersection = tree.varargsElement != >> null || implSize == descPTypes.size(); >> + useSAM = checkForIntersection && >> localContext.interfaceParameterIsIntersectionOrUnionType(); >> >> // Use parameter types of the implementation method >> unless the unerased >> // SAM parameter type is an intersection type, in that case use the >> @@ -963,18 +967,7 @@ >> // are used as pointers to the current parameter type information >> // and are thus not usable afterwards. >> for (int i = 0; implPTypes.nonEmpty() && i < last; ++i) { >> - // By default use the implementation method parmeter type >> - Type parmType = implPTypes.head; >> - // If the unerased parameter type is a type variable whose >> - // bound is an intersection (eg. ) then >> - // use the SAM parameter type >> - if (checkForIntersection && descPTypes.head.getKind() >> == TypeKind.TYPEVAR) { >> - TypeVar tv = (TypeVar) descPTypes.head; >> - if (tv.getUpperBound().getKind() == >> TypeKind.INTERSECTION) { >> - parmType = samPTypes.head; >> - } >> - } >> - addParameter("x$" + i, parmType, true); >> + addParameter("x$" + i, useSAM ? samPTypes.head : >> implPTypes.head, true); >> >> // Advance to the next parameter >> implPTypes = implPTypes.tail; >> @@ -1094,7 +1087,7 @@ >> List staticArgs = List.of( >> typeToMethodType(samSym.type), >> refSym.asHandle(), >> - typeToMethodType(tree.getDescriptorType(types))); >> + typeToMethodType(context.useSAM ? samSym.type : >> tree.getDescriptorType(types))); >> >> //computed indy arg types >> ListBuffer indy_args_types = new ListBuffer<>(); >> @@ -1826,6 +1819,8 @@ >> /** list of methods to be bridged by the meta-factory */ >> final List bridges; >> >> + boolean useSAM = false; >> + >> TranslationContext(T tree) { >> this.tree = tree; >> this.owner = owner(true); >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java >> @@ -1892,6 +1892,7 @@ >> public JCTree body; >> public boolean canCompleteNormally = true; >> public ParameterKind paramKind; >> + public boolean useSAM = false; >> >> public JCLambda(List params, >> JCTree body) { From jjg at openjdk.java.net Thu Jan 14 21:52:05 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 14 Jan 2021 21:52:05 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window In-Reply-To: <3Q3nGvdUsOrd9z2yScMCrA2Q1Hp7Cps7IY--qvD9qyk=.ee70b1f3-17e7-4339-88ac-20dc00e6df02@github.com> References: <3Q3nGvdUsOrd9z2yScMCrA2Q1Hp7Cps7IY--qvD9qyk=.ee70b1f3-17e7-4339-88ac-20dc00e6df02@github.com> Message-ID: On Thu, 14 Jan 2021 21:14:40 GMT, Vicente Romero wrote: >> Hi all, >> >> The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below. >> >> @Override @DefinedBy(Api.COMPILER) >> public String getName() { >> return relativePath.resolveAgainst(userPackageRootDir).toString(); // <----------------- >> } >> >> And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below >> >> public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException { >> String sep = directory.getFileSystem().getSeparator(); // <--------------------- >> return directory.resolve(path.replace("/", sep)); >> } >> >> We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected. >> >> This patch fixes the test by using the file system separator instead of operating system separator. >> >> Thank you for taking the time to review. >> >> Best Regards. > > test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java line 213: > >> 211: String sourcePath = file.getName(); >> 212: // Here, we should use file system separator instead of the operating system separator. >> 213: String fileSystemSep = ((PathFileObject) file).getPath().getFileSystem().getSeparator(); > > what about using: System.getProperty("file.separator")? @vicente-romero-oracle Explaining a bit more ... on Windows, the default file system separator is `` but we're dealing here with `Path` objects from the "internal" JRT file system, which uses `/` as a separator. That's why we have to be careful to use the right separator. On Unix/Linux/macOS, the separators are the same, which is how the test has passed on those platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/2004 From ljiang at openjdk.java.net Fri Jan 15 02:02:11 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Fri, 15 Jan 2021 02:02:11 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: Message-ID: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> On Thu, 14 Jan 2021 17:19:11 GMT, Naoto Sato wrote: >> Leo Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into msgdrop >> - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518: > >> 516: doclet.footer_specified=\ >> 517: The -footer option is no longer supported and will be ignored.\n\ >> 518: It may be removed in a future release. > > I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this? Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? doclet.help.systemProperties.body=\ The {0} page lists references to system properties. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 15 12:22:19 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 15 Jan 2021 12:22:19 GMT Subject: RFR: 8232765: NullPointerException at Types.eraseNotNeeded() when compiling a class Message-ID: <1aAA0XDVv4IDazXeCSwgqnaI8TSloIz_kb2jPRLJEk4=.5c06fc0f-9e5c-4f8c-aa89-49fa4a3f7925@github.com> Hi all, The method `types::asSuper` may return `null` so that `types.erasure(types.asSuper(iterator.type.getReturnType(), syms.iteratorType.tsym))` throws `NPE`. This patch sets the return type and outputs the corresponding error message if `types::asSuper` returns `null`. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8232765: NullPointerException at Types.eraseNotNeeded() when compiling a class Changes: https://git.openjdk.java.net/jdk/pull/2099/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2099&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8232765 Stats: 168 lines in 4 files changed: 165 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2099.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2099/head:pull/2099 PR: https://git.openjdk.java.net/jdk/pull/2099 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 15 12:54:25 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 15 Jan 2021 12:54:25 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 21:33:08 GMT, Jonathan Gibbons wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use StandardJavaFileManager::asPath > > test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java line 213: > >> 211: String sourcePath = file.getName(); >> 212: // Here, we should use file system separator instead of the operating system separator. >> 213: String fileSystemSep = ((PathFileObject) file).getPath().getFileSystem().getSeparator(); > > It should be possible to get the `Path` without having to cast to the internal `PathFileObject` type. > > See https://docs.oracle.com/en/java/javase/15/docs/api/java.compiler/javax/tools/StandardJavaFileManager.html#asPath(javax.tools.FileObject) @jonathan-gibbons Thanks for your suggestion. I have updated the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/2004 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 15 12:54:24 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 15 Jan 2021 12:54:24 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v2] In-Reply-To: References: Message-ID: <_5--Fg9625hxd0AL_yW1wG0xKRc2aQzGfHNdeFIJK5U=.6375e1ea-0247-4c76-8841-bfe3a9558138@github.com> > Hi all, > > The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below. > > @Override @DefinedBy(Api.COMPILER) > public String getName() { > return relativePath.resolveAgainst(userPackageRootDir).toString(); // <----------------- > } > > And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below > > public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException { > String sep = directory.getFileSystem().getSeparator(); // <--------------------- > return directory.resolve(path.replace("/", sep)); > } > > We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected. > > This patch fixes the test by using the file system separator instead of operating system separator. > > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Use StandardJavaFileManager::asPath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2004/files - new: https://git.openjdk.java.net/jdk/pull/2004/files/d375cc03..aee1c4a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2004&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2004&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2004.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2004/head:pull/2004 PR: https://git.openjdk.java.net/jdk/pull/2004 From bsrbnd at gmail.com Fri Jan 15 13:36:05 2021 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 15 Jan 2021 14:36:05 +0100 Subject: Records, Intersection type and lambda In-Reply-To: <83250674-fa48-27c0-446e-d484bee83d89@oracle.com> References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr> <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr> <83250674-fa48-27c0-446e-d484bee83d89@oracle.com> Message-ID: On Thu, 14 Jan 2021 at 22:38, Vicente Romero wrote: > > Hi Bernard, > > On 1/6/21 8:02 AM, B. Blaser wrote: > > Hi Vicente, > > > > I saw you've integrated the initial fix with no additional change > > which seems reasonable. > > > > However, did you also try the example I provided below > > no I didn't sorry, I think that we will have to file a follow-up issue Already filed a few days ago ;-) https://bugs.openjdk.java.net/browse/JDK-8259491 Bernard From alanb at openjdk.java.net Fri Jan 15 15:01:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Jan 2021 15:01:09 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote: >> Marked as reviewed by prr (Reviewer). > > This PR is not stale; it's just still waiting for input from @AlanBateman. @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From mark.reinhold at oracle.com Fri Jan 15 18:27:09 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 15 Jan 2021 10:27:09 -0800 Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> Message-ID: <20210115102709.538599954@eggemoggin.niobe.net> 2020/12/4 6:08:13 -0800, erikj at openjdk.java.net: > On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >>> And I can certainly move jdwp.spec to java.base instead. That's the >>> reason I need input on this: All I know is that is definitely not >>> the responsibility of the Build Group to maintain that document, and >>> I made my best guess at where to place it. >> >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably >> the most suitable home because Java SE specifies JDWP as an optional >> interface. So nothing to do with java.base and the build will need to >> continue to generate the sources for the front-end (jdk.jdi) and >> back-end (jdk.jdwp.agent) as they implement the protocol. > > My understanding of JEPs is that they should be viewed as living > documents. In this case, I think it's perfectly valid to update JEP > 201 with additional source code layout. Both for this and for the > other missing dirs. Feature JEPs are living documents until such time as they are delivered. In this case it would not be appropriate to update JEP 201, which is as much about the transition from the old source-code layout as it is about the new layout as of 2014. At this point, and given that we?d already gone beyond JEP 201 prior to this change (with `man` and `lib` subdirectories), what?d make the most sense is a new informational JEP that documents the source-code layout. Informational JEPs can, within reason, be updated over time. - Mark From ihse at openjdk.java.net Fri Jan 15 18:30:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 15 Jan 2021 18:30:07 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? @AlanBateman That sounds like an excellent idea. I'll update the PR first thing next week. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From vromero at openjdk.java.net Fri Jan 15 19:20:04 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 15 Jan 2021 19:20:04 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v2] In-Reply-To: References: <3Q3nGvdUsOrd9z2yScMCrA2Q1Hp7Cps7IY--qvD9qyk=.ee70b1f3-17e7-4339-88ac-20dc00e6df02@github.com> Message-ID: On Thu, 14 Jan 2021 21:49:19 GMT, Jonathan Gibbons wrote: >> test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java line 213: >> >>> 211: String sourcePath = file.getName(); >>> 212: // Here, we should use file system separator instead of the operating system separator. >>> 213: String fileSystemSep = ((PathFileObject) file).getPath().getFileSystem().getSeparator(); >> >> what about using: System.getProperty("file.separator")? > > @vicente-romero-oracle Explaining a bit more ... on Windows, the default file system separator is `` but we're dealing here with `Path` objects from the "internal" JRT file system, which uses `/` as a separator. That's why we have to be careful to use the right separator. On Unix/Linux/macOS, the separators are the same, which is how the test has passed on those platforms. I see thanks for the clarification ------------- PR: https://git.openjdk.java.net/jdk/pull/2004 From naoto at openjdk.java.net Sat Jan 16 00:51:09 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 16 Jan 2021 00:51:09 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> References: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> Message-ID: On Fri, 15 Jan 2021 01:59:07 GMT, Leo Jiang wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 518: >> >>> 516: doclet.footer_specified=\ >>> 517: The -footer option is no longer supported and will be ignored.\n\ >>> 518: It may be removed in a future release. >> >> I believe this is to fix no newline at the end (unrelated to l10n changes). Do we need to change the copyright year for this? > > Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? > doclet.help.systemProperties.body=\ > The {0} page lists references to system properties. I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From github.com+13688759+lgxbslgx at openjdk.java.net Sun Jan 17 17:16:14 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sun, 17 Jan 2021 17:16:14 GMT Subject: RFR: 8213766: Assertion error in TypeAnnotations$TypeAnnotationPositions.resolveFrame Message-ID: <-img5oopyq6D7dQCDMBQOGMSlf5kDClvabMowfqgpXU=.2a316b41-63a6-4149-8434-8fbb5d0000c1@github.com> Hi all, This regression is caused by [PATCH-8078093](https://github.com/openjdk/jdk/commit/981c6dc2989b66f3691090c9f81e23d2b0a00087). The method `DeferredAttr$DeferredAttrNode$StructuralStuckChecker.canLambdaBodyCompleteNormally` uses `attribSpeculativeLambda`. Later, the `ArgumentAttr.visitLambda(JCLambda that)` would be invoked, which sets the `ExplicitLambdaType.tree.type` to its `ExplicitLambdaType`. Note: currently, the `ExplicitLambdaType.tree` was not attributed and only the `ExplicitLambdaType.speculativeTree` was attributed. Then, `DeferredAttr$RecoveryDeferredTypeMap.typeOf` would not invoke the method `recover` to attribute the `ExplicitLambdaType.tree` because the `owntype` is not equal to `Type.noType`. The code and some comments are shown below for you. protected Type typeOf(DeferredType dt, Type pt) { Type owntype = super.typeOf(dt, pt); // The `super.typeOf(dt, pt)` returns the `ExplicitLambdaType` which is set previously. return owntype == Type.noType ? recover(dt, pt) : owntype; // Here, the method `recover` is not invoked because `owntype == Type.noType` returns false. } Because the tree is not attributed, some regressions will occur, including this bug. Although I found the cause of this bug, I think my patch is the simplest solution but it may be not the best solution. Another solution is that method `DeferredAttr$DeferredAttrNode$StructuralStuckChecker.canLambdaBodyCompleteNormally` uses other way instead of using `attribSpeculativeLambda`. The old way which is before PATCH-8078093 is a candidate. Any better solution is appreciated. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8213766: Assertion error in TypeAnnotations.resolveFrame Changes: https://git.openjdk.java.net/jdk/pull/2118/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2118&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8213766 Stats: 58 lines in 2 files changed: 56 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2118.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2118/head:pull/2118 PR: https://git.openjdk.java.net/jdk/pull/2118 From ljiang at openjdk.java.net Mon Jan 18 05:52:57 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Mon, 18 Jan 2021 05:52:57 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v3] In-Reply-To: References: Message-ID: > This is the changes for JDK 16 msg drop 10. Leo Jiang has updated the pull request incrementally with one additional commit since the last revision: fix the missing copyright year for standard.properties ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/123/files - new: https://git.openjdk.java.net/jdk16/pull/123/files/d72f444a..9c7574e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123 From ljiang at openjdk.java.net Mon Jan 18 05:52:57 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Mon, 18 Jan 2021 05:52:57 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2] In-Reply-To: References: <1Bb8sf6zFDnQSM5kRQIlrgBNwEpO-IvxsPmN05F0QFs=.13eb3035-71d5-4310-98e5-d9989e51cf60@github.com> Message-ID: On Sat, 16 Jan 2021 00:48:43 GMT, Naoto Sato wrote: >> Actually I was correcting the L217, changed {) -> {}. But 2 days ago, Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after running the merge. Looks both of us forgot to update the copyright year. Any suggestion? >> doclet.help.systemProperties.body=\ >> The {0} page lists references to system properties. > > I believe your PR still contains the fix to add the newline at the end of the file (at L518). So I think you can simply change the copyright year in `standard.properties` file. Thx! Fixed the copyright year for this file. ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From anna.kozlova at jetbrains.com Mon Jan 18 09:38:39 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Mon, 18 Jan 2021 10:38:39 +0100 Subject: java 17: anonymous classes with diamonds Message-ID: Hi all, The following code doesn't compile with java 17 eap (java: foo.Boo.Nested is abstract; cannot be instantiated) ``` public class Boo { static abstract class Nested { protected Nested(Class aAcceptedClass) { } } static class Outer { protected Outer(final Nested condition) { } } static final Outer PATTERN = new Outer<>(new Nested<>(Boo.class) {}) {}; } ``` though the anonymous class is used. At the same time, if I remove the anonymous class from outer call, like `static final Outer PATTERN = new Outer<>(new Nested<>(Boo.class) {});` the code would compile. If explicit types instead of diamonds are used, everything compiles fine as well. To me this looks like a bug in the compiler, could someone check this please? Thanks, Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Mon Jan 18 10:18:00 2021 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 18 Jan 2021 15:48:00 +0530 Subject: java 17: anonymous classes with diamonds In-Reply-To: References: Message-ID: <5b520566-76d9-a2a0-b255-7cce6ff24047@oracle.com> Thanks for the problem report Anna. It does look suspect and I have raised JDK-8259910 to follow up. This problem dates back to jdk9 and is reproducible in all the major releases from then on. Srikanth On 18/01/21 3:08 pm, Anna Kozlova wrote: > Hi all, > > The following code doesn't compile with java 17 eap (java: > foo.Boo.Nested is abstract; cannot be instantiated) > ``` > public class Boo { > static abstract class Nested { > protected Nested(Class aAcceptedClass) { } > > } > static class Outer { > protected Outer(final Nested condition) { } > } > > static final Outer PATTERN =new Outer<>(new Nested<>(Boo.class) {}) {}; > } > ``` > though the anonymous class is used. > > At the same time, if I remove the anonymous class from outer call, like > `static final Outer PATTERN = new Outer<>(new Nested<>(Boo.class) > {});` the code would compile. > > If explicit types instead of diamonds are used, everything compiles > fine as well. > > To me this looks like a bug in the compiler, could someone check this > please? > > Thanks, > Anna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kozlova at jetbrains.com Mon Jan 18 11:06:33 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Mon, 18 Jan 2021 12:06:33 +0100 Subject: No subject Message-ID: Hi all, the following code doesn't compile with java 12 + (including java 17) with "cannot find symbolsymbol: variable p" ``` class Boo { { create(p -> new ArrayList<>() { @Override public int size() { System.out.println(p); return super.size(); } }); } private void create(Function> o) { } } ``` though if I replace diamond with explicit type the lambda parameter can be found in the anonymous class body. If I remove unused type parameter `C` from `create`, code compiles fine again. Looks like a bug to me, could someone please check? Thanks, Anna P.S. java 11 fails with internal compiler error -------------- next part -------------- An HTML attachment was scrubbed... URL: From neshkeev at yandex.ru Mon Jan 18 12:54:03 2021 From: neshkeev at yandex.ru (Nikita Eshkeev) Date: Mon, 18 Jan 2021 15:54:03 +0300 Subject: Unchecked cast to intersection type Message-ID: <2340201610971248@mail.yandex.ru> An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Mon Jan 18 13:21:07 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 14:21:07 +0100 Subject: RFR: 8257733: Move module-specific data from make to respective module In-Reply-To: <20210115102709.538599954@eggemoggin.niobe.net> References: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com> <20210115102709.538599954@eggemoggin.niobe.net> Message-ID: <0219364d-3926-2b7b-4cb5-90f698eeb706@oracle.com> On 2021-01-15 19:27, mark.reinhold at oracle.com wrote: > Feature JEPs are living documents until such time as they are delivered. > In this case it would not be appropriate to update JEP 201, which is as > much about the transition from the old source-code layout as it is about > the new layout as of 2014. > > At this point, and given that we?d already gone beyond JEP 201 prior to > this change (with `man` and `lib` subdirectories), what?d make the most > sense is a new informational JEP that documents the source-code layout. > Informational JEPs can, within reason, be updated over time. So I take it I need to create a new informational JEP. :-) Fine, I can do that. I assume I mostly need to extract the parts of JEP 201 that describes the (then "new") layout, update wording to show that this is a description of the current layout, and add the new additions. It'll be a very short JEP, but in this case, that's probably a virtue. /Magnus From ihse at openjdk.java.net Mon Jan 18 13:47:20 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:47:20 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v5] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Move characterdata templates to share/classes/java/lang. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/68b252b5..c4894348 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=03-04 Stats: 4 lines in 9 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Jan 18 13:49:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Jan 2021 13:49:49 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? @AlanBateman When I moved the charset templates, I found this gold nugget: # Copy two Java files that need no preprocessing. $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template $(call LogInfo, Generating $(@F)) $(call install-file) GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From anna.kozlova at jetbrains.com Mon Jan 18 13:56:31 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Mon, 18 Jan 2021 14:56:31 +0100 Subject: java 17: anonymous classes with diamonds In-Reply-To: <5b520566-76d9-a2a0-b255-7cce6ff24047@oracle.com> References: <5b520566-76d9-a2a0-b255-7cce6ff24047@oracle.com> Message-ID: Thanks! Not sure if it's exactly the same issue, could you please check as well? At least the error message is not very helpful: "cannot find symbol symbol: class location: class foo.Boo" (no line number) ``` import java.util.List; import java.util.function.Predicate; public class Boo { public Boo(List l) { } void m(List list){ Boo boo3 = new Boo<>(findAll(list, s -> s.length() > 0)){}; } static List findAll(List collection, Predicate condition) { return null; } } ``` If I remove anonymous class braces, the code starts to compile. Checked with with java 11 & java 17 Thanks, Anna P.S. I've migrated IntelliJ sources to java 11 diamonds, thus the issues. This one is the last issue I could reproduce with java 17. A lot of issues have been fixed since java 11! On Mon, Jan 18, 2021 at 11:18 AM Srikanth wrote: > Thanks for the problem report Anna. > > It does look suspect and I have raised JDK-8259910 to follow up. > > This problem dates back to jdk9 and is reproducible in all the major > releases from then on. > > Srikanth > > On 18/01/21 3:08 pm, Anna Kozlova wrote: > > Hi all, > > The following code doesn't compile with java 17 eap (java: foo.Boo.Nested > is abstract; cannot be instantiated) > ``` > public class Boo { > > static abstract class Nested { > protected Nested(Class aAcceptedClass) { } > > } > static class Outer { > protected Outer(final Nested condition) { } > } > > static final Outer PATTERN = new Outer<>(new Nested<>(Boo.class) {}) {}; > } > > ``` > though the anonymous class is used. > > At the same time, if I remove the anonymous class from outer call, like > `static final Outer PATTERN = new Outer<>(new Nested<>(Boo.class) > {});` the code would compile. > > If explicit types instead of diamonds are used, everything compiles fine > as well. > > To me this looks like a bug in the compiler, could someone check this > please? > > Thanks, > Anna > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Tue Jan 19 08:21:06 2021 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 19 Jan 2021 13:51:06 +0530 Subject: java 17: anonymous classes with diamonds In-Reply-To: References: <5b520566-76d9-a2a0-b255-7cce6ff24047@oracle.com> Message-ID: <2574eed3-ebee-ce23-2b92-eb386c05f475@oracle.com> On 18/01/21 7:26 pm, Anna Kozlova wrote: > Thanks! > > Not sure if it's exactly the same issue, could you please check as > well? At least the error message is not very helpful: "cannot find symbol > ? symbol: ? class > ? location: class foo.Boo" (no line number) Thanks for the report, I have raised JDK-8259960 to investigate this. Srikanth > > ``` > import java.util.List; > import java.util.function.Predicate; > > public class Boo { > public Boo(List l) { > } > void m(List list){ > Boo boo3 =new Boo<>(findAll(list, s -> s.length() >0)){}; > } > > static List findAll(List collection, > Predicate condition) { > return null; > } > } > ``` > > If I remove anonymous class braces, the code starts to compile. > Checked with with java 11 & java 17 > > Thanks, > Anna > > P.S. I've migrated IntelliJ sources to java 11 diamonds, thus the > issues. This one is the last issue I could reproduce with?java 17. A > lot of issues have been fixed since java 11! > > On Mon, Jan 18, 2021 at 11:18 AM Srikanth > > wrote: > > Thanks for the problem report Anna. > > It does look suspect and I have raised JDK-8259910 to follow up. > > This problem dates back to jdk9 and is reproducible in all the > major releases from then on. > > Srikanth > > On 18/01/21 3:08 pm, Anna Kozlova wrote: >> Hi all, >> >> The following code doesn't compile with java 17 eap (java: >> foo.Boo.Nested is abstract; cannot be instantiated) >> ``` >> public class Boo { >> static abstract class Nested { >> protected Nested(Class aAcceptedClass) { } >> >> } >> static class Outer { >> protected Outer(final Nested condition) { } >> } >> >> static final Outer PATTERN =new Outer<>(new Nested<>(Boo.class) {}) {}; >> } >> ``` >> though the anonymous class is used. >> >> At the same time, if I remove the anonymous class from outer >> call, like >> `static final Outer PATTERN = new Outer<>(new >> Nested<>(Boo.class) {});` the code would compile. >> >> If explicit types instead of diamonds are used, everything >> compiles fine as well. >> >> To me this looks like a bug in the compiler, could someone check >> this please? >> >> Thanks, >> Anna >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Tue Jan 19 08:26:38 2021 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 19 Jan 2021 13:56:38 +0530 Subject: No subject In-Reply-To: References: Message-ID: Thanks Anna, I have added this test case to JDK-8259960, if it proves necessary? I'll split it later into an issue of its own. Srikanth On 18/01/21 4:36 pm, Anna Kozlova wrote: > Hi all, > > the following code doesn't compile with?java 12?+ (including java 17) > with "cannot find symbolsymbol: variable p" > > ``` > class Boo { > { > create(p ->new ArrayList<>() { > @Override public int size() { > System.out.println(p); > return super.size(); > } > }); > } > > private void create(Function> o) { } > > } > ``` > > though if I replace diamond with explicit type the lambda parameter > can be found in the anonymous class body. > > If I remove unused type parameter `C` from `create`, code compiles > fine again. > > Looks like a bug to me, could someone please check? > > Thanks, > Anna > > P.S. java 11 fails with internal?compiler error -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kozlova at jetbrains.com Tue Jan 19 11:38:01 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Tue, 19 Jan 2021 12:38:01 +0100 Subject: No subject In-Reply-To: References: Message-ID: Thanks! On Tue, Jan 19, 2021 at 9:27 AM Srikanth wrote: > Thanks Anna, I have added this test case to JDK-8259960, if it proves > necessary I'll split it later into an issue of its own. > > Srikanth > > On 18/01/21 4:36 pm, Anna Kozlova wrote: > > Hi all, > > the following code doesn't compile with java 12 + (including java 17) with > "cannot find symbolsymbol: variable p" > > ``` > > class Boo { > { > create(p -> new ArrayList<>() { > @Override public int size() { > System.out.println(p); > return super.size(); > } > }); > } > > private void create(Function> o) { } > > } > > ``` > > though if I replace diamond with explicit type the lambda parameter can be > found in the anonymous class body. > > If I remove unused type parameter `C` from `create`, code compiles fine > again. > > Looks like a bug to me, could someone please check? > > Thanks, > Anna > > P.S. java 11 fails with internal compiler error > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kozlova at jetbrains.com Tue Jan 19 11:38:18 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Tue, 19 Jan 2021 12:38:18 +0100 Subject: java 17: anonymous classes with diamonds In-Reply-To: <2574eed3-ebee-ce23-2b92-eb386c05f475@oracle.com> References: <5b520566-76d9-a2a0-b255-7cce6ff24047@oracle.com> <2574eed3-ebee-ce23-2b92-eb386c05f475@oracle.com> Message-ID: Thanks! On Tue, Jan 19, 2021 at 9:21 AM Srikanth wrote: > > > On 18/01/21 7:26 pm, Anna Kozlova wrote: > > Thanks! > > Not sure if it's exactly the same issue, could you please check as well? > At least the error message is not very helpful: "cannot find symbol > symbol: class > location: class foo.Boo" (no line number) > > > Thanks for the report, I have raised JDK-8259960 to investigate this. > > Srikanth > > > ``` > > import java.util.List;import java.util.function.Predicate; > public class Boo { > public Boo(List l) { > } > void m(List list){ > Boo boo3 = new Boo<>(findAll(list, s -> s.length() > 0)){}; > } > > static List findAll(List collection, > Predicate condition) { > return null; > } > } > > ``` > > If I remove anonymous class braces, the code starts to compile. Checked > with with java 11 & java 17 > > Thanks, > Anna > > P.S. I've migrated IntelliJ sources to java 11 diamonds, thus the issues. > This one is the last issue I could reproduce with java 17. A lot of issues > have been fixed since java 11! > > On Mon, Jan 18, 2021 at 11:18 AM Srikanth > wrote: > >> Thanks for the problem report Anna. >> >> It does look suspect and I have raised JDK-8259910 to follow up. >> >> This problem dates back to jdk9 and is reproducible in all the major >> releases from then on. >> >> Srikanth >> >> On 18/01/21 3:08 pm, Anna Kozlova wrote: >> >> Hi all, >> >> The following code doesn't compile with java 17 eap (java: foo.Boo.Nested >> is abstract; cannot be instantiated) >> ``` >> public class Boo { >> >> static abstract class Nested { >> protected Nested(Class aAcceptedClass) { } >> >> } >> static class Outer { >> protected Outer(final Nested condition) { } >> } >> >> static final Outer PATTERN = new Outer<>(new Nested<>(Boo.class) {}) {}; >> } >> >> ``` >> though the anonymous class is used. >> >> At the same time, if I remove the anonymous class from outer call, like >> `static final Outer PATTERN = new Outer<>(new Nested<>(Boo.class) >> {});` the code would compile. >> >> If explicit types instead of diamonds are used, everything compiles fine >> as well. >> >> To me this looks like a bug in the compiler, could someone check this >> please? >> >> Thanks, >> Anna >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.java.net Tue Jan 19 16:55:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 19 Jan 2021 16:55:46 GMT Subject: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v3] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 05:52:57 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > Leo Jiang has updated the pull request incrementally with one additional commit since the last revision: > > fix the missing copyright year for standard.properties Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From jjg at openjdk.java.net Wed Jan 20 06:19:59 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 20 Jan 2021 06:19:59 GMT Subject: RFR: JDK-8255464: Cannot access ModuleTree in a CompilationUnitTree Message-ID: Please review a small change to add an overdue missing method to access the `ModuleTree` when a `CompilationUnitTree` represents a modular compilation unit. CSR is in progress. ------------- Commit messages: - JDK-8255464: Cannot access ModuleTree in a CompilationUnitTree Changes: https://git.openjdk.java.net/jdk/pull/2155/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2155&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255464 Stats: 179 lines in 5 files changed: 171 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2155.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2155/head:pull/2155 PR: https://git.openjdk.java.net/jdk/pull/2155 From sirinath1978m at gmail.com Wed Jan 20 06:53:11 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Wed, 20 Jan 2021 12:23:11 +0530 Subject: Intersection and Union Types for Java Message-ID: Hello, Can the Java type system be extended to accommodate Intersection and Union Types. Currently we can write: void f(T t) { ... } but not void f(T t) { ... } or void f(T t) { ... } Also we cannot have void f(A & B t) { ... } or void f((A | B) & C t) { ... } When considering languages like Ceylon (https://ceylon-lang.org/) and Scala 3 / Dotty (https://dotty.epfl.ch/) these seem to be very useful. Suminda -------------- next part -------------- An HTML attachment was scrubbed... URL: From lgxbslgx at gmail.com Wed Jan 20 12:10:53 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Wed, 20 Jan 2021 20:10:53 +0800 Subject: A possible improvement at Tokens and Names Message-ID: Hi all, When I read the code at `jdk.compiler/com.sun.tools.javac.parser.Tokens` and ``jdk.compiler/com.sun.tools.javac.util.Names`, I find a point which can be possibly improved. The constructor of the class `Tokens` invokes `Names.instance(context)` to initialize `Names` which would initialize many unrelated names. Then, this constructor uses the method `enterKeyword` to initialize the names about `TokenKind` and to set `maxKey`. Because `Names.instance(context)` initializes many unrelated names, the `Name.index` becomes very large so that the `maxKey` also becomes very large. Then, the constructor creates an array `key` by using the code `key = new TokenKind[maxKey+1]`. We can identify that the variable `key` is unnecessary to be so large. I would like to initialize the related names, which are about `TokenKind`, at the beginning of the constructor of the class `Names` to improve the code. The complete patch is shown at the end of this email. When using the code of the master branch, the length of the array `Tokens.key` is 4280. When using my patch, the length of the array `Tokens.key` is 383. The improvement is obvious. Could I get your help to identify whether this improvement is feasible? If so, could I get your help to file an issue at the bug tracker? Thanks a lot. The patch: diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java index bd61dcf8ad2..3b4eb5bf4be 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java @@ -60,7 +60,7 @@ public class Tokens { /** The names of all tokens. */ - private Name[] tokenName = new Name[TokenKind.values().length]; + private Name[] tokenName; public static final Context.Key tokensKey = new Context.Key<>(); @@ -74,11 +74,10 @@ public class Tokens { protected Tokens(Context context) { context.put(tokensKey, this); names = Names.instance(context); - for (TokenKind t : TokenKind.values()) { - if (t.name != null) - enterKeyword(t.name, t); - else - tokenName[t.ordinal()] = null; + tokenName = names.tokenName; + for (Name n : tokenName) { + if (n != null && n.getIndex() > maxKey) + maxKey = n.getIndex(); } key = new TokenKind[maxKey+1]; @@ -89,12 +88,6 @@ public class Tokens { } } - private void enterKeyword(String s, TokenKind token) { - Name n = names.fromString(s); - tokenName[token.ordinal()] = n; - if (n.getIndex() > maxKey) maxKey = n.getIndex(); - } - /** * Create a new token given a name; if the name corresponds to a token name, * a new token of the corresponding kind is returned; otherwise, an diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java index 26e0b7577aa..341817e8ff9 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java @@ -25,6 +25,8 @@ package com.sun.tools.javac.util; +import com.sun.tools.javac.parser.Tokens.TokenKind; + /** * Access to the compiler's name table. Standard names are defined, * as well as methods to create new names. @@ -47,6 +49,9 @@ public class Names { return instance; } + // the names about TokenKind + public final Name[] tokenName = new Name[TokenKind.values().length]; + // operators and punctuation public final Name asterisk; public final Name comma; @@ -220,6 +225,15 @@ public class Names { Options options = Options.instance(context); table = createTable(options); + // set the names about TokenKind + for (TokenKind tokenKind : TokenKind.values()) { + Name tempName = null; + if (tokenKind.name != null) { + tempName = fromString(tokenKind.name); + } + tokenName[tokenKind.ordinal()] = tempName; + } + // operators and punctuation asterisk = fromString("*"); comma = fromString(","); -------------- next part -------------- An HTML attachment was scrubbed... URL: From ljiang at openjdk.java.net Wed Jan 20 14:01:48 2021 From: ljiang at openjdk.java.net (Leo Jiang) Date: Wed, 20 Jan 2021 14:01:48 GMT Subject: [jdk16] Integrated: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang wrote: > This is the changes for JDK 16 msg drop 10. This pull request has now been integrated. Changeset: 01205109 Author: Leo Jiang URL: https://git.openjdk.java.net/jdk16/commit/01205109 Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod 8259732: JDK 16 L10n resource file update - msg drop 10 Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk16/pull/123 From jonathan.gibbons at oracle.com Wed Jan 20 14:26:04 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 20 Jan 2021 06:26:04 -0800 Subject: A possible improvement at Tokens and Names In-Reply-To: References: Message-ID: <6ece5e31-96b0-7425-bf89-3d6f63b68607@oracle.com> Hi, I'll create a JBS issue to track this. In itself, that does not imply a review or an endorsement of the idea, but it does provide a place to record the discussion. https://bugs.openjdk.java.net/browse/JDK-8260053 Can you post the patch as a PR? -- Jon On 1/20/21 4:10 AM, Guoxiong Li wrote: > Hi all, > > When I read the code at > `jdk.compiler/com.sun.tools.javac.parser.Tokens` and > ``jdk.compiler/com.sun.tools.javac.util.Names`, I find a point which > can be?possibly improved. > > The constructor of the class `Tokens` invokes > `Names.instance(context)` to initialize `Names` which would initialize > many unrelated names. Then, this constructor uses the method > `enterKeyword` to initialize the names about `TokenKind` and to set > `maxKey`. Because `Names.instance(context)` initializes many unrelated > names, the `Name.index` becomes very large so that the `maxKey` also > becomes very large. Then, the constructor creates an array `key` by > using the code `key =? new TokenKind[maxKey+1]`. We can identify that > the variable `key` is unnecessary to be so large. > > I would like to initialize the related names, which are about > `TokenKind`, at the beginning of the constructor of the class `Names` > to improve the code. The complete patch is shown at the end of this email. > > When using the code of the master branch, the length of the array > `Tokens.key` is 4280. When using my patch,?the length of the array > `Tokens.key` is 383. The improvement is obvious. > > Could I get your help to identify whether this improvement is feasible? > If so, could I get your help to file an issue at the bug tracker? > Thanks a lot. > > > > The patch: > > diff --git > a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > index bd61dcf8ad2..3b4eb5bf4be 100644 > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > @@ -60,7 +60,7 @@ public class Tokens { > > ? ? ?/** The names of all tokens. > ? ? ? */ > - ? ?private Name[] tokenName = new Name[TokenKind.values().length]; > + ? ?private Name[] tokenName; > > ? ? ?public static final Context.Key tokensKey = new > Context.Key<>(); > > @@ -74,11 +74,10 @@ public class Tokens { > ? ? ?protected Tokens(Context context) { > ? ? ? ? ?context.put(tokensKey, this); > ? ? ? ? ?names = Names.instance(context); > - ? ? ? ?for (TokenKind t : TokenKind.values()) { > - ? ? ? ? ? ?if (t.name != null) > - ? ? ? ? ? ? ? ?enterKeyword(t.name , t); > - ? ? ? ? ? ?else > - ? ? ? ? ? ? ? ?tokenName[t.ordinal()] = null; > + ? ? ? ?tokenName = names.tokenName; > + ? ? ? ?for (Name n : tokenName) { > + ? ? ? ? ? ?if (n != null && n.getIndex() > maxKey) > + ? ? ? ? ? ? ? ?maxKey = n.getIndex(); > ? ? ? ? ?} > > ? ? ? ? ?key = new TokenKind[maxKey+1]; > @@ -89,12 +88,6 @@ public class Tokens { > ? ? ? ? ?} > ? ? ?} > > - ? ?private void enterKeyword(String s, TokenKind token) { > - ? ? ? ?Name n = names.fromString(s); > - ? ? ? ?tokenName[token.ordinal()] = n; > - ? ? ? ?if (n.getIndex() > maxKey) maxKey = n.getIndex(); > - ? ?} > - > ? ? ?/** > ? ? ? * Create a new token given a name; if the name corresponds to a > token name, > ? ? ? * a new token of the corresponding kind is returned; otherwise, an > diff --git > a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > index 26e0b7577aa..341817e8ff9 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > @@ -25,6 +25,8 @@ > > ?package com.sun.tools.javac.util; > > +import com.sun.tools.javac.parser.Tokens.TokenKind; > + > ?/** > ? * Access to the compiler's name table.? Standard names are defined, > ? * as well as methods to create new names. > @@ -47,6 +49,9 @@ public class Names { > ? ? ? ? ?return instance; > ? ? ?} > > + ? ?// the names about TokenKind > + ? ?public final Name[] tokenName = new Name[TokenKind.values().length]; > + > ? ? ?// operators and punctuation > ? ? ?public final Name asterisk; > ? ? ?public final Name comma; > @@ -220,6 +225,15 @@ public class Names { > ? ? ? ? ?Options options = Options.instance(context); > ? ? ? ? ?table = createTable(options); > > + ? ? ? ?// set the names about TokenKind > + ? ? ? ?for (TokenKind tokenKind : TokenKind.values()) { > + ? ? ? ? ? ?Name tempName = null; > + ? ? ? ? ? ?if (tokenKind.name != null) { > + ? ? ? ? ? ? ? ?tempName = fromString(tokenKind.name); > + ? ? ? ? ? ?} > + ? ? ? ? ? ?tokenName[tokenKind.ordinal()] = tempName; > + ? ? ? ?} > + > ? ? ? ? ?// operators and punctuation > ? ? ? ? ?asterisk = fromString("*"); > ? ? ? ? ?comma = fromString(","); > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Wed Jan 20 14:37:25 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 20 Jan 2021 09:37:25 -0500 Subject: Intersection and Union Types for Java In-Reply-To: References: Message-ID: <9b25e69d-d7ef-81e6-ef70-5423e86ef6dd@oracle.com> It surely *can*; evidence is here: https://scholarship.rice.edu/handle/1911/103594 The real question (and this is always the case) is whether we should.? As you point out, there is clearly a nonzero benefit. But doing so is a complex endeavor, full of tradeoffs.? Spending the at-least-a-thousand expert-hours on this, means that effort is not available to do something else, whose benefit might be dramatically more.? And we have a limited budget for asking users to absorb new language complexity; this may not be the best place to spend that. So yes, it could, but it's been a deliberate choice not to, because there are other places we can better expend that effort. On 1/20/2021 1:53 AM, Suminda Sirinath Salpitikorala Dharmasena wrote: > Hello, > > Can the Java type system be extended to accommodate?Intersection and > Union Types. > > Currently we can write: > ? void f(T t) { ... } > > but not > > ? void f(T t) { ... } > > or > > ? void f(T t) { ... } > > Also we cannot have > > ? ?void f(A & B t) { ... } > > or > > ? ?void f((A | B) & C t) { ... } > > When considering languages like Ceylon (https://ceylon-lang.org/ > ) and Scala 3 / Dotty > (https://dotty.epfl.ch/ ) these seem to be > very useful. > > Suminda -------------- next part -------------- An HTML attachment was scrubbed... URL: From lgxbslgx at gmail.com Wed Jan 20 17:11:22 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 21 Jan 2021 01:11:22 +0800 Subject: A possible improvement at Tokens and Names In-Reply-To: <6ece5e31-96b0-7425-bf89-3d6f63b68607@oracle.com> References: <6ece5e31-96b0-7425-bf89-3d6f63b68607@oracle.com> Message-ID: Hi Jon, Thank you for your help. I opened a PR at Github just now. Please see https://github.com/openjdk/jdk/pull/2169. Best Regards. On Wed, Jan 20, 2021 at 10:26 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Hi, > > I'll create a JBS issue to track this. In itself, that does not imply a > review or an endorsement of the idea, but it does provide a place to record > the discussion. > https://bugs.openjdk.java.net/browse/JDK-8260053 > > Can you post the patch as a PR? > > -- Jon > On 1/20/21 4:10 AM, Guoxiong Li wrote: > > Hi all, > > When I read the code at `jdk.compiler/com.sun.tools.javac.parser.Tokens` > and ``jdk.compiler/com.sun.tools.javac.util.Names`, I find a point which > can be possibly improved. > > The constructor of the class `Tokens` invokes `Names.instance(context)` to > initialize `Names` which would initialize many unrelated names. Then, this > constructor uses the method `enterKeyword` to initialize the names about > `TokenKind` and to set `maxKey`. Because `Names.instance(context)` > initializes many unrelated names, the `Name.index` becomes very large so > that the `maxKey` also becomes very large. Then, the constructor creates an > array `key` by using the code `key = new TokenKind[maxKey+1]`. We can > identify that the variable `key` is unnecessary to be so large. > > I would like to initialize the related names, which are about `TokenKind`, > at the beginning of the constructor of the class `Names` to improve the > code. The complete patch is shown at the end of this email. > > When using the code of the master branch, the length of the array > `Tokens.key` is 4280. When using my patch, the length of the array > `Tokens.key` is 383. The improvement is obvious. > > Could I get your help to identify whether this improvement is feasible? > If so, could I get your help to file an issue at the bug tracker? Thanks a > lot. > > > > The patch: > > diff --git > a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > index bd61dcf8ad2..3b4eb5bf4be 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java > @@ -60,7 +60,7 @@ public class Tokens { > > /** The names of all tokens. > */ > - private Name[] tokenName = new Name[TokenKind.values().length]; > + private Name[] tokenName; > > public static final Context.Key tokensKey = new > Context.Key<>(); > > @@ -74,11 +74,10 @@ public class Tokens { > protected Tokens(Context context) { > context.put(tokensKey, this); > names = Names.instance(context); > - for (TokenKind t : TokenKind.values()) { > - if (t.name != null) > - enterKeyword(t.name, t); > - else > - tokenName[t.ordinal()] = null; > + tokenName = names.tokenName; > + for (Name n : tokenName) { > + if (n != null && n.getIndex() > maxKey) > + maxKey = n.getIndex(); > } > > key = new TokenKind[maxKey+1]; > @@ -89,12 +88,6 @@ public class Tokens { > } > } > > - private void enterKeyword(String s, TokenKind token) { > - Name n = names.fromString(s); > - tokenName[token.ordinal()] = n; > - if (n.getIndex() > maxKey) maxKey = n.getIndex(); > - } > - > /** > * Create a new token given a name; if the name corresponds to a > token name, > * a new token of the corresponding kind is returned; otherwise, an > diff --git > a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > index 26e0b7577aa..341817e8ff9 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java > @@ -25,6 +25,8 @@ > > package com.sun.tools.javac.util; > > +import com.sun.tools.javac.parser.Tokens.TokenKind; > + > /** > * Access to the compiler's name table. Standard names are defined, > * as well as methods to create new names. > @@ -47,6 +49,9 @@ public class Names { > return instance; > } > > + // the names about TokenKind > + public final Name[] tokenName = new Name[TokenKind.values().length]; > + > // operators and punctuation > public final Name asterisk; > public final Name comma; > @@ -220,6 +225,15 @@ public class Names { > Options options = Options.instance(context); > table = createTable(options); > > + // set the names about TokenKind > + for (TokenKind tokenKind : TokenKind.values()) { > + Name tempName = null; > + if (tokenKind.name != null) { > + tempName = fromString(tokenKind.name); > + } > + tokenName[tokenKind.ordinal()] = tempName; > + } > + > // operators and punctuation > asterisk = fromString("*"); > comma = fromString(","); > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+13688759+lgxbslgx at openjdk.java.net Wed Jan 20 17:13:02 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 20 Jan 2021 17:13:02 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names Message-ID: Hi all, This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8260053: Optimize Tokens' use of Names Changes: https://git.openjdk.java.net/jdk/pull/2169/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2169&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260053 Stats: 27 lines in 2 files changed: 14 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2169/head:pull/2169 PR: https://git.openjdk.java.net/jdk/pull/2169 From jjg at openjdk.java.net Wed Jan 20 18:25:54 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 20 Jan 2021 18:25:54 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 17:07:26 GMT, Guoxiong Li wrote: > Hi all, > > This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. > > The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). > > Thank you for taking the time to review. > > Best Regards. src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java line 29: > 27: > 28: import com.sun.tools.javac.parser.Tokens.TokenKind; > 29: I realize why you need this, but this is a questionable import from an architectural point of view. Spaghetti imports can be a problem, and the intent has been that `utils` is a collection of low-level utility classes, and the parser is a layer built on top of that: here, you are adding a reverse dependence, so that a class in `utils` depends on a class in `parser`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From maurizio.cimadamore at oracle.com Wed Jan 20 18:54:27 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 Jan 2021 18:54:27 +0000 Subject: RFR: 8260053: Optimize Tokens' use of Names In-Reply-To: References: Message-ID: <37f28a42-122a-fb04-9412-f49ad3e0f719@oracle.com> On 20/01/2021 18:25, Jonathan Gibbons wrote: > I realize why you need this, but this is a questionable import from an architectural point of view. Spaghetti imports can be a problem, and the intent has been that `utils` is a collection of low-level utility classes, and the parser is a layer built on top of that: here, you are adding a reverse dependence, so that a class in `utils` depends on a class in `parser`. I tend to agree with Jon here. While it's clear what the intent is, creating an explicit coupling between Names (which is the global holder for all compiler names) and Tokens, by adding a coupling from the former to the latter, is smelly. What you want, in principle, is to setup some kind of map in TokenKind, so that, for each name, you know which token (if any) corresponds to that. What javac does right now is sub-optimal memory-wise (an array is created of which many buckets will be empty), but very efficient performance-wise (a lookup is just an array access). Additional note: in all cases I could find, this lookup will take place from a Java String. Which means the following sequence takes place: 1. lookup from String to Name (names.fromString(String)) 2. lookup from Name to Token I wouldn't be surprised if replacing this infrastructure with a Map on Tokens will lead to similar performances to those we have now (but better memory utilization). E.g. we have to do a "slow" lookup anyway before being able to do the fast lookup. Maurizio From sirinath1978m at gmail.com Thu Jan 21 04:32:56 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Thu, 21 Jan 2021 10:02:56 +0530 Subject: Intersection and Union Types for Java In-Reply-To: <9b25e69d-d7ef-81e6-ef70-5423e86ef6dd@oracle.com> References: <9b25e69d-d7ef-81e6-ef70-5423e86ef6dd@oracle.com> Message-ID: Maybe this can be given to a university as a research project. Perhaps Rice? When they come up with something tangible it can be added to Java. May not cost as much as doing it in house. On Wed, 20 Jan 2021 at 20:07, Brian Goetz wrote: > It surely *can*; evidence is here: > https://scholarship.rice.edu/handle/1911/103594 > > The real question (and this is always the case) is whether we should. As > you point out, there is clearly a nonzero benefit. But doing so is a > complex endeavor, full of tradeoffs. Spending the at-least-a-thousand > expert-hours on this, means that effort is not available to do something > else, whose benefit might be dramatically more. And we have a limited > budget for asking users to absorb new language complexity; this may not be > the best place to spend that. > > So yes, it could, but it's been a deliberate choice not to, because there > are other places we can better expend that effort. > > On 1/20/2021 1:53 AM, Suminda Sirinath Salpitikorala Dharmasena wrote: > > Hello, > > Can the Java type system be extended to accommodate Intersection and Union > Types. > > Currently we can write: > void f(T t) { ... } > > but not > > void f(T t) { ... } > > or > > void f(T t) { ... } > > Also we cannot have > > void f(A & B t) { ... } > > or > > void f((A | B) & C t) { ... } > > When considering languages like Ceylon (https://ceylon-lang.org/) and > Scala 3 / Dotty (https://dotty.epfl.ch/) these seem to be very useful. > > Suminda > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilhelm at openjdk.java.net Thu Jan 21 04:41:15 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 21 Jan 2021 04:41:15 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259757: add a regression test for 8259353 and 8259601 - 8259732: JDK 16 L10n resource file update - msg drop 10 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2176/files Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/2176.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2176/head:pull/2176 PR: https://git.openjdk.java.net/jdk/pull/2176 From jwilhelm at openjdk.java.net Thu Jan 21 05:26:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 21 Jan 2021 05:26:59 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <9sHQ5RFKu7eMA2dnKWQ9ZWXPzT_HnSJdXDZ2j4kX8to=.69bf5258-7371-4404-a1af-b54febf7cad7@github.com> On Thu, 21 Jan 2021 04:33:47 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 133bcb09 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/133bcb09 Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2176 From forax at univ-mlv.fr Thu Jan 21 08:32:24 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 21 Jan 2021 09:32:24 +0100 (CET) Subject: Can not call a private method, no idea why ? Message-ID: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> The following code doesn't compile. No idea why ? public interface IOBug { private IOBug foo() { return this; } default IOBug flatMap(Function map) { return map.apply(null).foo(); ^------ } } It works if foo is declared as a default method instead of a private method. regards, R?mi From anna.kozlova at jetbrains.com Thu Jan 21 10:53:18 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Thu, 21 Jan 2021 11:53:18 +0100 Subject: Can not call a private method, no idea why ? In-Reply-To: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, type of `map.apply(null)` is capture of `? extends IOBug` and thus it has no access to private methods of IOBug. Do I miss something? Thanks, Anna On Thu, Jan 21, 2021 at 9:34 AM Remi Forax wrote: > The following code doesn't compile. > No idea why ? > > public interface IOBug { > private IOBug foo() { > return this; > } > > default IOBug flatMap(Function map) { > return map.apply(null).foo(); > ^------ > } > } > > It works if foo is declared as a default method instead of a private > method. > > regards, > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Jan 21 10:59:13 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 21 Jan 2021 11:59:13 +0100 (CET) Subject: Can not call a private method, no idea why ? In-Reply-To: References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> Message-ID: <600928849.507233.1611226753282.JavaMail.zimbra@u-pem.fr> > De: "Anna Kozlova" > ?: "Remi Forax" > Cc: "compiler-dev" > Envoy?: Jeudi 21 Janvier 2021 11:53:18 > Objet: Re: Can not call a private method, no idea why ? > Hi Remi, > type of `map.apply(null)` is capture of `? extends IOBug` and thus it has no > access to private methods of IOBug. Do I miss something? Why the type (? extends IOBug) and not the corresponding class, the erasure (IOBug) is used here to check the method access ? > Thanks, > Anna regards, R?mi > On Thu, Jan 21, 2021 at 9:34 AM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> The following code doesn't compile. >> No idea why ? >> public interface IOBug { >> private IOBug foo() { >> return this; >> } >> default IOBug flatMap(Function map) { >> return map.apply(null).foo(); >> ^------ >> } >> } >> It works if foo is declared as a default method instead of a private method. >> regards, >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jan 21 11:20:20 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 Jan 2021 11:20:20 +0000 Subject: Can not call a private method, no idea why ? In-Reply-To: References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> Message-ID: I agree with this analysis. This has nothing to do with default methods, and interfaces in general: $ cat Test.java import java.util.function.Function; class Test { ? private void greet() { System.out.println("hello"); } ? void test(Function f) { ??? f.apply(null).greet(); ? } } This still fails. As Anna points out, the function returns `? extends Test`, so the compiler cannot assume that what will be returned by the function will be "exactly" a Test. If it's a subclass, then the method will be inaccessible, even for the VM. Maurizio On 21/01/2021 10:53, Anna Kozlova wrote: > Hi Remi, > > type of ?`map.apply(null)` is capture of `? extends IOBug` and thus it > has no access to private methods of IOBug. Do I miss something? > > Thanks, > Anna > > On Thu, Jan 21, 2021 at 9:34 AM Remi Forax > wrote: > > The following code doesn't compile. > No idea why ? > > public interface IOBug { > ? private IOBug foo() { > ? ? return this; > ? } > > ? default IOBug flatMap(Function > map) { > ? ? return map.apply(null).foo(); > ? ? ? ? ? ? ? ? ? ? ? ? ? ?^------ > ? } > } > > It works if foo is declared as a default method instead of a > private method. > > regards, > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 21 11:23:49 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Jan 2021 11:23:49 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names In-Reply-To: References: Message-ID: <7BAaLq7iC5pczHy03x1zE5Knq9jjijIuMRd1HYtZiKk=.94db9b44-22e7-4a2e-9e39-77e393484306@github.com> On Wed, 20 Jan 2021 17:07:26 GMT, Guoxiong Li wrote: > Hi all, > > This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. > > The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). > > Thank you for taking the time to review. > > Best Regards. Thanks for your comments. My patch mainly focused on using less memory without causing performance degradation. But I lacked consideration about the architecture which is also important. I agree with you that the utility classes should not dependent on other classes. Using `Map` instead of `TokenKind[]` looks like a good idea. It reduces the memory and doesn't revise the class `Names`. But the more important aspect is that it can't cause performance regression. I will do some benchmark test by using `Map` locally to observe the performance and will share the result with you. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From forax at univ-mlv.fr Thu Jan 21 11:48:19 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 21 Jan 2021 12:48:19 +0100 (CET) Subject: Can not call a private method, no idea why ? In-Reply-To: References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> Message-ID: <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> > De: "Maurizio Cimadamore" > ?: "Anna Kozlova" , "Remi Forax" > Cc: "compiler-dev" > Envoy?: Jeudi 21 Janvier 2021 12:20:20 > Objet: Re: Can not call a private method, no idea why ? > I agree with this analysis. This has nothing to do with default methods, and > interfaces in general: > $ cat Test.java > import java.util.function.Function; > class Test { > private void greet() { System.out.println("hello"); } > void test(Function f) { > f.apply(null).greet(); > } > } > This still fails. As Anna points out, the function returns `? extends Test`, so > the compiler cannot assume that what will be returned by the function will be > "exactly" a Test. If it's a subclass, then the method will be inaccessible, > even for the VM. If you have a classical method, like the one below, test can also be a subclass, still you can access to the private method void test(Test test) { test.greet(); } Here, because Function is a parametrized type, you need a wildcard to have subtyping, so in both cases you have subtyping, but the compiler doesn't behave the same way. > Maurizio R?mi > On 21/01/2021 10:53, Anna Kozlova wrote: >> Hi Remi, >> type of `map.apply(null)` is capture of `? extends IOBug` and thus it has no >> access to private methods of IOBug. Do I miss something? >> Thanks, >> Anna >> On Thu, Jan 21, 2021 at 9:34 AM Remi Forax < [ mailto:forax at univ-mlv.fr | >> forax at univ-mlv.fr ] > wrote: >>> The following code doesn't compile. >>> No idea why ? >>> public interface IOBug { >>> private IOBug foo() { >>> return this; >>> } >>> default IOBug flatMap(Function map) { >>> return map.apply(null).foo(); >>> ^------ >>> } >>> } >>> It works if foo is declared as a default method instead of a private method. >>> regards, >>> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jan 21 12:18:32 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 Jan 2021 12:18:32 +0000 Subject: [External] : Re: Can not call a private method, no idea why ? In-Reply-To: <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> Message-ID: <2fcd16d3-5ee5-9971-3865-f23975fc3a73@oracle.com> On 21/01/2021 11:48, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *De: *"Maurizio Cimadamore" > *?: *"Anna Kozlova" , "Remi Forax" > > *Cc: *"compiler-dev" > *Envoy?: *Jeudi 21 Janvier 2021 12:20:20 > *Objet: *Re: Can not call a private method, no idea why ? > > I agree with this analysis. This has nothing to do with default > methods, and interfaces in general: > > $ cat Test.java > import java.util.function.Function; > > class Test { > ? private void greet() { System.out.println("hello"); } > > ? void test(Function f) { > ??? f.apply(null).greet(); > ? } > } > > This still fails. As Anna points out, the function returns `? > extends Test`, so the compiler cannot assume that what will be > returned by the function will be "exactly" a Test. If it's a > subclass, then the method will be inaccessible, even for the VM. > > > If you have a classical method, like the one below, test can also be a > subclass, still you can access to the private method > ? void test(Test test) { > ??? test.greet(); > ? } > > Here, because Function is a parametrized type, you need a wildcard to > have subtyping, so in both cases you have subtyping, > but the compiler doesn't behave the same way. I don't believe that's the right analogy; this is: ``` import java.util.function.Function; class Test { ? private void greet() { System.out.println("hello"); } ? void test(X x) { ??? x.greet(); ? } } ``` Which also fails, no wildcards around this time. When you access a member on a `? extends T` you get back a captured variable, which is a fresh type variable with some bounds. As per JLS 4.4 the members of a type variable X extends A & I1 ... In are the members of the intersection type (A, I1 .. In). In the definition of intersection type in JLS 4.9 you will see that only public members are allowed. This decision comes from the fact that type-variables have a "for all" spirit to them - when you write something like x.e, and x is of type X (with X a type variable) the intent of the language is for x.e to either be valid _for all_ instantiations of X, or to be rejected. Without this rule, it would be very easy to write a generic class which can be instantiated in ways that make it break some (runtime) assumptions. Maurizio > > > Maurizio > > > R?mi > > > On 21/01/2021 10:53, Anna Kozlova wrote: > > Hi Remi, > > type of ?`map.apply(null)` is capture of `? extends IOBug` and > thus it has no access to private methods of IOBug. Do I miss > something? > > Thanks, > Anna > > On Thu, Jan 21, 2021 at 9:34 AM Remi Forax > wrote: > > The following code doesn't compile. > No idea why ? > > public interface IOBug { > ? private IOBug foo() { > ? ? return this; > ? } > > ? default IOBug flatMap(Function IOBug> map) { > ? ? return map.apply(null).foo(); > ? ? ? ? ? ? ? ? ? ? ? ? ? ?^------ > ? } > } > > It works if foo is declared as a default method instead of > a private method. > > regards, > R?mi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Jan 21 12:40:40 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 21 Jan 2021 13:40:40 +0100 (CET) Subject: [External] : Re: Can not call a private method, no idea why ? In-Reply-To: <2fcd16d3-5ee5-9971-3865-f23975fc3a73@oracle.com> References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> <2fcd16d3-5ee5-9971-3865-f23975fc3a73@oracle.com> Message-ID: <333975252.621457.1611232840148.JavaMail.zimbra@u-pem.fr> > De: "Maurizio Cimadamore" > ?: "Remi Forax" > Cc: "Anna Kozlova" , "compiler-dev" > > Envoy?: Jeudi 21 Janvier 2021 13:18:32 > Objet: Re: [External] : Re: Can not call a private method, no idea why ? > On 21/01/2021 11:48, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >>> De: "Maurizio Cimadamore" [ mailto:maurizio.cimadamore at oracle.com | >>> ] >>> ?: "Anna Kozlova" [ mailto:anna.kozlova at jetbrains.com | >>> ] , "Remi Forax" [ mailto:forax at univ-mlv.fr | >>> ] >>> Cc: "compiler-dev" [ mailto:compiler-dev at openjdk.java.net | >>> ] >>> Envoy?: Jeudi 21 Janvier 2021 12:20:20 >>> Objet: Re: Can not call a private method, no idea why ? >>> I agree with this analysis. This has nothing to do with default methods, and >>> interfaces in general: >>> $ cat Test.java >>> import java.util.function.Function; >>> class Test { >>> private void greet() { System.out.println("hello"); } >>> void test(Function f) { >>> f.apply(null).greet(); >>> } >>> } >>> This still fails. As Anna points out, the function returns `? extends Test`, so >>> the compiler cannot assume that what will be returned by the function will be >>> "exactly" a Test. If it's a subclass, then the method will be inaccessible, >>> even for the VM. >> If you have a classical method, like the one below, test can also be a subclass, >> still you can access to the private method >> void test(Test test) { >> test.greet(); >> } >> Here, because Function is a parametrized type, you need a wildcard to have >> subtyping, so in both cases you have subtyping, >> but the compiler doesn't behave the same way. > I don't believe that's the right analogy; this is: > ``` > import java.util.function.Function; > class Test { > private void greet() { System.out.println("hello"); } > void test(X x) { > x.greet(); > } > } > ``` > Which also fails, no wildcards around this time. > When you access a member on a `? extends T` you get back a captured variable, > which is a fresh type variable with some bounds. As per JLS 4.4 the members of > a type variable X extends A & I1 ... In are the members of the intersection > type (A, I1 .. In). In the definition of intersection type in JLS 4.9 you will > see that only public members are allowed. > This decision comes from the fact that type-variables have a "for all" spirit to > them - when you write something like x.e, and x is of type X (with X a type > variable) the intent of the language is for x.e to either be valid _for all_ > instantiations of X, or to be rejected. Without this rule, it would be very > easy to write a generic class which can be instantiated in ways that make it > break some (runtime) assumptions. Given that private method are not dynamically linked, i don't see how this is issue at runtime. Back to the first example, if you introduce a 'var' in the middle, it will compile class Test { private void greet() { System.out.println("hello"); } void test(Function f) { f.apply(null).greet(); // nope var t = f.apply(null); t.greet(); // yes ! } } so i don't think itcan break some runtime assumptions. > Maurizio R?mi >>> Maurizio >> R?mi >>> On 21/01/2021 10:53, Anna Kozlova wrote: >>>> Hi Remi, >>>> type of `map.apply(null)` is capture of `? extends IOBug` and thus it has no >>>> access to private methods of IOBug. Do I miss something? >>>> Thanks, >>>> Anna >>>> On Thu, Jan 21, 2021 at 9:34 AM Remi Forax < [ mailto:forax at univ-mlv.fr | >>>> forax at univ-mlv.fr ] > wrote: >>>>> The following code doesn't compile. >>>>> No idea why ? >>>>> public interface IOBug { >>>>> private IOBug foo() { >>>>> return this; >>>>> } >>>>> default IOBug flatMap(Function map) { >>>>> return map.apply(null).foo(); >>>>> ^------ >>>>> } >>>>> } >>>>> It works if foo is declared as a default method instead of a private method. >>>>> regards, >>>>> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jan 21 13:03:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 Jan 2021 13:03:50 +0000 Subject: [External] : Re: Can not call a private method, no idea why ? In-Reply-To: <333975252.621457.1611232840148.JavaMail.zimbra@u-pem.fr> References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> <2fcd16d3-5ee5-9971-3865-f23975fc3a73@oracle.com> <333975252.621457.1611232840148.JavaMail.zimbra@u-pem.fr> Message-ID: <8bfbfe47-e41c-cd62-2e02-fdf708402af7@oracle.com> > I don't believe that's the right analogy; this is: > > ``` > import java.util.function.Function; > > class Test { > ? private void greet() { System.out.println("hello"); } > > ? void test(X x) { > ??? x.greet(); > ? } > } > ``` > > Which also fails, no wildcards around this time. > > When you access a member on a `? extends T` you get back a > captured variable, which is a fresh type variable with some > bounds. As per JLS 4.4 the members of a type variable X extends A > & I1 ... In are the members of the intersection type (A, I1 .. > In). In the definition of intersection type in JLS 4.9 you will > see that only public members are allowed. > > This decision comes from the fact that type-variables have a "for > all" spirit to them - when you write something like x.e, and x is > of type X (with X a type variable) the intent of the language is > for x.e to either be valid _for all_ instantiations of X, or to be > rejected. Without this rule, it would be very easy to write a > generic class which can be instantiated in ways that make it break > some (runtime) assumptions. > > > Given that private method are not dynamically linked, i don't see how > this is issue at runtime. > > Back to the first example, if you introduce a 'var' in the middle, it > will compile > > class Test { > ? private void greet() { System.out.println("hello"); } > > ? void test(Function f) { > ??? f.apply(null).greet();? // nope > ??? var t = f.apply(null); > ??? t.greet();?????????????????? // yes ! > ? } > } > > so i don't think itcan break some runtime assumptions. I think your example is subtly misleading - you are using `var` and `var` has special normalization for avoiding captured variables - which means that accessing apply(null).greet() and t.greet() have completely different static types. To back off form this specific example, think of this: public class Box { ?? X x; ?? Box(X x) { this.x = x; } ?? void m() { ?????? x. ??? ?? } } What are the valid member access for "x" ? Say that Box and Foo are in the same package - can I access all members of "Foo" ? Note that this Box class can be used from a completely different package, so there will be runtime issues if we bake in assumptions on which members can be accessed from the type variable. In other words - if Box is a well-formed type, I want a guarantee that no bad stuff can happen at runtime (yes, there can be unchecked casts and all that - but let's assume that all the code compiled w/o warnings). And if you allow access to anything other than public members you have no such guarantee. I sympathize with your argument: at the end of the day, when you have X <: Foo, you can always widen (e.g. assign) X to Foo (w/o warnings) and take it from there, and all restrictions are gone - so maybe this is excessive hand-holding on the language-side - but I was trying to explain the rationale behind the rules - it is pretty common when dealing with parametric polymorphism to think of membership of a type-variable X in a "for all" semantics - e.g. the intersection of members that are available in all instantiations of X; so, for the language (and the compiler) X <: Foo and Foo are two very different types, with very different membership rules. Maurizio > > Maurizio > > > R?mi > > > > > > Maurizio > > > R?mi > > > On 21/01/2021 10:53, Anna Kozlova wrote: > > Hi Remi, > > type of ?`map.apply(null)` is capture of `? extends > IOBug` and thus it has no access to private methods of > IOBug. Do I miss something? > > Thanks, > Anna > > On Thu, Jan 21, 2021 at 9:34 AM Remi Forax > > wrote: > > The following code doesn't compile. > No idea why ? > > public interface IOBug { > ? private IOBug foo() { > ? ? return this; > ? } > > ? default IOBug flatMap(Function extends IOBug> map) { > ? ? return map.apply(null).foo(); > ? ? ? ? ? ? ? ? ? ? ? ? ? ?^------ > ? } > } > > It works if foo is declared as a default method > instead of a private method. > > regards, > R?mi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jan 21 13:11:57 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 Jan 2021 13:11:57 +0000 Subject: [External] : Re: Can not call a private method, no idea why ? In-Reply-To: <8bfbfe47-e41c-cd62-2e02-fdf708402af7@oracle.com> References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> <2fcd16d3-5ee5-9971-3865-f23975fc3a73@oracle.com> <333975252.621457.1611232840148.JavaMail.zimbra@u-pem.fr> <8bfbfe47-e41c-cd62-2e02-fdf708402af7@oracle.com> Message-ID: <85cb267f-ec01-fcfa-900d-338fbb5b6d21@oracle.com> Some further history - this was tweaked several years ago in 7: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6246814 There's also an open RFE on the spec: https://bugs.openjdk.java.net/browse/JDK-6644562 Which basically refers to what we have discussed - e.g. the type system rules being too conservative and applying intersection type semantics even if there's only one bound. Maurizio On 21/01/2021 13:03, Maurizio Cimadamore wrote: > I sympathize with your argument: at the end of the day, when you have > X <: Foo, you can always widen (e.g. assign) X to Foo (w/o warnings) > and take it from there, and all restrictions are gone - so maybe this > is excessive hand-holding on the language-side - but I was trying to > explain the rationale behind the rules - it is pretty common when > dealing with parametric polymorphism to think of membership of a > type-variable X in a "for all" semantics - e.g. the intersection of > members that are available in all instantiations of X; so, for the > language (and the compiler) X <: Foo and Foo are two very different > types, with very different membership rules. From forax at univ-mlv.fr Thu Jan 21 14:29:01 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 21 Jan 2021 15:29:01 +0100 (CET) Subject: [External] : Re: Can not call a private method, no idea why ? In-Reply-To: <8bfbfe47-e41c-cd62-2e02-fdf708402af7@oracle.com> References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> <2fcd16d3-5ee5-9971-3865-f23975fc3a73@oracle.com> <333975252.621457.1611232840148.JavaMail.zimbra@u-pem.fr> <8bfbfe47-e41c-cd62-2e02-fdf708402af7@oracle.com> Message-ID: <1065715180.739340.1611239341263.JavaMail.zimbra@u-pem.fr> > De: "Maurizio Cimadamore" > ?: "Remi Forax" > Cc: "Anna Kozlova" , "compiler-dev" > > Envoy?: Jeudi 21 Janvier 2021 14:03:50 > Objet: Re: [External] : Re: Can not call a private method, no idea why ? >>> I don't believe that's the right analogy; this is: >>> ``` >>> import java.util.function.Function; >>> class Test { >>> private void greet() { System.out.println("hello"); } >>> void test(X x) { >>> x.greet(); >>> } >>> } >>> ``` >>> Which also fails, no wildcards around this time. >>> When you access a member on a `? extends T` you get back a captured variable, >>> which is a fresh type variable with some bounds. As per JLS 4.4 the members of >>> a type variable X extends A & I1 ... In are the members of the intersection >>> type (A, I1 .. In). In the definition of intersection type in JLS 4.9 you will >>> see that only public members are allowed. >>> This decision comes from the fact that type-variables have a "for all" spirit to >>> them - when you write something like x.e, and x is of type X (with X a type >>> variable) the intent of the language is for x.e to either be valid _for all_ >>> instantiations of X, or to be rejected. Without this rule, it would be very >>> easy to write a generic class which can be instantiated in ways that make it >>> break some (runtime) assumptions. >> Given that private method are not dynamically linked, i don't see how this is >> issue at runtime. >> Back to the first example, if you introduce a 'var' in the middle, it will >> compile >> class Test { >> private void greet() { System.out.println("hello"); } >> void test(Function f) { >> f.apply(null).greet(); // nope >> var t = f.apply(null); >> t.greet(); // yes ! >> } >> } >> so i don't think itcan break some runtime assumptions. > I think your example is subtly misleading - you are using `var` and `var` has > special normalization for avoiding captured variables - which means that > accessing apply(null).greet() and t.greet() have completely different static > types. yes, my example just shows that you will not get an exception at runtime. Not that both codes are equivalent in term of types, there are only equivalent at runtime. > To back off form this specific example, think of this: > public class Box { > X x; > Box(X x) { this.x = x; } > void m() { > x. ??? > } > } > What are the valid member access for "x" ? > Say that Box and Foo are in the same package - can I access all members of "Foo" > ? Note that this Box class can be used from a completely different package, so > there will be runtime issues if we bake in assumptions on which members can be > accessed from the type variable. This is a different question, in the first code, the greet() was private. To answer to your question all members of Foo that are visibles from Box. > In other words - if Box is a well-formed type, I want a guarantee that no bad > stuff can happen at runtime (yes, there can be unchecked casts and all that - > but let's assume that all the code compiled w/o warnings). And if you allow > access to anything other than public members you have no such guarantee. > I sympathize with your argument: at the end of the day, when you have X <: Foo, > you can always widen (e.g. assign) X to Foo (w/o warnings) and take it from > there, and all restrictions are gone - so maybe this is excessive hand-holding > on the language-side - but I was trying to explain the rationale behind the > rules - it is pretty common when dealing with parametric polymorphism to think > of membership of a type-variable X in a "for all" semantics - e.g. the > intersection of members that are available in all instantiations of X; so, for > the language (and the compiler) X <: Foo and Foo are two very different types, > with very different membership rules. as i said, you can use the same "for all" argument for subtyping too, like Ruby does, where you can only access to the private members from this. > Maurizio R?mi >>> Maurizio >> R?mi >>>>> Maurizio >>>> R?mi >>>>> On 21/01/2021 10:53, Anna Kozlova wrote: >>>>>> Hi Remi, >>>>>> type of `map.apply(null)` is capture of `? extends IOBug` and thus it has no >>>>>> access to private methods of IOBug. Do I miss something? >>>>>> Thanks, >>>>>> Anna >>>>>> On Thu, Jan 21, 2021 at 9:34 AM Remi Forax < [ mailto:forax at univ-mlv.fr | >>>>>> forax at univ-mlv.fr ] > wrote: >>>>>>> The following code doesn't compile. >>>>>>> No idea why ? >>>>>>> public interface IOBug { >>>>>>> private IOBug foo() { >>>>>>> return this; >>>>>>> } >>>>>>> default IOBug flatMap(Function map) { >>>>>>> return map.apply(null).foo(); >>>>>>> ^------ >>>>>>> } >>>>>>> } >>>>>>> It works if foo is declared as a default method instead of a private method. >>>>>>> regards, >>>>>>> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Jan 21 14:30:41 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 21 Jan 2021 15:30:41 +0100 (CET) Subject: [External] : Re: Can not call a private method, no idea why ? In-Reply-To: <85cb267f-ec01-fcfa-900d-338fbb5b6d21@oracle.com> References: <1014311327.313230.1611217944094.JavaMail.zimbra@u-pem.fr> <2090004153.561171.1611229699536.JavaMail.zimbra@u-pem.fr> <2fcd16d3-5ee5-9971-3865-f23975fc3a73@oracle.com> <333975252.621457.1611232840148.JavaMail.zimbra@u-pem.fr> <8bfbfe47-e41c-cd62-2e02-fdf708402af7@oracle.com> <85cb267f-ec01-fcfa-900d-338fbb5b6d21@oracle.com> Message-ID: <1644068646.742305.1611239441833.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Remi Forax" > Cc: "Anna Kozlova" , "compiler-dev" > Envoy?: Jeudi 21 Janvier 2021 14:11:57 > Objet: Re: [External] : Re: Can not call a private method, no idea why ? > Some further history - this was tweaked several years ago in 7: > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6246814 > > There's also an open RFE on the spec: > > https://bugs.openjdk.java.net/browse/JDK-6644562 > > Which basically refers to what we have discussed - e.g. the type system > rules being too conservative and applying intersection type semantics > even if there's only one bound. yes, thanks. > > Maurizio R?mi > > > On 21/01/2021 13:03, Maurizio Cimadamore wrote: >> I sympathize with your argument: at the end of the day, when you have >> X <: Foo, you can always widen (e.g. assign) X to Foo (w/o warnings) >> and take it from there, and all restrictions are gone - so maybe this >> is excessive hand-holding on the language-side - but I was trying to >> explain the rationale behind the rules - it is pretty common when >> dealing with parametric polymorphism to think of membership of a >> type-variable X in a "for all" semantics - e.g. the intersection of >> members that are available in all instantiations of X; so, for the >> language (and the compiler) X <: Foo and Foo are two very different > > types, with very different membership rules. From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 21 18:26:50 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Jan 2021 18:26:50 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. > > The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). > > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Use Map ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2169/files - new: https://git.openjdk.java.net/jdk/pull/2169/files/5470a4ee..5bbf949f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2169&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2169&range=00-01 Stats: 47 lines in 2 files changed: 6 ins; 35 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2169/head:pull/2169 PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 21 18:44:56 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Jan 2021 18:44:56 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names In-Reply-To: <7BAaLq7iC5pczHy03x1zE5Knq9jjijIuMRd1HYtZiKk=.94db9b44-22e7-4a2e-9e39-77e393484306@github.com> References: <7BAaLq7iC5pczHy03x1zE5Knq9jjijIuMRd1HYtZiKk=.94db9b44-22e7-4a2e-9e39-77e393484306@github.com> Message-ID: On Thu, 21 Jan 2021 11:21:21 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. >> >> The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). >> >> Thank you for taking the time to review. >> >> Best Regards. > > Thanks for your comments. > > My patch mainly focused on using less memory without causing performance degradation. But I lacked consideration about the architecture which is also important. I agree with you that the utility classes should not dependent on other classes. > > Using `Map` instead of `TokenKind[]` looks like a good idea. It reduces the memory and doesn't revise the class `Names`. But the more important aspect is that it can't cause performance regression. I will do some benchmark test by using `Map` locally to observe the performance and will share the result with you. I updated the code by using `Map`. And I found the related benchmark is already at [jmh-jdk-microbenchmarks](https://github.com/openjdk/jmh-jdk-microbenchmarks). When I built the code of this `jmh-jdk-microbenchmarks` project locally, I could not get the result over 5 hours which made me give up. The build output is shown below. Many `......` are at the end of the output which I don't paste it here. [INFO] Scanning for projects... [INFO] [INFO] ----------------------< org.openjdk:micros-javac >---------------------- [INFO] Building OpenJDK Microbenchmark of Java Compile 1.0-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ micros-javac --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /home/lgx/source/java/jmh-jdk-microbenchmarks/micros-javac/src/main/resources [INFO] [INFO] --- maven-antrun-plugin:1.8:run (default) @ micros-javac --- [INFO] Executing tasks main: [mkdir] Created dir: /home/lgx/source/java/jmh-jdk-microbenchmarks/micros-javac/target/classes [get] Getting: https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_windows-x64_bin.zip [get] To: /home/lgx/source/java/jmh-jdk-microbenchmarks/micros-javac/target/jdk-bin.zip .............................................................................................................. // many ...... Could I get your help to try to build and run the benchmark locally? Or could the JMH team help to run the test? Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From mcimadamore at openjdk.java.net Thu Jan 21 18:49:34 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 21 Jan 2021 18:49:34 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: Message-ID: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> On Thu, 21 Jan 2021 18:26:50 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. >> >> The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). >> >> Thank you for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Use Map Looks great - and much simpler. Have you tried running some benchmark? If you are not familiar with JMH, another way to quickly (and unofficially :-) benchmark javac is typically trying to clean/build the JDK before/after the change and see if there's an impact. Since this change affects tokenization, if there's a regression you should be able to see it. If you are familiar with JMH, and alternative would be to setup a compilation task using the compiler API, and then just parse some files. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 21 18:55:31 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Jan 2021 18:55:31 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v3] In-Reply-To: References: Message-ID: > Hi all, > > The statement `String sourcePath = file.getName();` in method `prepareBCP(Path target)` would use `DirectoryFileObject::getName` which is shown below. > > @Override @DefinedBy(Api.COMPILER) > public String getName() { > return relativePath.resolveAgainst(userPackageRootDir).toString(); // <----------------- > } > > And the `DirectoryFileObject::getName` would use `RelativePath::resolveAgainst` which is shown below > > public Path resolveAgainst(Path directory) throws /*unchecked*/ InvalidPathException { > String sep = directory.getFileSystem().getSeparator(); // <--------------------- > return directory.resolve(path.replace("/", sep)); > } > > We can see that `RelativePath::resolveAgainst` use file system separator instead of operating system separator. In method `prepareBCP`, the file system should be JRT file system, but we don't need to know actually which file system to be used. We only need to use the same file system separator so that the test can run as expected. > > This patch fixes the test by using the file system separator instead of operating system separator. > > Thank you for taking the time to review. > > Best Regards. Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into JDK-8231179 - Use StandardJavaFileManager::asPath - Modify copyright - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2004/files - new: https://git.openjdk.java.net/jdk/pull/2004/files/aee1c4a9..0cfaae62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2004&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2004&range=01-02 Stats: 58667 lines in 1480 files changed: 24466 ins; 25774 del; 8427 mod Patch: https://git.openjdk.java.net/jdk/pull/2004.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2004/head:pull/2004 PR: https://git.openjdk.java.net/jdk/pull/2004 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 21 19:00:10 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Jan 2021 19:00:10 GMT Subject: RFR: 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window [v3] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 21:33:21 GMT, Jonathan Gibbons wrote: >> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8231179 >> - Use StandardJavaFileManager::asPath >> - Modify copyright >> - 8231179: Investigate why tools/javac/options/BCPOrSystemNotSpecified.java fails on Window > > Changes requested by jjg (Reviewer). I find the windows-x64-build of the pre-submit-tests failed. I merge the code of the master branch to try to fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2004 From github.com+13688759+lgxbslgx at openjdk.java.net Thu Jan 21 19:18:55 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Thu, 21 Jan 2021 19:18:55 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> Message-ID: On Thu, 21 Jan 2021 18:46:12 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Map > > Looks great - and much simpler. Have you tried running some benchmark? > > If you are not familiar with JMH, another way to quickly (and unofficially :-) benchmark javac is typically trying to clean/build the JDK before/after the change and see if there's an impact. Since this change affects tokenization, if there's a regression you should be able to see it. > > If you are familiar with JMH, and alternative would be to setup a compilation task using the compiler API, and then just parse some files. @mcimadamore As you can see my previous comment, the project jmh-jdk-microbenchmarks already had the benchmark we need. I thought we shouldn't do the repetitive work so I used it but failed to build it. It is better to run the jmh-jdk-microbenchmarks than run the newly written test. If the jmh-jdk-microbenchmarks still fails, I will write a new benchmark test tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From neshkeev at yandex.ru Thu Jan 21 19:52:39 2021 From: neshkeev at yandex.ru (Nikita Eshkeev) Date: Thu, 21 Jan 2021 22:52:39 +0300 Subject: SuppressWarnings on preview features Message-ID: <5822801611256975@mail.yandex.ru> An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Jan 21 21:29:24 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 21 Jan 2021 13:29:24 -0800 Subject: SuppressWarnings on preview features In-Reply-To: <5822801611256975@mail.yandex.ru> References: <5822801611256975@mail.yandex.ru> Message-ID: Hi Nikita, The text you quoted -- "Whether preview features are enabled or disabled, ..." -- refers to use of a preview language feature. You're using Class::isSealed, which is a preview API, not a preview language feature. Use of preview APIs is discussed earlier in JEP 12, in the section "Use of Preview Features": > When compiling with preview features enabled, any source code > reference to (i) a class or interface declared using a preview > language feature, or (ii) a normal preview API, causes a preview > warning. This warning is mandated by the JLS so it occurs on all Java > compilers; it is not specific to javac. It can be suppressed with > @SuppressWarnings("preview"). Alex On 1/21/2021 11:52 AM, Nikita Eshkeev wrote: > The JEP 12 https://openjdk.java.net/jeps/12 > states that: > > /Whether preview features are enabled or disabled/, |javac| in JDK $N > prints a message if it detects the use of a preview language feature of > Java SE $N in source code. THIS MESSAGE CANNOT BE TURNED OFF BY USING > |@SuppressWarnings| in source code, because developers must be > unfailingly aware of their reliance on the Java SE $N version of a > preview language feature; > But consider the following code : > // @SuppressWarnings("preview") > class Main { > ?{ > ? ?String.class.isSealed(); > ?} > } > The Class#isSealed method is annotated (here is the link > https://github.com/openjdk/jdk/blob/jdk-15%2B36/src/java.base/share/classes/java/lang/Class.java#L4446 > ) > with @PreviewFeature(feature=PreviewFeature.Feature.SEALED_CLASSES ... > and SEALED_CLASSES is a preview feature in JDK15. > When I compile the code with OpenJDK 15 I get the following output: > > Main.java:4: warning: [preview] isSealed() is an API that is part of a > preview feature > ? ? ? ? ? ? ? ? ? Main.class.isSealed(); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > 1 warning > When I comment out the SuppressWarnings annotation and compile the code > again, there is no warnings in the output. Is this a bug? > Sincerely, > Nikita Eshkeev From alex.buckley at oracle.com Thu Jan 21 21:47:51 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 21 Jan 2021 13:47:51 -0800 Subject: SuppressWarnings on preview features In-Reply-To: References: <5822801611256975@mail.yandex.ru> Message-ID: <03cda936-b6c6-09f0-b673-b3fe0a709c5c@oracle.com> It further occurs to me that you're using Class::isSealed, which is a _reflective_ preview API rather than a _normal_ preview API. JEP 12 has a section "Special rules for use of reflective preview APIs" which explains, among other things, that use of such APIs is allowed whether preview features are enabled or disabled. Due to the timing of when JEP 12 introduced preview APIs, JDK 15 didn't quite support them as first-class preview features. That's why your error message says "an API that is part of a preview feature", meaning part of the preview language feature called Sealed Classes. JDK 16 does a much better job of supporting preview APIs. Alex On 1/21/2021 1:29 PM, Alex Buckley wrote: > Hi Nikita, > > The text you quoted -- "Whether preview features are enabled or > disabled, ..." -- refers to use of a preview language feature. You're > using Class::isSealed, which is a preview API, not a preview language > feature. Use of preview APIs is discussed earlier in JEP 12, in the > section "Use of Preview Features": > >> When compiling with preview features enabled, any source code >> reference to (i) a class or interface declared using a preview >> language feature, or (ii) a normal preview API, causes a preview >> warning. This warning is mandated by the JLS so it occurs on all Java >> compilers; it is not specific to javac. It can be suppressed with >> @SuppressWarnings("preview"). > Alex > > On 1/21/2021 11:52 AM, Nikita Eshkeev wrote: >> The JEP 12 https://openjdk.java.net/jeps/12 >> states that: >> ?> /Whether preview features are enabled or disabled/, |javac| in JDK >> $N prints a message if it detects the use of a preview language >> feature of Java SE $N in source code. THIS MESSAGE CANNOT BE TURNED >> OFF BY USING |@SuppressWarnings| in source code, because developers >> must be unfailingly aware of their reliance on the Java SE $N version >> of a preview language feature; >> But consider the following code : >> // @SuppressWarnings("preview") >> class Main { >> ??{ >> ?? ?String.class.isSealed(); >> ??} >> } >> The Class#isSealed method is annotated (here is the link >> https://github.com/openjdk/jdk/blob/jdk-15%2B36/src/java.base/share/classes/java/lang/Class.java#L4446 >> ) >> with @PreviewFeature(feature=PreviewFeature.Feature.SEALED_CLASSES ... >> and SEALED_CLASSES is a preview feature in JDK15. >> When I compile the code with OpenJDK 15 I get the following output: >> >> Main.java:4: warning: [preview] isSealed() is an API that is part of a >> preview feature >> ?? ? ? ? ? ? ? ? ? Main.class.isSealed(); >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >> 1 warning >> When I comment out the SuppressWarnings annotation and compile the >> code again, there is no warnings in the output. Is this a bug? >> Sincerely, >> Nikita Eshkeev From mcimadamore at openjdk.java.net Thu Jan 21 22:16:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 21 Jan 2021 22:16:50 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> Message-ID: On Thu, 21 Jan 2021 18:46:12 GMT, Maurizio Cimadamore wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Map > > Looks great - and much simpler. Have you tried running some benchmark? > > If you are not familiar with JMH, another way to quickly (and unofficially :-) benchmark javac is typically trying to clean/build the JDK before/after the change and see if there's an impact. Since this change affects tokenization, if there's a regression you should be able to see it. > > If you are familiar with JMH, and alternative would be to setup a compilation task using the compiler API, and then just parse some files. > @mcimadamore As you can see my previous comment, the project jmh-jdk-microbenchmarks already had the benchmark we need. I thought we shouldn't do the repetitive work so I used it but failed to build it. It is better to run the jmh-jdk-microbenchmarks than run the newly written test. > > If the jmh-jdk-microbenchmarks still fails, I will write a new benchmark test tomorrow. @asotona can you please help? ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 22 06:07:58 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Jan 2021 06:07:58 GMT Subject: RFR: 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash In-Reply-To: References: Message-ID: <3-_sEFQd8FZI9BmuK4soif7nWSdNdYYKQ-2f_BzNdeQ=.88344c22-c639-4ca5-a0a9-e40d2f19ed3c@github.com> On Thu, 14 Jan 2021 19:08:02 GMT, Vicente Romero wrote: >> Hi all, >> >> Currently, javac doesn't attribute unexpected super constructor invocation qualifier. Please see the following code. >> >> public class SuperConstructorCallInErrorClass extends Undefined1 { >> public SuperConstructorCallInErrorClass(int i) { >> new Undefined2() { public void test(int i) { Undefined3 u; } }.super(); //<------------------- >> } >> } >> >> The code `new Undefined2() { public void test(int i) { Undefined3 u; } }` isn't attributed by javac. >> If we use options like `-XDshould-stop.at=FLOW -XDdev`, the compiler would crash. >> >> This patch fixes it and adds the corresponding test cases. >> >> Thank you for taking the time to review. >> >> Best Regards. > > looks sensible, I like the fact that this new code is executed if the compiler has already detected an error, so we are already in recovery mode @vicente-romero-oracle Could I get your help to sponsor this patch? Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/2021 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 22 06:10:51 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Jan 2021 06:10:51 GMT Subject: RFR: 8236490: Compiler bug relating to @NonNull annotation In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 18:11:30 GMT, Vicente Romero wrote: >> Hi all, >> >> If the exception class index in constant pool exceeds 256, the `exception_index` in `TypeAnnotationPosition` will not work as expected. Please see the following code: >> >> public void setCatchInfo(final int catchType, final int startPos) { >> Assert.check(!hasExceptionIndex(), >> "exception_index is already set"); >> Assert.check(catchType >= 0, "Expected a valid catch type"); >> this.exception_index = -((catchType | startPos << 8) + 1); // <------------------------------ >> } >> >> If `catchType` > 256, which means the 8-15 bits is useful, the ` -((catchType | startPos << 8) + 1);` would override these bits. >> >> This patch separates the `startPos` into a new field `exceptionStartPos` to solve the bug. And a test case is added. >> >> Thank you for taking the time to review. >> >> Best Regards. > > looks sensible @vicente-romero-oracle Could I get your help to sponsor this patch? Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/2060 From asotona at openjdk.java.net Fri Jan 22 07:32:41 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Fri, 22 Jan 2021 07:32:41 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> Message-ID: <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> On Thu, 21 Jan 2021 19:16:15 GMT, Guoxiong Li wrote: >> Looks great - and much simpler. Have you tried running some benchmark? >> >> If you are not familiar with JMH, another way to quickly (and unofficially :-) benchmark javac is typically trying to clean/build the JDK before/after the change and see if there's an impact. Since this change affects tokenization, if there's a regression you should be able to see it. >> >> If you are familiar with JMH, and alternative would be to setup a compilation task using the compiler API, and then just parse some files. > > @mcimadamore As you can see my previous comment, the project jmh-jdk-microbenchmarks already had the benchmark we need. I thought we shouldn't do the repetitive work so I used it but failed to build it. It is better to run the jmh-jdk-microbenchmarks than run the newly written test. > > If the jmh-jdk-microbenchmarks still fails, I will write a new benchmark test tomorrow. @lgxbslgx jmh-jdk-microbenchmarks contain a lot of various benchmarks and even micros-javac-... part can take hours if you run it all. As you mention you've successfully built jmh-jdk-microbenchmarks and so to execute only minimal necessary javac benchmarks in local environment you need to limit executed benchmarks to GroupJavacBenchmark only by command line: `java -jar micros-javac/target/micros-javac-1.0-SNAPSHOT.jar .+GroupJavacBenchmark.+` The argument given to JMH benchmarks is regular expression specifying what benchmarks to execute and by default it executes everything bundled. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 22 08:26:46 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Jan 2021 08:26:46 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> Message-ID: <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> On Fri, 22 Jan 2021 07:29:55 GMT, Adam Sotona wrote: > As you mention you've successfully built jmh-jdk-microbenchmarks I couldn't build successfully. Maybe my previous comments were not clear: > When I built the code of this jmh-jdk-microbenchmarks project locally, I **could not get the result** over 5 hours which made me give up. > I thought we shouldn't do the repetitive work so I used it but **failed to build it**. I understand that the test may take hours to run. But the build should not take so much time. @asotona Is it normal to take over 5 hours to build these code? I interrupted the build process when the time exceeded 5 hours. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From lgxbslgx at gmail.com Fri Jan 22 08:49:41 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Fri, 22 Jan 2021 16:49:41 +0800 Subject: The difference between comment and document about the parser Message-ID: Hi all, The comment at class jdk.compiler/com.sun.tools.javac.parser.JavacParser states it as below. ``` /** The parser maps a token sequence into an abstract syntax * tree. It operates by recursive descent, with code derived * systematically from an LL(1) grammar. For efficiency reasons, an * operator precedence scheme is used for parsing binary operation * expressions. ``` And the document of the project `Compiler Grammar`[1] states it as below. > The parser that is currently in the javac compiler is a hand-written LALR parser. We can see that one is LL(1) and another is LALR. I think the comment may be right. No matter which one is the right description, the difference is not acceptable and need to be unified. What is your opinion? Any idea is appreciated. [1] http://openjdk.java.net/projects/compiler-grammar/ Best Regards. -- xiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.java.net Fri Jan 22 09:37:00 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Fri, 22 Jan 2021 09:37:00 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> Message-ID: On Fri, 22 Jan 2021 08:23:50 GMT, Guoxiong Li wrote: >> @lgxbslgx jmh-jdk-microbenchmarks contain a lot of various benchmarks and even micros-javac-... part can take hours if you run it all. As you mention you've successfully built jmh-jdk-microbenchmarks and so to execute only minimal necessary javac benchmarks in local environment you need to limit executed benchmarks to GroupJavacBenchmark only by command line: `java -jar micros-javac/target/micros-javac-1.0-SNAPSHOT.jar .+GroupJavacBenchmark.+` >> The argument given to JMH benchmarks is regular expression specifying what benchmarks to execute and by default it executes everything bundled. > >> As you mention you've successfully built jmh-jdk-microbenchmarks > > I couldn't build successfully. Maybe my previous comments were not clear: > >> When I built the code of this jmh-jdk-microbenchmarks project locally, I **could not get the result** over 5 hours which made me give up. > >> I thought we shouldn't do the repetitive work so I used it but **failed to build it**. > > I understand that the test may take hours to run. But the build should not take so much time. > @asotona Is it normal to take over 5 hours to build these code? I interrupted the build process when the time exceeded 5 hours. @lgxbslgx OK, I see - it is definitely not normal to build it so long. Now I see from your log it got stuck at download of the reference jdk-bin.zip, which is used as benchmarks subject to compile. It indicates probably some networking obstacles, however the workaround is simple: 1. download the reference jdk-bin.zip from [https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_windows-x64_bin.zip](https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_windows-x64_bin.zip) manually 2. build benchmarks with property pointing to the local copy, for example: `mvn package -Djavac.benchmark.openjdk.zip.download.url=file:////openjdk-11+28_windows-x64_bin.zip` ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 22 09:51:01 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Jan 2021 09:51:01 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> Message-ID: On Fri, 22 Jan 2021 09:34:21 GMT, Adam Sotona wrote: >>> As you mention you've successfully built jmh-jdk-microbenchmarks >> >> I couldn't build successfully. Maybe my previous comments were not clear: >> >>> When I built the code of this jmh-jdk-microbenchmarks project locally, I **could not get the result** over 5 hours which made me give up. >> >>> I thought we shouldn't do the repetitive work so I used it but **failed to build it**. >> >> I understand that the test may take hours to run. But the build should not take so much time. >> @asotona Is it normal to take over 5 hours to build these code? I interrupted the build process when the time exceeded 5 hours. > > @lgxbslgx OK, I see - it is definitely not normal to build it so long. Now I see from your log it got stuck at download of the reference jdk-bin.zip, which is used as benchmarks subject to compile. It indicates probably some networking obstacles, however the workaround is simple: > > 1. download the reference jdk-bin.zip from [https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_windows-x64_bin.zip](https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_windows-x64_bin.zip) manually > 2. build benchmarks with property pointing to the local copy, for example: > `mvn package -Djavac.benchmark.openjdk.zip.download.url=file:////openjdk-11+28_windows-x64_bin.zip` @asotona Thank you for your workaround. I will try it later. I find the jdk-bin.zip that you provide is about windows. But my local environment is Linux&x64. Does it have any problem? Or the jdk-bin.zip about linux should be downloaded instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From asotona at openjdk.java.net Fri Jan 22 09:58:57 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Fri, 22 Jan 2021 09:58:57 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> Message-ID: <-oo5Lz6tH7w5MxdYZmvaIE3XKstIwWfDz7Mt0k4a-Gk=.580ca51f-5b21-4fda-b1da-2aaa14ad08e0@github.com> On Fri, 22 Jan 2021 09:47:25 GMT, Guoxiong Li wrote: >> @lgxbslgx OK, I see - it is definitely not normal to build it so long. Now I see from your log it got stuck at download of the reference jdk-bin.zip, which is used as benchmarks subject to compile. It indicates probably some networking obstacles, however the workaround is simple: >> >> 1. download the reference jdk-bin.zip from [https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_windows-x64_bin.zip](https://download.java.net/openjdk/jdk11/ri/openjdk-11+28_windows-x64_bin.zip) manually >> 2. build benchmarks with property pointing to the local copy, for example: >> `mvn package -Djavac.benchmark.openjdk.zip.download.url=file:////openjdk-11+28_windows-x64_bin.zip` > > @asotona Thank you for your workaround. I will try it later. > > I find the jdk-bin.zip that you provide is about windows. But my local environment is Linux&x64. Does it have any problem? Or the jdk-bin.zip about linux should be downloaded instead? @lgxbslgx platform of the jdk-bin.zip is not important until it is a zip file containing src.zip bundle with Open JDK 9, 10 or 11 sources used for javac benchmarking. I would suggest to use the above mentioned win distribution as the benchmarks are tested with it and commonly used as reference. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From asotona at openjdk.java.net Fri Jan 22 10:47:44 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Fri, 22 Jan 2021 10:47:44 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: <-oo5Lz6tH7w5MxdYZmvaIE3XKstIwWfDz7Mt0k4a-Gk=.580ca51f-5b21-4fda-b1da-2aaa14ad08e0@github.com> References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> <-oo5Lz6tH7w5MxdYZmvaIE3XKstIwWfDz7Mt0k4a-Gk=.580ca51f-5b21-4fda-b1da-2aaa14ad08e0@github.com> Message-ID: On Fri, 22 Jan 2021 09:56:23 GMT, Adam Sotona wrote: >> @asotona Thank you for your workaround. I will try it later. >> >> I find the jdk-bin.zip that you provide is about windows. But my local environment is Linux&x64. Does it have any problem? Or the jdk-bin.zip about linux should be downloaded instead? > > @lgxbslgx platform of the jdk-bin.zip is not important until it is a zip file containing src.zip bundle with Open JDK 9, 10 or 11 sources used for javac benchmarking. I would suggest to use the above mentioned win distribution as the benchmarks are tested with it and commonly used as reference. I forgot to add that since Jigsaw enforcement has been applied it is also necessary to add following exports to the benchmark execution command line: --add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 22 12:18:53 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Jan 2021 12:18:53 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> <-oo5Lz6tH7w5MxdYZmvaIE3XKstIwWfDz7Mt0k4a-Gk=.580ca51f-5b21-4fda-b1da-2aaa14ad08e0@github.com> Message-ID: On Fri, 22 Jan 2021 10:45:07 GMT, Adam Sotona wrote: >> @lgxbslgx platform of the jdk-bin.zip is not important until it is a zip file containing src.zip bundle with Open JDK 9, 10 or 11 sources used for javac benchmarking. I would suggest to use the above mentioned win distribution as the benchmarks are tested with it and commonly used as reference. > > I forgot to add that since Jigsaw enforcement has been applied it is also necessary to add following exports to the benchmark execution command line: > --add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED > --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED > --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED > --add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED > --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED @asotona I built the test successfully. And the test is running. Thanks again. ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 22 14:41:49 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Jan 2021 14:41:49 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> <-oo5Lz6tH7w5MxdYZmvaIE3XKstIwWfDz7Mt0k4a-Gk=.580ca51f-5b21-4fda-b1da-2aaa14ad08e0@github.com> Message-ID: On Fri, 22 Jan 2021 12:15:51 GMT, Guoxiong Li wrote: >> I forgot to add that since Jigsaw enforcement has been applied it is also necessary to add following exports to the benchmark execution command line: >> --add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED >> --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED >> --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED >> --add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED >> --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED > > @asotona I built the test successfully. And the test is running. Thanks again. Hi all, This is the result of the benchmark test. The master branch: Benchmark Mode Cnt Score Error Units GroupJavacBenchmark.coldGroup ss 15 39.032 ? 2.142 s/op GroupJavacBenchmark.coldGroup:cold1_Init ss 15 0.691 ? 0.119 s/op GroupJavacBenchmark.coldGroup:cold2_Parse ss 15 11.259 ? 1.343 s/op GroupJavacBenchmark.coldGroup:cold3_InitModules ss 15 11.735 ? 1.359 s/op GroupJavacBenchmark.coldGroup:cold4_Enter ss 15 20.556 ? 2.403 s/op GroupJavacBenchmark.coldGroup:cold5_Attribute ss 15 57.171 ? 3.202 s/op GroupJavacBenchmark.coldGroup:cold6_Flow ss 15 59.490 ? 3.237 s/op GroupJavacBenchmark.coldGroup:cold7_Desugar ss 15 69.980 ? 3.928 s/op GroupJavacBenchmark.coldGroup:cold8_Generate ss 15 81.376 ? 4.422 s/op GroupJavacBenchmark.hotGroup ss 10 22.001 ? 1.084 s/op GroupJavacBenchmark.hotGroup:hot1_Init ss 10 0.270 ? 0.042 s/op GroupJavacBenchmark.hotGroup:hot2_Parse ss 10 6.812 ? 0.586 s/op GroupJavacBenchmark.hotGroup:hot3_InitModules ss 10 7.025 ? 0.619 s/op GroupJavacBenchmark.hotGroup:hot4_Enter ss 10 11.157 ? 0.904 s/op GroupJavacBenchmark.hotGroup:hot5_Attribute ss 10 31.882 ? 1.465 s/op GroupJavacBenchmark.hotGroup:hot6_Flow ss 10 32.996 ? 1.515 s/op GroupJavacBenchmark.hotGroup:hot7_Desugar ss 10 40.072 ? 1.967 s/op GroupJavacBenchmark.hotGroup:hot8_Generate ss 10 45.798 ? 2.170 s/op The JDK-8260053 branch(this patch): Benchmark Mode Cnt Score Error Units GroupJavacBenchmark.coldGroup ss 15 39.878 ? 4.123 s/op GroupJavacBenchmark.coldGroup:cold1_Init ss 15 0.696 ? 0.138 s/op GroupJavacBenchmark.coldGroup:cold2_Parse ss 15 11.317 ? 1.422 s/op GroupJavacBenchmark.coldGroup:cold3_InitModules ss 15 11.788 ? 1.428 s/op GroupJavacBenchmark.coldGroup:cold4_Enter ss 15 20.339 ? 1.662 s/op GroupJavacBenchmark.coldGroup:cold5_Attribute ss 15 58.910 ? 6.163 s/op GroupJavacBenchmark.coldGroup:cold6_Flow ss 15 61.114 ? 6.619 s/op GroupJavacBenchmark.coldGroup:cold7_Desugar ss 15 71.692 ? 9.120 s/op GroupJavacBenchmark.coldGroup:cold8_Generate ss 15 83.169 ? 11.241 s/op GroupJavacBenchmark.hotGroup ss 10 22.024 ? 1.883 s/op GroupJavacBenchmark.hotGroup:hot1_Init ss 10 0.273 ? 0.090 s/op GroupJavacBenchmark.hotGroup:hot2_Parse ss 10 6.520 ? 0.576 s/op GroupJavacBenchmark.hotGroup:hot3_InitModules ss 10 6.710 ? 0.581 s/op GroupJavacBenchmark.hotGroup:hot4_Enter ss 10 10.756 ? 0.698 s/op GroupJavacBenchmark.hotGroup:hot5_Attribute ss 10 32.317 ? 3.305 s/op GroupJavacBenchmark.hotGroup:hot6_Flow ss 10 33.495 ? 3.486 s/op GroupJavacBenchmark.hotGroup:hot7_Desugar ss 10 40.116 ? 3.698 s/op GroupJavacBenchmark.hotGroup:hot8_Generate ss 10 46.002 ? 3.795 s/op At `coldGroup:cold2_Parse`, this patch(11.317) is little higher than the master branch(11.259). At `hotGroup:hot2_Parse`, this patch(6.520) is little lower than the master branch(6.812). If my understanding of the data is correct, I believe this patch has little influence to performance. The concrete log is attached below. [master.log](https://github.com/openjdk/jdk/files/5856433/master.log) [JDK-8260053.log](https://github.com/openjdk/jdk/files/5856434/JDK-8260053.log) ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From jonathan.gibbons at oracle.com Fri Jan 22 15:01:04 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Jan 2021 07:01:04 -0800 Subject: The difference between comment and document about the parser In-Reply-To: References: Message-ID: <7c9fd785-6b95-d2d7-84b6-c7f148093a4a@oracle.com> Hi, The compiler-grammar project is no longer under active development. I think the best solution is just to put a warning notice to that effect at the top of the project page. -- Jon On 1/22/21 12:49 AM, Guoxiong Li wrote: > Hi all, > > The comment at class > jdk.compiler/com.sun.tools.javac.parser.JavacParser states it as below. > > ``` > /** The parser maps a token sequence into an abstract syntax > ?* ?tree. It operates by recursive descent, with code derived > ?* ?systematically from an LL(1) grammar. For efficiency reasons, an > ?* ?operator precedence scheme is used for parsing binary operation > ?* ?expressions. > ``` > > And the document of the project `Compiler Grammar`[1] states it as below. > > >?The parser that is currently in the javac compiler is a hand-written > LALR parser. > > We can see that one is? LL(1) and another is LALR. I think the comment > may be right. > No matter which one is the right description, the difference is not > acceptable and need to be unified. > > What is your opinion? Any idea is appreciated. > > [1] http://openjdk.java.net/projects/compiler-grammar/ > > > Best Regards. > > -- xiong From lgxbslgx at gmail.com Fri Jan 22 15:20:08 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Fri, 22 Jan 2021 23:20:08 +0800 Subject: The difference between comment and document about the parser In-Reply-To: <7c9fd785-6b95-d2d7-84b6-c7f148093a4a@oracle.com> References: <7c9fd785-6b95-d2d7-84b6-c7f148093a4a@oracle.com> Message-ID: Hi Jon, Thank you for your comment. I am still confused by the following statement. > The parser that is currently in the javac compiler is a hand-written LALR parser. Does it mean: the compiler of the main-line code was a LALR parser previously? Or it means: the compiler of the project `Compiler Grammar` is a LALR parser? On Fri, Jan 22, 2021 at 11:03 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Hi, > > The compiler-grammar project is no longer under active development. > > I think the best solution is just to put a warning notice to that effect > at the top of the project page. > > -- Jon > > On 1/22/21 12:49 AM, Guoxiong Li wrote: > > Hi all, > > > > The comment at class > > jdk.compiler/com.sun.tools.javac.parser.JavacParser states it as below. > > > > ``` > > /** The parser maps a token sequence into an abstract syntax > > * tree. It operates by recursive descent, with code derived > > * systematically from an LL(1) grammar. For efficiency reasons, an > > * operator precedence scheme is used for parsing binary operation > > * expressions. > > ``` > > > > And the document of the project `Compiler Grammar`[1] states it as below. > > > > > The parser that is currently in the javac compiler is a hand-written > > LALR parser. > > > > We can see that one is LL(1) and another is LALR. I think the comment > > may be right. > > No matter which one is the right description, the difference is not > > acceptable and need to be unified. > > > > What is your opinion? Any idea is appreciated. > > > > [1] http://openjdk.java.net/projects/compiler-grammar/ > > > > > > Best Regards. > > > > -- xiong > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.java.net Fri Jan 22 15:43:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 22 Jan 2021 15:43:50 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 18:26:50 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. >> >> The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). >> >> Thank you for taking the time to review. >> >> Best Regards. > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Use Map Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From mcimadamore at openjdk.java.net Fri Jan 22 15:43:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 22 Jan 2021 15:43:50 GMT Subject: RFR: 8260053: Optimize Tokens' use of Names [v2] In-Reply-To: References: <5amhXJJVsxvlKzxG_J0opRCjTvU9_6nj_Pw1JoYT3rg=.439d6327-5416-4ee0-a851-5a6806b1a8fa@github.com> <1_I6hF0o__GYrQ-elMBcFk-xle7Q_OHHgg_zemjTCW0=.98a58de9-6911-46c3-b720-9ceb8c2a0b27@github.com> <2fahBa5FUJXu4_CNwCfFgGk7Gj7wz3XYRdh7aGBVye4=.7678ace7-89e0-42d7-ae4e-d047bbee9e3c@github.com> <-oo5Lz6tH7w5MxdYZmvaIE3XKstIwWfDz7Mt0k4a-Gk=.580ca51f-5b21-4fda-b1da-2aaa14ad08e0@github.com> Message-ID: On Fri, 22 Jan 2021 14:32:16 GMT, Guoxiong Li wrote: >> @asotona I built the test successfully. And the test is running. Thanks again. > > Hi all, > > This is the result of the benchmark test. > > The master branch: > > Benchmark Mode Cnt Score Error Units > GroupJavacBenchmark.coldGroup ss 15 39.032 ? 2.142 s/op > GroupJavacBenchmark.coldGroup:cold1_Init ss 15 0.691 ? 0.119 s/op > GroupJavacBenchmark.coldGroup:cold2_Parse ss 15 11.259 ? 1.343 s/op > GroupJavacBenchmark.coldGroup:cold3_InitModules ss 15 11.735 ? 1.359 s/op > GroupJavacBenchmark.coldGroup:cold4_Enter ss 15 20.556 ? 2.403 s/op > GroupJavacBenchmark.coldGroup:cold5_Attribute ss 15 57.171 ? 3.202 s/op > GroupJavacBenchmark.coldGroup:cold6_Flow ss 15 59.490 ? 3.237 s/op > GroupJavacBenchmark.coldGroup:cold7_Desugar ss 15 69.980 ? 3.928 s/op > GroupJavacBenchmark.coldGroup:cold8_Generate ss 15 81.376 ? 4.422 s/op > GroupJavacBenchmark.hotGroup ss 10 22.001 ? 1.084 s/op > GroupJavacBenchmark.hotGroup:hot1_Init ss 10 0.270 ? 0.042 s/op > GroupJavacBenchmark.hotGroup:hot2_Parse ss 10 6.812 ? 0.586 s/op > GroupJavacBenchmark.hotGroup:hot3_InitModules ss 10 7.025 ? 0.619 s/op > GroupJavacBenchmark.hotGroup:hot4_Enter ss 10 11.157 ? 0.904 s/op > GroupJavacBenchmark.hotGroup:hot5_Attribute ss 10 31.882 ? 1.465 s/op > GroupJavacBenchmark.hotGroup:hot6_Flow ss 10 32.996 ? 1.515 s/op > GroupJavacBenchmark.hotGroup:hot7_Desugar ss 10 40.072 ? 1.967 s/op > GroupJavacBenchmark.hotGroup:hot8_Generate ss 10 45.798 ? 2.170 s/op > > The JDK-8260053 branch(this patch): > > Benchmark Mode Cnt Score Error Units > GroupJavacBenchmark.coldGroup ss 15 39.878 ? 4.123 s/op > GroupJavacBenchmark.coldGroup:cold1_Init ss 15 0.696 ? 0.138 s/op > GroupJavacBenchmark.coldGroup:cold2_Parse ss 15 11.317 ? 1.422 s/op > GroupJavacBenchmark.coldGroup:cold3_InitModules ss 15 11.788 ? 1.428 s/op > GroupJavacBenchmark.coldGroup:cold4_Enter ss 15 20.339 ? 1.662 s/op > GroupJavacBenchmark.coldGroup:cold5_Attribute ss 15 58.910 ? 6.163 s/op > GroupJavacBenchmark.coldGroup:cold6_Flow ss 15 61.114 ? 6.619 s/op > GroupJavacBenchmark.coldGroup:cold7_Desugar ss 15 71.692 ? 9.120 s/op > GroupJavacBenchmark.coldGroup:cold8_Generate ss 15 83.169 ? 11.241 s/op > GroupJavacBenchmark.hotGroup ss 10 22.024 ? 1.883 s/op > GroupJavacBenchmark.hotGroup:hot1_Init ss 10 0.273 ? 0.090 s/op > GroupJavacBenchmark.hotGroup:hot2_Parse ss 10 6.520 ? 0.576 s/op > GroupJavacBenchmark.hotGroup:hot3_InitModules ss 10 6.710 ? 0.581 s/op > GroupJavacBenchmark.hotGroup:hot4_Enter ss 10 10.756 ? 0.698 s/op > GroupJavacBenchmark.hotGroup:hot5_Attribute ss 10 32.317 ? 3.305 s/op > GroupJavacBenchmark.hotGroup:hot6_Flow ss 10 33.495 ? 3.486 s/op > GroupJavacBenchmark.hotGroup:hot7_Desugar ss 10 40.116 ? 3.698 s/op > GroupJavacBenchmark.hotGroup:hot8_Generate ss 10 46.002 ? 3.795 s/op > > At `coldGroup:cold2_Parse`, this patch(11.317) is little higher than the master branch(11.259). > At `hotGroup:hot2_Parse`, this patch(6.520) is little lower than the master branch(6.812). > If my understanding of the data is correct, I believe this patch has little influence to performance. > > The concrete log is attached below. > [master.log](https://github.com/openjdk/jdk/files/5856433/master.log) > [JDK-8260053.log](https://github.com/openjdk/jdk/files/5856434/JDK-8260053.log) Yeah - I don't think there's any evidence in the benchmark run of a change in performances. I think this looks good -very nice work! ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 22 15:49:39 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 22 Jan 2021 15:49:39 GMT Subject: Integrated: 8260053: Optimize Tokens' use of Names In-Reply-To: References: Message-ID: <6MMIz5R76HZue634GP3TQzKbrHiCiasZfeVXjGozr0U=.a1fad378-4694-49b1-99e3-0effae78057b@github.com> On Wed, 20 Jan 2021 17:07:26 GMT, Guoxiong Li wrote: > Hi all, > > This patch initializes the names about `TokenKind` at the beginning of the constructor of the class `Names`. As a result, the `Tokens.maxKey` and the length of the array `Tokens.key` become small. By using this patch, the length of the array `Tokens.key` is changed from 4280 to 383. > > The original discussion is at [compiler-dev](https://mail.openjdk.java.net/pipermail/compiler-dev/2021-January/016126.html). > > Thank you for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: 0ea58626 Author: Guoxiong Li Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/0ea58626 Stats: 39 lines in 1 file changed: 4 ins; 26 del; 9 mod 8260053: Optimize Tokens' use of Names Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/2169 From vromero at openjdk.java.net Fri Jan 22 20:04:42 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 22 Jan 2021 20:04:42 GMT Subject: RFR: JDK-8255464: Cannot access ModuleTree in a CompilationUnitTree In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 06:14:03 GMT, Jonathan Gibbons wrote: > Please review a small change to add an overdue missing method to access the `ModuleTree` when a `CompilationUnitTree` represents a modular compilation unit. > > CSR is in progress. looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2155 From alanb at openjdk.java.net Sat Jan 23 07:57:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 23 Jan 2021 07:57:43 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang? > @AlanBateman When I moved the charset templates, I found this gold nugget: > > ``` > # Copy two Java files that need no preprocessing. > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template > $(call LogInfo, Generating $(@F)) > $(call install-file) > > GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ > $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java > ``` > > What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now. Good find, surprised this wasn't spotted before now. We should create a separate issue to rename them and get rid of the copying in the make file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jonathan.gibbons at oracle.com Sat Jan 23 17:05:49 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 23 Jan 2021 09:05:49 -0800 Subject: The difference between comment and document about the parser In-Reply-To: References: Message-ID: <3dfb1696-55d6-f380-ba5d-b3363e204588@oracle.com> Going back in the public record, I note that JLS 3rd Edition, chapter 18[1] says: /The grammar presented in this chapter is the basis for the reference implementation. Note that it is not an LL(1) grammar, though in many cases it minimizes the necessary look ahead./ -- Jon 1: https://docs.oracle.com/javase/specs/jls/se6/html/syntax.html On 1/22/21 12:49 AM, Guoxiong Li wrote: > Hi all, > > The comment at class > jdk.compiler/com.sun.tools.javac.parser.JavacParser states it as below. > > ``` > /** The parser maps a token sequence into an abstract syntax > ?* ?tree. It operates by recursive descent, with code derived > ?* ?systematically from an LL(1) grammar. For efficiency reasons, an > ?* ?operator precedence scheme is used for parsing binary operation > ?* ?expressions. > ``` > > And the document of the project `Compiler Grammar`[1] states it as below. > > >?The parser that is currently in the javac compiler is a hand-written > LALR parser. > > We can see that one is? LL(1) and another is LALR. I think the comment > may be right. > No matter which one is the right description, the difference is not > acceptable and need to be unified. > > What is your opinion? Any idea is appreciated. > > [1] http://openjdk.java.net/projects/compiler-grammar/ > > > Best Regards. > > -- xiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Jan 23 19:49:36 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 23 Jan 2021 11:49:36 -0800 Subject: The difference between comment and document about the parser In-Reply-To: <3dfb1696-55d6-f380-ba5d-b3363e204588@oracle.com> References: <3dfb1696-55d6-f380-ba5d-b3363e204588@oracle.com> Message-ID: For the comment in JavacParser.java, I suggest the phrase "with code derived systematically from an LL(1) grammar" is replaced by something like "according to the grammar described in the Java Language Specification", and for bonus points, possibly even give the URL https://docs.oracle.com/javase/specs/index.html. I would recommend not citing any specific version, because that would need to be updated on each release.? For additional pedantry, you could also include reference to the preview features, which are not part of JLS itself. -- Jon On 1/23/21 9:05 AM, Jonathan Gibbons wrote: > > Going back in the public record, I note that JLS 3rd Edition, chapter > 18[1] says: > > /The grammar presented in this chapter is the basis for the reference > implementation. Note that it is not an LL(1) grammar, though in many > cases it minimizes the necessary look ahead./ > > -- Jon > > 1: https://docs.oracle.com/javase/specs/jls/se6/html/syntax.html > > On 1/22/21 12:49 AM, Guoxiong Li wrote: >> Hi all, >> >> The comment at class >> jdk.compiler/com.sun.tools.javac.parser.JavacParser states it as below. >> >> ``` >> /** The parser maps a token sequence into an abstract syntax >> ?* ?tree. It operates by recursive descent, with code derived >> ?* ?systematically from an LL(1) grammar. For efficiency reasons, an >> ?* ?operator precedence scheme is used for parsing binary operation >> ?* ?expressions. >> ``` >> >> And the document of the project `Compiler Grammar`[1] states it as below. >> >> >?The parser that is currently in the javac compiler is a >> hand-written LALR parser. >> >> We can see that one is? LL(1) and another is LALR. I think the >> comment may be right. >> No matter which one is the right description, the difference is not >> acceptable and need to be unified. >> >> What is your opinion? Any idea is appreciated. >> >> [1] http://openjdk.java.net/projects/compiler-grammar/ >> >> >> Best Regards. >> >> -- xiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From neshkeev at yandex.ru Mon Jan 25 09:28:54 2021 From: neshkeev at yandex.ru (Nikita Eshkeev) Date: Mon, 25 Jan 2021 12:28:54 +0300 Subject: Unchecked cast to intersection type In-Reply-To: <2340201610971248@mail.yandex.ru> References: <2340201610971248@mail.yandex.ru> Message-ID: <7621361611566908@mail.yandex.ru> An HTML attachment was scrubbed... URL: From jlahoda at openjdk.java.net Mon Jan 25 12:18:43 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 25 Jan 2021 12:18:43 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v3] In-Reply-To: References: Message-ID: On Tue, 29 Dec 2020 04:53:10 GMT, Jia Yanwei wrote: >> **Issue:** >> `javac` crashes with a NPE when compiling such code: >> - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types) >> - instance the local class in a nested lambda >> >> Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1: >> >> An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. >> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null >> at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571) >> at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942) >> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723) >> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084) >> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917) >> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) >> at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) >> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59) >> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45) >> printing javac parameters to: /tmp/javac.20201126_141249.args >> >> The minimal reproducing code is: >> >> java >> class Main { >> static Runnable runnable = () -> { >> boolean b0 = false; >> String s0 = "hello"; >> >> class Local { >> int i = s0.length(); >> } >> >> Runnable dummy = () -> new Local(); >> }; >> } >> >> If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.: >> >> java >> public class CaptureInt { >> static Runnable runnable = () -> { >> boolean b0 = false; >> int i0 = 5; >> >> class Local { >> int i = i0 + 2; >> } >> >> Runnable dummy = () -> new Local(); >> }; >> >> public static void main(String args[]) { >> } >> } >> >> **Reason & Experimental solution:** >> >> During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. >> But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda. >> My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda. >> I'm not sure whether the code style as well as the solution itself are appropriate. Welcome any advice and better solution. > > Jia Yanwei has updated the pull request incrementally with three additional commits since the last revision: > > - fix 8258897: wrong translation of capturing local classes inside nested lambdas > - rename test case directory name > - revert the experimental fix in 9dec0d2 Seems sensible to me. Some recommendations on improving the text comment format are inline. test/langtools/tools/javac/lambda/8258897/CaptureVariables.java line 3: > 1: import java.util.function.Supplier; > 2: > 3: /** It would be nice to tweak the test to so that: -the comment with `@test` is first, and imports follow -`@test` is augmented with `/nodynamiccopyright/` -`@bug` is added -`@summary` is added (applies to both tests) ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1479 From github.com+13688759+lgxbslgx at openjdk.java.net Mon Jan 25 13:26:48 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Mon, 25 Jan 2021 13:26:48 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 12:15:36 GMT, Jan Lahoda wrote: >> Jia Yanwei has updated the pull request incrementally with three additional commits since the last revision: >> >> - fix 8258897: wrong translation of capturing local classes inside nested lambdas >> - rename test case directory name >> - revert the experimental fix in 9dec0d2 > > test/langtools/tools/javac/lambda/8258897/CaptureVariables.java line 3: > >> 1: import java.util.function.Supplier; >> 2: >> 3: /** > > It would be nice to tweak the test to so that: > -the comment with `@test` is first, and imports follow > -`@test` is augmented with `/nodynamiccopyright/` > -`@bug` is added > -`@summary` is added > > (applies to both tests) And the action tag `@run main CaptureVariables` should be added. @hltj Some documents are helpful to you: [Regression Test Harness for the JDK: jtreg](http://openjdk.java.net/jtreg/index.html) [The JDK Test Framework: Tag Language Specification](http://openjdk.java.net/jtreg/tag-spec.html) ------------- PR: https://git.openjdk.java.net/jdk/pull/1479 From jjg at openjdk.java.net Mon Jan 25 21:47:44 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 25 Jan 2021 21:47:44 GMT Subject: Integrated: JDK-8255464: Cannot access ModuleTree in a CompilationUnitTree In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 06:14:03 GMT, Jonathan Gibbons wrote: > Please review a small change to add an overdue missing method to access the `ModuleTree` when a `CompilationUnitTree` represents a modular compilation unit. > > CSR is in progress. This pull request has now been integrated. Changeset: d6fb9d72 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/d6fb9d72 Stats: 179 lines in 5 files changed: 171 ins; 0 del; 8 mod 8255464: Cannot access ModuleTree in a CompilationUnitTree Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2155 From github.com+3896345+hltj at openjdk.java.net Tue Jan 26 04:08:43 2021 From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei) Date: Tue, 26 Jan 2021 04:08:43 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v3] In-Reply-To: References: Message-ID: <_yN1iFH5lhhv7t2UnJPTZbkEZae4IuB8hgOOXePPu-s=.6e7246ec-4b6a-495c-8b4b-80b3f81ffefb@github.com> On Mon, 25 Jan 2021 12:15:36 GMT, Jan Lahoda wrote: >> Jia Yanwei has updated the pull request incrementally with three additional commits since the last revision: >> >> - fix 8258897: wrong translation of capturing local classes inside nested lambdas >> - rename test case directory name >> - revert the experimental fix in 9dec0d2 > > test/langtools/tools/javac/lambda/8258897/CaptureVariables.java line 3: > >> 1: import java.util.function.Supplier; >> 2: >> 3: /** > > It would be nice to tweak the test to so that: > -the comment with `@test` is first, and imports follow > -`@test` is augmented with `/nodynamiccopyright/` > -`@bug` is added > -`@summary` is added > > (applies to both tests) Thanks to @lahodaj and @lgxbslgx ! I will add the tags. ------------- PR: https://git.openjdk.java.net/jdk/pull/1479 From github.com+3896345+hltj at openjdk.java.net Tue Jan 26 04:42:03 2021 From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei) Date: Tue, 26 Jan 2021 04:42:03 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v4] In-Reply-To: References: Message-ID: > **Issue:** > `javac` crashes with a NPE when compiling such code: > - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types) > - instance the local class in a nested lambda > > Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1: > > An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null > at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571) > at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45) > printing javac parameters to: /tmp/javac.20201126_141249.args > > The minimal reproducing code is: > > java > class Main { > static Runnable runnable = () -> { > boolean b0 = false; > String s0 = "hello"; > > class Local { > int i = s0.length(); > } > > Runnable dummy = () -> new Local(); > }; > } > > If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.: > > java > public class CaptureInt { > static Runnable runnable = () -> { > boolean b0 = false; > int i0 = 5; > > class Local { > int i = i0 + 2; > } > > Runnable dummy = () -> new Local(); > }; > > public static void main(String args[]) { > } > } > > **Reason & Experimental solution:** > > During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. > But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda. > My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda. > I'm not sure whether the code style as well as the solution itself are appropriate. Welcome any advice and better solution. Jia Yanwei has updated the pull request incrementally with one additional commit since the last revision: tweak the test: add informational tags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1479/files - new: https://git.openjdk.java.net/jdk/pull/1479/files/86cb0ad8..810b909d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=02-03 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1479/head:pull/1479 PR: https://git.openjdk.java.net/jdk/pull/1479 From github.com+3896345+hltj at openjdk.java.net Tue Jan 26 04:59:52 2021 From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei) Date: Tue, 26 Jan 2021 04:59:52 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v5] In-Reply-To: References: Message-ID: > **Issue:** > `javac` crashes with a NPE when compiling such code: > - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types) > - instance the local class in a nested lambda > > Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1: > > An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null > at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571) > at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45) > printing javac parameters to: /tmp/javac.20201126_141249.args > > The minimal reproducing code is: > > java > class Main { > static Runnable runnable = () -> { > boolean b0 = false; > String s0 = "hello"; > > class Local { > int i = s0.length(); > } > > Runnable dummy = () -> new Local(); > }; > } > > If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.: > > java > public class CaptureInt { > static Runnable runnable = () -> { > boolean b0 = false; > int i0 = 5; > > class Local { > int i = i0 + 2; > } > > Runnable dummy = () -> new Local(); > }; > > public static void main(String args[]) { > } > } > > **Reason & Experimental solution:** > > During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. > But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda. > My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda. > I'm not sure whether the code style as well as the solution itself are appropriate. Welcome any advice and better solution. Jia Yanwei has updated the pull request incrementally with one additional commit since the last revision: tweak the test comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1479/files - new: https://git.openjdk.java.net/jdk/pull/1479/files/810b909d..f142d14e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=03-04 Stats: 12 lines in 2 files changed: 6 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1479/head:pull/1479 PR: https://git.openjdk.java.net/jdk/pull/1479 From jfranck at openjdk.java.net Tue Jan 26 07:58:41 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 26 Jan 2021 07:58:41 GMT Subject: RFR: 8236490: Compiler bug relating to @NonNull annotation In-Reply-To: References: Message-ID: <-WgiK3wJiYymUL0berj5w92RM4hFQeTBGbujk6ytWW8=.829fb868-9129-47d3-8cd1-49262187a88e@github.com> On Fri, 22 Jan 2021 06:05:25 GMT, Guoxiong Li wrote: >> looks sensible > > @vicente-romero-oracle Could I get your help to sponsor this patch? Thanks a lot. @lgxbslgx can you rebase on a fresh upstream and I'll sponsor this for you ------------- PR: https://git.openjdk.java.net/jdk/pull/2060 From jfranck at openjdk.java.net Tue Jan 26 08:52:42 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Tue, 26 Jan 2021 08:52:42 GMT Subject: RFR: 8236490: Compiler bug relating to @NonNull annotation In-Reply-To: References: Message-ID: <9rW0iDzXEPObR0Mk1YFxXJZNLEtbX3DTyftwc26t1GI=.8a9986af-9e16-4597-81a7-fe827adc8fff@github.com> On Wed, 13 Jan 2021 10:01:26 GMT, Guoxiong Li wrote: > Hi all, > > If the exception class index in constant pool exceeds 256, the `exception_index` in `TypeAnnotationPosition` will not work as expected. Please see the following code: > > public void setCatchInfo(final int catchType, final int startPos) { > Assert.check(!hasExceptionIndex(), > "exception_index is already set"); > Assert.check(catchType >= 0, "Expected a valid catch type"); > this.exception_index = -((catchType | startPos << 8) + 1); // <------------------------------ > } > > If `catchType` > 256, which means the 8-15 bits is useful, the ` -((catchType | startPos << 8) + 1);` would override these bits. > > This patch separates the `startPos` into a new field `exceptionStartPos` to solve the bug. And a test case is added. > > Thank you for taking the time to review. > > Best Regards. I think is still trying to be way to clever with compressing the different states into previously 1 int and now 2 ints. However this is an improvement and fixes an issue we have. ------------- Marked as reviewed by jfranck (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2060 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Jan 26 09:00:42 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Jan 2021 09:00:42 GMT Subject: RFR: 8236490: Compiler bug relating to @NonNull annotation In-Reply-To: <9rW0iDzXEPObR0Mk1YFxXJZNLEtbX3DTyftwc26t1GI=.8a9986af-9e16-4597-81a7-fe827adc8fff@github.com> References: <9rW0iDzXEPObR0Mk1YFxXJZNLEtbX3DTyftwc26t1GI=.8a9986af-9e16-4597-81a7-fe827adc8fff@github.com> Message-ID: On Tue, 26 Jan 2021 08:49:51 GMT, Joel Borggr?n-Franck wrote: >> Hi all, >> >> If the exception class index in constant pool exceeds 256, the `exception_index` in `TypeAnnotationPosition` will not work as expected. Please see the following code: >> >> public void setCatchInfo(final int catchType, final int startPos) { >> Assert.check(!hasExceptionIndex(), >> "exception_index is already set"); >> Assert.check(catchType >= 0, "Expected a valid catch type"); >> this.exception_index = -((catchType | startPos << 8) + 1); // <------------------------------ >> } >> >> If `catchType` > 256, which means the 8-15 bits is useful, the ` -((catchType | startPos << 8) + 1);` would override these bits. >> >> This patch separates the `startPos` into a new field `exceptionStartPos` to solve the bug. And a test case is added. >> >> Thank you for taking the time to review. >> >> Best Regards. > > I think is still trying to be way to clever with compressing the different states into previously 1 int and now 2 ints. However this is an improvement and fixes an issue we have. @jbf Thank you. The patch can be integrated directly because the robot doesn't remind of conflict. ------------- PR: https://git.openjdk.java.net/jdk/pull/2060 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Jan 26 09:00:45 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 26 Jan 2021 09:00:45 GMT Subject: Integrated: 8236490: Compiler bug relating to @NonNull annotation In-Reply-To: References: Message-ID: On Wed, 13 Jan 2021 10:01:26 GMT, Guoxiong Li wrote: > Hi all, > > If the exception class index in constant pool exceeds 256, the `exception_index` in `TypeAnnotationPosition` will not work as expected. Please see the following code: > > public void setCatchInfo(final int catchType, final int startPos) { > Assert.check(!hasExceptionIndex(), > "exception_index is already set"); > Assert.check(catchType >= 0, "Expected a valid catch type"); > this.exception_index = -((catchType | startPos << 8) + 1); // <------------------------------ > } > > If `catchType` > 256, which means the 8-15 bits is useful, the ` -((catchType | startPos << 8) + 1);` would override these bits. > > This patch separates the `startPos` into a new field `exceptionStartPos` to solve the bug. And a test case is added. > > Thank you for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: 23edb6f6 Author: Guoxiong Li Committer: Joel Borggr?n-Franck URL: https://git.openjdk.java.net/jdk/commit/23edb6f6 Stats: 117 lines in 2 files changed: 111 ins; 0 del; 6 mod 8236490: Compiler bug relating to @NonNull annotation Reviewed-by: vromero, jfranck ------------- PR: https://git.openjdk.java.net/jdk/pull/2060 From ihse at openjdk.java.net Tue Jan 26 10:14:41 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 26 Jan 2021 10:14:41 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v4] In-Reply-To: References: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com> Message-ID: On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman wrote: > We should create a separate issue to rename them and get rid of the copying in the make file. I opened https://bugs.openjdk.java.net/browse/JDK-8260406. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From anna.kozlova at jetbrains.com Tue Jan 26 12:05:21 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Tue, 26 Jan 2021 13:05:21 +0100 Subject: Pluggable Annotation Processing: problems from the IDE (IntelliJ) perspective Message-ID: Hi all, As we lately see the `JSR 269 - Pluggable Annotation Processing - Maintenance Review ballot', we would like to share our troubles with this API from the IDE perspective. It isn't connected to the latest changes in the JSR so I was advised to post our thoughts here. *Initial setup:* IntelliJ IDEA allows incremental compilation, which means that only changed code and its dependencies are recompiled instead of the whole project (workspace)/module (project). The task is complicated by itself but when people use Annotation Processors it becomes sometimes impossible though, it seems, we may get all information we need to build source - output relation and thus enable incremental compilation. *Problem description:* When a processor generates a java source code, a bytecode or a resource file, it uses "create*" methods from the javax.annotation.processing.Filer interface. Every "create*" method has a vararg parameter "originatingElements" which are supposed to be "type or package or module elements causally associated with the creation of this file, may be elided or null". Those elements are supposed to be used by the processing environment to register and track dependencies between generated classes and existing code elements (classes, methods, fields) used by the processor to produce the generated code. The default Filter implementation by javac simply ignores this data. Internally, javac calls JavaFileManager to actually create and store the generated data, but, unfortunately, the originatingElements passed by processors are already lost. When generating bytecode, javac uses the javax.tools.JavaFileManager.getJavaFileForOutput() method and passes the "sibling" argument, pointing to the corresponding source file. This information is used by our build system to register source->output dependencies and facilitate incremental compilation. However, if data generation is initiated by an annotation processor, the "sibling" parameter is always null. One could expect it to point to a source file object containing originatingElements passed by the AP. (Another problem is that there are multiple originating elements potentially corresponding to multiple source files, but there is only a single "sibling" reference in the getJavaFileForOutput() method.) Because originatingElements are ignored, our build system cannot track dependencies between source files and AP-generated code. So we should always assume the worst scenario and recompile the whole module or a project whenever we detect that generated code is affected. Without this information the detection itself is not as reliable as it could have been. So if a project heavily relies on AP code generation, we cannot provide the best incremental compilation experience because of lack of data. *Current solution:* The javadoc for create* methods in the Filer interface suggests that "This information may be used in an incremental environment to determine the need to rerun processors or remove generated files. Non-incremental environments may ignore the originating element information." In order to get access to originatingElements, our build system has to provide its own implementation of Filer interface. We do this by wrapping the original Filter implementation with a wrapper that registers originatingElements and delegates the call to original Filter implementation. This is on its own a non-trivial task, because the whole API provides no direct ways neither to access the originatingElements nor to register a custom Filter implementation. Just to wrap the original Filer implementation, we have to re-implement the AP discovery logic, and then use the JavaCompiler.CompilationTask.setProcessors() method that would explicitly configure processor objects. Every Processor object is in turn wrapped with our "wrapper", whose the only purpose is to make sure the AP will get a wrapped Filer and not the original one. *Problems with the current solution:* This approach generally works, but it leads to additional problems on the annotation processor side. Unfortunately, many popular processors assume that passed objects like ProcessingEnvironment and Filer have certain implementations. The processor code may heavily rely on this assumption, e.g. cast the passed object to implementation or use instanceof checks on it. So if processor gets a wrapped ProcessingEnvironment, it would fail to execute further. As a result, user's project just stops compiling. Another problem caused by such wrapping approach, is javac's so called Tree API. An annotation processor may use the Tree API for its internal logic. The only way for the processor to obtain a reference to this API Facade is a call com.sun.source.util.Trees.instance(ProcessingEnvironment). If processor passes the wrapped ProcessingEnvironment object to the Trees.instance() method, it won't work, because its implementation internally uses an instanceof check itself! Our current approach is to detect such situation and provide AP developer with hints in the error message. In order to make the processor work in our incremental environment, the AP developer has to write additional code that "unwraps" the passed ProcessingEnvironment object and uses the unwrapped object to initialize the Tree API. Such a situation, of course, is far from ideal: AP developers should not write code to please an IDE. *What can improve the situation:* So would be great if following problems were addressed in the API: there should be a direct way to access originatingElements. Ideally there accessing this data should not make AP developers to change their code. If code changes are inevitable on AP side, those changes should be possible without making assumptions about inteface implementations. There should be a standard way to get access to Tree API as well, or, even better, the original API should be extended to make implementation of complex processing logic possible without semi-closed Tree API. Thanks, Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.java.net Tue Jan 26 14:05:51 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 26 Jan 2021 14:05:51 GMT Subject: RFR: 8259050: Error recovery in lexer could be improved Message-ID: Consider code like: public class BrokenEscape { private String s = "\uaaa"; } (note the broken escape). This produces: $ javac BrokenEscape.java BrokenEscape.java:2: error: illegal unicode escape private String s = "\uaaa"; ^ BrokenEscape.java:2: error: unclosed string literal private String s = "\uaaa"; ^ 2 errors After this patch, it produces: $ javac BrokenEscape.java BrokenEscape.java:2: error: illegal unicode escape private String s = "\uaaa"; ^ 1 error which is the error message that used to be produced in the past. The patch also improves the AST for source levels where text blocks are not supported, but are in fact present in the source code. ------------- Commit messages: - 8259050: Error recovery in lexer could be improved Changes: https://git.openjdk.java.net/jdk/pull/2239/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2239&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259050 Stats: 91 lines in 4 files changed: 79 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2239.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2239/head:pull/2239 PR: https://git.openjdk.java.net/jdk/pull/2239 From vromero at openjdk.java.net Tue Jan 26 15:56:48 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 26 Jan 2021 15:56:48 GMT Subject: [jdk16] RFR: 8259025: Record compact constructor using Objects.requireNonNull Message-ID: <8SIvf_KwdY5Er9rVtEmymYS_H9lR3TQsHoiDAHe5tj8=.32cc5c12-e9bb-4b48-aaf0-7e348238e666@github.com> Hi, This PR is basically a backport to 16 of the code already reviewed at [PR-1917](https://github.com/openjdk/jdk/pull/1917). TIA ------------- Commit messages: - 8259025: Record compact constructor using Objects.requireNonNull Changes: https://git.openjdk.java.net/jdk16/pull/133/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=133&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259025 Stats: 15 lines in 2 files changed: 11 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/133.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/133/head:pull/133 PR: https://git.openjdk.java.net/jdk16/pull/133 From mcimadamore at openjdk.java.net Tue Jan 26 16:03:42 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 26 Jan 2021 16:03:42 GMT Subject: [jdk16] RFR: 8259025: Record compact constructor using Objects.requireNonNull In-Reply-To: <8SIvf_KwdY5Er9rVtEmymYS_H9lR3TQsHoiDAHe5tj8=.32cc5c12-e9bb-4b48-aaf0-7e348238e666@github.com> References: <8SIvf_KwdY5Er9rVtEmymYS_H9lR3TQsHoiDAHe5tj8=.32cc5c12-e9bb-4b48-aaf0-7e348238e666@github.com> Message-ID: On Tue, 26 Jan 2021 15:51:37 GMT, Vicente Romero wrote: > Hi, > > This PR is basically a backport to 16 of the code already reviewed at [PR-1917](https://github.com/openjdk/jdk/pull/1917). > > TIA Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/133 From vromero at openjdk.java.net Tue Jan 26 16:03:43 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 26 Jan 2021 16:03:43 GMT Subject: [jdk16] Integrated: 8259025: Record compact constructor using Objects.requireNonNull In-Reply-To: <8SIvf_KwdY5Er9rVtEmymYS_H9lR3TQsHoiDAHe5tj8=.32cc5c12-e9bb-4b48-aaf0-7e348238e666@github.com> References: <8SIvf_KwdY5Er9rVtEmymYS_H9lR3TQsHoiDAHe5tj8=.32cc5c12-e9bb-4b48-aaf0-7e348238e666@github.com> Message-ID: On Tue, 26 Jan 2021 15:51:37 GMT, Vicente Romero wrote: > Hi, > > This PR is basically a backport to 16 of the code already reviewed at [PR-1917](https://github.com/openjdk/jdk/pull/1917). > > TIA This pull request has now been integrated. Changeset: 408772c9 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk16/commit/408772c9 Stats: 15 lines in 2 files changed: 11 ins; 1 del; 3 mod 8259025: Record compact constructor using Objects.requireNonNull Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk16/pull/133 From vromero at openjdk.java.net Wed Jan 27 06:36:42 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 27 Jan 2021 06:36:42 GMT Subject: RFR: 8259050: Error recovery in lexer could be improved In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 14:00:20 GMT, Jan Lahoda wrote: > Consider code like: > public class BrokenEscape { > private String s = "\uaaa"; > } > (note the broken escape). This produces: > $ javac BrokenEscape.java > BrokenEscape.java:2: error: illegal unicode escape > private String s = "\uaaa"; > ^ > BrokenEscape.java:2: error: unclosed string literal > private String s = "\uaaa"; > ^ > 2 errors > > After this patch, it produces: > $ javac BrokenEscape.java > BrokenEscape.java:2: error: illegal unicode escape > private String s = "\uaaa"; > ^ > 1 error > which is the error message that used to be produced in the past. > > The patch also improves the AST for source levels where text blocks are not supported, but are in fact present in the source code. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2239 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Jan 27 06:38:45 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 27 Jan 2021 06:38:45 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 12:15:36 GMT, Jan Lahoda wrote: >> Jia Yanwei has updated the pull request incrementally with three additional commits since the last revision: >> >> - fix 8258897: wrong translation of capturing local classes inside nested lambdas >> - rename test case directory name >> - revert the experimental fix in 9dec0d2 > > test/langtools/tools/javac/lambda/8258897/CaptureVariables.java line 3: > >> 1: import java.util.function.Supplier; >> 2: >> 3: /** > > It would be nice to tweak the test to so that: > -the comment with `@test` is first, and imports follow > -`@test` is augmented with `/nodynamiccopyright/` > -`@bug` is added > -`@summary` is added > > (applies to both tests) @lahodaj I think the tests in this case can use the copyright header instead of `/nodynamiccopyright/`. What's your opinion? ------------- PR: https://git.openjdk.java.net/jdk/pull/1479 From jlahoda at openjdk.java.net Wed Jan 27 07:47:41 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 27 Jan 2021 07:47:41 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v3] In-Reply-To: References: Message-ID: <6nKFTYtNazynhistRx2QJVM6mqGqZrrd52gmlouD3rw=.9473817d-681e-48ab-b354-556a016eeaaf@github.com> On Wed, 27 Jan 2021 06:36:21 GMT, Guoxiong Li wrote: >> test/langtools/tools/javac/lambda/8258897/CaptureVariables.java line 3: >> >>> 1: import java.util.function.Supplier; >>> 2: >>> 3: /** >> >> It would be nice to tweak the test to so that: >> -the comment with `@test` is first, and imports follow >> -`@test` is augmented with `/nodynamiccopyright/` >> -`@bug` is added >> -`@summary` is added >> >> (applies to both tests) > > @lahodaj I think the tests in this case can use the copyright header instead of `/nodynamiccopyright/`. What's your opinion? @lgxbslgx - you are right, I am sorry. `/nodymiccopyright/` is used when line numbers are significant, and I somehow thought they are here, but you are right they are not. So there should be a normal header here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1479 From linuxhippy at gmail.com Wed Jan 27 10:47:32 2021 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 27 Jan 2021 11:47:32 +0100 Subject: Frequent c1 compiler crashes running IntelliJ with Openjdk 15 (JavaCallWrapper::JavaCallWrapper) Message-ID: Hi, Since I started using IntelliJ for working on the java2d opengl backend I get runtime crashes in C1, in the method JavaCallWrapper::JavaCallWrapper. I observed those crashes with both - fedora bundled openjdk as well as with a build of adoptopenjdk: Fedora-33: openjdk version "15.0.1" 2020-10-20 OpenJDK Runtime Environment 20.9 (build 15.0.1+9) AdoptOpenJDK: openjdk version "15.0.2" 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7) The crash log looks quite equal each time (log attached). I wonder, is this a known problem - is should I report it? Thanks, Clemens Current CompileTask: C1: 485187 64127 3 com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod (362 bytes) Stack: [0x00007fe2fc0fb000,0x00007fe2fc1fc000], sp=0x00007fe2fc1f8fc0, free space=1015k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7ded64] JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, Thread*)+0x1c4 V [libjvm.so+0x7e2253] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x183 V [libjvm.so+0x7e066c] JavaCalls::call_special(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x1cc V [libjvm.so+0xdfe55d] SystemDictionary::validate_protection_domain(InstanceKlass*, Handle, Handle, Thread*)+0x20d V [libjvm.so+0xe0113c] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0xb1c V [libjvm.so+0xe012ea] SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*)+0x2a V [libjvm.so+0xe026ce] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x2e V [libjvm.so+0x598baf] ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*)+0xdf V [libjvm.so+0x7bf7e0] ConstantPool::klass_at(int, Thread*)+0x60 V [libjvm.so+0x7b9d17] InstanceKlass::has_nest_member(InstanceKlass*, Thread*) const+0x397 V [libjvm.so+0x7bbbbe] InstanceKlass::nest_host(Thread*) [clone .part.349]+0x3ae V [libjvm.so+0x7bbd1c] InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x4c V [libjvm.so+0xc5b707] Reflection::verify_member_access(Klass const*, Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x207 V [libjvm.so+0xa17b21] LinkResolver::check_method_accessability(Klass*, Klass*, Klass*, methodHandle const&, Thread*)+0x61 V [libjvm.so+0xa18776] LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, Thread*)+0x3e6 V [libjvm.so+0xa1b947] LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, Thread*)+0x27 V [libjvm.so+0xa1bbb2] LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo const&)+0x32 V [libjvm.so+0x4d137c] ciEnv::get_method_by_index_impl(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x3ec V [libjvm.so+0x4d1910] ciEnv::get_method_by_index(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x310 V [libjvm.so+0x4f58ee] ciBytecodeStream::get_method(bool&, ciSignature**)+0x11e V [libjvm.so+0x407323] GraphBuilder::invoke(Bytecodes::Code)+0x33 V [libjvm.so+0x409667] GraphBuilder::iterate_bytecodes_for_block(int)+0x10b7 V [libjvm.so+0x40b0d4] GraphBuilder::iterate_all_blocks(bool)+0x174 V [libjvm.so+0x40cf30] GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x440 V [libjvm.so+0x410a72] IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x1d2 V [libjvm.so+0x4116b6] IR::IR(Compilation*, ciMethod*, int)+0xa6 V [libjvm.so+0x3f1586] Compilation::build_hir() [clone .part.95]+0x166 V [libjvm.so+0x3f1dd3] Compilation::compile_java_method()+0x3a3 V [libjvm.so+0x3f1f6f] Compilation::compile_method()+0x12f V [libjvm.so+0x3f23cc] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22c V [libjvm.so+0x3f2cae] Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xae V [libjvm.so+0x5720cc] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xeec V [libjvm.so+0x572eb8] CompileBroker::compiler_thread_loop()+0x5b8 V [libjvm.so+0xe50f8a] JavaThread::thread_main_inner()+0x1da V [libjvm.so+0xe55baf] Thread::call_run()+0xff V [libjvm.so+0xbc77e7] thread_native_entry(Thread*)+0xe7 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: java_error_in_idea_31897.log Type: text/x-log Size: 217416 bytes Desc: not available URL: From jlahoda at openjdk.java.net Wed Jan 27 11:02:42 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 27 Jan 2021 11:02:42 GMT Subject: Integrated: 8259050: Error recovery in lexer could be improved In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 14:00:20 GMT, Jan Lahoda wrote: > Consider code like: > public class BrokenEscape { > private String s = "\uaaa"; > } > (note the broken escape). This produces: > $ javac BrokenEscape.java > BrokenEscape.java:2: error: illegal unicode escape > private String s = "\uaaa"; > ^ > BrokenEscape.java:2: error: unclosed string literal > private String s = "\uaaa"; > ^ > 2 errors > > After this patch, it produces: > $ javac BrokenEscape.java > BrokenEscape.java:2: error: illegal unicode escape > private String s = "\uaaa"; > ^ > 1 error > which is the error message that used to be produced in the past. > > The patch also improves the AST for source levels where text blocks are not supported, but are in fact present in the source code. This pull request has now been integrated. Changeset: b3c8a528 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/b3c8a528 Stats: 91 lines in 4 files changed: 79 ins; 0 del; 12 mod 8259050: Error recovery in lexer could be improved Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2239 From github.com+3896345+hltj at openjdk.java.net Wed Jan 27 12:50:58 2021 From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei) Date: Wed, 27 Jan 2021 12:50:58 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v6] In-Reply-To: References: Message-ID: > **Issue:** > `javac` crashes with a NPE when compiling such code: > - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types) > - instance the local class in a nested lambda > > Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1: > > An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null > at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571) > at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45) > printing javac parameters to: /tmp/javac.20201126_141249.args > > The minimal reproducing code is: > > java > class Main { > static Runnable runnable = () -> { > boolean b0 = false; > String s0 = "hello"; > > class Local { > int i = s0.length(); > } > > Runnable dummy = () -> new Local(); > }; > } > > If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.: > > java > public class CaptureInt { > static Runnable runnable = () -> { > boolean b0 = false; > int i0 = 5; > > class Local { > int i = i0 + 2; > } > > Runnable dummy = () -> new Local(); > }; > > public static void main(String args[]) { > } > } > > **Reason & Experimental solution:** > > During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. > But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda. > My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda. > I'm not sure whether the code style as well as the solution itself are appropriate. Welcome any advice and better solution. Jia Yanwei has updated the pull request incrementally with one additional commit since the last revision: add copyright comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1479/files - new: https://git.openjdk.java.net/jdk/pull/1479/files/f142d14e..a4c6aec0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=04-05 Stats: 48 lines in 2 files changed: 46 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1479/head:pull/1479 PR: https://git.openjdk.java.net/jdk/pull/1479 From github.com+3896345+hltj at openjdk.java.net Wed Jan 27 12:50:58 2021 From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei) Date: Wed, 27 Jan 2021 12:50:58 GMT Subject: RFR: 8258897: wrong translation of capturing local classes inside nested lambdas [v3] In-Reply-To: <6nKFTYtNazynhistRx2QJVM6mqGqZrrd52gmlouD3rw=.9473817d-681e-48ab-b354-556a016eeaaf@github.com> References: <6nKFTYtNazynhistRx2QJVM6mqGqZrrd52gmlouD3rw=.9473817d-681e-48ab-b354-556a016eeaaf@github.com> Message-ID: On Wed, 27 Jan 2021 07:45:19 GMT, Jan Lahoda wrote: >> @lahodaj I think the tests in this case can use the copyright header instead of `/nodynamiccopyright/`. What's your opinion? > > @lgxbslgx - you are right, I am sorry. `/nodymiccopyright/` is used when line numbers are significant, and I somehow thought they are here, but you are right they are not. So there should be a normal header here. I added the copyright comments moments ago. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1479 From jay.a at outlook.in Wed Jan 27 13:58:02 2021 From: jay.a at outlook.in (Jayaprakash Artanareeswaran) Date: Wed, 27 Jan 2021 13:58:02 +0000 Subject: Reporting of pattern variable redefinition Message-ID: Hello, I am looking at the following code and wondering why Javac (from JDK 16, ea33) reports an error on the first line and not on the second: boolean b1 = (o instanceof String a) ? false : (o instanceof String a); // Error boolean b2 = (o instanceof String a) ? false : ((o instanceof String a) ? false : true); // No error Is reporting the first case required as the pattern variable "a" is not in scope in the false arm of the conditional expression anyway? Regards, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gavin.Bierman at oracle.com Wed Jan 27 16:45:26 2021 From: Gavin.Bierman at oracle.com (Gavin Bierman) Date: Wed, 27 Jan 2021 16:45:26 +0000 Subject: Reporting of pattern variable redefinition In-Reply-To: References: Message-ID: Hi Jay, This stuff is subtle! It isn?t a bug actually, but a deliberate design decision. The place to look is 6.3.1.4 of the draft spec (http://cr.openjdk.java.net/~gbierman/jep394/jep394-20210108/specs/patterns-instanceof-jls.html#jls-6.3.1.4 ) You?ll see at the end of that section a list of compile-time errors, the first error actually covers your example. Your next question is probably, ?But why, Gavin??. Here?s the thinking. We decided not to allow pattern variable declarations to syntactically appear twice but in ways where exactly one will be executed. Here?s an example: e ? (o instanceof String s) : (o instanceof String s) Note here, no matter the value of e, always one of the pattern variables will be initialised by pattern matching. So, we could have allowed this, but we decided not to. (At least not for now.) If we had supported it, then we would have to break some very deep-rooted assumptions in the language about declarations. We would have a Java where, depending on your viewpoint, declarations can be bifurcated or merged. We must thought that was too strange and unlike the Java we love today. (Imagine asking your IDE for the declaration of a variable, and seeing several things highlighted!?) So, to your example, the compiler is not complaining because it thinks ?a? is in scope in the false arm - try (o instanceof String a) ? false : ( a == ?hello?) and you?ll see that isn?t the case, but because it sees that you are trying to merge the two declarations of the String a pattern variable. Hope this helps! Gavin > On 27 Jan 2021, at 13:58, Jayaprakash Artanareeswaran wrote: > > Hello, > > I am looking at the following code and wondering why Javac (from JDK 16, ea33) reports an error on the first line and not on the second: > > boolean b1 = (o instanceof String a) ? false : (o instanceof String a); // Error > boolean b2 = (o instanceof String a) ? false : ((o instanceof String a) ? false : true); // No error > > Is reporting the first case required as the pattern variable "a" is not in scope in the false arm of the conditional expression anyway? > > Regards, > Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+13688759+lgxbslgx at openjdk.java.net Wed Jan 27 18:15:42 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 27 Jan 2021 18:15:42 GMT Subject: Integrated: 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 07:17:47 GMT, Guoxiong Li wrote: > Hi all, > > Currently, javac doesn't attribute unexpected super constructor invocation qualifier. Please see the following code. > > public class SuperConstructorCallInErrorClass extends Undefined1 { > public SuperConstructorCallInErrorClass(int i) { > new Undefined2() { public void test(int i) { Undefined3 u; } }.super(); //<------------------- > } > } > > The code `new Undefined2() { public void test(int i) { Undefined3 u; } }` isn't attributed by javac. > If we use options like `-XDshould-stop.at=FLOW -XDdev`, the compiler would crash. > > This patch fixes it and adds the corresponding test cases. > > Thank you for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: 0eed2c33 Author: Guoxiong Li Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/0eed2c33 Stats: 103 lines in 2 files changed: 103 ins; 0 del; 0 mod 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2021 From joe.darcy at oracle.com Wed Jan 27 22:30:16 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 Jan 2021 14:30:16 -0800 Subject: Pluggable Annotation Processing: problems from the IDE (IntelliJ) perspective In-Reply-To: References: Message-ID: Hi Anna, Thanks for the comments. For context, can you describe in more detail how IntelliJ is using javac and any other Java compilers? For example, is javac being invoked programmatically, or phases of it being subclassed, is a different compiler infrastructure used for incremental IDE usage versus generation of class files? For background, when JSR 269 was being developed, besides javac there was an independent implementation of the API being done in Eclipse. The Eclipse implementation was in the context of that IDE and was a successor to the earlier Eclipse implementation of the apt API. Eclipse provided incremental running of annotation processors in response to updated files, etc. My understanding is the apt implementation in Eclipse had more complete dependency tracking, but the JSR 269 API provides fuller mechanisms to implement an incremental re-running policy. As you note, internally javac currently drops the originating elements information as it is not used in a batch compilation context. The interfaces for the environment objects, Filer, etc. were designed to be wrappable, but that is problematic if users do instanceof tests or rely on other implementation-class functionality. During JSR 269, the utility of having a standard AST API was recognized, but it was technically infeasible to have an AST-level API that worked well across two compiler that didn't shave the same code base, javac and ecj in particular. Thanks, -Joe On 1/26/2021 4:05 AM, Anna Kozlova wrote: > Hi all, > > As we lately see the?`JSR 269 - Pluggable Annotation Processing - > Maintenance Review ballot', we would like to share our troubles with > this API from the IDE perspective. It isn't connected to the latest > changes in the JSR so I was advised to post our thoughts here. > > *Initial setup:* > IntelliJ IDEA allows incremental compilation, which means that only > changed code and its dependencies are recompiled instead of the whole > project (workspace)/module (project). The task is complicated by > itself but when people use Annotation Processors it becomes sometimes > impossible though, it seems, we may get all information we need to > build source - output relation and thus enable incremental compilation. > > *Problem description:* > When a processor generates a java source code, a bytecode or a > resource file, it uses "create*" methods from the > javax.annotation.processing.Filer interface.?Every "create*" method > has a vararg parameter "originatingElements" which are supposed to be > "type or package or module elements causally associated with the > creation of this file, may be elided or null".?Those elements are > supposed to be used by the processing environment to register and > track dependencies between generated classes and existing code > elements (classes, methods, fields) used by the processor to produce > the generated code.?The default Filter implementation by javac simply > ignores this data. Internally, javac calls JavaFileManager to actually > create and store the generated data, but, unfortunately, the > originatingElements passed by processors are already lost.?When > generating bytecode, javac uses the > javax.tools.JavaFileManager.getJavaFileForOutput() method and passes > the "sibling" argument, pointing to the corresponding source file. > This information is used by our build system to register > source->output dependencies and facilitate incremental > compilation.?However, if data generation is initiated by an annotation > processor, the "sibling" parameter is always null. One could expect it > to point to a source file object containing originatingElements passed > by the AP. > (Another problem is that there are multiple originating elements > potentially corresponding to multiple source files, but there is only > a single "sibling" reference in the getJavaFileForOutput() > method.)?Because originatingElements are ignored, our build system > cannot track dependencies between source files and AP-generated code. > So we should always assume the worst scenario and recompile the whole > module or a project whenever we detect that generated code is affected. > > Without this information the detection itself is not as reliable as it > could have been. So if a project heavily relies on AP code generation, > we cannot provide the best incremental compilation experience because > of lack of data. > > *Current solution:* > > The javadoc for create* methods in the Filer interface suggests that > > "This information may be used in an incremental environment to > determine the need to rerun processors or remove generated files. > Non-incremental environments may ignore the originating element > information." > > In order to get access to originatingElements, our build system has to > provide its own implementation of Filer interface. We do this by > wrapping the original Filter implementation with a wrapper that > registers originatingElements and delegates the call to original > Filter implementation.?This is on its own a non-trivial task, because > the whole API provides no direct ways neither to access the > originatingElements nor to register a custom Filter implementation. > Just to wrap the original Filer implementation, we have to > re-implement the AP discovery logic, and then use the > JavaCompiler.CompilationTask.setProcessors() method that would > explicitly configure processor objects. Every Processor object is in > turn wrapped with our "wrapper", whose the only purpose is to make > sure the AP will get a wrapped Filer and not the original one. > > *Problems with the current solution:* > > This approach generally works, but it leads to additional problems on > the annotation processor side. Unfortunately, many popular processors > assume that passed objects like ProcessingEnvironment and Filer have > certain implementations. The processor code may heavily rely on this > assumption, e.g. cast the passed object to implementation or use > instanceof checks on it. So if processor gets a wrapped > ProcessingEnvironment, it would fail to execute further.?As a result, > user's project just stops compiling. > > Another problem caused by such wrapping approach, is javac's so called > Tree API. An annotation processor may use the Tree API for its > internal logic. The only way for the processor to obtain a reference > to this API Facade is a call > com.sun.source.util.Trees.instance(ProcessingEnvironment). If > processor passes the wrapped ProcessingEnvironment object to the > Trees.instance() method, it won't work, because its implementation > internally uses an instanceof check itself! > > Our current approach is to detect such situation and provide AP > developer with hints in the error message. In order to make the > processor work in our incremental environment, the AP developer has to > write additional code that "unwraps" the passed ProcessingEnvironment > object and uses the unwrapped object to initialize the Tree API.?Such > a situation, of course, is far from ideal: AP developers should not > write code to please an IDE. > > *What can improve the situation:* > So would be great if following problems were addressed in the API: > there should be a direct way to access originatingElements. Ideally > there accessing this data should not make AP developers to change > their code. If code changes are inevitable on AP side, those changes > should be possible without making assumptions about inteface > implementations. There should be a standard way to get access to Tree > API as well, or, even better, the original API should be extended to > make implementation of complex processing logic possible without > semi-closed Tree API. > > Thanks, > Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jan 28 02:12:27 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 27 Jan 2021 18:12:27 -0800 Subject: Pluggable Annotation Processing: problems from the IDE (IntelliJ) perspective In-Reply-To: References: Message-ID: <90b43299-1755-2f71-c7c1-9a598daf295c@oracle.com> On 1/26/21 4:05 AM, Anna Kozlova wrote: > There should be a standard way to get access to Tree API as well, or, > even better, the original API should be extended to make > implementation of complex processing logic possible without > semi-closed Tree API. 1. See Trees.instance(ProcessingEnvironment) https://docs.oracle.com/en/java/javase/14/docs/api/jdk.compiler/com/sun/source/util/Trees.html#instance(javax.annotation.processing.ProcessingEnvironment) 2. The Tree API is not "semi-closed". Although it is not a Java SE API in `java.*` or `javax.*`, it is a public supported JDK API, as evidenced by its inclusion in the JDK API documentation. -- Jon From maurizio.cimadamore at oracle.com Thu Jan 28 10:34:42 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 10:34:42 +0000 Subject: Frequent c1 compiler crashes running IntelliJ with Openjdk 15 (JavaCallWrapper::JavaCallWrapper) In-Reply-To: References: Message-ID: Hi, I believe you reached out on the wrong mailing list - the names are a bit confusing. compiler-dev --> javac (e.g. static compiler) hotspot-compiler-dev [1] -> hotspot C1/C2 compilers I believe you might want to reach the latter? [1] - https://mail.openjdk.java.net/mailman/listinfo/hotspot-compiler-dev On Wed, 2021-01-27 at 11:47 +0100, Clemens Eisserer wrote: Hi, Since I started using IntelliJ for working on the java2d opengl backend I get runtime crashes in C1, in the method JavaCallWrapper::JavaCallWrapper. I observed those crashes with both - fedora bundled openjdk as well as with a build of adoptopenjdk: Fedora-33: openjdk version "15.0.1" 2020-10-20 OpenJDK Runtime Environment 20.9 (build 15.0.1+9) AdoptOpenJDK: openjdk version "15.0.2" 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.2+7) The crash log looks quite equal each time (log attached). I wonder, is this a known problem - is should I report it? Thanks, Clemens Current CompileTask: C1: 485187 64127 3 com.intellij.codeInspection.sameParameterValue.SameParameterValueInspection$LocalSameParameterValueInspection$1::visitMethod (362 bytes) Stack: [0x00007fe2fc0fb000,0x00007fe2fc1fc000], sp=0x00007fe2fc1f8fc0, free space=1015k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7ded64] JavaCallWrapper::JavaCallWrapper(methodHandle const&, Handle, JavaValue*, Thread*)+0x1c4 V [libjvm.so+0x7e2253] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x183 V [libjvm.so+0x7e066c] JavaCalls::call_special(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, Handle, Thread*)+0x1cc V [libjvm.so+0xdfe55d] SystemDictionary::validate_protection_domain(InstanceKlass*, Handle, Handle, Thread*)+0x20d V [libjvm.so+0xe0113c] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0xb1c V [libjvm.so+0xe012ea] SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*)+0x2a V [libjvm.so+0xe026ce] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x2e V [libjvm.so+0x598baf] ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*)+0xdf V [libjvm.so+0x7bf7e0] ConstantPool::klass_at(int, Thread*)+0x60 V [libjvm.so+0x7b9d17] InstanceKlass::has_nest_member(InstanceKlass*, Thread*) const+0x397 V [libjvm.so+0x7bbbbe] InstanceKlass::nest_host(Thread*) [clone .part.349]+0x3ae V [libjvm.so+0x7bbd1c] InstanceKlass::has_nestmate_access_to(InstanceKlass*, Thread*)+0x4c V [libjvm.so+0xc5b707] Reflection::verify_member_access(Klass const*, Klass const*, Klass const*, AccessFlags, bool, bool, Thread*)+0x207 V [libjvm.so+0xa17b21] LinkResolver::check_method_accessability(Klass*, Klass*, Klass*, methodHandle const&, Thread*)+0x61 V [libjvm.so+0xa18776] LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, Thread*)+0x3e6 V [libjvm.so+0xa1b947] LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, Thread*)+0x27 V [libjvm.so+0xa1bbb2] LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo const&)+0x32 V [libjvm.so+0x4d137c] ciEnv::get_method_by_index_impl(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x3ec V [libjvm.so+0x4d1910] ciEnv::get_method_by_index(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x310 V [libjvm.so+0x4f58ee] ciBytecodeStream::get_method(bool&, ciSignature**)+0x11e V [libjvm.so+0x407323] GraphBuilder::invoke(Bytecodes::Code)+0x33 V [libjvm.so+0x409667] GraphBuilder::iterate_bytecodes_for_block(int)+0x10b7 V [libjvm.so+0x40b0d4] GraphBuilder::iterate_all_blocks(bool)+0x174 V [libjvm.so+0x40cf30] GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x440 V [libjvm.so+0x410a72] IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x1d2 V [libjvm.so+0x4116b6] IR::IR(Compilation*, ciMethod*, int)+0xa6 V [libjvm.so+0x3f1586] Compilation::build_hir() [clone .part.95]+0x166 V [libjvm.so+0x3f1dd3] Compilation::compile_java_method()+0x3a3 V [libjvm.so+0x3f1f6f] Compilation::compile_method()+0x12f V [libjvm.so+0x3f23cc] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x22c V [libjvm.so+0x3f2cae] Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xae V [libjvm.so+0x5720cc] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xeec V [libjvm.so+0x572eb8] CompileBroker::compiler_thread_loop()+0x5b8 V [libjvm.so+0xe50f8a] JavaThread::thread_main_inner()+0x1da V [libjvm.so+0xe55baf] Thread::call_run()+0xff V [libjvm.so+0xbc77e7] thread_native_entry(Thread*)+0xe7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Thu Jan 28 13:58:47 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 28 Jan 2021 14:58:47 +0100 Subject: Possibly inefficient code gen of instanceof patterns Message-ID: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> Hi, as an experiment, I changed some code to use instanceof pattern matching to see if there's any effect on the generated code. Consider j.l.i.BootstrapMethodInvoker.invoke, which I changed from: private static Object invoke(MethodHandle bootstrapMethod, Lookup caller, String name, Object type) throws Throwable { if (type instanceof Class) { return bootstrapMethod.invoke(caller, name, (Class)type); } else { return bootstrapMethod.invoke(caller, name, (MethodType)type); } } .. to: private static Object invoke(MethodHandle bootstrapMethod, Lookup caller, String name, Object type) throws Throwable { if (type instanceof Class c) { return bootstrapMethod.invoke(caller, name, c); } else { return bootstrapMethod.invoke(caller, name, (MethodType)type); } } This seem to grow the bytecode size ever so slightly. Looking at the javap output it seems some of that might be redundant and possibly fixable: private static java.lang.Object invoke(java.lang.invoke.MethodHandle, java.lang.invoke.MethodHandles$Lookup, java.lang.String, java.lang.Object) throws java.lang.Throwable; descriptor: (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; flags: (0x000a) ACC_PRIVATE, ACC_STATIC Code: stack=4, locals=6, args_size=4 0: aload_3 1: astore 5 3: aload 5 5: instanceof #46 // class java/lang/Class 8: ifeq 27 11: aload 5 13: checkcast #46 // class java/lang/Class 16: astore 4 18: aload_0 19: aload_1 20: aload_2 21: aload 4 23: invokevirtual #169 // Method java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; 26: areturn 27: aload_0 28: aload_1 29: aload_2 30: aload_3 31: checkcast #61 // class java/lang/invoke/MethodType 34: invokevirtual #172 // Method java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; 37: areturn LineNumberTable: line 226: 0 line 227: 18 line 229: 27 LocalVariableTable: Start Length Slot Name Signature 18 9 4 c Ljava/lang/Class; 0 38 0 bootstrapMethod Ljava/lang/invoke/MethodHandle; 0 38 1 caller Ljava/lang/invoke/MethodHandles$Lookup; 0 38 2 name Ljava/lang/String; 0 38 3 type Ljava/lang/Object; StackMapTable: number_of_entries = 1 frame_type = 27 /* same */ Exceptions: throws java.lang.Throwable - The storing and loading of the type argument into slot 5 seem completely redundant: couldn't we load slot 3 in each place that now loads slot 5? - Storing c into a new slot 4 also seem unfortunate, but is more understandable (I guess this is a limitation of the LVT not allowing overlapping a new variable with a new type into the same slot?) - It's also unfortunate that the checkcast now bubbles up so that the result has to be stored and loaded again, but I guess pushing the checkcast down to just before the invokevirtual as in the other branch would go against some specification. My gut feeling - without knowing much about javac - is that at least the use of a temporary slot (5) could be optimized away here. WDYT? For reference the baseline method without the pattern matching compiles to this: private static java.lang.Object invoke(java.lang.invoke.MethodHandle, java.lang.invoke.MethodHandles$Lookup, java.lang.String, java.lang.Object) throws java.lang.Throwable; descriptor: (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; flags: (0x000a) ACC_PRIVATE, ACC_STATIC Code: stack=4, locals=4, args_size=4 0: aload_3 1: instanceof #46 // class java/lang/Class 4: ifeq 18 7: aload_0 8: aload_1 9: aload_2 10: aload_3 11: checkcast #46 // class java/lang/Class 14: invokevirtual #169 // Method java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; 17: areturn 18: aload_0 19: aload_1 20: aload_2 21: aload_3 22: checkcast #61 // class java/lang/invoke/MethodType 25: invokevirtual #172 // Method java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; 28: areturn LineNumberTable: line 226: 0 line 227: 7 line 229: 18 LocalVariableTable: Start Length Slot Name Signature 0 29 0 bootstrapMethod Ljava/lang/invoke/MethodHandle; 0 29 1 caller Ljava/lang/invoke/MethodHandles$Lookup; 0 29 2 name Ljava/lang/String; 0 29 3 type Ljava/lang/Object; StackMapTable: number_of_entries = 1 frame_type = 18 /* same */ Exceptions: throws java.lang.Throwable Thanks! /Claes From volker.simonis at gmail.com Thu Jan 28 14:08:23 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Jan 2021 15:08:23 +0100 Subject: Possibly inefficient code gen of instanceof patterns In-Reply-To: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> References: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> Message-ID: I understand that this question is about javac but nevertheless it would be interesting to know if and if yes how your little change affects the C2 generated assembly code. Have you checked that? Claes Redestad schrieb am Do., 28. Jan. 2021, 14:59: > Hi, > > as an experiment, I changed some code to use instanceof pattern > matching to see if there's any effect on the generated code. > > Consider j.l.i.BootstrapMethodInvoker.invoke, which I changed from: > > private static Object invoke(MethodHandle bootstrapMethod, Lookup > caller, > String name, Object type) throws > Throwable { > if (type instanceof Class) { > return bootstrapMethod.invoke(caller, name, (Class)type); > } else { > return bootstrapMethod.invoke(caller, name, (MethodType)type); > } > } > > .. to: > > private static Object invoke(MethodHandle bootstrapMethod, Lookup > caller, > String name, Object type) throws > Throwable { > if (type instanceof Class c) { > return bootstrapMethod.invoke(caller, name, c); > } else { > return bootstrapMethod.invoke(caller, name, (MethodType)type); > } > } > > This seem to grow the bytecode size ever so slightly. Looking at the > javap output it seems some of that might be redundant and possibly > fixable: > > private static java.lang.Object invoke(java.lang.invoke.MethodHandle, > java.lang.invoke.MethodHandles$Lookup, java.lang.String, > java.lang.Object) throws java.lang.Throwable; > descriptor: > > (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > flags: (0x000a) ACC_PRIVATE, ACC_STATIC > Code: > stack=4, locals=6, args_size=4 > 0: aload_3 > 1: astore 5 > 3: aload 5 > 5: instanceof #46 // class java/lang/Class > 8: ifeq 27 > 11: aload 5 > 13: checkcast #46 // class java/lang/Class > 16: astore 4 > 18: aload_0 > 19: aload_1 > 20: aload_2 > 21: aload 4 > 23: invokevirtual #169 // Method > > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; > 26: areturn > 27: aload_0 > 28: aload_1 > 29: aload_2 > 30: aload_3 > 31: checkcast #61 // class > java/lang/invoke/MethodType > 34: invokevirtual #172 // Method > > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; > 37: areturn > LineNumberTable: > line 226: 0 > line 227: 18 > line 229: 27 > LocalVariableTable: > Start Length Slot Name Signature > 18 9 4 c Ljava/lang/Class; > 0 38 0 bootstrapMethod > Ljava/lang/invoke/MethodHandle; > 0 38 1 caller > Ljava/lang/invoke/MethodHandles$Lookup; > 0 38 2 name Ljava/lang/String; > 0 38 3 type Ljava/lang/Object; > StackMapTable: number_of_entries = 1 > frame_type = 27 /* same */ > Exceptions: > throws java.lang.Throwable > > - The storing and loading of the type argument into slot 5 seem > completely redundant: couldn't we load slot 3 in each place that > now loads slot 5? > > - Storing c into a new slot 4 also seem unfortunate, but is more > understandable (I guess this is a limitation of the LVT not allowing > overlapping a new variable with a new type into the same slot?) > > - It's also unfortunate that the checkcast now bubbles up so that the > result has to be stored and loaded again, but I guess pushing the > checkcast down to just before the invokevirtual as in the other > branch would go against some specification. > > My gut feeling - without knowing much about javac - is that at least > the use of a temporary slot (5) could be optimized away here. > > WDYT? > > For reference the baseline method without the pattern matching > compiles to this: > > private static java.lang.Object invoke(java.lang.invoke.MethodHandle, > java.lang.invoke.MethodHandles$Lookup, java.lang.String, > java.lang.Object) throws java.lang.Throwable; > descriptor: > > (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > flags: (0x000a) ACC_PRIVATE, ACC_STATIC > Code: > stack=4, locals=4, args_size=4 > 0: aload_3 > 1: instanceof #46 // class java/lang/Class > 4: ifeq 18 > 7: aload_0 > 8: aload_1 > 9: aload_2 > 10: aload_3 > 11: checkcast #46 // class java/lang/Class > 14: invokevirtual #169 // Method > > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; > 17: areturn > 18: aload_0 > 19: aload_1 > 20: aload_2 > 21: aload_3 > 22: checkcast #61 // class > java/lang/invoke/MethodType > 25: invokevirtual #172 // Method > > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; > 28: areturn > LineNumberTable: > line 226: 0 > line 227: 7 > line 229: 18 > LocalVariableTable: > Start Length Slot Name Signature > 0 29 0 bootstrapMethod > Ljava/lang/invoke/MethodHandle; > 0 29 1 caller > Ljava/lang/invoke/MethodHandles$Lookup; > 0 29 2 name Ljava/lang/String; > 0 29 3 type Ljava/lang/Object; > StackMapTable: number_of_entries = 1 > frame_type = 18 /* same */ > Exceptions: > throws java.lang.Throwable > > Thanks! > > /Claes > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Thu Jan 28 14:14:36 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 28 Jan 2021 15:14:36 +0100 Subject: Possibly inefficient code gen of instanceof patterns In-Reply-To: References: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> Message-ID: <1b2e7ce6-3f51-9f41-8841-506f20d86d4c@oracle.com> I haven't, no. Increasing bytecode size like this has historically been shown to cause issues with some inlining heuristics that (unfortunately) take bytecode size into consideration. /Claes On 2021-01-28 15:08, Volker Simonis wrote: > I understand that this question is about javac but nevertheless it would > be interesting to know if and if yes how your little change affects the > C2 generated assembly code. Have you checked that? > > Claes Redestad > schrieb am Do., 28. Jan. 2021, 14:59: > > Hi, > > as an experiment, I changed some code to use instanceof pattern > matching to see if there's any effect on the generated code. > > Consider j.l.i.BootstrapMethodInvoker.invoke, which I changed from: > > ? ? ?private static Object invoke(MethodHandle bootstrapMethod, Lookup > caller, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? String name, Object type) throws > Throwable { > ? ? ? ? ?if (type instanceof Class) { > ? ? ? ? ? ? ?return bootstrapMethod.invoke(caller, name, (Class)type); > ? ? ? ? ?} else { > ? ? ? ? ? ? ?return bootstrapMethod.invoke(caller, name, > (MethodType)type); > ? ? ? ? ?} > ? ? ?} > > .. to: > > ? ? ?private static Object invoke(MethodHandle bootstrapMethod, Lookup > caller, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? String name, Object type) throws > Throwable { > ? ? ? ? ?if (type instanceof Class c) { > ? ? ? ? ? ? ?return bootstrapMethod.invoke(caller, name, c); > ? ? ? ? ?} else { > ? ? ? ? ? ? ?return bootstrapMethod.invoke(caller, name, > (MethodType)type); > ? ? ? ? ?} > ? ? ?} > > This seem to grow the bytecode size ever so slightly. Looking at the > javap output it seems some of that might be redundant and possibly > fixable: > > ? ?private static java.lang.Object > invoke(java.lang.invoke.MethodHandle, > java.lang.invoke.MethodHandles$Lookup, java.lang.String, > java.lang.Object) throws java.lang.Throwable; > ? ? ?descriptor: > (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > ? ? ?flags: (0x000a) ACC_PRIVATE, ACC_STATIC > ? ? ?Code: > ? ? ? ?stack=4, locals=6, args_size=4 > ? ? ? ? ? 0: aload_3 > ? ? ? ? ? 1: astore? ? ? ? 5 > ? ? ? ? ? 3: aload? ? ? ? ?5 > ? ? ? ? ? 5: instanceof? ? #46? ? ? ? ? ? ? ? ?// class java/lang/Class > ? ? ? ? ? 8: ifeq? ? ? ? ? 27 > ? ? ? ? ?11: aload? ? ? ? ?5 > ? ? ? ? ?13: checkcast? ? ?#46? ? ? ? ? ? ? ? ?// class java/lang/Class > ? ? ? ? ?16: astore? ? ? ? 4 > ? ? ? ? ?18: aload_0 > ? ? ? ? ?19: aload_1 > ? ? ? ? ?20: aload_2 > ? ? ? ? ?21: aload? ? ? ? ?4 > ? ? ? ? ?23: invokevirtual #169? ? ? ? ? ? ? ? // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; > ? ? ? ? ?26: areturn > ? ? ? ? ?27: aload_0 > ? ? ? ? ?28: aload_1 > ? ? ? ? ?29: aload_2 > ? ? ? ? ?30: aload_3 > ? ? ? ? ?31: checkcast? ? ?#61? ? ? ? ? ? ? ? ?// class > java/lang/invoke/MethodType > ? ? ? ? ?34: invokevirtual #172? ? ? ? ? ? ? ? // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; > ? ? ? ? ?37: areturn > ? ? ? ?LineNumberTable: > ? ? ? ? ?line 226: 0 > ? ? ? ? ?line 227: 18 > ? ? ? ? ?line 229: 27 > ? ? ? ?LocalVariableTable: > ? ? ? ? ?Start? Length? Slot? Name? ?Signature > ? ? ? ? ? ? 18? ? ? ?9? ? ?4? ? ?c? ?Ljava/lang/Class; > ? ? ? ? ? ? ?0? ? ? 38? ? ?0 bootstrapMethod > Ljava/lang/invoke/MethodHandle; > ? ? ? ? ? ? ?0? ? ? 38? ? ?1 caller > Ljava/lang/invoke/MethodHandles$Lookup; > ? ? ? ? ? ? ?0? ? ? 38? ? ?2? name? ?Ljava/lang/String; > ? ? ? ? ? ? ?0? ? ? 38? ? ?3? type? ?Ljava/lang/Object; > ? ? ? ?StackMapTable: number_of_entries = 1 > ? ? ? ? ?frame_type = 27 /* same */ > ? ? ?Exceptions: > ? ? ? ?throws java.lang.Throwable > > - The storing and loading of the type argument into slot 5 seem > completely redundant: couldn't we load slot 3 in each place that > now loads slot 5? > > - Storing c into a new slot 4 also seem unfortunate, but is more > understandable (I guess this is a limitation of the LVT not allowing > overlapping a new variable with a new type into the same slot?) > > - It's also unfortunate that the checkcast now bubbles up so that the > result has to be stored and loaded again, but I guess pushing the > checkcast down to just before the invokevirtual as in the other > branch would go against some specification. > > My gut feeling - without knowing much about javac - is that at least > the use of a temporary slot (5) could be optimized away here. > > WDYT? > > For reference the baseline method without the pattern matching > compiles to this: > > ? ?private static java.lang.Object > invoke(java.lang.invoke.MethodHandle, > java.lang.invoke.MethodHandles$Lookup, java.lang.String, > java.lang.Object) throws java.lang.Throwable; > ? ? ?descriptor: > (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > ? ? ?flags: (0x000a) ACC_PRIVATE, ACC_STATIC > ? ? ?Code: > ? ? ? ?stack=4, locals=4, args_size=4 > ? ? ? ? ? 0: aload_3 > ? ? ? ? ? 1: instanceof? ? #46? ? ? ? ? ? ? ? ?// class java/lang/Class > ? ? ? ? ? 4: ifeq? ? ? ? ? 18 > ? ? ? ? ? 7: aload_0 > ? ? ? ? ? 8: aload_1 > ? ? ? ? ? 9: aload_2 > ? ? ? ? ?10: aload_3 > ? ? ? ? ?11: checkcast? ? ?#46? ? ? ? ? ? ? ? ?// class java/lang/Class > ? ? ? ? ?14: invokevirtual #169? ? ? ? ? ? ? ? // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; > ? ? ? ? ?17: areturn > ? ? ? ? ?18: aload_0 > ? ? ? ? ?19: aload_1 > ? ? ? ? ?20: aload_2 > ? ? ? ? ?21: aload_3 > ? ? ? ? ?22: checkcast? ? ?#61? ? ? ? ? ? ? ? ?// class > java/lang/invoke/MethodType > ? ? ? ? ?25: invokevirtual #172? ? ? ? ? ? ? ? // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; > ? ? ? ? ?28: areturn > ? ? ? ?LineNumberTable: > ? ? ? ? ?line 226: 0 > ? ? ? ? ?line 227: 7 > ? ? ? ? ?line 229: 18 > ? ? ? ?LocalVariableTable: > ? ? ? ? ?Start? Length? Slot? Name? ?Signature > ? ? ? ? ? ? ?0? ? ? 29? ? ?0 bootstrapMethod > Ljava/lang/invoke/MethodHandle; > ? ? ? ? ? ? ?0? ? ? 29? ? ?1 caller > Ljava/lang/invoke/MethodHandles$Lookup; > ? ? ? ? ? ? ?0? ? ? 29? ? ?2? name? ?Ljava/lang/String; > ? ? ? ? ? ? ?0? ? ? 29? ? ?3? type? ?Ljava/lang/Object; > ? ? ? ?StackMapTable: number_of_entries = 1 > ? ? ? ? ?frame_type = 18 /* same */ > ? ? ?Exceptions: > ? ? ? ?throws java.lang.Throwable > > Thanks! > > /Claes > From forax at univ-mlv.fr Thu Jan 28 14:25:24 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 28 Jan 2021 15:25:24 +0100 (CET) Subject: Possibly inefficient code gen of instanceof patterns In-Reply-To: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> References: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> Message-ID: <500752481.452074.1611843924147.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "compiler-dev" > Envoy?: Jeudi 28 Janvier 2021 14:58:47 > Objet: Possibly inefficient code gen of instanceof patterns > Hi, > > as an experiment, I changed some code to use instanceof pattern > matching to see if there's any effect on the generated code. > > Consider j.l.i.BootstrapMethodInvoker.invoke, which I changed from: > > private static Object invoke(MethodHandle bootstrapMethod, Lookup > caller, > String name, Object type) throws > Throwable { > if (type instanceof Class) { > return bootstrapMethod.invoke(caller, name, (Class)type); > } else { > return bootstrapMethod.invoke(caller, name, (MethodType)type); > } > } > > .. to: > > private static Object invoke(MethodHandle bootstrapMethod, Lookup > caller, > String name, Object type) throws > Throwable { > if (type instanceof Class c) { > return bootstrapMethod.invoke(caller, name, c); > } else { > return bootstrapMethod.invoke(caller, name, (MethodType)type); > } > } It should be "type instanceof Class c" BTW. > > This seem to grow the bytecode size ever so slightly. Looking at the > javap output it seems some of that might be redundant and possibly > fixable: > > private static java.lang.Object invoke(java.lang.invoke.MethodHandle, > java.lang.invoke.MethodHandles$Lookup, java.lang.String, > java.lang.Object) throws java.lang.Throwable; > descriptor: > (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > flags: (0x000a) ACC_PRIVATE, ACC_STATIC > Code: > stack=4, locals=6, args_size=4 > 0: aload_3 > 1: astore 5 > 3: aload 5 > 5: instanceof #46 // class java/lang/Class > 8: ifeq 27 > 11: aload 5 > 13: checkcast #46 // class java/lang/Class > 16: astore 4 > 18: aload_0 > 19: aload_1 > 20: aload_2 > 21: aload 4 > 23: invokevirtual #169 // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; > 26: areturn > 27: aload_0 > 28: aload_1 > 29: aload_2 > 30: aload_3 > 31: checkcast #61 // class > java/lang/invoke/MethodType > 34: invokevirtual #172 // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; > 37: areturn > LineNumberTable: > line 226: 0 > line 227: 18 > line 229: 27 > LocalVariableTable: > Start Length Slot Name Signature > 18 9 4 c Ljava/lang/Class; > 0 38 0 bootstrapMethod > Ljava/lang/invoke/MethodHandle; > 0 38 1 caller > Ljava/lang/invoke/MethodHandles$Lookup; > 0 38 2 name Ljava/lang/String; > 0 38 3 type Ljava/lang/Object; > StackMapTable: number_of_entries = 1 > frame_type = 27 /* same */ > Exceptions: > throws java.lang.Throwable > > - The storing and loading of the type argument into slot 5 seem > completely redundant: couldn't we load slot 3 in each place that > now loads slot 5? yes, it looks like a bug. > > - Storing c into a new slot 4 also seem unfortunate, but is more > understandable (I guess this is a limitation of the LVT not allowing > overlapping a new variable with a new type into the same slot?) The new syntax declares a supplementary local variable so it has to be visible in the bytecode for debuggers. > > - It's also unfortunate that the checkcast now bubbles up so that the > result has to be stored and loaded again, but I guess pushing the > checkcast down to just before the invokevirtual as in the other > branch would go against some specification. Modern javac (i don't know the previous version, before java 1.4) never had such "optimization". As a grey beard, when the enhanced for was introduced, the for(:), we had the very similar discussions, because the enhanced for introduces a supplementary variable and usually a cast because of the erasure of generics, so the bytecode is a little more verbose. In the end, yes, it inflates the generated bytecodes at bit because it creates a new local variable but the java code is more readable because it creates a new local variable :) > > My gut feeling - without knowing much about javac - is that at least > the use of a temporary slot (5) could be optimized away here. I agree. > > WDYT? > > For reference the baseline method without the pattern matching > compiles to this: > > private static java.lang.Object invoke(java.lang.invoke.MethodHandle, > java.lang.invoke.MethodHandles$Lookup, java.lang.String, > java.lang.Object) throws java.lang.Throwable; > descriptor: > (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > flags: (0x000a) ACC_PRIVATE, ACC_STATIC > Code: > stack=4, locals=4, args_size=4 > 0: aload_3 > 1: instanceof #46 // class java/lang/Class > 4: ifeq 18 > 7: aload_0 > 8: aload_1 > 9: aload_2 > 10: aload_3 > 11: checkcast #46 // class java/lang/Class > 14: invokevirtual #169 // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; > 17: areturn > 18: aload_0 > 19: aload_1 > 20: aload_2 > 21: aload_3 > 22: checkcast #61 // class > java/lang/invoke/MethodType > 25: invokevirtual #172 // Method > java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; > 28: areturn > LineNumberTable: > line 226: 0 > line 227: 7 > line 229: 18 > LocalVariableTable: > Start Length Slot Name Signature > 0 29 0 bootstrapMethod > Ljava/lang/invoke/MethodHandle; > 0 29 1 caller > Ljava/lang/invoke/MethodHandles$Lookup; > 0 29 2 name Ljava/lang/String; > 0 29 3 type Ljava/lang/Object; > StackMapTable: number_of_entries = 1 > frame_type = 18 /* same */ > Exceptions: > throws java.lang.Throwable > > Thanks! > > /Claes R?mi From jan.lahoda at oracle.com Thu Jan 28 15:11:02 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 28 Jan 2021 16:11:02 +0100 Subject: Possibly inefficient code gen of instanceof patterns In-Reply-To: <500752481.452074.1611843924147.JavaMail.zimbra@u-pem.fr> References: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> <500752481.452074.1611843924147.JavaMail.zimbra@u-pem.fr> Message-ID: <9cdb6608-ea9a-59d2-f7f9-d0af505f6f6c@oracle.com> Hi, I've filled: https://bugs.openjdk.java.net/browse/JDK-8260593 Thanks, ??? Jan On 28. 01. 21 15:25, Remi Forax wrote: > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "compiler-dev" >> Envoy?: Jeudi 28 Janvier 2021 14:58:47 >> Objet: Possibly inefficient code gen of instanceof patterns >> Hi, >> >> as an experiment, I changed some code to use instanceof pattern >> matching to see if there's any effect on the generated code. >> >> Consider j.l.i.BootstrapMethodInvoker.invoke, which I changed from: >> >> private static Object invoke(MethodHandle bootstrapMethod, Lookup >> caller, >> String name, Object type) throws >> Throwable { >> if (type instanceof Class) { >> return bootstrapMethod.invoke(caller, name, (Class)type); >> } else { >> return bootstrapMethod.invoke(caller, name, (MethodType)type); >> } >> } >> >> .. to: >> >> private static Object invoke(MethodHandle bootstrapMethod, Lookup >> caller, >> String name, Object type) throws >> Throwable { >> if (type instanceof Class c) { >> return bootstrapMethod.invoke(caller, name, c); >> } else { >> return bootstrapMethod.invoke(caller, name, (MethodType)type); >> } >> } > It should be "type instanceof Class c" BTW. > >> This seem to grow the bytecode size ever so slightly. Looking at the >> javap output it seems some of that might be redundant and possibly >> fixable: >> >> private static java.lang.Object invoke(java.lang.invoke.MethodHandle, >> java.lang.invoke.MethodHandles$Lookup, java.lang.String, >> java.lang.Object) throws java.lang.Throwable; >> descriptor: >> (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; >> flags: (0x000a) ACC_PRIVATE, ACC_STATIC >> Code: >> stack=4, locals=6, args_size=4 >> 0: aload_3 >> 1: astore 5 >> 3: aload 5 >> 5: instanceof #46 // class java/lang/Class >> 8: ifeq 27 >> 11: aload 5 >> 13: checkcast #46 // class java/lang/Class >> 16: astore 4 >> 18: aload_0 >> 19: aload_1 >> 20: aload_2 >> 21: aload 4 >> 23: invokevirtual #169 // Method >> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; >> 26: areturn >> 27: aload_0 >> 28: aload_1 >> 29: aload_2 >> 30: aload_3 >> 31: checkcast #61 // class >> java/lang/invoke/MethodType >> 34: invokevirtual #172 // Method >> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; >> 37: areturn >> LineNumberTable: >> line 226: 0 >> line 227: 18 >> line 229: 27 >> LocalVariableTable: >> Start Length Slot Name Signature >> 18 9 4 c Ljava/lang/Class; >> 0 38 0 bootstrapMethod >> Ljava/lang/invoke/MethodHandle; >> 0 38 1 caller >> Ljava/lang/invoke/MethodHandles$Lookup; >> 0 38 2 name Ljava/lang/String; >> 0 38 3 type Ljava/lang/Object; >> StackMapTable: number_of_entries = 1 >> frame_type = 27 /* same */ >> Exceptions: >> throws java.lang.Throwable >> >> - The storing and loading of the type argument into slot 5 seem >> completely redundant: couldn't we load slot 3 in each place that >> now loads slot 5? > yes, it looks like a bug. > >> - Storing c into a new slot 4 also seem unfortunate, but is more >> understandable (I guess this is a limitation of the LVT not allowing >> overlapping a new variable with a new type into the same slot?) > The new syntax declares a supplementary local variable so it has to be visible in the bytecode for debuggers. > >> - It's also unfortunate that the checkcast now bubbles up so that the >> result has to be stored and loaded again, but I guess pushing the >> checkcast down to just before the invokevirtual as in the other >> branch would go against some specification. > Modern javac (i don't know the previous version, before java 1.4) never had such "optimization". > > As a grey beard, when the enhanced for was introduced, the for(:), we had the very similar discussions, because the enhanced for introduces a supplementary variable and usually a cast because of the erasure of generics, so the bytecode is a little more verbose. In the end, yes, it inflates the generated bytecodes at bit because it creates a new local variable but the java code is more readable because it creates a new local variable :) > >> My gut feeling - without knowing much about javac - is that at least >> the use of a temporary slot (5) could be optimized away here. > I agree. > >> WDYT? >> >> For reference the baseline method without the pattern matching >> compiles to this: >> >> private static java.lang.Object invoke(java.lang.invoke.MethodHandle, >> java.lang.invoke.MethodHandles$Lookup, java.lang.String, >> java.lang.Object) throws java.lang.Throwable; >> descriptor: >> (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; >> flags: (0x000a) ACC_PRIVATE, ACC_STATIC >> Code: >> stack=4, locals=4, args_size=4 >> 0: aload_3 >> 1: instanceof #46 // class java/lang/Class >> 4: ifeq 18 >> 7: aload_0 >> 8: aload_1 >> 9: aload_2 >> 10: aload_3 >> 11: checkcast #46 // class java/lang/Class >> 14: invokevirtual #169 // Method >> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; >> 17: areturn >> 18: aload_0 >> 19: aload_1 >> 20: aload_2 >> 21: aload_3 >> 22: checkcast #61 // class >> java/lang/invoke/MethodType >> 25: invokevirtual #172 // Method >> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; >> 28: areturn >> LineNumberTable: >> line 226: 0 >> line 227: 7 >> line 229: 18 >> LocalVariableTable: >> Start Length Slot Name Signature >> 0 29 0 bootstrapMethod >> Ljava/lang/invoke/MethodHandle; >> 0 29 1 caller >> Ljava/lang/invoke/MethodHandles$Lookup; >> 0 29 2 name Ljava/lang/String; >> 0 29 3 type Ljava/lang/Object; >> StackMapTable: number_of_entries = 1 >> frame_type = 18 /* same */ >> Exceptions: >> throws java.lang.Throwable >> >> Thanks! >> >> /Claes > R?mi From claes.redestad at oracle.com Thu Jan 28 15:24:02 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 28 Jan 2021 16:24:02 +0100 Subject: Possibly inefficient code gen of instanceof patterns In-Reply-To: <9cdb6608-ea9a-59d2-f7f9-d0af505f6f6c@oracle.com> References: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> <500752481.452074.1611843924147.JavaMail.zimbra@u-pem.fr> <9cdb6608-ea9a-59d2-f7f9-d0af505f6f6c@oracle.com> Message-ID: <79e65698-c57b-600e-1c08-926938ee0b72@oracle.com> Thanks, Jan! /Claes On 2021-01-28 16:11, Jan Lahoda wrote: > Hi, > > I've filled: > > https://bugs.openjdk.java.net/browse/JDK-8260593 > > > Thanks, > > ??? Jan > > > On 28. 01. 21 15:25, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Claes Redestad" >>> ?: "compiler-dev" >>> Envoy?: Jeudi 28 Janvier 2021 14:58:47 >>> Objet: Possibly inefficient code gen of instanceof patterns >>> Hi, >>> >>> as an experiment, I changed some code to use instanceof pattern >>> matching to see if there's any effect on the generated code. >>> >>> Consider j.l.i.BootstrapMethodInvoker.invoke, which I changed from: >>> >>> ???? private static Object invoke(MethodHandle bootstrapMethod, Lookup >>> caller, >>> ????????????????????????????????? String name, Object type) throws >>> Throwable { >>> ???????? if (type instanceof Class) { >>> ???????????? return bootstrapMethod.invoke(caller, name, (Class)type); >>> ???????? } else { >>> ???????????? return bootstrapMethod.invoke(caller, name, >>> (MethodType)type); >>> ???????? } >>> ???? } >>> >>> .. to: >>> >>> ???? private static Object invoke(MethodHandle bootstrapMethod, Lookup >>> caller, >>> ????????????????????????????????? String name, Object type) throws >>> Throwable { >>> ???????? if (type instanceof Class c) { >>> ???????????? return bootstrapMethod.invoke(caller, name, c); >>> ???????? } else { >>> ???????????? return bootstrapMethod.invoke(caller, name, >>> (MethodType)type); >>> ???????? } >>> ???? } >> It should be "type instanceof Class c" BTW. >> >>> This seem to grow the bytecode size ever so slightly. Looking at the >>> javap output it seems some of that might be redundant and possibly >>> fixable: >>> >>> ?? private static java.lang.Object invoke(java.lang.invoke.MethodHandle, >>> java.lang.invoke.MethodHandles$Lookup, java.lang.String, >>> java.lang.Object) throws java.lang.Throwable; >>> ???? descriptor: >>> (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; >>> >>> ???? flags: (0x000a) ACC_PRIVATE, ACC_STATIC >>> ???? Code: >>> ?????? stack=4, locals=6, args_size=4 >>> ????????? 0: aload_3 >>> ????????? 1: astore??????? 5 >>> ????????? 3: aload???????? 5 >>> ????????? 5: instanceof??? #46???????????????? // class java/lang/Class >>> ????????? 8: ifeq????????? 27 >>> ???????? 11: aload???????? 5 >>> ???????? 13: checkcast???? #46???????????????? // class java/lang/Class >>> ???????? 16: astore??????? 4 >>> ???????? 18: aload_0 >>> ???????? 19: aload_1 >>> ???????? 20: aload_2 >>> ???????? 21: aload???????? 4 >>> ???????? 23: invokevirtual #169??????????????? // Method >>> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; >>> >>> ???????? 26: areturn >>> ???????? 27: aload_0 >>> ???????? 28: aload_1 >>> ???????? 29: aload_2 >>> ???????? 30: aload_3 >>> ???????? 31: checkcast???? #61???????????????? // class >>> java/lang/invoke/MethodType >>> ???????? 34: invokevirtual #172??????????????? // Method >>> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; >>> >>> ???????? 37: areturn >>> ?????? LineNumberTable: >>> ???????? line 226: 0 >>> ???????? line 227: 18 >>> ???????? line 229: 27 >>> ?????? LocalVariableTable: >>> ???????? Start? Length? Slot? Name?? Signature >>> ??????????? 18?????? 9???? 4???? c?? Ljava/lang/Class; >>> ???????????? 0????? 38???? 0 bootstrapMethod >>> Ljava/lang/invoke/MethodHandle; >>> ???????????? 0????? 38???? 1 caller >>> Ljava/lang/invoke/MethodHandles$Lookup; >>> ???????????? 0????? 38???? 2? name?? Ljava/lang/String; >>> ???????????? 0????? 38???? 3? type?? Ljava/lang/Object; >>> ?????? StackMapTable: number_of_entries = 1 >>> ???????? frame_type = 27 /* same */ >>> ???? Exceptions: >>> ?????? throws java.lang.Throwable >>> >>> - The storing and loading of the type argument into slot 5 seem >>> completely redundant: couldn't we load slot 3 in each place that >>> now loads slot 5? >> yes, it looks like a bug. >> >>> - Storing c into a new slot 4 also seem unfortunate, but is more >>> understandable (I guess this is a limitation of the LVT not allowing >>> overlapping a new variable with a new type into the same slot?) >> The new syntax declares a supplementary local variable so it has to be >> visible in the bytecode for debuggers. >> >>> - It's also unfortunate that the checkcast now bubbles up so that the >>> result has to be stored and loaded again, but I guess pushing the >>> checkcast down to just before the invokevirtual as in the other >>> branch would go against some specification. >> Modern javac (i don't know the previous version, before java 1.4) >> never had such "optimization". >> >> As a grey beard, when the enhanced for was introduced, the for(:), we >> had the very similar discussions, because the enhanced for introduces >> a supplementary variable and usually a cast because of the erasure of >> generics, so the bytecode is a little more verbose. In the end, yes, >> it inflates the generated bytecodes at bit because it creates a new >> local variable but the java code is more readable because it creates a >> new local variable :) >> >>> My gut feeling - without knowing much about javac - is that at least >>> the use of a temporary slot (5) could be optimized away here. >> I agree. >> >>> WDYT? >>> >>> For reference the baseline method without the pattern matching >>> compiles to this: >>> >>> ?? private static java.lang.Object invoke(java.lang.invoke.MethodHandle, >>> java.lang.invoke.MethodHandles$Lookup, java.lang.String, >>> java.lang.Object) throws java.lang.Throwable; >>> ???? descriptor: >>> (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; >>> >>> ???? flags: (0x000a) ACC_PRIVATE, ACC_STATIC >>> ???? Code: >>> ?????? stack=4, locals=4, args_size=4 >>> ????????? 0: aload_3 >>> ????????? 1: instanceof??? #46???????????????? // class java/lang/Class >>> ????????? 4: ifeq????????? 18 >>> ????????? 7: aload_0 >>> ????????? 8: aload_1 >>> ????????? 9: aload_2 >>> ???????? 10: aload_3 >>> ???????? 11: checkcast???? #46???????????????? // class java/lang/Class >>> ???????? 14: invokevirtual #169??????????????? // Method >>> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)Ljava/lang/Object; >>> >>> ???????? 17: areturn >>> ???????? 18: aload_0 >>> ???????? 19: aload_1 >>> ???????? 20: aload_2 >>> ???????? 21: aload_3 >>> ???????? 22: checkcast???? #61???????????????? // class >>> java/lang/invoke/MethodType >>> ???????? 25: invokevirtual #172??????????????? // Method >>> java/lang/invoke/MethodHandle.invoke:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/Object; >>> >>> ???????? 28: areturn >>> ?????? LineNumberTable: >>> ???????? line 226: 0 >>> ???????? line 227: 7 >>> ???????? line 229: 18 >>> ?????? LocalVariableTable: >>> ???????? Start? Length? Slot? Name?? Signature >>> ???????????? 0????? 29???? 0 bootstrapMethod >>> Ljava/lang/invoke/MethodHandle; >>> ???????????? 0????? 29???? 1 caller >>> Ljava/lang/invoke/MethodHandles$Lookup; >>> ???????????? 0????? 29???? 2? name?? Ljava/lang/String; >>> ???????????? 0????? 29???? 3? type?? Ljava/lang/Object; >>> ?????? StackMapTable: number_of_entries = 1 >>> ???????? frame_type = 18 /* same */ >>> ???? Exceptions: >>> ?????? throws java.lang.Throwable >>> >>> Thanks! >>> >>> /Claes >> R?mi From vromero at openjdk.java.net Thu Jan 28 18:50:49 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 28 Jan 2021 18:50:49 GMT Subject: RFR: 8259905: Compiler treats 'sealed' keyword as 'var' keyword Message-ID: Hi, Please review this fix which is basically fixing an oversaw issue affecting new restricted keywords: `sealed` and `permits`. The fix per se is in lines: 3341-3343, but then I made some additional changes to the position where previous errors were reported at method JavacParser::variableDeclaratorRest. That was done for consistency with the new code. I could have done the other way but then users would have two error notifications for some code, one for the use of the restricted type per se and another one for the use of the variable or field so like: void m() { sealed s1; ^ compiler error here ^ and before you go, compiler error here too } I guess it make sense for the already existing code to be positioned on the use of the restricted type and not on the variable declared afterwards. Doing that adjustment has implied some changes to the golden file associated to test ParserTest. Also I added another case and did some additional editing to test SealedCompilationTests. TIA ------------- Commit messages: - 8259905: Compiler treats 'sealed' keyword as 'var' keyword Changes: https://git.openjdk.java.net/jdk/pull/2298/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2298&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259905 Stats: 48 lines in 3 files changed: 14 ins; 22 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2298.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2298/head:pull/2298 PR: https://git.openjdk.java.net/jdk/pull/2298 From jlahoda at openjdk.java.net Thu Jan 28 19:27:43 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 28 Jan 2021 19:27:43 GMT Subject: RFR: 8259905: Compiler treats 'sealed' keyword as 'var' keyword In-Reply-To: References: Message-ID: <7gZG9KkHFe0vp1NVIcxW291hZ5Wy9wqNI28Jlb4ZC9U=.e62f39cd-9bf9-4f62-8ccc-c67692782796@github.com> On Thu, 28 Jan 2021 18:45:21 GMT, Vicente Romero wrote: > Hi, > > Please review this fix which is basically fixing an oversaw issue affecting new restricted keywords: `sealed` and `permits`. The fix per se is in lines: 3341-3343, but then I made some additional changes to the position where previous errors were reported at method JavacParser::variableDeclaratorRest. That was done for consistency with the new code. I could have done the other way but then users would have two error notifications for some code, one for the use of the restricted type per se and another one for the use of the variable or field so like: > > void m() { > sealed s1; > ^ > compiler error here > ^ > and before you go, compiler error here too > } > I guess it make sense for the already existing code to be positioned on the use of the restricted type and not on the variable declared afterwards. Doing that adjustment has implied some changes to the golden file associated to test ParserTest. Also I added another case and did some additional editing to test SealedCompilationTests. > > TIA Looking at the spec here: http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html It does not seem to exclude `sealed` from `TypeIdentifier` (as the specs exclude `var`, `yield` and `record`). So it should be possible to have a class named `"sealed"`? Seems `sealed` is a keyword only on particular places, like e.g. `open`? But possibly I am not reading the spec properly? ------------- PR: https://git.openjdk.java.net/jdk/pull/2298 From claes.redestad at oracle.com Thu Jan 28 19:40:40 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 28 Jan 2021 20:40:40 +0100 Subject: Possibly inefficient code gen of instanceof patterns In-Reply-To: <500752481.452074.1611843924147.JavaMail.zimbra@u-pem.fr> References: <94e759d7-1759-5f58-a088-684274370ce9@oracle.com> <500752481.452074.1611843924147.JavaMail.zimbra@u-pem.fr> Message-ID: On 2021-01-28 15:25, Remi Forax wrote: >> - Storing c into a new slot 4 also seem unfortunate, but is more >> understandable (I guess this is a limitation of the LVT not allowing >> overlapping a new variable with a new type into the same slot?) > The new syntax declares a supplementary local variable so it has to be visible in the bytecode for debuggers. > It was just an observation based on the perhaps far-flung thought that as long as two variable refers to the exact same thing just with added type information - evident through the LVT - they could technically share a slot until such a time that either local is assigned a new value. An optimization that could perhaps be worthwhile now that it might become common to have extra local variables that are just added to provide extra type information. Again, just an observation. I'm happy as long as the first inefficiency is addressed. /Claes From Gavin.Bierman at oracle.com Thu Jan 28 21:41:24 2021 From: Gavin.Bierman at oracle.com (Gavin Bierman) Date: Thu, 28 Jan 2021 21:41:24 +0000 Subject: RFR: 8259905: Compiler treats 'sealed' keyword as 'var' keyword In-Reply-To: <7gZG9KkHFe0vp1NVIcxW291hZ5Wy9wqNI28Jlb4ZC9U=.e62f39cd-9bf9-4f62-8ccc-c67692782796@github.com> References: <7gZG9KkHFe0vp1NVIcxW291hZ5Wy9wqNI28Jlb4ZC9U=.e62f39cd-9bf9-4f62-8ccc-c67692782796@github.com> Message-ID: <7A0E5E96-450E-47B4-A543-C8B87C0B3AF8@oracle.com> No that is an omission. `sealed` and `permits` should be classified as restricted identifiers (new concept to JLS 16) and thus not valid type identifiers. I?ll fix this in the next version of the spec. Gavin > On 28 Jan 2021, at 19:27, Jan Lahoda wrote: > > On Thu, 28 Jan 2021 18:45:21 GMT, Vicente Romero > wrote: > >> Hi, >> >> Please review this fix which is basically fixing an oversaw issue affecting new restricted keywords: `sealed` and `permits`. The fix per se is in lines: 3341-3343, but then I made some additional changes to the position where previous errors were reported at method JavacParser::variableDeclaratorRest. That was done for consistency with the new code. I could have done the other way but then users would have two error notifications for some code, one for the use of the restricted type per se and another one for the use of the variable or field so like: >> >> void m() { >> sealed s1; >> ^ >> compiler error here >> ^ >> and before you go, compiler error here too >> } >> I guess it make sense for the already existing code to be positioned on the use of the restricted type and not on the variable declared afterwards. Doing that adjustment has implied some changes to the golden file associated to test ParserTest. Also I added another case and did some additional editing to test SealedCompilationTests. >> >> TIA > > Looking at the spec here: > http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html > > It does not seem to exclude `sealed` from `TypeIdentifier` (as the specs exclude `var`, `yield` and `record`). So it should be possible to have a class named `"sealed"`? Seems `sealed` is a keyword only on particular places, like e.g. `open`? But possibly I am not reading the spec properly? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2298 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.java.net Thu Jan 28 22:38:49 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 28 Jan 2021 22:38:49 GMT Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation type Message-ID: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com> Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations. ------------- Commit messages: - 8231436: Fix the applicability of a no- at Target annotation type Changes: https://git.openjdk.java.net/jdk/pull/2303/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2303&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231436 Stats: 12 lines in 3 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2303/head:pull/2303 PR: https://git.openjdk.java.net/jdk/pull/2303 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 29 11:24:48 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Jan 2021 11:24:48 GMT Subject: RFR: 8260566: Pattern type X is a subtype of expression type Y message is incorrect Message-ID: Hi all, The order of the arguments is wrong when using method `Errors.InstanceofPatternNoSubtype`. This patch fixes it and revises the corresponding tests. Thank you for taking the time to review. And it may be good to fix JDK16 as well. Best Regards. -- xiong ------------- Commit messages: - 8260566:Pattern type X is a subtype of expression type Y message is incorrect Changes: https://git.openjdk.java.net/jdk/pull/2311/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2311&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260566 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2311.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2311/head:pull/2311 PR: https://git.openjdk.java.net/jdk/pull/2311 From tvaleev at openjdk.java.net Fri Jan 29 12:02:40 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Fri, 29 Jan 2021 12:02:40 GMT Subject: RFR: 8260566: Pattern type X is a subtype of expression type Y message is incorrect In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 11:20:06 GMT, Guoxiong Li wrote: > Hi all, > > The order of the arguments is wrong when using method `Errors.InstanceofPatternNoSubtype`. > > This patch fixes it and revises the corresponding tests. > Thank you for taking the time to review. > And it may be good to fix JDK16 as well. > > Best Regards. > -- xiong The fix doesn't seem correct to me. Consider the code in the ticket: public class Test { void test(String s) { if(s instanceof Object obj) {} } } The previous message was: Test.java:3: error: pattern type Object is a subtype of expression type String if(s instanceof Object obj) {} It was incorrect because Object is not a subtype of String After applying this fix, the message will be Test.java:3: error: pattern type String is a subtype of expression type Object if(s instanceof Object obj) {} It's also incorrect because String is not a pattern type, and Object is not an expression type. A correct message would be Test.java:3: error: expression type String is a subtype of pattern type Object or Test.java:3: error: pattern type Object is a supertype of expression type String ------------- PR: https://git.openjdk.java.net/jdk/pull/2311 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 29 12:26:48 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Jan 2021 12:26:48 GMT Subject: RFR: 8260566: Pattern type X is a subtype of expression type Y message is incorrect In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 11:59:30 GMT, Tagir F. Valeev wrote: >> Hi all, >> >> The order of the arguments is wrong when using method `Errors.InstanceofPatternNoSubtype`. >> >> This patch fixes it and revises the corresponding tests. >> Thank you for taking the time to review. >> And it may be good to fix JDK16 as well. >> >> Best Regards. >> -- xiong > > The fix doesn't seem correct to me. Consider the code in the ticket: > > public class Test { > void test(String s) { > if(s instanceof Object obj) {} > } > } > > The previous message was: > Test.java:3: error: pattern type Object is a subtype of expression type String > if(s instanceof Object obj) {} > It was incorrect because Object is not a subtype of String > > After applying this fix, the message will be > Test.java:3: error: pattern type String is a subtype of expression type Object > if(s instanceof Object obj) {} > It's also incorrect because String is not a pattern type, and Object is not an expression type. A correct message would be > Test.java:3: error: expression type String is a subtype of pattern type Object > or > Test.java:3: error: pattern type Object is a supertype of expression type String @amaembo You are right. I will fix it later. ------------- PR: https://git.openjdk.java.net/jdk/pull/2311 From jlahoda at openjdk.java.net Fri Jan 29 12:27:05 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 29 Jan 2021 12:27:05 GMT Subject: RFR: JDK-8260593: javac can skip a temporary local variable when pattern matching over a local variable Message-ID: When translating type test like ` instanceof String s`, javac needs to a) check if the value of `` is a String, and if yes, b) create a new variable `s`, and assign the value of `` into it. But, `` needs to be evaluated only once. So, javac will create a temporary local variable to hold the value of ``. But, if `` itself is a local variable, there is no need to create another temporary local variable, javac can read the original local variable twice, leading to a shorter bytecode. ------------- Commit messages: - JDK-8260593: javac can skip a temporary local variable when pattern matching over a local variable Changes: https://git.openjdk.java.net/jdk/pull/2313/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2313&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260593 Stats: 219 lines in 3 files changed: 209 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2313/head:pull/2313 PR: https://git.openjdk.java.net/jdk/pull/2313 From eugene.zhuravlev at gmail.com Fri Jan 29 12:40:54 2021 From: eugene.zhuravlev at gmail.com (Eugene Zhuravlev) Date: Fri, 29 Jan 2021 13:40:54 +0100 Subject: Pluggable Annotation Processing: problems from the IDE (IntelliJ) perspective In-Reply-To: References: Message-ID: Thanks, Joe I would like to add some comments regarding our usage of compiler API. We invoke javac programmatically via the JavaCompiler.getTask().call(). This allows us to customize the FileManager used by the compiler in order to closer integrate javac with our build. This approach also allows us to use eclipse batch compiler "ecj" via the same Compiler API, because ecj implements it too. We do not subclass the compiler or alter the way it works, but we use the Compiler API abilities to track and control input/output files (via the FileManager) and get AST-level information about references (via the TaskListener) that cannot be recovered from the bytecode. All dependency tracking for the incremental compilation is done outside the compiler. This approach allows us to use any compiler that implements Compiler API. The primary source of dependency information is the bytecode: we process it with ASM and thus obtain most class structure- and references- related information. The fact that we get dependency data from the bytecode allows us to remain relatively compiler-independent since we only rely on a standard bytecode format. However, we have to use Compiler API to get information about imports and inlined compile-time constants directly from javac, as this data cannot be obtained from the bytecode. This is of course, a javac-specific part, but it does not affect the general approach to collecting dependency data. So we do not rely on compiler built-in incremental capabilities, but rather manage and process dependency data separately. Because of that it is critical for the build to have access to any data that help maintain dependency information complete. One of this data is the mapping between source and output files. For java sources we get it from the "sibling" argument passed to a FileManager, but for anything produced by an AnnotationProcessor we only have to reply on originatingElements arguments. We have not found any other way to access this data as by wrapping the Filer object with our own wrapper that would intercept these values. But in order to install the wrapper over the Filer, we have to wrap the ProcessingEnvironment and Processor objects too. As you mention these interfaces were designed to be wrappable so we use this possibility to get access to the data that is otherwise skipped by javac. If there was an alternative way to access originatingElements, we'd gladly skip the wrapping as it complicates the code and brings us to another problem: the way third-party authors write their AnnotationProcessors. Sure, if processor code is written so that it makes restrictive assumptions about ProcessingEnvironment instances, the code should be fixed on processor's side. But if processor wans to use a Tree API, it has a little choice, because Tree.instance() is itself written in the assumption that it is passed a certain instance of AnnotationProcessing environment object. Despite the wrappable design of AP interface classes, javac's own internal implementation (Trees API) contradicts to this approach. So the best thing we came up with, is to explain the AP author how to "unwrap" the wrapped ProcessingEnvironment object so that Tree API facade can be properly instantiated. Ann's post goal was to draw attention to these problems. I would also like to suggest following changes that would simplify life for both us and AP authors: 1. Do not ignore originatingElements on the Filer implementation level but provide a way to pass this data further to FileManager or to some dedicated listener that can be registered on a CompilerTask, for example. This would allow build environments collecting dependency data to get access to it. 2. If interface wrapping is a supported approach, changes could be made to Trees.instance(ProcessingEnvironment) to make it aware of this. For example, there can be an "official" and standard way to unwrap the wrapped environment object so that the facade object could be reliably instantiated. Regards, Eugene On Wed, Jan 27, 2021 at 11:30 PM Joe Darcy wrote: > Hi Anna, > > Thanks for the comments. For context, can you describe in more detail how > IntelliJ is using javac and any other Java compilers? For example, is javac > being invoked programmatically, or phases of it being subclassed, is a > different compiler infrastructure used for incremental IDE usage versus > generation of class files? > > For background, when JSR 269 was being developed, besides javac there was > an independent implementation of the API being done in Eclipse. The Eclipse > implementation was in the context of that IDE and was a successor to the > earlier Eclipse implementation of the apt API. Eclipse provided incremental > running of annotation processors in response to updated files, etc. My > understanding is the apt implementation in Eclipse had more complete > dependency tracking, but the JSR 269 API provides fuller mechanisms to > implement an incremental re-running policy. > > As you note, internally javac currently drops the originating elements > information as it is not used in a batch compilation context. > > The interfaces for the environment objects, Filer, etc. were designed to > be wrappable, but that is problematic if users do instanceof tests or rely > on other implementation-class functionality. > > During JSR 269, the utility of having a standard AST API was recognized, > but it was technically infeasible to have an AST-level API that worked well > across two compiler that didn't shave the same code base, javac and ecj in > particular. > > Thanks, > > -Joe > On 1/26/2021 4:05 AM, Anna Kozlova wrote: > > Hi all, > > As we lately see the `JSR 269 - Pluggable Annotation Processing - > Maintenance Review ballot', we would like to share our troubles with this > API from the IDE perspective. It isn't connected to the latest changes in > the JSR so I was advised to post our thoughts here. > > *Initial setup:* > IntelliJ IDEA allows incremental compilation, which means that only > changed code and its dependencies are recompiled instead of the whole > project (workspace)/module (project). The task is complicated by itself but > when people use Annotation Processors it becomes sometimes impossible > though, it seems, we may get all information we need to build source - > output relation and thus enable incremental compilation. > > *Problem description:* > When a processor generates a java source code, a bytecode or a resource > file, it uses "create*" methods from the javax.annotation.processing.Filer > interface. Every "create*" method has a vararg parameter > "originatingElements" which are supposed to be "type or package or module > elements causally associated with the creation of this file, may be elided > or null". Those elements are supposed to be used by the processing > environment to register and track dependencies between generated classes > and existing code elements (classes, methods, fields) used by the processor > to produce the generated code. The default Filter implementation by javac > simply ignores this data. Internally, javac calls JavaFileManager to > actually create and store the generated data, but, unfortunately, the > originatingElements passed by processors are already lost. When generating > bytecode, javac uses the javax.tools.JavaFileManager.getJavaFileForOutput() > method and passes the "sibling" argument, pointing to the corresponding > source file. This information is used by our build system to register > source->output dependencies and facilitate incremental > compilation. However, if data generation is initiated by an annotation > processor, the "sibling" parameter is always null. One could expect it to > point to a source file object containing originatingElements passed by the > AP. > (Another problem is that there are multiple originating elements > potentially corresponding to multiple source files, but there is only a > single "sibling" reference in the getJavaFileForOutput() method.) Because > originatingElements are ignored, our build system cannot track dependencies > between source files and AP-generated code. So we should always assume the > worst scenario and recompile the whole module or a project whenever we > detect that generated code is affected. > > Without this information the detection itself is not as reliable as it > could have been. So if a project heavily relies on AP code generation, we > cannot provide the best incremental compilation experience because of lack > of data. > > *Current solution:* > > The javadoc for create* methods in the Filer interface suggests that > > "This information may be used in an incremental environment to determine > the need to rerun processors or remove generated files. Non-incremental > environments may ignore the originating element information." > > In order to get access to originatingElements, our build system has to > provide its own implementation of Filer interface. We do this by wrapping > the original Filter implementation with a wrapper that registers > originatingElements and delegates the call to original Filter > implementation. This is on its own a non-trivial task, because the whole > API provides no direct ways neither to access the originatingElements nor > to register a custom Filter implementation. Just to wrap the original Filer > implementation, we have to re-implement the AP discovery logic, and then > use the JavaCompiler.CompilationTask.setProcessors() method that would > explicitly configure processor objects. Every Processor object is in turn > wrapped with our "wrapper", whose the only purpose is to make sure the AP > will get a wrapped Filer and not the original one. > > *Problems with the current solution:* > > This approach generally works, but it leads to additional problems on the > annotation processor side. Unfortunately, many popular processors assume > that passed objects like ProcessingEnvironment and Filer have certain > implementations. The processor code may heavily rely on this assumption, > e.g. cast the passed object to implementation or use instanceof checks on > it. So if processor gets a wrapped ProcessingEnvironment, it would fail to > execute further. As a result, user's project just stops compiling. > > Another problem caused by such wrapping approach, is javac's so called > Tree API. An annotation processor may use the Tree API for its internal > logic. The only way for the processor to obtain a reference to this API > Facade is a call com.sun.source.util.Trees.instance(ProcessingEnvironment). > If processor passes the wrapped ProcessingEnvironment object to the > Trees.instance() method, it won't work, because its implementation > internally uses an instanceof check itself! > > Our current approach is to detect such situation and provide AP developer > with hints in the error message. In order to make the processor work in our > incremental environment, the AP developer has to write additional code that > "unwraps" the passed ProcessingEnvironment object and uses the unwrapped > object to initialize the Tree API. Such a situation, of course, is far from > ideal: AP developers should not write code to please an IDE. > > *What can improve the situation:* > So would be great if following problems were addressed in the API: there > should be a direct way to access originatingElements. Ideally there > accessing this data should not make AP developers to change their code. If > code changes are inevitable on AP side, those changes should be possible > without making assumptions about inteface implementations. There should be > a standard way to get access to Tree API as well, or, even better, the > original API should be extended to make implementation of complex > processing logic possible without semi-closed Tree API. > > Thanks, > Anna > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 29 12:49:06 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Jan 2021 12:49:06 GMT Subject: RFR: 8260566: Pattern type X is a subtype of expression type Y message is incorrect [v2] In-Reply-To: References: Message-ID: > Hi all, > > The order of the arguments is wrong when using method `Errors.InstanceofPatternNoSubtype`. > > This patch fixes it and revises the corresponding tests. > Thank you for taking the time to review. > And it may be good to fix JDK16 as well. > > Best Regards. > -- xiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Revise error message. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2311/files - new: https://git.openjdk.java.net/jdk/pull/2311/files/26f93d3a..6bcda73c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2311&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2311&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2311.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2311/head:pull/2311 PR: https://git.openjdk.java.net/jdk/pull/2311 From jlahoda at openjdk.java.net Fri Jan 29 13:22:43 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 29 Jan 2021 13:22:43 GMT Subject: RFR: 8260566: Pattern type X is a subtype of expression type Y message is incorrect [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 12:49:06 GMT, Guoxiong Li wrote: >> Hi all, >> >> The order of the arguments is wrong when using method `Errors.InstanceofPatternNoSubtype`. >> >> This patch fixes it and revises the corresponding tests. >> Thank you for taking the time to review. >> And it may be good to fix JDK16 as well. >> >> Best Regards. >> -- xiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Revise error message. Looks good to me. Thanks for Tagir for pointing out the mistake in the error message. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2311 From tvaleev at openjdk.java.net Fri Jan 29 13:22:44 2021 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Fri, 29 Jan 2021 13:22:44 GMT Subject: RFR: 8260566: Pattern type X is a subtype of expression type Y message is incorrect [v2] In-Reply-To: References: Message-ID: <5hjZwjS95dIMvlbJyXmsbu19Vo92BEo3DNCxZXAiATM=.86c8e785-ca04-43ff-86b5-0f50c3def40c@github.com> On Fri, 29 Jan 2021 12:49:06 GMT, Guoxiong Li wrote: >> Hi all, >> >> The order of the arguments is wrong when using method `Errors.InstanceofPatternNoSubtype`. >> >> This patch fixes it and revises the corresponding tests. >> Thank you for taking the time to review. >> And it may be good to fix JDK16 as well. >> >> Best Regards. >> -- xiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Revise error message. Looks good to me! (I'm not an official reviewer though) ------------- Marked as reviewed by tvaleev (Committer). PR: https://git.openjdk.java.net/jdk/pull/2311 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 29 13:43:41 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Jan 2021 13:43:41 GMT Subject: RFR: 8260566: Pattern type X is a subtype of expression type Y message is incorrect [v2] In-Reply-To: <5hjZwjS95dIMvlbJyXmsbu19Vo92BEo3DNCxZXAiATM=.86c8e785-ca04-43ff-86b5-0f50c3def40c@github.com> References: <5hjZwjS95dIMvlbJyXmsbu19Vo92BEo3DNCxZXAiATM=.86c8e785-ca04-43ff-86b5-0f50c3def40c@github.com> Message-ID: <_LAEwYkZTJsZAm63CdEtmJkr6WTq6C9wV9yb8cSYi4E=.76547fbb-a7af-41d6-ac5b-6a62cead9a38@github.com> On Fri, 29 Jan 2021 13:19:37 GMT, Tagir F. Valeev wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise error message. > > Looks good to me! (I'm not an official reviewer though) @amaembo @lahodaj Thanks for your review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/2311 From jlahoda at openjdk.java.net Fri Jan 29 13:49:39 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 29 Jan 2021 13:49:39 GMT Subject: RFR: 8259905: Compiler treats 'sealed' keyword as 'var' keyword In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 18:45:21 GMT, Vicente Romero wrote: > Hi, > > Please review this fix which is basically fixing an oversaw issue affecting new restricted keywords: `sealed` and `permits`. The fix per se is in lines: 3341-3343, but then I made some additional changes to the position where previous errors were reported at method JavacParser::variableDeclaratorRest. That was done for consistency with the new code. I could have done the other way but then users would have two error notifications for some code, one for the use of the restricted type per se and another one for the use of the variable or field so like: > > void m() { > sealed s1; > ^ > compiler error here > ^ > and before you go, compiler error here too > } > I guess it make sense for the already existing code to be positioned on the use of the restricted type and not on the variable declared afterwards. Doing that adjustment has implied some changes to the golden file associated to test ParserTest. Also I added another case and did some additional editing to test SealedCompilationTests. > > TIA LGTM ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2298 From vromero at openjdk.java.net Fri Jan 29 16:53:40 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 29 Jan 2021 16:53:40 GMT Subject: Integrated: 8259905: Compiler treats 'sealed' keyword as 'var' keyword In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 18:45:21 GMT, Vicente Romero wrote: > Hi, > > Please review this fix which is basically fixing an oversaw issue affecting new restricted keywords: `sealed` and `permits`. The fix per se is in lines: 3341-3343, but then I made some additional changes to the position where previous errors were reported at method JavacParser::variableDeclaratorRest. That was done for consistency with the new code. I could have done the other way but then users would have two error notifications for some code, one for the use of the restricted type per se and another one for the use of the variable or field so like: > > void m() { > sealed s1; > ^ > compiler error here > ^ > and before you go, compiler error here too > } > I guess it make sense for the already existing code to be positioned on the use of the restricted type and not on the variable declared afterwards. Doing that adjustment has implied some changes to the golden file associated to test ParserTest. Also I added another case and did some additional editing to test SealedCompilationTests. > > TIA This pull request has now been integrated. Changeset: b2e582a8 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/b2e582a8 Stats: 48 lines in 3 files changed: 14 ins; 22 del; 12 mod 8259905: Compiler treats 'sealed' keyword as 'var' keyword Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/2298 From jlahoda at openjdk.java.net Fri Jan 29 17:39:55 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 29 Jan 2021 17:39:55 GMT Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags Message-ID: [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ] Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol. We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy. We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile. My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows: -the current long-based Flags are split into 4 groups: --"flat" Flags, long based, work exactly as before. --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well. There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like: -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable) -split TypeSymbolFlags into Class/Package/MethodSymbolFlags The positives of this solution include: -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe -improves the abstractions at least for some flags -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments) -the performances appears to be acceptable. The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code. Some more alternatives: -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags). -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it . Any feedback is welcome! ------------- Commit messages: - Whitespaces. - Cleanup. - Merging master into JDK-8241356 - 8241356: Use a more reliable way to encode Symbol flags Changes: https://git.openjdk.java.net/jdk/pull/2316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241356 Stats: 765 lines in 30 files changed: 331 ins; 198 del; 236 mod Patch: https://git.openjdk.java.net/jdk/pull/2316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2316/head:pull/2316 PR: https://git.openjdk.java.net/jdk/pull/2316 From github.com+13688759+lgxbslgx at openjdk.java.net Fri Jan 29 18:29:42 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Jan 2021 18:29:42 GMT Subject: Integrated: 8260566: Pattern type X is a subtype of expression type Y message is incorrect In-Reply-To: References: Message-ID: <_kHn-x8PrxwD5OMJZxsS_soibt7dEQ59qtxKvL8gv0I=.6ebe7c1c-9871-41f4-9169-8f7a66abc2d4@github.com> On Fri, 29 Jan 2021 11:20:06 GMT, Guoxiong Li wrote: > Hi all, > > The order of the arguments is wrong when using method `Errors.InstanceofPatternNoSubtype`. > > This patch fixes it and revises the corresponding tests. > Thank you for taking the time to review. > And it may be good to fix JDK16 as well. > > Best Regards. > -- xiong This pull request has now been integrated. Changeset: 739bbd03 Author: Guoxiong Li Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/739bbd03 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod 8260566: Pattern type X is a subtype of expression type Y message is incorrect Reviewed-by: jlahoda, tvaleev ------------- PR: https://git.openjdk.java.net/jdk/pull/2311 From vromero at openjdk.java.net Fri Jan 29 19:49:41 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 29 Jan 2021 19:49:41 GMT Subject: RFR: JDK-8260593: javac can skip a temporary local variable when pattern matching over a local variable In-Reply-To: References: Message-ID: <1Rx9HLwSpUz6TVydNUoM9Ax8MxpEA5OVz931C-KurLY=.92ab4213-3d09-4d7f-bf18-7ea3ac6c8c6d@github.com> On Fri, 29 Jan 2021 12:22:00 GMT, Jan Lahoda wrote: > When translating type test like ` instanceof String s`, javac needs to a) check if the value of `` is a String, and if yes, b) create a new variable `s`, and assign the value of `` into it. But, `` needs to be evaluated only once. So, javac will create a temporary local variable to hold the value of ``. But, if `` itself is a local variable, there is no need to create another temporary local variable, javac can read the original local variable twice, leading to a shorter bytecode. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2313 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Jan 30 08:55:56 2021 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 30 Jan 2021 08:55:56 GMT Subject: RFR: 8200145: Conditional expression mistakenly treated as standalone Message-ID: Hi all, If the argument `Type t` of the method `Types.unboxedType` is an `ErrorType`, the `Types.unboxedType` may return the wrong result. And in this case, `Attr.isBooleanOrNumeric` and `Attr.isBooleanOrNumeric` return the wrong result, too. This patch fixes it and adds a test case. Thank you for taking the time to review. Best Regards. -- xiong ------------- Commit messages: - 8200145: Conditional expression mistakenly treated as standalone Changes: https://git.openjdk.java.net/jdk/pull/2324/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2324&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8200145 Stats: 46 lines in 3 files changed: 45 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2324/head:pull/2324 PR: https://git.openjdk.java.net/jdk/pull/2324