From ross.goldberg at gmail.com Sat Sep 1 14:17:23 2018 From: ross.goldberg at gmail.com (Ross Goldberg) Date: Sat, 1 Sep 2018 10:17:23 -0400 Subject: _module-specific form_ for --module-source-path from Bug # 8208609 In-Reply-To: References: Message-ID: > Directories, are supported; no, files in the subdirectories are not > automatically compiled. That never was (and still is) true for > -sourcepath, it is likewise true for the module source path. Maybe a separate option could be added to recursively compile all *.java files found under the -sourcepath / ?module-source-path without explicitly listing them in the _sourcefiles_ arguments. Thus, all options would be consistent & backwards compatible, yet users could use a more concise syntax that is probably applicable to the vastly overwhelming majority of all javac invocations. > Are your concerns related to any specific build system, or to direct use > of the javac command in a Makefile or script, or just abstract academic > concerns? I?m writing a plugin for Gradle to support modules, so I should support any conceivable module directory structure, preferably without any manual configuration or forced conventions. I already have code that uses the g:com.github.javaparser:javaparser-core library to parse module names from module-info.java files. Besides the many obvious plugin development & runtime negatives, requiring an otherwise unnecessary library subjects my plugin & its users to the library?s bugs, and to any compatibility issues and/or update lags caused by changes in Java or in other libraries (e.g., Java version format issues lead to delays in adoption of recent versions of Java due to library incompatibilities, and library module issues are still causing delays in adoption of JPMS). Given that the module name is functionally unnecessary in the command line, and that it requires knowing it and correctly aligning it between command line & module-info.java, it seems odd to require it. I do see the potential documentation use, but I feel it should be optional rather than required. Much of the time, the module name will be in the directory hierarchy, so an explicit module name will even be redundant for a documentation basis. I can?t imagine that the code to handle any of my suggestions is difficult or time consuming to write, maintain, document, or teach. The benefits seem to vastly outweigh the costs. Thanks again, Ross On Fri, Aug 31, 2018 at 4:43 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 8/31/18 12:51 PM, Ross Goldberg wrote: > > Can someone provide some details for the _module-specific form_ > > enhancement for --module-source-path from 8208609? > > (https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8208609) > > > > Is a _file-path_ always to a file, or could it be to a directory? > > By itself, "path" is an overloaded and potentially ambiguous term: it > can mean the path for a specific item in a file system (as may be > represented by java.nio.file.Path) or it can mean a search path, like a > class path, source path or module path. So I try and qualify which > variant I mean. > _file-path_ is used to mean a reference to a specific item in the file > system. In the context of the module source path, it probably will be a > directory, in which case it should be the directory that is the root of > the package hierarchy for some or all of the module's source code. > > > > > If directories are supported, are all *.java file descendants compiled > > with a package hierarchy rooted at the directory? > Directories, are supported; no, files in the subdirectories are not > automatically compiled. That never was (and still is) true for > -sourcepath, it is likewise true for the module source path. > > > > If directories aren't supported, why? The additional error conditions > > (e.g., 1 _file_path_ being a descendant of another) should be easy to > > check, and allowing directories could significantly shorten command > lines. > n/a. See previous answer. > > > > If a file is included in a module's path via a _file-path_, must the > > file also be included in the standard _sourcefiles_ arguments? If so, > > that seems redundant? > You put directories on the module source path. You put the specific > files to be compiled in the _sourcefiles_ argument. While it might > seem redundant, it is pragmatically necessary to put the directories on > the module source path as well: this is required to help determine the > enclosing module, by making it possible to find the corresponding > module-info.java file. > > Note that you only need use --module-source-path when compiling multiple > modules at once. If you're just compiling one module at a time, you can > use --source-path. > > > > > Will you support {,} alternates in the _module-specific form_? That > > would also help shorten command lines. > > There are no plans to do that at this time. > > > > > Requiring that the module name be specified before the equals sign > > makes it harder for build systems to use --module-source-path. They > > must either: > > > > 1. parse module-info.java: performance (must parse file), > > compatibility (might require parser updates if module-info.java spec > > is changed) > > 2. read from directory structure based on convention: flexibility > > (limits layouts) > > 3. read from build config file: maintenance (config module name must > > align with module-info.java module name) > > If your files follow the suggested layout, you can use the > module-pattern form, which does not require any module name to be > specified on the command line. The module-specific form is for those > cases where the file layout does not follow the standard form, in which > case it is not unreasonable to specify the name of the module whose > source path is being specified. > > > > > Could you provide another option, possibly named --module-source, that > > doesn't require the module name? > > Unlikely. It is not clear that there is a problem here that needs to > be solved. > > > > There should obviously always be one and only one module-info.java in > > each module's path, so javac should be able to get the module name > > from that file instead of from the command line. > The current syntax matches that used for the --patch-module option. > There is benefit in consistency. > There is also benefit in having the user (or build system) explicitly > provide the module name, both for documentation and for consistency > checking. > > > > Thanks for any info, > > Are your concerns related to any specific build system, or to direct use > of the javac command in a Makefile or script, or just abstract academic > concerns? > > > > Ross > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Sep 1 16:17:15 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 1 Sep 2018 09:17:15 -0700 Subject: _module-specific form_ for --module-source-path from Bug # 8208609 In-Reply-To: References: Message-ID: On 9/1/18 7:17 AM, Ross Goldberg wrote: > > Directories, are supported; no, files in the subdirectories are not > > automatically compiled. That never was (and still is) true for > > -sourcepath, it is likewise true for the module source path. > > Maybe a separate option could be added to recursively compile all > *.java files found under the -sourcepath / ?module-source-path without > explicitly listing them in the _sourcefiles_ arguments. Thus, all > options would be consistent & backwards compatible, yet users could > use a more concise syntax that is?probably?applicable to?the vastly > overwhelming majority of all javac invocations. Look at --module [, > > Are your concerns related to any specific build system, or to direct > use > > of the javac command in a Makefile or script, or just abstract academic > > concerns? > > I?m writing a plugin for Gradle to support modules, so I should > support any conceivable module directory structure, preferably without > any manual configuration or forced conventions. OK, thanks for the context info. > > I already have code that uses > the?g:com.github.javaparser:javaparser-core library to parse module > names from module-info.java files. > > Besides the many obvious plugin development & runtime negatives, > requiring an otherwise unnecessary library?subjects my plugin & its > users to the library?s bugs, and to any compatibility issues and/or > update lags caused by changes in Java or in other libraries (e.g., > Java version format issues lead to delays in adoption of recent > versions of Java due to library incompatibilities, and library module > issues are still causing delays in adoption of JPMS). > > Given that the module name is functionally unnecessary in the command > line, and that it requires knowing it and correctly aligning it > between command line & module-info.java, it seems odd to require it. > > I do see the potential documentation use, but I feel it should be > optional rather than required. Much of the time, the module name will > be in the directory hierarchy, so an explicit module name will even be > redundant for a documentation basis. > > I can?t imagine that the code to handle any of my suggestions is > difficult or time consuming to write,?maintain, document,?or?teach. > The benefits seem to vastly outweigh the costs. It is already the case that there is a precedent for the "=..." convention for module-specific command-line args in various JDK tools, including, but not limited to the --patch-module option. There are other considerations too ... if javac were to support these "anonymous" module source paths, and an error appears in it, how should we identify the path in error messages?? The module name is useful in that context as well. Finally, this change is a relatively small one, simply exposing functionality provided in the JavaFileManager API, thereby aligning functionality provided on the javac command line with that already available to clients of the Java Compiler API. -- Jon > > Thanks again, > > Ross > > On Fri, Aug 31, 2018 at 4:43 PM Jonathan Gibbons > > wrote: > > > > On 8/31/18 12:51 PM, Ross Goldberg wrote: > > Can someone provide some details for the _module-specific form_ > > enhancement for --module-source-path from 8208609? > > (https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8208609) > > > > Is a _file-path_ always to a file, or could it be to a directory? > > By itself, "path" is an overloaded and potentially ambiguous term: it > can mean the path for a specific item in a file system (as may be > represented by? java.nio.file.Path) or it can mean a search path, > like a > class path, source path or module path. So I try and qualify which > variant I mean. > _file-path_ is used to mean a reference to a specific item in the > file > system.? In the context of the module source path, it probably > will be a > directory, in which case it should be the directory that is the > root of > the package hierarchy for some or all of the module's source code. > > > > > If directories are supported, are all *.java file descendants > compiled > > with a package hierarchy rooted at the directory? > Directories, are supported; no, files in the subdirectories are not > automatically compiled. That never was (and still is) true for > -sourcepath, it is likewise true for the module source path. > > > > If directories aren't supported, why?? The additional error > conditions > > (e.g., 1 _file_path_ being a descendant of another) should be > easy to > > check, and allowing directories could significantly shorten > command lines. > n/a. See previous answer. > > > > If a file is included in a module's path via a _file-path_, must > the > > file also be included in the standard _sourcefiles_ arguments?? > If so, > > that seems redundant? > You put directories on the module source path. You put the specific > files to be compiled in the _sourcefiles_ argument.?? While it might > seem redundant, it is pragmatically necessary to put the > directories on > the module source path as well: this is required to help determine > the > enclosing module, by making it possible to find the corresponding > module-info.java file. > > Note that you only need use --module-source-path when compiling > multiple > modules at once. If you're just compiling one module at a time, > you can > use --source-path. > > > > > Will you support {,} alternates in the _module-specific form_?? > That > > would also help shorten command lines. > > There are no plans to do that at this time. > > > > > Requiring that the module name be specified before the equals sign > > makes it harder for build systems to use --module-source-path. They > > must either: > > > > 1. parse module-info.java: performance (must parse file), > > compatibility (might require parser updates if module-info.java > spec > > is changed) > > 2. read from directory structure based on convention: flexibility > > (limits layouts) > > 3. read from build config file: maintenance (config module name > must > > align with module-info.java module name) > > If your files follow the suggested layout, you can use the > module-pattern form, which does not require any module name to be > specified on the command line.? The module-specific form is for those > cases where the file layout does not follow the standard form, in > which > case it is not unreasonable to specify the name of the module whose > source path is being specified. > > > > > Could you provide another option, possibly named > --module-source, that > > doesn't require the module name? > > Unlikely.?? It is not clear that there is a problem here that > needs to > be solved. > > > > There should obviously always be one and only one > module-info.java in > > each module's path, so javac should be able to get the module name > > from that file instead of from the command line. > The current syntax matches that used for the --patch-module option. > There is benefit in consistency. > There is also benefit in having the user (or build system) explicitly > provide the module name, both for documentation and for consistency > checking. > > > > Thanks for any info, > > Are your concerns related to any specific build system, or to > direct use > of the javac command in a Makefile or script, or just abstract > academic > concerns? > > > > Ross > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Sep 3 12:39:19 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 3 Sep 2018 13:39:19 +0100 Subject: RFR 8210318: idea.sh script doesn't work on Mac Message-ID: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> Hi, following the latest updates to the idea.sh script, Mac users reported issues - mostly having to do with usage of 'sed' - more specifically: * sed -i option is not portable - it has different formats in Mac vs. Linux. This patch does without -i, by moving the replaced file onto a temporary file, then moving such file on top of the template file in a subsequent step. This should be more robust. * sed doesn't like newlines in replaced text in Mac. I've thus omitted the newline from the SOURCE template - as that was mostly cosmetic. Thanks for Michael McMahon to report (and figure out how to deal with) these issues, and to Alan Bateman for testing the patch. I also fixed another minor glitch, this time in the langtools-only template - which was still referring to the old ant file location in the various run configuration. Webrev: http://cr.openjdk.java.net/~mcimadamore/8210318/ Cheers Maurizio From peter.levart at gmail.com Tue Sep 4 12:17:12 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 4 Sep 2018 14:17:12 +0200 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> Message-ID: Hello, On 08/27/2018 04:11 AM, seth lytle wrote: > to add to what Jon said, recompiling doesn't necessarily provide the > correct info as it may have been manipulated by another agent or > classloader (there is a similar weakness in my current workaround) > > getResourceAsStream (getRAS) is: > - robust: you know it's the same bytecode your parent CL used > - flexible: you can run woven and unwoven code concurrently > - chainable: downstream CLs will see your modifications > > > i haven't been able to think of anything that getResource adds, though > some people may use that instead > > on the core-libs-dev list david lloyd wrote: > > Why not go ahead and implement getResource as well?? It's not *that* > > big of a deal to add a URL handler, and it would be a fairly trivial one. > > > @jon - would you like to reply to that or should i ? > > my feeling is that we're better off without getResource (getR) > - the javadocs appear to allow differences between getR and getRAS > - getR adds complexity, startup cost and increases footprint Not that much. Most code can be in separate classes which are loaded only if .getResourceXXX is actually used. > - we're not aware of a consumer of the getR api Which does not mean there is none. > - the only resource is bytecode, and that's naturally accessed as a stream > - many things are changing with java 11 so any bytecode-modifying > library is likely to need to make source code changes anyway > > the only problem i see with not implementing getR is that there's no > way to convey to a hypothetical consumer of the API that the bytecode > that they're looking for is available via getRAS The correct way, I think, is to implement findResource() and findResources(). getResource(), getResources() and getResourceAsStream() are just front-end methods to be called by users. They implement ClassLoader delegation model and call findResource(s) at appropriate time. Making getResourceAsStream() available, but getResource() always return null (or even throw exception?) would be a precedent, I think. Here's a prototype that works and is not that complicated: http://cr.openjdk.java.net/~plevart/jdk-dev/MemoryClassLoader_getResource/webrev.01/ Someone might say that the URL protocol in this implementation does not allow parsing such URL(s) from String(s). That's true, but if one wanted to do that, one would have to identify (in the URL) the target MemoryClassLoader instance. There may be more than one MemoryClassLoader instance in the JVM. Comparing it to other protocols: in http://host:port/path/resource, the host:port part of the URL uniquely identifies the http server, where the resources are located; in file:///path/resource, the protocol refers to the single local file system on the host machine where the JVM is running, etc. How would one identify multiple instances of MemoryClassLoader such that their unique "names" would be known in advance? No way. I think that the presented prototype strikes the balance where the full resource resolving API of ClassLoader is implemented, while the URL protocol is not supported in a way that would allow parsing such URL(s) from String(s). If this is acceptable compromise, I suggest moving in this direction. Regards, Peter From michael.x.mcmahon at oracle.com Tue Sep 4 13:20:00 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 04 Sep 2018 14:20:00 +0100 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> Message-ID: <5B8E8680.9080707@oracle.com> The change looks fine to me Maurizio. Maybe you could append a .$$ to the temporary file name to make it less likely to overwrite something that already exists in /tmp - Michael. On 03/09/2018, 13:39, Maurizio Cimadamore wrote: > Hi, > following the latest updates to the idea.sh script, Mac users reported > issues - mostly having to do with usage of 'sed' - more specifically: > > * sed -i option is not portable - it has different formats in Mac vs. > Linux. This patch does without -i, by moving the replaced file onto a > temporary file, then moving such file on top of the template file in a > subsequent step. This should be more robust. > > * sed doesn't like newlines in replaced text in Mac. I've thus omitted > the newline from the SOURCE template - as that was mostly cosmetic. > > Thanks for Michael McMahon to report (and figure out how to deal with) > these issues, and to Alan Bateman for testing the patch. > > I also fixed another minor glitch, this time in the langtools-only > template - which was still referring to the old ant file location in > the various run configuration. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8210318/ > > Cheers > Maurizio > From jonathan.gibbons at oracle.com Tue Sep 4 15:02:07 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 4 Sep 2018 08:02:07 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> Message-ID: <2760b135-2a33-5271-7dd9-8b97c73ce8aa@oracle.com> On 9/4/18 5:17 AM, Peter Levart wrote: > Hello, > > On 08/27/2018 04:11 AM, seth lytle wrote: >> to add to what Jon said, recompiling doesn't necessarily provide the >> correct info as it may have been manipulated by another agent or >> classloader (there is a similar weakness in my current workaround) >> >> getResourceAsStream (getRAS) is: >> - robust: you know it's the same bytecode your parent CL used >> - flexible: you can run woven and unwoven code concurrently >> - chainable: downstream CLs will see your modifications >> >> >> i haven't been able to think of anything that getResource adds, >> though some people may use that instead >> >> on the core-libs-dev list david lloyd wrote: >> > Why not go ahead and implement getResource as well?? It's not *that* >> > big of a deal to add a URL handler, and it would be a fairly >> trivial one. >> >> >> @jon - would you like to reply to that or should i ? >> >> my feeling is that we're better off without getResource (getR) >> - the javadocs appear to allow differences between getR and getRAS >> - getR adds complexity, startup cost and increases footprint > > Not that much. Most code can be in separate classes which are loaded > only if .getResourceXXX is actually used. > >> - we're not aware of a consumer of the getR api > > Which does not mean there is none. > >> - the only resource is bytecode, and that's naturally accessed as a >> stream >> - many things are changing with java 11 so any bytecode-modifying >> library is likely to need to make source code changes anyway >> >> the only problem i see with not implementing getR is that there's no >> way to convey to a hypothetical consumer of the API that the bytecode >> that they're looking for is available via getRAS > > The correct way, I think, is to implement findResource() and > findResources(). getResource(), getResources() and > getResourceAsStream() are just front-end methods to be called by > users. They implement ClassLoader delegation model and call > findResource(s) at appropriate time. Making getResourceAsStream() > available, but getResource() always return null (or even throw > exception?) would be a precedent, I think. > > Here's a prototype that works and is not that complicated: > > http://cr.openjdk.java.net/~plevart/jdk-dev/MemoryClassLoader_getResource/webrev.01/ > > > Someone might say that the URL protocol in this implementation does > not allow parsing such URL(s) from String(s). That's true, but if one > wanted to do that, one would have to identify (in the URL) the target > MemoryClassLoader instance. There may be more than one > MemoryClassLoader instance in the JVM. Comparing it to other > protocols: in http://host:port/path/resource, the host:port part of > the URL uniquely identifies the http server, where the resources are > located; in file:///path/resource, the protocol refers to the single > local file system on the host machine where the JVM is running, etc. > How would one identify multiple instances of MemoryClassLoader such > that their unique "names" would be known in advance? No way. > > I think that the presented prototype strikes the balance where the > full resource resolving API of ClassLoader is implemented, while the > URL protocol is not supported in a way that would allow parsing such > URL(s) from String(s). > > If this is acceptable compromise, I suggest moving in this direction. > > Regards, Peter > Peter, Thank you for your suggestion.? We already have a prototype that provides getResource, getResources and getResourceAsStream, by implementing findResource and findResources.? There are issues related to the possible presence of a security manager, which we are working to resolve. I'll be posting a webrev for review soon. -- Jon Peter, Thank you for your suggestion.? We already have a prototype that provides getResource, getResources and getResourceAsStream, by implementing findResource and findResources.? There are issues related to the possible presence of a security manager, which we are working to resolve. I'll be posting a webrev for review soon. -- Jon From erik.joelsson at oracle.com Tue Sep 4 15:55:20 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Sep 2018 08:55:20 -0700 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> Message-ID: Hello, When choosing a temp file in the build, we avoid using /tmp whenever possible. A common pattern is instead to write to $TARGET.tmp and then mv that to $TARGET. Though unlikely to cause an issue, /tmp/replacement is a global location which is potentially risky (file permissions, concurrent execution etc). Otherwise looks good. /Erik On 2018-09-03 05:39, Maurizio Cimadamore wrote: > Hi, > following the latest updates to the idea.sh script, Mac users reported > issues - mostly having to do with usage of 'sed' - more specifically: > > * sed -i option is not portable - it has different formats in Mac vs. > Linux. This patch does without -i, by moving the replaced file onto a > temporary file, then moving such file on top of the template file in a > subsequent step. This should be more robust. > > * sed doesn't like newlines in replaced text in Mac. I've thus omitted > the newline from the SOURCE template - as that was mostly cosmetic. > > Thanks for Michael McMahon to report (and figure out how to deal with) > these issues, and to Alan Bateman for testing the patch. > > I also fixed another minor glitch, this time in the langtools-only > template - which was still referring to the old ant file location in > the various run configuration. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8210318/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Tue Sep 4 17:34:21 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 4 Sep 2018 18:34:21 +0100 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> Message-ID: Hi Erik, would $TARGET be set by make? Maurizio On 04/09/18 16:55, Erik Joelsson wrote: > Hello, > > When choosing a temp file in the build, we avoid using /tmp whenever > possible. A common pattern is instead to write to $TARGET.tmp and then > mv that to $TARGET. Though unlikely to cause an issue, > /tmp/replacement is a global location which is potentially risky (file > permissions, concurrent execution etc). > > Otherwise looks good. > > /Erik > > On 2018-09-03 05:39, Maurizio Cimadamore wrote: >> Hi, >> following the latest updates to the idea.sh script, Mac users >> reported issues - mostly having to do with usage of 'sed' - more >> specifically: >> >> * sed -i option is not portable - it has different formats in Mac vs. >> Linux. This patch does without -i, by moving the replaced file onto a >> temporary file, then moving such file on top of the template file in >> a subsequent step. This should be more robust. >> >> * sed doesn't like newlines in replaced text in Mac. I've thus >> omitted the newline from the SOURCE template - as that was mostly >> cosmetic. >> >> Thanks for Michael McMahon to report (and figure out how to deal >> with) these issues, and to Alan Bateman for testing the patch. >> >> I also fixed another minor glitch, this time in the langtools-only >> template - which was still referring to the old ant file location in >> the various run configuration. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8210318/ >> >> Cheers >> Maurizio >> > From erik.joelsson at oracle.com Tue Sep 4 17:50:29 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Sep 2018 10:50:29 -0700 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> Message-ID: <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com> Hello, $TARGET was just pseudo code. In your case it's $1.tmp. /Erik On 2018-09-04 10:34, Maurizio Cimadamore wrote: > Hi Erik, > would $TARGET be set by make? > > Maurizio > > > On 04/09/18 16:55, Erik Joelsson wrote: >> Hello, >> >> When choosing a temp file in the build, we avoid using /tmp whenever >> possible. A common pattern is instead to write to $TARGET.tmp and >> then mv that to $TARGET. Though unlikely to cause an issue, >> /tmp/replacement is a global location which is potentially risky >> (file permissions, concurrent execution etc). >> >> Otherwise looks good. >> >> /Erik >> >> On 2018-09-03 05:39, Maurizio Cimadamore wrote: >>> Hi, >>> following the latest updates to the idea.sh script, Mac users >>> reported issues - mostly having to do with usage of 'sed' - more >>> specifically: >>> >>> * sed -i option is not portable - it has different formats in Mac >>> vs. Linux. This patch does without -i, by moving the replaced file >>> onto a temporary file, then moving such file on top of the template >>> file in a subsequent step. This should be more robust. >>> >>> * sed doesn't like newlines in replaced text in Mac. I've thus >>> omitted the newline from the SOURCE template - as that was mostly >>> cosmetic. >>> >>> Thanks for Michael McMahon to report (and figure out how to deal >>> with) these issues, and to Alan Bateman for testing the patch. >>> >>> I also fixed another minor glitch, this time in the langtools-only >>> template - which was still referring to the old ant file location in >>> the various run configuration. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8210318/ >>> >>> Cheers >>> Maurizio >>> >> > From maurizio.cimadamore at oracle.com Tue Sep 4 17:56:49 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 4 Sep 2018 18:56:49 +0100 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com> References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com> Message-ID: <3b98f4cc-f444-1a84-eaea-e303c1f06077@oracle.com> Ah - thanks for the tip, I'll give that a try Maurizio On 04/09/18 18:50, Erik Joelsson wrote: > Hello, > > $TARGET was just pseudo code. In your case it's $1.tmp. > > /Erik > > > On 2018-09-04 10:34, Maurizio Cimadamore wrote: >> Hi Erik, >> would $TARGET be set by make? >> >> Maurizio >> >> >> On 04/09/18 16:55, Erik Joelsson wrote: >>> Hello, >>> >>> When choosing a temp file in the build, we avoid using /tmp whenever >>> possible. A common pattern is instead to write to $TARGET.tmp and >>> then mv that to $TARGET. Though unlikely to cause an issue, >>> /tmp/replacement is a global location which is potentially risky >>> (file permissions, concurrent execution etc). >>> >>> Otherwise looks good. >>> >>> /Erik >>> >>> On 2018-09-03 05:39, Maurizio Cimadamore wrote: >>>> Hi, >>>> following the latest updates to the idea.sh script, Mac users >>>> reported issues - mostly having to do with usage of 'sed' - more >>>> specifically: >>>> >>>> * sed -i option is not portable - it has different formats in Mac >>>> vs. Linux. This patch does without -i, by moving the replaced file >>>> onto a temporary file, then moving such file on top of the template >>>> file in a subsequent step. This should be more robust. >>>> >>>> * sed doesn't like newlines in replaced text in Mac. I've thus >>>> omitted the newline from the SOURCE template - as that was mostly >>>> cosmetic. >>>> >>>> Thanks for Michael McMahon to report (and figure out how to deal >>>> with) these issues, and to Alan Bateman for testing the patch. >>>> >>>> I also fixed another minor glitch, this time in the langtools-only >>>> template - which was still referring to the old ant file location >>>> in the various run configuration. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8210318/ >>>> >>>> Cheers >>>> Maurizio >>>> >>> >> > From jonathan.gibbons at oracle.com Tue Sep 4 18:27:25 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 Sep 2018 11:27:25 -0700 Subject: CFV: New Compiler Group Member: Vicente Romero Message-ID: <5B8ECE8D.3050801@oracle.com> |I hereby nominate Vicente Romero to Membership in the Compiler Group. Vicente is a leading contributor to javac, and has contributed 282 changesets since he started back in 2012. Votes are due in two weeks, by 11:30 a.m. PDT, Sep 18th. Only current Members of the Compiler Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. -- Jon Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/groups/#member-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Sep 4 18:31:19 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 Sep 2018 11:31:19 -0700 Subject: CFV: New Compiler Group Member: Vicente Romero In-Reply-To: <5B8ECE8D.3050801@oracle.com> References: <5B8ECE8D.3050801@oracle.com> Message-ID: <5B8ECF77.1020906@oracle.com> Vote: yes On 09/04/2018 11:27 AM, Jonathan Gibbons wrote: > |I hereby nominate Vicente Romero to Membership in the Compiler Group. > > Vicente is a leading contributor to javac, and has contributed 282 changesets > since he started back in 2012. > > Votes are due in two weeks, by 11:30 a.m. PDT, Sep 18th. > > Only current Members of the Compiler Group [1] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > -- Jon Gibbons > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/groups/#member-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Sep 4 18:32:44 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 4 Sep 2018 11:32:44 -0700 Subject: CFV: New Compiler Group Member: Vicente Romero In-Reply-To: <5B8ECE8D.3050801@oracle.com> References: <5B8ECE8D.3050801@oracle.com> Message-ID: <072f0493-e921-eed8-8c2d-fff731200f6e@oracle.com> Vote: yes -Joe On 9/4/2018 11:27 AM, Jonathan Gibbons wrote: > |I hereby nominate Vicente Romero to Membership in the Compiler Group. > Vicente is a leading contributor to javac, and has contributed 282 > changesets since he started back in 2012. Votes are due in two weeks, > by 11:30 a.m. PDT, Sep 18th. Only current Members of the Compiler > Group [1] are eligible to vote on this nomination. Votes must be cast > in the open by replying to this mailing list For Lazy Consensus voting > instructions, see [2]. -- Jon Gibbons [1] > http://openjdk.java.net/census [2] > http://openjdk.java.net/groups/#member-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Tue Sep 4 18:36:29 2018 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 4 Sep 2018 11:36:29 -0700 (PDT) Subject: CFV: New Compiler Group Member: Vicente Romero In-Reply-To: <5B8ECE8D.3050801@oracle.com> References: <5B8ECE8D.3050801@oracle.com> Message-ID: Vote: yes ? Thanks, iris ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Sep 4 20:04:44 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 4 Sep 2018 21:04:44 +0100 Subject: CFV: New Compiler Group Member: Vicente Romero In-Reply-To: <5B8ECE8D.3050801@oracle.com> References: <5B8ECE8D.3050801@oracle.com> Message-ID: <83119734-9392-3d41-5d80-4dcc86b01786@oracle.com> Vote: yes!! Maurizio On 04/09/18 19:27, Jonathan Gibbons wrote: > |I hereby nominate Vicente Romero to Membership in the Compiler Group. > Vicente is a leading contributor to javac, and has contributed 282 > changesets since he started back in 2012. Votes are due in two weeks, > by 11:30 a.m. PDT, Sep 18th. Only current Members of the Compiler > Group [1] are eligible to vote on this nomination. Votes must be cast > in the open by replying to this mailing list For Lazy Consensus voting > instructions, see [2]. -- Jon Gibbons [1] > http://openjdk.java.net/census [2] > http://openjdk.java.net/groups/#member-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Sep 4 20:52:52 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 Sep 2018 13:52:52 -0700 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream Message-ID: <5B8EF0A4.7040500@oracle.com> Please review a change to add support for the getResource* group of methods to the internal class loader used by the Source Launcher, introduced in JEP 330. The overall issue has been discussed on OpenJDK lists, [1,2] The implementation consists of providing findResource and findResources, along with a couple of minor additional classes to implement URLStreamHandler and URLConnection. There is one implementation detail worthy of note. The "new URL" should be inside a doPrivileged block, but overall, the Source Launcher does not work when a security manager in installed. This is being tracked as JDK-8210274, and the appropriate doPrivileged call will be added as part of that fix. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8210009 Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.01/ [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-August/012294.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/055001.html From mandy.chung at oracle.com Tue Sep 4 23:31:18 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 4 Sep 2018 16:31:18 -0700 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: <5B8EF0A4.7040500@oracle.com> References: <5B8EF0A4.7040500@oracle.com> Message-ID: On 9/4/18 1:52 PM, Jonathan Gibbons wrote: > Please review a change to add support for the getResource* group of > methods > to the internal class loader used by the Source Launcher, introduced > in JEP 330. > > The overall issue has been discussed on OpenJDK lists, [1,2] > > The implementation consists of providing findResource and findResources, > along with a couple of minor additional classes to implement > URLStreamHandler > and URLConnection. > > There is one implementation detail worthy of note. The "new URL" should > be inside a doPrivileged block, but overall, the Source Launcher does not > work when a security manager in installed. This is being tracked as > JDK-8210274, > and the appropriate doPrivileged call will be added as part of that fix. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210009 > Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.01/ This patch looks okay to me. This is a reasonable solution to allow getResource* to obtain the class file bytes loaded by the source launcher.?? JEP 330 might document that the URL protocol is implementation specific and the only way to get the URL of a .class file loaded by the source launcher is via the getResource(s) method.? It does not support creating such a URL from a string. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Wed Sep 5 00:31:43 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 4 Sep 2018 17:31:43 -0700 Subject: CFV: New Compiler Group Member: Vicente Romero In-Reply-To: <5B8ECE8D.3050801@oracle.com> References: <5B8ECE8D.3050801@oracle.com> Message-ID: Vote: yes From peter.levart at gmail.com Wed Sep 5 08:43:41 2018 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 5 Sep 2018 10:43:41 +0200 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: <5B8EF0A4.7040500@oracle.com> References: <5B8EF0A4.7040500@oracle.com> Message-ID: Hi Jon, A few comments at the end... On 09/04/2018 10:52 PM, Jonathan Gibbons wrote: > Please review a change to add support for the getResource* group of > methods > to the internal class loader used by the Source Launcher, introduced > in JEP 330. > > The overall issue has been discussed on OpenJDK lists, [1,2] > > The implementation consists of providing findResource and findResources, > along with a couple of minor additional classes to implement > URLStreamHandler > and URLConnection. > > There is one implementation detail worthy of note. The "new URL" should > be inside a doPrivileged block, but overall, the Source Launcher does not > work when a security manager in installed. This is being tracked as > JDK-8210274, > and the appropriate doPrivileged call will be added as part of that fix. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210009 > Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.01/ In the protocol (schema) name: ?618???????? private final String PROTOCOL = "sourcelauncher_" + getClass().getSimpleName() + hashCode(); ...which looks like "sourcelauncher_MemoryClassLoader-12345", the underscore is not an allowed character. The syntax of schema name is: alpha *( alpha | digit | "+" | "-" | "." ) URL does not check for that, but when you perform say url.toURI() you get URISyntaxException. If the intent was to append hashCode() to make the schema name unique per MemoryClassLoader instance (is there a reason for that?), then hashCode() does not guarantee that. Although the probability of a clash is very low. Was the intent of randomizing protocol name preventing things like making url3 below succeed in returning "wrong" resource? MemoryClassLoader cl1 = ... MemoryClassLoader cl2 = ... URL url1 = cl1.getResource(path1); URL url2 = cl2.getResource(path2); URL url3 = new URL(url1, url2.toString()); findResource() may be called concurrently from multiple threads, so lazy initialization of 'handler' field should be performed carefully using local variables: ??????????? URLStreamHandler handler = this.handler; ??????????? if (handler == null) { ??????????????? this.handler = handler = new MemoryURLStreamHandler(); ??????????? } ...then use local var 'hander' for constructing URL, or you risk reorderings which might pass null as handler parameter to URL constructor. This is still publication via data race, but should be safe as the only MemoryURLStreamHandler's state is a synthetic final field referencing outer MemoryClassLoader instance. I haven't tried to run the test, but how does this work: ? 56???????? String[] names = { ? 57???????????? "p/q/CLTest.class", ? 58???????????? "p/q/CLTest$Inner.class", ? 59???????????? "p/q/CLTest2.class", ? 60???????????? "java/lang/Object.class", ? 61???????????? "UNKNOWN.class", ? 62???????????? "UNKNOWN" ? 63???????? }; ...and then: ? 80???????????? URL u = cl.getResource(name); ? 81???????????? if (u == null) { ? 82???????????????? if (!name.contains("UNKNOWN")) { ? 83???????????????????? error("resource not found: " + name); ? 84???????????????? } Shouldn't resource name "p/q/CLTest2.class" raise an error? Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Sep 5 11:42:27 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 5 Sep 2018 12:42:27 +0100 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com> References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com> Message-ID: <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com> Here's the modified webrev - as suggested, I replaced /tmp/replacement with $1.tmp http://cr.openjdk.java.net/~mcimadamore/8210318_v2/ Thanks Maurizio On 04/09/18 18:50, Erik Joelsson wrote: > Hello, > > $TARGET was just pseudo code. In your case it's $1.tmp. > > /Erik > > > On 2018-09-04 10:34, Maurizio Cimadamore wrote: >> Hi Erik, >> would $TARGET be set by make? >> >> Maurizio >> >> >> On 04/09/18 16:55, Erik Joelsson wrote: >>> Hello, >>> >>> When choosing a temp file in the build, we avoid using /tmp whenever >>> possible. A common pattern is instead to write to $TARGET.tmp and >>> then mv that to $TARGET. Though unlikely to cause an issue, >>> /tmp/replacement is a global location which is potentially risky >>> (file permissions, concurrent execution etc). >>> >>> Otherwise looks good. >>> >>> /Erik >>> >>> On 2018-09-03 05:39, Maurizio Cimadamore wrote: >>>> Hi, >>>> following the latest updates to the idea.sh script, Mac users >>>> reported issues - mostly having to do with usage of 'sed' - more >>>> specifically: >>>> >>>> * sed -i option is not portable - it has different formats in Mac >>>> vs. Linux. This patch does without -i, by moving the replaced file >>>> onto a temporary file, then moving such file on top of the template >>>> file in a subsequent step. This should be more robust. >>>> >>>> * sed doesn't like newlines in replaced text in Mac. I've thus >>>> omitted the newline from the SOURCE template - as that was mostly >>>> cosmetic. >>>> >>>> Thanks for Michael McMahon to report (and figure out how to deal >>>> with) these issues, and to Alan Bateman for testing the patch. >>>> >>>> I also fixed another minor glitch, this time in the langtools-only >>>> template - which was still referring to the old ant file location >>>> in the various run configuration. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8210318/ >>>> >>>> Cheers >>>> Maurizio >>>> >>> >> > From magnus.ihse.bursie at oracle.com Wed Sep 5 11:51:59 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Sep 2018 13:51:59 +0200 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com> References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com> <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com> Message-ID: <4c7bdfd1-3516-ad52-8d7b-748ac06b97f2@oracle.com> On 2018-09-05 13:42, Maurizio Cimadamore wrote: > Here's the modified webrev - as suggested, I replaced /tmp/replacement > with $1.tmp > > http://cr.openjdk.java.net/~mcimadamore/8210318_v2/ Looks good to me. /Magnus > > Thanks > Maurizio > > > On 04/09/18 18:50, Erik Joelsson wrote: >> Hello, >> >> $TARGET was just pseudo code. In your case it's $1.tmp. >> >> /Erik >> >> >> On 2018-09-04 10:34, Maurizio Cimadamore wrote: >>> Hi Erik, >>> would $TARGET be set by make? >>> >>> Maurizio >>> >>> >>> On 04/09/18 16:55, Erik Joelsson wrote: >>>> Hello, >>>> >>>> When choosing a temp file in the build, we avoid using /tmp >>>> whenever possible. A common pattern is instead to write to >>>> $TARGET.tmp and then mv that to $TARGET. Though unlikely to cause >>>> an issue, /tmp/replacement is a global location which is >>>> potentially risky (file permissions, concurrent execution etc). >>>> >>>> Otherwise looks good. >>>> >>>> /Erik >>>> >>>> On 2018-09-03 05:39, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> following the latest updates to the idea.sh script, Mac users >>>>> reported issues - mostly having to do with usage of 'sed' - more >>>>> specifically: >>>>> >>>>> * sed -i option is not portable - it has different formats in Mac >>>>> vs. Linux. This patch does without -i, by moving the replaced file >>>>> onto a temporary file, then moving such file on top of the >>>>> template file in a subsequent step. This should be more robust. >>>>> >>>>> * sed doesn't like newlines in replaced text in Mac. I've thus >>>>> omitted the newline from the SOURCE template - as that was mostly >>>>> cosmetic. >>>>> >>>>> Thanks for Michael McMahon to report (and figure out how to deal >>>>> with) these issues, and to Alan Bateman for testing the patch. >>>>> >>>>> I also fixed another minor glitch, this time in the langtools-only >>>>> template - which was still referring to the old ant file location >>>>> in the various run configuration. >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/8210318/ >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Sep 5 15:04:38 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 5 Sep 2018 08:04:38 -0700 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: References: <5B8EF0A4.7040500@oracle.com> Message-ID: Peter, Thanks, comments inline. -- Jon On 9/5/18 1:43 AM, Peter Levart wrote: > Hi Jon, > > A few comments at the end... > > On 09/04/2018 10:52 PM, Jonathan Gibbons wrote: >> Please review a change to add support for the getResource* group of >> methods >> to the internal class loader used by the Source Launcher, introduced >> in JEP 330. >> >> The overall issue has been discussed on OpenJDK lists, [1,2] >> >> The implementation consists of providing findResource and findResources, >> along with a couple of minor additional classes to implement >> URLStreamHandler >> and URLConnection. >> >> There is one implementation detail worthy of note. The "new URL" should >> be inside a doPrivileged block, but overall, the Source Launcher does >> not >> work when a security manager in installed. This is being tracked as >> JDK-8210274, >> and the appropriate doPrivileged call will be added as part of that fix. >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210009 >> Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.01/ > > In the protocol (schema) name: > > ?618???????? private final String PROTOCOL = "sourcelauncher_" + > getClass().getSimpleName() + hashCode(); > > ...which looks like "sourcelauncher_MemoryClassLoader-12345", the > underscore is not an allowed character. The syntax of schema name is: > > alpha *( alpha | digit | "+" | "-" | "." ) > > URL does not check for that, but when you perform say url.toURI() you > get URISyntaxException. Good catch, will fix. > > If the intent was to append hashCode() to make the schema name unique > per MemoryClassLoader instance (is there a reason for that?), then > hashCode() does not guarantee that. Although the probability of a > clash is very low. The intent was not so much to make it unique, as to make it more obvious that you should not expect to create URLs from strings. > > Was the intent of randomizing protocol name preventing things like > making url3 below succeed in returning "wrong" resource? > > MemoryClassLoader cl1 = ... > MemoryClassLoader cl2 = ... > URL url1 = cl1.getResource(path1); > URL url2 = cl2.getResource(path2); > > URL url3 = new URL(url1, url2.toString()); > > > findResource() may be called concurrently from multiple threads, so > lazy initialization of 'handler' field should be performed carefully > using local variables: > > ??????????? URLStreamHandler handler = this.handler; > ??????????? if (handler == null) { > ??????????????? this.handler = handler = new MemoryURLStreamHandler(); > ??????????? } > > ...then use local var 'hander' for constructing URL, or you risk > reorderings which might pass null as handler parameter to URL > constructor. This is still publication via data race, but should be > safe as the only MemoryURLStreamHandler's state is a synthetic final > field referencing outer MemoryClassLoader instance. OK. Noted. > > > I haven't tried to run the test, but how does this work: > > ? 56???????? String[] names = { > ? 57???????????? "p/q/CLTest.class", > ? 58???????????? "p/q/CLTest$Inner.class", > ? 59???????????? "p/q/CLTest2.class", > ? 60???????????? "java/lang/Object.class", > ? 61???????????? "UNKNOWN.class", > ? 62???????????? "UNKNOWN" > ? 63???????? }; > > > ...and then: > > ? 80???????????? URL u = cl.getResource(name); > ? 81???????????? if (u == null) { > ? 82???????????????? if (!name.contains("UNKNOWN")) { > ? 83???????????????????? error("resource not found: " + name); > ? 84???????????????? } The intent is to create a test that looks up both valid and invalid resource names, and verifies the correct behavior for each. The use of UNKNOWN was just a convenient way of setting up a test case with an invalid URL. > > Shouldn't resource name "p/q/CLTest2.class" raise an error? No, the class is defined at the end of the source file. > > > > Regards, Peter > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Wed Sep 5 15:33:44 2018 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 5 Sep 2018 17:33:44 +0200 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: References: <5B8EF0A4.7040500@oracle.com> Message-ID: On 09/05/2018 05:04 PM, Jonathan Gibbons wrote: >> Shouldn't resource name "p/q/CLTest2.class" raise an error? > No, the class is defined at the end of the source file. Ah, the last line! I missed it. ;-( Regards, Peter From erik.joelsson at oracle.com Wed Sep 5 16:57:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 5 Sep 2018 09:57:44 -0700 Subject: RFR 8210318: idea.sh script doesn't work on Mac In-Reply-To: <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com> References: <40878adc-6d15-cd6d-3b63-68c9d650e56e@oracle.com> <8ee0ac4f-9d55-57ab-1b2c-cc93dc22f021@oracle.com> <8581cc17-843b-954c-cf6a-f6820d602bd7@oracle.com> Message-ID: Looks good, thanks! /Erik On 2018-09-05 04:42, Maurizio Cimadamore wrote: > Here's the modified webrev - as suggested, I replaced /tmp/replacement > with $1.tmp > > http://cr.openjdk.java.net/~mcimadamore/8210318_v2/ > > Thanks > Maurizio > > > On 04/09/18 18:50, Erik Joelsson wrote: >> Hello, >> >> $TARGET was just pseudo code. In your case it's $1.tmp. >> >> /Erik >> >> >> On 2018-09-04 10:34, Maurizio Cimadamore wrote: >>> Hi Erik, >>> would $TARGET be set by make? >>> >>> Maurizio >>> >>> >>> On 04/09/18 16:55, Erik Joelsson wrote: >>>> Hello, >>>> >>>> When choosing a temp file in the build, we avoid using /tmp >>>> whenever possible. A common pattern is instead to write to >>>> $TARGET.tmp and then mv that to $TARGET. Though unlikely to cause >>>> an issue, /tmp/replacement is a global location which is >>>> potentially risky (file permissions, concurrent execution etc). >>>> >>>> Otherwise looks good. >>>> >>>> /Erik >>>> >>>> On 2018-09-03 05:39, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> following the latest updates to the idea.sh script, Mac users >>>>> reported issues - mostly having to do with usage of 'sed' - more >>>>> specifically: >>>>> >>>>> * sed -i option is not portable - it has different formats in Mac >>>>> vs. Linux. This patch does without -i, by moving the replaced file >>>>> onto a temporary file, then moving such file on top of the >>>>> template file in a subsequent step. This should be more robust. >>>>> >>>>> * sed doesn't like newlines in replaced text in Mac. I've thus >>>>> omitted the newline from the SOURCE template - as that was mostly >>>>> cosmetic. >>>>> >>>>> Thanks for Michael McMahon to report (and figure out how to deal >>>>> with) these issues, and to Alan Bateman for testing the patch. >>>>> >>>>> I also fixed another minor glitch, this time in the langtools-only >>>>> template - which was still referring to the old ant file location >>>>> in the various run configuration. >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/8210318/ >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Wed Sep 5 19:08:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 05 Sep 2018 12:08:11 -0700 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: References: <5B8EF0A4.7040500@oracle.com> Message-ID: <5B90299B.5030209@oracle.com> Updated webrev, addressing comments from Peter. 1. Fixed protocol string, and updated test to verify that URLs are OK 2. Changed init of the stream handler Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.02/ -- Jon On 09/05/2018 01:43 AM, Peter Levart wrote: > Hi Jon, > > A few comments at the end... > > On 09/04/2018 10:52 PM, Jonathan Gibbons wrote: >> Please review a change to add support for the getResource* group of >> methods >> to the internal class loader used by the Source Launcher, introduced >> in JEP 330. >> >> The overall issue has been discussed on OpenJDK lists, [1,2] >> >> The implementation consists of providing findResource and findResources, >> along with a couple of minor additional classes to implement >> URLStreamHandler >> and URLConnection. >> >> There is one implementation detail worthy of note. The "new URL" should >> be inside a doPrivileged block, but overall, the Source Launcher does >> not >> work when a security manager in installed. This is being tracked as >> JDK-8210274, >> and the appropriate doPrivileged call will be added as part of that fix. >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210009 >> Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.01/ > > In the protocol (schema) name: > > 618 private final String PROTOCOL = "sourcelauncher_" + > getClass().getSimpleName() + hashCode(); > > ...which looks like "sourcelauncher_MemoryClassLoader-12345", the > underscore is not an allowed character. The syntax of schema name is: > > alpha *( alpha | digit | "+" | "-" | "." ) > > URL does not check for that, but when you perform say url.toURI() you > get URISyntaxException. > > If the intent was to append hashCode() to make the schema name unique > per MemoryClassLoader instance (is there a reason for that?), then > hashCode() does not guarantee that. Although the probability of a > clash is very low. > > Was the intent of randomizing protocol name preventing things like > making url3 below succeed in returning "wrong" resource? > > MemoryClassLoader cl1 = ... > MemoryClassLoader cl2 = ... > URL url1 = cl1.getResource(path1); > URL url2 = cl2.getResource(path2); > > URL url3 = new URL(url1, url2.toString()); > > > findResource() may be called concurrently from multiple threads, so > lazy initialization of 'handler' field should be performed carefully > using local variables: > > URLStreamHandler handler = this.handler; > if (handler == null) { > this.handler = handler = new MemoryURLStreamHandler(); > } > > ...then use local var 'hander' for constructing URL, or you risk > reorderings which might pass null as handler parameter to URL > constructor. This is still publication via data race, but should be > safe as the only MemoryURLStreamHandler's state is a synthetic final > field referencing outer MemoryClassLoader instance. > > > I haven't tried to run the test, but how does this work: > > 56 String[] names = { > 57 "p/q/CLTest.class", > 58 "p/q/CLTest$Inner.class", > 59 "p/q/CLTest2.class", > 60 "java/lang/Object.class", > 61 "UNKNOWN.class", > 62 "UNKNOWN" > 63 }; > > > ...and then: > > 80 URL u = cl.getResource(name); > 81 if (u == null) { > 82 if (!name.contains("UNKNOWN")) { > 83 error("resource not found: " + name); > 84 } > > Shouldn't resource name "p/q/CLTest2.class" raise an error? > > > > Regards, Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Sep 5 19:18:43 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 05 Sep 2018 12:18:43 -0700 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: References: <5B8EF0A4.7040500@oracle.com> Message-ID: <5B902C13.5050604@oracle.com> On 09/04/2018 04:31 PM, mandy chung wrote: > > > On 9/4/18 1:52 PM, Jonathan Gibbons wrote: >> Please review a change to add support for the getResource* group of >> methods >> to the internal class loader used by the Source Launcher, introduced >> in JEP 330. >> >> The overall issue has been discussed on OpenJDK lists, [1,2] >> >> The implementation consists of providing findResource and findResources, >> along with a couple of minor additional classes to implement >> URLStreamHandler >> and URLConnection. >> >> There is one implementation detail worthy of note. The "new URL" should >> be inside a doPrivileged block, but overall, the Source Launcher does >> not >> work when a security manager in installed. This is being tracked as >> JDK-8210274, >> and the appropriate doPrivileged call will be added as part of that fix. >> >> -- Jon >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210009 >> Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.01/ > > This patch looks okay to me. > > This is a reasonable solution to allow getResource* to obtain the > class file bytes > loaded by the source launcher. JEP 330 might document that the URL > protocol > is implementation specific and the only way to get the URL of a .class > file loaded > by the source launcher is via the getResource(s) method. It does not > support > creating such a URL from a string. > How about ... The class loader that is used to load the compiled classes itself uses an implementation-specific protocol for any URLs that refer to resources defined by the class loader. The only way to get such URLs is by using methods like |getResource| or |getResources|; creating any such URL from a string is not supported. -- Jon > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Sep 5 20:33:43 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 5 Sep 2018 13:33:43 -0700 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: <5B902C13.5050604@oracle.com> References: <5B8EF0A4.7040500@oracle.com> <5B902C13.5050604@oracle.com> Message-ID: <1a93cf45-cc26-d6af-0bed-fecf24e5a4ac@oracle.com> On 9/5/18 12:18 PM, Jonathan Gibbons wrote: > > > How about ... > > The class loader that is used to load the compiled classes itself uses > an implementation-specific protocol for any URLs that refer to > resources defined by the class loader. The only way to get such URLs > is by using methods like |getResource| or |getResources|; creating any > such URL from a string is not supported. > > That's good. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Sep 6 00:26:12 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Sep 2018 20:26:12 -0400 Subject: RFR: JDK-8210435: don't add local variable spots if they are DCE'ed by the compiler Message-ID: Please review the fix for [1] at [2]. This patch comes from a bug reported in amber-dev [3] in the context of the condy-folding project. In that discussion it was noted that the same issue can be reproduced in vanilla JDK when final local variables are into play. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8210435 [2] http://cr.openjdk.java.net/~vromero/8210435/webrev.00/jdk.dev.patch [3] http://mail.openjdk.java.net/pipermail/amber-dev/2018-September/003407.html From maurizio.cimadamore at oracle.com Thu Sep 6 12:03:04 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 6 Sep 2018 13:03:04 +0100 Subject: RFR: JDK-8210435: don't add local variable spots if they are DCE'ed by the compiler In-Reply-To: References: Message-ID: Looks good Thanks Maurizio On 06/09/18 01:26, Vicente Romero wrote: > Please review the fix for [1] at [2]. This patch comes from a bug > reported in amber-dev [3] in the context of the condy-folding project. > In that discussion it was noted that the same issue can be reproduced > in vanilla JDK when final local variables are into play. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8210435 > [2] http://cr.openjdk.java.net/~vromero/8210435/webrev.00/jdk.dev.patch > [3] > http://mail.openjdk.java.net/pipermail/amber-dev/2018-September/003407.html From mandy.chung at oracle.com Thu Sep 6 20:10:00 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 6 Sep 2018 13:10:00 -0700 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: <5B90299B.5030209@oracle.com> References: <5B8EF0A4.7040500@oracle.com> <5B90299B.5030209@oracle.com> Message-ID: <54bc46f1-5b77-4236-fdb2-6fdfdc7db501@oracle.com> On 9/5/18 12:08 PM, Jonathan Gibbons wrote: > Updated webrev, addressing comments from Peter. > > 1. Fixed protocol string, and updated test to verify that URLs are OK > 2. Changed init of the stream handler > > Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.02/ > The updated webrev looks okay. The test now verifies URL.toURI() - that's good (I mixed that in my review). The formatting in src/CLTest.java seems to need some clean up (the identation) - no need for a new webrev. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.borggren.franck at gmail.com Fri Sep 7 08:00:51 2018 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Fri, 7 Sep 2018 10:00:51 +0200 Subject: CFV: New Compiler Group Member: Vicente Romero In-Reply-To: <5B8ECE8D.3050801@oracle.com> References: <5B8ECE8D.3050801@oracle.com> Message-ID: Vote: yes! cheers /Joel On Tue, Sep 4, 2018 at 8:27 PM Jonathan Gibbons wrote: > > I hereby nominate Vicente Romero to Membership in the Compiler Group. > > Vicente is a leading contributor to javac, and has contributed 282 changesets > since he started back in 2012. > > Votes are due in two weeks, by 11:30 a.m. PDT, Sep 18th. > > Only current Members of the Compiler Group [1] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > -- Jon Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From andrej.golovnin at gmail.com Fri Sep 7 08:45:38 2018 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 7 Sep 2018 10:45:38 +0200 Subject: Possible bug in the compiler Message-ID: Hi all, I'm in the process to migrate our product to Java 11. When I try to compile our product using javac from OpenJDK 11 (build 11+28), then the compiler stops at some point with the following exception: compiler message file broken: key=compiler.misc.msg.bug arguments=11, {1}, {2}, {3}, {4}, {5}, {6}, {7} com.sun.tools.javac.code.Types$SignatureGenerator$InvalidSignatureException at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5107) at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod.typeSig(LambdaToMethod.java:2436) at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$LambdaTranslationContext.serializedLambdaDisambiguation(LambdaToMethod.java:2049) at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$LambdaTranslationContext.serializedLambdaName(LambdaToMethod.java:2082) at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$LambdaTranslationContext.complete(LambdaToMethod.java:2282) at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.analyzeLambda(LambdaToMethod.java:1477) at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.visitLambda(LambdaToMethod.java:1454) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1807) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitApply(TreeTranslator.java:280) at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.visitApply(LambdaToMethod.java:1337) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitExec(TreeTranslator.java:250) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) ... (I can provide the full stack trace when needed.) Unfortunately I'm not able to create a small example to reproduce this error. But the code that causes this error looks like this: public class JDK11CompilerBug { interface IFilter { Component getComponent(); } static class Filter implements IFilter { @Override public Component getComponent() {} } public Component buildFilter(List l, Dialog dialog) { Panel c = new Panel(); l.stream() .map(f -> { Button btn = (Button) f.getComponent(); btn.addActionListener(evt -> { applyFilter(f); dialog.setVisible(false); }); return btn; }) .forEach(c::add); return c; } private void applyFilter(IFilter f) {} } When I remove the call "applyFilter(f);", then the error disappears. But this is not really helpful. The real workaround is to add the type to the lambda parameter: .map((Filter f) -> {}). When I do so, then the project is compiled without any problem. The compiler from OpenJDK 10 compiles the project even without this modifications. I hope this helps to identify the problem in the compiler. Please let me know if there are some options that allow to get more diagnostic informations from the compiler. (FYI: I have already tried -Xdiags:verbose. But it doesn't seem to produce any useful information or I'm not able to find it.) Best regards, Andrej Golovnin From maurizio.cimadamore at oracle.com Fri Sep 7 11:33:17 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 7 Sep 2018 12:33:17 +0100 Subject: Possible bug in the compiler In-Reply-To: References: Message-ID: <8b6f089f-2182-a14a-474a-a9a393540df8@oracle.com> Hi, from the looks of it, seems like a latent bug that is made more explicit by the fact that the compiler now fails over when attempting to generate a bad signature containing an intersection type (which is not legal at the VM level). If I'm correct, even if the code compile correctly with JDK 10, the bytecode you got out of that was probably illegal, which might be in itself a javac issue. Also, Javac should generate a better error message, so there's definitively an issue here (e.g. the compiler should not crash like this). Seems to me that your example has to do with serializable lambdas, but your simplified test case doesn't have Serializable lambdas in them - could that be the issue? I'm able to reproduce with this: import java.awt.*; import java.awt.event.*; import java.util.List; import java.util.function.*; class JDK11CompilerBug { ??? interface IFilter { ??????? Component getComponent(); ??? } ??? static class Filter implements IFilter { ??????? @Override ??????? public Component getComponent() { return null; } ??? } ??? public Component buildFilter(List l, Dialog dialog) { ??????? Panel c = new Panel(); ??????? l.stream() ??????????? .map(f -> { ??????????????? Button btn = (Button) f.getComponent(); ??????????????? btn.addActionListener((java.io.Serializable & ActionListener)evt -> { ??????????????????? applyFilter(f); ??????????????????? dialog.setVisible(false); ??????????????? }); ??????????????? return btn; ??????????? }) ??????????? .forEach(c::add); ??????? return c; ??? } ??? private void applyFilter(IFilter f) {} } And, if I fix the compiler crash, I get this better message: error: error while generating class JDK11CompilerBug ? (illegal signature attribute for type CAP#1) ? where CAP#1 is a fresh type-variable: ??? CAP#1 extends Filter from capture of ? extends Filter 1 error So indeed it looks as if the compiler was trying to generate an illegal signature here. But - there's a caveat here - the signature generation logic here is just called in order to get a unique string that we can use for the lambda deserialized method. So, whether that contains characters that are illegal for the VM or not, it's not great cause of concern and one might argue that the compiler is being overly zealous here. I will followup with creating a new issue and issue a RFR as I think I have a fix. Maurizio On 07/09/18 09:45, Andrej Golovnin wrote: > Hi all, > > I'm in the process to migrate our product to Java 11. > When I try to compile our product using javac from OpenJDK 11 (build 11+28), > then the compiler stops at some point with the following exception: > > compiler message file broken: key=compiler.misc.msg.bug arguments=11, > {1}, {2}, {3}, {4}, {5}, {6}, {7} > com.sun.tools.javac.code.Types$SignatureGenerator$InvalidSignatureException > at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5107) > at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod.typeSig(LambdaToMethod.java:2436) > at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$LambdaTranslationContext.serializedLambdaDisambiguation(LambdaToMethod.java:2049) > at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$LambdaTranslationContext.serializedLambdaName(LambdaToMethod.java:2082) > at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$LambdaTranslationContext.complete(LambdaToMethod.java:2282) > at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.analyzeLambda(LambdaToMethod.java:1477) > at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.visitLambda(LambdaToMethod.java:1454) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1807) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitApply(TreeTranslator.java:280) > at jdk.compiler/com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.visitApply(LambdaToMethod.java:1337) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitExec(TreeTranslator.java:250) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452) > at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > ... > (I can provide the full stack trace when needed.) > > Unfortunately I'm not able to create a small example to reproduce this error. > But the code that causes this error looks like this: > > public class JDK11CompilerBug { > > interface IFilter { > Component getComponent(); > } > > static class Filter implements IFilter { > > @Override > public Component getComponent() {} > > } > > public Component buildFilter(List l, Dialog dialog) { > Panel c = new Panel(); > l.stream() > .map(f -> { > Button btn = (Button) f.getComponent(); > btn.addActionListener(evt -> { > applyFilter(f); > dialog.setVisible(false); > }); > return btn; > }) > .forEach(c::add); > return c; > } > > private void applyFilter(IFilter f) {} > > } > > When I remove the call "applyFilter(f);", then the error disappears. > But this is not really helpful. > > The real workaround is to add the type to the lambda parameter: > .map((Filter f) -> {}). > When I do so, then the project is compiled without any problem. > > The compiler from OpenJDK 10 compiles the project even without this > modifications. > > I hope this helps to identify the problem in the compiler. > Please let me know if there are some options that allow to get more > diagnostic informations from the compiler. (FYI: I have already tried > -Xdiags:verbose. > But it doesn't seem to produce any useful information or I'm not able > to find it.) > > Best regards, > Andrej Golovnin From andrej.golovnin at gmail.com Fri Sep 7 12:25:31 2018 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 7 Sep 2018 14:25:31 +0200 Subject: Possible bug in the compiler In-Reply-To: <8b6f089f-2182-a14a-474a-a9a393540df8@oracle.com> References: <8b6f089f-2182-a14a-474a-a9a393540df8@oracle.com> Message-ID: Hi Maurizio, > Seems to me that your example has to do with serializable lambdas, but > your simplified test case doesn't have Serializable lambdas in them - > could that be the issue? Yes, you are absolutely right! I always forget that lambdas can be Serializable. > I will followup with creating a new issue and issue a RFR as I think I > have a fix. Thanks a lot! Best regards, Andrej Golovnin From maurizio.cimadamore at oracle.com Fri Sep 7 12:49:48 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 7 Sep 2018 13:49:48 +0100 Subject: RFR: 8210495: compiler crashes because of illegal signature in otherwise legal code Message-ID: <404c46cc-5305-3c71-90f7-500eeb1ea5b1@oracle.com> Hi, this is a fix for the issue described in a recent compiler-dev thread [1]; the fix does two things: 1) adds proper catch of illegal signature exceptions in LambdaToMethod 2) Add ability to avoid exception throwing when generating signature for those clients that can live with loose semantics Crucially (2) allows to retain compatibility with previously serialized names. If e.g. we required all types to be erased prior to deserialized lambda name generation, we would obtain a different hash. Webrev: http://cr.openjdk.java.net/~mcimadamore/8210495/ JBS: https://bugs.openjdk.java.net/browse/JDK-8210495 Maurizio From vicente.romero at oracle.com Fri Sep 7 13:27:35 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 7 Sep 2018 09:27:35 -0400 Subject: RFR: 8210495: compiler crashes because of illegal signature in otherwise legal code In-Reply-To: <404c46cc-5305-3c71-90f7-500eeb1ea5b1@oracle.com> References: <404c46cc-5305-3c71-90f7-500eeb1ea5b1@oracle.com> Message-ID: <4bf35e69-1071-0845-d203-daacc660b7a6@oracle.com> looks good, Vicente On 09/07/2018 08:49 AM, Maurizio Cimadamore wrote: > Hi, > this is a fix for the issue described in a recent compiler-dev thread > [1]; the fix does two things: > > 1) adds proper catch of illegal signature exceptions in LambdaToMethod > 2) Add ability to avoid exception throwing when generating signature > for those clients that can live with loose semantics > > Crucially (2) allows to retain compatibility with previously > serialized names. If e.g. we required all types to be erased prior to > deserialized lambda name generation, we would obtain a different hash. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8210495/ > > JBS: > > https://bugs.openjdk.java.net/browse/JDK-8210495 > > Maurizio > From peter.levart at gmail.com Sat Sep 8 07:12:40 2018 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 8 Sep 2018 09:12:40 +0200 Subject: RFR: JDK-8210009: Source Launcher classloader should support getResource and getResourceAsStream In-Reply-To: <54bc46f1-5b77-4236-fdb2-6fdfdc7db501@oracle.com> References: <5B8EF0A4.7040500@oracle.com> <5B90299B.5030209@oracle.com> <54bc46f1-5b77-4236-fdb2-6fdfdc7db501@oracle.com> Message-ID: Yes, it looks okay to me too. Regards, Peter On 09/06/2018 10:10 PM, mandy chung wrote: > > > On 9/5/18 12:08 PM, Jonathan Gibbons wrote: >> Updated webrev, addressing comments from Peter. >> >> 1. Fixed protocol string, and updated test to verify that URLs are OK >> 2. Changed init of the stream handler >> >> Webrev: http://cr.openjdk.java.net/~jjg/8210009/webrev.02/ >> > > The updated webrev looks okay. > > The test now verifies URL.toURI() - that's good (I mixed that in my > review). The formatting in src/CLTest.java seems to need some clean up > (the identation) - no need for a new webrev. > > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Mon Sep 10 16:52:45 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 10 Sep 2018 13:52:45 -0300 Subject: RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time Message-ID: <328735A4-4A01-401C-8CC0-B9ACC0F7131B@oracle.com> Please review the following webrev. This feature is a tied implementation of Raw String Literals and supporting String methods. Cheers, ? Jim webrev: http://cr.openjdk.java.net/~jlaskey/8210550/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8210550 From jonathan.gibbons at oracle.com Mon Sep 10 20:37:09 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2018 13:37:09 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager Message-ID: <5B96D5F5.7010800@oracle.com> Please review a patch to have the Source Launcher be able to work when a security manager is enabled. There are 4 parts to the work: an update to the default policy file, an update to the source launcher itself, updates to tests, and a custom security manager to help with testing. 1. src/java.base/share/lib/security/default.policy Add reasonably fine-grain permissions to give javac the permissions it needs to run when a security manager is enabled. These permissions were determined by running all javac tests under with a special security manager installed: more on that later. There is one anomalous property which was detected, which is a property to control some internal javac behavior. Arguably, it should eventually be renamed with at least a "javac.*" prefix. 2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java Update the source launcher to use doPrivileged in a couple of places: most notably around the main invocation of javac. Generally, it continues to be the policy that command-line tools like javac, javadoc do not use fine-grained doPrivileged blocks throughout the tool, and this update does not change that. It is worth noting that when javac is invoked from the Source Launcher, it does not support callbacks like annotation processors, task listeners, and other plugin code, so that eliminates any issues relating to using callbacks from code in a doPrivileged block. 3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java This is a custom new security manager for manual testing purposes in conjunction with jtreg, so that we can run a large subset of tests under the influence of a security manager. . It is a design characteristic of jtreg that almost all tests have their own distinct codebase, and so it is impractical to use a modified policy file to grant all necessary permissions to all necessary tests, so this security manager installs a custom Policy object that grants permissions to test code while deferring to the system policy for everything else (and for javac in particular.) Using this security manager, it is possible to run all the javac tests to detect with high probability all the permissions that it requires. Using a custom security manager to install a custom Policy object allows the feature to be easily enabled on the jtreg command line. There is one workaround in this security manager: a bug was uncovered such that the jdk.zipfs module needs permission to access the user.dir system property. ( https://bugs.openjdk.java.net/browse/JDK-8210469 ) A temporary workaround is used to get a clean test run. Note: this code is not directly used in any normal/automated test runs for javac; nevertheless, it is deemed worthwhile to save the code for use in similar situations in the future. 4. Minor updates to tests. Some new test cases are added to Source Launcher tests. Although most tests are not directly affected by the use of a security manager, there are some exceptions. Some tests manipulate the security manager and/or expect the security manager to be unset. These tests are modified to "pass by default" if the runtime conditions are not suitable (i.e. a security manager has been installed.) Although it is not a requirement to be able to run annotation processing tests when a security manager is enabled (because that condition cannot arise with the Source Launcher), most annotation processing tests do run successfully. There were 3 exceptions, where the test required more permissions than granted to javac in code being called from javac. These permissions were to access test.* system properties and the setIO runtime permission. Rather than grant unnecessary properties to javac, it was enough to use doPrivileged in a couple of places in the javac "toolbox" test library, and to refactor those tests to better use toolbox. In conjunction with these changes,ignoring any tests on the ProblemList, all javac tests pass, with and without a security manager being present. JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/ -- Jon From vicente.romero at oracle.com Mon Sep 10 21:12:05 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 10 Sep 2018 17:12:05 -0400 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: References: Message-ID: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> ping On 08/31/2018 03:18 PM, Vicente Romero wrote: > Please review the fix for [1] at [2]. The bug was found by a user that > was compiling some classes with JDK11 while having some old libs built > with JDK6 in the class path. It seems like some versions of javac6 > produced constructors for inner classes with no arguments. This is not > expected by newer versions of javac and it was producing a NPE. This > fix aims at making sure that ClassReader::adjustMethodParams wont > return a null even if the list of arguments passed to it is empty. > > TIA, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 > [2] http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch From forax at univ-mlv.fr Mon Sep 10 21:45:04 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 10 Sep 2018 23:45:04 +0200 (CEST) Subject: RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time In-Reply-To: <328735A4-4A01-401C-8CC0-B9ACC0F7131B@oracle.com> References: <328735A4-4A01-401C-8CC0-B9ACC0F7131B@oracle.com> Message-ID: <166250517.418649.1536615904711.JavaMail.zimbra@u-pem.fr> Hi Jim, There is a big drawback of doing that in the compiler, if String::align or String::indent has a bug, users will have to recompile all their codes which is not something we are used to in Java. Moreover, i'm not convinced by the arguments cited in the bug description 1) minimum space is used to represent the string in the class file and 2) zero runtime cost occurs. For (1) it depends! String::indent can add more spaces so the original text may may smaller than the result of a call to indent. For (2) there is no real performance penalty once the JIT (even c1) kicks in. Also, if we don't want to wait the JIT, using constant dynamic is another option. There is is another issue, why String::strip is constant folded and not String::trim ? Java 12 have not being used yet, so we do not know which method is popular and which is not, so who decide which method should be constant folded or not. And in term of implementation, - the javadoc should clearly reflect which methods is constant folded, by an annotation by example - it will help all languages that consumes the JDK API (instead of each compiler maintaining its own set) regards, R?mi ----- Mail original ----- > De: "Jim Laskey" > ?: "compiler-dev" > Envoy?: Lundi 10 Septembre 2018 18:52:45 > Objet: RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time > Please review the following webrev. This feature is a tied implementation of > Raw String Literals and supporting String methods. > > Cheers, > > ? Jim > > webrev: http://cr.openjdk.java.net/~jlaskey/8210550/webrev/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8210550 From cushon at google.com Mon Sep 10 22:54:27 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 10 Sep 2018 15:54:27 -0700 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> Message-ID: Hi Vicente, This looks good to me, for what that's worth. A couple of nits: * Consider doing the `args.isEmpty()` check earlier, at the beginning of adjustMethodParams or even before it's called. It might be slightly clearer, and it avoids processing the empty list and creating an unnecessary ListBuffer. * I thought more descriptive test names were now preferred over T8207160-style names? On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero wrote: > ping > > On 08/31/2018 03:18 PM, Vicente Romero wrote: > > Please review the fix for [1] at [2]. The bug was found by a user that > > was compiling some classes with JDK11 while having some old libs built > > with JDK6 in the class path. It seems like some versions of javac6 > > produced constructors for inner classes with no arguments. This is not > > expected by newer versions of javac and it was producing a NPE. This > > fix aims at making sure that ClassReader::adjustMethodParams wont > > return a null even if the list of arguments passed to it is empty. > > > > TIA, > > Vicente > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 > > [2] http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Sep 11 01:05:05 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 10 Sep 2018 18:05:05 -0700 Subject: RFR 8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679 Message-ID: Hi, This change fixes a regression introduced by the fix for JDK-8203679. I left a comment on the bug with my diagnosis of the crash: https://bugs.openjdk.java.net/browse/JDK-8210483?focusedCommentId=14209494&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14209494 bug: https://bugs.openjdk.java.net/browse/JDK-8210483 webrev: http://cr.openjdk.java.net/~cushon/8210483/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Sep 11 07:51:40 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 11 Sep 2018 08:51:40 +0100 Subject: RFR 8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679 In-Reply-To: References: Message-ID: <2d197480-065b-6ede-7274-18bb01481ced@oracle.com> What you did looks sensible - I'm not sure we've seen the end of it though; the issue is that there are clients that rely on this value: http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1308 So if that value changes from OVERLOAD to ERROR, a method reference would (e.g. in this case) not considered as 'stuck'. That means that we would attempt to type-check it during overload resolution in Attr. This is not a big deal (Attr will simply end up with an erroneous type), but it kind of gives an idea of the hidden scope of the change here. At the very least I would try to also fix the Overload and CheckStuckPolicy in DeferredAttr to take the new enum constant into account so that en ERROR overload kind is effectively treated as OVERLOAD for the purpose of stuck analysis. That should minimize impact. Thoughts? Maurizio On 11/09/18 02:05, Liam Miller-Cushon wrote: > Hi, > > This change fixes a regression introduced by the fix for JDK-8203679. > > I left a comment on the bug with my diagnosis of the crash: > https://bugs.openjdk.java.net/browse/JDK-8210483?focusedCommentId=14209494&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14209494 > > bug: https://bugs.openjdk.java.net/browse/JDK-8210483 > webrev: http://cr.openjdk.java.net/~cushon/8210483/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Sep 11 07:58:18 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2018 08:58:18 +0100 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5B96D5F5.7010800@oracle.com> References: <5B96D5F5.7010800@oracle.com> Message-ID: <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> On 10/09/2018 21:37, Jonathan Gibbons wrote: > Please review a patch to have the Source Launcher be able to work when > a security manager is enabled. It's not clear to me that this is an interesting use-case but in any case I think you've got two scenarios to test. One is setting java.security.manager on the command line, the other is the launched code's main method calling System.setSecurityManager which amounts to setting a security manager in a running VM. You might want to add a test case for the latter. Is there any way (spi.ToolProvider or some means) for untrusted code to indirectly run the source launcher? This question is important because the updated source launcher could be abused to probe anywhere on the file system. What are the implications for uses of javax.tools and com.sun.tools.javac.Main in code running with a security manager? Maybe that is a separate project but I would have expected to see privileged blocks in places that need permissions. -Alan From james.laskey at oracle.com Tue Sep 11 15:16:43 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 11 Sep 2018 12:16:43 -0300 Subject: RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time In-Reply-To: <166250517.418649.1536615904711.JavaMail.zimbra@u-pem.fr> References: <328735A4-4A01-401C-8CC0-B9ACC0F7131B@oracle.com> <166250517.418649.1536615904711.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, After further discussion we?ve decided close this review and move this task to JEP 303. Follow up, 1) If you have a have a constantRSL.align() or constantRSL.indent(n) you will end up with two strings in the heap after compilation (pre-call and post-call.) 2) Agree this is not a strong argument unless you are looping on the string and you haven't hit the compile threshold (rare-ish thing.) Note: this optimization was only done in preview mode. Cheers, ? Jim > On Sep 10, 2018, at 6:45 PM, Remi Forax wrote: > > Hi Jim, > There is a big drawback of doing that in the compiler, if String::align or String::indent has a bug, users will have to recompile all their codes which is not something we are used to in Java. > > Moreover, i'm not convinced by the arguments cited in the bug description > 1) minimum space is used to represent the string in the class file and > 2) zero runtime cost occurs. > > For (1) it depends! String::indent can add more spaces so the original text may may smaller than the result of a call to indent. > For (2) there is no real performance penalty once the JIT (even c1) kicks in. Also, if we don't want to wait the JIT, using constant dynamic is another option. > > There is is another issue, why String::strip is constant folded and not String::trim ? > Java 12 have not being used yet, so we do not know which method is popular and which is not, so who decide which method should be constant folded or not. > > And in term of implementation, > - the javadoc should clearly reflect which methods is constant folded, by an annotation by example > - it will help all languages that consumes the JDK API (instead of each compiler maintaining its own set) > > regards, > R?mi > > ----- Mail original ----- >> De: "Jim Laskey" >> ?: "compiler-dev" >> Envoy?: Lundi 10 Septembre 2018 18:52:45 >> Objet: RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time > >> Please review the following webrev. This feature is a tied implementation of >> Raw String Literals and supporting String methods. >> >> Cheers, >> >> ? Jim >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8210550/webrev/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8210550 From forax at univ-mlv.fr Tue Sep 11 16:49:46 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 11 Sep 2018 18:49:46 +0200 (CEST) Subject: RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time In-Reply-To: References: <328735A4-4A01-401C-8CC0-B9ACC0F7131B@oracle.com> <166250517.418649.1536615904711.JavaMail.zimbra@u-pem.fr> Message-ID: <252064863.866903.1536684586372.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Jim Laskey" > ?: "Remi Forax" > Cc: "compiler-dev" > Envoy?: Mardi 11 Septembre 2018 17:16:43 > Objet: Re: RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time > Remi, > > After further discussion we?ve decided close this review and move this task to > JEP 303. > > Follow up, > > 1) If you have a have a constantRSL.align() or constantRSL.indent(n) you will > end up with two strings in the heap after compilation (pre-call and post-call.) yes, maybe it means that when we will add the lazy resolution of the constant pool for bootstrap arguments, we should have a way to get the value of a constant pool index without caching it, so only the post-call result will be in the heap > 2) Agree this is not a strong argument unless you are looping on the string and > you haven't hit the compile threshold (rare-ish thing.) VMs routinely have a threshold per loop and do on stack replacement. And you still have the constant dynamic option, which is not zero cost but you pay the cost of the call only once. I wonder if the best is not to use constant dynamic and have a jlink plugin and/or CDS that does the constant folding, so you play the cost once if the library/application is deliver as a jar or zero if you pre-link your application. > > Note: this optimization was only done in preview mode. > > Cheers, > > ? Jim R?mi > >> On Sep 10, 2018, at 6:45 PM, Remi Forax wrote: >> >> Hi Jim, >> There is a big drawback of doing that in the compiler, if String::align or >> String::indent has a bug, users will have to recompile all their codes which is >> not something we are used to in Java. >> >> Moreover, i'm not convinced by the arguments cited in the bug description >> 1) minimum space is used to represent the string in the class file and >> 2) zero runtime cost occurs. >> >> For (1) it depends! String::indent can add more spaces so the original text may >> may smaller than the result of a call to indent. >> For (2) there is no real performance penalty once the JIT (even c1) kicks in. >> Also, if we don't want to wait the JIT, using constant dynamic is another >> option. >> >> There is is another issue, why String::strip is constant folded and not >> String::trim ? >> Java 12 have not being used yet, so we do not know which method is popular and >> which is not, so who decide which method should be constant folded or not. >> >> And in term of implementation, >> - the javadoc should clearly reflect which methods is constant folded, by an >> annotation by example >> - it will help all languages that consumes the JDK API (instead of each compiler >> maintaining its own set) >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "Jim Laskey" >>> ?: "compiler-dev" >>> Envoy?: Lundi 10 Septembre 2018 18:52:45 >>> Objet: RFR - JDK-8210550 - Applying String::align and String::indent at Compile >>> Time >> >>> Please review the following webrev. This feature is a tied implementation of >>> Raw String Literals and supporting String methods. >>> >>> Cheers, >>> >>> ? Jim >>> >>> webrev: http://cr.openjdk.java.net/~jlaskey/8210550/webrev/index.html > >> jbs: https://bugs.openjdk.java.net/browse/JDK-8210550 From vicente.romero at oracle.com Tue Sep 11 17:50:10 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 11 Sep 2018 13:50:10 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API Message-ID: Please review the first iteration of the implementation for JEP-334 [1] JVM Constants API. The implementation can be found at [2]. JEP-334 introduces an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool and has already been the subject of several discussions. The implementation of this JEP has been publicly accessible throw the amber repo at [3] in the jep-334 branch. Thanks to all members of the Amber project and specially to Brian for all the hard work on the design and the implementation of this API. Thanks for all the feedback we have received so far, most of it has been integrated in the current implementation. Thanks, Vicente [1] http://openjdk.java.net/jeps/334 [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch [3] http://hg.openjdk.java.net/amber/amber From jonathan.gibbons at oracle.com Tue Sep 11 18:42:05 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Sep 2018 11:42:05 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> Message-ID: <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> On 9/11/18 12:58 AM, Alan Bateman wrote: > On 10/09/2018 21:37, Jonathan Gibbons wrote: >> Please review a patch to have the Source Launcher be able to work >> when a security manager is enabled. > It's not clear to me that this is an interesting use-case but in any > case I think you've got two scenarios to test. One is setting > java.security.manager on the command line, the other is the launched > code's main method calling System.setSecurityManager which amounts to > setting a security manager in a running VM. You might want to add a > test case for the latter. I agree that this may not be a very interesting use case, and I have no strong feelings about whether or not to support it, except to say that I think we should specify the interaction between Source Launcher and the use of a security manager.? I note that this piece of work was triggered by the recent change to support the getResource* family of methods in the classloader used to run the user classes. At that time, it was noted that creating the URL involved directly calling a method that needed a privilege to be available (NetPermission specifyStreamHandler) (as compared to all the permissions indirectly required when invoking the compiler.) As regards the interaction between Source Launcher and the use of a security manager, I see 3 possibilities: 1. Specifically support it, as provided in this webrev 2. No code change, but update JEP 330 to specify the behavior 3. Explicitly reject the combination of Source Launcher and the security manager. > > Is there any way (spi.ToolProvider or some means) for untrusted code > to indirectly run the source launcher? This question is important > because the updated source launcher could be abused to probe anywhere > on the file system. Untrusted code can only run the source launcher by breaking encapsulation on the command line.? The source launcher is a combination of native code in the launcher itself and a class in an unexported package of jdk.compiler.? Even if you could access the source launcher, the compilation command line (i.e. the args for the internal call to javac) is highly constrained, and so it is difficult to see how the source launcher could be abused. > > What are the implications for uses of javax.tools and > com.sun.tools.javac.Main in code running with a security manager? > Maybe that is a separate project but I would have expected to see > privileged blocks in places that need permissions. The intent was to stay clear (in this changeset) of all other ways of invoking javac, meaning javax.tools, com.sun.tools.javac.Main and spi.ToolProvider. While there are relatively few ways to invoke javac, these ways all permit the use of annotation processors and other callbacks, and so we would need privileged blocks in all places where callbacks could re-enter javac. > > -Alan If we were to drop the support for a security manager from the source launcher, would you still consider it worthwhile to update the policy file to enumerate the privileges required to run javac? Setting aside the updates for the Source Launcher tests, I think the work to improve all the other tests to function better when a security manager is involved is also worth while. -- Jon From Alan.Bateman at oracle.com Tue Sep 11 19:34:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2018 20:34:35 +0100 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> Message-ID: <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> On 11/09/2018 19:42, Jonathan Gibbons wrote: > : > > As regards the interaction between Source Launcher and the use of a > security manager, I see 3 possibilities: > > 1. Specifically support it, as provided in this webrev > 2. No code change, but update JEP 330 to specify the behavior > 3. Explicitly reject the combination of Source Launcher and the > security manager. Since you've started into this then it's probably best to just continue with #1 and get it done. My main point here was the test in the webrev sets the security manager on the command line and I think you also need another test that sets in the test main method. >> >> Is there any way (spi.ToolProvider or some means) for untrusted code >> to indirectly run the source launcher? This question is important >> because the updated source launcher could be abused to probe anywhere >> on the file system. > Untrusted code can only run the source launcher by breaking > encapsulation on the command line.? The source launcher is a > combination of native code in the launcher itself and a class in an > unexported package of jdk.compiler.? Even if you could access the > source launcher, the compilation command line (i.e. the args for the > internal call to javac) is highly constrained, and so it is difficult > to see how the source launcher could be abused. Thanks, the question had to be asked because the privileged block in the source launcher main means it can access any file. >> >> What are the implications for uses of javax.tools and >> com.sun.tools.javac.Main in code running with a security manager? >> Maybe that is a separate project but I would have expected to see >> privileged blocks in places that need permissions. > The intent was to stay clear (in this changeset) of all other ways of > invoking javac, meaning javax.tools, com.sun.tools.javac.Main and > spi.ToolProvider. While there are relatively few ways to invoke javac, > these ways all permit the use of annotation processors and other > callbacks, and so we would need privileged blocks in all places where > callbacks could re-enter javac. That is what I was wondering about it. I don't see a queue at the door of developers looking to run javac with a security manager but at the same time it is possible to configure many app servers with JSP support to run with a security manager. I assume they must have historically granted at least some permissions to "tools.jar" for this to work. > > If we were to drop the support for a security manager from the source > launcher, would you still consider it worthwhile to update the policy > file to enumerate the privileges required to run javac? Setting aside > the updates for the Source Launcher tests, I think the work to improve > all the other tests to function better when a security manager is > involved is also worth while. It took a lot of work in JDK 9 to identify the minimum permissions needed by several modules. The java.xml.bind and java.xml.ws modules took a lot of effort because of the callbacks and missing privileged blocks. It does take a lot of effort and testing to be confident. So my personal view (and not my call) is that it's probably not high priority to do the same for jdk.compiler at this time. -Alan From jonathan.gibbons at oracle.com Tue Sep 11 19:44:32 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Sep 2018 12:44:32 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> Message-ID: <5B981B20.2070309@oracle.com> Alan, Thanks for all the feedback. I'll add the extra test case you suggest. -- Jon On 09/11/2018 12:34 PM, Alan Bateman wrote: > On 11/09/2018 19:42, Jonathan Gibbons wrote: >> : >> >> As regards the interaction between Source Launcher and the use of a >> security manager, I see 3 possibilities: >> >> 1. Specifically support it, as provided in this webrev >> 2. No code change, but update JEP 330 to specify the behavior >> 3. Explicitly reject the combination of Source Launcher and the >> security manager. > Since you've started into this then it's probably best to just > continue with #1 and get it done. My main point here was the test in > the webrev sets the security manager on the command line and I think > you also need another test that sets in the test main method. > > >>> >>> Is there any way (spi.ToolProvider or some means) for untrusted code >>> to indirectly run the source launcher? This question is important >>> because the updated source launcher could be abused to probe >>> anywhere on the file system. >> Untrusted code can only run the source launcher by breaking >> encapsulation on the command line. The source launcher is a >> combination of native code in the launcher itself and a class in an >> unexported package of jdk.compiler. Even if you could access the >> source launcher, the compilation command line (i.e. the args for the >> internal call to javac) is highly constrained, and so it is difficult >> to see how the source launcher could be abused. > Thanks, the question had to be asked because the privileged block in > the source launcher main means it can access any file. > >>> >>> What are the implications for uses of javax.tools and >>> com.sun.tools.javac.Main in code running with a security manager? >>> Maybe that is a separate project but I would have expected to see >>> privileged blocks in places that need permissions. >> The intent was to stay clear (in this changeset) of all other ways of >> invoking javac, meaning javax.tools, com.sun.tools.javac.Main and >> spi.ToolProvider. While there are relatively few ways to invoke >> javac, these ways all permit the use of annotation processors and >> other callbacks, and so we would need privileged blocks in all places >> where callbacks could re-enter javac. > That is what I was wondering about it. I don't see a queue at the door > of developers looking to run javac with a security manager but at the > same time it is possible to configure many app servers with JSP > support to run with a security manager. I assume they must have > historically granted at least some permissions to "tools.jar" for this > to work. > >> >> If we were to drop the support for a security manager from the source >> launcher, would you still consider it worthwhile to update the policy >> file to enumerate the privileges required to run javac? Setting aside >> the updates for the Source Launcher tests, I think the work to >> improve all the other tests to function better when a security >> manager is involved is also worth while. > It took a lot of work in JDK 9 to identify the minimum permissions > needed by several modules. The java.xml.bind and java.xml.ws modules > took a lot of effort because of the callbacks and missing privileged > blocks. It does take a lot of effort and testing to be confident. So > my personal view (and not my call) is that it's probably not high > priority to do the same for jdk.compiler at this time. > > -Alan > From sean.mullan at oracle.com Tue Sep 11 19:53:24 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Sep 2018 15:53:24 -0400 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5B96D5F5.7010800@oracle.com> References: <5B96D5F5.7010800@oracle.com> Message-ID: I have looked over the changes and they look reasonable, though I am not very familiar with this code. I was wondering, when running with the PermissiveTestSecurityManager did you also have to enable security debugging (ex: java.security.debug=access) so that you log the permissions that were required? If so, it might be helpful to add that to the comments in the test. If not, how did you figure that out? - it's not immediately apparent when looking at the code. --Sean On 9/10/18 4:37 PM, Jonathan Gibbons wrote: > Please review a patch to have the Source Launcher be able to work when a > security manager is enabled. > > There are 4 parts to the work: an update to the default policy file, an > update to the source launcher itself, updates to tests, and a custom > security manager to help with testing. > > 1. src/java.base/share/lib/security/default.policy > > Add reasonably fine-grain permissions to give javac the permissions it > needs to run when a security manager is enabled. These permissions were > determined by running all javac tests under with a special security > manager installed: more on that later. There is one anomalous property > which was detected, which is a property to control some internal javac > behavior. Arguably, it should eventually be renamed with at least a > "javac.*" prefix. > > 2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java > > Update the source launcher to use doPrivileged in a couple of places: > most notably around the main invocation of javac. Generally, it > continues to be the policy that command-line tools like javac, javadoc > do not use fine-grained doPrivileged blocks throughout the tool, and > this update does not change that.? It is worth noting that when javac is > invoked from the Source Launcher, it does not support callbacks like > annotation processors, task listeners, and other plugin code, so that > eliminates any issues relating to using callbacks from code in a > doPrivileged block. > > 3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java > > This is a custom new security manager for manual testing purposes in > conjunction with jtreg, so that we can run a large subset of tests under > the influence of a security manager. . It is a design characteristic of > jtreg that almost all tests have their own distinct codebase, and so it > is impractical to use a modified policy file to grant all necessary > permissions to all necessary tests, so this security manager installs a > custom Policy object that grants permissions to test code while > deferring to the system policy for everything else (and for javac in > particular.)?? Using this security manager, it is possible to run all > the javac tests to detect with high probability all the permissions that > it requires. Using a custom security manager to install a custom Policy > object allows the feature to be easily enabled on the jtreg command line. > > There is one workaround in this security manager: a bug was uncovered > such that the jdk.zipfs module needs permission to access the user.dir > system property.? ( https://bugs.openjdk.java.net/browse/JDK-8210469 ) A > temporary workaround is used to get a clean test run. > > Note: this code is not directly used in any normal/automated test runs > for javac; nevertheless, it is deemed worthwhile to save the code for > use in similar situations in the future. > > 4. Minor updates to tests. > > Some new test cases are added to Source Launcher tests. > > Although most tests are not directly affected by the use of a security > manager, there are some exceptions. Some tests manipulate the security > manager and/or expect the security manager to be unset.? These tests are > modified to "pass by default" if the runtime conditions are not suitable > (i.e. a security manager has been installed.) > > Although it is not a requirement to be able to run annotation processing > tests when a security manager is enabled (because that condition cannot > arise with the Source Launcher), most annotation processing tests do run > successfully. There were 3 exceptions, where the test required more > permissions than granted to javac in code being called from javac. These > permissions were to access test.* system properties and the setIO > runtime permission. Rather than grant unnecessary properties to javac, > it was enough to use doPrivileged in a couple of places in the javac > "toolbox" test library, and to refactor those tests to better use toolbox. > > In conjunction with these changes,ignoring any tests on the ProblemList, > all javac tests pass, with and without a security manager being present. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 > Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/ > > > -- Jon From jonathan.gibbons at oracle.com Tue Sep 11 20:33:48 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Sep 2018 13:33:48 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: References: <5B96D5F5.7010800@oracle.com> Message-ID: <5B9826AC.9080507@oracle.com> On 09/11/2018 12:53 PM, Sean Mullan wrote: > I have looked over the changes and they look reasonable, though I am > not very familiar with this code. > > I was wondering, when running with the PermissiveTestSecurityManager > did you also have to enable security debugging (ex: > java.security.debug=access) so that you log the permissions that were > required? If so, it might be helpful to add that to the comments in > the test. If not, how did you figure that out? - it's not immediately > apparent when looking at the code. > > --Sean Sean, Thanks for looking at this. I did not need to enable any security debugging when using the PermissiveTestSecurityManager. For the most part, the basic security infrastructure was good enough by itself, since it reported enough information in the SecurityExceptions to be able to easily determine the missing but required permissions. It helped to have a sense of what permissions might be required, such file access, system properties, and permissions for class loaders and reflections in some limited parts of javac, and the corresponding tests in the test suite. The most "tedious" part was just running the tests until all the issues had been found and fixed, but that being said, the overall process converged pretty quickly. I will note that PermissiveTestSecurityManager arrived late in the game for this work. For the most part, I was using the plain standard security manager, and was adding permissions for tests as needed in a custom policy file that I also specified on the jtreg command line. That work could never have been checked in, since it involved lots of host-specific paths in the additional policy file. It was only later on that I came up with the idea of using first a custom security manager, and from there, the idea of using a custom policy in the custom security manager. The use of PermissiveTestSecurityManager made it much faster to find and fix all remaining issues and enabled me to achieve the goal of getting all javac tests to work, instead of settling for most tests. (I had previously been prepared to set aside and ignore the main block of annotation processing tests.) -- Jon From mandy.chung at oracle.com Tue Sep 11 20:56:56 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 11 Sep 2018 13:56:56 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> Message-ID: On 9/11/18 12:34 PM, Alan Bateman wrote: >>> >>> What are the implications for uses of javax.tools and >>> com.sun.tools.javac.Main in code running with a security manager? >>> Maybe that is a separate project but I would have expected to see >>> privileged blocks in places that need permissions. >> The intent was to stay clear (in this changeset) of all other ways of >> invoking javac, meaning javax.tools, com.sun.tools.javac.Main and >> spi.ToolProvider. While there are relatively few ways to invoke >> javac, these ways all permit the use of annotation processors and >> other callbacks, and so we would need privileged blocks in all places >> where callbacks could re-enter javac. > That is what I was wondering about it. I don't see a queue at the door > of developers looking to run javac with a security manager but at the > same time it is possible to configure many app servers with JSP > support to run with a security manager. I assume they must have > historically granted at least some permissions to "tools.jar" for this > to work. > Probably.? Also they might also wrap their call to javac with doPrivileged. >> >> If we were to drop the support for a security manager from the source >> launcher, would you still consider it worthwhile to update the policy >> file to enumerate the privileges required to run javac? Setting aside >> the updates for the Source Launcher tests, I think the work to >> improve all the other tests to function better when a security >> manager is involved is also worth while. > It took a lot of work in JDK 9 to identify the minimum permissions > needed by several modules. The java.xml.bind and java.xml.ws modules > took a lot of effort because of the callbacks and missing privileged > blocks. It does take a lot of effort and testing to be confident. So > my personal view (and not my call) is that it's probably not high > priority to do the same for jdk.compiler at this time. I see this changeset is to get the source launcher to work with security manager so that launching in class file mode and source mode can specify the same runtime options. You are right that it'd be a lot of effort to get jdk.compiler to work with callbacks and missing privileged blocks.? The minimum permissions are good for source launcher support.?? If we were to drop the support for a security manager from the source launcher, I think jdk.compiler would need AllPermission due to callback. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Sep 11 23:06:07 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 11 Sep 2018 16:06:07 -0700 Subject: RFR 8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679 In-Reply-To: <2d197480-065b-6ede-7274-18bb01481ced@oracle.com> References: <2d197480-065b-6ede-7274-18bb01481ced@oracle.com> Message-ID: On Tue, Sep 11, 2018 at 12:51 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > What you did looks sensible - I'm not sure we've seen the end of it > though; the issue is that there are clients that rely on this value: > > > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1308 > > So if that value changes from OVERLOAD to ERROR, a method reference would > (e.g. in this case) not considered as 'stuck'. That means that we would > attempt to type-check it during overload resolution in Attr. This is not a > big deal (Attr will simply end up with an erroneous type), but it kind of > gives an idea of the hidden scope of the change here. > > At the very least I would try to also fix the Overload and > CheckStuckPolicy in DeferredAttr to take the new enum constant into account > so that en ERROR overload kind is effectively treated as OVERLOAD for the > purpose of stuck analysis. That should minimize impact. > I might be missing something, but I tried to update all uses I found of the enum. E.g. for the use you linked to in DeferredAttr: - if (tree.getOverloadKind() == JCMemberReference.OverloadKind.OVERLOADED) { + if (tree.getOverloadKind() != JCMemberReference.OverloadKind.UNOVERLOADED) { (see: http://cr.openjdk.java.net/~cushon/8210483/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java.sdiff.html ) So we should be treating method references as stuck unless they're specifically UNOVERLOADED, which seems consistent with the previous behaviour. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Sep 11 23:40:16 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 11 Sep 2018 16:40:16 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: On Fri, Jul 27, 2018 at 1:25 PM Werner Dietl wrote: > Hi Liam, > > thanks, this looks very nice! Removing all this incorrect code is > great. The examples I tried worked correctly. > Thanks Werner! I have rebased the patch, and confirmed the tests are still passing. Here's the latest version: http://cr.openjdk.java.net/~cushon/8198945/webrev.05/ Is there any additional feedback on this change? -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Sep 12 09:12:50 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 12 Sep 2018 10:12:50 +0100 Subject: RFR 8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679 In-Reply-To: References: <2d197480-065b-6ede-7274-18bb01481ced@oracle.com> Message-ID: <0c3e1844-9ec5-0517-b7ac-e3bc1bed53f9@oracle.com> Ok - for some reason I did miss these changes in DeferredAttr. What you have looks good. Maurizio On 12/09/18 00:06, Liam Miller-Cushon wrote: > On Tue, Sep 11, 2018 at 12:51 AM Maurizio Cimadamore > > wrote: > > What you did looks sensible - I'm not sure we've seen the end of > it though; the issue is that there are clients that rely on this > value: > > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1308 > > So if that value changes from OVERLOAD to ERROR, a method > reference would (e.g. in this case) not considered as 'stuck'. > That means that we would attempt to type-check it during overload > resolution in Attr. This is not a big deal (Attr will simply end > up with an erroneous type), but it kind of gives an idea of the > hidden scope of the change here. > > At the very least I would try to also fix the Overload and > CheckStuckPolicy in DeferredAttr to take the new enum constant > into account so that en ERROR overload kind is effectively treated > as OVERLOAD for the purpose of stuck analysis. That should > minimize impact. > > I might be missing something, but I tried to update all uses I found > of the enum. E.g. for the use you linked to in DeferredAttr: > > - if (tree.getOverloadKind() == > JCMemberReference.OverloadKind.OVERLOADED) { > + if (tree.getOverloadKind() != > JCMemberReference.OverloadKind.UNOVERLOADED) { > > (see: > http://cr.openjdk.java.net/~cushon/8210483/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java.sdiff.html > ) > > So we should be treating method references as stuck unless they're > specifically UNOVERLOADED, which seems consistent with the previous > behaviour. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Sep 12 11:49:37 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 12 Sep 2018 13:49:37 +0200 Subject: RFF (12): JDK-8207954: Data for --release 11 In-Reply-To: <5B58942B.5090308@oracle.com> References: <5B55BF9E.1090901@oracle.com> <8bad4563-4c8d-7246-1976-4b80a6b59ce9@oracle.com> <5B58942B.5090308@oracle.com> Message-ID: <5B98FD51.9060509@oracle.com> Hi, I've updated the data patch to include the recently added java.net.http.HttpConnectTimeoutException (see JDK-8209187): http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.01/ The code patch remains unchanged from the last round: http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.01/ Any feedback on this? Thanks, Jan On 25.7.2018 17:15, Jan Lahoda wrote: > Thanks Erik. I've updated the code patch here: > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.01/ > > (the data patch remains the same) > > Does this look better? > > Thanks, > Jan > > On 23.7.2018 18:56, Erik Joelsson wrote: >> Hello Jan, >> >> The assignment of a non existent directory looks suspect. You should be >> able assign to an empty value using ?=. On the other hand, what it looks >> like you want to achieve is having both the open and closed value on the >> command line. Then I would just change the ?= to +=. >> >> /Erik >> >> >> On 2018-07-23 04:44, Jan Lahoda wrote: >>> Hi, >>> >>> To support --release 11 in JDK 12, historical data for JDK 11 need to >>> be added. As new attributes (NestHost and NestMembers) have been added >>> to the classfile, there also needs to be some tweaking of the tool >>> that creates the historical descriptions and the ct.sym sigfiles. >>> >>> The proposed patch has two parts: >>> -code changes, which include: >>> --update to the build scripts and the tool, so that the tool can read >>> both the open and extra/closed description of the ct.sym content, and >>> merge those (there should not be any extra/closed for JDK 11, AFAIK, >>> so this is to avoid having to update the closed part). >>> --improving the description on how to add historical data for new >>> releases, using the new source launcher >>> --adding support for the new NestHost/NestMembers attributes >>> --adding a new test which strives to fail when a new attribute is >>> added and CreateSymbols is not updated >>> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ >>> >>> -addition of the historical data: >>> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ >>> (these may need to be re-generated when the final JDK 11 is released >>> in case there are any changes, but that should be very simple) >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 >>> >>> Any feedback is welcome, >>> Jan >> From magnus.ihse.bursie at oracle.com Wed Sep 12 12:07:58 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Sep 2018 14:07:58 +0200 Subject: RFF (12): JDK-8207954: Data for --release 11 In-Reply-To: <5B98FD51.9060509@oracle.com> References: <5B55BF9E.1090901@oracle.com> <8bad4563-4c8d-7246-1976-4b80a6b59ce9@oracle.com> <5B58942B.5090308@oracle.com> <5B98FD51.9060509@oracle.com> Message-ID: On 2018-09-12 13:49, Jan Lahoda wrote: > Hi, > > I've updated the data patch to include the recently added > java.net.http.HttpConnectTimeoutException (see JDK-8209187): > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.01/ > > The code patch remains unchanged from the last round: > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.01/ > > Any feedback on this? No objections from the build perspective. /Magnus > > Thanks, > ??? Jan > > On 25.7.2018 17:15, Jan Lahoda wrote: >> Thanks Erik. I've updated the code patch here: >> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.01/ >> >> (the data patch remains the same) >> >> Does this look better? >> >> Thanks, >> ???? Jan >> >> On 23.7.2018 18:56, Erik Joelsson wrote: >>> Hello Jan, >>> >>> The assignment of a non existent directory looks suspect. You should be >>> able assign to an empty value using ?=. On the other hand, what it >>> looks >>> like you want to achieve is having both the open and closed value on >>> the >>> command line. Then I would just change the ?= to +=. >>> >>> /Erik >>> >>> >>> On 2018-07-23 04:44, Jan Lahoda wrote: >>>> Hi, >>>> >>>> To support --release 11 in JDK 12, historical data for JDK 11 need to >>>> be added. As new attributes (NestHost and NestMembers) have been added >>>> to the classfile, there also needs to be some tweaking of the tool >>>> that creates the historical descriptions and the ct.sym sigfiles. >>>> >>>> The proposed patch has two parts: >>>> -code changes, which include: >>>> --update to the build scripts and the tool, so that the tool can read >>>> both the open and extra/closed description of the ct.sym content, and >>>> merge those (there should not be any extra/closed for JDK 11, AFAIK, >>>> so this is to avoid having to update the closed part). >>>> --improving the description on how to add historical data for new >>>> releases, using the new source launcher >>>> --adding support for the new NestHost/NestMembers attributes >>>> --adding a new test which strives to fail when a new attribute is >>>> added and CreateSymbols is not updated >>>> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ >>>> >>>> -addition of the historical data: >>>> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ >>>> (these may need to be re-generated when the final JDK 11 is released >>>> in case there are any changes, but that should be very simple) >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 >>>> >>>> Any feedback is welcome, >>>> ???? Jan >>> From vicente.romero at oracle.com Wed Sep 12 12:13:23 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 12 Sep 2018 08:13:23 -0400 Subject: RFR 8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679 In-Reply-To: References: <2d197480-065b-6ede-7274-18bb01481ced@oracle.com> Message-ID: <6d6b9298-5676-42ec-2bec-98c9e6fd2048@oracle.com> looks good to me too, Vicente On 09/11/2018 07:06 PM, Liam Miller-Cushon wrote: > On Tue, Sep 11, 2018 at 12:51 AM Maurizio Cimadamore > > wrote: > > What you did looks sensible - I'm not sure we've seen the end of > it though; the issue is that there are clients that rely on this > value: > > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1308 > > So if that value changes from OVERLOAD to ERROR, a method > reference would (e.g. in this case) not considered as 'stuck'. > That means that we would attempt to type-check it during overload > resolution in Attr. This is not a big deal (Attr will simply end > up with an erroneous type), but it kind of gives an idea of the > hidden scope of the change here. > > At the very least I would try to also fix the Overload and > CheckStuckPolicy in DeferredAttr to take the new enum constant > into account so that en ERROR overload kind is effectively treated > as OVERLOAD for the purpose of stuck analysis. That should > minimize impact. > > I might be missing something, but I tried to update all uses I found > of the enum. E.g. for the use you linked to in DeferredAttr: > > - if (tree.getOverloadKind() == > JCMemberReference.OverloadKind.OVERLOADED) { > + if (tree.getOverloadKind() != > JCMemberReference.OverloadKind.UNOVERLOADED) { > > (see: > http://cr.openjdk.java.net/~cushon/8210483/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java.sdiff.html > ) > > So we should be treating method references as stuck unless they're > specifically UNOVERLOADED, which seems consistent with the previous > behaviour. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Wed Sep 12 19:28:06 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 12 Sep 2018 21:28:06 +0200 Subject: RFR JDK-8183548: Comma-expressions shouldn't use any temporary variable Message-ID: Hi, Please review the following straightforward fix for [1] to avoid using any temporary variable in comma expressions. It makes use of the recently (as part of [2]) enhanced 'LetExpr' to allow more than one statement. Any feedback is welcome (langtools:tier1 is OK), Bernard [1] https://bugs.openjdk.java.net/browse/JDK-8183548 [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012197.html diff -r 3aafd7015d87 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java Wed Sep 12 14:24:17 2018 +0200 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java Wed Sep 12 20:31:32 2018 +0200 @@ -2057,7 +2057,9 @@ // evaluate and discard the first expression, then evaluate the second. JCExpression makeComma(final JCExpression expr1, final JCExpression expr2) { - return abstractRval(expr1, discarded -> expr2); + JCExpression res = make.LetExpr(List.of(make.Exec(expr1)), expr2); + res.type = expr2.type; + return res; } /************************************************************************** diff -r 3aafd7015d87 test/langtools/tools/javac/desugar/BoxingAndSuper.java --- a/test/langtools/tools/javac/desugar/BoxingAndSuper.java Wed Sep 12 14:24:17 2018 +0200 +++ b/test/langtools/tools/javac/desugar/BoxingAndSuper.java Wed Sep 12 20:31:32 2018 +0200 @@ -100,7 +100,7 @@ "p.Test.dump()java.lang.Integer\n" + "{\n" + " return (let /*synthetic*/ final Integer $le0 = (Integer)super.i " + - "in (let /*synthetic*/ final Integer $le1 = super.i = Integer.valueOf((int)(super.i.intValue() + 1)) " + + "in (let super.i = Integer.valueOf((int)(super.i.intValue() + 1)); " + "in $le0));\n" + "}\n"); //qualified super, same package: @@ -121,7 +121,7 @@ "p.Test.Inner.dump()java.lang.Integer\n" + "{\n" + " return (let /*synthetic*/ final Integer $le0 = (Integer)Test.access$001(this$0) " + - "in (let /*synthetic*/ final Integer $le1 = Test.access$103(this$0, Integer.valueOf((int)(Test.access$201(this$0).intValue() + 1))) " + + "in (let Test.access$103(this$0, Integer.valueOf((int)(Test.access$201(this$0).intValue() + 1))); " + "in $le0));\n" + "}\n" + "p.Test.access$001(p.Test)java.lang.Integer\n" + @@ -152,7 +152,7 @@ "p1.Test.dump()java.lang.Integer\n" + "{\n" + " return (let /*synthetic*/ final Integer $le0 = (Integer)super.i " + - "in (let /*synthetic*/ final Integer $le1 = super.i = Integer.valueOf((int)(super.i.intValue() + 1)) " + + "in (let super.i = Integer.valueOf((int)(super.i.intValue() + 1)); " + "in $le0));\n" + "}\n"); //qualified super, different packages: @@ -173,7 +173,7 @@ "p1.Test.Inner.dump()java.lang.Integer\n" + "{\n" + " return (let /*synthetic*/ final Integer $le0 = (Integer)Test.access$001(this$0) " + - "in (let /*synthetic*/ final Integer $le1 = Test.access$103(this$0, Integer.valueOf((int)(Test.access$201(this$0).intValue() + 1))) " + + "in (let Test.access$103(this$0, Integer.valueOf((int)(Test.access$201(this$0).intValue() + 1))); " + "in $le0));\n" + "}\n" + "p1.Test.access$001(p1.Test)java.lang.Integer\n" + @@ -201,8 +201,8 @@ String expected = "Test.dump()void\n" + "{\n" + - " (let /*synthetic*/ final Integer $le0 = i in (let /*synthetic*/ final Integer $le1 = i = Integer.valueOf((int)(i.intValue() + 1)) in $le0));\n" + - " (let /*synthetic*/ final Integer $le2 = (Integer)this.i in (let /*synthetic*/ final Integer $le3 = this.i = Integer.valueOf((int)(this.i.intValue() + 1)) in $le2));\n" + + " (let /*synthetic*/ final Integer $le0 = i in (let i = Integer.valueOf((int)(i.intValue() + 1)); in $le0));\n" + + " (let /*synthetic*/ final Integer $le1 = (Integer)this.i in (let this.i = Integer.valueOf((int)(this.i.intValue() + 1)); in $le1));\n" + "}\n"; runTest(code, expected); //qualified this: @@ -219,8 +219,8 @@ "Test.Inner1.Inner2.dump()java.lang.Integer\n" + "{\n" + " return (let /*synthetic*/ final Integer $le0 = (Integer)this$1.this$0.i" + - " in (let /*synthetic*/ final Integer $le1 = this$1.this$0.i = " + - "Integer.valueOf((int)(this$1.this$0.i.intValue() + 1)) " + + " in (let this$1.this$0.i = " + + "Integer.valueOf((int)(this$1.this$0.i.intValue() + 1)); " + "in $le0));\n" + "}\n" ); @@ -329,7 +329,8 @@ LetExpr le = (LetExpr) tree; for (JCStatement var : le.defs) { - letExprRemap.put(((JCVariableDecl) var).name.toString(), "$le" + i++); + if (var.hasTag(Tag.VARDEF)) + letExprRemap.put(((JCVariableDecl) var).name.toString(), "$le" + i++); } } return super.visitOther(node, p); From vicente.romero at oracle.com Wed Sep 12 19:36:08 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 12 Sep 2018 15:36:08 -0400 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> Message-ID: <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> Hi Liam, Thanks for your comments, I have updated the patch [1], [1] http://cr.openjdk.java.net/~vromero/8207160/webrev.01/jdk.dev.patch On 09/10/2018 06:54 PM, Liam Miller-Cushon wrote: > Hi Vicente, > > This looks good to me, for what that's worth. > > A couple of nits: > * Consider doing the `args.isEmpty()` check earlier, at the beginning > of adjustMethodParams or even before it's called. It might be slightly > clearer, and it avoids processing the empty list and creating an > unnecessary ListBuffer. > * I thought more descriptive test names were now preferred over > T8207160-style names? > > On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero > > wrote: > > ping > > On 08/31/2018 03:18 PM, Vicente Romero wrote: > > Please review the fix for [1] at [2]. The bug was found by a > user that > > was compiling some classes with JDK11 while having some old libs > built > > with JDK6 in the class path. It seems like some versions of javac6 > > produced constructors for inner classes with no arguments. This > is not > > expected by newer versions of javac and it was producing a NPE. > This > > fix aims at making sure that ClassReader::adjustMethodParams wont > > return a null even if the list of arguments passed to it is empty. > > > > TIA, > > Vicente > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 > > [2] > http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Wed Sep 12 19:55:23 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 12 Sep 2018 16:55:23 -0300 Subject: RFR: JDK-8210671 CheckExamples.java fail after Raw String Literals checkin Message-ID: Add to not-yet until tests are added. webrev: http://cr.openjdk.java.net//~jlaskey/8210671/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8210671 From vicente.romero at oracle.com Wed Sep 12 19:58:50 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 12 Sep 2018 15:58:50 -0400 Subject: RFR: JDK-8210671 CheckExamples.java fail after Raw String Literals checkin In-Reply-To: References: Message-ID: <68b2b942-8849-0c52-821e-bc1c0698bcc9@oracle.com> looks good, Vicente On 09/12/2018 03:55 PM, Jim Laskey wrote: > Add to not-yet until tests are added. > > > webrev: http://cr.openjdk.java.net//~jlaskey/8210671/webrev/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8210671 > From joe.darcy at oracle.com Wed Sep 12 20:01:12 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 12 Sep 2018 13:01:12 -0700 Subject: RFR: JDK-8210671 CheckExamples.java fail after Raw String Literals checkin In-Reply-To: <68b2b942-8849-0c52-821e-bc1c0698bcc9@oracle.com> References: <68b2b942-8849-0c52-821e-bc1c0698bcc9@oracle.com> Message-ID: <69f25b09-9f7a-98ae-80dd-d132d3961df4@oracle.com> Looks okay, but please add a link to a follow-up bug for a fuller fix. -Joe On 9/12/2018 12:58 PM, Vicente Romero wrote: > looks good, > Vicente > > On 09/12/2018 03:55 PM, Jim Laskey wrote: >> Add to not-yet until tests are added. >> >> >> webrev: http://cr.openjdk.java.net//~jlaskey/8210671/webrev/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8210671 >> > From james.laskey at oracle.com Wed Sep 12 20:01:45 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 12 Sep 2018 17:01:45 -0300 Subject: RFR: JDK-8210671 CheckExamples.java fail after Raw String Literals checkin In-Reply-To: <69f25b09-9f7a-98ae-80dd-d132d3961df4@oracle.com> References: <68b2b942-8849-0c52-821e-bc1c0698bcc9@oracle.com> <69f25b09-9f7a-98ae-80dd-d132d3961df4@oracle.com> Message-ID: Will do. > On Sep 12, 2018, at 5:01 PM, joe darcy wrote: > > Looks okay, but please add a link to a follow-up bug for a fuller fix. > > -Joe > > > On 9/12/2018 12:58 PM, Vicente Romero wrote: >> looks good, >> Vicente >> >> On 09/12/2018 03:55 PM, Jim Laskey wrote: >>> Add to not-yet until tests are added. >>> >>> >>> webrev: http://cr.openjdk.java.net//~jlaskey/8210671/webrev/index.html >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8210671 >>> >> > From cushon at google.com Wed Sep 12 20:23:36 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 12 Sep 2018 13:23:36 -0700 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> Message-ID: Looks good, thanks! On Wed, Sep 12, 2018 at 12:36 PM Vicente Romero wrote: > Hi Liam, > > Thanks for your comments, I have updated the patch [1], > > [1] http://cr.openjdk.java.net/~vromero/8207160/webrev.01/jdk.dev.patch > > > On 09/10/2018 06:54 PM, Liam Miller-Cushon wrote: > > Hi Vicente, > > This looks good to me, for what that's worth. > > A couple of nits: > * Consider doing the `args.isEmpty()` check earlier, at the beginning of adjustMethodParams > or even before it's called. It might be slightly clearer, and it avoids > processing the empty list and creating an unnecessary ListBuffer. > * I thought more descriptive test names were now preferred over T8207160-style > names? > > On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero > wrote: > >> ping >> >> On 08/31/2018 03:18 PM, Vicente Romero wrote: >> > Please review the fix for [1] at [2]. The bug was found by a user that >> > was compiling some classes with JDK11 while having some old libs built >> > with JDK6 in the class path. It seems like some versions of javac6 >> > produced constructors for inner classes with no arguments. This is not >> > expected by newer versions of javac and it was producing a NPE. This >> > fix aims at making sure that ClassReader::adjustMethodParams wont >> > return a null even if the list of arguments passed to it is empty. >> > >> > TIA, >> > Vicente >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 >> > [2] http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Sep 12 20:41:29 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 12 Sep 2018 21:41:29 +0100 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> Message-ID: <38b6ddd5-e077-6939-273e-149addbd55b5@oracle.com> There's no copyright on the jasm file - is that deliberate? Thanks Maurizio On 12/09/18 21:23, Liam Miller-Cushon wrote: > Looks good, thanks! > > On Wed, Sep 12, 2018 at 12:36 PM Vicente Romero > > wrote: > > Hi Liam, > > Thanks for your comments, I have updated the patch [1], > > [1] > http://cr.openjdk.java.net/~vromero/8207160/webrev.01/jdk.dev.patch > > > On 09/10/2018 06:54 PM, Liam Miller-Cushon wrote: >> Hi Vicente, >> >> This looks good to me, for what that's worth. >> >> A couple of nits: >> * Consider doing the `args.isEmpty()` check earlier, at the >> beginning of adjustMethodParams or even before it's called. It >> might be slightly clearer, and it avoids processing the empty >> list and creating an unnecessary ListBuffer. >> * I thought more descriptive test names were now preferred over >> T8207160-style names? >> >> On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero >> > wrote: >> >> ping >> >> On 08/31/2018 03:18 PM, Vicente Romero wrote: >> > Please review the fix for [1] at [2]. The bug was found by >> a user that >> > was compiling some classes with JDK11 while having some old >> libs built >> > with JDK6 in the class path. It seems like some versions of >> javac6 >> > produced constructors for inner classes with no arguments. >> This is not >> > expected by newer versions of javac and it was producing a >> NPE. This >> > fix aims at making sure that >> ClassReader::adjustMethodParams wont >> > return a null even if the list of arguments passed to it is >> empty. >> > >> > TIA, >> > Vicente >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 >> > [2] >> http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Sep 12 20:50:31 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 12 Sep 2018 16:50:31 -0400 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: <38b6ddd5-e077-6939-273e-149addbd55b5@oracle.com> References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> <38b6ddd5-e077-6939-273e-149addbd55b5@oracle.com> Message-ID: <92638059-b8d7-b9f1-2152-bd3c36398bf4@oracle.com> On 09/12/2018 04:41 PM, Maurizio Cimadamore wrote: > > There's no copyright on the jasm file - is that deliberate? > I just forgot :|, I have updated the webrev: http://cr.openjdk.java.net/~vromero/8207160/webrev.02/jdk.dev.patch > Thanks > Maurizio > > > On 12/09/18 21:23, Liam Miller-Cushon wrote: >> Looks good, thanks! >> >> On Wed, Sep 12, 2018 at 12:36 PM Vicente Romero >> > wrote: >> >> Hi Liam, >> >> Thanks for your comments, I have updated the patch [1], >> >> [1] >> http://cr.openjdk.java.net/~vromero/8207160/webrev.01/jdk.dev.patch >> >> >> On 09/10/2018 06:54 PM, Liam Miller-Cushon wrote: >>> Hi Vicente, >>> >>> This looks good to me, for what that's worth. >>> >>> A couple of nits: >>> * Consider doing the `args.isEmpty()` check earlier, at the >>> beginning of adjustMethodParams or even before it's called. It >>> might be slightly clearer, and it avoids processing the empty >>> list and creating an unnecessary ListBuffer. >>> * I thought more descriptive test names were now preferred over >>> T8207160-style names? >>> >>> On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero >>> > >>> wrote: >>> >>> ping >>> >>> On 08/31/2018 03:18 PM, Vicente Romero wrote: >>> > Please review the fix for [1] at [2]. The bug was found by >>> a user that >>> > was compiling some classes with JDK11 while having some >>> old libs built >>> > with JDK6 in the class path. It seems like some versions >>> of javac6 >>> > produced constructors for inner classes with no arguments. >>> This is not >>> > expected by newer versions of javac and it was producing a >>> NPE. This >>> > fix aims at making sure that >>> ClassReader::adjustMethodParams wont >>> > return a null even if the list of arguments passed to it >>> is empty. >>> > >>> > TIA, >>> > Vicente >>> > >>> > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 >>> > [2] >>> http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Sep 12 20:51:43 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 12 Sep 2018 21:51:43 +0100 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: <92638059-b8d7-b9f1-2152-bd3c36398bf4@oracle.com> References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> <38b6ddd5-e077-6939-273e-149addbd55b5@oracle.com> <92638059-b8d7-b9f1-2152-bd3c36398bf4@oracle.com> Message-ID: Looks good Maurizio On 12/09/18 21:50, Vicente Romero wrote: > > > On 09/12/2018 04:41 PM, Maurizio Cimadamore wrote: >> >> There's no copyright on the jasm file - is that deliberate? >> > > I just forgot :|, I have updated the webrev: > > http://cr.openjdk.java.net/~vromero/8207160/webrev.02/jdk.dev.patch > > >> Thanks >> Maurizio >> >> >> On 12/09/18 21:23, Liam Miller-Cushon wrote: >>> Looks good, thanks! >>> >>> On Wed, Sep 12, 2018 at 12:36 PM Vicente Romero >>> > wrote: >>> >>> Hi Liam, >>> >>> Thanks for your comments, I have updated the patch [1], >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/8207160/webrev.01/jdk.dev.patch >>> >>> >>> On 09/10/2018 06:54 PM, Liam Miller-Cushon wrote: >>>> Hi Vicente, >>>> >>>> This looks good to me, for what that's worth. >>>> >>>> A couple of nits: >>>> * Consider doing the `args.isEmpty()` check earlier, at the >>>> beginning of adjustMethodParams or even before it's called. It >>>> might be slightly clearer, and it avoids processing the empty >>>> list and creating an unnecessary ListBuffer. >>>> * I thought more descriptive test names were now preferred over >>>> T8207160-style names? >>>> >>>> On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero >>>> > >>>> wrote: >>>> >>>> ping >>>> >>>> On 08/31/2018 03:18 PM, Vicente Romero wrote: >>>> > Please review the fix for [1] at [2]. The bug was found >>>> by a user that >>>> > was compiling some classes with JDK11 while having some >>>> old libs built >>>> > with JDK6 in the class path. It seems like some versions >>>> of javac6 >>>> > produced constructors for inner classes with no >>>> arguments. This is not >>>> > expected by newer versions of javac and it was producing >>>> a NPE. This >>>> > fix aims at making sure that >>>> ClassReader::adjustMethodParams wont >>>> > return a null even if the list of arguments passed to it >>>> is empty. >>>> > >>>> > TIA, >>>> > Vicente >>>> > >>>> > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 >>>> > [2] >>>> http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Sep 12 20:55:33 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 12 Sep 2018 16:55:33 -0400 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: <92638059-b8d7-b9f1-2152-bd3c36398bf4@oracle.com> References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> <38b6ddd5-e077-6939-273e-149addbd55b5@oracle.com> <92638059-b8d7-b9f1-2152-bd3c36398bf4@oracle.com> Message-ID: it seems like the link is referring to an old webrev, this one should work: http://cr.openjdk.java.net/~vromero/8207160/webrev.02/jdk.dev.patch On 09/12/2018 04:50 PM, Vicente Romero wrote: > > > On 09/12/2018 04:41 PM, Maurizio Cimadamore wrote: >> >> There's no copyright on the jasm file - is that deliberate? >> > > I just forgot :|, I have updated the webrev: > > http://cr.openjdk.java.net/~vromero/8207160/webrev.02/jdk.dev.patch > > >> Thanks >> Maurizio >> >> >> On 12/09/18 21:23, Liam Miller-Cushon wrote: >>> Looks good, thanks! >>> >>> On Wed, Sep 12, 2018 at 12:36 PM Vicente Romero >>> > wrote: >>> >>> Hi Liam, >>> >>> Thanks for your comments, I have updated the patch [1], >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/8207160/webrev.01/jdk.dev.patch >>> >>> >>> On 09/10/2018 06:54 PM, Liam Miller-Cushon wrote: >>>> Hi Vicente, >>>> >>>> This looks good to me, for what that's worth. >>>> >>>> A couple of nits: >>>> * Consider doing the `args.isEmpty()` check earlier, at the >>>> beginning of adjustMethodParams or even before it's called. It >>>> might be slightly clearer, and it avoids processing the empty >>>> list and creating an unnecessary ListBuffer. >>>> * I thought more descriptive test names were now preferred over >>>> T8207160-style names? >>>> >>>> On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero >>>> > >>>> wrote: >>>> >>>> ping >>>> >>>> On 08/31/2018 03:18 PM, Vicente Romero wrote: >>>> > Please review the fix for [1] at [2]. The bug was found >>>> by a user that >>>> > was compiling some classes with JDK11 while having some >>>> old libs built >>>> > with JDK6 in the class path. It seems like some versions >>>> of javac6 >>>> > produced constructors for inner classes with no >>>> arguments. This is not >>>> > expected by newer versions of javac and it was producing >>>> a NPE. This >>>> > fix aims at making sure that >>>> ClassReader::adjustMethodParams wont >>>> > return a null even if the list of arguments passed to it >>>> is empty. >>>> > >>>> > TIA, >>>> > Vicente >>>> > >>>> > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 >>>> > [2] >>>> http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Wed Sep 12 21:01:30 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 12 Sep 2018 18:01:30 -0300 Subject: RFR - JDK-8210674 - Need to add examples for use of javac properties introduced by Raw String Literals Message-ID: <6E3B39AC-7BA3-4D0E-A007-866809259529@oracle.com> Please review the following misstep; webrev: http://cr.openjdk.java.net/~jlaskey/8210674/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8210674 Cheers, ? Jim From vicente.romero at oracle.com Wed Sep 12 21:45:30 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 12 Sep 2018 17:45:30 -0400 Subject: RFR - JDK-8210674 - Need to add examples for use of javac properties introduced by Raw String Literals In-Reply-To: <6E3B39AC-7BA3-4D0E-A007-866809259529@oracle.com> References: <6E3B39AC-7BA3-4D0E-A007-866809259529@oracle.com> Message-ID: Hi Jim, Looks good but as a suggestion you can fold both examples into one, Thanks, Vicente On 09/12/2018 05:01 PM, Jim Laskey wrote: > Please review the following misstep; > > webrev: http://cr.openjdk.java.net/~jlaskey/8210674/webrev/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8210674 > > Cheers, > > ? Jim > > From bsrbnd at gmail.com Wed Sep 12 21:49:31 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 12 Sep 2018 23:49:31 +0200 Subject: RFR JDK-8183548: Comma-expressions shouldn't use any temporary variable In-Reply-To: References: Message-ID: On Wed, 12 Sep 2018 at 21:28, B. Blaser wrote: > > Hi, > > Please review the following straightforward fix for [1] to avoid using > any temporary variable in comma expressions. > It makes use of the recently (as part of [2]) enhanced 'LetExpr' to > allow more than one statement. > > Any feedback is welcome (langtools:tier1 is OK), > Bernard > > [1] https://bugs.openjdk.java.net/browse/JDK-8183548 > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012197.html Webrev: http://cr.openjdk.java.net/~bsrbnd/jdk8183548/webrev.00/ Thanks, Bernard From jonathan.gibbons at oracle.com Wed Sep 12 21:53:35 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Sep 2018 14:53:35 -0700 Subject: RFR - JDK-8210674 - Need to add examples for use of javac properties introduced by Raw String Literals In-Reply-To: References: <6E3B39AC-7BA3-4D0E-A007-866809259529@oracle.com> Message-ID: <901106c4-0aea-558b-db61-0a2cac7f330a@oracle.com> In general, it would be bad style to have one example serving multiple diagnostics, since that often implies that the example is not as simple as it could be for any one message. This example is borderline, because some of the messages will go away if and when Raw String Literals gets promoted from being a preview feature to an official feature. -- Jon On 9/12/18 2:45 PM, Vicente Romero wrote: > Hi Jim, > > Looks good but as a suggestion you can fold both examples into one, > > Thanks, > Vicente > > On 09/12/2018 05:01 PM, Jim Laskey wrote: >> Please review the following misstep; >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8210674/webrev/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8210674 >> >> Cheers, >> >> ? Jim >> >> > From maurizio.cimadamore at oracle.com Thu Sep 13 10:38:16 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 13 Sep 2018 11:38:16 +0100 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty In-Reply-To: References: <2d76b4e5-b506-cf8a-ff3d-920e81f6bb81@oracle.com> <38b43389-c810-2cab-7cfe-deca6088224d@oracle.com> <38b6ddd5-e077-6939-273e-149addbd55b5@oracle.com> <92638059-b8d7-b9f1-2152-bd3c36398bf4@oracle.com> Message-ID: <40eba0bf-5c2d-3f63-3f60-81da7883c41b@oracle.com> Yeah that's the one I approved, as I figured out that there was a discrepancy between the text and the hyperlink :-) On 12/09/18 21:55, Vicente Romero wrote: > it seems like the link is referring to an old webrev, this one should > work: > > http://cr.openjdk.java.net/~vromero/8207160/webrev.02/jdk.dev.patch > > On 09/12/2018 04:50 PM, Vicente Romero wrote: >> >> >> On 09/12/2018 04:41 PM, Maurizio Cimadamore wrote: >>> >>> There's no copyright on the jasm file - is that deliberate? >>> >> >> I just forgot :|, I have updated the webrev: >> >> http://cr.openjdk.java.net/~vromero/8207160/webrev.02/jdk.dev.patch >> >> >>> Thanks >>> Maurizio >>> >>> >>> On 12/09/18 21:23, Liam Miller-Cushon wrote: >>>> Looks good, thanks! >>>> >>>> On Wed, Sep 12, 2018 at 12:36 PM Vicente Romero >>>> > wrote: >>>> >>>> Hi Liam, >>>> >>>> Thanks for your comments, I have updated the patch [1], >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/8207160/webrev.01/jdk.dev.patch >>>> >>>> >>>> On 09/10/2018 06:54 PM, Liam Miller-Cushon wrote: >>>>> Hi Vicente, >>>>> >>>>> This looks good to me, for what that's worth. >>>>> >>>>> A couple of nits: >>>>> * Consider doing the `args.isEmpty()` check earlier, at the >>>>> beginning of adjustMethodParams or even before it's called. It >>>>> might be slightly clearer, and it avoids processing the empty >>>>> list and creating an unnecessary ListBuffer. >>>>> * I thought more descriptive test names were now preferred >>>>> over T8207160-style names? >>>>> >>>>> On Mon, Sep 10, 2018 at 2:13 PM Vicente Romero >>>>> > >>>>> wrote: >>>>> >>>>> ping >>>>> >>>>> On 08/31/2018 03:18 PM, Vicente Romero wrote: >>>>> > Please review the fix for [1] at [2]. The bug was found >>>>> by a user that >>>>> > was compiling some classes with JDK11 while having some >>>>> old libs built >>>>> > with JDK6 in the class path. It seems like some versions >>>>> of javac6 >>>>> > produced constructors for inner classes with no >>>>> arguments. This is not >>>>> > expected by newer versions of javac and it was producing >>>>> a NPE. This >>>>> > fix aims at making sure that >>>>> ClassReader::adjustMethodParams wont >>>>> > return a null even if the list of arguments passed to it >>>>> is empty. >>>>> > >>>>> > TIA, >>>>> > Vicente >>>>> > >>>>> > [1] https://bugs.openjdk.java.net/browse/JDK-8207160 >>>>> > [2] >>>>> http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Thu Sep 13 13:27:41 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 13 Sep 2018 10:27:41 -0300 Subject: RFR - JDK-8210674 - Need to add examples for use of javac properties introduced by Raw String Literals In-Reply-To: <901106c4-0aea-558b-db61-0a2cac7f330a@oracle.com> References: <6E3B39AC-7BA3-4D0E-A007-866809259529@oracle.com> <901106c4-0aea-558b-db61-0a2cac7f330a@oracle.com> Message-ID: <5592B9EA-B3EF-4084-AF6A-6D594C9332D1@oracle.com> As per suggestions, I have reduced to // key: compiler.err.unicode.backtick // key: compiler.misc.feature.raw.string.literals // key: compiler.warn.preview.feature.use.plural // options: --enable-preview -source 12 -Xlint:preview class RawStringLiteral { String m() { return `abc` + \u0060`def`; } } Which will reduce to two messages once out of preview. > On Sep 12, 2018, at 6:53 PM, Jonathan Gibbons wrote: > > In general, it would be bad style to have one example serving multiple diagnostics, since that often implies that the example is not as simple as it could be for any one message. > > This example is borderline, because some of the messages will go away if and when Raw String Literals gets promoted from being a preview feature to an official feature. > > -- Jon > > On 9/12/18 2:45 PM, Vicente Romero wrote: >> Hi Jim, >> >> Looks good but as a suggestion you can fold both examples into one, >> >> Thanks, >> Vicente >> >> On 09/12/2018 05:01 PM, Jim Laskey wrote: >>> Please review the following misstep; >>> >>> webrev: http://cr.openjdk.java.net/~jlaskey/8210674/webrev/index.html >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8210674 >>> >>> Cheers, >>> >>> ? Jim >>> >>> >> > From vicente.romero at oracle.com Thu Sep 13 16:18:26 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 13 Sep 2018 12:18:26 -0400 Subject: RFR JDK-8183548: Comma-expressions shouldn't use any temporary variable In-Reply-To: References: Message-ID: looks good to me, Vicente On 09/12/2018 05:49 PM, B. Blaser wrote: > On Wed, 12 Sep 2018 at 21:28, B. Blaser wrote: >> Hi, >> >> Please review the following straightforward fix for [1] to avoid using >> any temporary variable in comma expressions. >> It makes use of the recently (as part of [2]) enhanced 'LetExpr' to >> allow more than one statement. >> >> Any feedback is welcome (langtools:tier1 is OK), >> Bernard >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8183548 >> [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012197.html > Webrev: http://cr.openjdk.java.net/~bsrbnd/jdk8183548/webrev.00/ > > Thanks, > Bernard From bsrbnd at gmail.com Thu Sep 13 17:55:01 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 13 Sep 2018 19:55:01 +0200 Subject: RFR JDK-8183548: Comma-expressions shouldn't use any temporary variable In-Reply-To: References: Message-ID: Thanks Vicente, I'll push it soon... Bernard On Thu, 13 Sep 2018 at 18:18, Vicente Romero wrote: > > looks good to me, > > Vicente > > On 09/12/2018 05:49 PM, B. Blaser wrote: > > On Wed, 12 Sep 2018 at 21:28, B. Blaser wrote: > >> Hi, > >> > >> Please review the following straightforward fix for [1] to avoid using > >> any temporary variable in comma expressions. > >> It makes use of the recently (as part of [2]) enhanced 'LetExpr' to > >> allow more than one statement. > >> > >> Any feedback is welcome (langtools:tier1 is OK), > >> Bernard > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8183548 > >> [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012197.html > > Webrev: http://cr.openjdk.java.net/~bsrbnd/jdk8183548/webrev.00/ > > > > Thanks, > > Bernard > From mandy.chung at oracle.com Thu Sep 13 22:25:44 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 13 Sep 2018 15:25:44 -0700 Subject: RFR: JDK-8210731 PropertiesParser does not produce reproducible output In-Reply-To: <28385672-2843-9499-debd-fd7dc70e3f7c@oracle.com> References: <28385672-2843-9499-debd-fd7dc70e3f7c@oracle.com> Message-ID: <4d9ed0b0-770d-2d5f-2629-03d5661690fa@oracle.com> Looks okay to me. Mandy P.S. I cc'ed compiler-dev since I think you meant to cc compiler-dev instead of hotspot-compiler-dev. On 9/13/18 3:20 PM, Magnus Ihse Bursie wrote: > The file make/langtools/tools/propertiesparser/PropertiesParser.java > b/make/langtools/tools/propertiesparser/PropertiesParser.java is used > to convert .properties files into .java files as part of the gensrc step. > > However, due to it's use of creating it's output directly from > HashMaps, it's not guaranteed to be stable, and is causing spurios > differences in our cmp-baseline builds. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210731 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8210731-properties-parser-is-not-stable/webrev.01 > > /Magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Sep 13 22:25:54 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Sep 2018 15:25:54 -0700 Subject: RFR: JDK-8210731 PropertiesParser does not produce reproducible output In-Reply-To: <4d9ed0b0-770d-2d5f-2629-03d5661690fa@oracle.com> References: <28385672-2843-9499-debd-fd7dc70e3f7c@oracle.com> <4d9ed0b0-770d-2d5f-2629-03d5661690fa@oracle.com> Message-ID: <5B9AE3F2.4020404@oracle.com> +1 -- Jon On 09/13/2018 03:25 PM, mandy chung wrote: > Looks okay to me. > > Mandy > P.S. I cc'ed compiler-dev since I think you meant to cc compiler-dev > instead of hotspot-compiler-dev. > > On 9/13/18 3:20 PM, Magnus Ihse Bursie wrote: >> The file make/langtools/tools/propertiesparser/PropertiesParser.java >> b/make/langtools/tools/propertiesparser/PropertiesParser.java is used >> to convert .properties files into .java files as part of the gensrc >> step. >> >> However, due to it's use of creating it's output directly from >> HashMaps, it's not guaranteed to be stable, and is causing spurios >> differences in our cmp-baseline builds. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210731 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8210731-properties-parser-is-not-stable/webrev.01 >> >> /Magnus >> > From cushon at google.com Thu Sep 13 22:38:15 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 13 Sep 2018 15:38:15 -0700 Subject: RFR: 8193037 package-info annotations are not reported when annotation processing is enabled In-Reply-To: References: Message-ID: Hello, Please consider this fix for JDK-8193037. Currently JavacProcessingEnvironment incorrectly resets package-infos corresponding to all package in the compilation (even if the package-info was loaded from the classpath), rather than only resetting package-infos that are being compiled from source as part of that compilation. The fix uses the isPkgInfo helper already defined in JavacProcessingEnvironment. webrev: http://cr.openjdk.java.net/~cushon/8193037/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8193037 On Thu, Jan 25, 2018 at 10:27 AM Liam Miller-Cushon wrote: > Friendly ping. > > On Mon, Jan 8, 2018 at 11:42 AM, Liam Miller-Cushon > wrote: > >> Is anyone interested in sponsoring this patch? >> >> On Tue, Dec 5, 2017 at 5:49 PM, Liam Miller-Cushon >> wrote: >> >>> Hello, >>> >>> Please review the following fix for JDK-8193037. >>> >>> javac should only reset package-info symbols between annotation >>> processing rounds if >>> the package-info is being compiled from source. Previously package-infos >>> loaded from >>> the classpath were reset and not reinitialized, leading to package >>> annotations being >>> unavailable during later annotation processing rounds. >>> >>> I included an additional test case to ensure that package-infos are >>> still reset when >>> necessary. Related discussion: >>> >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-December/011398.html >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8193037 >>> webrev: http://cr.openjdk.java.net/~cushon/8193037/webrev.00/ >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Sep 13 22:49:05 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Sep 2018 15:49:05 -0700 Subject: RFR: 8193037 package-info annotations are not reported when annotation processing is enabled In-Reply-To: References: Message-ID: Looks OK to me. -- Jon On 9/13/18 3:38 PM, Liam Miller-Cushon wrote: > Hello, > > Please consider this fix for JDK-8193037. Currently > JavacProcessingEnvironment incorrectly resets package-infos > corresponding to all package in the compilation (even if the > package-info was loaded from the classpath), rather than only > resetting package-infos that are being compiled from source as part of > that compilation. > > The fix uses the isPkgInfo helper already defined in > JavacProcessingEnvironment. > > webrev: http://cr.openjdk.java.net/~cushon/8193037/webrev.01/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8193037 > > On Thu, Jan 25, 2018 at 10:27 AM Liam Miller-Cushon > wrote: > > Friendly ping. > > On Mon, Jan 8, 2018 at 11:42 AM, Liam Miller-Cushon > > wrote: > > Is anyone interested in sponsoring this patch? > > On Tue, Dec 5, 2017 at 5:49 PM, Liam Miller-Cushon > > wrote: > > Hello, > > Please review the following fix for?JDK-8193037. > > javac should only reset package-info symbols between > annotation processing rounds if > the package-info is being compiled from source. Previously > package-infos loaded from > the classpath were reset and not reinitialized, leading to > package annotations being > unavailable during later annotation processing rounds. > > I included an additional test case to ensure that > package-infos are still reset when > necessary. Related discussion: > http://mail.openjdk.java.net/pipermail/compiler-dev/2017-December/011398.html > > bug: https://bugs.openjdk.java.net/browse/JDK-8193037 > webrev: > http://cr.openjdk.java.net/~cushon/8193037/webrev.00/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Fri Sep 14 01:07:49 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Sep 2018 20:07:49 -0500 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: Message-ID: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> I am running a review of VM-level work on bootstrap methods which can optionally help simplify some of these APIs: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html Specifically, this work can be use to implement a "symbolic expression mode" for BSMs which causes the JVM to unpack constant pool nodes directly as ConstantDesc items to present to BSMs. This might simplify the condy forms of ConstantDesc instances, if javac stores native constants to reflect, rather than lists of strings to reassemble. ? John On Sep 11, 2018, at 12:50 PM, Vicente Romero wrote: > > Please review the first iteration of the implementation for JEP-334 [1] JVM Constants API. The implementation can be found at [2]. JEP-334 introduces an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool and has already been the subject of several discussions. The implementation of this JEP has been publicly accessible throw the amber repo at [3] in the jep-334 branch. Thanks to all members of the Amber project and specially to Brian for all the hard work on the design and the implementation of this API. Thanks for all the feedback we have received so far, most of it has been integrated in the current implementation. > > Thanks, > Vicente > > [1] http://openjdk.java.net/jeps/334 > [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch > [3] http://hg.openjdk.java.net/amber/amber From cushon at google.com Fri Sep 14 03:42:47 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 13 Sep 2018 20:42:47 -0700 Subject: RFR: 8193037 package-info annotations are not reported when annotation processing is enabled In-Reply-To: References: Message-ID: Thanks for the review! On Thu, Sep 13, 2018 at 3:49 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Looks OK to me. > > -- Jon > > On 9/13/18 3:38 PM, Liam Miller-Cushon wrote: > > Hello, > > Please consider this fix for JDK-8193037. Currently > JavacProcessingEnvironment incorrectly resets package-infos corresponding > to all package in the compilation (even if the package-info was loaded from > the classpath), rather than only resetting package-infos that are being > compiled from source as part of that compilation. > > The fix uses the isPkgInfo helper already defined in > JavacProcessingEnvironment. > > webrev: http://cr.openjdk.java.net/~cushon/8193037/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8193037 > > On Thu, Jan 25, 2018 at 10:27 AM Liam Miller-Cushon > wrote: > >> Friendly ping. >> >> On Mon, Jan 8, 2018 at 11:42 AM, Liam Miller-Cushon >> wrote: >> >>> Is anyone interested in sponsoring this patch? >>> >>> On Tue, Dec 5, 2017 at 5:49 PM, Liam Miller-Cushon >>> wrote: >>> >>>> Hello, >>>> >>>> Please review the following fix for JDK-8193037. >>>> >>>> javac should only reset package-info symbols between annotation >>>> processing rounds if >>>> the package-info is being compiled from source. Previously >>>> package-infos loaded from >>>> the classpath were reset and not reinitialized, leading to package >>>> annotations being >>>> unavailable during later annotation processing rounds. >>>> >>>> I included an additional test case to ensure that package-infos are >>>> still reset when >>>> necessary. Related discussion: >>>> >>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-December/011398.html >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8193037 >>>> webrev: http://cr.openjdk.java.net/~cushon/8193037/webrev.00/ >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlists at juma.me.uk Fri Sep 14 05:05:23 2018 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 13 Sep 2018 22:05:23 -0700 Subject: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource Message-ID: Hi all, JDK-8194978 introduced some changes to the bytecode generated by javac for the try with resource construct. In the following code, it seems to generate a null check on a reference after invoking a method on it: public static void readFileAsString(String path) throws IOException { try (FileChannel fc = FileChannel.open(Paths.get(path))) { fc.size(); } } In line 16 to 22 of the bytecode, it looks like we check for null after calling a method on the fc reference: 16: aload_1 17: invokevirtual #6 // Method java/nio/channels/FileChannel.size:()J 20: pop2 21: aload_1 22: ifnull 52 25: aload_1 26: invokevirtual #7 // Method java/nio/channels/FileChannel.close:()V Is this intentional? I ask because this pattern triggers a spotBugs warning since it often implies a bug in user's code: RCN | Nullcheck of fc at line 10 of value previously dereferenced in TryTest.readFileAsString(String, Charset) Note that this works fine in Java versions older than Java 11. Since this spotBugs warning is generally useful, it would be handy if javac did not trigger it. Alternatively, if there's a good way to detect the code that was generated by javac, spotBugs could be updated to ignore it. For reference, this was discussed in the spotBugs issue tracker: https://github.com/spotbugs/spotbugs/issues/756 And method bytecode in full: public static void readFileAsString(java.lang.String) throws java.io.IOException; Code: 0: aload_0 1: iconst_0 2: anewarray #2 // class java/lang/String 5: invokestatic #3 // Method java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; 8: iconst_0 9: anewarray #4 // class java/nio/file/OpenOption 12: invokestatic #5 // Method java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel; 15: astore_1 16: aload_1 17: invokevirtual #6 // Method java/nio/channels/FileChannel.size:()J 20: pop2 21: aload_1 22: ifnull 52 25: aload_1 26: invokevirtual #7 // Method java/nio/channels/FileChannel.close:()V 29: goto 52 32: astore_2 33: aload_1 34: ifnull 50 37: aload_1 38: invokevirtual #7 // Method java/nio/channels/FileChannel.close:()V 41: goto 50 44: astore_3 45: aload_2 46: aload_3 47: invokevirtual #9 // Method java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V 50: aload_2 51: athrow 52: return Exception table: from to target type 16 21 32 Class java/lang/Throwable 37 41 44 Class java/lang/Throwable Thanks, Ismael -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Fri Sep 14 07:33:55 2018 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Sep 2018 09:33:55 +0200 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> Message-ID: <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> Hi Jaikiran, Forwarding to compiler-dev as the core of source file launcher feature is produced there... The check for main class is performed after compilation (which actually produces the main class name). I think it would be possible to check for all classes compiled from the source file after compilation without to much complication. The compilation produces classes and stores them into a Map. The keySet() of that map is a Set of compiled class names. Each of them could be tested via .getResource() invoked upon the application class loader. The error could even point to the URL of the conflicting class file that way... Regards, Peter On 09/14/2018 07:36 AM, Jaikiran Pai wrote: > Please consider this trivial code C.java: > > public class C { > ?? ?public static void main(String[] args) throws Exception { > ?? ??? ?System.out.println("main() execution started"); > ?? ?} > } > > >> ls > C.java > > Similar to a previous discussion[1] while doing random testing, I ended > up compiling C.java explicitly using javac: > >> javac C.java >> ls > C.java C.class > > and then at a later date tried to use the source file launcher feature > of Java 11 (without realizing C.class was already present in the dir): > >> java C.java > This threw the error: > > error: class found on application class path: C > > Although the error isn't that clear for the reason I note in [2], having > run into this before, I was aware what this meant and deleted the > C.class and moved on. The important part here is that the source > launcher noticed this condition and aborted even before it auto > compiled(?) and launched and executed the main() of the program. > > Now consider a slight modification to that source file: > > public class C { > ??? public static void main(String[] args) throws Exception { > ??? ??? System.out.println("main() execution started"); > ??? ??? final B b = new B(); > ??? ??? System.out.println("Done"); > ??? } > > ??? private static class B { > > ??? } > } > > Again at some point I compiled this explicitly using javac, so my > directory is (among other things): > >> ls > C$B.class??? C.class??? ??? C.java > > Then ran the source file launcher feature: > >> java C.java > error: class found on application class path: C > > As expected, ran into the same previous error. As before, in order to > move on, deleted C.class: > >> rm C.class > but forgot to delete the nested static class that belonged to it. So the > directory now contained: > >> ls > C$B.class??? C.java > > Now used the source launcher feature again: > >> java C.java > This time it failed with: > > main() execution started > Exception in thread "main" java.lang.IllegalAccessError: failed to > access class C$B from class C (C$B is in unnamed module of loader 'app'; > C is in unnamed module of loader > com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab) > ??? at C.main(C.java:4) > > The error message isn't clear to pinpoint the issue, but at least the > reference to MemoryClassLoader was a hint that was enough for me to > understand where to look. It did take me a few minutes to realize that > C$B.class was lying around which I needed to remove too. > > However, IMO, the important part here is that unlike in the first case > where the program itself wasn't launched and instead was aborted early, > in this case the program did get executed (notice the System.out.println > "main() execution started" message that got printed) and failed at runtime. > > Would it be possible to make these two behaviours consistent and detect > such cases and abort early here too? Or would that add too much > complexity to this feature? > > Finally, any thoughts on the error messages for this feature to make it > a bit easier in terms of debugging (classloading) issues like these? > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html > > -Jaikiran > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Sep 14 11:33:25 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 14 Sep 2018 13:33:25 +0200 Subject: RFR: JDK-8193561: Cyclic hierarchy causes a NullPointerException when setting DEFAULT flag Message-ID: <5B9B9C85.5060909@oracle.com> Hi, Consider code like: --- package p; interface T8193561 extends p.T8193561.I { interface I extends T8193561 { default boolean m() { return false; } } default boolean m() { return false; } } --- There is apparently a cycle between the interfaces, and an error will be reported correctly for it, but then it will crash in MemberEnter: --- $ javac -XDdev T8193561.java T8193561.java:9: error: cyclic inheritance involving T8193561 interface T8193561 extends p.T8193561.I { ^ 1 error An exception has occurred in the compiler (12-internal). 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 and the following diagnostic in your report. Thank you. java.lang.NullPointerException at jdk.compiler/com.sun.tools.javac.comp.MemberEnter.visitMethodDef(MemberEnter.java:186) [snip] --- (Note the -XDdev - as there is an error already reported, the exception would normally be hidden, but the crash is still observable in certain cases, e.g. in tests.) The offending line is: m.enclClass().flags_field |= DEFAULT; The issue here, IMO, is that when the cycle is detected, the class/interface is marked as erroneous, and m.enclClass() won't return erroneous owner (will return null instead). Seems that using "m.owner" instead of "m.enclClass()" should be sufficient at this place? Proposed patch: http://cr.openjdk.java.net/~jlahoda/8193561/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8193561 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Fri Sep 14 14:08:26 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 14 Sep 2018 15:08:26 +0100 Subject: RFR: JDK-8193561: Cyclic hierarchy causes a NullPointerException when setting DEFAULT flag In-Reply-To: <5B9B9C85.5060909@oracle.com> References: <5B9B9C85.5060909@oracle.com> Message-ID: <601528e5-a643-87d2-9dfa-dfae9f3e4abd@oracle.com> Looks good - owner and enclClass() should have identical effects in this case (e.g. go one level up to the method owner). Maurizio On 14/09/18 12:33, Jan Lahoda wrote: > Hi, > > Consider code like: > --- > package p; > > interface T8193561 extends p.T8193561.I { > > ??? interface I? extends T8193561 { > ??????? default boolean m() { > ??????????? return false; > ??????? } > ??? } > > ??? default boolean m() { > ??????? return false; > ??? } > > } > --- > > There is apparently a cycle between the interfaces, and an error will > be reported correctly for it, but then it will crash in MemberEnter: > --- > $ javac -XDdev T8193561.java > T8193561.java:9: error: cyclic inheritance involving T8193561 > interface T8193561 extends p.T8193561.I { > ^ > 1 error > An exception has occurred in the compiler (12-internal). 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 and the > following diagnostic in your report. Thank you. > java.lang.NullPointerException > ??????? at > jdk.compiler/com.sun.tools.javac.comp.MemberEnter.visitMethodDef(MemberEnter.java:186) > [snip] > --- > > (Note the -XDdev - as there is an error already reported, the > exception would normally be hidden, but the crash is still observable > in certain cases, e.g. in tests.) > > The offending line is: > ??????????? m.enclClass().flags_field |= DEFAULT; > > The issue here, IMO, is that when the cycle is detected, the > class/interface is marked as erroneous, and m.enclClass() won't return > erroneous owner (will return null instead). Seems that using "m.owner" > instead of "m.enclClass()" should be sufficient at this place? > > Proposed patch: http://cr.openjdk.java.net/~jlahoda/8193561/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8193561 > > How does this look? > > Thanks, > ??? Jan From seth.lytle at gmail.com Fri Sep 14 17:14:52 2018 From: seth.lytle at gmail.com (seth lytle) Date: Fri, 14 Sep 2018 13:14:52 -0400 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> Message-ID: this behavior of throwing an error if the class is found twice on the classpath strikes me as unusual - afaik, in all other cases, java is fine with finding multiple implementations on the classpath and uses the first found (similar to the unix path, which also allows overriding by providing an explicit path) and this is really one of the powerful features of java - allowing you to swap out one class for another seamlessly. and for rapid prototyping, "java -cp target/classes:$cp src/myPackage/Stuff.java" runs much faster than "mvn package -Dexec.mainClass=myPackage.Stuff", and doubly so for mvnDebug On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart wrote: > Hi Jaikiran, > > Forwarding to compiler-dev as the core of source file launcher feature is > produced there... > > The check for main class is performed after compilation (which actually > produces the main class name). > > I think it would be possible to check for all classes compiled from the > source file after compilation without to much complication. The compilation > produces classes and stores them into a Map. The keySet() > of that map is a Set of compiled class names. Each of them could be tested > via .getResource() invoked upon the application class loader. The error > could even point to the URL of the conflicting class file that way... > > Regards, Peter > > > On 09/14/2018 07:36 AM, Jaikiran Pai wrote: > > Please consider this trivial code C.java: > > public class C { > public static void main(String[] args) throws Exception { > System.out.println("main() execution started"); > } > } > > > > ls > > C.java > > Similar to a previous discussion[1] while doing random testing, I ended > up compiling C.java explicitly using javac: > > > javac C.java > ls > > C.java C.class > > and then at a later date tried to use the source file launcher feature > of Java 11 (without realizing C.class was already present in the dir): > > > java C.java > > This threw the error: > > error: class found on application class path: C > > Although the error isn't that clear for the reason I note in [2], having > run into this before, I was aware what this meant and deleted the > C.class and moved on. The important part here is that the source > launcher noticed this condition and aborted even before it auto > compiled(?) and launched and executed the main() of the program. > > Now consider a slight modification to that source file: > > public class C { > public static void main(String[] args) throws Exception { > System.out.println("main() execution started"); > final B b = new B(); > System.out.println("Done"); > } > > private static class B { > > } > } > > Again at some point I compiled this explicitly using javac, so my > directory is (among other things): > > > ls > > C$B.class C.class C.java > > Then ran the source file launcher feature: > > > java C.java > > error: class found on application class path: C > > As expected, ran into the same previous error. As before, in order to > move on, deleted C.class: > > > rm C.class > > but forgot to delete the nested static class that belonged to it. So the > directory now contained: > > > ls > > C$B.class C.java > > Now used the source launcher feature again: > > > java C.java > > This time it failed with: > > main() execution started > Exception in thread "main" java.lang.IllegalAccessError: failed to > access class C$B from class C (C$B is in unnamed module of loader 'app'; > C is in unnamed module of loader > com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab) > at C.main(C.java:4) > > The error message isn't clear to pinpoint the issue, but at least the > reference to MemoryClassLoader was a hint that was enough for me to > understand where to look. It did take me a few minutes to realize that > C$B.class was lying around which I needed to remove too. > > However, IMO, the important part here is that unlike in the first case > where the program itself wasn't launched and instead was aborted early, > in this case the program did get executed (notice the System.out.println > "main() execution started" message that got printed) and failed at runtime. > > Would it be possible to make these two behaviours consistent and detect > such cases and abort early here too? Or would that add too much > complexity to this feature? > > Finally, any thoughts on the error messages for this feature to make it > a bit easier in terms of debugging (classloading) issues like these? > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html > > -Jaikiran > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Sep 14 17:49:24 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 14 Sep 2018 10:49:24 -0700 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> Message-ID: <5B9BF4A4.5040605@oracle.com> Seth, The reason for reporting an error is to prevent the "wrong" class being used! -- Jon On 09/14/2018 10:14 AM, seth lytle wrote: > this behavior of throwing an error if the class is found twice on the > classpath strikes me as unusual - afaik, in all other cases, java is fine > with finding multiple implementations on the classpath and uses the first > found (similar to the unix path, which also allows overriding by providing > an explicit path) and this is really one of the powerful features of java - > allowing you to swap out one class for another seamlessly. and for rapid > prototyping, "java -cp target/classes:$cp src/myPackage/Stuff.java" runs > much faster than "mvn package -Dexec.mainClass=myPackage.Stuff", and doubly > so for mvnDebug > > > > > > > > > > > On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart > wrote: > >> Hi Jaikiran, >> >> Forwarding to compiler-dev as the core of source file launcher feature is >> produced there... >> >> The check for main class is performed after compilation (which actually >> produces the main class name). >> >> I think it would be possible to check for all classes compiled from the >> source file after compilation without to much complication. The compilation >> produces classes and stores them into a Map. The keySet() >> of that map is a Set of compiled class names. Each of them could be tested >> via .getResource() invoked upon the application class loader. The error >> could even point to the URL of the conflicting class file that way... >> >> Regards, Peter >> >> >> On 09/14/2018 07:36 AM, Jaikiran Pai wrote: >> >> Please consider this trivial code C.java: >> >> public class C { >> public static void main(String[] args) throws Exception { >> System.out.println("main() execution started"); >> } >> } >> >> >> >> ls >> >> C.java >> >> Similar to a previous discussion[1] while doing random testing, I ended >> up compiling C.java explicitly using javac: >> >> >> javac C.java >> ls >> >> C.java C.class >> >> and then at a later date tried to use the source file launcher feature >> of Java 11 (without realizing C.class was already present in the dir): >> >> >> java C.java >> >> This threw the error: >> >> error: class found on application class path: C >> >> Although the error isn't that clear for the reason I note in [2], having >> run into this before, I was aware what this meant and deleted the >> C.class and moved on. The important part here is that the source >> launcher noticed this condition and aborted even before it auto >> compiled(?) and launched and executed the main() of the program. >> >> Now consider a slight modification to that source file: >> >> public class C { >> public static void main(String[] args) throws Exception { >> System.out.println("main() execution started"); >> final B b = new B(); >> System.out.println("Done"); >> } >> >> private static class B { >> >> } >> } >> >> Again at some point I compiled this explicitly using javac, so my >> directory is (among other things): >> >> >> ls >> >> C$B.class C.class C.java >> >> Then ran the source file launcher feature: >> >> >> java C.java >> >> error: class found on application class path: C >> >> As expected, ran into the same previous error. As before, in order to >> move on, deleted C.class: >> >> >> rm C.class >> >> but forgot to delete the nested static class that belonged to it. So the >> directory now contained: >> >> >> ls >> >> C$B.class C.java >> >> Now used the source launcher feature again: >> >> >> java C.java >> >> This time it failed with: >> >> main() execution started >> Exception in thread "main" java.lang.IllegalAccessError: failed to >> access class C$B from class C (C$B is in unnamed module of loader 'app'; >> C is in unnamed module of loader >> com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab) >> at C.main(C.java:4) >> >> The error message isn't clear to pinpoint the issue, but at least the >> reference to MemoryClassLoader was a hint that was enough for me to >> understand where to look. It did take me a few minutes to realize that >> C$B.class was lying around which I needed to remove too. >> >> However, IMO, the important part here is that unlike in the first case >> where the program itself wasn't launched and instead was aborted early, >> in this case the program did get executed (notice the System.out.println >> "main() execution started" message that got printed) and failed at runtime. >> >> Would it be possible to make these two behaviours consistent and detect >> such cases and abort early here too? Or would that add too much >> complexity to this feature? >> >> Finally, any thoughts on the error messages for this feature to make it >> a bit easier in terms of debugging (classloading) issues like these? >> >> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html >> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html >> >> -Jaikiran >> >> >> >> From seth.lytle at gmail.com Fri Sep 14 22:00:00 2018 From: seth.lytle at gmail.com (seth lytle) Date: Fri, 14 Sep 2018 18:00:00 -0400 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: <5B9BF4A4.5040605@oracle.com> References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> <5B9BF4A4.5040605@oracle.com> Message-ID: ah - compiler semantics vs launcher semantics, and the source code launcher lives in both worlds javac refuses to compile two sources for the same class javac will compile a source file for a class that exists on the classpath (and even overwrite a class on the classpath) java accepts two class files for the same class on the classpath (favors the first) java -jar accepts a jar containing classes that also exist on the classpath (favors the jar) java refuses to launch a source file for a class that exists on the classpath the source code launcher "feels" like an outlier to me, but it could certainly go either way and i guess the source code launcher is an outlier anyway, as it decouples the first toplevel class name from the file name On Fri, Sep 14, 2018 at 1:49 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Seth, > > The reason for reporting an error is to prevent the "wrong" class being > used! > > -- Jon > > > On 09/14/2018 10:14 AM, seth lytle wrote: > >> this behavior of throwing an error if the class is found twice on the >> classpath strikes me as unusual - afaik, in all other cases, java is fine >> with finding multiple implementations on the classpath and uses the first >> found (similar to the unix path, which also allows overriding by providing >> an explicit path) and this is really one of the powerful features of java >> - >> allowing you to swap out one class for another seamlessly. and for rapid >> prototyping, "java -cp target/classes:$cp src/myPackage/Stuff.java" runs >> much faster than "mvn package -Dexec.mainClass=myPackage.Stuff", and >> doubly >> so for mvnDebug >> >> >> >> >> >> >> >> >> >> >> On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart >> wrote: >> >> Hi Jaikiran, >>> >>> Forwarding to compiler-dev as the core of source file launcher feature is >>> produced there... >>> >>> The check for main class is performed after compilation (which actually >>> produces the main class name). >>> >>> I think it would be possible to check for all classes compiled from the >>> source file after compilation without to much complication. The >>> compilation >>> produces classes and stores them into a Map. The keySet() >>> of that map is a Set of compiled class names. Each of them could be >>> tested >>> via .getResource() invoked upon the application class loader. The error >>> could even point to the URL of the conflicting class file that way... >>> >>> Regards, Peter >>> >>> >>> On 09/14/2018 07:36 AM, Jaikiran Pai wrote: >>> >>> Please consider this trivial code C.java: >>> >>> public class C { >>> public static void main(String[] args) throws Exception { >>> System.out.println("main() execution started"); >>> } >>> } >>> >>> >>> >>> ls >>> >>> C.java >>> >>> Similar to a previous discussion[1] while doing random testing, I ended >>> up compiling C.java explicitly using javac: >>> >>> >>> javac C.java >>> ls >>> >>> C.java C.class >>> >>> and then at a later date tried to use the source file launcher feature >>> of Java 11 (without realizing C.class was already present in the dir): >>> >>> >>> java C.java >>> >>> This threw the error: >>> >>> error: class found on application class path: C >>> >>> Although the error isn't that clear for the reason I note in [2], having >>> run into this before, I was aware what this meant and deleted the >>> C.class and moved on. The important part here is that the source >>> launcher noticed this condition and aborted even before it auto >>> compiled(?) and launched and executed the main() of the program. >>> >>> Now consider a slight modification to that source file: >>> >>> public class C { >>> public static void main(String[] args) throws Exception { >>> System.out.println("main() execution started"); >>> final B b = new B(); >>> System.out.println("Done"); >>> } >>> >>> private static class B { >>> >>> } >>> } >>> >>> Again at some point I compiled this explicitly using javac, so my >>> directory is (among other things): >>> >>> >>> ls >>> >>> C$B.class C.class C.java >>> >>> Then ran the source file launcher feature: >>> >>> >>> java C.java >>> >>> error: class found on application class path: C >>> >>> As expected, ran into the same previous error. As before, in order to >>> move on, deleted C.class: >>> >>> >>> rm C.class >>> >>> but forgot to delete the nested static class that belonged to it. So the >>> directory now contained: >>> >>> >>> ls >>> >>> C$B.class C.java >>> >>> Now used the source launcher feature again: >>> >>> >>> java C.java >>> >>> This time it failed with: >>> >>> main() execution started >>> Exception in thread "main" java.lang.IllegalAccessError: failed to >>> access class C$B from class C (C$B is in unnamed module of loader 'app'; >>> C is in unnamed module of loader >>> com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab) >>> at C.main(C.java:4) >>> >>> The error message isn't clear to pinpoint the issue, but at least the >>> reference to MemoryClassLoader was a hint that was enough for me to >>> understand where to look. It did take me a few minutes to realize that >>> C$B.class was lying around which I needed to remove too. >>> >>> However, IMO, the important part here is that unlike in the first case >>> where the program itself wasn't launched and instead was aborted early, >>> in this case the program did get executed (notice the System.out.println >>> "main() execution started" message that got printed) and failed at >>> runtime. >>> >>> Would it be possible to make these two behaviours consistent and detect >>> such cases and abort early here too? Or would that add too much >>> complexity to this feature? >>> >>> Finally, any thoughts on the error messages for this feature to make it >>> a bit easier in terms of debugging (classloading) issues like these? >>> >>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html >>> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html >>> >>> -Jaikiran >>> >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Sep 14 22:09:03 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 14 Sep 2018 15:09:03 -0700 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> <5B9BF4A4.5040605@oracle.com> Message-ID: <4070f498-b1ec-1eb8-6b4b-501c406f8b3e@oracle.com> Seth, this is not so much "compiler semantics" vs "launcher semantics" ... it's just "ClassLoader semantics", combined with the fact that an empty class path defaults to the current directory. In the source launcher, the compiler is not worried about the classes in the current directory. But the classes are executed in a class loader, in which the normal semantics[1] are to check the parent class loader first, before checking for a local definition. Using those normal semantics, any classes on the application class path (defaulting to the current directory) are found before those defined to the class loader. That's the problem that is being encountered here. -- Jon [1]https://docs.oracle.com/javase/10/docs/api/java/lang/ClassLoader.html#loadClass(java.lang.String,boolean) On 9/14/18 3:00 PM, seth lytle wrote: > ah - compiler semantics vs launcher semantics, and the source code > launcher lives in both worlds > > javac refuses to compile two sources for the same class > javac will compile a source file for a class that exists on the > classpath (and even overwrite a class on the classpath) > java accepts two class files for the same class on the classpath > (favors the first) > java -jar accepts a jar containing classes that also exist on the > classpath (favors the jar) > java refuses to launch a source file for a class that exists on the > classpath > > the source code launcher "feels" like an outlier to me, but it could > certainly go either way > > and i guess the source code launcher is an outlier anyway, as it > decouples the first toplevel class name from the file name > > > > > > > > > > > > > On Fri, Sep 14, 2018 at 1:49 PM, Jonathan Gibbons > > wrote: > > Seth, > > The reason for reporting an error is to prevent the "wrong" class > being used! > > -- Jon > > > On 09/14/2018 10:14 AM, seth lytle wrote: > > this behavior of throwing an error if the class is found twice > on the > classpath strikes me as unusual - afaik, in all other cases, > java is fine > with finding multiple implementations on the classpath and > uses the first > found (similar to the unix path, which also allows overriding > by providing > an explicit path) and this is really one of the powerful > features of java - > allowing you to swap out one class for another seamlessly. and > for rapid > prototyping, "java -cp target/classes:$cp > src/myPackage/Stuff.java" runs > much faster than "mvn package > -Dexec.mainClass=myPackage.Stuff", and doubly > so for mvnDebug > > > > > > > > > > > On Fri, Sep 14, 2018 at 3:33 AM, Peter Levart > > > wrote: > > Hi Jaikiran, > > Forwarding to compiler-dev as the core of source file > launcher feature is > produced there... > > The check for main class is performed after compilation > (which actually > produces the main class name). > > I think it would be possible to check for all classes > compiled from the > source file after compilation without to much > complication. The compilation > produces classes and stores them into a Map byte[]>. The keySet() > of that map is a Set of compiled class names. Each of them > could be tested > via .getResource() invoked upon the application class > loader. The error > could even point to the URL of the conflicting class file > that way... > > Regards, Peter > > > On 09/14/2018 07:36 AM, Jaikiran Pai wrote: > > Please consider this trivial code C.java: > > public class C { > ? ? ?public static void main(String[] args) throws Exception { > ? ? ? ? ?System.out.println("main() execution started"); > ? ? ?} > } > > > > ls > > C.java > > Similar to a previous discussion[1] while doing random > testing, I ended > up compiling C.java explicitly using javac: > > > javac C.java > ls > > C.java C.class > > and then at a later date tried to use the source file > launcher feature > of Java 11 (without realizing C.class was already present > in the dir): > > > java C.java > > This threw the error: > > error: class found on application class path: C > > Although the error isn't that clear for the reason I note > in [2], having > run into this before, I was aware what this meant and > deleted the > C.class and moved on. The important part here is that the > source > launcher noticed this condition and aborted even before it > auto > compiled(?) and launched and executed the main() of the > program. > > Now consider a slight modification to that source file: > > public class C { > ? ? ?public static void main(String[] args) throws Exception { > ? ? ? ? ?System.out.println("main() execution started"); > ? ? ? ? ?final B b = new B(); > ? ? ? ? ?System.out.println("Done"); > ? ? ?} > > ? ? ?private static class B { > > ? ? ?} > } > > Again at some point I compiled this explicitly using > javac, so my > directory is (among other things): > > > ls > > C$B.class? ? C.class? ? ? ? C.java > > Then ran the source file launcher feature: > > > java C.java > > error: class found on application class path: C > > As expected, ran into the same previous error. As before, > in order to > move on, deleted C.class: > > > rm C.class > > but forgot to delete the nested static class that belonged > to it. So the > directory now contained: > > > ls > > C$B.class? ? C.java > > Now used the source launcher feature again: > > > java C.java > > This time it failed with: > > main() execution started > Exception in thread "main" java.lang.IllegalAccessError: > failed to > access class C$B from class C (C$B is in unnamed module of > loader 'app'; > C is in unnamed module of loader > com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab) > ? ? ?at C.main(C.java:4) > > The error message isn't clear to pinpoint the issue, but > at least the > reference to MemoryClassLoader was a hint that was enough > for me to > understand where to look. It did take me a few minutes to > realize that > C$B.class was lying around which I needed to remove too. > > However, IMO, the important part here is that unlike in > the first case > where the program itself wasn't launched and instead was > aborted early, > in this case the program did get executed (notice the > System.out.println > "main() execution started" message that got printed) and > failed at runtime. > > Would it be possible to make these two behaviours > consistent and detect > such cases and abort early here too? Or would that add too > much > complexity to this feature? > > Finally, any thoughts on the error messages for this > feature to make it > a bit easier in terms of debugging (classloading) issues > like these? > > [1] > http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html > > [2] > http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html > > > -Jaikiran > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Sat Sep 15 02:50:57 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 15 Sep 2018 08:20:57 +0530 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> Message-ID: Hello Peter, On 14/09/18 1:03 PM, Peter Levart wrote: > > The check for main class is performed after compilation (which > actually produces the main class name). > > I think it would be possible to check for all classes compiled from > the source file after compilation without to much complication. The > compilation produces classes and stores them into a Map byte[]>. The keySet() of that map is a Set of compiled class names. > Each of them could be tested via .getResource() invoked upon the > application class loader. The error could even point to the URL of the > conflicting class file that way... > Thank you for moving this to the correct mailing list. Thanks for those details about how it's done and what can be done to improve this. Should I report this as an enhancement request at bugs.java.com? I don't have access to the OpenJDK JIRA for creating this request there. -Jaikiran From jonathan.gibbons at oracle.com Sat Sep 15 17:04:12 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 15 Sep 2018 10:04:12 -0700 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> Message-ID: <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com> Jaikiran, This issue is on our radar; there is no need for any additional action on your part at this point. -- Jon On 9/14/18 7:50 PM, Jaikiran Pai wrote: > Hello Peter, > > > On 14/09/18 1:03 PM, Peter Levart wrote: >> The check for main class is performed after compilation (which >> actually produces the main class name). >> >> I think it would be possible to check for all classes compiled from >> the source file after compilation without to much complication. The >> compilation produces classes and stores them into a Map> byte[]>. The keySet() of that map is a Set of compiled class names. >> Each of them could be tested via .getResource() invoked upon the >> application class loader. The error could even point to the URL of the >> conflicting class file that way... >> > Thank you for moving this to the correct mailing list. Thanks for those > details about how it's done and what can be done to improve this. Should > I report this as an enhancement request at bugs.java.com? I don't have > access to the OpenJDK JIRA for creating this request there. > > -Jaikiran From jai.forums2013 at gmail.com Sun Sep 16 02:31:21 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 16 Sep 2018 08:01:21 +0530 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com> References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com> Message-ID: Thank you Jon. -Jaikiran On 15/09/18 10:34 PM, Jonathan Gibbons wrote: > Jaikiran, > > This issue is on our radar; there is no need for any additional action > on your part at this point. > > -- Jon > > > On 9/14/18 7:50 PM, Jaikiran Pai wrote: >> Hello Peter, >> >> >> On 14/09/18 1:03 PM, Peter Levart wrote: >>> The check for main class is performed after compilation (which >>> actually produces the main class name). >>> >>> I think it would be possible to check for all classes compiled from >>> the source file after compilation without to much complication. The >>> compilation produces classes and stores them into a Map>> byte[]>. The keySet() of that map is a Set of compiled class names. >>> Each of them could be tested via .getResource() invoked upon the >>> application class loader. The error could even point to the URL of the >>> conflicting class file that way... >>> >> Thank you for moving this to the correct mailing list. Thanks for those >> details about how it's done and what can be done to improve this. Should >> I report this as an enhancement request at bugs.java.com? I don't have >> access to the OpenJDK JIRA for creating this request there. >> >> -Jaikiran > From martinrb at google.com Mon Sep 17 18:00:41 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 17 Sep 2018 11:00:41 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: I'm not a compiler engineer, but I am a Reviewer, and this change looks good to me. Here are things I might do differently: debugAnnotation, printElementValue I might name these toDebugString. I don't like methods named printXX that don't print. I might rename testEnclosingMethod to testTopLevelMethod and testInsideInnerClass to testInnerClassMethod for clarity. I might refactor code body annotation finding code into a method that returns a Set of Annotation + if (method.attributes.get(Attribute.RuntimeVisibleTypeAnnotations) != null) { + throw new AssertionError( + "expected no RuntimeVisibleTypeAnnotations attribute on enclosing method"); + } + Code_attribute code = (Code_attribute) method.attributes.get(Attribute.Code); + RuntimeVisibleTypeAnnotations_attribute rvta = + (RuntimeVisibleTypeAnnotations_attribute) + code.attributes.get(Attribute.RuntimeVisibleTypeAnnotations); On Tue, Sep 11, 2018 at 4:40 PM, Liam Miller-Cushon wrote: > On Fri, Jul 27, 2018 at 1:25 PM Werner Dietl wrote: >> >> Hi Liam, >> >> thanks, this looks very nice! Removing all this incorrect code is >> great. The examples I tried worked correctly. > > > Thanks Werner! > > I have rebased the patch, and confirmed the tests are still passing. Here's > the latest version: > > http://cr.openjdk.java.net/~cushon/8198945/webrev.05/ > > Is there any additional feedback on this change? From cushon at google.com Mon Sep 17 18:25:43 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 17 Sep 2018 11:25:43 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: On Mon, Sep 17, 2018 at 11:00 AM Martin Buchholz wrote: > I'm not a compiler engineer, but I am a Reviewer, and this change > looks good to me. > Thanks for the review! I made the suggested improvements to the test. Here's the updated webrev: http://cr.openjdk.java.net/~cushon/8198945/webrev.06/ Does anyone have additional feedback? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Sep 17 18:54:39 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 17 Sep 2018 11:54:39 -0700 Subject: RFF (12): JDK-8207954: Data for --release 11 In-Reply-To: <5B55BF9E.1090901@oracle.com> References: <5B55BF9E.1090901@oracle.com> Message-ID: <5B9FF86F.1070703@oracle.com> Jan, OK for the code changes. I still think it would be nice to see makefile support for generating these files, as compared to comments in source coe, but that can be handled separately. -- Jon On 07/23/2018 04:44 AM, Jan Lahoda wrote: > Hi, > > To support --release 11 in JDK 12, historical data for JDK 11 need to > be added. As new attributes (NestHost and NestMembers) have been added > to the classfile, there also needs to be some tweaking of the tool > that creates the historical descriptions and the ct.sym sigfiles. > > The proposed patch has two parts: > -code changes, which include: > --update to the build scripts and the tool, so that the tool can read > both the open and extra/closed description of the ct.sym content, and > merge those (there should not be any extra/closed for JDK 11, AFAIK, > so this is to avoid having to update the closed part). > --improving the description on how to add historical data for new > releases, using the new source launcher > --adding support for the new NestHost/NestMembers attributes > --adding a new test which strives to fail when a new attribute is > added and CreateSymbols is not updated > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ > > -addition of the historical data: > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ > (these may need to be re-generated when the final JDK 11 is released > in case there are any changes, but that should be very simple) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 > > Any feedback is welcome, > Jan From bsrbnd at gmail.com Tue Sep 18 13:41:49 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 18 Sep 2018 15:41:49 +0200 Subject: RFR JDK-8208470: Type annotations on inner type that is an array component Message-ID: Hi, Please review the following fix for [1]: http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/ We've seen in thread [2] that [3] has probably caused the regression. Among the variants we explored, Werner's one enhanced as discussed in [2] seems quite good to me. It has a small side-effect as the array element type would then carry the annotation which is revealed by test [4], but I'm of Werner's opinion that this would be correct. I've made other attempts [5] to avoid this side-effect but I'm not sure this is really the right approach. Any feedback is welcome (langtools:tier1 is OK), Bernard [1] https://bugs.openjdk.java.net/browse/JDK-8208470 [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012199.html [3] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83#l6.440 [4] http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/test/langtools/tools/javac/warnings/6747671/T6747671.out.frames.html [5] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012266.html From jan.lahoda at oracle.com Tue Sep 18 15:09:50 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 18 Sep 2018 17:09:50 +0200 Subject: RFF (12): JDK-8207954: Data for --release 11 In-Reply-To: <5B9FF86F.1070703@oracle.com> References: <5B55BF9E.1090901@oracle.com> <5B9FF86F.1070703@oracle.com> Message-ID: <5BA1153E.8040208@oracle.com> On 17.9.2018 20:54, Jonathan Gibbons wrote: > Jan, > > OK for the code changes. Thanks. > > I still think it would be nice to see makefile support for generating > these files, as compared > to comments in source coe, but that can be handled separately. Ok, I'll work on that. Thanks, Jan > > -- Jon > > On 07/23/2018 04:44 AM, Jan Lahoda wrote: >> Hi, >> >> To support --release 11 in JDK 12, historical data for JDK 11 need to >> be added. As new attributes (NestHost and NestMembers) have been added >> to the classfile, there also needs to be some tweaking of the tool >> that creates the historical descriptions and the ct.sym sigfiles. >> >> The proposed patch has two parts: >> -code changes, which include: >> --update to the build scripts and the tool, so that the tool can read >> both the open and extra/closed description of the ct.sym content, and >> merge those (there should not be any extra/closed for JDK 11, AFAIK, >> so this is to avoid having to update the closed part). >> --improving the description on how to add historical data for new >> releases, using the new source launcher >> --adding support for the new NestHost/NestMembers attributes >> --adding a new test which strives to fail when a new attribute is >> added and CreateSymbols is not updated >> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ >> >> -addition of the historical data: >> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ >> (these may need to be re-generated when the final JDK 11 is released >> in case there are any changes, but that should be very simple) >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 >> >> Any feedback is welcome, >> Jan > From jan.lahoda at oracle.com Wed Sep 19 15:54:12 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 19 Sep 2018 17:54:12 +0200 Subject: RFR: JDK-8209865: Incorrect 'multiple elements' notes with Elements#getTypeElement and --release & JDK-8209058: Cannot find annotation method 'value()' in type 'Profile+Annotation' Message-ID: <5BA27124.4000504@oracle.com> Hi, I'd like to ask for a review of two related --release related bugs: The first bug is: https://bugs.openjdk.java.net/browse/JDK-8209865 Incorrect 'multiple elements' notes with Elements#getTypeElement and --release The issue here is that Elements.getTypeElement("javax.annotation.processing.Generated") returns null. The cause is the structure of ct.sym: to share classfile used for --release 8 and --release 9, the --release 9 is implemented in a way that every module gets a plain directory with all classfiles (whether they belong to the given module or not) on its path, and when compiling, javac picks the correct packages/classes from this directory based on module exports. But for the "unbound" search using getTypeElement, all modules are searched, ignoring module exports, so the Generated class is found in multiple modules. The proposed patch drops this ct.sym structure, and creates a simple module-path-like structure for --release 9+ data: 9/java.base /java.compiler ... 9A/java.base /java.compiler ... The paths for a module M for --release N are all directories in the form ".*N.*/M". These contain only classes that belong to the given module. For --release <= 8, the original approach remains. As a consequence, there are no shared classfiles between JDK 8 and JDK 9 data, but the size increase seems acceptable compared to the much cleaner structure of ct.sym (originally about 6.2MB with JDK 11 data, about 7.9MB with this patch and JDK 11 data). JBS: https://bugs.openjdk.java.net/browse/JDK-8209865 Webrev: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.00/ The second bug is: https://bugs.openjdk.java.net/browse/JDK-8209058 Cannot find annotation method 'value()' in type 'Profile+Annotation' The problem is that compiling code like: --- import javax.annotation.processing.ProcessingEnvironment; public class NoProfileAnnotationWarning { void t(ProcessingEnvironment pe) { pe.getElementUtils().getTypeElement("a"); } } --- with --release 10 and -Xlint:all may lead to warnings like: --- /9A/java.compiler/javax/annotation/processing/ProcessingEnvironment.sig: warning: Cannot find annotation method 'value()' in type 'Profile+Annotation': class file for jdk.Profile+Annotation not found --- The reason is that ct.sym still uses the synthetic jdk/Profile+Annotation annotation to assign classes to profiles. While this is only relevant for --release 8, to maximize data/classfile reuse, the annotation is present also in classfiles for other versions, for both the 'make/data/symbols/*.sym.txt' files and in ct.sym. This causes problem for --release >= 9, as the synthetic annotation is not always properly removed from the symbols as it is read in ClassReader (as it is in a non-exported package). As, after the first patch above, there is no sharing between classfiles for <= 8 and >= 9 in ct.sym, the proposal is to simply remove this annotation for classfiles in ct.sym that are not used for --release 8. JBS: https://bugs.openjdk.java.net/browse/JDK-8209058 Webrev: http://cr.openjdk.java.net/~jlahoda/8209058/webrev.00/ How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Thu Sep 20 00:21:45 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 19 Sep 2018 17:21:45 -0700 Subject: RFR: JDK-8209865: Incorrect 'multiple elements' notes with Elements#getTypeElement and --release & JDK-8209058: Cannot find annotation method 'value()' in type 'Profile+Annotation' In-Reply-To: <5BA27124.4000504@oracle.com> References: <5BA27124.4000504@oracle.com> Message-ID: <5BA2E819.8060508@oracle.com> On 09/19/2018 08:54 AM, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of two related --release related bugs: > > The first bug is: > https://bugs.openjdk.java.net/browse/JDK-8209865 > > Incorrect 'multiple elements' notes with Elements#getTypeElement and > --release > > The issue here is that > Elements.getTypeElement("javax.annotation.processing.Generated") > returns null. The cause is the structure of ct.sym: to share classfile > used for --release 8 and --release 9, the --release 9 is implemented > in a way that every module gets a plain directory with all classfiles > (whether they belong to the given module or not) on its path, and when > compiling, javac picks the correct packages/classes from this > directory based on module exports. But for the "unbound" search using > getTypeElement, all modules are searched, ignoring module exports, so > the Generated class is found in multiple modules. > > The proposed patch drops this ct.sym structure, and creates a simple > module-path-like structure for --release 9+ data: > 9/java.base > /java.compiler > ... > > 9A/java.base > /java.compiler > ... > > The paths for a module M for --release N are all directories in the > form ".*N.*/M". These contain only classes that belong to the given > module. > > For --release <= 8, the original approach remains. As a consequence, > there are no shared classfiles between JDK 8 and JDK 9 data, but the > size increase seems acceptable compared to the much cleaner structure > of ct.sym (originally about 6.2MB with JDK 11 data, about 7.9MB with > this patch and JDK 11 data). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209865 > Webrev: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.00/ This email is just about the first of your two bugs. So, this works because the data files for the releases remain unchanged, and all you're doing here is changing the way those text files are "compiled" into ct.sym at build time, right, and subsequently read by JDKPlatformProvider at user-compile-time? Separately, we should really have an (internal) spec for the format of files like ct.cym. Yes, you're changing code, but it is surprising that there are no comments or any other documentation being updated along with the code changes to modify the format of the file. I understand that you want to move away from the old way of handling modules by introducing a new layer of module name. How hard would it be to share the data with versions <=8 by ignoring the enclosing module? -- Jon From jonathan.gibbons at oracle.com Thu Sep 20 00:28:15 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 19 Sep 2018 17:28:15 -0700 Subject: RFR: JDK-8209865: Incorrect 'multiple elements' notes with Elements#getTypeElement and --release & JDK-8209058: Cannot find annotation method 'value()' in type 'Profile+Annotation' In-Reply-To: <5BA27124.4000504@oracle.com> References: <5BA27124.4000504@oracle.com> Message-ID: <5BA2E99F.40100@oracle.com> On 09/19/2018 08:54 AM, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of two related --release related bugs: > > The second bug is: > https://bugs.openjdk.java.net/browse/JDK-8209058 > > Cannot find annotation method 'value()' in type 'Profile+Annotation' > > The problem is that compiling code like: > --- > import javax.annotation.processing.ProcessingEnvironment; > > public class NoProfileAnnotationWarning { > void t(ProcessingEnvironment pe) { > pe.getElementUtils().getTypeElement("a"); > } > } > --- > with --release 10 and -Xlint:all may lead to warnings like: > --- > /9A/java.compiler/javax/annotation/processing/ProcessingEnvironment.sig: > warning: Cannot find annotation method 'value()' in type > 'Profile+Annotation': class file for jdk.Profile+Annotation not found > --- > > The reason is that ct.sym still uses the synthetic > jdk/Profile+Annotation annotation to assign classes to profiles. While > this is only relevant for --release 8, to maximize data/classfile > reuse, the annotation is present also in classfiles for other > versions, for both the 'make/data/symbols/*.sym.txt' files and in > ct.sym. This causes problem for --release >= 9, as the synthetic > annotation is not always properly removed from the symbols as it is > read in ClassReader (as it is in a non-exported package). As, after > the first patch above, there is no sharing between classfiles for <= 8 > and >= 9 in ct.sym, the proposal is to simply remove this annotation > for classfiles in ct.sym that are not used for --release 8. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209058 > Webrev: http://cr.openjdk.java.net/~jlahoda/8209058/webrev.00/ > > How does this look? > > Thanks, > Jan This is about the second review. This looks OK, but is conditional on the first review, and whether it is worth trying to share between 8 and >=9 or not, so lets sort that one out. That being said, I realize this issue may help influence the first one. -- jon From vicente.romero at oracle.com Thu Sep 20 01:10:13 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 19 Sep 2018 21:10:13 -0400 Subject: RFR: JDK-8209022: Missing checkcast when casting to type parameter bounded by intersection type Message-ID: <8d6582a4-72d4-00e5-cf78-88e7d7fe090b@oracle.com> Please review fix for [1] at [2]. Javac was `forgetting` to coerce some expressions to the target type after erasure. Implying that there were missing checkcasts generated in the byte code. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8209022 [2]http://cr.openjdk.java.net/~vromero/8209022/webrev.00/jdk.dev.patch From maurizio.cimadamore at oracle.com Thu Sep 20 09:05:33 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 20 Sep 2018 10:05:33 +0100 Subject: RFR: JDK-8209022: Missing checkcast when casting to type parameter bounded by intersection type In-Reply-To: <8d6582a4-72d4-00e5-cf78-88e7d7fe090b@oracle.com> References: <8d6582a4-72d4-00e5-cf78-88e7d7fe090b@oracle.com> Message-ID: Looks good. The test could be simplified either by using TestNG (which supports assertions for exceptions), or by defining an helper function which takes a Runnable. Then you can pass it two method references ::f and ::g and the helper function could call them and check for exceptions. Maurizio On 20/09/18 02:10, Vicente Romero wrote: > Please review fix for [1] at [2]. Javac was `forgetting` to coerce > some expressions to the target type after erasure. Implying that there > were missing checkcasts generated in the byte code. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8209022 > [2]http://cr.openjdk.java.net/~vromero/8209022/webrev.00/jdk.dev.patch From maurizio.cimadamore at oracle.com Thu Sep 20 09:06:29 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 20 Sep 2018 10:06:29 +0100 Subject: RFR: JDK-8209022: Missing checkcast when casting to type parameter bounded by intersection type In-Reply-To: References: <8d6582a4-72d4-00e5-cf78-88e7d7fe090b@oracle.com> Message-ID: <70c01a08-8379-1c99-5240-1b1a41968d1f@oracle.com> Also copyright header in test seems stale (2013) Maurizio On 20/09/18 10:05, Maurizio Cimadamore wrote: > Looks good. > > The test could be simplified either by using TestNG (which supports > assertions for exceptions), or by defining an helper function which > takes a Runnable. Then you can pass it two method references ::f and > ::g and the helper function could call them and check for exceptions. > > Maurizio > > > On 20/09/18 02:10, Vicente Romero wrote: >> Please review fix for [1] at [2]. Javac was `forgetting` to coerce >> some expressions to the target type after erasure. Implying that >> there were missing checkcasts generated in the byte code. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209022 >> [2]http://cr.openjdk.java.net/~vromero/8209022/webrev.00/jdk.dev.patch > From jan.lahoda at oracle.com Thu Sep 20 14:35:01 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 20 Sep 2018 16:35:01 +0200 Subject: RFR: JDK-8209865: Incorrect 'multiple elements' notes with Elements#getTypeElement and --release & JDK-8209058: Cannot find annotation method 'value()' in type 'Profile+Annotation' In-Reply-To: <5BA2E819.8060508@oracle.com> References: <5BA27124.4000504@oracle.com> <5BA2E819.8060508@oracle.com> Message-ID: <5BA3B015.3060002@oracle.com> On 20.9.2018 02:21, Jonathan Gibbons wrote: > > > On 09/19/2018 08:54 AM, Jan Lahoda wrote: >> Hi, >> >> I'd like to ask for a review of two related --release related bugs: >> >> The first bug is: >> https://bugs.openjdk.java.net/browse/JDK-8209865 >> >> Incorrect 'multiple elements' notes with Elements#getTypeElement and >> --release >> >> The issue here is that >> Elements.getTypeElement("javax.annotation.processing.Generated") >> returns null. The cause is the structure of ct.sym: to share classfile >> used for --release 8 and --release 9, the --release 9 is implemented >> in a way that every module gets a plain directory with all classfiles >> (whether they belong to the given module or not) on its path, and when >> compiling, javac picks the correct packages/classes from this >> directory based on module exports. But for the "unbound" search using >> getTypeElement, all modules are searched, ignoring module exports, so >> the Generated class is found in multiple modules. >> >> The proposed patch drops this ct.sym structure, and creates a simple >> module-path-like structure for --release 9+ data: >> 9/java.base >> /java.compiler >> ... >> >> 9A/java.base >> /java.compiler >> ... >> >> The paths for a module M for --release N are all directories in the >> form ".*N.*/M". These contain only classes that belong to the given >> module. >> >> For --release <= 8, the original approach remains. As a consequence, >> there are no shared classfiles between JDK 8 and JDK 9 data, but the >> size increase seems acceptable compared to the much cleaner structure >> of ct.sym (originally about 6.2MB with JDK 11 data, about 7.9MB with >> this patch and JDK 11 data). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209865 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.00/ > > This email is just about the first of your two bugs. > > So, this works because the data files for the releases remain unchanged, > and all you're doing here is changing the way those text files are > "compiled" into ct.sym at build time, right, and subsequently read by > JDKPlatformProvider at user-compile-time? Yes. > > Separately, we should really have an (internal) spec for the format of > files like ct.cym. Yes, you're changing code, but it is surprising > that there are no comments or any other documentation being updated > along with the code changes to modify the format of the file. > > I understand that you want to move away from the old way of handling > modules by introducing a new layer of module name. How hard would it be > to share the data with versions <=8 by ignoring the enclosing module? Not that hard, a patch doing that is here: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.01/ A delta from webrev.00: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.delta.00.01/ And a patch fixing the second bug in a different way that does allow sharing the classfiles is here: http://cr.openjdk.java.net/~jlahoda/8209058/webrev.01/ The main drawback is that the bootclasspath for --release <= 8 will be longer (as it needs to include "879/java.base", "879/java.desktop", etc.) Thanks for the comments, Jan > > -- Jon From vicente.romero at oracle.com Thu Sep 20 15:34:13 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 20 Sep 2018 11:34:13 -0400 Subject: RFR: JDK-8209022: Missing checkcast when casting to type parameter bounded by intersection type In-Reply-To: References: <8d6582a4-72d4-00e5-cf78-88e7d7fe090b@oracle.com> Message-ID: Thanks for the review, I have updated the webrev: http://cr.openjdk.java.net/~vromero/8209022/webrev.01/jdk.dev.patch Thanks, Vicente On 09/20/2018 05:05 AM, Maurizio Cimadamore wrote: > Looks good. > > The test could be simplified either by using TestNG (which supports > assertions for exceptions), or by defining an helper function which > takes a Runnable. Then you can pass it two method references ::f and > ::g and the helper function could call them and check for exceptions. > > Maurizio > > > On 20/09/18 02:10, Vicente Romero wrote: >> Please review fix for [1] at [2]. Javac was `forgetting` to coerce >> some expressions to the target type after erasure. Implying that >> there were missing checkcasts generated in the byte code. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209022 >> [2]http://cr.openjdk.java.net/~vromero/8209022/webrev.00/jdk.dev.patch > From jonathan.gibbons at oracle.com Thu Sep 20 17:39:49 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Sep 2018 10:39:49 -0700 Subject: Source file launcher - Handling of pre-compiled classes of the source file In-Reply-To: <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com> References: <39979e5f-96c8-ebb3-ccef-f1d8bdb308e2@gmail.com> <1f2e07bc-ab37-e286-46e4-f88152262f04@gmail.com> <0e096a76-9ece-432f-ee99-d50bd8fbec8e@oracle.com> Message-ID: <5BA3DB65.4080909@oracle.com> This is tracked as JDK-8210839 https://bugs.openjdk.java.net/browse/JDK-8210839 -- Jon On 09/15/2018 10:04 AM, Jonathan Gibbons wrote: > Jaikiran, > > This issue is on our radar; there is no need for any additional action > on your part at this point. > > -- Jon > > > On 9/14/18 7:50 PM, Jaikiran Pai wrote: >> Hello Peter, >> >> >> On 14/09/18 1:03 PM, Peter Levart wrote: >>> The check for main class is performed after compilation (which >>> actually produces the main class name). >>> >>> I think it would be possible to check for all classes compiled from >>> the source file after compilation without to much complication. The >>> compilation produces classes and stores them into a Map>> byte[]>. The keySet() of that map is a Set of compiled class names. >>> Each of them could be tested via .getResource() invoked upon the >>> application class loader. The error could even point to the URL of the >>> conflicting class file that way... >>> >> Thank you for moving this to the correct mailing list. Thanks for those >> details about how it's done and what can be done to improve this. Should >> I report this as an enhancement request at bugs.java.com? I don't have >> access to the OpenJDK JIRA for creating this request there. >> >> -Jaikiran > From jonathan.gibbons at oracle.com Thu Sep 20 18:18:41 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Sep 2018 11:18:41 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath Message-ID: <5BA3E481.5080708@oracle.com> Please review a medium-small change to the source launcher, so that classes defined in the source file are used in preference to the same or similar classes on the classpath. There is no perfect solution here. Various solutions were considered. The decision was made in favor of least surprise for simple and relatively simple use, which is the original target for the feature. So, yes, it is possible to write some programs that can be run with the source launcher that do not behave the same as if they were compiled and run the "traditional" way, but such examples are generally beyond the intended use of the feature. The solution that is proposed is to modify the internal class loader so that the set of classes (or resources) defined in the source file are checked before checking the application class path. A side-effect of the change is that the obscure/annoying error message class found on application class path: {0} is no longer required. The changes to CLTest.java are white-space only. Email: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055437.html Email: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012427.html JBS: https://bugs.openjdk.java.net/browse/JDK-8210839 Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.00/index.html -- Jon From maurizio.cimadamore at oracle.com Thu Sep 20 20:00:10 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 20 Sep 2018 21:00:10 +0100 Subject: RFR: JDK-8209022: Missing checkcast when casting to type parameter bounded by intersection type In-Reply-To: References: <8d6582a4-72d4-00e5-cf78-88e7d7fe090b@oracle.com> Message-ID: Looks good Maurizio On 20/09/18 16:34, Vicente Romero wrote: > Thanks for the review, I have updated the webrev: > > http://cr.openjdk.java.net/~vromero/8209022/webrev.01/jdk.dev.patch > > Thanks, > Vicente > > On 09/20/2018 05:05 AM, Maurizio Cimadamore wrote: >> Looks good. >> >> The test could be simplified either by using TestNG (which supports >> assertions for exceptions), or by defining an helper function which >> takes a Runnable. Then you can pass it two method references ::f and >> ::g and the helper function could call them and check for exceptions. >> >> Maurizio >> >> >> On 20/09/18 02:10, Vicente Romero wrote: >>> Please review fix for [1] at [2]. Javac was `forgetting` to coerce >>> some expressions to the target type after erasure. Implying that >>> there were missing checkcasts generated in the byte code. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8209022 >>> [2]http://cr.openjdk.java.net/~vromero/8209022/webrev.00/jdk.dev.patch >> > From maurizio.cimadamore at oracle.com Thu Sep 20 20:05:49 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 20 Sep 2018 21:05:49 +0100 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <5BA3E481.5080708@oracle.com> References: <5BA3E481.5080708@oracle.com> Message-ID: Looks very neat. One test (CLTest) in the webrev has empty changesets, but the patch does show something - looks like only indentation has changed in there? Cheers Maurizio On 20/09/18 19:18, Jonathan Gibbons wrote: > Please review a medium-small change to the source launcher, so that > classes defined > in the source file are used in preference to the same or similar > classes on the classpath. > > There is no perfect solution here. Various solutions were considered. > The decision was > made in favor of least surprise for simple and relatively simple use, > which is the original > target for the feature.? So, yes, it is possible to write some > programs that can be run > with the source launcher that do not behave the same as if they were > compiled and run > the "traditional" way, but such examples are generally beyond the > intended use of the > feature. > > The solution that is proposed is to modify the internal class loader > so that the set of > classes (or resources) defined in the source file are checked before > checking the > application class path. > > A side-effect of the change is that the obscure/annoying error message > ??? class found on application class path: {0} > is no longer required. > > The changes to CLTest.java are white-space only. > > Email: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055437.html > Email: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012427.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210839 > Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.00/index.html > > -- Jon From jonathan.gibbons at oracle.com Thu Sep 20 20:10:09 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Sep 2018 13:10:09 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: References: <5BA3E481.5080708@oracle.com> Message-ID: Yes, as I noted in the initial message: > > The changes to CLTest.java are white-space only. It was fixing some indentation issues that had crept into the file. -- Jon On 9/20/18 1:05 PM, Maurizio Cimadamore wrote: > Looks very neat. One test (CLTest) in the webrev has empty changesets, > but the patch does show something - looks like only indentation has > changed in there? > > Cheers > Maurizio > > > On 20/09/18 19:18, Jonathan Gibbons wrote: >> Please review a medium-small change to the source launcher, so that >> classes defined >> in the source file are used in preference to the same or similar >> classes on the classpath. >> >> There is no perfect solution here. Various solutions were considered. >> The decision was >> made in favor of least surprise for simple and relatively simple use, >> which is the original >> target for the feature.? So, yes, it is possible to write some >> programs that can be run >> with the source launcher that do not behave the same as if they were >> compiled and run >> the "traditional" way, but such examples are generally beyond the >> intended use of the >> feature. >> >> The solution that is proposed is to modify the internal class loader >> so that the set of >> classes (or resources) defined in the source file are checked before >> checking the >> application class path. >> >> A side-effect of the change is that the obscure/annoying error message >> ??? class found on application class path: {0} >> is no longer required. >> >> The changes to CLTest.java are white-space only. >> >> Email: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055437.html >> Email: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012427.html >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210839 >> Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.00/index.html >> >> -- Jon > From jonathan.gibbons at oracle.com Thu Sep 20 20:29:53 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Sep 2018 13:29:53 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5B96D5F5.7010800@oracle.com> References: <5B96D5F5.7010800@oracle.com> Message-ID: <5BA40341.3020904@oracle.com> Please review a simplified solution to this issue. It turns out to be not reasonable to make the source launcher work as well as might be desired when a security manager is enabled, without addressing the bigger problem of making javac (i.e. the jdk.compiler module) work well with a security manager, and the related problems of handling callbacks from javac in such an environment. In addition, working with a security manager is arguably beyond the scope of the feature as described in JEP 330. The simplified solution proposed here is just to use a protection domain with a code source set to the source file when defining classes in the internal MemoryClassLoader. This at least gives advanced users the ability to set permissions for classes in the source file, if they also address or workaround the issues of permissions for the jdk.compiler module. JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.01/ -- Jon On 09/10/2018 01:37 PM, Jonathan Gibbons wrote: > Please review a patch to have the Source Launcher be able to work when > a security manager is enabled. > > There are 4 parts to the work: an update to the default policy file, > an update to the source launcher itself, updates to tests, and a > custom security manager to help with testing. > > 1. src/java.base/share/lib/security/default.policy > > Add reasonably fine-grain permissions to give javac the permissions it > needs to run when a security manager is enabled. These permissions > were determined by running all javac tests under with a special > security manager installed: more on that later. There is one anomalous > property which was detected, which is a property to control some > internal javac behavior. Arguably, it should eventually be renamed > with at least a "javac.*" prefix. > > 2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java > > Update the source launcher to use doPrivileged in a couple of places: > most notably around the main invocation of javac. Generally, it > continues to be the policy that command-line tools like javac, javadoc > do not use fine-grained doPrivileged blocks throughout the tool, and > this update does not change that. It is worth noting that when javac > is invoked from the Source Launcher, it does not support callbacks > like annotation processors, task listeners, and other plugin code, so > that eliminates any issues relating to using callbacks from code in a > doPrivileged block. > > 3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java > > This is a custom new security manager for manual testing purposes in > conjunction with jtreg, so that we can run a large subset of tests > under the influence of a security manager. . It is a design > characteristic of jtreg that almost all tests have their own distinct > codebase, and so it is impractical to use a modified policy file to > grant all necessary permissions to all necessary tests, so this > security manager installs a custom Policy object that grants > permissions to test code while deferring to the system policy for > everything else (and for javac in particular.) Using this security > manager, it is possible to run all the javac tests to detect with high > probability all the permissions that it requires. Using a custom > security manager to install a custom Policy object allows the feature > to be easily enabled on the jtreg command line. > > There is one workaround in this security manager: a bug was uncovered > such that the jdk.zipfs module needs permission to access the user.dir > system property. ( https://bugs.openjdk.java.net/browse/JDK-8210469 > ) A temporary workaround is used to get a clean test run. > > Note: this code is not directly used in any normal/automated test runs > for javac; nevertheless, it is deemed worthwhile to save the code for > use in similar situations in the future. > > 4. Minor updates to tests. > > Some new test cases are added to Source Launcher tests. > > Although most tests are not directly affected by the use of a security > manager, there are some exceptions. Some tests manipulate the security > manager and/or expect the security manager to be unset. These tests > are modified to "pass by default" if the runtime conditions are not > suitable (i.e. a security manager has been installed.) > > Although it is not a requirement to be able to run annotation > processing tests when a security manager is enabled (because that > condition cannot arise with the Source Launcher), most annotation > processing tests do run successfully. There were 3 exceptions, where > the test required more permissions than granted to javac in code being > called from javac. These permissions were to access test.* system > properties and the setIO runtime permission. Rather than grant > unnecessary properties to javac, it was enough to use doPrivileged in > a couple of places in the javac "toolbox" test library, and to > refactor those tests to better use toolbox. > > In conjunction with these changes,ignoring any tests on the > ProblemList, all javac tests pass, with and without a security manager > being present. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 > Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/ > > > -- Jon From jonathan.gibbons at oracle.com Thu Sep 20 23:57:41 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Sep 2018 16:57:41 -0700 Subject: RFR: JDK-8209865: Incorrect 'multiple elements' notes with Elements#getTypeElement and --release & JDK-8209058: Cannot find annotation method 'value()' in type 'Profile+Annotation' In-Reply-To: <5BA3B015.3060002@oracle.com> References: <5BA27124.4000504@oracle.com> <5BA2E819.8060508@oracle.com> <5BA3B015.3060002@oracle.com> Message-ID: <5BA433F5.4020706@oracle.com> 2 +1's inline. -- Jon On 09/20/2018 07:35 AM, Jan Lahoda wrote: > On 20.9.2018 02:21, Jonathan Gibbons wrote: >> >> >> On 09/19/2018 08:54 AM, Jan Lahoda wrote: >>> Hi, >>> >>> I'd like to ask for a review of two related --release related bugs: >>> >>> The first bug is: >>> https://bugs.openjdk.java.net/browse/JDK-8209865 >>> >>> Incorrect 'multiple elements' notes with Elements#getTypeElement and >>> --release >>> >>> The issue here is that >>> Elements.getTypeElement("javax.annotation.processing.Generated") >>> returns null. The cause is the structure of ct.sym: to share classfile >>> used for --release 8 and --release 9, the --release 9 is implemented >>> in a way that every module gets a plain directory with all classfiles >>> (whether they belong to the given module or not) on its path, and when >>> compiling, javac picks the correct packages/classes from this >>> directory based on module exports. But for the "unbound" search using >>> getTypeElement, all modules are searched, ignoring module exports, so >>> the Generated class is found in multiple modules. >>> >>> The proposed patch drops this ct.sym structure, and creates a simple >>> module-path-like structure for --release 9+ data: >>> 9/java.base >>> /java.compiler >>> ... >>> >>> 9A/java.base >>> /java.compiler >>> ... >>> >>> The paths for a module M for --release N are all directories in the >>> form ".*N.*/M". These contain only classes that belong to the given >>> module. >>> >>> For --release <= 8, the original approach remains. As a consequence, >>> there are no shared classfiles between JDK 8 and JDK 9 data, but the >>> size increase seems acceptable compared to the much cleaner structure >>> of ct.sym (originally about 6.2MB with JDK 11 data, about 7.9MB with >>> this patch and JDK 11 data). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209865 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.00/ >> >> This email is just about the first of your two bugs. >> >> So, this works because the data files for the releases remain unchanged, >> and all you're doing here is changing the way those text files are >> "compiled" into ct.sym at build time, right, and subsequently read by >> JDKPlatformProvider at user-compile-time? > > Yes. > >> >> Separately, we should really have an (internal) spec for the format of >> files like ct.cym. Yes, you're changing code, but it is surprising >> that there are no comments or any other documentation being updated >> along with the code changes to modify the format of the file. >> >> I understand that you want to move away from the old way of handling >> modules by introducing a new layer of module name. How hard would it be >> to share the data with versions <=8 by ignoring the enclosing module? > > Not that hard, a patch doing that is here: > http://cr.openjdk.java.net/~jlahoda/8209865/webrev.01/ > > A delta from webrev.00: > http://cr.openjdk.java.net/~jlahoda/8209865/webrev.delta.00.01/ +1 > > And a patch fixing the second bug in a different way that does allow > sharing the classfiles is here: > http://cr.openjdk.java.net/~jlahoda/8209058/webrev.01/ +1 > > The main drawback is that the bootclasspath for --release <= 8 will be > longer (as it needs to include "879/java.base", "879/java.desktop", etc.) I don't see that as a big drawback, since it is now conceptually the same across all versions. > > Thanks for the comments, > Jan -- Jon > >> >> -- Jon From jonathan.gibbons at oracle.com Fri Sep 21 00:01:15 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Sep 2018 17:01:15 -0700 Subject: RFR: JDK-8209865: Incorrect 'multiple elements' notes with Elements#getTypeElement and --release & JDK-8209058: Cannot find annotation method 'value()' in type 'Profile+Annotation' In-Reply-To: <5BA433F5.4020706@oracle.com> References: <5BA27124.4000504@oracle.com> <5BA2E819.8060508@oracle.com> <5BA3B015.3060002@oracle.com> <5BA433F5.4020706@oracle.com> Message-ID: <5BA434CB.3090301@oracle.com> Just checking ... the name of the webrev is "Code Review for jdk10", the workspace path ends in "/jdk10" and the patch is named "jdk10.patch". I presume that's leftovers, right, and that this is really for JDK 12? -- Jon On 09/20/2018 04:57 PM, Jonathan Gibbons wrote: > 2 +1's inline. > > -- Jon > > On 09/20/2018 07:35 AM, Jan Lahoda wrote: >> On 20.9.2018 02:21, Jonathan Gibbons wrote: >>> >>> >>> On 09/19/2018 08:54 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I'd like to ask for a review of two related --release related bugs: >>>> >>>> The first bug is: >>>> https://bugs.openjdk.java.net/browse/JDK-8209865 >>>> >>>> Incorrect 'multiple elements' notes with Elements#getTypeElement and >>>> --release >>>> >>>> The issue here is that >>>> Elements.getTypeElement("javax.annotation.processing.Generated") >>>> returns null. The cause is the structure of ct.sym: to share classfile >>>> used for --release 8 and --release 9, the --release 9 is implemented >>>> in a way that every module gets a plain directory with all classfiles >>>> (whether they belong to the given module or not) on its path, and when >>>> compiling, javac picks the correct packages/classes from this >>>> directory based on module exports. But for the "unbound" search using >>>> getTypeElement, all modules are searched, ignoring module exports, so >>>> the Generated class is found in multiple modules. >>>> >>>> The proposed patch drops this ct.sym structure, and creates a simple >>>> module-path-like structure for --release 9+ data: >>>> 9/java.base >>>> /java.compiler >>>> ... >>>> >>>> 9A/java.base >>>> /java.compiler >>>> ... >>>> >>>> The paths for a module M for --release N are all directories in the >>>> form ".*N.*/M". These contain only classes that belong to the given >>>> module. >>>> >>>> For --release <= 8, the original approach remains. As a consequence, >>>> there are no shared classfiles between JDK 8 and JDK 9 data, but the >>>> size increase seems acceptable compared to the much cleaner structure >>>> of ct.sym (originally about 6.2MB with JDK 11 data, about 7.9MB with >>>> this patch and JDK 11 data). >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209865 >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.00/ >>> >>> This email is just about the first of your two bugs. >>> >>> So, this works because the data files for the releases remain >>> unchanged, >>> and all you're doing here is changing the way those text files are >>> "compiled" into ct.sym at build time, right, and subsequently read by >>> JDKPlatformProvider at user-compile-time? >> >> Yes. >> >>> >>> Separately, we should really have an (internal) spec for the format of >>> files like ct.cym. Yes, you're changing code, but it is surprising >>> that there are no comments or any other documentation being updated >>> along with the code changes to modify the format of the file. >>> >>> I understand that you want to move away from the old way of handling >>> modules by introducing a new layer of module name. How hard would >>> it be >>> to share the data with versions <=8 by ignoring the enclosing module? >> >> Not that hard, a patch doing that is here: >> http://cr.openjdk.java.net/~jlahoda/8209865/webrev.01/ >> >> A delta from webrev.00: >> http://cr.openjdk.java.net/~jlahoda/8209865/webrev.delta.00.01/ > > +1 > >> >> And a patch fixing the second bug in a different way that does allow >> sharing the classfiles is here: >> http://cr.openjdk.java.net/~jlahoda/8209058/webrev.01/ > > +1 > >> >> The main drawback is that the bootclasspath for --release <= 8 will >> be longer (as it needs to include "879/java.base", >> "879/java.desktop", etc.) > > I don't see that as a big drawback, since it is now conceptually the > same across all versions. > >> >> Thanks for the comments, >> Jan > > -- Jon > > >> >>> >>> -- Jon > From Alan.Bateman at oracle.com Fri Sep 21 07:34:47 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Sep 2018 08:34:47 +0100 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <5BA3E481.5080708@oracle.com> References: <5BA3E481.5080708@oracle.com> Message-ID: On 20/09/2018 19:18, Jonathan Gibbons wrote: > : > > A side-effect of the change is that the obscure/annoying error message > ??? class found on application class path: {0} > is no longer required. > > The changes to CLTest.java are white-space only. > > Email: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055437.html > Email: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012427.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210839 > Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.00/index.html Changing to local-first before delegating seems right here. For loadClass then I would expect it to synchronize on getClassLoaderLock(name) and check the loaded class cache with findLoadedClases(name) before calling findClass. There is a related discussion on whether this class loader should be parallel capable but that isn't important right thing. The getResourceXXX look rights except the check at L616 which I assume will never match as the parent cannot return a URL that locates the resource in memory. In addition, it's not wrong for a resource to be located by the parent at the same location (it would be strange but has always been possible). -Alan. From jan.lahoda at oracle.com Fri Sep 21 10:39:04 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 21 Sep 2018 12:39:04 +0200 Subject: RFR: JDK-8209865: Incorrect 'multiple elements' notes with Elements#getTypeElement and --release & JDK-8209058: Cannot find annotation method 'value()' in type 'Profile+Annotation' In-Reply-To: <5BA434CB.3090301@oracle.com> References: <5BA27124.4000504@oracle.com> <5BA2E819.8060508@oracle.com> <5BA3B015.3060002@oracle.com> <5BA433F5.4020706@oracle.com> <5BA434CB.3090301@oracle.com> Message-ID: <5BA4CA48.4080208@oracle.com> On 21.9.2018 02:01, Jonathan Gibbons wrote: > Just checking ... the name of the webrev is "Code Review for jdk10", the > workspace path ends in "/jdk10" > and the patch is named "jdk10.patch". I presume that's leftovers, right, > and that this is really for JDK 12? Yes, it is for JDK 12, I only still have the checkout inside directory named "jdk10". Sorry for the confusion. Thanks for the reviews! Jan > > -- Jon > > On 09/20/2018 04:57 PM, Jonathan Gibbons wrote: >> 2 +1's inline. >> >> -- Jon >> >> On 09/20/2018 07:35 AM, Jan Lahoda wrote: >>> On 20.9.2018 02:21, Jonathan Gibbons wrote: >>>> >>>> >>>> On 09/19/2018 08:54 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I'd like to ask for a review of two related --release related bugs: >>>>> >>>>> The first bug is: >>>>> https://bugs.openjdk.java.net/browse/JDK-8209865 >>>>> >>>>> Incorrect 'multiple elements' notes with Elements#getTypeElement and >>>>> --release >>>>> >>>>> The issue here is that >>>>> Elements.getTypeElement("javax.annotation.processing.Generated") >>>>> returns null. The cause is the structure of ct.sym: to share classfile >>>>> used for --release 8 and --release 9, the --release 9 is implemented >>>>> in a way that every module gets a plain directory with all classfiles >>>>> (whether they belong to the given module or not) on its path, and when >>>>> compiling, javac picks the correct packages/classes from this >>>>> directory based on module exports. But for the "unbound" search using >>>>> getTypeElement, all modules are searched, ignoring module exports, so >>>>> the Generated class is found in multiple modules. >>>>> >>>>> The proposed patch drops this ct.sym structure, and creates a simple >>>>> module-path-like structure for --release 9+ data: >>>>> 9/java.base >>>>> /java.compiler >>>>> ... >>>>> >>>>> 9A/java.base >>>>> /java.compiler >>>>> ... >>>>> >>>>> The paths for a module M for --release N are all directories in the >>>>> form ".*N.*/M". These contain only classes that belong to the given >>>>> module. >>>>> >>>>> For --release <= 8, the original approach remains. As a consequence, >>>>> there are no shared classfiles between JDK 8 and JDK 9 data, but the >>>>> size increase seems acceptable compared to the much cleaner structure >>>>> of ct.sym (originally about 6.2MB with JDK 11 data, about 7.9MB with >>>>> this patch and JDK 11 data). >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209865 >>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8209865/webrev.00/ >>>> >>>> This email is just about the first of your two bugs. >>>> >>>> So, this works because the data files for the releases remain >>>> unchanged, >>>> and all you're doing here is changing the way those text files are >>>> "compiled" into ct.sym at build time, right, and subsequently read by >>>> JDKPlatformProvider at user-compile-time? >>> >>> Yes. >>> >>>> >>>> Separately, we should really have an (internal) spec for the format of >>>> files like ct.cym. Yes, you're changing code, but it is surprising >>>> that there are no comments or any other documentation being updated >>>> along with the code changes to modify the format of the file. >>>> >>>> I understand that you want to move away from the old way of handling >>>> modules by introducing a new layer of module name. How hard would >>>> it be >>>> to share the data with versions <=8 by ignoring the enclosing module? >>> >>> Not that hard, a patch doing that is here: >>> http://cr.openjdk.java.net/~jlahoda/8209865/webrev.01/ >>> >>> A delta from webrev.00: >>> http://cr.openjdk.java.net/~jlahoda/8209865/webrev.delta.00.01/ >> >> +1 >> >>> >>> And a patch fixing the second bug in a different way that does allow >>> sharing the classfiles is here: >>> http://cr.openjdk.java.net/~jlahoda/8209058/webrev.01/ >> >> +1 >> >>> >>> The main drawback is that the bootclasspath for --release <= 8 will >>> be longer (as it needs to include "879/java.base", >>> "879/java.desktop", etc.) >> >> I don't see that as a big drawback, since it is now conceptually the >> same across all versions. >> >>> >>> Thanks for the comments, >>> Jan >> >> -- Jon >> >> >>> >>>> >>>> -- Jon >> > From jonathan.gibbons at oracle.com Fri Sep 21 17:15:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 21 Sep 2018 10:15:20 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: References: <5BA3E481.5080708@oracle.com> Message-ID: <5BA52728.90806@oracle.com> On 09/21/2018 12:34 AM, Alan Bateman wrote: > On 20/09/2018 19:18, Jonathan Gibbons wrote: >> : >> >> A side-effect of the change is that the obscure/annoying error message >> class found on application class path: {0} >> is no longer required. >> >> The changes to CLTest.java are white-space only. >> >> Email: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055437.html >> Email: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012427.html >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210839 >> Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.00/index.html > Changing to local-first before delegating seems right here. > > For loadClass then I would expect it to synchronize on > getClassLoaderLock(name) and check the loaded class cache with > findLoadedClases(name) before calling findClass. There is a related > discussion on whether this class loader should be parallel capable but > that isn't important right thing. > > The getResourceXXX look rights except the check at L616 which I assume > will never match as the parent cannot return a URL that locates the > resource in memory. In addition, it's not wrong for a resource to be > located by the parent at the same location (it would be strange but > has always been possible). The check at L616 is because super.getResources will do "the normal delegation thing" and will return an enumeration of the resources in the parent class loader followed by resources in the child class loader. Since we already have found the classes in the child class loader, we want to avoid the duplicate that will be found by super.getResources. > > -Alan. From Alan.Bateman at oracle.com Fri Sep 21 17:22:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Sep 2018 18:22:29 +0100 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <5BA52728.90806@oracle.com> References: <5BA3E481.5080708@oracle.com> <5BA52728.90806@oracle.com> Message-ID: <66347b8d-c357-8775-3809-a33952d73ec7@oracle.com> On 21/09/2018 18:15, Jonathan Gibbons wrote: > > The check at L616 is because super.getResources will do "the normal > delegation thing" and will return an enumeration of the resources in > the parent class loader followed by resources in the child class > loader. Since we already have found the classes in the child class > loader, we want to avoid the duplicate that will be found by > super.getResources. > Shouldn't that be parent.getResources() rather than super.getResources() ? -Alan From jonathan.gibbons at oracle.com Fri Sep 21 17:25:56 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 21 Sep 2018 10:25:56 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <66347b8d-c357-8775-3809-a33952d73ec7@oracle.com> References: <5BA3E481.5080708@oracle.com> <5BA52728.90806@oracle.com> <66347b8d-c357-8775-3809-a33952d73ec7@oracle.com> Message-ID: <5BA529A4.60800@oracle.com> On 09/21/2018 10:22 AM, Alan Bateman wrote: > On 21/09/2018 18:15, Jonathan Gibbons wrote: >> >> The check at L616 is because super.getResources will do "the normal >> delegation thing" and will return an enumeration of the resources in >> the parent class loader followed by resources in the child class >> loader. Since we already have found the classes in the child class >> loader, we want to avoid the duplicate that will be found by >> super.getResources. >> > Shouldn't that be parent.getResources() rather than > super.getResources() ? > > -Alan You're right; that would indeed be a simpler way ;-) -- Jon From jonathan.gibbons at oracle.com Fri Sep 21 17:53:10 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 21 Sep 2018 10:53:10 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <5BA3E481.5080708@oracle.com> References: <5BA3E481.5080708@oracle.com> Message-ID: <5BA53006.1070903@oracle.com> Updated webrev, incorporating review feedback. Webrev:_http://cr.openjdk.java.net/~jjg/8210839/webrev.01/index.html _ -- Jon On 09/20/2018 11:18 AM, Jonathan Gibbons wrote: > Please review a medium-small change to the source launcher, so that > classes defined > in the source file are used in preference to the same or similar > classes on the classpath. > > There is no perfect solution here. Various solutions were considered. > The decision was > made in favor of least surprise for simple and relatively simple use, > which is the original > target for the feature. So, yes, it is possible to write some > programs that can be run > with the source launcher that do not behave the same as if they were > compiled and run > the "traditional" way, but such examples are generally beyond the > intended use of the > feature. > > The solution that is proposed is to modify the internal class loader > so that the set of > classes (or resources) defined in the source file are checked before > checking the > application class path. > > A side-effect of the change is that the obscure/annoying error message > class found on application class path: {0} > is no longer required. > > The changes to CLTest.java are white-space only. > > Email: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055437.html > Email: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012427.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210839 > Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.00/index.html > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Sep 21 22:44:02 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 21 Sep 2018 15:44:02 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <5BA53006.1070903@oracle.com> References: <5BA3E481.5080708@oracle.com> <5BA53006.1070903@oracle.com> Message-ID: <7f0645c2-e6c5-2f03-802b-d1ddf565cad4@oracle.com> On 9/21/18 10:53 AM, Jonathan Gibbons wrote: > Updated webrev, incorporating review feedback. > > Webrev:_http://cr.openjdk.java.net/~jjg/8210839/webrev.01/index.html _ I agree that finding class locally first before delegating to the parent is a reasonable solution in particular with the simple use of this feature. This change looks good (changing to super.getResource(s) to getParent().getResource(s) is a good one). Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Sep 22 06:31:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Sep 2018 07:31:12 +0100 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <7f0645c2-e6c5-2f03-802b-d1ddf565cad4@oracle.com> References: <5BA3E481.5080708@oracle.com> <5BA53006.1070903@oracle.com> <7f0645c2-e6c5-2f03-802b-d1ddf565cad4@oracle.com> Message-ID: <6206dce3-8ff0-6e8a-a112-623f3abbcb3a@oracle.com> On 21/09/2018 23:44, mandy chung wrote: > On 9/21/18 10:53 AM, Jonathan Gibbons wrote: >> Updated webrev, incorporating review feedback. >> >> Webrev:_http://cr.openjdk.java.net/~jjg/8210839/webrev.01/index.html _ > > I agree that finding class locally first before delegating to the > parent is a reasonable solution in particular with the simple use of > this feature. > > This change looks good (changing to super.getResource(s) to > getParent().getResource(s) is a good one). I can't see the change just as cr.openjdk.java.net isn't back yet. However just to say that loadClass will need to do the same to avoid a delegation loop and stack overflow when a class is not found. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Sep 22 07:58:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Sep 2018 08:58:35 +0100 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <6206dce3-8ff0-6e8a-a112-623f3abbcb3a@oracle.com> References: <5BA3E481.5080708@oracle.com> <5BA53006.1070903@oracle.com> <7f0645c2-e6c5-2f03-802b-d1ddf565cad4@oracle.com> <6206dce3-8ff0-6e8a-a112-623f3abbcb3a@oracle.com> Message-ID: On 22/09/2018 07:31, Alan Bateman wrote: > On 21/09/2018 23:44, mandy chung wrote: >> On 9/21/18 10:53 AM, Jonathan Gibbons wrote: >>> Updated webrev, incorporating review feedback. >>> >>> Webrev:_http://cr.openjdk.java.net/~jjg/8210839/webrev.01/index.html _ >> >> I agree that finding class locally first before delegating to the >> parent is a reasonable solution in particular with the simple use of >> this feature. >> >> This change looks good (changing to super.getResource(s) to >> getParent().getResource(s) is a good one). > I can't see the change just as cr.openjdk.java.net isn't back yet. > However just to say that loadClass will need to do the same to avoid a > delegation loop and stack overflow when a class is not found. cr.ojn is back so I see the proposed patch. The new loadClass looks much better but it calls super.loadClass when it should be parent.loadClass. I also see that it delegates before checking if the class loader was recorded as an initiating loader. I think it needs to change to this: ??????????? synchronized (getClassLoadingLock(name)) { ??????????????? Class c = findLoadedClass(name); ??????????????? if (c == null) { ??????????????????? if (map.containsKey(name)) { ??????????????????????? c = findClass(name); ??????????????????? } else { ??????????????????????? c = parent.loadClass(name); ??????????????????? } ??????????????? } ??????????????? if (resolve) { ??????????????????? resolveClass(c); ??????????????? } ??????????????? return c; ??????????? } One suggestion for a test is Class.forName("MIA") to ensure that CNFE is reported. I think that provide better confident that you don't have a stack overflow. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sat Sep 22 16:59:34 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 22 Sep 2018 18:59:34 +0200 Subject: RFR JDK-8208470: Type annotations on inner type that is an array component In-Reply-To: References: Message-ID: Hi, I tried the initial example at processing and at runtime: $ cat ArrayOfInner.java ArrayOfInnerProc.java import java.lang.annotation.*; import java.lang.reflect.*; @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER}) @interface TA { int value(); } @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE}) @interface TB {} @TB class ArrayOfInner { @TB class Inner {} @TA(1) ArrayOfInner. @TA(2) Inner oi; @TA(3) ArrayOfInner. @TA(4) Inner [] oia; @TA(5) Inner i; @TA(6) Inner [] ia; public static void main(String... args) throws Exception { printField(ArrayOfInner.class.getDeclaredField("oi")); printArray(ArrayOfInner.class.getDeclaredField("oia")); printField(ArrayOfInner.class.getDeclaredField("i")); printArray(ArrayOfInner.class.getDeclaredField("ia")); } private static void printField(Field f) { AnnotatedType typeUse = f.getAnnotatedType(); System.out.println(f + ":"); for (Annotation a: typeUse.getAnnotations()) System.out.println(" " + a + " // type use"); if (typeUse.getAnnotatedOwnerType() != null) for (Annotation a: typeUse.getAnnotatedOwnerType().getAnnotations()) System.out.println(" " + a + " // outer type use"); for (Annotation a: f.getType().getAnnotations()) System.out.println(" " + a + " // declared type"); } private static void printArray(Field f) { AnnotatedArrayType array = (AnnotatedArrayType)f.getAnnotatedType(); AnnotatedType typeUse = array.getAnnotatedGenericComponentType(); System.out.println(f + ":"); for (Annotation a: typeUse.getAnnotations()) System.out.println(" " + a + " // type use"); if (typeUse.getAnnotatedOwnerType() != null) for (Annotation a: typeUse.getAnnotatedOwnerType().getAnnotations()) System.out.println(" " + a + " // outer type use"); for (Annotation a: f.getType().getComponentType().getAnnotations()) System.out.println(" " + a + " // declared type"); } } import java.util.*; import javax.annotation.processing.*; import javax.lang.model.*; import javax.lang.model.element.*; import javax.lang.model.type.*; @SupportedSourceVersion(SourceVersion.RELEASE_12) @SupportedAnnotationTypes({"*"}) public class ArrayOfInnerProc extends AbstractProcessor { @Override public boolean process(Set annotations, RoundEnvironment roundEnv) { for (Element c: roundEnv.getRootElements()) { if (!c.toString().equals("ArrayOfInner")) continue; for(Element f: ((TypeElement)c).getEnclosedElements()) { if (f.getKind() != ElementKind.FIELD) continue; System.out.println(f + ":"); TypeMirror t = f.asType(); if (t.getKind() == TypeKind.ARRAY) t = ((ArrayType)f.asType()).getComponentType(); for (AnnotationMirror a: t.getAnnotationMirrors()) System.out.println(" " + a + " // type use"); for (AnnotationMirror a: ((DeclaredType)t).getEnclosingType().getAnnotationMirrors()) System.out.println(" " + a + " // outer type use"); Element e = processingEnv.getTypeUtils().asElement(t); for (AnnotationMirror a: e.getAnnotationMirrors()) System.out.println(" " + a + " // declared type"); } } return false; } } Without fix, note the wrong location for @TA(3) at processing: $ javac ArrayOfInnerProc.java $ javac -processor ArrayOfInnerProc ArrayOfInner.java oi: @TA(2) // type use @TA(1) // outer type use @TB // declared type oia: @TA(3) // type use @TA(4) // type use @TB // declared type i: @TA(5) // type use @TB // declared type ia: @TA(6) // type use @TB // declared type And note the wrong location for @TA(6) at runtime: $ java ArrayOfInner ArrayOfInner$Inner ArrayOfInner.oi: @TA(value=2) // type use @TA(value=1) // outer type use @TB() // declared type ArrayOfInner$Inner[] ArrayOfInner.oia: @TA(value=4) // type use @TA(value=3) // outer type use @TB() // declared type ArrayOfInner$Inner ArrayOfInner.i: @TA(value=5) // type use @TB() // declared type ArrayOfInner$Inner[] ArrayOfInner.ia: @TA(value=6) // outer type use @TB() // declared type All seems to be fine with the fix: $ javac -processor ArrayOfInnerProc ArrayOfInner.java oi: @TA(2) // type use @TA(1) // outer type use @TB // declared type oia: @TA(4) // type use @TA(3) // outer type use @TB // declared type i: @TA(5) // type use @TB // declared type ia: @TA(6) // type use @TB // declared type $ java ArrayOfInner ArrayOfInner$Inner ArrayOfInner.oi: @TA(value=2) // type use @TA(value=1) // outer type use @TB() // declared type ArrayOfInner$Inner[] ArrayOfInner.oia: @TA(value=4) // type use @TA(value=3) // outer type use @TB() // declared type ArrayOfInner$Inner ArrayOfInner.i: @TA(value=5) // type use @TB() // declared type ArrayOfInner$Inner[] ArrayOfInner.ia: @TA(value=6) // type use @TB() // declared type Thoughts? Thanks, Bernard On Tue, 18 Sep 2018 at 15:41, B. Blaser wrote: > > Hi, > > Please review the following fix for [1]: > > http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/ > > We've seen in thread [2] that [3] has probably caused the regression. > Among the variants we explored, Werner's one enhanced as discussed in > [2] seems quite good to me. > It has a small side-effect as the array element type would then carry > the annotation which is revealed by test [4], but I'm of Werner's > opinion that this would be correct. > I've made other attempts [5] to avoid this side-effect but I'm not > sure this is really the right approach. > > Any feedback is welcome (langtools:tier1 is OK), > Bernard > > [1] https://bugs.openjdk.java.net/browse/JDK-8208470 > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012199.html > [3] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83#l6.440 > [4] http://cr.openjdk.java.net/~bsrbnd/jdk8208470/webrev.00/test/langtools/tools/javac/warnings/6747671/T6747671.out.frames.html > [5] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-July/012266.html From magnus.ihse.bursie at oracle.com Mon Sep 24 09:29:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Sep 2018 11:29:40 +0200 Subject: Help with JDK-8211057 Message-ID: <1106a62c-2cd1-ef0c-db4f-b38e23bd0a03@oracle.com> Hi compiler folks! Could anyone possibly help me with having a look at https://bugs.openjdk.java.net/browse/JDK-8211057? The CompileProperties build tool helper is not generating reproducible output, that is, if you run it multiple times one after another, with no source code changes, it will (sometimes) not generate identical output. This breaks our build tests for reproducibility. :-( I've fixed a handful of similar build tool issues the last year, and almost all of the cases ended up with someone iterating over a HashMap and just outputting elements in the order they happened to get them. However, this case seem different. I see no HashMap, and there is code that clearly intends to sort the output. My best guess here is that Properties.keySet() is backed by a HashMap, and that Collections.sort(sortedKeys) does not do what the author of the code intended, but that's just my guess. Since this is hard to reproduce (it's an highly intermittent failure, typically appearing mostly on Windows machines) I'd really appreciate some help by reasoning about the code. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Sep 24 12:42:26 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 24 Sep 2018 13:42:26 +0100 Subject: Help with JDK-8211057 In-Reply-To: <1106a62c-2cd1-ef0c-db4f-b38e23bd0a03@oracle.com> References: <1106a62c-2cd1-ef0c-db4f-b38e23bd0a03@oracle.com> Message-ID: <0ddc66f8-aee3-23d1-8335-da0bfdcb49cb@oracle.com> Hi Magnus, it's true that CompileProperties relies on Properties, which rely on Hashtable (not HashMap) which is likely NOT to have predictable iteration order (although I haven't been able to make it spit things in different orders on my Linux box). That said, it seems like the code keeps that into account: Properties p = new Properties(); try { ???? p.load(new FileInputStream(propertiesPath)); } ... List sortedKeys = new ArrayList(); for ( Object key : p.keySet() ) { ????? sortedKeys.add((String)key); } Collections.sort(sortedKeys); // <----- That is, there is always a sort step on the keys, which should guarantee some predictability of the output? So I think this is ok. But, looking at your JBS issue more in detail, I see that the problem you have is NOT with CompileProperties but with the PropertiesParser tool; this is a more complex tool. Eyeballing at it, I find one suspicious piece of code: http://hg.openjdk.java.net/jdk/jdk/file/354fb27fd38a/make/langtools/tools/propertiesparser/gen/ClassGenerator.java#l151 This is a complex stream call which ends up with a Collectors.groupingBy - and that method ends up collecting things into an HashMap. I suggest changing as follows: Map>> groupedEntries = ??????????????? messageFile.messages.entrySet().stream() ??????????????????????? .collect(Collectors.groupingBy(e -> FactoryKind.parseFrom(e.getKey().split("\\.")[1]), LinkedHashMap::new, Collectors.toList())); And see whether your problem is addressed? (seems so on my machine) Hope this helps Maurizio On 24/09/18 10:29, Magnus Ihse Bursie wrote: > Hi compiler folks! > > Could anyone possibly help me with having a look at > https://bugs.openjdk.java.net/browse/JDK-8211057? The > CompileProperties build tool helper is not generating reproducible > output, that is, if you run it multiple times one after another, with > no source code changes, it will (sometimes) not generate identical > output. This breaks our build tests for reproducibility. :-( > > I've fixed a handful of similar build tool issues the last year, and > almost all of the cases ended up with someone iterating over a HashMap > and just outputting elements in the order they happened to get them. > However, this case seem different. I see no HashMap, and there is code > that clearly intends to sort the output. > > My best guess here is that Properties.keySet() is backed by a HashMap, > and that Collections.sort(sortedKeys) does not do what the author of > the code intended, but that's just my guess. > > Since this is hard to reproduce (it's an highly intermittent failure, > typically appearing mostly on Windows machines) I'd really appreciate > some help by reasoning about the code. > > /Magnus From brent.n.douglas at gmail.com Mon Sep 24 14:49:26 2018 From: brent.n.douglas at gmail.com (Brent Douglas) Date: Mon, 24 Sep 2018 22:49:26 +0800 Subject: javac enum Flag has no entry for POTENTIALLY_AMBIGUOUS Message-ID: Hello all, I have been looking into a crash in error-prone which I think stems from the enum com.sun.tools.javac.code.Flags#Flag not having an entry for POTENTIALLY_AMBIGUOUS, while the assertion at the end of Flags#asFlagSet(long) makes me think it should. My apologies if this is the wrong list to bring this up on, if so could someone please point me the the right list? Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Sep 24 15:00:29 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 24 Sep 2018 16:00:29 +0100 Subject: javac enum Flag has no entry for POTENTIALLY_AMBIGUOUS In-Reply-To: References: Message-ID: I think you are right - given how the 'asFlagSet' is setup, any numeric constant that doesn't show up in the enum could cause a crash. Maurizio On 24/09/18 15:49, Brent Douglas wrote: > Hello all, > > I have been looking into a crash in error-prone which I think stems > from the enum com.sun.tools.javac.code.Flags#Flag not having an entry > for?POTENTIALLY_AMBIGUOUS, while the assertion at the end?of > Flags#asFlagSet(long) makes me think it should. > > My apologies if this is the wrong list to bring this up on, if so > could someone please point me the the right list? > > Brent From maurizio.cimadamore at oracle.com Mon Sep 24 15:28:09 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 24 Sep 2018 16:28:09 +0100 Subject: javac enum Flag has no entry for POTENTIALLY_AMBIGUOUS In-Reply-To: References: Message-ID: <47c8af07-c73c-8beb-492c-1a54843a3e20@oracle.com> For the records, with some scripting, the list of flags that are not covered is this: ACC_BRIDGE ACC_MODULE ACC_SUPER ACC_VARARGS ANONCONSTR_BASED BODY_ONLY_FINALIZE POTENTIALLY_AMBIGUOUS Now, ACC_BRIDGE, ACC_MODULE, ACC_SUPER, ACC_VARARGS, BODY_ONLY_FINALIZE are just aliases for other flags which are indeed covered. Which leaves out ANONCONSTR_BASED and POTENTIALLY_AMBIGUOUS, which should indeed be added to avoid spurious assertion failures. Maurizio On 24/09/18 16:00, Maurizio Cimadamore wrote: > I think you are right - given how the 'asFlagSet' is setup, any > numeric constant that doesn't show up in the enum could cause a crash. > > Maurizio > > > On 24/09/18 15:49, Brent Douglas wrote: >> Hello all, >> >> I have been looking into a crash in error-prone which I think stems >> from the enum com.sun.tools.javac.code.Flags#Flag not having an entry >> for?POTENTIALLY_AMBIGUOUS, while the assertion at the end?of >> Flags#asFlagSet(long) makes me think it should. >> >> My apologies if this is the wrong list to bring this up on, if so >> could someone please point me the the right list? >> >> Brent > From jonathan.gibbons at oracle.com Mon Sep 24 21:03:54 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Sep 2018 14:03:54 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: References: <5BA3E481.5080708@oracle.com> <5BA53006.1070903@oracle.com> <7f0645c2-e6c5-2f03-802b-d1ddf565cad4@oracle.com> <6206dce3-8ff0-6e8a-a112-623f3abbcb3a@oracle.com> Message-ID: <5BA9513A.5000208@oracle.com> On 09/22/2018 12:58 AM, Alan Bateman wrote: > On 22/09/2018 07:31, Alan Bateman wrote: >> On 21/09/2018 23:44, mandy chung wrote: >>> On 9/21/18 10:53 AM, Jonathan Gibbons wrote: >>>> Updated webrev, incorporating review feedback. >>>> >>>> Webrev:_http://cr.openjdk.java.net/~jjg/8210839/webrev.01/index.html _ >>> >>> I agree that finding class locally first before delegating to the >>> parent is a reasonable solution in particular with the simple use of >>> this feature. >>> >>> This change looks good (changing to super.getResource(s) to >>> getParent().getResource(s) is a good one). >> I can't see the change just as cr.openjdk.java.net isn't back yet. >> However just to say that loadClass will need to do the same to avoid >> a delegation loop and stack overflow when a class is not found. > cr.ojn is back so I see the proposed patch. The new loadClass looks > much better but it calls super.loadClass when it should be > parent.loadClass. I also see that it delegates before checking if the > class loader was recorded as an initiating loader. I think it needs to > change to this: > > synchronized (getClassLoadingLock(name)) { > Class c = findLoadedClass(name); > if (c == null) { > if (map.containsKey(name)) { > c = findClass(name); > } else { > c = parent.loadClass(name); > } > } > if (resolve) { > resolveClass(c); > } > return c; > } > > One suggestion for a test is Class.forName("MIA") to ensure that CNFE > is reported. I think that provide better confident that you don't have > a stack overflow. > > -Alan Alan, Mandy, Thanks for the additional feedback. New webrev: * addresses issues with loadClass * renames "map" to "sourceFileClasses" for added clarity * fixes/improves comments on MemoryClassLoader and contents * adds new test case as suggested Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.02/index.html -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Sep 24 21:47:50 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 24 Sep 2018 14:47:50 -0700 Subject: JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip for enum values() method Message-ID: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com> Hello, Since enum types were added in JDK 5, which shipped GA in 2004, the javadoc for the compiler-generated static values() method for enums has stated: > Returns an array containing the constants of this enum type, in the > order they are declared. This method may be used to iterate over the > constants as follows: > > for (RoundingMode c : RoundingMode.values()) > ??? System.out.println(c); While the tip to use the enhanced for loop to iterate over the constants of the enum type may have been reasonable to include in 2004, IMO it is unnecessary and clutter in 2018. Therefore, please review the changes for ??? JDK-8173730: Stop including enhanced for-loop tip for enum values() method ??? http://cr.openjdk.java.net/~darcy/8173730.0/ to remove the generation of the for loop tip. Patch below. Docs builds complete successfully and elides the tip as expected. Thanks, -Joe --- old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 2018-09-24 14:31:57.943000000 -0700 +++ new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties 2018-09-24 14:31:57.771000000 -0700 @@ -230,12 +230,7 @@ ?#Documentation for Enums ?doclet.enum_values_doc.fullbody=\ ? Returns an array containing the constants of this enum type, in\n\ - the order they are declared. This method may be used to iterate\n\ - over the constants as follows:\n\ - 
\n\
- for ({0} c : {0}.values())\n\
-  ?? System.out.println(c);\n\
-
+ the order they are declared. ?doclet.enum_values_doc.return=\ ?an array containing the constants of this enum type, in the order they are declared From bsrbnd at gmail.com Mon Sep 24 22:05:31 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 25 Sep 2018 00:05:31 +0200 Subject: Should @SupportedAnnotationTypes handle TYPE_USE? Message-ID: Hi, I noted that the annotation processor [1] isn't run if @SupportedAnnotationTypes ({"TA"}) is used instead of ({"*"}) because annotations on TYPE_USE don't seem to be handled when selecting processors. Is this normal or should we add something like below (to be completed)? The documentation [2] isn't clear about that. Thanks, Bernard [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012467.html [2] http://hg.openjdk.java.net/jdk/jdk/file/11b9d3a6f31c/src/java.compiler/share/classes/javax/annotation/processing/SupportedAnnotationTypes.java#l33 diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java @@ -954,9 +954,14 @@ return super.visitExecutable(e, p); } - void addAnnotations(Element e, Set p) { - for (AnnotationMirror annotationMirror : - elements.getAllAnnotationMirrors(e) ) { + @Override @DefinedBy(Api.LANGUAGE_MODEL) + public Set visitVariable(VariableElement e, Set p) { + new ComputeTypeAnnos().visit(e.asType(), p); + return super.visitVariable(e, p); + } + + void addAnnotations(java.util.List annos, Set p) { + for (AnnotationMirror annotationMirror : annos ) { Element e2 = annotationMirror.getAnnotationType().asElement(); p.add((TypeElement) e2); } @@ -964,9 +969,18 @@ @Override @DefinedBy(Api.LANGUAGE_MODEL) public Set scan(Element e, Set p) { - addAnnotations(e, p); + addAnnotations(elements.getAllAnnotationMirrors(e), p); return super.scan(e, p); } + + private class ComputeTypeAnnos extends SimpleTypeVisitor9> { + @Override @DefinedBy(Api.LANGUAGE_MODEL) + public Void visitDeclared(javax.lang.model.type.DeclaredType t, Set p) { + addAnnotations(t.getAnnotationMirrors(), p); + return super.visitDeclared(t, p); + } + // TODO ... + } } private boolean callProcessor(Processor proc, From jonathan.gibbons at oracle.com Mon Sep 24 22:15:07 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Sep 2018 15:15:07 -0700 Subject: JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip for enum values() method In-Reply-To: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com> References: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com> Message-ID: <5b4b0cdc-4da7-1426-f8b2-274a0db3df2a@oracle.com> This will require some thought, Joe, .... ... done. :-) Looks good to me. -- Jon On 9/24/18 2:47 PM, joe darcy wrote: > Hello, > > Since enum types were added in JDK 5, which shipped GA in 2004, the > javadoc for the compiler-generated static values() method for enums > has stated: > >> Returns an array containing the constants of this enum type, in the >> order they are declared. This method may be used to iterate over the >> constants as follows: >> >> for (RoundingMode c : RoundingMode.values()) >> ??? System.out.println(c); > > While the tip to use the enhanced for loop to iterate over the > constants of the enum type may have been reasonable to include in > 2004, IMO it is unnecessary and clutter in 2018. Therefore, please > review the changes for > > ??? JDK-8173730: Stop including enhanced for-loop tip for enum > values() method > ??? http://cr.openjdk.java.net/~darcy/8173730.0/ > > to remove the generation of the for loop tip. > > Patch below. > > Docs builds complete successfully and elides the tip as expected. > > Thanks, > > -Joe > > --- > old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > 2018-09-24 14:31:57.943000000 -0700 > +++ > new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > 2018-09-24 14:31:57.771000000 -0700 > @@ -230,12 +230,7 @@ > ?#Documentation for Enums > ?doclet.enum_values_doc.fullbody=\ > ? Returns an array containing the constants of this enum type, in\n\ > - the order they are declared. This method may be used to iterate\n\ > - over the constants as follows:\n\ > - 
\n\
> - for ({0} c : {0}.values())\n\
> -  ?? System.out.println(c);\n\
> -
> + the order they are declared. > > ?doclet.enum_values_doc.return=\ > ?an array containing the constants of this enum type, in the order > they are declared > From amaembo at gmail.com Tue Sep 25 00:06:57 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Tue, 25 Sep 2018 07:06:57 +0700 Subject: JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip for enum values() method In-Reply-To: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com> References: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com> Message-ID: Hello! Sorry for stupid question, but what is modern alternative to iterate over the enum values? With best regards, Tagir Valeev ??, 25 ????. 2018 ?., 4:48 joe darcy : > Hello, > > Since enum types were added in JDK 5, which shipped GA in 2004, the > javadoc for the compiler-generated static values() method for enums has > stated: > > > Returns an array containing the constants of this enum type, in the > > order they are declared. This method may be used to iterate over the > > constants as follows: > > > > for (RoundingMode c : RoundingMode.values()) > > System.out.println(c); > > While the tip to use the enhanced for loop to iterate over the constants > of the enum type may have been reasonable to include in 2004, IMO it is > unnecessary and clutter in 2018. Therefore, please review the changes for > > JDK-8173730: Stop including enhanced for-loop tip for enum values() > method > http://cr.openjdk.java.net/~darcy/8173730.0/ > > to remove the generation of the for loop tip. > > Patch below. > > Docs builds complete successfully and elides the tip as expected. > > Thanks, > > -Joe > > --- > old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > > 2018-09-24 14:31:57.943000000 -0700 > +++ > new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > > 2018-09-24 14:31:57.771000000 -0700 > @@ -230,12 +230,7 @@ > #Documentation for Enums > doclet.enum_values_doc.fullbody=\ > Returns an array containing the constants of this enum type, in\n\ > - the order they are declared. This method may be used to iterate\n\ > - over the constants as follows:\n\ > - 
\n\
> - for ({0} c : {0}.values())\n\
> -     System.out.println(c);\n\
> -
> + the order they are declared. > > doclet.enum_values_doc.return=\ > an array containing the constants of this enum type, in the order they > are declared > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Sep 25 00:39:58 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Sep 2018 17:39:58 -0700 Subject: JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip for enum values() method In-Reply-To: References: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com> Message-ID: <5BA983DE.6020204@oracle.com> Tagir, The enum values are in an array, so you can use any of your favorite methods for iterating over the contents of an array. You can still use an enhanced for loop, if you so choose; this edit is just about that hint being no longer necessary in the generates documentation. -- Jon On 09/24/2018 05:06 PM, Tagir Valeev wrote: > Hello! > > Sorry for stupid question, but what is modern alternative to iterate > over the enum values? > > With best regards, > Tagir Valeev > > ??, 25 ????. 2018 ?., 4:48 joe darcy >: > > Hello, > > Since enum types were added in JDK 5, which shipped GA in 2004, the > javadoc for the compiler-generated static values() method for > enums has > stated: > > > Returns an array containing the constants of this enum type, in the > > order they are declared. This method may be used to iterate over > the > > constants as follows: > > > > for (RoundingMode c : RoundingMode.values()) > > System.out.println(c); > > While the tip to use the enhanced for loop to iterate over the > constants > of the enum type may have been reasonable to include in 2004, IMO > it is > unnecessary and clutter in 2018. Therefore, please review the > changes for > > JDK-8173730: Stop including enhanced for-loop tip for enum > values() > method > http://cr.openjdk.java.net/~darcy/8173730.0/ > > > to remove the generation of the for loop tip. > > Patch below. > > Docs builds complete successfully and elides the tip as expected. > > Thanks, > > -Joe > > --- > old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > > 2018-09-24 14:31:57.943000000 -0700 > +++ > new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties > > 2018-09-24 14:31:57.771000000 -0700 > @@ -230,12 +230,7 @@ > #Documentation for Enums > doclet.enum_values_doc.fullbody=\ > Returns an array containing the constants of this enum type, in\n\ > - the order they are declared. This method may be used to iterate\n\ > - over the constants as follows:\n\ > - 
\n\
>     - for ({0} c : {0}.values())\n\
>     -     System.out.println(c);\n\
>     -
> + the order they are declared. > > doclet.enum_values_doc.return=\ > an array containing the constants of this enum type, in the > order they > are declared > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Sep 25 00:54:39 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 24 Sep 2018 17:54:39 -0700 Subject: JDK 12 RFR of JDK-8173730: Stop including enhanced for-loop tip for enum values() method In-Reply-To: <5BA983DE.6020204@oracle.com> References: <420127fc-df9d-4999-5758-9fa5b13a7d84@oracle.com> <5BA983DE.6020204@oracle.com> Message-ID: Right; the change is just to remove the "BTW, you can use a for loop over an array here" comment from every since enum type's values method. -Joe On 9/24/2018 5:39 PM, Jonathan Gibbons wrote: > Tagir, > > The enum values are in an array, so you can use any of your favorite > methods > for iterating over the contents of an array. You can still use an > enhanced for loop, > if you so choose;? this edit is just about that hint being no longer > necessary in the > generates documentation. > > -- Jon > > On 09/24/2018 05:06 PM, Tagir Valeev wrote: >> Hello! >> >> Sorry for stupid question, but what is modern alternative to iterate >> over the enum values? >> >> With best regards, >> Tagir Valeev >> >> ??, 25 ????. 2018 ?., 4:48 joe darcy > >: >> >> Hello, >> >> Since enum types were added in JDK 5, which shipped GA in 2004, the >> javadoc for the compiler-generated static values() method for >> enums has >> stated: >> >> > Returns an array containing the constants of this enum type, in >> the >> > order they are declared. This method may be used to iterate >> over the >> > constants as follows: >> > >> > for (RoundingMode c : RoundingMode.values()) >> > ??? System.out.println(c); >> >> While the tip to use the enhanced for loop to iterate over the >> constants >> of the enum type may have been reasonable to include in 2004, IMO >> it is >> unnecessary and clutter in 2018. Therefore, please review the >> changes for >> >> ???? JDK-8173730: Stop including enhanced for-loop tip for enum >> values() >> method >> http://cr.openjdk.java.net/~darcy/8173730.0/ >> >> >> to remove the generation of the for loop tip. >> >> Patch below. >> >> Docs builds complete successfully and elides the tip as expected. >> >> Thanks, >> >> -Joe >> >> --- >> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties >> >> 2018-09-24 14:31:57.943000000 -0700 >> +++ >> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties >> >> 2018-09-24 14:31:57.771000000 -0700 >> @@ -230,12 +230,7 @@ >> ??#Documentation for Enums >> ??doclet.enum_values_doc.fullbody=\ >> ?? Returns an array containing the constants of this enum type, in\n\ >> - the order they are declared. This method may be used to iterate\n\ >> - over the constants as follows:\n\ >> - 
\n\
>>     - for ({0} c : {0}.values())\n\
>>     -  ?? System.out.println(c);\n\
>>     -
>> + the order they are declared. >> >> ??doclet.enum_values_doc.return=\ >> ??an array containing the constants of this enum type, in the >> order they >> are declared >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.field at oracle.com Tue Sep 25 02:14:55 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 24 Sep 2018 19:14:55 -0700 Subject: Switch expressions: parsing / syntax Message-ID: <39a7c3ca-2a7a-8125-5b18-65fba64c905a@oracle.com> I'm working on getting all the corners of switch expressions to work in JShell. I found myself surprised at an asymmetry which is perhaps intentional and reflected in the syntax (pointers please). However, I don't understand why it would diverge. Switch expressions are in almost all cases treated as PrimaryNoNewArray (in JLS lingo), however, field access ( SwitchExpression . Identifier ), and array access ( SwitchExpression [ Expression ] ) give syntax errors. In JavacParser, switch expressions are handled in term3(), which appears to align with UnaryExpression in the JLS.? The handling of switch expression diverges from the handling of all other cases in term3() in that it returns rather than falling out of the switch into a call to term3Rest() (which handles field and array access).? Other cases do not return from term3() -- except for failure cases and recursive cases (which call term3Rest() indirectly). -Robert From joe.darcy at oracle.com Tue Sep 25 03:07:20 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 24 Sep 2018 20:07:20 -0700 Subject: Should @SupportedAnnotationTypes handle TYPE_USE? In-Reply-To: References: Message-ID: <25963002-2045-2157-732b-09323b937d80@oracle.com> Hi Bernard, On 9/24/2018 3:05 PM, B. Blaser wrote: > Hi, > > I noted that the annotation processor [1] isn't run if > @SupportedAnnotationTypes ({"TA"}) is used instead of ({"*"}) because > annotations on TYPE_USE don't seem to be handled when selecting > processors. > > Is this normal or should we add something like below (to be completed)? > The documentation [2] isn't clear about that. The documentation of the Processor interface covers this situation: " Annotations on type uses, as opposed to annotations on elements, are ignored when computing whether or not an annotation type is present." https://docs.oracle.com/javase/10/docs/api/javax/annotation/processing/Processor.html HTH, -Joe From robert.field at oracle.com Tue Sep 25 03:11:53 2018 From: robert.field at oracle.com (Robert Field) Date: Mon, 24 Sep 2018 20:11:53 -0700 Subject: Switch expressions: parsing / syntax In-Reply-To: <39a7c3ca-2a7a-8125-5b18-65fba64c905a@oracle.com> References: <39a7c3ca-2a7a-8125-5b18-65fba64c905a@oracle.com> Message-ID: Dan sent me a the spec changes for switch-expressions (which do seem like they should be associated with the JEP) -- thanks Dan! So, switch expressions are UnaryExpressionNotPlusMinus -- which seems a bit strange for a self-contained thing, and which correlates with its odd handling in the parser. -Robert On 09/24/18 19:14, Robert Field wrote: > I'm working on getting all the corners of switch expressions to work > in JShell. > > I found myself surprised at an asymmetry which is perhaps intentional > and reflected in the syntax (pointers please). However, I don't > understand why it would diverge. > > Switch expressions are in almost all cases treated as > PrimaryNoNewArray (in JLS lingo), however, field access ( > SwitchExpression . Identifier ), and array access ( SwitchExpression [ > Expression ] ) give syntax errors. > > In JavacParser, switch expressions are handled in term3(), which > appears to align with UnaryExpression in the JLS.? The handling of > switch expression diverges from the handling of all other cases in > term3() in that it returns rather than falling out of the switch into > a call to term3Rest() (which handles field and array access).? Other > cases do not return from term3() -- except for failure cases and > recursive cases (which call term3Rest() indirectly). > > -Robert > > From mandy.chung at oracle.com Tue Sep 25 03:25:08 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 24 Sep 2018 20:25:08 -0700 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <5BA9513A.5000208@oracle.com> References: <5BA3E481.5080708@oracle.com> <5BA53006.1070903@oracle.com> <7f0645c2-e6c5-2f03-802b-d1ddf565cad4@oracle.com> <6206dce3-8ff0-6e8a-a112-623f3abbcb3a@oracle.com> <5BA9513A.5000208@oracle.com> Message-ID: <2da64eb1-43cc-4d7b-4763-4c388b3f1c0b@oracle.com> On 9/24/18 2:03 PM, Jonathan Gibbons wrote: > > Alan, Mandy, > > Thanks for the additional feedback. > > New webrev: > > * addresses issues with loadClass > * renames "map" to "sourceFileClasses" for added clarity > * fixes/improves comments on MemoryClassLoader and contents > * adds new test case as suggested > > Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.02/index.html > Looks good to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Sep 25 06:33:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Sep 2018 07:33:57 +0100 Subject: RFR: 8210839 Improve interaction between source launcher and classpath In-Reply-To: <5BA9513A.5000208@oracle.com> References: <5BA3E481.5080708@oracle.com> <5BA53006.1070903@oracle.com> <7f0645c2-e6c5-2f03-802b-d1ddf565cad4@oracle.com> <6206dce3-8ff0-6e8a-a112-623f3abbcb3a@oracle.com> <5BA9513A.5000208@oracle.com> Message-ID: <6db4e630-7f81-883a-49b1-d646be7680ab@oracle.com> On 24/09/2018 22:03, Jonathan Gibbons wrote: > : > > Alan, Mandy, > > Thanks for the additional feedback. > > New webrev: > > * addresses issues with loadClass > * renames "map" to "sourceFileClasses" for added clarity > * fixes/improves comments on MemoryClassLoader and contents > * adds new test case as suggested > > Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.02/index.html > This version looks good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Tue Sep 25 09:42:18 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 25 Sep 2018 11:42:18 +0200 Subject: Should @SupportedAnnotationTypes handle TYPE_USE? In-Reply-To: <25963002-2045-2157-732b-09323b937d80@oracle.com> References: <25963002-2045-2157-732b-09323b937d80@oracle.com> Message-ID: On Tue, 25 Sep 2018 at 05:07, joe darcy wrote: > > Hi Bernard, > > > On 9/24/2018 3:05 PM, B. Blaser wrote: > > Hi, > > > > I noted that the annotation processor [1] isn't run if > > @SupportedAnnotationTypes ({"TA"}) is used instead of ({"*"}) because > > annotations on TYPE_USE don't seem to be handled when selecting > > processors. > > > > Is this normal or should we add something like below (to be completed)? > > The documentation [2] isn't clear about that. > > The documentation of the Processor interface covers this situation: > > " Annotations on type uses, as opposed to annotations on elements, are > ignored when computing whether or not an annotation type is present." > https://docs.oracle.com/javase/10/docs/api/javax/annotation/processing/Processor.html Thanks Joe, I missed it :-( But is there any justification for this or is it planned to handle annotations on type use when selecting processor? It should be possible to do that as I showed with the draft I posted yesterday. Using "*" means that processors focusing on type use are always run which isn't what we'd expect and not optimal in performance terms... Bernard > HTH, > > -Joe > From jan.lahoda at oracle.com Tue Sep 25 15:38:04 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 25 Sep 2018 17:38:04 +0200 Subject: RFR: JDK-8211102: Crash with -XDfind=lambda and -source 7 Message-ID: <5BAA565C.1090108@oracle.com> Hi, I'd like to ask for a review of changes that relate to code like: --- import java.util.*; public class AnalyzerBug { private void t(boolean b) { (b ? Collections.emptyList() : new Iterable() { public Iterator iterator() { return null; } }).toString(); } } --- When this code is compiled like: $ javac -XDfind=lambda -source 7 /tmp/AnalyzerBug.java javac crashes in Analyzer. There are two immediate causes for the crash: a) when AnalyzerModes are read form -XDfind, if an analyzer key is explicitly mentioned there, the source level is not checked, and the analyzer is enabled. So, in the case above, the analyzer with try to convert the Iterable to a lambda and process the source, despite the -source 7. I suspect this is not intended, so proposing to always disable an analyzer if it does not have a meaning in the current source level. b) if there's a lambda in a standalone conditional (i.e. without a target), in JDK 12 we try to attribute it anyway, but as a result, the type of the lambda will be the recovery type. And the computation of the type of the standalone conditional chokes on that, as the recovery type does not have a Symbol. So proposing to make the lambda's type an erroneous type in such cases (as was before 12), while still attributing it. There's also related problem, when (very broken) code like this: int j = i instanceof ArrayList ? (ArrayList) i : () -> { return null; }; is attributed, visitLambda will keep JCFunctionalExpression.target unfilled, which seems fine as JCFunctionalExpression.getDescriptorType is prepared for that (and there indeed is no reasonable). But Attr.postAttr will fill it with unknownType, and then calls to getDescriptorType (e.g. from Flow.FlowAnalyzer.visitLambda) lead to FunctionDescriptorLookupError. Seems it might be better to keep the field unfilled, which is what the proposed patch is doing. (This is somewhat less important, as I am not aware of a way to reproduce this without -XDshould-stop.at=FLOW.) JBS: https://bugs.openjdk.java.net/browse/JDK-8211102 Webrev: http://cr.openjdk.java.net/~jlahoda/8211102/webrev.00/ Any feedback is welcome! Thanks, Jan From james.laskey at oracle.com Tue Sep 25 16:55:21 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 25 Sep 2018 13:55:21 -0300 Subject: RFR - JDK-8211080 - RawStringLiteralLangAPI.java test times out by default Message-ID: <602C016B-F37B-47D9-A837-957A938B095C@oracle.com> Reduce the time of the tests. webrev: http://cr.openjdk.java.net/~jlaskey/8211080/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8211080 From maurizio.cimadamore at oracle.com Tue Sep 25 17:16:54 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 25 Sep 2018 18:16:54 +0100 Subject: RFR: JDK-8211102: Crash with -XDfind=lambda and -source 7 In-Reply-To: <5BAA565C.1090108@oracle.com> References: <5BAA565C.1090108@oracle.com> Message-ID: What you say makes sense, but the tests do not reflect what you say in the email. First, none of the test seems to use -XDfind=lambda. That means that no test is actually checking that the condition described in 8211102 does not occur? Secondly, it seems like the issue you are describing with conditional happens w/ or w/o analyzer - e.g. this looks like a standalone issue, and using the analyzer bug to fix it seems misleading (similarly for the 3rd issue fixed by this patch). So, while I don't dispute any of the changes in the patch, I'm having hard time following which is which - can you please clarify? Maurizio On 25/09/18 16:38, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of changes that relate to code like: > --- > import java.util.*; > > public class AnalyzerBug { > ??? private void t(boolean b) { > ??????? (b ? Collections.emptyList() : new Iterable() { public > Iterator iterator() { return null; } }).toString(); > ??? } > } > --- > > When this code is compiled like: > $ javac -XDfind=lambda -source 7 /tmp/AnalyzerBug.java > > javac crashes in Analyzer. There are two immediate causes for the crash: > a) when AnalyzerModes are read form -XDfind, if an analyzer key is > explicitly mentioned there, the source level is not checked, and the > analyzer is enabled. So, in the case above, the analyzer with try to > convert the Iterable to a lambda and process the source, > despite the -source 7. I suspect this is not intended, so proposing to > always disable an analyzer if it does not have a meaning in the > current source level. > > b) if there's a lambda in a standalone conditional (i.e. without a > target), in JDK 12 we try to attribute it anyway, but as a result, the > type of the lambda will be the recovery type. And the computation of > the type of the standalone conditional chokes on that, as the recovery > type does not have a Symbol. So proposing to make the lambda's type an > erroneous type in such cases (as was before 12), while still > attributing it. > > There's also related problem, when (very broken) code like this: > ??????? int j = i instanceof ArrayList ? (ArrayList) i : () -> > { return null; }; > > is attributed, visitLambda will keep JCFunctionalExpression.target > unfilled, which seems fine as JCFunctionalExpression.getDescriptorType > is prepared for that (and there indeed is no reasonable). But > Attr.postAttr will fill it with unknownType, and then calls to > getDescriptorType (e.g. from Flow.FlowAnalyzer.visitLambda) lead to > FunctionDescriptorLookupError. Seems it might be better to keep the > field unfilled, which is what the proposed patch is doing. (This is > somewhat less important, as I am not aware of a way to reproduce this > without -XDshould-stop.at=FLOW.) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211102 > Webrev: http://cr.openjdk.java.net/~jlahoda/8211102/webrev.00/ > > Any feedback is welcome! > > Thanks, > ??? Jan From jan.lahoda at oracle.com Tue Sep 25 19:05:01 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 25 Sep 2018 21:05:01 +0200 Subject: RFR: JDK-8211102: Crash with -XDfind=lambda and -source 7 In-Reply-To: References: <5BAA565C.1090108@oracle.com> Message-ID: <5BAA86DD.9010800@oracle.com> On 25.9.2018 19:16, Maurizio Cimadamore wrote: > What you say makes sense, but the tests do not reflect what you say in > the email. > > First, none of the test seems to use -XDfind=lambda. That means that no > test is actually checking that the condition described in 8211102 does > not occur? > > Secondly, it seems like the issue you are describing with conditional > happens w/ or w/o analyzer - e.g. this looks like a standalone issue, > and using the analyzer bug to fix it seems misleading (similarly for the > 3rd issue fixed by this patch). > > So, while I don't dispute any of the changes in the patch, I'm having > hard time following which is which - can you please clarify? The Analyzer testcase is what I've found first, and it is probably the most serious thing, as javac crashes on valid source (albeit with somewhat non-standard options). While looking at the reasons, I realized that a) the lambda analyzer runs with -source 7 (which is suspicious), and also b) that there is a crash that can be reproduced without using analyzer (which is also the root cause for the analyzer crash). So I went to fix both of these. The third problem, I've ran into it while trying to find a testcase without analyzer, so I went to fix it as well. I can split the patch (and bug) into three parts if desired. Thanks, Jan > > Maurizio > > > On 25/09/18 16:38, Jan Lahoda wrote: >> Hi, >> >> I'd like to ask for a review of changes that relate to code like: >> --- >> import java.util.*; >> >> public class AnalyzerBug { >> private void t(boolean b) { >> (b ? Collections.emptyList() : new Iterable() { public >> Iterator iterator() { return null; } }).toString(); >> } >> } >> --- >> >> When this code is compiled like: >> $ javac -XDfind=lambda -source 7 /tmp/AnalyzerBug.java >> >> javac crashes in Analyzer. There are two immediate causes for the crash: >> a) when AnalyzerModes are read form -XDfind, if an analyzer key is >> explicitly mentioned there, the source level is not checked, and the >> analyzer is enabled. So, in the case above, the analyzer with try to >> convert the Iterable to a lambda and process the source, >> despite the -source 7. I suspect this is not intended, so proposing to >> always disable an analyzer if it does not have a meaning in the >> current source level. >> >> b) if there's a lambda in a standalone conditional (i.e. without a >> target), in JDK 12 we try to attribute it anyway, but as a result, the >> type of the lambda will be the recovery type. And the computation of >> the type of the standalone conditional chokes on that, as the recovery >> type does not have a Symbol. So proposing to make the lambda's type an >> erroneous type in such cases (as was before 12), while still >> attributing it. >> >> There's also related problem, when (very broken) code like this: >> int j = i instanceof ArrayList ? (ArrayList) i : () -> >> { return null; }; >> >> is attributed, visitLambda will keep JCFunctionalExpression.target >> unfilled, which seems fine as JCFunctionalExpression.getDescriptorType >> is prepared for that (and there indeed is no reasonable). But >> Attr.postAttr will fill it with unknownType, and then calls to >> getDescriptorType (e.g. from Flow.FlowAnalyzer.visitLambda) lead to >> FunctionDescriptorLookupError. Seems it might be better to keep the >> field unfilled, which is what the proposed patch is doing. (This is >> somewhat less important, as I am not aware of a way to reproduce this >> without -XDshould-stop.at=FLOW.) >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8211102 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8211102/webrev.00/ >> >> Any feedback is welcome! >> >> Thanks, >> Jan > From jonathan.gibbons at oracle.com Tue Sep 25 20:22:14 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Sep 2018 13:22:14 -0700 Subject: RFR: JDK-8210555: create --source --target synonyms for -source -target Message-ID: <5BAA98F6.1000002@oracle.com> Please review a mostly-trivial change to add --source and --target as synonyms for -source and -target in javac and javadoc. There's also some related test-cleanup. Here's a brief explanation of the changes, listed in the order given in the webrev/index.html file. src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java Add synonyms in javac src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Start.java Replace a hard-coded use of the option name with a symbolic reference src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java Add synonym in the old/deprecated version of the javadoc tool In this version, option aliases are only available using distinct ToolOption members src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java Add synonym in the main/current version of the javadoc tool In this version, option aliases are supported directly, as in javac test/langtools/jdk/javadoc/tool/api/basic/IsSupportedOptionTest.java We don't have good regular testing infrastructure for testing javadoc options; this test is as good as any for a basic test that the alias is recognized. test/langtools/jdk/javadoc/tool/sourceOption/SourceOption.java There is no code change in this test, but the comment was broken, and way too version-specific. The comment is rewritten to be less version-specific. test/langtools/tools/javac/options/IsSupportedOptionTest.java As with the javadoc version of this test given above, we don't have good regular testing infrastructure for testing javac options; this test is as good as any for a basic test that the alias is recognized. test/langtools/tools/javadoc/sourceOption/SourceOption.java This is the version of the SourceOption test for the old/deprecated version of javadoc. The new comment is a cut-n-paste copy of the new text for the version of the test for the standard version of javadoc, given above. test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java This test was in the set of tests for the old/deprecated version of javadoc, but was not specific to the old doclet, and the text was almost identical to the other version, given above. The only differences in the text was a 1-character difference in the copyright date, and a 1-character typo that has already been corrected in the new version. JBS: https://bugs.openjdk.java.net/browse/JDK-8210555 Webrev: http://cr.openjdk.java.net/~jjg/8210555/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8210556 -- Jon From jonathan.gibbons at oracle.com Tue Sep 25 21:12:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Sep 2018 14:12:11 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5BA40341.3020904@oracle.com> References: <5B96D5F5.7010800@oracle.com> <5BA40341.3020904@oracle.com> Message-ID: <5BAAA4AB.1000401@oracle.com> Updated webrev against the latest jdk/jdk sources. No change in the updates for this feature (just changes in the surrounding context) Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.02/ -- Jon On 09/20/2018 01:29 PM, Jonathan Gibbons wrote: > Please review a simplified solution to this issue. > > It turns out to be not reasonable to make the source launcher work as > well as might > be desired when a security manager is enabled, without addressing the > bigger problem > of making javac (i.e. the jdk.compiler module) work well with a > security manager, > and the related problems of handling callbacks from javac in such an > environment. > > In addition, working with a security manager is arguably beyond the > scope of the > feature as described in JEP 330. > > The simplified solution proposed here is just to use a protection > domain with a > code source set to the source file when defining classes in the > internal MemoryClassLoader. > This at least gives advanced users the ability to set permissions for > classes in the > source file, if they also address or workaround the issues of > permissions for the > jdk.compiler module. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 > Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.01/ > > -- Jon > > > On 09/10/2018 01:37 PM, Jonathan Gibbons wrote: >> Please review a patch to have the Source Launcher be able to work >> when a security manager is enabled. >> >> There are 4 parts to the work: an update to the default policy file, >> an update to the source launcher itself, updates to tests, and a >> custom security manager to help with testing. >> >> 1. src/java.base/share/lib/security/default.policy >> >> Add reasonably fine-grain permissions to give javac the permissions >> it needs to run when a security manager is enabled. These permissions >> were determined by running all javac tests under with a special >> security manager installed: more on that later. There is one >> anomalous property which was detected, which is a property to control >> some internal javac behavior. Arguably, it should eventually be >> renamed with at least a "javac.*" prefix. >> >> 2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java >> >> Update the source launcher to use doPrivileged in a couple of places: >> most notably around the main invocation of javac. Generally, it >> continues to be the policy that command-line tools like javac, >> javadoc do not use fine-grained doPrivileged blocks throughout the >> tool, and this update does not change that. It is worth noting that >> when javac is invoked from the Source Launcher, it does not support >> callbacks like annotation processors, task listeners, and other >> plugin code, so that eliminates any issues relating to using >> callbacks from code in a doPrivileged block. >> >> 3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java >> >> This is a custom new security manager for manual testing purposes in >> conjunction with jtreg, so that we can run a large subset of tests >> under the influence of a security manager. . It is a design >> characteristic of jtreg that almost all tests have their own distinct >> codebase, and so it is impractical to use a modified policy file to >> grant all necessary permissions to all necessary tests, so this >> security manager installs a custom Policy object that grants >> permissions to test code while deferring to the system policy for >> everything else (and for javac in particular.) Using this security >> manager, it is possible to run all the javac tests to detect with >> high probability all the permissions that it requires. Using a custom >> security manager to install a custom Policy object allows the feature >> to be easily enabled on the jtreg command line. >> >> There is one workaround in this security manager: a bug was uncovered >> such that the jdk.zipfs module needs permission to access the >> user.dir system property. ( >> https://bugs.openjdk.java.net/browse/JDK-8210469 ) A temporary >> workaround is used to get a clean test run. >> >> Note: this code is not directly used in any normal/automated test >> runs for javac; nevertheless, it is deemed worthwhile to save the >> code for use in similar situations in the future. >> >> 4. Minor updates to tests. >> >> Some new test cases are added to Source Launcher tests. >> >> Although most tests are not directly affected by the use of a >> security manager, there are some exceptions. Some tests manipulate >> the security manager and/or expect the security manager to be unset. >> These tests are modified to "pass by default" if the runtime >> conditions are not suitable (i.e. a security manager has been >> installed.) >> >> Although it is not a requirement to be able to run annotation >> processing tests when a security manager is enabled (because that >> condition cannot arise with the Source Launcher), most annotation >> processing tests do run successfully. There were 3 exceptions, where >> the test required more permissions than granted to javac in code >> being called from javac. These permissions were to access test.* >> system properties and the setIO runtime permission. Rather than grant >> unnecessary properties to javac, it was enough to use doPrivileged in >> a couple of places in the javac "toolbox" test library, and to >> refactor those tests to better use toolbox. >> >> In conjunction with these changes,ignoring any tests on the >> ProblemList, all javac tests pass, with and without a security >> manager being present. >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 >> Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/ >> >> >> -- Jon > From jonathan.gibbons at oracle.com Tue Sep 25 21:17:37 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Sep 2018 14:17:37 -0700 Subject: Result: New Compiler Group Member: Vicente Romero In-Reply-To: <5B8ECE8D.3050801@oracle.com> References: <5B8ECE8D.3050801@oracle.com> Message-ID: <5BAAA5F1.6030300@oracle.com> The vote for Vicente Romero [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Jon Gibbons [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012351.html On 09/04/2018 11:27 AM, Jonathan Gibbons wrote: > |I hereby nominate Vicente Romero to Membership in the Compiler Group. > > Vicente is a leading contributor to javac, and has contributed 282 changesets > since he started back in 2012. > > Votes are due in two weeks, by 11:30 a.m. PDT, Sep 18th. > > Only current Members of the Compiler Group [1] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > -- Jon Gibbons > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/groups/#member-vote| -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Sep 25 21:48:53 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 25 Sep 2018 14:48:53 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5BAAA4AB.1000401@oracle.com> References: <5B96D5F5.7010800@oracle.com> <5BA40341.3020904@oracle.com> <5BAAA4AB.1000401@oracle.com> Message-ID: <8215bf4e-a03c-33ff-c2e4-36dc4e9cf4ac@oracle.com> On 9/25/18 2:12 PM, Jonathan Gibbons wrote: > Updated webrev against the latest jdk/jdk sources. > > No change in the updates for this feature (just changes in the > surrounding context) > > Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.02/ > This simplified solution sounds reasonable.? This would allow the developers to to run with security manager if desirable. You added the test case to verify the code source.?? It'd also be good to include a test case to launch with a test policy to validate the intended workaround this provides. The change is fine to create its protection domain.? An alternative is to make MemoryClassLoader extends SecureClassLoader such that you can call defineClass to pass in the CodeSource.?? Just to mention it and I don't have strong opinion in one way or other. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Sep 25 22:23:27 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Sep 2018 15:23:27 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <8215bf4e-a03c-33ff-c2e4-36dc4e9cf4ac@oracle.com> References: <5B96D5F5.7010800@oracle.com> <5BA40341.3020904@oracle.com> <5BAAA4AB.1000401@oracle.com> <8215bf4e-a03c-33ff-c2e4-36dc4e9cf4ac@oracle.com> Message-ID: <5BAAB55F.5080305@oracle.com> On 09/25/2018 02:48 PM, mandy chung wrote: > > > On 9/25/18 2:12 PM, Jonathan Gibbons wrote: >> Updated webrev against the latest jdk/jdk sources. >> >> No change in the updates for this feature (just changes in the >> surrounding context) >> >> Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.02/ >> > > This simplified solution sounds reasonable. This would allow the > developers to > to run with security manager if desirable. > > You added the test case to verify the code source. It'd also be good > to include > a test case to launch with a test policy to validate the intended > workaround > this provides. > > The change is fine to create its protection domain. An alternative is > to make MemoryClassLoader extends SecureClassLoader such that > you can call defineClass to pass in the CodeSource. Just to mention it > and I don't have strong opinion in one way or other. > > Mandy > Mandy, Thanks for the review. Here's the additional test case you suggested, demonstrating the ability to give source file permission to read a system property, but not write it. Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.03/ -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Sep 25 22:32:10 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 25 Sep 2018 15:32:10 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5BAAB55F.5080305@oracle.com> References: <5B96D5F5.7010800@oracle.com> <5BA40341.3020904@oracle.com> <5BAAA4AB.1000401@oracle.com> <8215bf4e-a03c-33ff-c2e4-36dc4e9cf4ac@oracle.com> <5BAAB55F.5080305@oracle.com> Message-ID: <7ea9b72a-a50e-1828-5be1-7b08ff82ca0e@oracle.com> On 9/25/18 3:23 PM, Jonathan Gibbons wrote: > > Mandy, > > Thanks for the review.? Here's the additional test case you suggested, > demonstrating the ability to give source file permission to read a > system property, but not write it. > > Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.03/ +1 Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Sep 25 22:38:02 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 25 Sep 2018 23:38:02 +0100 Subject: RFR: JDK-8211102: Crash with -XDfind=lambda and -source 7 In-Reply-To: <5BAA86DD.9010800@oracle.com> References: <5BAA565C.1090108@oracle.com> <5BAA86DD.9010800@oracle.com> Message-ID: <7338fe5b-0e40-7e7f-c057-fe87bafbedb6@oracle.com> On 25/09/18 20:05, Jan Lahoda wrote: > On 25.9.2018 19:16, Maurizio Cimadamore wrote: >> What you say makes sense, but the tests do not reflect what you say in >> the email. >> >> First, none of the test seems to use -XDfind=lambda. That means that no >> test is actually checking that the condition described in 8211102 does >> not occur? >> >> Secondly, it seems like the issue you are describing with conditional >> happens w/ or w/o analyzer - e.g. this looks like a standalone issue, >> and using the analyzer bug to fix it seems misleading (similarly for the >> 3rd issue fixed by this patch). >> >> So, while I don't dispute any of the changes in the patch, I'm having >> hard time following which is which - can you please clarify? > > The Analyzer testcase is what I've found first, and it is probably the > most serious thing, as javac crashes on valid source (albeit with > somewhat non-standard options). While looking at the reasons, I > realized that a) the lambda analyzer runs with -source 7 (which is > suspicious), and also b) that there is a crash that can be reproduced > without using analyzer (which is also the root cause for the analyzer > crash). So I went to fix both of these. The third problem, I've ran > into it while trying to find a testcase without analyzer, so I went to > fix it as well. > > I can split the patch (and bug) into three parts if desired. I'm ok with keeping them together, but I'd add a test with the -XDfind option, just in case. E.g. something that makes sure that we don't generate 'finder' messages for features that are not supported in a given source level. Maurizio > > Thanks, > ??? Jan > >> >> Maurizio >> >> >> On 25/09/18 16:38, Jan Lahoda wrote: >>> Hi, >>> >>> I'd like to ask for a review of changes that relate to code like: >>> --- >>> import java.util.*; >>> >>> public class AnalyzerBug { >>> ??? private void t(boolean b) { >>> ??????? (b ? Collections.emptyList() : new Iterable() { public >>> Iterator iterator() { return null; } }).toString(); >>> ??? } >>> } >>> --- >>> >>> When this code is compiled like: >>> $ javac -XDfind=lambda -source 7 /tmp/AnalyzerBug.java >>> >>> javac crashes in Analyzer. There are two immediate causes for the >>> crash: >>> a) when AnalyzerModes are read form -XDfind, if an analyzer key is >>> explicitly mentioned there, the source level is not checked, and the >>> analyzer is enabled. So, in the case above, the analyzer with try to >>> convert the Iterable to a lambda and process the source, >>> despite the -source 7. I suspect this is not intended, so proposing to >>> always disable an analyzer if it does not have a meaning in the >>> current source level. >>> >>> b) if there's a lambda in a standalone conditional (i.e. without a >>> target), in JDK 12 we try to attribute it anyway, but as a result, the >>> type of the lambda will be the recovery type. And the computation of >>> the type of the standalone conditional chokes on that, as the recovery >>> type does not have a Symbol. So proposing to make the lambda's type an >>> erroneous type in such cases (as was before 12), while still >>> attributing it. >>> >>> There's also related problem, when (very broken) code like this: >>> ??????? int j = i instanceof ArrayList ? (ArrayList) i : () -> >>> { return null; }; >>> >>> is attributed, visitLambda will keep JCFunctionalExpression.target >>> unfilled, which seems fine as JCFunctionalExpression.getDescriptorType >>> is prepared for that (and there indeed is no reasonable). But >>> Attr.postAttr will fill it with unknownType, and then calls to >>> getDescriptorType (e.g. from Flow.FlowAnalyzer.visitLambda) lead to >>> FunctionDescriptorLookupError. Seems it might be better to keep the >>> field unfilled, which is what the proposed patch is doing. (This is >>> somewhat less important, as I am not aware of a way to reproduce this >>> without -XDshould-stop.at=FLOW.) >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8211102 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8211102/webrev.00/ >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ??? Jan >> From joe.darcy at oracle.com Tue Sep 25 23:18:44 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 25 Sep 2018 16:18:44 -0700 Subject: Should @SupportedAnnotationTypes handle TYPE_USE? In-Reply-To: References: <25963002-2045-2157-732b-09323b937d80@oracle.com> Message-ID: <5BAAC254.1020301@oracle.com> Hi Bernard, On 9/25/2018 2:42 AM, B. Blaser wrote: > On Tue, 25 Sep 2018 at 05:07, joe darcy wrote: >> Hi Bernard, >> >> >> On 9/24/2018 3:05 PM, B. Blaser wrote: >>> Hi, >>> >>> I noted that the annotation processor [1] isn't run if >>> @SupportedAnnotationTypes ({"TA"}) is used instead of ({"*"}) because >>> annotations on TYPE_USE don't seem to be handled when selecting >>> processors. >>> >>> Is this normal or should we add something like below (to be completed)? >>> The documentation [2] isn't clear about that. >> The documentation of the Processor interface covers this situation: >> >> " Annotations on type uses, as opposed to annotations on elements, are >> ignored when computing whether or not an annotation type is present." >> https://docs.oracle.com/javase/10/docs/api/javax/annotation/processing/Processor.html > Thanks Joe, I missed it :-( > But is there any justification for this or is it planned to handle > annotations on type use when selecting processor? > It should be possible to do that as I showed with the draft I posted yesterday. > Using "*" means that processors focusing on type use are always run > which isn't what we'd expect and not optimal in performance terms... > The text in question was added under JDK-7162089: Add support for repeating annotations to javax.annotation.processing. This is the level of support for type annotations and annotation processing that was proposed and agreed to back in 2013 when the feature was added to the platform as part of JDK 8: http://mail.openjdk.java.net/pipermail/type-annotations-spec-comments/2013-May/000033.html http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-May/000212.html Supporting type annotations was not the intended design center of the annotation processing API. Note that it would be possible to write a TypeAnnotationProcessor which wrapped a Processor instanced and provided the sort of functionality you're interested in. HTH, -Joe From cushon at google.com Wed Sep 26 04:42:25 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 25 Sep 2018 21:42:25 -0700 Subject: RFR: 8211138: Missing Flag enum constants In-Reply-To: <47c8af07-c73c-8beb-492c-1a54843a3e20@oracle.com> References: <47c8af07-c73c-8beb-492c-1a54843a3e20@oracle.com> Message-ID: On Mon, Sep 24, 2018 at 8:29 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Which leaves out ANONCONSTR_BASED and POTENTIALLY_AMBIGUOUS, which > should indeed be added to avoid spurious assertion failures. > I put together a patch and created a simple test to ensure the enum constants are kept in sync: webrev: http://cr.openjdk.java.net/~cushon/8211138/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8211138 I wonder if there are good options for preventing this mistake statically, instead of with a test. (e.g. using EnumSets, but maybe that's a non-starter for performance reasons?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Sep 26 08:43:42 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 26 Sep 2018 10:43:42 +0200 Subject: RFR: JDK-8211102: Crash with -XDfind=lambda and -source 7 In-Reply-To: <7338fe5b-0e40-7e7f-c057-fe87bafbedb6@oracle.com> References: <5BAA565C.1090108@oracle.com> <5BAA86DD.9010800@oracle.com> <7338fe5b-0e40-7e7f-c057-fe87bafbedb6@oracle.com> Message-ID: <5BAB46BE.3060906@oracle.com> On 26.9.2018 00:38, Maurizio Cimadamore wrote: > > > On 25/09/18 20:05, Jan Lahoda wrote: >> On 25.9.2018 19:16, Maurizio Cimadamore wrote: >>> What you say makes sense, but the tests do not reflect what you say in >>> the email. >>> >>> First, none of the test seems to use -XDfind=lambda. That means that no >>> test is actually checking that the condition described in 8211102 does >>> not occur? >>> >>> Secondly, it seems like the issue you are describing with conditional >>> happens w/ or w/o analyzer - e.g. this looks like a standalone issue, >>> and using the analyzer bug to fix it seems misleading (similarly for the >>> 3rd issue fixed by this patch). >>> >>> So, while I don't dispute any of the changes in the patch, I'm having >>> hard time following which is which - can you please clarify? >> >> The Analyzer testcase is what I've found first, and it is probably the >> most serious thing, as javac crashes on valid source (albeit with >> somewhat non-standard options). While looking at the reasons, I >> realized that a) the lambda analyzer runs with -source 7 (which is >> suspicious), and also b) that there is a crash that can be reproduced >> without using analyzer (which is also the root cause for the analyzer >> crash). So I went to fix both of these. The third problem, I've ran >> into it while trying to find a testcase without analyzer, so I went to >> fix it as well. >> >> I can split the patch (and bug) into three parts if desired. > I'm ok with keeping them together, but I'd add a test with the -XDfind > option, just in case. E.g. something that makes sure that we don't > generate 'finder' messages for features that are not supported in a > given source level. Sure, updated webrev: http://cr.openjdk.java.net/~jlahoda/8211102/webrev.01/ Thanks, Jan > > Maurizio > >> >> Thanks, >> Jan >> >>> >>> Maurizio >>> >>> >>> On 25/09/18 16:38, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I'd like to ask for a review of changes that relate to code like: >>>> --- >>>> import java.util.*; >>>> >>>> public class AnalyzerBug { >>>> private void t(boolean b) { >>>> (b ? Collections.emptyList() : new Iterable() { public >>>> Iterator iterator() { return null; } }).toString(); >>>> } >>>> } >>>> --- >>>> >>>> When this code is compiled like: >>>> $ javac -XDfind=lambda -source 7 /tmp/AnalyzerBug.java >>>> >>>> javac crashes in Analyzer. There are two immediate causes for the >>>> crash: >>>> a) when AnalyzerModes are read form -XDfind, if an analyzer key is >>>> explicitly mentioned there, the source level is not checked, and the >>>> analyzer is enabled. So, in the case above, the analyzer with try to >>>> convert the Iterable to a lambda and process the source, >>>> despite the -source 7. I suspect this is not intended, so proposing to >>>> always disable an analyzer if it does not have a meaning in the >>>> current source level. >>>> >>>> b) if there's a lambda in a standalone conditional (i.e. without a >>>> target), in JDK 12 we try to attribute it anyway, but as a result, the >>>> type of the lambda will be the recovery type. And the computation of >>>> the type of the standalone conditional chokes on that, as the recovery >>>> type does not have a Symbol. So proposing to make the lambda's type an >>>> erroneous type in such cases (as was before 12), while still >>>> attributing it. >>>> >>>> There's also related problem, when (very broken) code like this: >>>> int j = i instanceof ArrayList ? (ArrayList) i : () -> >>>> { return null; }; >>>> >>>> is attributed, visitLambda will keep JCFunctionalExpression.target >>>> unfilled, which seems fine as JCFunctionalExpression.getDescriptorType >>>> is prepared for that (and there indeed is no reasonable). But >>>> Attr.postAttr will fill it with unknownType, and then calls to >>>> getDescriptorType (e.g. from Flow.FlowAnalyzer.visitLambda) lead to >>>> FunctionDescriptorLookupError. Seems it might be better to keep the >>>> field unfilled, which is what the proposed patch is doing. (This is >>>> somewhat less important, as I am not aware of a way to reproduce this >>>> without -XDshould-stop.at=FLOW.) >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8211102 >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8211102/webrev.00/ >>>> >>>> Any feedback is welcome! >>>> >>>> Thanks, >>>> Jan >>> > From Alan.Bateman at oracle.com Wed Sep 26 12:51:40 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Sep 2018 13:51:40 +0100 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5BAAB55F.5080305@oracle.com> References: <5B96D5F5.7010800@oracle.com> <5BA40341.3020904@oracle.com> <5BAAA4AB.1000401@oracle.com> <8215bf4e-a03c-33ff-c2e4-36dc4e9cf4ac@oracle.com> <5BAAB55F.5080305@oracle.com> Message-ID: <4461bdb6-88c0-694e-ec94-8a0a492ddf5a@oracle.com> On 25/09/2018 23:23, Jonathan Gibbons wrote: > : > > Thanks for the review.? Here's the additional test case you suggested, > demonstrating the ability to give source file permission to read a > system property, but not write it. > > Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.03/ I assume it would be a SecureClassLoader but this version seems okay. Also I think okay for the code source to be the source file. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Sep 26 13:28:16 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 26 Sep 2018 09:28:16 -0400 Subject: RFR: 8211138: Missing Flag enum constants In-Reply-To: References: <47c8af07-c73c-8beb-492c-1a54843a3e20@oracle.com> Message-ID: <7b554fb0-7524-f708-b3eb-8fa2c1671dfa@oracle.com> looks good, Vicente On 09/26/2018 12:42 AM, Liam Miller-Cushon wrote: > On Mon, Sep 24, 2018 at 8:29 AM Maurizio Cimadamore > > wrote: > > Which leaves out ANONCONSTR_BASED and POTENTIALLY_AMBIGUOUS, which > should indeed be added to avoid spurious assertion failures. > > > I put together a patch and created a simple test to ensure the enum > constants are kept in sync: > > webrev: http://cr.openjdk.java.net/~cushon/8211138/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8211138 > > I wonder if there are good options for preventing this mistake > statically, instead of with a test. (e.g. using EnumSets, but maybe > that's a non-starter for performance reasons?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Sep 26 13:59:43 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 26 Sep 2018 14:59:43 +0100 Subject: RFR: 8211138: Missing Flag enum constants In-Reply-To: References: <47c8af07-c73c-8beb-492c-1a54843a3e20@oracle.com> Message-ID: <39b70c80-da4a-0cec-7392-943cd4de548f@oracle.com> On 26/09/18 05:42, Liam Miller-Cushon wrote: > On Mon, Sep 24, 2018 at 8:29 AM Maurizio Cimadamore > > wrote: > > Which leaves out ANONCONSTR_BASED and POTENTIALLY_AMBIGUOUS, which > should indeed be added to avoid spurious assertion failures. > > > I put together a patch and created a simple test to ensure the enum > constants are kept in sync: > > webrev: http://cr.openjdk.java.net/~cushon/8211138/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8211138 > > I wonder if there are good options for preventing this mistake > statically, instead of with a test. (e.g. using EnumSets, but maybe > that's a non-starter for performance reasons?) Thanks, looks good. We have discussed internally to replace flags with an enum. I'll polish that email and share it here, since it's related Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes.wallnoefer at oracle.com Wed Sep 26 14:01:32 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 26 Sep 2018 16:01:32 +0200 Subject: RFR: JDK-8210555: create --source --target synonyms for -source -target In-Reply-To: <5BAA98F6.1000002@oracle.com> References: <5BAA98F6.1000002@oracle.com> Message-ID: Looks good to me. Hannes > Am 25.09.2018 um 22:22 schrieb Jonathan Gibbons : > > Please review a mostly-trivial change to add --source and --target as > synonyms for -source and -target in javac and javadoc. > > There's also some related test-cleanup. > > Here's a brief explanation of the changes, listed in the order given in the > webrev/index.html file. > > src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java > Add synonyms in javac > > src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Start.java > Replace a hard-coded use of the option name with a symbolic reference > > src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java > Add synonym in the old/deprecated version of the javadoc tool > In this version, option aliases are only available using distinct ToolOption members > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java > Add synonym in the main/current version of the javadoc tool > In this version, option aliases are supported directly, as in javac > > test/langtools/jdk/javadoc/tool/api/basic/IsSupportedOptionTest.java > We don't have good regular testing infrastructure for testing javadoc options; > this test is as good as any for a basic test that the alias is recognized. > > test/langtools/jdk/javadoc/tool/sourceOption/SourceOption.java > There is no code change in this test, but the comment was > broken, and way too version-specific. The comment is rewritten > to be less version-specific. > > test/langtools/tools/javac/options/IsSupportedOptionTest.java > As with the javadoc version of this test given above, > we don't have good regular testing infrastructure for testing javac options; > this test is as good as any for a basic test that the alias is recognized. > > test/langtools/tools/javadoc/sourceOption/SourceOption.java > This is the version of the SourceOption test for the old/deprecated version > of javadoc. The new comment is a cut-n-paste copy of the new text > for the version of the test for the standard version of javadoc, given above. > > test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java > This test was in the set of tests for the old/deprecated version of javadoc, > but was not specific to the old doclet, and the text was almost identical > to the other version, given above. The only differences in the text was > a 1-character difference in the copyright date, and a 1-character typo > that has already been corrected in the new version. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210555 > Webrev: http://cr.openjdk.java.net/~jjg/8210555/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8210556 > > -- Jon From maurizio.cimadamore at oracle.com Wed Sep 26 14:16:29 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 26 Sep 2018 15:16:29 +0100 Subject: on javac flags Message-ID: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> Hi, In javac we have a Flags class which is used to define a list of all the flags that are used, both internally (i.e. javac private flags) and externally (i.e ACC_ flags). The assumption is that external flags are 16-bit wide, while internal flags are all values above 2^16 (_which can fit in a long_). There are several issues with the current handling of flags: * since both internal and external flags are mapped onto the same abstraction (a numeric constant), it becomes confusing to marshal/unmarshal public flags to private flags. For instance, the internal BRIDGE flag must be mapped to the public ACC_BRIDGE flag when we are about to write a classfile - and the reverse operation must be performed when we read from the classfile (if we used ACC_BRIDGE internally javac would think that the method is VOLATILE). For the records - there are 4 separate methods for mapping public flags onto private and viceversa (spread between ClassReader and ClassWriter). * The code for checking well-formedness of flags has become very convoluted. This is caused by the fact that this code used to work on the assumption that the well-formedness check only needed to work on public flags (i.e. X < 2^16). But when we added default methods, this code needed to be upgraded to work on any flag (even internal ones - such as DEFAULT, an internal flag), and that turned the code even more obscure. * checking presence/absence of flags is very tedious; we have many many occurrences (600+) of C-like code like: if ((sym.flags() & STATIC) == 0 && ... or (sym.flags() & (ABSTRACT|DEFAULT|PRIVATE)) == ABSTRACT) { ... } etc. * this is kind of related to the point above - since checking flags is so darn unhandy - helper methods popped up; i.e. Symbol.isStatic will essentially do (Symbol.flags() & STATIC) != 0 - etc. So there are more ways to get to the same answer - and of the codebase doesn't adhere to any strict guideline on whether to use one way or the other (although generally speaking, the low level variant is preferred when symbol completion needs to be avoided). * last and not least - we are running out of internal flags (we only have 6 available slots in jdk/jdk [2]). While we can be more parsimonious w.r.t. our internal flags (and indeed we have, see [3]), I think - and garbage collect the unused ones over times, I also think that the very nature of an internal flag is such that it can be used to describe something very specific (i.e. a compiler invariant - such as UNCOMPLETED or ACYCLIC) - and there are many many occasions where we'd like to be able to do so; so while 16 bits might be enough for public flags (cough), I don't think that 64 bits are necessarily adequate for representing the internal flags space. I'd be wary of starting to play the same dance we do for public flags - e.g. UNCOMPLETED and ACYCLIC can never occur on the same symbols, so let's reuse the same bit for both. * Duplication with the Flags.Flag enum; each flag constant is represented as an enum, as sometimes client code need to access flags that way; needless to say, over time this has led to inconsistencies - the last of which has been described in this thread [1] All this got me thinking; it seems to me that most of the problems above are caused by the fact that we want to shoehorn private flags onto the same bits we use for public flags. So, what if we used different abstractions for public vs private flags? More specifically, we could keep using ints for mapping well-known public flag values (whose value is specified in the JVMS after all). But we could use something fancier like an EnumSet for internal flags. What does this mean? First of all, Symbol would no longer have a 'long' field for flags - it will have an Set, where Flag is an enum (stay with me on this - if you are concerned about memory footprint, please note that I'll address that later on). This simple change of representation has already many advantages: * as Flag is an enum, the number of internal flags is virtually unbounded. * since we have a Set, testing for flag presence/absence becomes much nicer (and if the underlying set is an EnumSet, we get good performances too!) * we could centralize the logic for mapping internal flags to external ones onto the Flag itself! This means that each private flag would know how to map itself onto an external one (and viceversa) - and ClassReader/Writer will simply take advantage of that. Ok, the obvious catch is that what used to be a 'value' (a long) is now a reference pointing into the heap. So, with a naive implementation, we would have one more heap-allocated object per Symbol. This is of course not a very desirable property. Can we improve? I think we can - for instance, the Flag enum can define immutable enum sets for very common flags combos: public static public protected public abstract and so forth. Since these flag masks are shared, they will need to be made immutable (Collections.immutableSet) to make sure that nobody will try to add stuff to them. Flags could also define a bunch of methods to union/intersect flags, so that you get a new EnumSet with the right bits (this overcomes the problem that some flag sets are immutable). At the same time, Flags could also define a factory method which takes a bunch of Modifiers (as read by the parser) and turns them into an internal flag set - the factory would check for common idioms and return the shared objects where possible. Another, even more extreme way, would be to pool all flags into a Set> - and then, if the flag set you are about to create is already contained in the set, you return it, otherwise you add the new flag combo into the set. This means taking a slight hit on flag creation (i.e. the new flag combo will need to be looked up in the shared set). But it has the advantage of not needing to 'guess' which flag combos are likely - and, since all sets created in this way will be immutable, it would provide more uniformity - i.e. to chain flags together you have to go through the Flag helper methods. Where does this leave us? I think with these optimizations the memory footprint should be relatively contained - we are essentially trading a 64-bit value (long flag) with a 64 bit pointer which might or might not point to a fresh new object (if not, no extra cost). Of course this all needed to be validated with some real world profiling/JMH benchmark, but seems like a direction worth exploring. Thoughts? Maurizio [1] - http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012470.html [2] - http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l314 [3] - http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l320 From forax at univ-mlv.fr Wed Sep 26 15:12:21 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 26 Sep 2018 17:12:21 +0200 (CEST) Subject: on javac flags In-Reply-To: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> Message-ID: <1713932138.396282.1537974741727.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "compiler-dev" > Envoy?: Mercredi 26 Septembre 2018 16:16:29 > Objet: on javac flags > Hi, > In javac we have a Flags class which is used to define a list of all the > flags that are used, both internally (i.e. javac private flags) and > externally (i.e ACC_ flags). The assumption is that external flags are > 16-bit wide, while internal flags are all values above 2^16 (_which can > fit in a long_). > > There are several issues with the current handling of flags: > > * since both internal and external flags are mapped onto the same > abstraction (a numeric constant), it becomes confusing to > marshal/unmarshal public flags to private flags. For instance, the > internal BRIDGE flag must be mapped to the public ACC_BRIDGE flag when > we are about to write a classfile - and the reverse operation must be > performed when we read from the classfile (if we used ACC_BRIDGE > internally javac would think that the method is VOLATILE). For the > records - there are 4 separate methods for mapping public flags onto > private and viceversa (spread between ClassReader and ClassWriter). > > * The code for checking well-formedness of flags has become very > convoluted. This is caused by the fact that this code used to work on > the assumption that the well-formedness check only needed to work on > public flags (i.e. X < 2^16). But when we added default methods, this > code needed to be upgraded to work on any flag (even internal ones - > such as DEFAULT, an internal flag), and that turned the code even more > obscure. > > * checking presence/absence of flags is very tedious; we have many many > occurrences (600+) of C-like code like: > > if ((sym.flags() & STATIC) == 0 && ... > > or > > (sym.flags() & (ABSTRACT|DEFAULT|PRIVATE)) == ABSTRACT) { ... } > > etc. > > * this is kind of related to the point above - since checking flags is > so darn unhandy - helper methods popped up; i.e. Symbol.isStatic will > essentially do (Symbol.flags() & STATIC) != 0 - etc. So there are more > ways to get to the same answer - and of the codebase doesn't adhere to > any strict guideline on whether to use one way or the other (although > generally speaking, the low level variant is preferred when symbol > completion needs to be avoided). > > * last and not least - we are running out of internal flags (we only > have 6 available slots in jdk/jdk [2]). While we can be more > parsimonious w.r.t. our internal flags (and indeed we have, see [3]), I > think - and garbage collect the unused ones over times, I also think > that the very nature of an internal flag is such that it can be used to > describe something very specific (i.e. a compiler invariant - such as > UNCOMPLETED or ACYCLIC) - and there are many many occasions where we'd > like to be able to do so; so while 16 bits might be enough for public > flags (cough), I don't think that 64 bits are necessarily adequate for > representing the internal flags space. I'd be wary of starting to play > the same dance we do for public flags - e.g. UNCOMPLETED and ACYCLIC can > never occur on the same symbols, so let's reuse the same bit for both. > > * Duplication with the Flags.Flag enum; each flag constant is > represented as an enum, as sometimes client code need to access flags > that way; needless to say, over time this has led to inconsistencies - > the last of which has been described in this thread [1] > > All this got me thinking; it seems to me that most of the problems above > are caused by the fact that we want to shoehorn private flags onto the > same bits we use for public flags. So, what if we used different > abstractions for public vs private flags? More specifically, we could > keep using ints for mapping well-known public flag values (whose value > is specified in the JVMS after all). But we could use something fancier > like an EnumSet for internal flags. What does this mean? > > First of all, Symbol would no longer have a 'long' field for flags - it > will have an Set, where Flag is an enum (stay with me on this - if > you are concerned about memory footprint, please note that I'll address > that later on). This simple change of representation has already many > advantages: > > * as Flag is an enum, the number of internal flags is virtually unbounded. > * since we have a Set, testing for flag presence/absence becomes > much nicer (and if the underlying set is an EnumSet, we get good > performances too!) > * we could centralize the logic for mapping internal flags to external > ones onto the Flag itself! This means that each private flag would know > how to map itself onto an external one (and viceversa) - and > ClassReader/Writer will simply take advantage of that. > > Ok, the obvious catch is that what used to be a 'value' (a long) is now > a reference pointing into the heap. So, with a naive implementation, we > would have one more heap-allocated object per Symbol. This is of course > not a very desirable property. Can we improve? I think we can - for > instance, the Flag enum can define immutable enum sets for very common > flags combos: > > public static > public > protected > public abstract > > and so forth. Since these flag masks are shared, they will need to be > made immutable (Collections.immutableSet) to make sure that nobody will > try to add stuff to them. Flags could also define a bunch of methods to > union/intersect flags, so that you get a new EnumSet with the right bits > (this overcomes the problem that some flag sets are immutable). > > At the same time, Flags could also define a factory method which takes a > bunch of Modifiers (as read by the parser) and turns them into an > internal flag set - the factory would check for common idioms and return > the shared objects where possible. > > Another, even more extreme way, would be to pool all flags into a > Set> - and then, if the flag set you are about to create is > already contained in the set, you return it, otherwise you add the new > flag combo into the set. This means taking a slight hit on flag creation > (i.e. the new flag combo will need to be looked up in the shared set). > But it has the advantage of not needing to 'guess' which flag combos are > likely - and, since all sets created in this way will be immutable, it > would provide more uniformity - i.e. to chain flags together you have to > go through the Flag helper methods. > > Where does this leave us? I think with these optimizations the memory > footprint should be relatively contained - we are essentially trading a > 64-bit value (long flag) with a 64 bit pointer which might or might not > point to a fresh new object (if not, no extra cost). Of course this all > needed to be validated with some real world profiling/JMH benchmark, but > seems like a direction worth exploring. > > Thoughts? Three years ago, i've done the opposite transformation Set to long for a compiler far less complex than javac, the main issues when you have a Set are: - the JumboEnumSet (more than 64 flags) is quite slow because it uses an array internally, - it's very easy to have more than two representations for a callsite, and at that point your flag check code goes megamorphic. - even using an interface makes the code slow because an invokevirtual means there is a check in the assembly code, each additional checks in a tight loop is visible in term of perf. The last two points can be easily hidden when doing JMH tests. For dealing with the fact that there are more than 64 flags, i've used 2 longs, one for the public API, one for the internal code, but since another developer change the code to go back to use a 64 bits by reusing the bits (because of the memory consumption). What you are describing is the kind of perfect use case for a value type. So we know the perfect solution, it's just that you can not using it yet. > > Maurizio R?mi > > [1] - > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012470.html > [2] - > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l314 > [3] - > http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l320 From maurizio.cimadamore at oracle.com Wed Sep 26 15:34:14 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 26 Sep 2018 16:34:14 +0100 Subject: on javac flags In-Reply-To: <1713932138.396282.1537974741727.JavaMail.zimbra@u-pem.fr> References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> <1713932138.396282.1537974741727.JavaMail.zimbra@u-pem.fr> Message-ID: <6f4efb15-ebd2-6a46-9815-11adc0ce46d9@oracle.com> > Three years ago, i've done the opposite transformation Set to long for a compiler far less complex than javac, > the main issues when you have a Set are: > - the JumboEnumSet (more than 64 flags) is quite slow because it uses an array internally, > - it's very easy to have more than two representations for a callsite, and at that point your flag check code goes megamorphic. > - even using an interface makes the code slow because an invokevirtual means there is a check in the assembly code, each additional checks in a tight loop is visible in term of perf. > > The last two points can be easily hidden when doing JMH tests. > > For dealing with the fact that there are more than 64 flags, i've used 2 longs, one for the public API, one for the internal code, but since another developer change the code to go back to use a 64 bits by reusing the bits (because of the memory consumption). > > What you are describing is the kind of perfect use case for a value type. So we know the perfect solution, it's just that you can not using it yet. +1 on that front. And thanks for sharing your thoughts. As I said in a previous email, these are some ideas that we discussed internally but never committed to too seriously (in part for the reasons you describe). Regarding your performance notes, for (1) I think I'm not too worried about JumboEnumSet being slow. Of course (2) is a much bigger problem, thanks for reminding me of that. As for (3) I would suspect that in case of a tight loop the JIT should be able to hoist the check out of the loop - but maybe you refer to cases that are not 'hot' enough to trigger the JIT (which I agree are problematic, given a compiler rarely takes advantage of advanced JIT opts, as its too short lived). Maurizio > >> Maurizio > R?mi > >> [1] - >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012470.html >> [2] - >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l314 >> [3] - >> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l320 From maurizio.cimadamore at oracle.com Wed Sep 26 15:36:36 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 26 Sep 2018 16:36:36 +0100 Subject: RFR: JDK-8211102: Crash with -XDfind=lambda and -source 7 In-Reply-To: <5BAB46BE.3060906@oracle.com> References: <5BAA565C.1090108@oracle.com> <5BAA86DD.9010800@oracle.com> <7338fe5b-0e40-7e7f-c057-fe87bafbedb6@oracle.com> <5BAB46BE.3060906@oracle.com> Message-ID: Looks good. Thanks. Maurizio On 26/09/18 09:43, Jan Lahoda wrote: > On 26.9.2018 00:38, Maurizio Cimadamore wrote: >> >> >> On 25/09/18 20:05, Jan Lahoda wrote: >>> On 25.9.2018 19:16, Maurizio Cimadamore wrote: >>>> What you say makes sense, but the tests do not reflect what you say in >>>> the email. >>>> >>>> First, none of the test seems to use -XDfind=lambda. That means >>>> that no >>>> test is actually checking that the condition described in 8211102 does >>>> not occur? >>>> >>>> Secondly, it seems like the issue you are describing with conditional >>>> happens w/ or w/o analyzer - e.g. this looks like a standalone issue, >>>> and using the analyzer bug to fix it seems misleading (similarly >>>> for the >>>> 3rd issue fixed by this patch). >>>> >>>> So, while I don't dispute any of the changes in the patch, I'm having >>>> hard time following which is which - can you please clarify? >>> >>> The Analyzer testcase is what I've found first, and it is probably the >>> most serious thing, as javac crashes on valid source (albeit with >>> somewhat non-standard options). While looking at the reasons, I >>> realized that a) the lambda analyzer runs with -source 7 (which is >>> suspicious), and also b) that there is a crash that can be reproduced >>> without using analyzer (which is also the root cause for the analyzer >>> crash). So I went to fix both of these. The third problem, I've ran >>> into it while trying to find a testcase without analyzer, so I went to >>> fix it as well. >>> >>> I can split the patch (and bug) into three parts if desired. >> I'm ok with keeping them together, but I'd add a test with the -XDfind >> option, just in case. E.g. something that makes sure that we don't >> generate 'finder' messages for features that are not supported in a >> given source level. > > Sure, updated webrev: > http://cr.openjdk.java.net/~jlahoda/8211102/webrev.01/ > > Thanks, > ??? Jan > >> >> Maurizio >> >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> Maurizio >>>> >>>> >>>> On 25/09/18 16:38, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I'd like to ask for a review of changes that relate to code like: >>>>> --- >>>>> import java.util.*; >>>>> >>>>> public class AnalyzerBug { >>>>> ??? private void t(boolean b) { >>>>> ??????? (b ? Collections.emptyList() : new Iterable() { >>>>> public >>>>> Iterator iterator() { return null; } }).toString(); >>>>> ??? } >>>>> } >>>>> --- >>>>> >>>>> When this code is compiled like: >>>>> $ javac -XDfind=lambda -source 7 /tmp/AnalyzerBug.java >>>>> >>>>> javac crashes in Analyzer. There are two immediate causes for the >>>>> crash: >>>>> a) when AnalyzerModes are read form -XDfind, if an analyzer key is >>>>> explicitly mentioned there, the source level is not checked, and the >>>>> analyzer is enabled. So, in the case above, the analyzer with try to >>>>> convert the Iterable to a lambda and process the source, >>>>> despite the -source 7. I suspect this is not intended, so >>>>> proposing to >>>>> always disable an analyzer if it does not have a meaning in the >>>>> current source level. >>>>> >>>>> b) if there's a lambda in a standalone conditional (i.e. without a >>>>> target), in JDK 12 we try to attribute it anyway, but as a result, >>>>> the >>>>> type of the lambda will be the recovery type. And the computation of >>>>> the type of the standalone conditional chokes on that, as the >>>>> recovery >>>>> type does not have a Symbol. So proposing to make the lambda's >>>>> type an >>>>> erroneous type in such cases (as was before 12), while still >>>>> attributing it. >>>>> >>>>> There's also related problem, when (very broken) code like this: >>>>> ??????? int j = i instanceof ArrayList ? (ArrayList) i : >>>>> () -> >>>>> { return null; }; >>>>> >>>>> is attributed, visitLambda will keep JCFunctionalExpression.target >>>>> unfilled, which seems fine as >>>>> JCFunctionalExpression.getDescriptorType >>>>> is prepared for that (and there indeed is no reasonable). But >>>>> Attr.postAttr will fill it with unknownType, and then calls to >>>>> getDescriptorType (e.g. from Flow.FlowAnalyzer.visitLambda) lead to >>>>> FunctionDescriptorLookupError. Seems it might be better to keep the >>>>> field unfilled, which is what the proposed patch is doing. (This is >>>>> somewhat less important, as I am not aware of a way to reproduce this >>>>> without -XDshould-stop.at=FLOW.) >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8211102 >>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8211102/webrev.00/ >>>>> >>>>> Any feedback is welcome! >>>>> >>>>> Thanks, >>>>> ??? Jan >>>> >> From jonathan.gibbons at oracle.com Wed Sep 26 19:14:26 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Sep 2018 12:14:26 -0700 Subject: RFR: JDK-8209963: source file mode for JVM should provide a hook to locate the source file Message-ID: <5BABDA92.3000500@oracle.com> Please review a 1-line patch, and test, for source-file mode, to make the name of the source file available in a system property. This patch is the last in the recent series of minor enhancements to the source-file launcher feature. JBS: https://bugs.openjdk.java.net/browse/JDK-8209963 CSR:https://bugs.openjdk.java.net/browse/JDK-8210877 Webrev: http://cr.openjdk.java.net/~jjg/8209963/webrev.00/index.html -- Jon From bsrbnd at gmail.com Wed Sep 26 19:26:15 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 26 Sep 2018 21:26:15 +0200 Subject: on javac flags In-Reply-To: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> Message-ID: Hi Maurizio, On Wed, 26 Sep 2018 at 16:17, Maurizio Cimadamore wrote: > > Hi, > In javac we have a Flags class which is used to define a list of all the > flags that are used, both internally (i.e. javac private flags) and > externally (i.e ACC_ flags). The assumption is that external flags are > 16-bit wide, while internal flags are all values above 2^16 (_which can > fit in a long_). > > There are several issues with the current handling of flags: > [...] > * checking presence/absence of flags is very tedious; we have many many > occurrences (600+) of C-like code like: > > if ((sym.flags() & STATIC) == 0 && ... > > or > > (sym.flags() & (ABSTRACT|DEFAULT|PRIVATE)) == ABSTRACT) { ... } > > [...] > Where does this leave us? I think with these optimizations the memory > footprint should be relatively contained - we are essentially trading a > 64-bit value (long flag) with a 64 bit pointer which might or might not > point to a fresh new object (if not, no extra cost). Of course this all > needed to be validated with some real world profiling/JMH benchmark, but > seems like a direction worth exploring. > > Thoughts? I'm afraid that if (!sym.flags().contains(Flag.STATIC) && ... would be also tedious, somewhat slow and probably expensive in term of memory usage... I guess I'd be more for something like: $ cat OnFlags.java class OnFlags { static enum Flag { PUBLIC(0, 0x1), PRIVATE(1, 0x2), INTERNAL(2, 0x0); int index; int mask; // maybe 'short' would be enough Flag(int index, int mask) { this.index = index; this.mask = mask; } } static class Symbol { boolean[] flags = new boolean[Flag.values().length]; } public static void main(String... args) { var sym = new Symbol(); sym.flags[Flag.PUBLIC.index] = true; sym.flags[Flag.INTERNAL.index] = true; int jvmFlags = 0; for (Flag f: Flag.values()) if (sym.flags[f.index]) jvmFlags |= f.mask; for (Flag f: Flag.values()) System.out.println(f + ": " + sym.flags[f.index]); System.out.println("jvm flags " + jvmFlags); } } No difference between corresponding internal and external flags, so no mapping would be necessary. Testing a flag would be as fast as simple without much extra memory cost: if (!sym.flags[Flag.STATIC.index] && ... Computing the jvm external flag would be also straightforward: int jvmFlags = 0; for (Flag f: Flag.values()) if (sym.flags[f.index]) jvmFlags |= f.mask; Opinions? Bernard > > Maurizio From maurizio.cimadamore at oracle.com Wed Sep 26 20:06:09 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 26 Sep 2018 21:06:09 +0100 Subject: on javac flags In-Reply-To: References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> Message-ID: <2331f0c6-686f-512d-3f4c-53c169ca0e96@oracle.com> Hi Bernard, your solution is clever, but now a symbol has an array of N elements - which makes it completely unfeasible from a memory footprint perspective. Although maybe the core of what you are suggesting is - just use a custom data structure, e.g. something like an immutable bitset, so that we can share common combinations, etc. Maurizio On 26/09/18 20:26, B. Blaser wrote: > Hi Maurizio, > > On Wed, 26 Sep 2018 at 16:17, Maurizio Cimadamore > wrote: >> Hi, >> In javac we have a Flags class which is used to define a list of all the >> flags that are used, both internally (i.e. javac private flags) and >> externally (i.e ACC_ flags). The assumption is that external flags are >> 16-bit wide, while internal flags are all values above 2^16 (_which can >> fit in a long_). >> >> There are several issues with the current handling of flags: >> [...] >> * checking presence/absence of flags is very tedious; we have many many >> occurrences (600+) of C-like code like: >> >> if ((sym.flags() & STATIC) == 0 && ... >> >> or >> >> (sym.flags() & (ABSTRACT|DEFAULT|PRIVATE)) == ABSTRACT) { ... } >> >> [...] >> Where does this leave us? I think with these optimizations the memory >> footprint should be relatively contained - we are essentially trading a >> 64-bit value (long flag) with a 64 bit pointer which might or might not >> point to a fresh new object (if not, no extra cost). Of course this all >> needed to be validated with some real world profiling/JMH benchmark, but >> seems like a direction worth exploring. >> >> Thoughts? > I'm afraid that > > if (!sym.flags().contains(Flag.STATIC) && ... > > would be also tedious, somewhat slow and probably expensive in term of > memory usage... > > I guess I'd be more for something like: > > $ cat OnFlags.java > class OnFlags { > static enum Flag { > PUBLIC(0, 0x1), PRIVATE(1, 0x2), INTERNAL(2, 0x0); > > int index; > int mask; // maybe 'short' would be enough > > Flag(int index, int mask) { > this.index = index; > this.mask = mask; > } > } > > static class Symbol { > boolean[] flags = new boolean[Flag.values().length]; > } > > public static void main(String... args) { > var sym = new Symbol(); > sym.flags[Flag.PUBLIC.index] = true; > sym.flags[Flag.INTERNAL.index] = true; > > int jvmFlags = 0; > for (Flag f: Flag.values()) > if (sym.flags[f.index]) > jvmFlags |= f.mask; > > for (Flag f: Flag.values()) > System.out.println(f + ": " + sym.flags[f.index]); > > System.out.println("jvm flags " + jvmFlags); > } > } > > No difference between corresponding internal and external flags, so no > mapping would be necessary. > > Testing a flag would be as fast as simple without much extra memory cost: > > if (!sym.flags[Flag.STATIC.index] && ... > > Computing the jvm external flag would be also straightforward: > > int jvmFlags = 0; > for (Flag f: Flag.values()) > if (sym.flags[f.index]) > jvmFlags |= f.mask; > > Opinions? > > Bernard > >> Maurizio From jonathan.gibbons at oracle.com Wed Sep 26 20:15:10 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Sep 2018 13:15:10 -0700 Subject: on javac flags In-Reply-To: <2331f0c6-686f-512d-3f4c-53c169ca0e96@oracle.com> References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> <2331f0c6-686f-512d-3f4c-53c169ca0e96@oracle.com> Message-ID: <5BABE8CE.5000208@oracle.com> Maurizio, I think it would also be good to separate the storage from the API, to provide concise usage within the javac codebase. For example, sym.hasFlag(Flag.STATIC) sym.setFlag(Flag.PUBLIC) etc as compared to (sym.flags() & STATIC) != 0 sym.flags |= STATIC; If you get the API right, maybe as a first step, it would then be easier to tweak the implementation later on as needed. -- Jon On 09/26/2018 01:06 PM, Maurizio Cimadamore wrote: > Hi Bernard, > your solution is clever, but now a symbol has an array of N elements - > which makes it completely unfeasible from a memory footprint > perspective. Although maybe the core of what you are suggesting is - > just use a custom data structure, e.g. something like an immutable > bitset, so that we can share common combinations, etc. > > Maurizio > > On 26/09/18 20:26, B. Blaser wrote: >> Hi Maurizio, >> >> On Wed, 26 Sep 2018 at 16:17, Maurizio Cimadamore >> wrote: >>> Hi, >>> In javac we have a Flags class which is used to define a list of all >>> the >>> flags that are used, both internally (i.e. javac private flags) and >>> externally (i.e ACC_ flags). The assumption is that external flags are >>> 16-bit wide, while internal flags are all values above 2^16 (_which can >>> fit in a long_). >>> >>> There are several issues with the current handling of flags: >>> [...] >>> * checking presence/absence of flags is very tedious; we have many many >>> occurrences (600+) of C-like code like: >>> >>> if ((sym.flags() & STATIC) == 0 && ... >>> >>> or >>> >>> (sym.flags() & (ABSTRACT|DEFAULT|PRIVATE)) == ABSTRACT) { ... } >>> >>> [...] >>> Where does this leave us? I think with these optimizations the memory >>> footprint should be relatively contained - we are essentially trading a >>> 64-bit value (long flag) with a 64 bit pointer which might or might not >>> point to a fresh new object (if not, no extra cost). Of course this all >>> needed to be validated with some real world profiling/JMH benchmark, >>> but >>> seems like a direction worth exploring. >>> >>> Thoughts? >> I'm afraid that >> >> if (!sym.flags().contains(Flag.STATIC) && ... >> >> would be also tedious, somewhat slow and probably expensive in term of >> memory usage... >> >> I guess I'd be more for something like: >> >> $ cat OnFlags.java >> class OnFlags { >> static enum Flag { >> PUBLIC(0, 0x1), PRIVATE(1, 0x2), INTERNAL(2, 0x0); >> >> int index; >> int mask; // maybe 'short' would be enough >> >> Flag(int index, int mask) { >> this.index = index; >> this.mask = mask; >> } >> } >> >> static class Symbol { >> boolean[] flags = new boolean[Flag.values().length]; >> } >> >> public static void main(String... args) { >> var sym = new Symbol(); >> sym.flags[Flag.PUBLIC.index] = true; >> sym.flags[Flag.INTERNAL.index] = true; >> >> int jvmFlags = 0; >> for (Flag f: Flag.values()) >> if (sym.flags[f.index]) >> jvmFlags |= f.mask; >> >> for (Flag f: Flag.values()) >> System.out.println(f + ": " + sym.flags[f.index]); >> >> System.out.println("jvm flags " + jvmFlags); >> } >> } >> >> No difference between corresponding internal and external flags, so no >> mapping would be necessary. >> >> Testing a flag would be as fast as simple without much extra memory >> cost: >> >> if (!sym.flags[Flag.STATIC.index] && ... >> >> Computing the jvm external flag would be also straightforward: >> >> int jvmFlags = 0; >> for (Flag f: Flag.values()) >> if (sym.flags[f.index]) >> jvmFlags |= f.mask; >> >> Opinions? >> >> Bernard >> >>> Maurizio > From jonathan.gibbons at oracle.com Wed Sep 26 21:18:37 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Sep 2018 14:18:37 -0700 Subject: [XXS] RFR tier1 testbug JDK-8211180: SourceLauncherTest.java fails in JDK12 CI on Win* Message-ID: <5BABF7AD.2040606@oracle.com> Please review a small urgent fix for a tier1 testbug issue. It is a perennial problem, comparing golden text on Windows. This time, with that in mind, I was too clever by half, and proactively converted platform newlines in the generated output to \n, not realizing that the method being used for the comparison was doing the opposite, and converting \n in the golden string to platform newlines! The fix is just to avoid converting newlines to \n. $ hg diff diff -r 76a3e8be46e6 test/langtools/tools/javac/launcher/SourceLauncherTest.java --- a/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed Sep 26 12:47:38 2018 -0700 +++ b/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed Sep 26 14:16:45 2018 -0700 @@ -244,7 +244,7 @@ .className(sourceFile.toString()) .run(Task.Expect.SUCCESS) .getOutput(Task.OutputKind.STDOUT); - checkEqual("stdout", log.trim().replace(tb.lineSeparator, "\n"), + checkEqual("stdout", log.trim(), "user.dir=" + System.getProperty("user.dir") + "\n" + "exception: java.security.AccessControlException: " + "access denied (\"java.util.PropertyPermission\" \"user.dir\" \"write\")"); JBS: https://bugs.openjdk.java.net/browse/JDK-8211180 Webrev: http://cr.openjdk.java.net/~jjg/8211180/webrev.00/ -- Jon From joe.darcy at oracle.com Wed Sep 26 21:48:54 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 26 Sep 2018 14:48:54 -0700 Subject: [XXS] RFR tier1 testbug JDK-8211180: SourceLauncherTest.java fails in JDK12 CI on Win* In-Reply-To: <5BABF7AD.2040606@oracle.com> References: <5BABF7AD.2040606@oracle.com> Message-ID: +1 -Joe On 9/26/2018 2:18 PM, Jonathan Gibbons wrote: > Please review a small urgent fix for a tier1 testbug issue. > > It is a perennial problem, comparing golden text on Windows. This > time, with that in mind, I was too clever by half, and proactively > converted platform newlines in the generated output to \n, not > realizing that the method being used for the comparison was doing the > opposite, and converting \n in the golden string to platform newlines! > > The fix is just to avoid converting newlines to \n. > > $ hg diff > diff -r 76a3e8be46e6 > test/langtools/tools/javac/launcher/SourceLauncherTest.java > --- a/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed > Sep 26 12:47:38 2018 -0700 > +++ b/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed > Sep 26 14:16:45 2018 -0700 > @@ -244,7 +244,7 @@ > ???????????????? .className(sourceFile.toString()) > ???????????????? .run(Task.Expect.SUCCESS) > ???????????????? .getOutput(Task.OutputKind.STDOUT); > -??????? checkEqual("stdout", log.trim().replace(tb.lineSeparator, "\n"), > +??????? checkEqual("stdout", log.trim(), > ???????????????? "user.dir=" + System.getProperty("user.dir") + "\n" + > ???????????????? "exception: java.security.AccessControlException: " + > ???????????????????? "access denied (\"java.util.PropertyPermission\" > \"user.dir\" \"write\")"); > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211180 > Webrev: http://cr.openjdk.java.net/~jjg/8211180/webrev.00/ > > -- Jon From mandy.chung at oracle.com Wed Sep 26 21:49:31 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 26 Sep 2018 14:49:31 -0700 Subject: [XXS] RFR tier1 testbug JDK-8211180: SourceLauncherTest.java fails in JDK12 CI on Win* In-Reply-To: <5BABF7AD.2040606@oracle.com> References: <5BABF7AD.2040606@oracle.com> Message-ID: <208b3333-b034-6f2e-20a0-f57fa7311996@oracle.com> +1 Mandy On 9/26/18 2:18 PM, Jonathan Gibbons wrote: > Please review a small urgent fix for a tier1 testbug issue. > > It is a perennial problem, comparing golden text on Windows. This > time, with that in mind, I was too clever by half, and proactively > converted platform newlines in the generated output to \n, not > realizing that the method being used for the comparison was doing the > opposite, and converting \n in the golden string to platform newlines! > > The fix is just to avoid converting newlines to \n. > > $ hg diff > diff -r 76a3e8be46e6 > test/langtools/tools/javac/launcher/SourceLauncherTest.java > --- a/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed > Sep 26 12:47:38 2018 -0700 > +++ b/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed > Sep 26 14:16:45 2018 -0700 > @@ -244,7 +244,7 @@ > ???????????????? .className(sourceFile.toString()) > ???????????????? .run(Task.Expect.SUCCESS) > ???????????????? .getOutput(Task.OutputKind.STDOUT); > -??????? checkEqual("stdout", log.trim().replace(tb.lineSeparator, "\n"), > +??????? checkEqual("stdout", log.trim(), > ???????????????? "user.dir=" + System.getProperty("user.dir") + "\n" + > ???????????????? "exception: java.security.AccessControlException: " + > ???????????????????? "access denied (\"java.util.PropertyPermission\" > \"user.dir\" \"write\")"); > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211180 > Webrev: http://cr.openjdk.java.net/~jjg/8211180/webrev.00/ > > -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Sep 26 21:53:08 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Sep 2018 14:53:08 -0700 Subject: [XXS] RFR tier1 testbug JDK-8211180: SourceLauncherTest.java fails in JDK12 CI on Win* In-Reply-To: References: <5BABF7AD.2040606@oracle.com> Message-ID: <5295ce7d-2dc0-19f8-c422-71378b345603@oracle.com> Thanks On 9/26/18 2:48 PM, joe darcy wrote: > +1 > > -Joe > > > On 9/26/2018 2:18 PM, Jonathan Gibbons wrote: >> Please review a small urgent fix for a tier1 testbug issue. >> >> It is a perennial problem, comparing golden text on Windows. This >> time, with that in mind, I was too clever by half, and proactively >> converted platform newlines in the generated output to \n, not >> realizing that the method being used for the comparison was doing the >> opposite, and converting \n in the golden string to platform newlines! >> >> The fix is just to avoid converting newlines to \n. >> >> $ hg diff >> diff -r 76a3e8be46e6 >> test/langtools/tools/javac/launcher/SourceLauncherTest.java >> --- a/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed >> Sep 26 12:47:38 2018 -0700 >> +++ b/test/langtools/tools/javac/launcher/SourceLauncherTest.java Wed >> Sep 26 14:16:45 2018 -0700 >> @@ -244,7 +244,7 @@ >> ???????????????? .className(sourceFile.toString()) >> ???????????????? .run(Task.Expect.SUCCESS) >> ???????????????? .getOutput(Task.OutputKind.STDOUT); >> -??????? checkEqual("stdout", log.trim().replace(tb.lineSeparator, >> "\n"), >> +??????? checkEqual("stdout", log.trim(), >> ???????????????? "user.dir=" + System.getProperty("user.dir") + "\n" + >> ???????????????? "exception: java.security.AccessControlException: " + >> ???????????????????? "access denied (\"java.util.PropertyPermission\" >> \"user.dir\" \"write\")"); >> >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8211180 >> Webrev: http://cr.openjdk.java.net/~jjg/8211180/webrev.00/ >> >> -- Jon > From joe.darcy at oracle.com Wed Sep 26 23:11:59 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 26 Sep 2018 16:11:59 -0700 Subject: RFR: JDK-8209963: source file mode for JVM should provide a hook to locate the source file In-Reply-To: <5BABDA92.3000500@oracle.com> References: <5BABDA92.3000500@oracle.com> Message-ID: <5BAC123F.4070502@oracle.com> Hi Jon, Looks fine; cheers, -Joe On 9/26/2018 12:14 PM, Jonathan Gibbons wrote: > Please review a 1-line patch, and test, for source-file mode, > to make the name of the source file available in a system property. > > This patch is the last in the recent series of minor enhancements to > the source-file launcher feature. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209963 > CSR:https://bugs.openjdk.java.net/browse/JDK-8210877 > Webrev: http://cr.openjdk.java.net/~jjg/8209963/webrev.00/index.html > > -- Jon From mandy.chung at oracle.com Wed Sep 26 23:52:02 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 26 Sep 2018 16:52:02 -0700 Subject: RFR: JDK-8209963: source file mode for JVM should provide a hook to locate the source file In-Reply-To: <5BABDA92.3000500@oracle.com> References: <5BABDA92.3000500@oracle.com> Message-ID: <33714710-a14e-0477-b768-bd36d78c57e6@oracle.com> On 9/26/18 12:14 PM, Jonathan Gibbons wrote: > Please review a 1-line patch, and test, for source-file mode, > to make the name of the source file available in a system property. > > This patch is the last in the recent series of minor enhancements to > the source-file launcher feature. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209963 > CSR:https://bugs.openjdk.java.net/browse/JDK-8210877 > Webrev: http://cr.openjdk.java.net/~jjg/8209963/webrev.00/index.html This change looks fine. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu Sep 27 04:25:11 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 26 Sep 2018 21:25:11 -0700 Subject: on javac flags In-Reply-To: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> Message-ID: <8088876F-5DC1-4868-84A6-51138A4A56CE@oracle.com> Having two different mechanisms for the two sets of flags doesn?t sound great either. However, if the problem is that we?re worried about overflowing RegularEnumSet, we can have a FlagSet class that implements Set that uses two longs instead of an array. Then we can put the public and private flags into one enum, and wrap a flag-spec specific API around all of it. Then when we have values, we can turn it into a value. > On Sep 26, 2018, at 7:16 AM, Maurizio Cimadamore wrote: > > Hi, > In javac we have a Flags class which is used to define a list of all the flags that are used, both internally (i.e. javac private flags) and externally (i.e ACC_ flags). The assumption is that external flags are 16-bit wide, while internal flags are all values above 2^16 (_which can fit in a long_). > > There are several issues with the current handling of flags: > > * since both internal and external flags are mapped onto the same abstraction (a numeric constant), it becomes confusing to marshal/unmarshal public flags to private flags. For instance, the internal BRIDGE flag must be mapped to the public ACC_BRIDGE flag when we are about to write a classfile - and the reverse operation must be performed when we read from the classfile (if we used ACC_BRIDGE internally javac would think that the method is VOLATILE). For the records - there are 4 separate methods for mapping public flags onto private and viceversa (spread between ClassReader and ClassWriter). > > * The code for checking well-formedness of flags has become very convoluted. This is caused by the fact that this code used to work on the assumption that the well-formedness check only needed to work on public flags (i.e. X < 2^16). But when we added default methods, this code needed to be upgraded to work on any flag (even internal ones - such as DEFAULT, an internal flag), and that turned the code even more obscure. > > * checking presence/absence of flags is very tedious; we have many many occurrences (600+) of C-like code like: > > if ((sym.flags() & STATIC) == 0 && ... > > or > > (sym.flags() & (ABSTRACT|DEFAULT|PRIVATE)) == ABSTRACT) { ... } > > etc. > > * this is kind of related to the point above - since checking flags is so darn unhandy - helper methods popped up; i.e. Symbol.isStatic will essentially do (Symbol.flags() & STATIC) != 0 - etc. So there are more ways to get to the same answer - and of the codebase doesn't adhere to any strict guideline on whether to use one way or the other (although generally speaking, the low level variant is preferred when symbol completion needs to be avoided). > > * last and not least - we are running out of internal flags (we only have 6 available slots in jdk/jdk [2]). While we can be more parsimonious w.r.t. our internal flags (and indeed we have, see [3]), I think - and garbage collect the unused ones over times, I also think that the very nature of an internal flag is such that it can be used to describe something very specific (i.e. a compiler invariant - such as UNCOMPLETED or ACYCLIC) - and there are many many occasions where we'd like to be able to do so; so while 16 bits might be enough for public flags (cough), I don't think that 64 bits are necessarily adequate for representing the internal flags space. I'd be wary of starting to play the same dance we do for public flags - e.g. UNCOMPLETED and ACYCLIC can never occur on the same symbols, so let's reuse the same bit for both. > > * Duplication with the Flags.Flag enum; each flag constant is represented as an enum, as sometimes client code need to access flags that way; needless to say, over time this has led to inconsistencies - the last of which has been described in this thread [1] > > All this got me thinking; it seems to me that most of the problems above are caused by the fact that we want to shoehorn private flags onto the same bits we use for public flags. So, what if we used different abstractions for public vs private flags? More specifically, we could keep using ints for mapping well-known public flag values (whose value is specified in the JVMS after all). But we could use something fancier like an EnumSet for internal flags. What does this mean? > > First of all, Symbol would no longer have a 'long' field for flags - it will have an Set, where Flag is an enum (stay with me on this - if you are concerned about memory footprint, please note that I'll address that later on). This simple change of representation has already many advantages: > > * as Flag is an enum, the number of internal flags is virtually unbounded. > * since we have a Set, testing for flag presence/absence becomes much nicer (and if the underlying set is an EnumSet, we get good performances too!) > * we could centralize the logic for mapping internal flags to external ones onto the Flag itself! This means that each private flag would know how to map itself onto an external one (and viceversa) - and ClassReader/Writer will simply take advantage of that. > > Ok, the obvious catch is that what used to be a 'value' (a long) is now a reference pointing into the heap. So, with a naive implementation, we would have one more heap-allocated object per Symbol. This is of course not a very desirable property. Can we improve? I think we can - for instance, the Flag enum can define immutable enum sets for very common flags combos: > > public static > public > protected > public abstract > > and so forth. Since these flag masks are shared, they will need to be made immutable (Collections.immutableSet) to make sure that nobody will try to add stuff to them. Flags could also define a bunch of methods to union/intersect flags, so that you get a new EnumSet with the right bits (this overcomes the problem that some flag sets are immutable). > > At the same time, Flags could also define a factory method which takes a bunch of Modifiers (as read by the parser) and turns them into an internal flag set - the factory would check for common idioms and return the shared objects where possible. > > Another, even more extreme way, would be to pool all flags into a Set> - and then, if the flag set you are about to create is already contained in the set, you return it, otherwise you add the new flag combo into the set. This means taking a slight hit on flag creation (i.e. the new flag combo will need to be looked up in the shared set). But it has the advantage of not needing to 'guess' which flag combos are likely - and, since all sets created in this way will be immutable, it would provide more uniformity - i.e. to chain flags together you have to go through the Flag helper methods. > > Where does this leave us? I think with these optimizations the memory footprint should be relatively contained - we are essentially trading a 64-bit value (long flag) with a 64 bit pointer which might or might not point to a fresh new object (if not, no extra cost). Of course this all needed to be validated with some real world profiling/JMH benchmark, but seems like a direction worth exploring. > > Thoughts? > > Maurizio > > [1] - http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012470.html > [2] - http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l314 > [3] - http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java#l320 > From bsrbnd at gmail.com Thu Sep 27 10:00:22 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 27 Sep 2018 12:00:22 +0200 Subject: on javac flags In-Reply-To: <2331f0c6-686f-512d-3f4c-53c169ca0e96@oracle.com> References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> <2331f0c6-686f-512d-3f4c-53c169ca0e96@oracle.com> Message-ID: On Wed, 26 Sep 2018 at 22:06, Maurizio Cimadamore wrote: > > Hi Bernard, > your solution is clever, but now a symbol has an array of N elements - > which makes it completely unfeasible from a memory footprint > perspective. Although maybe the core of what you are suggesting is - > just use a custom data structure, e.g. something like an immutable > bitset, so that we can share common combinations, etc. Yes, a custom BitSet or FlagSet was the idea behind this and I guess Brian is of the same opinion. I've not verified how primitive boolean arrays are implemented, but do we use a 64-bit word for each boolean value? If so, maybe something might be improved here... but several long values, as Brian/R?mi suggest, would be a good solution. And note that EnumSet probably also uses an array of references internally (?) or something equivalent. But, as Jon said, first specifying the API would probably help choosing the right implementation. Bernard > > Maurizio From bsrbnd at gmail.com Sun Sep 30 14:23:43 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 30 Sep 2018 16:23:43 +0200 Subject: on javac flags In-Reply-To: References: <3a669e77-7ff7-9908-e6da-c8d8e62a3fa6@oracle.com> <2331f0c6-686f-512d-3f4c-53c169ca0e96@oracle.com> Message-ID: Hi, On Thu, 27 Sep 2018 at 12:00, B. Blaser wrote: > > On Wed, 26 Sep 2018 at 22:06, Maurizio Cimadamore > wrote: > > > > Hi Bernard, > > your solution is clever, but now a symbol has an array of N elements - > > which makes it completely unfeasible from a memory footprint > > perspective. Although maybe the core of what you are suggesting is - > > just use a custom data structure, e.g. something like an immutable > > bitset, so that we can share common combinations, etc. > > Yes, a custom BitSet or FlagSet was the idea behind this and I guess > Brian is of the same opinion. > I've not verified how primitive boolean arrays are implemented, but do > we use a 64-bit word for each boolean value? > If so, maybe something might be improved here... but several long > values, as Brian/R?mi suggest, would be a good solution. > And note that EnumSet probably also uses an array of references > internally (?) or something equivalent. > But, as Jon said, first specifying the API would probably help > choosing the right implementation. > > Bernard > > > > > Maurizio I did a quick investigation and comparison between boolean[] vs BitSet vs EnumSet: * boolean[] seems to use one byte per boolean which isn't as bad, see [1] * BitSet uses several long values which is good, see [2] * EnumSet (RegularEnumSet/JumboEnumSet) uses several long values too [3] and a shared reference array [4] which seems to be perfect. So I would lean towards EnumSet as you initially suggested unless you prefer a custom BitSet for some particular reasons? Bernard [1] https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.baload http://hg.openjdk.java.net/jdk/jdk/file/540c1a848dd8/src/hotspot/cpu/x86/templateTable_x86.cpp#l1182 [2] http://hg.openjdk.java.net/jdk/jdk/file/540c1a848dd8/src/java.base/share/classes/java/util/BitSet.java#l68 [3] http://hg.openjdk.java.net/jdk/jdk/file/540c1a848dd8/src/java.base/share/classes/java/util/JumboEnumSet.java#l40 [4] http://hg.openjdk.java.net/jdk/jdk/file/540c1a848dd8/src/java.base/share/classes/java/util/EnumSet.java#l402