From jan.lahoda at oracle.com Thu Mar 1 16:05:01 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 1 Mar 2018 17:05:01 +0100 Subject: RFR : JDK-8198552: Multiple javac plugins do not work at the same time. In-Reply-To: References: <5A8FFF30.7010902@oracle.com> Message-ID: <5A9824AD.9090102@oracle.com> On 23.2.2018 22:14, Vicente Romero wrote: > I think that for completeness we should test the case when the plugin(s) > are defined inside a module, Thanks Vicente, an updated webrev which tests also Plugins in modules is here: http://cr.openjdk.java.net/~jlahoda/8198552/webrev.01/ Jan > > Thanks, > Vicente > > On 02/23/2018 06:46 AM, Jan Lahoda wrote: >> Hi, >> >> When specifying multiple javac plugins using -Xplugin:, only one of >> them is run. The primary reason is that an incorrect (originally, >> there was only this one) method is overridden in Option.PLUGIN. I've >> found two more options that have the same problem ("-Xdoclint:" and >> "-Xdoclint/packages:"), I tried to fix those as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8198552 >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8198552/webrev.00/ >> >> How does this look? >> >> Thanks, >> Jan > From vicente.romero at oracle.com Thu Mar 1 20:06:47 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 1 Mar 2018 15:06:47 -0500 Subject: RFR : JDK-8198552: Multiple javac plugins do not work at the same time. In-Reply-To: <5A9824AD.9090102@oracle.com> References: <5A8FFF30.7010902@oracle.com> <5A9824AD.9090102@oracle.com> Message-ID: <5424ebc6-a4c6-caa9-e2b8-94d0ab8577d0@oracle.com> looks good, nice work, Vicente On 03/01/2018 11:05 AM, Jan Lahoda wrote: > On 23.2.2018 22:14, Vicente Romero wrote: >> I think that for completeness we should test the case when the plugin(s) >> are defined inside a module, > > Thanks Vicente, an updated webrev which tests also Plugins in modules > is here: > http://cr.openjdk.java.net/~jlahoda/8198552/webrev.01/ > > Jan > >> >> Thanks, >> Vicente >> >> On 02/23/2018 06:46 AM, Jan Lahoda wrote: >>> Hi, >>> >>> When specifying multiple javac plugins using -Xplugin:, only one of >>> them is run. The primary reason is that an incorrect (originally, >>> there was only this one) method is overridden in Option.PLUGIN. I've >>> found two more options that have the same problem ("-Xdoclint:" and >>> "-Xdoclint/packages:"), I tried to fix those as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198552 >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8198552/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From jonathan.gibbons at oracle.com Thu Mar 1 23:59:30 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 01 Mar 2018 15:59:30 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A7CDACB.50103@oracle.com> References: <5A7CDACB.50103@oracle.com> Message-ID: <5A9893E2.8040800@oracle.com> On 02/08/2018 03:18 PM, Jonathan Gibbons wrote: > This draft JEP contains a proposal to enhance the |java| launcher to > support running a > program supplied as a single file of Java source code. The program > will be compiled > and run, without the need to explicit invoke javac, or to package up a > jar file. > > For more details, see: > > http://openjdk.java.net/jeps/8192920 > > -- Jon Following up on this ... Thanks to all for the discussion. A number of interesting points were raised: 1. A desire to be able to specify the source version of the code to be compiled 2. A desire to specify additional VM options, most notably options like -Xmx or a classpath 3. General concerns with the limitations of the OS-provided shebang mechanism, especially related to how arguments are passed from the OS to the executable. To address these concerns, I propose to make the following two changes to the JEP. The first is user-visible, the second is mostly under-the-covers implementation detail. 1. Change the "-- source" option from being a simple no-arg option to an option that takes a release number, in line with the values currently accepted by the javac -source and --release options. In line with JEP 293, Guidelines for JDK Command-Line Tool Options, the value can be separated from the option name either by white space or an '='. 2. Change the Java Launcher so that if the first option begins with `--source` and contains white space, it will be split in-place into words separated by white space. This behavior will be limited as described so as not to affect the use of any other other options that may contain whitespace. The behavior is justified because the OS shebang mechanism is the underlying cause of the issue and the --source option is primarily intended for use in shebang files, to identify the use of a source file that does not follow the normal source-file naming conventions. The spec is intended to cover both cases, where the OS shebang mechanism passes the rest of the first line as a single arg to the executable, and where the OS itself breaks the rest of the line into words separated by whitespace. --- With these two modifications to the JEP proposal in mind, here are a bunch of examples to illustrate both simple and more advanced use cases. The shebang examples are obviously limited to those OS environments that provide a shebang feature, meaning primarily Unix-derived systems, like Linux, MacOS and Solaris. 1. A simple program in a source file named in the standard fashion $ java HelloWorld.java 2. A program that needs additional VM options $ java -Xmx1024m -Dplanet=Jupiter HelloPlanet.java $ java -classpath ../MyLibrary.jar MyApp.java 3. A program that wants to ensure the use of a specific language version $ java --source 10 HelloJDK10.java $ java --source=10 HelloJDK10.java 4. A shebang script in an otherwise normal source file. The example shows that you do not need a --source option in a shebang file that follows the normal naming conventions for a source file. First line of HelloShebang.java #!/usr/bin/java The file can be executed with $ ./HelloShebang.java a b c The effect of this line is to execute /usr/bin/java HelloShebang.java a b c 5. A shebang script that is named as a typical command might be named First line of a file called myScript #!/usr/bin/java --script 10 The file can be executed with $ ./myScript a b c The effect of this line is to execute the following, using quotes to indicate the arg provided by the OS shebang mechanism /usr/bin/java '--script 10' ./myScript a b c ... which will be treated by the launcher as equivalent to (note no quotes) /usr/bin/java --script 10 ./myScript a b c 6. A shebang script that uses additional VM options First line of a file called myScript #!/usr/bin/java --script 10 --classpath /home/my/lib/utils.jar -Xmx1024m The file can be executed with $ ./myScript a b c The effect of this line is to execute the following, using quotes to indicate the arg provided by the OS shebang mechanism /usr/bin/java '--script 10 --classpath /home/my/lib/utils.jar -Xmx1024m' ./myScript a b c ... which will be treated by the launcher as equivalent to (note no quotes) /usr/bin/java --script 10 --classpath /home/my/lib/utils.jar -Xmx1024m ./myScript a b c Note that a corollary of the proposed change is that if any arguments for the Java launcher are provided in a shebang file, then the --source option should be used, and should be appear as the first option after the name of the executable. This is avoid more complex rules about dealing with whitespace in any other options. This seems like an appropriate and reasonable compromise. -- Jon From jan.lahoda at oracle.com Fri Mar 2 16:52:21 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 2 Mar 2018 17:52:21 +0100 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 Message-ID: <5A998145.1050105@oracle.com> Hi, Having a source with a lot of imports can lead to a long compilation time, as the imports are lazily searched on each query to the Scope. But at least for named imports, the name is known, and can be used for quick filtering. (Sadly, for on-demand imports/package imports, this is much more difficult, and this patch does not improve them.) The principle of the patch is to have a map from name to scopes that may contain the given name in Scope.NamedImportScope. Also, the "current-file top-level scope" (JCCompilationUnit.toplevelScope) is no longer appended to the named import scope, but rather the relevant lookup is enhanced to query it as well if needed. This seems cleaner that trying to append the scope to the fast name lookup. Bug: https://bugs.openjdk.java.net/browse/JDK-8193717 Webrev: http://cr.openjdk.java.net/~jlahoda/8193717/webrev.00/ Liam, could you please check if this helps with your real-world case? How does this look? Thanks, Jan From cushon at google.com Sat Mar 3 06:44:44 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 2 Mar 2018 22:44:44 -0800 Subject: RFR: JDK-8193717: Import resolution performance regression in JDK 9 In-Reply-To: <5A998145.1050105@oracle.com> References: <5A998145.1050105@oracle.com> Message-ID: Hi Jan, > Liam, could you please check if this helps with your real-world case? > The numbers for the original compilation look great: before: avg 299.9s, stddev 56.5s after: avg 155.1s, stddev 24.8s That compilation is large and is less pathological than the repro in the bug (it's not just doing import resolution), so it's not surprising that it still takes some time. Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzaugg at gmail.com Mon Mar 5 00:49:20 2018 From: jzaugg at gmail.com (Jason Zaugg) Date: Mon, 05 Mar 2018 00:49:20 +0000 Subject: Future proofing use of ct.sym from Scala compiler Message-ID: I hope its okay to pose this question here, please let me know if there is a more appropriate list. I am adding support for JEP 247 (Compile for Older Platform Versions) to the Scala compiler. Together with support for multi-release JARs, we'll have a working --release compiler option like javac. JEP-247 doesn't specify the format of ct.sym, I understand this is an implementation detail of the JVM. In any case, ct.sym has a straightforward enough structure that we can code against it directly. I'd like to future proof this implementation as much as possible. What is the plan for encoding the versions into the ZIP entry name once in JDK 11+, at which point the "10" becomes a historical version and the assumption in CreateSymbols.java of: "Note: the versions are expected to be a single character." is violated? Will a delimiter be added ("10_9_8") or will the code that interprets this path name be updated to be able perform a smart parse of "1098"? If the latter, what rules would be used? I see that support was recently added [1] to version module-info.class. That aspect of the changed didn't seem to generate discussion in the review [2], but if there is anything subtle about the way module metadata is versioned, please let me know. Side note: It would certainly be helpful to expose something like `jrt://` for this historical data. The closest I could get via public APIs was with the javax.tools API, but this hardcodes `--release` to the running JDK version (or was it the --release of the running JVM?) Beyond that issue, the JavaFileManager API doesn't let one find the direct sub-packages of a given package without performing a full recursive walk of the contained class/source files, which is problematic for our use case. Thanks, Jason Zaugg [1] http://hg.openjdk.java.net/jdk/jdk/rev/dbfac941197a#l159.224 [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-October/thread.html#11183 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Mar 5 16:46:19 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 5 Mar 2018 17:46:19 +0100 Subject: Future proofing use of ct.sym from Scala compiler In-Reply-To: References: Message-ID: <5A9D745B.3090907@oracle.com> Hi Jason, On 5.3.2018 01:49, Jason Zaugg wrote: > I hope its okay to pose this question here, please let me know if there > is a more appropriate list. > > I am adding support for JEP 247 (Compile for Older Platform Versions) to > the Scala compiler. Together with support for multi-release JARs, we'll > have a working --release compiler option like javac. > > JEP-247 doesn't specify the format of ct.sym, I understand this is an > implementation detail of the JVM. Yes, I don't think the format is currently considered to be stable. > > In any case, ct.sym has a straightforward enough structure that we can > code against it directly. I'd like to future proof this implementation > as much as possible. > > What is the plan for encoding the versions into the ZIP entry name once > in JDK 11+, at which point the "10" becomes a historical version and the > assumption in CreateSymbols.java of: "Note: the versions are expected to > be a single character." is violated? Will a delimiter be added > ("10_9_8") or will the code that interprets this path name be updated to > be able perform a smart parse of "1098"? If the latter, what rules would > be used? The idea is to use letters as digits over 10 ('A', 'B', etc.). Does not have to be a hexadecimal number, could continue with 'G' after 'F'. > > I see that support was recently added [1] to version module-info.class. > That aspect of the changed didn't seem to generate discussion in the > review [2], but if there is anything subtle about the way module > metadata is versioned, please let me know. There is a possible subtlety in how the system module path is constructed. It may be something like: for module "java.base": 9-modules/java.base, 9, 89, ... for module "java.compiler": 9-modules/java.compiler, 9, 89, ... But the directories like "9" contain classfiles (.sig files) for all modules, not only for the given specific module. javac will only read classfiles for the packages the given module exports. > > Side note: It would certainly be helpful to expose something like > `jrt://` for this historical data. The closest I could get via public I think that this is something to consider. In this case, would it be enough to get access to ct.sym of the current runtime JDK? Jan > APIs was with the javax.tools API, but this hardcodes `--release` to the > running JDK version (or was it the --release of the running JVM?) > > Beyond that issue, the JavaFileManager API doesn't let one find the > direct sub-packages of a given package without performing a > full recursive walk of the contained class/source files, which is > problematic for our use case. > > Thanks, > > Jason Zaugg > > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/dbfac941197a#l159.224 > [2] > http://mail.openjdk.java.net/pipermail/compiler-dev/2017-October/thread.html#11183 > > From jonathan.gibbons at oracle.com Mon Mar 5 20:11:39 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 Mar 2018 12:11:39 -0800 Subject: Future proofing use of ct.sym from Scala compiler In-Reply-To: References: Message-ID: <5A9DA47B.9010103@oracle.com> On 03/04/2018 04:49 PM, Jason Zaugg wrote: > > Beyond that issue, the JavaFileManager API doesn't let one find the > direct sub-packages of a given package without performing a > full recursive walk of the contained class/source files, which is > problematic for our use case. > > Thanks, > > Jason Zaugg Yes, that is one of many known limitations of the JavaFileManager API. The javax.tools API predates the java.nio.file API, and would probably have looked very different had that been available when the javax.tools API was created. At least for StandardJavaFileManager, the trend has been to increase interoperability with the java.nio.file API, by making it possible to get java.nio.file.Path objects for Locations and FileObjects, thus allowing the use of java.nio.file API for all the otherwise "missing" API on (Standard)JavaFileManager. -- Jon From jzaugg at gmail.com Tue Mar 6 00:09:11 2018 From: jzaugg at gmail.com (Jason Zaugg) Date: Tue, 06 Mar 2018 00:09:11 +0000 Subject: Future proofing use of ct.sym from Scala compiler In-Reply-To: <5A9DA47B.9010103@oracle.com> References: <5A9DA47B.9010103@oracle.com> Message-ID: On Tue, 6 Mar 2018 at 06:15 Jonathan Gibbons wrote: > > At least for StandardJavaFileManager, the trend has been to increase > interoperability with the java.nio.file API, by making it possible to > get java.nio.file.Path objects for Locations and FileObjects, thus > allowing the use of java.nio.file API for all the otherwise "missing" > API on (Standard)JavaFileManager. > These are certainly welcome. I took a fresh look at what is possible, and got much closer to my ultimate goal of letting JavacFileManager do all the dirty work of dealing with ct.sym and MR JARs (not to mention --patch-module / --module-path etc) https://gist.github.com/2d1f8ab484427d032dc99bbbced92861 The missing link is JDKPlatformProvider, which is not exposed in javax.tools. Would be be possible to expose this? JDKs that don't want to support platform versioning would be only need to accept the running JDK version. I'll be able to workaround this in the meantime at the cost of coding against the ct.sym format. Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzaugg at gmail.com Tue Mar 6 00:09:10 2018 From: jzaugg at gmail.com (Jason Zaugg) Date: Tue, 06 Mar 2018 00:09:10 +0000 Subject: Future proofing use of ct.sym from Scala compiler In-Reply-To: <5A9D745B.3090907@oracle.com> References: <5A9D745B.3090907@oracle.com> Message-ID: On Tue, 6 Mar 2018 at 02:46 Jan Lahoda wrote: > The idea is to use letters as digits over 10 ('A', 'B', etc.). Does not > have to be a hexadecimal number, could continue with 'G' after 'F'. > Roger that, I'll teach our compiler about that encoding. > There is a possible subtlety in how the system module path is > constructed. It may be something like: > for module "java.base": 9-modules/java.base, 9, 89, ... > for module "java.compiler": 9-modules/java.compiler, 9, 89, ... > > But the directories like "9" contain classfiles (.sig files) for all > modules, not only for the given specific module. javac will only read > classfiles for the packages the given module exports. > Thanks, I'll keep that in mind when implementing JPMS (that's my next job after the lower hanging fruit of --release) > > > > > Side note: It would certainly be helpful to expose something like > > `jrt://` for this historical data. The closest I could get via public > > I think that this is something to consider. In this case, would it be > enough to get access to ct.sym of the current runtime JDK? > See my other email in the thread which discusses the possibility of exposing the functionality of JDKPlatformProvider via a supported API. Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Mar 6 01:11:44 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 05 Mar 2018 17:11:44 -0800 Subject: Future proofing use of ct.sym from Scala compiler In-Reply-To: References: <5A9DA47B.9010103@oracle.com> Message-ID: <5A9DEAD0.7080604@oracle.com> PlatformProvider, and JDKPlatformProvider addresses some use cases that are probably no longer relevant. I don't think we want to directly expose that functionality in javax.tools. However, I agree it is interesting to ensure that we can get at the functionality for supporting different versions of the platform, including the underlying mechanisms of ct.sym and MR-jars, but as much as possible I think we should work within the existing javax.tools API ... for example by setting options of a file manager. Is there anything specific on JDKPlatformProvider you are looking to use/support that could not be part of an enhanced file manager? -- Jon On 03/05/2018 04:09 PM, Jason Zaugg wrote: > On Tue, 6 Mar 2018 at 06:15 Jonathan Gibbons > > wrote: > > > At least for StandardJavaFileManager, the trend has been to increase > interoperability with the java.nio.file API, by making it possible to > get java.nio.file.Path objects for Locations and FileObjects, thus > allowing the use of java.nio.file API for all the otherwise "missing" > API on (Standard)JavaFileManager. > > > These are certainly welcome. > > I took a fresh look at what is possible, and got much closer to my > ultimate goal of letting JavacFileManager do all the dirty work of > dealing with ct.sym and MR JARs (not to mention --patch-module / > --module-path etc) > > https://gist.github.com/2d1f8ab484427d032dc99bbbced92861 > > The missing link is JDKPlatformProvider, which is not exposed in > javax.tools. Would be be possible to expose this? JDKs that don't want > to support platform versioning would be only need to accept the > running JDK version. I'll be able to workaround this in the meantime > at the cost of coding against the ct.sym format. > > Regards, > > Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzaugg at gmail.com Tue Mar 6 01:45:43 2018 From: jzaugg at gmail.com (Jason Zaugg) Date: Tue, 06 Mar 2018 01:45:43 +0000 Subject: Future proofing use of ct.sym from Scala compiler In-Reply-To: <5A9DEAD0.7080604@oracle.com> References: <5A9DA47B.9010103@oracle.com> <5A9DEAD0.7080604@oracle.com> Message-ID: On Tue, 6 Mar 2018 at 11:16 Jonathan Gibbons wrote: > PlatformProvider, and JDKPlatformProvider addresses some use cases that > are probably no longer relevant. > > I don't think we want to directly expose that functionality in > javax.tools. > > However, I agree it is interesting to ensure that we can get at the > functionality for supporting different versions of the platform, including > the underlying mechanisms of ct.sym and MR-jars, but as much as possible I > think we should work within the existing javax.tools API ... for example by > setting options of a file manager. > > Is there anything specific on JDKPlatformProvider you are looking to > use/support that could not be part of an enhanced file manager? > No, supporting --release as an option to the FileManager would support our use case. I suppose an alternative to exposing this via the existing API: handleOption("--release", "8") ... is the way to go, or whether new API should be introduced involving `Runtime.Version` to be consistent with `JarFile.` or `ModulePath.of`. I don't mind either way. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Mar 7 13:01:10 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 7 Mar 2018 14:01:10 +0100 Subject: RFR: JDK-8196519: Incomplete classpath causes infinite recursion in Resolve.isAccessible Message-ID: <5A9FE296.2000506@oracle.com> Hi, The problem here is that c.s.t.javac.code.Type.ErrorType.getEnclosingType returns "this", so if some code recursively analyses types and their enclosing types, it may get into trouble. In this case, it is Resolve.isAccessible which crashes with a StackOverflow. It would be possible to break the infinite recursion in isAccessible, but it seems as not quite correct to return "this" from getEnclosingType. The proposal is to return Type.noType. Bug: https://bugs.openjdk.java.net/browse/JDK-8196519 Webrev: http://cr.openjdk.java.net/~jlahoda/8196519/webrev.00/ How does this look? Thanks, Jan From cushon at google.com Wed Mar 7 18:02:40 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 7 Mar 2018 13:02:40 -0500 Subject: RFR: JDK-8196519: Incomplete classpath causes infinite recursion in Resolve.isAccessible In-Reply-To: <5A9FE296.2000506@oracle.com> References: <5A9FE296.2000506@oracle.com> Message-ID: Not a review, but it looks good to me. I verified the patch fixes the original problem that led to the bug report, and I did not see any compatibility impact in my testing. Thanks, On Wed, Mar 7, 2018 at 8:01 AM, Jan Lahoda wrote: > Hi, > > The problem here is that c.s.t.javac.code.Type.ErrorType.getEnclosingType > returns "this", so if some code recursively analyses types and their > enclosing types, it may get into trouble. In this case, it is > Resolve.isAccessible which crashes with a StackOverflow. > > It would be possible to break the infinite recursion in isAccessible, but > it seems as not quite correct to return "this" from getEnclosingType. The > proposal is to return Type.noType. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196519 > Webrev: http://cr.openjdk.java.net/~jlahoda/8196519/webrev.00/ > > How does this look? > > Thanks, > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 8 07:46:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Mar 2018 07:46:14 +0000 Subject: RFR : JDK-8071367 - JMX: Remove SNMP support In-Reply-To: References: Message-ID: On 08/03/2018 07:27, Amit Sapre wrote: > > Hello, > > Please review the changes for removing SNMP support. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8071367 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.00 > > cc'ing compiler-dev for help on javac/resources/legacy.properties. I'm not 100% sure if it is used when compiling to old releases or not. As you are re-wording the class description for jdk.internal.agent.Agent then we might as well get it right. The Agent class loaded and its static no-arg startAgent method is invoked when a system property starting with "com.sun.management" is specified on the command line. We could expand this to include the case where it is started in a running VM too. build.properties - I assume the empty value for excludes shouldn't have a continuation character now. The rest looks good to me. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Mar 8 20:02:52 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 8 Mar 2018 12:02:52 -0800 Subject: RFR : JDK-8071367 - JMX: Remove SNMP support In-Reply-To: References: Message-ID: <5fed6078-624f-2c4b-b92c-5022fd07925c@oracle.com> On 3/7/18 11:46 PM, Alan Bateman wrote: > On 08/03/2018 07:27, Amit Sapre wrote: >> >> Hello, >> >> Please review the changes for removing SNMP support. >> >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8071367 >> >> Webrev : >> http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.00 >> >> > cc'ing compiler-dev for help on javac/resources/legacy.properties. I'm > not 100% sure if it is used when compiling to old releases or not. > I think legacy.properties is for compiling for older releases prior to 9 and it should not be changed.?? Let's get the compiler team to confirm. > As you are re-wording the class description for > jdk.internal.agent.Agent then we might as well get it right. The Agent > class loaded and its static no-arg startAgent method is invoked when a > system property starting with "com.sun.management" is specified on the > command line. We could expand this to include the case where it is > started in a running VM too. > Good suggestion. > build.properties - I assume the empty value for excludes shouldn't > have a continuation character now. > > The rest looks good to me. > I look through the webrev.? No other comment besides called out above. I created https://bugs.openjdk.java.net/browse/JDK-8199358 to track the docs update. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Mar 9 01:11:46 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Mar 2018 17:11:46 -0800 Subject: Draft JEP: Launch Single-File Source-Code Programs In-Reply-To: <5A9893E2.8040800@oracle.com> References: <5A7CDACB.50103@oracle.com> <5A9893E2.8040800@oracle.com> Message-ID: <5AA1DF52.8010100@oracle.com> A couple of folk have pointed out there was a repeated typo in my previous message such that "--script" was used when "--source was intended. The following is a corrected version. -- Jon ----------------------------- Thanks to all for the discussion. A number of interesting points were raised: 1. A desire to be able to specify the source version of the code to be compiled 2. A desire to specify additional VM options, most notably options like -Xmx or a classpath 3. General concerns with the limitations of the OS-provided shebang mechanism, especially related to how arguments are passed from the OS to the executable. To address these concerns, I propose to make the following two changes to the JEP. The first is user-visible, the second is mostly under-the-covers implementation detail. 1. Change the "-- source" option from being a simple no-arg option to an option that takes a release number, in line with the values currently accepted by the javac -source and --release options. In line with JEP 293, Guidelines for JDK Command-Line Tool Options, the value can be separated from the option name either by white space or an '='. 2. Change the Java Launcher so that if the first option begins with `--source` and contains white space, it will be split in-place into words separated by white space. This behavior will be limited as described so as not to affect the use of any other other options that may contain whitespace. The behavior is justified because the OS shebang mechanism is the underlying cause of the issue and the --source option is primarily intended for use in shebang files, to identify the use of a source file that does not follow the normal source-file naming conventions. The spec is intended to cover both cases, where the OS shebang mechanism passes the rest of the first line as a single arg to the executable, and where the OS itself breaks the rest of the line into words separated by whitespace. --- With these two modifications to the JEP proposal in mind, here are a bunch of examples to illustrate both simple and more advanced use cases. The shebang examples are obviously limited to those OS environments that provide a shebang feature, meaning primarily Unix-derived systems, like Linux, MacOS and Solaris. 1. A simple program in a source file named in the standard fashion $ java HelloWorld.java 2. A program that needs additional VM options $ java -Xmx1024m -Dplanet=Jupiter HelloPlanet.java $ java -classpath ../MyLibrary.jar MyApp.java 3. A program that wants to ensure the use of a specific language version $ java --source 10 HelloJDK10.java $ java --source=10 HelloJDK10.java 4. A shebang script in an otherwise normal source file. The example shows that you do not need a --source option in a shebang file that follows the normal naming conventions for a source file. First line of HelloShebang.java #!/usr/bin/java The file can be executed with $ ./HelloShebang.java a b c The effect of this line is to execute /usr/bin/java HelloShebang.java a b c 5. A shebang script that is named as a typical command might be named First line of a file called myScript #!/usr/bin/java --source 10 The file can be executed with $ ./myScript a b c The effect of this line is to execute the following, using quotes to indicate the arg provided by the OS shebang mechanism /usr/bin/java '--source 10' ./myScript a b c ... which will be treated by the launcher as equivalent to (note no quotes) /usr/bin/java --source 10 ./myScript a b c 6. A shebang script that uses additional VM options First line of a file called myScript #!/usr/bin/java --source 10 --classpath /home/my/lib/utils.jar -Xmx1024m The file can be executed with $ ./myScript a b c The effect of this line is to execute the following, using quotes to indicate the arg provided by the OS shebang mechanism /usr/bin/java '--source 10 --classpath /home/my/lib/utils.jar -Xmx1024m' ./myScript a b c ... which will be treated by the launcher as equivalent to (note no quotes) /usr/bin/java --source 10 --classpath /home/my/lib/utils.jar -Xmx1024m ./myScript a b c Note that a corollary of the proposed change is that if any arguments for the Java launcher are provided in a shebang file, then the --source option should be used, and should be appear as the first option after the name of the executable. This is avoid more complex rules about dealing with whitespace in any other options. This seems like an appropriate and reasonable compromise. -- Jon From maurizio.cimadamore at oracle.com Fri Mar 9 13:03:59 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Mar 2018 13:03:59 +0000 Subject: RFR: JDK-8196519: Incomplete classpath causes infinite recursion in Resolve.isAccessible In-Reply-To: <5A9FE296.2000506@oracle.com> References: <5A9FE296.2000506@oracle.com> Message-ID: <2a9b1fc7-6d3a-e0dd-3dce-3885c6583c9b@oracle.com> Whoops - looks good Maurizio On 07/03/18 13:01, Jan Lahoda wrote: > Hi, > > The problem here is that > c.s.t.javac.code.Type.ErrorType.getEnclosingType returns "this", so if > some code recursively analyses types and their enclosing types, it may > get into trouble. In this case, it is Resolve.isAccessible which > crashes with a StackOverflow. > > It would be possible to break the infinite recursion in isAccessible, > but it seems as not quite correct to return "this" from > getEnclosingType. The proposal is to return Type.noType. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196519 > Webrev: http://cr.openjdk.java.net/~jlahoda/8196519/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From jonathan.gibbons at oracle.com Fri Mar 9 22:19:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 09 Mar 2018 14:19:11 -0800 Subject: RFR : JDK-8198552: Multiple javac plugins do not work at the same time. In-Reply-To: <5A9824AD.9090102@oracle.com> References: <5A8FFF30.7010902@oracle.com> <5A9824AD.9090102@oracle.com> Message-ID: <5AA3085F.7080505@oracle.com> +1 -- Jon On 03/01/2018 08:05 AM, Jan Lahoda wrote: > On 23.2.2018 22:14, Vicente Romero wrote: >> I think that for completeness we should test the case when the plugin(s) >> are defined inside a module, > > Thanks Vicente, an updated webrev which tests also Plugins in modules > is here: > http://cr.openjdk.java.net/~jlahoda/8198552/webrev.01/ > > Jan > >> >> Thanks, >> Vicente >> >> On 02/23/2018 06:46 AM, Jan Lahoda wrote: >>> Hi, >>> >>> When specifying multiple javac plugins using -Xplugin:, only one of >>> them is run. The primary reason is that an incorrect (originally, >>> there was only this one) method is overridden in Option.PLUGIN. I've >>> found two more options that have the same problem ("-Xdoclint:" and >>> "-Xdoclint/packages:"), I tried to fix those as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198552 >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8198552/webrev.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan >> From jonathan.gibbons at oracle.com Tue Mar 13 15:38:33 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Mar 2018 08:38:33 -0700 Subject: Future proofing use of ct.sym from Scala compiler In-Reply-To: References: Message-ID: <8f9da983-f246-a885-9b7c-2e544c2c516d@oracle.com> Filed as https://bugs.openjdk.java.net/browse/JDK-8199521 -- Jon On 3/4/18 4:49 PM, Jason Zaugg wrote: > I hope its okay to pose this question here, please let me know if > there is a more appropriate list. > > I am adding support for?JEP 247 (Compile for Older Platform Versions) > to the Scala compiler. Together with support for multi-release JARs, > we'll have a working --release compiler option like javac. > > JEP-247 doesn't specify the format of ct.sym, I understand this is an > implementation detail of the JVM. > > In any case, ct.sym has a straightforward enough structure that we can > code against it directly. I'd like to future proof this implementation > as much as possible. > > What is the plan for encoding the versions into the ZIP entry name > once in JDK 11+, at which point the "10" becomes a historical version > and the assumption in CreateSymbols.java of: "Note: the versions are > expected to be a single character." is violated? Will a delimiter be > added ("10_9_8") or will the code that interprets this path name be > updated to be able perform a smart parse of "1098"? If the latter, > what rules would be used? > > I see that support was recently added [1] to version > module-info.class. That aspect of the changed didn't seem to generate > discussion in the review [2], but if there is anything subtle about > the way module metadata is versioned, please let me know. > > Side note: It would certainly be helpful to expose something like > `jrt://` for this historical data. The closest I could get via public > APIs was with the javax.tools API, but this hardcodes?`--release` to > the running JDK version (or was it the --release of the running JVM?) > > Beyond that issue, the JavaFileManager API doesn't let one find the > direct sub-packages of a given package without performing a > full?recursive walk of the contained class/source files, which is > problematic for our use case. > > Thanks, > > Jason Zaugg > > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/dbfac941197a#l159.224 > [2] > http://mail.openjdk.java.net/pipermail/compiler-dev/2017-October/thread.html#11183 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Mar 13 21:23:01 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 Mar 2018 14:23:01 -0700 Subject: test/langtools/Makefile Message-ID: <58879ce4-1a59-ffc0-6002-e7664e04d295@oracle.com> Hello, We in the build/infra team would like to unify the langtools test/Makefile with the other test Makefiles. Currently all the others share a common TestCommon.gmk, but the langtools file was too different at the time so we didn't dare touching it. My question to you is if there are any known parts of that file that need to be preserved? The most obvious part would be the JCK support. Is that still used and/or needed? /Erik From jonathan.gibbons at oracle.com Tue Mar 13 22:51:30 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Mar 2018 15:51:30 -0700 Subject: test/langtools/Makefile In-Reply-To: <58879ce4-1a59-ffc0-6002-e7664e04d295@oracle.com> References: <58879ce4-1a59-ffc0-6002-e7664e04d295@oracle.com> Message-ID: <958fb02e-6002-0826-867b-740b5f44c1cc@oracle.com> JCK support is required in some form, but I would expect that the benefits in having a shared test infrastructure (capable of meeting all requirements) would outweigh the benefits of Makefiles written over 10 years ago. There are various aspects to JCK support, including primary functionality (running the runtime and compiler test suites) and secondary functionality (building the runtime test suite as a "test" of the compiler). The langtools tests do not currently need support for any native code; nor do we share the test library used by the hotspot and jdk repos. It would be nice to retain that independence until we choose to do otherwise. -- Jon On 3/13/18 2:23 PM, Erik Joelsson wrote: > Hello, > > We in the build/infra team would like to unify the langtools > test/Makefile with the other test Makefiles. Currently all the others > share a common TestCommon.gmk, but the langtools file was too > different at the time so we didn't dare touching it. > > My question to you is if there are any known parts of that file that > need to be preserved? The most obvious part would be the JCK support. > Is that still used and/or needed? > > /Erik > From jan.lahoda at oracle.com Thu Mar 15 15:40:42 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 15 Mar 2018 16:40:42 +0100 Subject: RFR JDK-8194978: Javac produces dead code for try-with-resource Message-ID: <5AAA93FA.2020104@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8194978 The issue here is that the bytecode generated for try-with-resources produces some unreachable instructions, and may be unnecessarily big. Consider this code: --- try (InputStream in = new FileInputStream(str)) { int read = in.read(); if (read == (-1)) return ; System.err.println(read); } --- javac desugars it to this: --- { final InputStream in = new FileInputStream(str); /*synthetic*/ Throwable primaryException0$ = null; try { int read = in.read(); if (read == (-1)) return; System.err.println(read); } catch (/*synthetic*/ final Throwable t$) { primaryException0$ = t$; throw t$; } finally { if (primaryException0$ != null) try { in.close(); } catch (/*synthetic*/ Throwable x2) { primaryException0$.addSuppressed(x2); } else in.close(); } } --- Which seems fine, but when the try-finally construct is written into bytecode, the "finally" section is duplicated into all (non-exceptional) exit points from the try body (it would also be copied to non-exception exit points from all catches, but there are no such exit points in this case). A rough idea on how the bytecode looks like is below - please note that some try-catches don't embed nicely with the rest of the code, so are denoted in comments only. --- { final InputStream in = new FileInputStream(str); /*synthetic*/ Throwable primaryException0$ = null; // try int read = in.read(); if (read == (-1)) { // catch Throwable: goto CATCH // catch any: goto FINALLY [1] //start injected finally if (primaryException0$ != null) try { // [2] in.close(); } catch (/*synthetic*/ Throwable x2) { primaryException0$.addSuppressed(x2); } else in.close(); //end injected finally return; } // try System.err.println(read); // catch Throwable: goto CATCH // catch any: goto FINALLY [1] //start injected finally if (primaryException0$ != null) try { // [2] in.close(); } catch (/*synthetic*/ Throwable x2) { primaryException0$.addSuppressed(x2); } else in.close(); //end injected finally //goto END CATCH: // catch (/*synthetic*/ final Throwable t$) // try primaryException0$ = t$; throw t$; // catch any: goto FINALLY FINALLY: if (primaryException0$ != null) try {// [3] in.close(); } catch (/*synthetic*/ Throwable x2) { primaryException0$.addSuppressed(x2); } else in.close(); END: } --- A few comments about the code: -[1]: this catches seem unnecessary: all Throwables have already been caught? -[2]: at this place, it is clear that primaryException0$ is null, so the is-non-null section is not useful -[3]: at this place, it is mostly clear that primaryException0$ is not-null, so the is-null section is not useful So, it seems it might be possible to construct the code so that only the needed sections of the finally would be used at the appropriate places. I.e. the original try-with-resources would get desugared to something like: --- { final InputStream in = new FileInputStream(str); try { int read = in.read(); if (read == (-1)) return; System.err.println(read); } body-only-finally { //copied to exit points in try body //only, not used as a real finally in.close(); } catch (/*synthetic*/ final Throwable t$) { try { in.close(); } catch (/*synthetic*/ Throwable x2) { t$.addSuppressed(x2); } throw t$; } } --- Which would then get generated to bytecode as: --- { final InputStream in = new FileInputStream(str); //try int read = in.read(); if (read == (-1)) { // catch Throwable: goto CATCH in.close(); return; } //try System.err.println(read); // catch Throwable: goto CATCH in.close(); //goto END CATCH: // catch (/*synthetic*/ final Throwable t$) try { in.close(); } catch (/*synthetic*/ Throwable x2) { t$.addSuppressed(x2); } throw t$; END: } --- The current desugaring is trying to pull out the finally code into a separate method when that appears to be worthwhile, but this proposed desugaring seems to be producing a better bytecode with less javac code. Does this updated desugaring/transformation look safe? Webrev: http://cr.openjdk.java.net/~jlahoda/8194978/webrev.00/ Thanks, Jan From joe.darcy at oracle.com Fri Mar 16 04:45:20 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 15 Mar 2018 21:45:20 -0700 Subject: Some thoughts on javax.lang.model support for preview language features Message-ID: <63ba79b2-4b81-5bcd-8d62-4c336f875341@oracle.com> Hello, As you may have seen elsewhere, JEP 12: Preview Language and VM Features (http://openjdk.java.net/jeps/12) is proposing to include preview language features as part of the platform. The JEP has been discussed in various threads on jdk-dev ([1], [2], etc.) Since one of the various and sundry aspects of supporting a language is updating the language model API [3], it is worthwhile to discuss a few alternatives in terms of how the language model API could support preview features The javax.lang.model APIs are part of the Java SE API and thus live by the strict compatibility rules of that space, with some slight accommodations for certain technical aspects of the API. For the sake of argument, let's assume we do *not* want to change mainline javax.lang.model API to describe the preview features. The ElementKind.OTHER and TypeKind.OTHER values are meant to indicate an object is outside of the values for the standardized system. Subtypes of the modeling interfaces and visitors can then be used as needed for the specialized and extended system. (Joel Borggren-Franck and I used this approach in the javax.lang.model backed by core reflection prototype from a few years back, JEP 119: javax.lang.model Implementation Backed by Core Reflection.) However, using such an extended API inside javac (or in annotation processors) is tedious. One could imagine a system where a different, updated, version of javax.lang.model were used when the incubating features were unlocked via upgrading its module or the like, but that would be awkward as well. If our intention is to only support one preview version at a time, part of the API approach could be to add a "PREVIEW" constant to SourceVersion that was always the most latest version. In other words in JDK 11 we'd have ??? RELEASE_0, ??? ... ??? RELEASE_11, ??? PREVIEW; and in JDK 12 ??? RELEASE_0, ??? ... ??? RELEASE_11, ??? RELEASE_12, ??? PREVIEW; Processors could them indicate they support the "PREVIEW" release value. The longer-term javax.lang.model API evolution to-do list includes thinking about other ways to evolve the visitors to support new language features. We've stopped automatically adding new visitors with every release, now only adding them as needed and we didn't need a new batch for 10. We could potentially have a similar structure for visitors with a cadre of "Preview" visitors as the most specialized versions in a release and new per-release visitors getting introduced as superclasses afterward. The main risk is pulling or changing the incubating feature in some way that would be incompatible with the API support added for it. Recent discussions have suggested @Deprecating new API items added to support preview features. Can is a reasonable precaution to discourage accidental dependence on them, but at times the behavior of existing methods is also changes so deprecation would not be a good fit. Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000515.html [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000831.html [3] https://blogs.oracle.com/darcy/so-you-want-to-change-the-java-programming-language From maurizio.cimadamore at oracle.com Fri Mar 16 13:02:22 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 16 Mar 2018 13:02:22 +0000 Subject: Some thoughts on javax.lang.model support for preview language features In-Reply-To: <63ba79b2-4b81-5bcd-8d62-4c336f875341@oracle.com> References: <63ba79b2-4b81-5bcd-8d62-4c336f875341@oracle.com> Message-ID: Hi Joe, I did some experiments along those lines few weeks ago and concluded that, while the idea of having a separate source version for PREVIEW is attractive, it is not as straightforward as it seems. Here is some evidence: * in javac, there's a 1-1 mapping between javac's Source enum constants and SourceVersion enum constants, which means if we have SourceVersion.PREVIEW, we probably should have Source.PREVIEW too * pulling more on that string, in javac there's a 1-1 mapping between the source levels available in the Source enum and the values that can be passed to the -source flag. But, if we add Source.PREVIEW, this would break that invariant, and we would now have a source version that is 'non denotable' via command line options. This distinction seems to have deep implications both in javac and in tests. * diagnostics; the set of diagnostics given for preview features when they are not enabled is almost certainly distinct from those given when you e.g. try to use lambdas with -source 7. * more onto the point - SourceVesrion has a couple of static methods: public static SourceVersion latest() private static SourceVersion getLatestSupported() What should these method return? 11 or PREVIEW? Also, note that the last method is affected by the value of the runtime property "java.specification.version", so any change here require some synergy with the runtime. All this left a sour taste on my mouth; having PREVIEW to mean Source.N + 1 seems appealing, but at the same time very problematic; if we instead treat preview has an orthogonal toggle, a lot of the complexity just disappears. I'm not sure what an equivalent of that toggle might be in the JLM-land - probably another way to get there would be to add a default method to the Processor interface - e.g. default isPreviewSupported() { return false; } And then augment the SupportedSourceVersion annotation: public @interface SupportedSourceVersion { ??? SourceVersion value(); ??? boolean preview default false; } Thoughts? Maurizio On 16/03/18 04:45, Joseph D. Darcy wrote: > Hello, > > As you may have seen elsewhere, JEP 12: Preview Language and VM > Features (http://openjdk.java.net/jeps/12) is proposing to include > preview language features as part of the platform. The JEP has been > discussed in various threads on jdk-dev ([1], [2], etc.) Since one of > the various and sundry aspects of supporting a language is updating > the language model API [3], it is worthwhile to discuss a few > alternatives in terms of how the language model API could support > preview features > > The javax.lang.model APIs are part of the Java SE API and thus live by > the strict compatibility rules of that space, with some slight > accommodations for certain technical aspects of the API. > > For the sake of argument, let's assume we do *not* want to change > mainline javax.lang.model API to describe the preview features. The > ElementKind.OTHER and TypeKind.OTHER values are meant to indicate an > object is outside of the values for the standardized system. Subtypes > of the modeling interfaces and visitors can then be used as needed for > the specialized and extended system. (Joel Borggren-Franck and I used > this approach in the javax.lang.model backed by core reflection > prototype from a few years back, JEP 119: javax.lang.model > Implementation Backed by Core Reflection.) > > However, using such an extended API inside javac (or in annotation > processors) is tedious. > > One could imagine a system where a different, updated, version of > javax.lang.model were used when the incubating features were unlocked > via upgrading its module or the like, but that would be awkward as well. > > If our intention is to only support one preview version at a time, > part of the API approach could be to add a "PREVIEW" constant to > SourceVersion that was always the most latest version. In other words > in JDK 11 we'd have > > ??? RELEASE_0, > ??? ... > ??? RELEASE_11, > ??? PREVIEW; > > and in JDK 12 > > ??? RELEASE_0, > ??? ... > ??? RELEASE_11, > ??? RELEASE_12, > ??? PREVIEW; > > Processors could them indicate they support the "PREVIEW" release value. > > The longer-term javax.lang.model API evolution to-do list includes > thinking about other ways to evolve the visitors to support new > language features. We've stopped automatically adding new visitors > with every release, now only adding them as needed and we didn't need > a new batch for 10. We could potentially have a similar structure for > visitors with a cadre of "Preview" visitors as the most specialized > versions in a release and new per-release visitors getting introduced > as superclasses afterward. > > The main risk is pulling or changing the incubating feature in some > way that would be incompatible with the API support added for it. > > Recent discussions have suggested @Deprecating new API items added to > support preview features. Can is a reasonable precaution to discourage > accidental dependence on them, but at times the behavior of existing > methods is also changes so deprecation would not be a good fit. > > Cheers, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000515.html > > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000831.html > > [3] > https://blogs.oracle.com/darcy/so-you-want-to-change-the-java-programming-language From maurizio.cimadamore at oracle.com Tue Mar 20 12:13:33 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 20 Mar 2018 12:13:33 +0000 Subject: RFR JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: <5AAA93FA.2020104@oracle.com> References: <5AAA93FA.2020104@oracle.com> Message-ID: <0cfa287b-8b20-8065-f6d8-7c8aaa515d00@oracle.com> Hi Jan, great work. The desugaring looks correct, at least there's nothing wrong I can spot about it. Some comments: * resourceNonNull = TreeInfo.skipParens(resource).hasTag(NEWCLASS); Is the above needed? I can't seem to support evidence that this syntax is even legal (in the branch where 'resource' is an expression, I mean) * The javadoc in Lower::makeTwrTry seems out of sync what is being actually generated * I think the Lower code would benefit from better variable names - the patch has a mixture of old names (e.g. primaryException) and new names (e.g. 'closeStatement2'). I suggest picking a naming scheme in the javadoc, and then stick to that in the code, so that there are explicit references to what bit it is that we're currently generating. * I find the code in Gen bit subtle; you want the new finally block to act as a finally - but only during the try block; that means, I believe, that you want genFinalizer to do the usual thing (e.g. copy finalizer body on exit points) but then skip doing that when it comes to exceptions. That is, you don't want a catch-all block and you don't want to copy finalizer body on exceptional paths. Another stacking would be to completely replace the 'env.info.finalize' after the body is done, e.g. if (tree.finalizer.flags & BODY_ONLY_FINALIZE != 0) { ?? env.info.finalize == null; } Wouldn't this be more consistent with what you are trying to achieve? Seems to me that with the current approach there are side effects that occur in the GenFinalizer even when afterBody is set (e.g. setting finalizer gaps in the encl environment). Cheers Maurizio On 15/03/18 15:40, Jan Lahoda wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8194978 > > The issue here is that the bytecode generated for try-with-resources > produces some unreachable instructions, and may be unnecessarily big. > > Consider this code: > --- > ??????? try (InputStream in = new FileInputStream(str)) { > ??????????? int read = in.read(); > ??????????? if (read == (-1)) return ; > ??????????? System.err.println(read); > ??????? } > --- > > javac desugars it to this: > --- > ??????? { > ??????????? final InputStream in = new FileInputStream(str); > ??????????? /*synthetic*/ Throwable primaryException0$ = null; > ??????????? try { > ??????????????? int read = in.read(); > ??????????????? if (read == (-1)) return; > ??????????????? System.err.println(read); > ??????????? } catch (/*synthetic*/ final Throwable t$) { > ??????????????? primaryException0$ = t$; > ??????????????? throw t$; > ??????????? } finally { > ??????????????? if (primaryException0$ != null) try { > ??????????????????? in.close(); > ??????????????? } catch (/*synthetic*/ Throwable x2) { > ??????????????????? primaryException0$.addSuppressed(x2); > ??????????????? } else in.close(); > ??????????? } > ??????? } > --- > > Which seems fine, but when the try-finally construct is written into > bytecode, the "finally" section is duplicated into all > (non-exceptional) exit points from the try body (it would also be > copied to non-exception exit points from all catches, but there are no > such exit points in this case). A rough idea on how the bytecode looks > like is below - please note that some try-catches don't embed nicely > with the rest of the code, so are denoted in comments only. > > --- > ??????? { > ??????????? final InputStream in = new FileInputStream(str); > ??????????? /*synthetic*/ Throwable primaryException0$ = null; > ??????????? // try > ??????????????? int read = in.read(); > ??????????????? if (read == (-1)) { > ??????????? // catch Throwable: goto CATCH > ??????????? // catch any: goto FINALLY [1] > ??????????????????? //start injected finally > ??????????????????? if (primaryException0$ != null) try { // [2] > ??????????????????????? in.close(); > ??????????????????? } catch (/*synthetic*/ Throwable x2) { > ??????????????????????? primaryException0$.addSuppressed(x2); > ??????????????????? } else in.close(); > ??????????????????? //end injected finally > > ??????????????????? return; > ??????????????? } > > ??????????? // try > ??????????????? System.err.println(read); > ??????????? // catch Throwable: goto CATCH > ??????????? // catch any: goto FINALLY [1] > > ??????????? //start injected finally > ??????????? if (primaryException0$ != null) try { // [2] > ??????????????? in.close(); > ??????????? } catch (/*synthetic*/ Throwable x2) { > ??????????????? primaryException0$.addSuppressed(x2); > ??????????? } else in.close(); > ??????????? //end injected finally > > ??????????? //goto END > > ??????????? CATCH: // catch (/*synthetic*/ final Throwable t$) > ??????????????? // try > ??????????????? primaryException0$ = t$; > ??????????????? throw t$; > ??????????????? // catch any: goto FINALLY > ??????????? FINALLY: > ??????????????? if (primaryException0$ != null) try {// [3] > ??????????????????? in.close(); > ??????????????? } catch (/*synthetic*/ Throwable x2) { > ??????????????????? primaryException0$.addSuppressed(x2); > ??????????????? } else in.close(); > ??????????? END: > ??????? } > --- > > A few comments about the code: > -[1]: this catches seem unnecessary: all Throwables have already been > caught? > -[2]: at this place, it is clear that primaryException0$ is null, so > the is-non-null section is not useful > -[3]: at this place, it is mostly clear that primaryException0$ is > not-null, so the is-null section is not useful > > So, it seems it might be possible to construct the code so that only > the needed sections of the finally would be used at the appropriate > places. I.e. the original try-with-resources would get desugared to > something like: > > --- > ??????? { > ??????????? final InputStream in = new FileInputStream(str); > ??????????? try { > ??????????????? int read = in.read(); > ??????????????? if (read == (-1)) return; > ??????????????? System.err.println(read); > ??????????? } body-only-finally { //copied to exit points in try body > ????????????????????????????????? //only, not used as a real finally > ??????????????? in.close(); > ??????????? } catch (/*synthetic*/ final Throwable t$) { > ??????????????? try { > ??????????????????? in.close(); > ??????????????? } catch (/*synthetic*/ Throwable x2) { > ??????????????????? t$.addSuppressed(x2); > ??????????????? } > ??????????????? throw t$; > ??????????? } > ??????? } > --- > > Which would then get generated to bytecode as: > --- > ??????? { > ??????????? final InputStream in = new FileInputStream(str); > ??????????? //try > ??????????????? int read = in.read(); > ??????????????? if (read == (-1)) { > ??????????? // catch Throwable: goto CATCH > ??????????????????? in.close(); > ??????????????????? return; > ??????????????? } > > ??????????? //try > ??????????????? System.err.println(read); > ??????????? // catch Throwable: goto CATCH > > ??????????? in.close(); > > ??????????? //goto END > > ??????????? CATCH: // catch (/*synthetic*/ final Throwable t$) > ??????????????? try { > ??????????????????? in.close(); > ??????????????? } catch (/*synthetic*/ Throwable x2) { > ??????????????????? t$.addSuppressed(x2); > ??????????????? } > ??????????????? throw t$; > ??????????? END: > ??????? } > --- > > The current desugaring is trying to pull out the finally code into a > separate method when that appears to be worthwhile, but this proposed > desugaring seems to be producing a better bytecode with less javac code. > > Does this updated desugaring/transformation look safe? > > Webrev: http://cr.openjdk.java.net/~jlahoda/8194978/webrev.00/ > > Thanks, > ???? Jan From naokikishida at gmail.com Wed Mar 21 01:54:02 2018 From: naokikishida at gmail.com (kishida naoki) Date: Wed, 21 Mar 2018 10:54:02 +0900 Subject: bug: compiler crashes with `var s=List.of("a",1)` Message-ID: Hi all! I'm glad that JDK 10 is released. But I've faced a compiler bug with `var`. I'm using the build 46. This code crashes the compiler with `-g` option. ``` public class Main { void m() { var s = java.util.List.of("a", 1); } } ``` $ javac Main.java -g C:\src>javac Main.java -g java.lang.AssertionError: Unexpected intersection type: java.lang.Object&java.io.Serializable&java.lang.Comparable> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) The cause is about intersection. The variable type that is infered becomes as a type with intersection, and will crash the compiler when generating a debug info. These are no problem. var s=List.of("a"); var s=List.of("a", 1, Optional.empty()); var s=List.of("a", 1, List.of()); Best regards. -- Naoki Kishida -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitterfoxc at gmail.com Wed Mar 21 02:53:27 2018 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 21 Mar 2018 11:53:27 +0900 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` Message-ID: Hi all and Kishida, Thank you for reporting the issue. I've filed and created a patch: Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ Could someone review this? If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 after backport approval. Regards, shinyafox(Shinya Yoshida) 2018-03-21 10:54 GMT+09:00 kishida naoki : > Hi all! > > I'm glad that JDK 10 is released. > But I've faced a compiler bug with `var`. > I'm using the build 46. > > This code crashes the compiler with `-g` option. > ``` > public class Main { > void m() { > var s = java.util.List.of("a", 1); > } > } > ``` > > $ javac Main.java -g > C:\src>javac Main.java -g > java.lang.AssertionError: Unexpected intersection type: java.lang.Object& > java.io.Serializable&java.lang.Comparable java.io.Serializable&java.lang.Comparable> > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter. > enterInner(ClassWriter.java:1043) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$ > CWSignatureGenerator.classReference(ClassWriter.java:312) > at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator. > assembleClassSig(Types.java:5182) > at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator. > assembleSig(Types.java:5114) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$ > CWSignatureGenerator.assembleSig(ClassWriter.java:291) > at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator. > assembleSig(Types.java:5225) > at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator. > assembleClassSig(Types.java:5201) > at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator. > assembleSig(Types.java:5114) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$ > CWSignatureGenerator.assembleSig(ClassWriter.java:291) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig( > ClassWriter.java:334) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter. > writeCode(ClassWriter.java:1271) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter. > writeMethod(ClassWriter.java:1158) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter. > writeMethods(ClassWriter.java:1653) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter. > writeClassFile(ClassWriter.java:1761) > at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter. > writeClass(ClassWriter.java:1679) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler. > genCode(JavaCompiler.java:749) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler. > generate(JavaCompiler.java:1627) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler. > generate(JavaCompiler.java:1595) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler. > compile(JavaCompiler.java:965) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main. > java:306) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main. > java:165) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > The cause is about intersection. The variable type that is infered becomes > as a type with intersection, and will crash the compiler when generating a > debug info. > These are no problem. > var s=List.of("a"); > var s=List.of("a", 1, Optional.empty()); > var s=List.of("a", 1, List.of()); > > Best regards. > > -- > Naoki Kishida > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naokikishida at gmail.com Wed Mar 21 03:01:34 2018 From: naokikishida at gmail.com (kishida naoki) Date: Wed, 21 Mar 2018 12:01:34 +0900 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: Message-ID: Hi, Yoshida! Thank you for the so quick processing! Regards. 2018-03-21 11:53 GMT+09:00 ShinyaYoshida : > Hi all and Kishida, > > Thank you for reporting the issue. > > I've filed and created a patch: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 > Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ > > Could someone review this? > > If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 > after backport approval. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 10:54 GMT+09:00 kishida naoki : > >> Hi all! >> >> I'm glad that JDK 10 is released. >> But I've faced a compiler bug with `var`. >> I'm using the build 46. >> >> This code crashes the compiler with `-g` option. >> ``` >> public class Main { >> void m() { >> var s = java.util.List.of("a", 1); >> } >> } >> ``` >> >> $ javac Main.java -g >> C:\src>javac Main.java -g >> java.lang.AssertionError: Unexpected intersection type: java.lang.Object& >> java.io.Serializable&java.lang.Comparable> java.io.Serializable&java.lang.Comparable> >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner( >> ClassWriter.java:1043) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.classReference(ClassWriter.java:312) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleClassSig(Types.java:5182) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5114) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.assembleSig(ClassWriter.java:291) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5225) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleClassSig(Types.java:5201) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5114) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.assembleSig(ClassWriter.java:291) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(Cla >> ssWriter.java:334) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode( >> ClassWriter.java:1271) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >> (ClassWriter.java:1158) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >> s(ClassWriter.java:1653) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassF >> ile(ClassWriter.java:1761) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass( >> ClassWriter.java:1679) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode( >> JavaCompiler.java:749) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >> JavaCompiler.java:1627) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >> JavaCompiler.java:1595) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile( >> JavaCompiler.java:965) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >> :306) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >> :165) >> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >> >> The cause is about intersection. The variable type that is infered >> becomes as a type with intersection, and will crash the compiler when >> generating a debug info. >> These are no problem. >> var s=List.of("a"); >> var s=List.of("a", 1, Optional.empty()); >> var s=List.of("a", 1, List.of()); >> >> Best regards. >> >> -- >> Naoki Kishida >> > > -- Naoki Kishida -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Mar 21 04:31:49 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Mar 2018 21:31:49 -0700 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: Message-ID: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> Shinya, Tests like the one you provided should normally have the full legal header, including the standard GPL license text. We only use the "/nodynamiccopyright/" version when the test is a negative test with a golden file that contains line numbers, such as a test using "@compile/fail/ref=file.out ....".?? This is to prevent the test from undergoing any automated processing should the license text ever change. -- Jon On 3/20/18 7:53 PM, ShinyaYoshida wrote: > Hi all and Kishida, > > Thank you for reporting the?issue. > > I've filed and created a patch: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 > Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ > > > Could someone review this? > > If it's fine, I'll commit to jdk repo and I'd like to backport to > jdk10 after backport approval. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 10:54 GMT+09:00 kishida naoki >: > > Hi all! > > I'm glad that JDK 10 is released. > But I've faced a compiler bug with `var`. > I'm using the build 46. > > This code crashes the compiler with `-g` option. > ``` > public class Main { > ??? void m() { > ??????? var s = java.util.List.of("a", 1); > ??? } > } > ``` > > $ javac Main.java -g > C:\src>javac Main.java -g > java.lang.AssertionError: Unexpected intersection type: > java.lang.Object&java.io > .Serializable&java.lang.Comparable java.lang.Object&java.io > .Serializable&java.lang.Comparable> > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) > ??????? at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > ??????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > The cause is about intersection. The variable type that is infered > becomes as a type with intersection, and will crash the compiler > when generating a debug info. > These are no problem. > ? var s=List.of("a"); > ? var s=List.of("a", 1, Optional.empty()); > ? var s=List.of("a", 1, List.of()); > > Best regards. > > -- > Naoki Kishida > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitterfoxc at gmail.com Wed Mar 21 04:39:31 2018 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 21 Mar 2018 13:39:31 +0900 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> References: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> Message-ID: Hi Jonathan, Thank you for the review. I was not sure the meaning of nodynamiccopyright in tests. Thank you for the pointing that. I've updated the webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/ Regards, shinyafox(Shinya Yoshida) 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons : > Shinya, > > Tests like the one you provided should normally have the full legal > header, including the standard GPL license text. > > We only use the "/nodynamiccopyright/" version when the test is a negative > test with a golden file that contains line numbers, such as a test using > "@compile/fail/ref=file.out ....". This is to prevent the test from > undergoing any automated processing should the license text ever change. > > -- Jon > > On 3/20/18 7:53 PM, ShinyaYoshida wrote: > > Hi all and Kishida, > > Thank you for reporting the issue. > > I've filed and created a patch: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 > Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ > > Could someone review this? > > If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 > after backport approval. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 10:54 GMT+09:00 kishida naoki : > >> Hi all! >> >> I'm glad that JDK 10 is released. >> But I've faced a compiler bug with `var`. >> I'm using the build 46. >> >> This code crashes the compiler with `-g` option. >> ``` >> public class Main { >> void m() { >> var s = java.util.List.of("a", 1); >> } >> } >> ``` >> >> $ javac Main.java -g >> C:\src>javac Main.java -g >> java.lang.AssertionError: Unexpected intersection type: java.lang.Object& >> java.io.Serializable&java.lang.Comparable> java.io.Serializable&java.lang.Comparable> >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner( >> ClassWriter.java:1043) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.classReference(ClassWriter.java:312) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleClassSig(Types.java:5182) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5114) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.assembleSig(ClassWriter.java:291) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5225) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleClassSig(Types.java:5201) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5114) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.assembleSig(ClassWriter.java:291) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(Cla >> ssWriter.java:334) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode( >> ClassWriter.java:1271) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >> (ClassWriter.java:1158) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >> s(ClassWriter.java:1653) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassF >> ile(ClassWriter.java:1761) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass( >> ClassWriter.java:1679) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode( >> JavaCompiler.java:749) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >> JavaCompiler.java:1627) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >> JavaCompiler.java:1595) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile( >> JavaCompiler.java:965) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >> :306) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >> :165) >> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >> >> The cause is about intersection. The variable type that is infered >> becomes as a type with intersection, and will crash the compiler when >> generating a debug info. >> These are no problem. >> var s=List.of("a"); >> var s=List.of("a", 1, Optional.empty()); >> var s=List.of("a", 1, List.of()); >> >> Best regards. >> >> -- >> Naoki Kishida >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Mar 21 04:51:18 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Mar 2018 21:51:18 -0700 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> Message-ID: Sorry to be picky, but you appear to have copied the legal header from a source file (in the src/ directory) and not from a nearby test (in the test/ directory). The difference is that source files are designated as subject to the "Classpath exception".? Test files are not. Generally, the rules are ... * New source files, in the src/ directory, use GPLv2 + Classpath Exception. * New tests, in the test/ directory, use GPLv2 .... except for files using @compile/fail/ref= * New tests, in the test/ directory, use /* nodynamiccopyright */? if the test uses golden files containing line numbers Generally, I recommend copying exactly the text from a nearby file, assuming the text looks "normal".? The only edit should be to initialize the year in the copyright line.?? I do not recommend editing anything else; we do occasionally run scripts to "audit the legal headers" and every so often, that turns up anomalies! -- Jon On 3/20/18 9:39 PM, ShinyaYoshida wrote: > Hi Jonathan, > Thank you for the review. > > I was not sure the meaning of nodynamiccopyright in tests. > Thank you for the pointing that. > > I've?updated the webrev: > http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/ > > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons > >: > > Shinya, > > Tests like the one you provided should normally have the full > legal header, including the standard GPL license text. > > We only use the "/nodynamiccopyright/" version when the test is a > negative test with a golden file that contains line numbers, such > as a test using "@compile/fail/ref=file.out ....".?? This is to > prevent the test from undergoing any automated processing should > the license text ever change. > > -- Jon > > > On 3/20/18 7:53 PM, ShinyaYoshida wrote: >> Hi all and Kishida, >> >> Thank you for reporting the?issue. >> >> I've filed and created a patch: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >> >> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >> >> >> Could someone review this? >> >> If it's fine, I'll commit to jdk repo and I'd like to backport to >> jdk10 after backport approval. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 10:54 GMT+09:00 kishida naoki > >: >> >> Hi all! >> >> I'm glad that JDK 10 is released. >> But I've faced a compiler bug with `var`. >> I'm using the build 46. >> >> This code crashes the compiler with `-g` option. >> ``` >> public class Main { >> ??? void m() { >> ??????? var s = java.util.List.of("a", 1); >> ??? } >> } >> ``` >> >> $ javac Main.java -g >> C:\src>javac Main.java -g >> java.lang.AssertionError: Unexpected intersection type: >> java.lang.Object&java.io >> .Serializable&java.lang.Comparable> java.lang.Object&java.io >> .Serializable&java.lang.Comparable> >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >> ??????? at >> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >> ??????? at >> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >> >> The cause is about intersection. The variable type that is >> infered becomes as a type with intersection, and will crash >> the compiler when generating a debug info. >> These are no problem. >> ? var s=List.of("a"); >> ? var s=List.of("a", 1, Optional.empty()); >> ? var s=List.of("a", 1, List.of()); >> >> Best regards. >> >> -- >> Naoki Kishida >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitterfoxc at gmail.com Wed Mar 21 04:56:54 2018 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 21 Mar 2018 13:56:54 +0900 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> Message-ID: Oops, I've copied from lvti/T8191959.java and it has such header... I'll fix my test header in same webrev URL. I'm not sure we should fix some other tests that have the wrong header like lvti/T8191959.java in this patch. Regards, shinyafox(Shinya Yoshida) 2018-03-21 13:51 GMT+09:00 Jonathan Gibbons : > Sorry to be picky, but you appear to have copied the legal header from a > source file (in the src/ directory) and not from a nearby test (in the > test/ directory). The difference is that source files are designated as > subject to the "Classpath exception". Test files are not. > > Generally, the rules are ... > > - New source files, in the src/ directory, use GPLv2 + Classpath > Exception. > - New tests, in the test/ directory, use GPLv2 .... except for files > using @compile/fail/ref= > - New tests, in the test/ directory, use /* nodynamiccopyright */ if > the test uses golden files containing line numbers > > Generally, I recommend copying exactly the text from a nearby file, > assuming the text looks "normal". The only edit should be to initialize > the year in the copyright line. I do not recommend editing anything else; > we do occasionally run scripts to "audit the legal headers" and every so > often, that turns up anomalies! > > -- Jon > > On 3/20/18 9:39 PM, ShinyaYoshida wrote: > > Hi Jonathan, > Thank you for the review. > > I was not sure the meaning of nodynamiccopyright in tests. > Thank you for the pointing that. > > I've updated the webrev: > http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/ > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons : > >> Shinya, >> >> Tests like the one you provided should normally have the full legal >> header, including the standard GPL license text. >> >> We only use the "/nodynamiccopyright/" version when the test is a >> negative test with a golden file that contains line numbers, such as a test >> using "@compile/fail/ref=file.out ....". This is to prevent the test from >> undergoing any automated processing should the license text ever change. >> >> -- Jon >> >> On 3/20/18 7:53 PM, ShinyaYoshida wrote: >> >> Hi all and Kishida, >> >> Thank you for reporting the issue. >> >> I've filed and created a patch: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >> >> Could someone review this? >> >> If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 >> after backport approval. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 10:54 GMT+09:00 kishida naoki : >> >>> Hi all! >>> >>> I'm glad that JDK 10 is released. >>> But I've faced a compiler bug with `var`. >>> I'm using the build 46. >>> >>> This code crashes the compiler with `-g` option. >>> ``` >>> public class Main { >>> void m() { >>> var s = java.util.List.of("a", 1); >>> } >>> } >>> ``` >>> >>> $ javac Main.java -g >>> C:\src>javac Main.java -g >>> java.lang.AssertionError: Unexpected intersection type: java.lang.Object& >>> java.io.Serializable&java.lang.Comparable>> java.io.Serializable&java.lang.Comparable> >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner( >>> ClassWriter.java:1043) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>> Generator.classReference(ClassWriter.java:312) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleClassSig(Types.java:5182) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleSig(Types.java:5114) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>> Generator.assembleSig(ClassWriter.java:291) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleSig(Types.java:5225) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleClassSig(Types.java:5201) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleSig(Types.java:5114) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>> Generator.assembleSig(ClassWriter.java:291) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(Cla >>> ssWriter.java:334) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(C >>> lassWriter.java:1271) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >>> (ClassWriter.java:1158) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >>> s(ClassWriter.java:1653) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassF >>> ile(ClassWriter.java:1761) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass( >>> ClassWriter.java:1679) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(J >>> avaCompiler.java:749) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >>> JavaCompiler.java:1627) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >>> JavaCompiler.java:1595) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(J >>> avaCompiler.java:965) >>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >>> :306) >>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >>> :165) >>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>> >>> The cause is about intersection. The variable type that is infered >>> becomes as a type with intersection, and will crash the compiler when >>> generating a debug info. >>> These are no problem. >>> var s=List.of("a"); >>> var s=List.of("a", 1, Optional.empty()); >>> var s=List.of("a", 1, List.of()); >>> >>> Best regards. >>> >>> -- >>> Naoki Kishida >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Mar 21 05:01:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Mar 2018 22:01:59 -0700 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> Message-ID: <17e0c95d-7b0d-3b4c-8f98-3d98f088e5b5@oracle.com> Shinya, Thanks for pointing out the problem in that other test. This is why we sometimes run scripts to check these headers! I recommend you fix your new test, and we'll separately check if there are any other tests using the Classpath Exception header. -- Jon On 3/20/18 9:56 PM, ShinyaYoshida wrote: > Oops, > I've copied from lvti/T8191959.java and it has such?header... > > I'll fix my test header in same webrev?URL. > > I'm not sure we should fix some other tests that have the?wrong header > like lvti/T8191959.java in this patch. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 13:51 GMT+09:00 Jonathan Gibbons > >: > > Sorry to be picky, but you appear to have copied the legal header > from a source file (in the src/ directory) and not from a nearby > test (in the test/ directory). The difference is that source files > are designated as subject to the "Classpath exception". Test files > are not. > > Generally, the rules are ... > > * New source files, in the src/ directory, use GPLv2 + Classpath > Exception. > * New tests, in the test/ directory, use GPLv2 .... except for > files using @compile/fail/ref= > * New tests, in the test/ directory, use /* nodynamiccopyright > */? if the test uses golden files containing line numbers > > Generally, I recommend copying exactly the text from a nearby > file, assuming the text looks "normal".? The only edit should be > to initialize the year in the copyright line.?? I do not recommend > editing anything else; we do occasionally run scripts to "audit > the legal headers" and every so often, that turns up anomalies! > > -- Jon > > > On 3/20/18 9:39 PM, ShinyaYoshida wrote: >> Hi Jonathan, >> Thank you for the review. >> >> I was not sure the meaning of nodynamiccopyright in tests. >> Thank you for the pointing that. >> >> I've?updated the webrev: >> http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/ >> >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons >> >: >> >> Shinya, >> >> Tests like the one you provided should normally have the full >> legal header, including the standard GPL license text. >> >> We only use the "/nodynamiccopyright/" version when the test >> is a negative test with a golden file that contains line >> numbers, such as a test using "@compile/fail/ref=file.out >> ....". This is to prevent the test from undergoing any >> automated processing should the license text ever change. >> >> -- Jon >> >> >> On 3/20/18 7:53 PM, ShinyaYoshida wrote: >>> Hi all and Kishida, >>> >>> Thank you for reporting the?issue. >>> >>> I've filed and created a patch: >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>> >>> >>> Could someone review this? >>> >>> If it's fine, I'll commit to jdk repo and I'd like to >>> backport to jdk10 after backport approval. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-21 10:54 GMT+09:00 kishida naoki >>> >: >>> >>> Hi all! >>> >>> I'm glad that JDK 10 is released. >>> But I've faced a compiler bug with `var`. >>> I'm using the build 46. >>> >>> This code crashes the compiler with `-g` option. >>> ``` >>> public class Main { >>> ??? void m() { >>> ??????? var s = java.util.List.of("a", 1); >>> ??? } >>> } >>> ``` >>> >>> $ javac Main.java -g >>> C:\src>javac Main.java -g >>> java.lang.AssertionError: Unexpected intersection type: >>> java.lang.Object&java.io >>> .Serializable&java.lang.Comparable>> extends java.lang.Object&java.io >>> .Serializable&java.lang.Comparable> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>> >>> The cause is about intersection. The variable type that >>> is infered becomes as a type with intersection, and will >>> crash the compiler when generating a debug info. >>> These are no problem. >>> ? var s=List.of("a"); >>> ? var s=List.of("a", 1, Optional.empty()); >>> ? var s=List.of("a", 1, List.of()); >>> >>> Best regards. >>> >>> -- >>> Naoki Kishida >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitterfoxc at gmail.com Wed Mar 21 05:04:53 2018 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Wed, 21 Mar 2018 14:04:53 +0900 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: <17e0c95d-7b0d-3b4c-8f98-3d98f088e5b5@oracle.com> References: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> <17e0c95d-7b0d-3b4c-8f98-3d98f088e5b5@oracle.com> Message-ID: Thank you for the direction, Jonathan. I've fixed my header: http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/test/langtools/tools/javac/T8199910.java.html Regards, shinyafox(Shinya Yoshida) 2018-03-21 14:01 GMT+09:00 Jonathan Gibbons : > Shinya, > > Thanks for pointing out the problem in that other test. This is why we > sometimes run scripts to check these headers! > > I recommend you fix your new test, and we'll separately check if there are > any other tests using the Classpath Exception header. > > -- Jon > > On 3/20/18 9:56 PM, ShinyaYoshida wrote: > > Oops, > I've copied from lvti/T8191959.java and it has such header... > > I'll fix my test header in same webrev URL. > > I'm not sure we should fix some other tests that have the wrong header > like lvti/T8191959.java in this patch. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 13:51 GMT+09:00 Jonathan Gibbons : > >> Sorry to be picky, but you appear to have copied the legal header from a >> source file (in the src/ directory) and not from a nearby test (in the >> test/ directory). The difference is that source files are designated as >> subject to the "Classpath exception". Test files are not. >> >> Generally, the rules are ... >> >> - New source files, in the src/ directory, use GPLv2 + Classpath >> Exception. >> - New tests, in the test/ directory, use GPLv2 .... except for files >> using @compile/fail/ref= >> - New tests, in the test/ directory, use /* nodynamiccopyright */ if >> the test uses golden files containing line numbers >> >> Generally, I recommend copying exactly the text from a nearby file, >> assuming the text looks "normal". The only edit should be to initialize >> the year in the copyright line. I do not recommend editing anything else; >> we do occasionally run scripts to "audit the legal headers" and every so >> often, that turns up anomalies! >> >> -- Jon >> >> On 3/20/18 9:39 PM, ShinyaYoshida wrote: >> >> Hi Jonathan, >> Thank you for the review. >> >> I was not sure the meaning of nodynamiccopyright in tests. >> Thank you for the pointing that. >> >> I've updated the webrev: >> http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/ >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons >> : >> >>> Shinya, >>> >>> Tests like the one you provided should normally have the full legal >>> header, including the standard GPL license text. >>> >>> We only use the "/nodynamiccopyright/" version when the test is a >>> negative test with a golden file that contains line numbers, such as a test >>> using "@compile/fail/ref=file.out ....". This is to prevent the test from >>> undergoing any automated processing should the license text ever change. >>> >>> -- Jon >>> >>> On 3/20/18 7:53 PM, ShinyaYoshida wrote: >>> >>> Hi all and Kishida, >>> >>> Thank you for reporting the issue. >>> >>> I've filed and created a patch: >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>> >>> Could someone review this? >>> >>> If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 >>> after backport approval. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-21 10:54 GMT+09:00 kishida naoki : >>> >>>> Hi all! >>>> >>>> I'm glad that JDK 10 is released. >>>> But I've faced a compiler bug with `var`. >>>> I'm using the build 46. >>>> >>>> This code crashes the compiler with `-g` option. >>>> ``` >>>> public class Main { >>>> void m() { >>>> var s = java.util.List.of("a", 1); >>>> } >>>> } >>>> ``` >>>> >>>> $ javac Main.java -g >>>> C:\src>javac Main.java -g >>>> java.lang.AssertionError: Unexpected intersection type: >>>> java.lang.Object&java.io.Serializable&java.lang.Comparable>>> java.lang.Object&java.io.Serializable&java.lang.Comparable> >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner( >>>> ClassWriter.java:1043) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>>> Generator.classReference(ClassWriter.java:312) >>>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>>> or.assembleClassSig(Types.java:5182) >>>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>>> or.assembleSig(Types.java:5114) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>>> Generator.assembleSig(ClassWriter.java:291) >>>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>>> or.assembleSig(Types.java:5225) >>>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>>> or.assembleClassSig(Types.java:5201) >>>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>>> or.assembleSig(Types.java:5114) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>>> Generator.assembleSig(ClassWriter.java:291) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(Cla >>>> ssWriter.java:334) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(C >>>> lassWriter.java:1271) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >>>> (ClassWriter.java:1158) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >>>> s(ClassWriter.java:1653) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassF >>>> ile(ClassWriter.java:1761) >>>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass( >>>> ClassWriter.java:1679) >>>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(J >>>> avaCompiler.java:749) >>>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >>>> JavaCompiler.java:1627) >>>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >>>> JavaCompiler.java:1595) >>>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(J >>>> avaCompiler.java:965) >>>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >>>> :306) >>>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >>>> :165) >>>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>> >>>> The cause is about intersection. The variable type that is infered >>>> becomes as a type with intersection, and will crash the compiler when >>>> generating a debug info. >>>> These are no problem. >>>> var s=List.of("a"); >>>> var s=List.of("a", 1, Optional.empty()); >>>> var s=List.of("a", 1, List.of()); >>>> >>>> Best regards. >>>> >>>> -- >>>> Naoki Kishida >>>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Mar 21 05:06:42 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 20 Mar 2018 22:06:42 -0700 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <0d2ec030-079a-8c5d-d42b-5045c3c9d943@oracle.com> <17e0c95d-7b0d-3b4c-8f98-3d98f088e5b5@oracle.com> Message-ID: <715b4421-e581-9228-d36c-3c8710425670@oracle.com> Looks good.? I'll let others comment on the fix itself. -- Jon On 3/20/18 10:04 PM, ShinyaYoshida wrote: > Thank you for the direction, Jonathan. > I've fixed my header: > http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/test/langtools/tools/javac/T8199910.java.html > > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 14:01 GMT+09:00 Jonathan Gibbons > >: > > Shinya, > > Thanks for pointing out the problem in that other test. This is > why we sometimes run scripts to check these headers! > > I recommend you fix your new test, and we'll separately check if > there are any other tests using the Classpath Exception header. > > -- Jon > > > On 3/20/18 9:56 PM, ShinyaYoshida wrote: >> Oops, >> I've copied from lvti/T8191959.java and it has such?header... >> >> I'll fix my test header in same webrev?URL. >> >> I'm not sure we should fix some other tests that have the?wrong >> header like lvti/T8191959.java in this patch. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 13:51 GMT+09:00 Jonathan Gibbons >> >: >> >> Sorry to be picky, but you appear to have copied the legal >> header from a source file (in the src/ directory) and not >> from a nearby test (in the test/ directory). The difference >> is that source files are designated as subject to the >> "Classpath exception".? Test files are not. >> >> Generally, the rules are ... >> >> * New source files, in the src/ directory, use GPLv2 + >> Classpath Exception. >> * New tests, in the test/ directory, use GPLv2 .... except >> for files using @compile/fail/ref= >> * New tests, in the test/ directory, use /* >> nodynamiccopyright */? if the test uses golden files >> containing line numbers >> >> Generally, I recommend copying exactly the text from a nearby >> file, assuming the text looks "normal". The only edit should >> be to initialize the year in the copyright line.?? I do not >> recommend editing anything else; we do occasionally run >> scripts to "audit the legal headers" and every so often, that >> turns up anomalies! >> >> -- Jon >> >> >> On 3/20/18 9:39 PM, ShinyaYoshida wrote: >>> Hi Jonathan, >>> Thank you for the review. >>> >>> I was not sure the meaning of nodynamiccopyright in tests. >>> Thank you for the pointing that. >>> >>> I've?updated the webrev: >>> http://cr.openjdk.java.net/~shinyafox/8199910/webrev.01/ >>> >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-21 13:31 GMT+09:00 Jonathan Gibbons >>> >> >: >>> >>> Shinya, >>> >>> Tests like the one you provided should normally have the >>> full legal header, including the standard GPL license text. >>> >>> We only use the "/nodynamiccopyright/" version when the >>> test is a negative test with a golden file that contains >>> line numbers, such as a test using >>> "@compile/fail/ref=file.out ....".?? This is to prevent >>> the test from undergoing any automated processing should >>> the license text ever change. >>> >>> -- Jon >>> >>> >>> On 3/20/18 7:53 PM, ShinyaYoshida wrote: >>>> Hi all and Kishida, >>>> >>>> Thank you for reporting the?issue. >>>> >>>> I've filed and created a patch: >>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>>> >>>> >>>> Could someone review this? >>>> >>>> If it's fine, I'll commit to jdk repo and I'd like to >>>> backport to jdk10 after backport approval. >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> 2018-03-21 10:54 GMT+09:00 kishida naoki >>>> >: >>>> >>>> Hi all! >>>> >>>> I'm glad that JDK 10 is released. >>>> But I've faced a compiler bug with `var`. >>>> I'm using the build 46. >>>> >>>> This code crashes the compiler with `-g` option. >>>> ``` >>>> public class Main { >>>> ??? void m() { >>>> ??????? var s = java.util.List.of("a", 1); >>>> ??? } >>>> } >>>> ``` >>>> >>>> $ javac Main.java -g >>>> C:\src>javac Main.java -g >>>> java.lang.AssertionError: Unexpected intersection >>>> type: java.lang.Object&java.io >>>> .Serializable&java.lang.Comparable>>> extends java.lang.Object&java.io >>>> .Serializable&java.lang.Comparable> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>> >>>> The cause is about intersection. The variable type >>>> that is infered becomes as a type with >>>> intersection, and will crash the compiler when >>>> generating a debug info. >>>> These are no problem. >>>> ? var s=List.of("a"); >>>> ? var s=List.of("a", 1, Optional.empty()); >>>> ? var s=List.of("a", 1, List.of()); >>>> >>>> Best regards. >>>> >>>> -- >>>> Naoki Kishida >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Mar 21 09:12:23 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 21 Mar 2018 10:12:23 +0100 Subject: RFR JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: <0cfa287b-8b20-8065-f6d8-7c8aaa515d00@oracle.com> References: <5AAA93FA.2020104@oracle.com> <0cfa287b-8b20-8065-f6d8-7c8aaa515d00@oracle.com> Message-ID: <5AB221F7.50007@oracle.com> Hi Maurizio, Thanks a lot for the comments. I've updated the patch according to the comments, updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8194978/webrev.01/ How does that look? Thanks, Jan On 20.3.2018 13:13, Maurizio Cimadamore wrote: > Hi Jan, > great work. The desugaring looks correct, at least there's nothing wrong > I can spot about it. Some comments: > > * resourceNonNull = TreeInfo.skipParens(resource).hasTag(NEWCLASS); > > Is the above needed? I can't seem to support evidence that this syntax > is even legal (in the branch where 'resource' is an expression, I mean) > > * The javadoc in Lower::makeTwrTry seems out of sync what is being > actually generated > > * I think the Lower code would benefit from better variable names - the > patch has a mixture of old names (e.g. primaryException) and new names > (e.g. 'closeStatement2'). I suggest picking a naming scheme in the > javadoc, and then stick to that in the code, so that there are explicit > references to what bit it is that we're currently generating. > > * I find the code in Gen bit subtle; you want the new finally block to > act as a finally - but only during the try block; that means, I believe, > that you want genFinalizer to do the usual thing (e.g. copy finalizer > body on exit points) but then skip doing that when it comes to > exceptions. That is, you don't want a catch-all block and you don't want > to copy finalizer body on exceptional paths. Another stacking would be > to completely replace the 'env.info.finalize' after the body is done, e.g. > > > > if (tree.finalizer.flags & BODY_ONLY_FINALIZE != 0) { > env.info.finalize == null; > } > > Wouldn't this be more consistent with what you are trying to achieve? > Seems to me that with the current approach there are side effects that > occur in the GenFinalizer even when afterBody is set (e.g. setting > finalizer gaps in the encl environment). > > Cheers > Maurizio > > On 15/03/18 15:40, Jan Lahoda wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194978 >> >> The issue here is that the bytecode generated for try-with-resources >> produces some unreachable instructions, and may be unnecessarily big. >> >> Consider this code: >> --- >> try (InputStream in = new FileInputStream(str)) { >> int read = in.read(); >> if (read == (-1)) return ; >> System.err.println(read); >> } >> --- >> >> javac desugars it to this: >> --- >> { >> final InputStream in = new FileInputStream(str); >> /*synthetic*/ Throwable primaryException0$ = null; >> try { >> int read = in.read(); >> if (read == (-1)) return; >> System.err.println(read); >> } catch (/*synthetic*/ final Throwable t$) { >> primaryException0$ = t$; >> throw t$; >> } finally { >> if (primaryException0$ != null) try { >> in.close(); >> } catch (/*synthetic*/ Throwable x2) { >> primaryException0$.addSuppressed(x2); >> } else in.close(); >> } >> } >> --- >> >> Which seems fine, but when the try-finally construct is written into >> bytecode, the "finally" section is duplicated into all >> (non-exceptional) exit points from the try body (it would also be >> copied to non-exception exit points from all catches, but there are no >> such exit points in this case). A rough idea on how the bytecode looks >> like is below - please note that some try-catches don't embed nicely >> with the rest of the code, so are denoted in comments only. >> >> --- >> { >> final InputStream in = new FileInputStream(str); >> /*synthetic*/ Throwable primaryException0$ = null; >> // try >> int read = in.read(); >> if (read == (-1)) { >> // catch Throwable: goto CATCH >> // catch any: goto FINALLY [1] >> //start injected finally >> if (primaryException0$ != null) try { // [2] >> in.close(); >> } catch (/*synthetic*/ Throwable x2) { >> primaryException0$.addSuppressed(x2); >> } else in.close(); >> //end injected finally >> >> return; >> } >> >> // try >> System.err.println(read); >> // catch Throwable: goto CATCH >> // catch any: goto FINALLY [1] >> >> //start injected finally >> if (primaryException0$ != null) try { // [2] >> in.close(); >> } catch (/*synthetic*/ Throwable x2) { >> primaryException0$.addSuppressed(x2); >> } else in.close(); >> //end injected finally >> >> //goto END >> >> CATCH: // catch (/*synthetic*/ final Throwable t$) >> // try >> primaryException0$ = t$; >> throw t$; >> // catch any: goto FINALLY >> FINALLY: >> if (primaryException0$ != null) try {// [3] >> in.close(); >> } catch (/*synthetic*/ Throwable x2) { >> primaryException0$.addSuppressed(x2); >> } else in.close(); >> END: >> } >> --- >> >> A few comments about the code: >> -[1]: this catches seem unnecessary: all Throwables have already been >> caught? >> -[2]: at this place, it is clear that primaryException0$ is null, so >> the is-non-null section is not useful >> -[3]: at this place, it is mostly clear that primaryException0$ is >> not-null, so the is-null section is not useful >> >> So, it seems it might be possible to construct the code so that only >> the needed sections of the finally would be used at the appropriate >> places. I.e. the original try-with-resources would get desugared to >> something like: >> >> --- >> { >> final InputStream in = new FileInputStream(str); >> try { >> int read = in.read(); >> if (read == (-1)) return; >> System.err.println(read); >> } body-only-finally { //copied to exit points in try body >> //only, not used as a real finally >> in.close(); >> } catch (/*synthetic*/ final Throwable t$) { >> try { >> in.close(); >> } catch (/*synthetic*/ Throwable x2) { >> t$.addSuppressed(x2); >> } >> throw t$; >> } >> } >> --- >> >> Which would then get generated to bytecode as: >> --- >> { >> final InputStream in = new FileInputStream(str); >> //try >> int read = in.read(); >> if (read == (-1)) { >> // catch Throwable: goto CATCH >> in.close(); >> return; >> } >> >> //try >> System.err.println(read); >> // catch Throwable: goto CATCH >> >> in.close(); >> >> //goto END >> >> CATCH: // catch (/*synthetic*/ final Throwable t$) >> try { >> in.close(); >> } catch (/*synthetic*/ Throwable x2) { >> t$.addSuppressed(x2); >> } >> throw t$; >> END: >> } >> --- >> >> The current desugaring is trying to pull out the finally code into a >> separate method when that appears to be worthwhile, but this proposed >> desugaring seems to be producing a better bytecode with less javac code. >> >> Does this updated desugaring/transformation look safe? >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8194978/webrev.00/ >> >> Thanks, >> Jan > From maurizio.cimadamore at oracle.com Wed Mar 21 11:02:48 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Mar 2018 11:02:48 +0000 Subject: RFR JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: <5AB221F7.50007@oracle.com> References: <5AAA93FA.2020104@oracle.com> <0cfa287b-8b20-8065-f6d8-7c8aaa515d00@oracle.com> <5AB221F7.50007@oracle.com> Message-ID: Looks great - please add a comment (no need for new webrev) in GenFInalizer::afterBody to explain why we are setting tryEnv.info.finalize to null (e.g. to disable Gen::genFinalizer). Maurizio On 21/03/18 09:12, Jan Lahoda wrote: > Hi Maurizio, > > Thanks a lot for the comments. I've updated the patch according to the > comments, updated webrev is here: > http://cr.openjdk.java.net/~jlahoda/8194978/webrev.01/ > > How does that look? > > Thanks, > ??? Jan > > On 20.3.2018 13:13, Maurizio Cimadamore wrote: >> Hi Jan, >> great work. The desugaring looks correct, at least there's nothing wrong >> I can spot about it. Some comments: >> >> * resourceNonNull = TreeInfo.skipParens(resource).hasTag(NEWCLASS); >> >> Is the above needed? I can't seem to support evidence that this syntax >> is even legal (in the branch where 'resource' is an expression, I mean) >> >> * The javadoc in Lower::makeTwrTry seems out of sync what is being >> actually generated >> >> * I think the Lower code would benefit from better variable names - the >> patch has a mixture of old names (e.g. primaryException) and new names >> (e.g. 'closeStatement2'). I suggest picking a naming scheme in the >> javadoc, and then stick to that in the code, so that there are explicit >> references to what bit it is that we're currently generating. >> >> * I find the code in Gen bit subtle; you want the new finally block to >> act as a finally - but only during the try block; that means, I believe, >> that you want genFinalizer to do the usual thing (e.g. copy finalizer >> body on exit points) but then skip doing that when it comes to >> exceptions. That is, you don't want a catch-all block and you don't want >> to copy finalizer body on exceptional paths. Another stacking would be >> to completely replace the 'env.info.finalize' after the body is done, >> e.g. >> >> >> >> if (tree.finalizer.flags & BODY_ONLY_FINALIZE != 0) { >> ??? env.info.finalize == null; >> } >> >> Wouldn't this be more consistent with what you are trying to achieve? >> Seems to me that with the current approach there are side effects that >> occur in the GenFinalizer even when afterBody is set (e.g. setting >> finalizer gaps in the encl environment). >> >> Cheers >> Maurizio >> >> On 15/03/18 15:40, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194978 >>> >>> The issue here is that the bytecode generated for try-with-resources >>> produces some unreachable instructions, and may be unnecessarily big. >>> >>> Consider this code: >>> --- >>> ??????? try (InputStream in = new FileInputStream(str)) { >>> ??????????? int read = in.read(); >>> ??????????? if (read == (-1)) return ; >>> ??????????? System.err.println(read); >>> ??????? } >>> --- >>> >>> javac desugars it to this: >>> --- >>> ??????? { >>> ??????????? final InputStream in = new FileInputStream(str); >>> ??????????? /*synthetic*/ Throwable primaryException0$ = null; >>> ??????????? try { >>> ??????????????? int read = in.read(); >>> ??????????????? if (read == (-1)) return; >>> ??????????????? System.err.println(read); >>> ??????????? } catch (/*synthetic*/ final Throwable t$) { >>> ??????????????? primaryException0$ = t$; >>> ??????????????? throw t$; >>> ??????????? } finally { >>> ??????????????? if (primaryException0$ != null) try { >>> ??????????????????? in.close(); >>> ??????????????? } catch (/*synthetic*/ Throwable x2) { >>> ??????????????????? primaryException0$.addSuppressed(x2); >>> ??????????????? } else in.close(); >>> ??????????? } >>> ??????? } >>> --- >>> >>> Which seems fine, but when the try-finally construct is written into >>> bytecode, the "finally" section is duplicated into all >>> (non-exceptional) exit points from the try body (it would also be >>> copied to non-exception exit points from all catches, but there are no >>> such exit points in this case). A rough idea on how the bytecode looks >>> like is below - please note that some try-catches don't embed nicely >>> with the rest of the code, so are denoted in comments only. >>> >>> --- >>> ??????? { >>> ??????????? final InputStream in = new FileInputStream(str); >>> ??????????? /*synthetic*/ Throwable primaryException0$ = null; >>> ??????????? // try >>> ??????????????? int read = in.read(); >>> ??????????????? if (read == (-1)) { >>> ??????????? // catch Throwable: goto CATCH >>> ??????????? // catch any: goto FINALLY [1] >>> ??????????????????? //start injected finally >>> ??????????????????? if (primaryException0$ != null) try { // [2] >>> ??????????????????????? in.close(); >>> ??????????????????? } catch (/*synthetic*/ Throwable x2) { >>> ??????????????????????? primaryException0$.addSuppressed(x2); >>> ??????????????????? } else in.close(); >>> ??????????????????? //end injected finally >>> >>> ??????????????????? return; >>> ??????????????? } >>> >>> ??????????? // try >>> ??????????????? System.err.println(read); >>> ??????????? // catch Throwable: goto CATCH >>> ??????????? // catch any: goto FINALLY [1] >>> >>> ??????????? //start injected finally >>> ??????????? if (primaryException0$ != null) try { // [2] >>> ??????????????? in.close(); >>> ??????????? } catch (/*synthetic*/ Throwable x2) { >>> ??????????????? primaryException0$.addSuppressed(x2); >>> ??????????? } else in.close(); >>> ??????????? //end injected finally >>> >>> ??????????? //goto END >>> >>> ??????????? CATCH: // catch (/*synthetic*/ final Throwable t$) >>> ??????????????? // try >>> ??????????????? primaryException0$ = t$; >>> ??????????????? throw t$; >>> ??????????????? // catch any: goto FINALLY >>> ??????????? FINALLY: >>> ??????????????? if (primaryException0$ != null) try {// [3] >>> ??????????????????? in.close(); >>> ??????????????? } catch (/*synthetic*/ Throwable x2) { >>> ??????????????????? primaryException0$.addSuppressed(x2); >>> ??????????????? } else in.close(); >>> ??????????? END: >>> ??????? } >>> --- >>> >>> A few comments about the code: >>> -[1]: this catches seem unnecessary: all Throwables have already been >>> caught? >>> -[2]: at this place, it is clear that primaryException0$ is null, so >>> the is-non-null section is not useful >>> -[3]: at this place, it is mostly clear that primaryException0$ is >>> not-null, so the is-null section is not useful >>> >>> So, it seems it might be possible to construct the code so that only >>> the needed sections of the finally would be used at the appropriate >>> places. I.e. the original try-with-resources would get desugared to >>> something like: >>> >>> --- >>> ??????? { >>> ??????????? final InputStream in = new FileInputStream(str); >>> ??????????? try { >>> ??????????????? int read = in.read(); >>> ??????????????? if (read == (-1)) return; >>> ??????????????? System.err.println(read); >>> ??????????? } body-only-finally { //copied to exit points in try body >>> ????????????????????????????????? //only, not used as a real finally >>> ??????????????? in.close(); >>> ??????????? } catch (/*synthetic*/ final Throwable t$) { >>> ??????????????? try { >>> ??????????????????? in.close(); >>> ??????????????? } catch (/*synthetic*/ Throwable x2) { >>> ??????????????????? t$.addSuppressed(x2); >>> ??????????????? } >>> ??????????????? throw t$; >>> ??????????? } >>> ??????? } >>> --- >>> >>> Which would then get generated to bytecode as: >>> --- >>> ??????? { >>> ??????????? final InputStream in = new FileInputStream(str); >>> ??????????? //try >>> ??????????????? int read = in.read(); >>> ??????????????? if (read == (-1)) { >>> ??????????? // catch Throwable: goto CATCH >>> ??????????????????? in.close(); >>> ??????????????????? return; >>> ??????????????? } >>> >>> ??????????? //try >>> ??????????????? System.err.println(read); >>> ??????????? // catch Throwable: goto CATCH >>> >>> ??????????? in.close(); >>> >>> ??????????? //goto END >>> >>> ??????????? CATCH: // catch (/*synthetic*/ final Throwable t$) >>> ??????????????? try { >>> ??????????????????? in.close(); >>> ??????????????? } catch (/*synthetic*/ Throwable x2) { >>> ??????????????????? t$.addSuppressed(x2); >>> ??????????????? } >>> ??????????????? throw t$; >>> ??????????? END: >>> ??????? } >>> --- >>> >>> The current desugaring is trying to pull out the finally code into a >>> separate method when that appears to be worthwhile, but this proposed >>> desugaring seems to be producing a better bytecode with less javac >>> code. >>> >>> Does this updated desugaring/transformation look safe? >>> >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8194978/webrev.00/ >>> >>> Thanks, >>> ???? Jan >> From maurizio.cimadamore at oracle.com Wed Mar 21 16:02:31 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Mar 2018 16:02:31 +0000 Subject: bug: compiler crashes with `var s=List.of("a",1)` In-Reply-To: References: Message-ID: <04eaa919-fb32-1d08-00d0-5bc261dd2f80@oracle.com> Seems like some missing erasure when writing LocalVariableTypeType attribute. Thanks for the prompt report. Maurizio On 21/03/18 01:54, kishida naoki wrote: > Hi all! > > I'm glad that JDK 10 is released. > But I've faced a compiler bug with `var`. > I'm using the build 46. > > This code crashes the compiler with `-g` option. > ``` > public class Main { > ??? void m() { > ??????? var s = java.util.List.of("a", 1); > ??? } > } > ``` > > $ javac Main.java -g > C:\src>javac Main.java -g > java.lang.AssertionError: Unexpected intersection type: > java.lang.Object&java.io.Serializable&java.lang.Comparable java.lang.Object&java.io.Serializable&java.lang.Comparable> > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) > ??????? at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > ??????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > The cause is about intersection. The variable type that is infered > becomes as a type with intersection, and will crash the compiler when > generating a debug info. > These are no problem. > ? var s=List.of("a"); > ? var s=List.of("a", 1, Optional.empty()); > ? var s=List.of("a", 1, List.of()); > > Best regards. > > -- > Naoki Kishida -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Mar 21 16:09:51 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Mar 2018 16:09:51 +0000 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: Message-ID: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> Hi Shinya, thanks for the fix; unfortunately, I believe it is not correct. An intersection type should be erased by the time we get here; we had a similar issue in the past with multicatch: https://bugs.openjdk.java.net/browse/JDK-6999635 https://bugs.openjdk.java.net/browse/JDK-7005371 I will take a closer look as to find out exactly what's going on; the fix for multicatch should have taken care for this one too... Maurizio On 21/03/18 02:53, ShinyaYoshida wrote: > Hi all and Kishida, > > Thank you for reporting the?issue. > > I've filed and created a patch: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 > Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ > > > Could someone review this? > > If it's fine, I'll commit to jdk repo and I'd like to backport to > jdk10 after backport approval. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 10:54 GMT+09:00 kishida naoki >: > > Hi all! > > I'm glad that JDK 10 is released. > But I've faced a compiler bug with `var`. > I'm using the build 46. > > This code crashes the compiler with `-g` option. > ``` > public class Main { > ??? void m() { > ??????? var s = java.util.List.of("a", 1); > ??? } > } > ``` > > $ javac Main.java -g > C:\src>javac Main.java -g > java.lang.AssertionError: Unexpected intersection type: > java.lang.Object&java.io > .Serializable&java.lang.Comparable java.lang.Object&java.io > .Serializable&java.lang.Comparable> > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) > ??????? at > jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) > ??????? at > jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) > ??????? at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > ??????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > The cause is about intersection. The variable type that is infered > becomes as a type with intersection, and will crash the compiler > when generating a debug info. > These are no problem. > ? var s=List.of("a"); > ? var s=List.of("a", 1, Optional.empty()); > ? var s=List.of("a", 1, List.of()); > > Best regards. > > -- > Naoki Kishida > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Mar 21 16:26:19 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Mar 2018 16:26:19 +0000 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> Message-ID: <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> Attached is my take on the problem. As I said, we added some logic to handle this with multi-catch, but unfortunately the current logic only handle cases where you have a type like A & B and not cases where you have Foo. I've enhanced the check to do a proper non-denotable visit on the type of the local variable, rather than just doing a simple check as before. Let me know what you think - and also if you'd like me to go ahead with it, or if you still want to take this. Cheers Maurizio On 21/03/18 16:09, Maurizio Cimadamore wrote: > > Hi Shinya, > thanks for the fix; unfortunately, I believe it is not correct. An > intersection type should be erased by the time we get here; we had a > similar issue in the past with multicatch: > > https://bugs.openjdk.java.net/browse/JDK-6999635 > > https://bugs.openjdk.java.net/browse/JDK-7005371 > > I will take a closer look as to find out exactly what's going on; the > fix for multicatch should have taken care for this one too... > > Maurizio > > > On 21/03/18 02:53, ShinyaYoshida wrote: >> Hi all and Kishida, >> >> Thank you for reporting the?issue. >> >> I've filed and created a patch: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >> >> >> Could someone review this? >> >> If it's fine, I'll commit to jdk repo and I'd like to backport to >> jdk10 after backport approval. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 10:54 GMT+09:00 kishida naoki > >: >> >> Hi all! >> >> I'm glad that JDK 10 is released. >> But I've faced a compiler bug with `var`. >> I'm using the build 46. >> >> This code crashes the compiler with `-g` option. >> ``` >> public class Main { >> ??? void m() { >> ??????? var s = java.util.List.of("a", 1); >> ??? } >> } >> ``` >> >> $ javac Main.java -g >> C:\src>javac Main.java -g >> java.lang.AssertionError: Unexpected intersection type: >> java.lang.Object&java.io >> .Serializable&java.lang.Comparable> java.lang.Object&java.io >> .Serializable&java.lang.Comparable> >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >> ??????? at >> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >> ??????? at >> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >> ??????? at >> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >> ??????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >> >> The cause is about intersection. The variable type that is >> infered becomes as a type with intersection, and will crash the >> compiler when generating a debug info. >> These are no problem. >> ? var s=List.of("a"); >> ? var s=List.of("a", 1, Optional.empty()); >> ? var s=List.of("a", 1, List.of()); >> >> Best regards. >> >> -- >> Naoki Kishida >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8199910.patch Type: text/x-patch Size: 2381 bytes Desc: not available URL: From bitterfoxc at gmail.com Wed Mar 21 17:08:15 2018 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 22 Mar 2018 02:08:15 +0900 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> Message-ID: Hi Maurizio, Thank you for the pointing that. I've read the logic around your fix. It seems to me it's reasonable. We don't need to handle intersection type in enterInner because inner classes are handled triggered by a symbol of another part. I could confirm the test passes. Please go ahead! Thank you for the opportunity to learn the logic around that. Regards, shinyafox(Shinya Yoshida) 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore < maurizio.cimadamore at oracle.com>: > Attached is my take on the problem. > > As I said, we added some logic to handle this with multi-catch, but > unfortunately the current logic only handle cases where you have a type > like A & B and not cases where you have Foo. > > I've enhanced the check to do a proper non-denotable visit on the type of > the local variable, rather than just doing a simple check as before. > > Let me know what you think - and also if you'd like me to go ahead with > it, or if you still want to take this. > > Cheers > Maurizio > > On 21/03/18 16:09, Maurizio Cimadamore wrote: > > Hi Shinya, > thanks for the fix; unfortunately, I believe it is not correct. An > intersection type should be erased by the time we get here; we had a > similar issue in the past with multicatch: > > https://bugs.openjdk.java.net/browse/JDK-6999635 > > https://bugs.openjdk.java.net/browse/JDK-7005371 > > I will take a closer look as to find out exactly what's going on; the fix > for multicatch should have taken care for this one too... > > Maurizio > > On 21/03/18 02:53, ShinyaYoshida wrote: > > Hi all and Kishida, > > Thank you for reporting the issue. > > I've filed and created a patch: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 > Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ > > Could someone review this? > > If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 > after backport approval. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-21 10:54 GMT+09:00 kishida naoki : > >> Hi all! >> >> I'm glad that JDK 10 is released. >> But I've faced a compiler bug with `var`. >> I'm using the build 46. >> >> This code crashes the compiler with `-g` option. >> ``` >> public class Main { >> void m() { >> var s = java.util.List.of("a", 1); >> } >> } >> ``` >> >> $ javac Main.java -g >> C:\src>javac Main.java -g >> java.lang.AssertionError: Unexpected intersection type: java.lang.Object& >> java.io.Serializable&java.lang.Comparable> java.io.Serializable&java.lang.Comparable> >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner( >> ClassWriter.java:1043) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.classReference(ClassWriter.java:312) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleClassSig(Types.java:5182) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5114) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.assembleSig(ClassWriter.java:291) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5225) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleClassSig(Types.java:5201) >> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >> or.assembleSig(Types.java:5114) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >> Generator.assembleSig(ClassWriter.java:291) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(Cla >> ssWriter.java:334) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode( >> ClassWriter.java:1271) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >> (ClassWriter.java:1158) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >> s(ClassWriter.java:1653) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassF >> ile(ClassWriter.java:1761) >> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass( >> ClassWriter.java:1679) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode( >> JavaCompiler.java:749) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >> JavaCompiler.java:1627) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >> JavaCompiler.java:1595) >> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile( >> JavaCompiler.java:965) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >> :306) >> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >> :165) >> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >> >> The cause is about intersection. The variable type that is infered >> becomes as a type with intersection, and will crash the compiler when >> generating a debug info. >> These are no problem. >> var s=List.of("a"); >> var s=List.of("a", 1, Optional.empty()); >> var s=List.of("a", 1, List.of()); >> >> Best regards. >> >> -- >> Naoki Kishida >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Mar 21 17:26:24 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Mar 2018 17:26:24 +0000 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> Message-ID: <44b380d9-91d9-5c68-692d-b70410f121a4@oracle.com> On 21/03/18 17:08, ShinyaYoshida wrote: > Hi Maurizio, > Thank you for the pointing that. > > I've read the logic around your fix. It seems to me?it's reasonable. > We don't need to handle intersection type in enterInner?because inner > classes are handled triggered by a symbol?of another part. > > I could confirm the test passes. > Please go ahead! Thanks for checking; I'll run some tests myself and push (might need another review for that one). Cheers Maurizio > > Thank you for the opportunity?to learn the logic around that. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore > >: > > Attached is my take on the problem. > > As I said, we added some logic to handle this with multi-catch, > but unfortunately the current logic only handle cases where you > have a type like A & B and not cases where you have Foo. > > I've enhanced the check to do a proper non-denotable visit on the > type of the local variable, rather than just doing a simple check > as before. > > Let me know what you think - and also if you'd like me to go ahead > with it, or if you still want to take this. > > Cheers > Maurizio > > > On 21/03/18 16:09, Maurizio Cimadamore wrote: >> >> Hi Shinya, >> thanks for the fix; unfortunately, I believe it is not correct. >> An intersection type should be erased by the time we get here; we >> had a similar issue in the past with multicatch: >> >> https://bugs.openjdk.java.net/browse/JDK-6999635 >> >> >> https://bugs.openjdk.java.net/browse/JDK-7005371 >> >> >> I will take a closer look as to find out exactly what's going on; >> the fix for multicatch should have taken care for this one too... >> >> Maurizio >> >> >> On 21/03/18 02:53, ShinyaYoshida wrote: >>> Hi all and Kishida, >>> >>> Thank you for reporting the?issue. >>> >>> I've filed and created a patch: >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>> >>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>> >>> >>> Could someone review this? >>> >>> If it's fine, I'll commit to jdk repo and I'd like to backport >>> to jdk10 after backport approval. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-21 10:54 GMT+09:00 kishida naoki >> >: >>> >>> Hi all! >>> >>> I'm glad that JDK 10 is released. >>> But I've faced a compiler bug with `var`. >>> I'm using the build 46. >>> >>> This code crashes the compiler with `-g` option. >>> ``` >>> public class Main { >>> ??? void m() { >>> ??????? var s = java.util.List.of("a", 1); >>> ??? } >>> } >>> ``` >>> >>> $ javac Main.java -g >>> C:\src>javac Main.java -g >>> java.lang.AssertionError: Unexpected intersection type: >>> java.lang.Object&java.io >>> .Serializable&java.lang.Comparable>> java.lang.Object&java.io >>> .Serializable&java.lang.Comparable> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>> >>> The cause is about intersection. The variable type that is >>> infered becomes as a type with intersection, and will crash >>> the compiler when generating a debug info. >>> These are no problem. >>> ? var s=List.of("a"); >>> ? var s=List.of("a", 1, Optional.empty()); >>> ? var s=List.of("a", 1, List.of()); >>> >>> Best regards. >>> >>> -- >>> Naoki Kishida >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitterfoxc at gmail.com Wed Mar 21 17:39:51 2018 From: bitterfoxc at gmail.com (ShinyaYoshida) Date: Thu, 22 Mar 2018 02:39:51 +0900 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> Message-ID: Hi Maurizio, Here is another question. Is there a possibility of supporting the representation of an intersection or union type in a signature format for debugging use or something? Recently, we see intersection type or union type in Java code often than before. We may see it more often because we can represent intersection types as a type of variables using var feature after JDK 10. So may it help debugging with var or something like that if it present? Regards, shinyafox(Shinya Yoshida) 2018-03-22 2:08 GMT+09:00 ShinyaYoshida : > Hi Maurizio, > Thank you for the pointing that. > > I've read the logic around your fix. It seems to me it's reasonable. > We don't need to handle intersection type in enterInner because inner > classes are handled triggered by a symbol of another part. > > I could confirm the test passes. > Please go ahead! > > Thank you for the opportunity to learn the logic around that. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore com>: > >> Attached is my take on the problem. >> >> As I said, we added some logic to handle this with multi-catch, but >> unfortunately the current logic only handle cases where you have a type >> like A & B and not cases where you have Foo. >> >> I've enhanced the check to do a proper non-denotable visit on the type of >> the local variable, rather than just doing a simple check as before. >> >> Let me know what you think - and also if you'd like me to go ahead with >> it, or if you still want to take this. >> >> Cheers >> Maurizio >> >> On 21/03/18 16:09, Maurizio Cimadamore wrote: >> >> Hi Shinya, >> thanks for the fix; unfortunately, I believe it is not correct. An >> intersection type should be erased by the time we get here; we had a >> similar issue in the past with multicatch: >> >> https://bugs.openjdk.java.net/browse/JDK-6999635 >> >> https://bugs.openjdk.java.net/browse/JDK-7005371 >> >> I will take a closer look as to find out exactly what's going on; the fix >> for multicatch should have taken care for this one too... >> >> Maurizio >> >> On 21/03/18 02:53, ShinyaYoshida wrote: >> >> Hi all and Kishida, >> >> Thank you for reporting the issue. >> >> I've filed and created a patch: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >> >> Could someone review this? >> >> If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 >> after backport approval. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 10:54 GMT+09:00 kishida naoki : >> >>> Hi all! >>> >>> I'm glad that JDK 10 is released. >>> But I've faced a compiler bug with `var`. >>> I'm using the build 46. >>> >>> This code crashes the compiler with `-g` option. >>> ``` >>> public class Main { >>> void m() { >>> var s = java.util.List.of("a", 1); >>> } >>> } >>> ``` >>> >>> $ javac Main.java -g >>> C:\src>javac Main.java -g >>> java.lang.AssertionError: Unexpected intersection type: java.lang.Object& >>> java.io.Serializable&java.lang.Comparable>> java.io.Serializable&java.lang.Comparable> >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner( >>> ClassWriter.java:1043) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>> Generator.classReference(ClassWriter.java:312) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleClassSig(Types.java:5182) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleSig(Types.java:5114) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>> Generator.assembleSig(ClassWriter.java:291) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleSig(Types.java:5225) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleClassSig(Types.java:5201) >>> at jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerat >>> or.assembleSig(Types.java:5114) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignature >>> Generator.assembleSig(ClassWriter.java:291) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(Cla >>> ssWriter.java:334) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(C >>> lassWriter.java:1271) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >>> (ClassWriter.java:1158) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod >>> s(ClassWriter.java:1653) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassF >>> ile(ClassWriter.java:1761) >>> at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass( >>> ClassWriter.java:1679) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(J >>> avaCompiler.java:749) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >>> JavaCompiler.java:1627) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate( >>> JavaCompiler.java:1595) >>> at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(J >>> avaCompiler.java:965) >>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >>> :306) >>> at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java >>> :165) >>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>> >>> The cause is about intersection. The variable type that is infered >>> becomes as a type with intersection, and will crash the compiler when >>> generating a debug info. >>> These are no problem. >>> var s=List.of("a"); >>> var s=List.of("a", 1, Optional.empty()); >>> var s=List.of("a", 1, List.of()); >>> >>> Best regards. >>> >>> -- >>> Naoki Kishida >>> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Mar 21 20:56:06 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Mar 2018 20:56:06 +0000 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> Message-ID: Here's an updated webrev - passes all tests. In addition to the tests already provided, I also tweaked the LVTI test harness to also use -g and report crashes (I verified that in this mode the harness crashes w/o the patch). Webrev here: http://cr.openjdk.java.net/~mcimadamore/8199910-v3/ Cheers Maurizio On 21/03/18 17:08, ShinyaYoshida wrote: > Hi Maurizio, > Thank you for the pointing that. > > I've read the logic around your fix. It seems to me?it's reasonable. > We don't need to handle intersection type in enterInner?because inner > classes are handled triggered by a symbol?of another part. > > I could confirm the test passes. > Please go ahead! > > Thank you for the opportunity?to learn the logic around that. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore > >: > > Attached is my take on the problem. > > As I said, we added some logic to handle this with multi-catch, > but unfortunately the current logic only handle cases where you > have a type like A & B and not cases where you have Foo. > > I've enhanced the check to do a proper non-denotable visit on the > type of the local variable, rather than just doing a simple check > as before. > > Let me know what you think - and also if you'd like me to go ahead > with it, or if you still want to take this. > > Cheers > Maurizio > > > On 21/03/18 16:09, Maurizio Cimadamore wrote: >> >> Hi Shinya, >> thanks for the fix; unfortunately, I believe it is not correct. >> An intersection type should be erased by the time we get here; we >> had a similar issue in the past with multicatch: >> >> https://bugs.openjdk.java.net/browse/JDK-6999635 >> >> >> https://bugs.openjdk.java.net/browse/JDK-7005371 >> >> >> I will take a closer look as to find out exactly what's going on; >> the fix for multicatch should have taken care for this one too... >> >> Maurizio >> >> >> On 21/03/18 02:53, ShinyaYoshida wrote: >>> Hi all and Kishida, >>> >>> Thank you for reporting the?issue. >>> >>> I've filed and created a patch: >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>> >>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>> >>> >>> Could someone review this? >>> >>> If it's fine, I'll commit to jdk repo and I'd like to backport >>> to jdk10 after backport approval. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-21 10:54 GMT+09:00 kishida naoki >> >: >>> >>> Hi all! >>> >>> I'm glad that JDK 10 is released. >>> But I've faced a compiler bug with `var`. >>> I'm using the build 46. >>> >>> This code crashes the compiler with `-g` option. >>> ``` >>> public class Main { >>> ??? void m() { >>> ??????? var s = java.util.List.of("a", 1); >>> ??? } >>> } >>> ``` >>> >>> $ javac Main.java -g >>> C:\src>javac Main.java -g >>> java.lang.AssertionError: Unexpected intersection type: >>> java.lang.Object&java.io >>> .Serializable&java.lang.Comparable>> java.lang.Object&java.io >>> .Serializable&java.lang.Comparable> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>> >>> The cause is about intersection. The variable type that is >>> infered becomes as a type with intersection, and will crash >>> the compiler when generating a debug info. >>> These are no problem. >>> ? var s=List.of("a"); >>> ? var s=List.of("a", 1, Optional.empty()); >>> ? var s=List.of("a", 1, List.of()); >>> >>> Best regards. >>> >>> -- >>> Naoki Kishida >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Mar 21 21:04:33 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 21 Mar 2018 21:04:33 +0000 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> Message-ID: Hi, I think extending the format of the signature attribute is something that *could* be done - but I would only consider it if there was a significant payoff (e.g. in the context of type specialization, etc.). We already have variable types today whose type is not represented in the LocalVariableTypeTable attribute due to denotability issues - of course 'var' is going to make that more frequent, but it doesn't change the substance. Also, take into account that changing sig attribute is not a small task - you also need to enhance the java.lang.reflect.Type API that goes with it - if the signature is more expressive, you might want to need additional Type subclasses to reflect over intersection types. On a related note, the only place where these weird types can pop up is in local variables - e.g. inside method bodies; this information in no way affects what can happen in other compilation units etc. - this is good (e.g. scope is limited - you might even get away w/o reflection changes) but begs the question as to whether is worth changing the grammar of the attribute for such a narrow case. Maurizio On 21/03/18 17:39, ShinyaYoshida wrote: > Hi Maurizio, > Here is another question. > > Is there a possibility of supporting the representation of an > intersection or union type in a signature format for debugging use or > something? > Recently, we see intersection type or union type in Java code often > than before. > We may see it more often because we can represent intersection types > as a type of variables using var feature after JDK 10. > So may it help debugging with var or something like that if it present? > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-22 2:08 GMT+09:00 ShinyaYoshida >: > > Hi Maurizio, > Thank you for the pointing that. > > I've read the logic around your fix. It seems to me?it's reasonable. > We don't need to handle intersection type in enterInner?because > inner classes are handled triggered by a symbol?of another part. > > I could confirm the test passes. > Please go ahead! > > Thank you for the opportunity?to learn the logic around that. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore > >: > > Attached is my take on the problem. > > As I said, we added some logic to handle this with > multi-catch, but unfortunately the current logic only handle > cases where you have a type like A & B and not cases where you > have Foo. > > I've enhanced the check to do a proper non-denotable visit on > the type of the local variable, rather than just doing a > simple check as before. > > Let me know what you think - and also if you'd like me to go > ahead with it, or if you still want to take this. > > Cheers > Maurizio > > > On 21/03/18 16:09, Maurizio Cimadamore wrote: >> >> Hi Shinya, >> thanks for the fix; unfortunately, I believe it is not >> correct. An intersection type should be erased by the time we >> get here; we had a similar issue in the past with multicatch: >> >> https://bugs.openjdk.java.net/browse/JDK-6999635 >> >> >> https://bugs.openjdk.java.net/browse/JDK-7005371 >> >> >> I will take a closer look as to find out exactly what's going >> on; the fix for multicatch should have taken care for this >> one too... >> >> Maurizio >> >> >> On 21/03/18 02:53, ShinyaYoshida wrote: >>> Hi all and Kishida, >>> >>> Thank you for reporting the?issue. >>> >>> I've filed and created a patch: >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>> >>> >>> Could someone review this? >>> >>> If it's fine, I'll commit to jdk repo and I'd like to >>> backport to jdk10 after backport approval. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-21 10:54 GMT+09:00 kishida naoki >>> >: >>> >>> Hi all! >>> >>> I'm glad that JDK 10 is released. >>> But I've faced a compiler bug with `var`. >>> I'm using the build 46. >>> >>> This code crashes the compiler with `-g` option. >>> ``` >>> public class Main { >>> ??? void m() { >>> ??????? var s = java.util.List.of("a", 1); >>> ??? } >>> } >>> ``` >>> >>> $ javac Main.java -g >>> C:\src>javac Main.java -g >>> java.lang.AssertionError: Unexpected intersection type: >>> java.lang.Object&java.io >>> .Serializable&java.lang.Comparable>> extends java.lang.Object&java.io >>> .Serializable&java.lang.Comparable> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>> >>> The cause is about intersection. The variable type that >>> is infered becomes as a type with intersection, and will >>> crash the compiler when generating a debug info. >>> These are no problem. >>> ? var s=List.of("a"); >>> ? var s=List.of("a", 1, Optional.empty()); >>> ? var s=List.of("a", 1, List.of()); >>> >>> Best regards. >>> >>> -- >>> Naoki Kishida >>> >>> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Mar 22 05:23:49 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 21 Mar 2018 22:23:49 -0700 Subject: Some thoughts on javax.lang.model support for preview language features In-Reply-To: References: <63ba79b2-4b81-5bcd-8d62-4c336f875341@oracle.com> Message-ID: <273bf807-2549-3c6f-c39c-1efcc13c7de1@oracle.com> Hi Maurizio, As a historical note, in times past javac did not have a 1:1 mapping between public -target alternatives and values in the Target enumeration; there were some synthetic values we've since removed (JDK-8010179: Remove transitional target values from javac). However, I agree it is preferable to not introduce such complications into the Source enum unless necessary. If a PREVIEW constant were to be added, I think it would be reasonable to define latest and latestSupported to *not* return PREVIEW. Are are some dual method pairs in javax.annotation.Processor and javax.annotation.ProcessingEnvironment including getSupportedSourceVersion and getSourceVersion. If the preview-ness is not conveyed view a new SourceVersion enum, then I'd recommend: ???? default isPreviewSupported() { return false; } as you've suggested and a similar default method on ProcessingEnvironment. (Further support could involved an update to AbstractProcessor to parse a PreviewSupported annotation, etc., but I don't think the duty cycle would be high enough to need this.) Cheers, -Joe On 3/16/2018 6:02 AM, Maurizio Cimadamore wrote: > Hi Joe, > I did some experiments along those lines few weeks ago and concluded > that, while the idea of having a separate source version for PREVIEW > is attractive, it is not as straightforward as it seems. Here is some > evidence: > > * in javac, there's a 1-1 mapping between javac's Source enum > constants and SourceVersion enum constants, which means if we have > SourceVersion.PREVIEW, we probably should have Source.PREVIEW too > > * pulling more on that string, in javac there's a 1-1 mapping between > the source levels available in the Source enum and the values that can > be passed to the -source flag. But, if we add Source.PREVIEW, this > would break that invariant, and we would now have a source version > that is 'non denotable' via command line options. This distinction > seems to have deep implications both in javac and in tests. > > * diagnostics; the set of diagnostics given for preview features when > they are not enabled is almost certainly distinct from those given > when you e.g. try to use lambdas with -source 7. > > * more onto the point - SourceVesrion has a couple of static methods: > > public static SourceVersion latest() > > private static SourceVersion getLatestSupported() > > What should these method return? 11 or PREVIEW? Also, note that the > last method is affected by the value of the runtime property > "java.specification.version", so any change here require some synergy > with the runtime. > > > All this left a sour taste on my mouth; having PREVIEW to mean > Source.N + 1 seems appealing, but at the same time very problematic; > if we instead treat preview has an orthogonal toggle, a lot of the > complexity just disappears. I'm not sure what an equivalent of that > toggle might be in the JLM-land - probably another way to get there > would be to add a default method to the Processor interface - e.g. > > default isPreviewSupported() { return false; } > > And then augment the SupportedSourceVersion annotation: > > public @interface SupportedSourceVersion { > ??? SourceVersion value(); > ??? boolean preview default false; > } > > Thoughts? > > Maurizio > > > On 16/03/18 04:45, Joseph D. Darcy wrote: >> Hello, >> >> As you may have seen elsewhere, JEP 12: Preview Language and VM >> Features (http://openjdk.java.net/jeps/12) is proposing to include >> preview language features as part of the platform. The JEP has been >> discussed in various threads on jdk-dev ([1], [2], etc.) Since one of >> the various and sundry aspects of supporting a language is updating >> the language model API [3], it is worthwhile to discuss a few >> alternatives in terms of how the language model API could support >> preview features >> >> The javax.lang.model APIs are part of the Java SE API and thus live >> by the strict compatibility rules of that space, with some slight >> accommodations for certain technical aspects of the API. >> >> For the sake of argument, let's assume we do *not* want to change >> mainline javax.lang.model API to describe the preview features. The >> ElementKind.OTHER and TypeKind.OTHER values are meant to indicate an >> object is outside of the values for the standardized system. Subtypes >> of the modeling interfaces and visitors can then be used as needed >> for the specialized and extended system. (Joel Borggren-Franck and I >> used this approach in the javax.lang.model backed by core reflection >> prototype from a few years back, JEP 119: javax.lang.model >> Implementation Backed by Core Reflection.) >> >> However, using such an extended API inside javac (or in annotation >> processors) is tedious. >> >> One could imagine a system where a different, updated, version of >> javax.lang.model were used when the incubating features were unlocked >> via upgrading its module or the like, but that would be awkward as well. >> >> If our intention is to only support one preview version at a time, >> part of the API approach could be to add a "PREVIEW" constant to >> SourceVersion that was always the most latest version. In other words >> in JDK 11 we'd have >> >> ??? RELEASE_0, >> ??? ... >> ??? RELEASE_11, >> ??? PREVIEW; >> >> and in JDK 12 >> >> ??? RELEASE_0, >> ??? ... >> ??? RELEASE_11, >> ??? RELEASE_12, >> ??? PREVIEW; >> >> Processors could them indicate they support the "PREVIEW" release value. >> >> The longer-term javax.lang.model API evolution to-do list includes >> thinking about other ways to evolve the visitors to support new >> language features. We've stopped automatically adding new visitors >> with every release, now only adding them as needed and we didn't need >> a new batch for 10. We could potentially have a similar structure for >> visitors with a cadre of "Preview" visitors as the most specialized >> versions in a release and new per-release visitors getting introduced >> as superclasses afterward. >> >> The main risk is pulling or changing the incubating feature in some >> way that would be incompatible with the API support added for it. >> >> Recent discussions have suggested @Deprecating new API items added to >> support preview features. Can is a reasonable precaution to >> discourage accidental dependence on them, but at times the behavior >> of existing methods is also changes so deprecation would not be a >> good fit. >> >> Cheers, >> >> -Joe >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000515.html >> >> [2] >> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000831.html >> >> [3] >> https://blogs.oracle.com/darcy/so-you-want-to-change-the-java-programming-language > From Alan.Bateman at oracle.com Thu Mar 22 13:12:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Mar 2018 13:12:23 +0000 Subject: RFR : JDK-8071367 - JMX: Remove SNMP support In-Reply-To: References: <5fed6078-624f-2c4b-b92c-5022fd07925c@oracle.com> Message-ID: On 22/03/2018 10:03, Amit Sapre wrote: > > Thanks Alan and Mandy for inputs. > > This webrev : > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.01/ > > addresses your comments. > > I reverted changes for ?legacy.properties? and also rebased the patch > for jdk/jdk repo. > > This looks good, just a few typos in Agent's class description "This class also provide entrypoints for jcmd tool ..." => "This class also provides entry points for the jcmd tool ...". -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Mar 22 14:35:24 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 22 Mar 2018 15:35:24 +0100 Subject: RFR JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: References: <5AAA93FA.2020104@oracle.com> <0cfa287b-8b20-8065-f6d8-7c8aaa515d00@oracle.com> <5AB221F7.50007@oracle.com> Message-ID: <5AB3BF2C.7000304@oracle.com> On 21.3.2018 12:02, Maurizio Cimadamore wrote: > Looks great - please add a comment (no need for new webrev) in > GenFInalizer::afterBody to explain why we are setting > tryEnv.info.finalize to null (e.g. to disable Gen::genFinalizer). Thanks! I've added the comment and pushed: http://hg.openjdk.java.net/jdk/jdk/rev/c2a3a2aa2475 Jan > > Maurizio > > > On 21/03/18 09:12, Jan Lahoda wrote: >> Hi Maurizio, >> >> Thanks a lot for the comments. I've updated the patch according to the >> comments, updated webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8194978/webrev.01/ >> >> How does that look? >> >> Thanks, >> Jan >> >> On 20.3.2018 13:13, Maurizio Cimadamore wrote: >>> Hi Jan, >>> great work. The desugaring looks correct, at least there's nothing wrong >>> I can spot about it. Some comments: >>> >>> * resourceNonNull = TreeInfo.skipParens(resource).hasTag(NEWCLASS); >>> >>> Is the above needed? I can't seem to support evidence that this syntax >>> is even legal (in the branch where 'resource' is an expression, I mean) >>> >>> * The javadoc in Lower::makeTwrTry seems out of sync what is being >>> actually generated >>> >>> * I think the Lower code would benefit from better variable names - the >>> patch has a mixture of old names (e.g. primaryException) and new names >>> (e.g. 'closeStatement2'). I suggest picking a naming scheme in the >>> javadoc, and then stick to that in the code, so that there are explicit >>> references to what bit it is that we're currently generating. >>> >>> * I find the code in Gen bit subtle; you want the new finally block to >>> act as a finally - but only during the try block; that means, I believe, >>> that you want genFinalizer to do the usual thing (e.g. copy finalizer >>> body on exit points) but then skip doing that when it comes to >>> exceptions. That is, you don't want a catch-all block and you don't want >>> to copy finalizer body on exceptional paths. Another stacking would be >>> to completely replace the 'env.info.finalize' after the body is done, >>> e.g. >>> >>> >>> >>> if (tree.finalizer.flags & BODY_ONLY_FINALIZE != 0) { >>> env.info.finalize == null; >>> } >>> >>> Wouldn't this be more consistent with what you are trying to achieve? >>> Seems to me that with the current approach there are side effects that >>> occur in the GenFinalizer even when afterBody is set (e.g. setting >>> finalizer gaps in the encl environment). >>> >>> Cheers >>> Maurizio >>> >>> On 15/03/18 15:40, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194978 >>>> >>>> The issue here is that the bytecode generated for try-with-resources >>>> produces some unreachable instructions, and may be unnecessarily big. >>>> >>>> Consider this code: >>>> --- >>>> try (InputStream in = new FileInputStream(str)) { >>>> int read = in.read(); >>>> if (read == (-1)) return ; >>>> System.err.println(read); >>>> } >>>> --- >>>> >>>> javac desugars it to this: >>>> --- >>>> { >>>> final InputStream in = new FileInputStream(str); >>>> /*synthetic*/ Throwable primaryException0$ = null; >>>> try { >>>> int read = in.read(); >>>> if (read == (-1)) return; >>>> System.err.println(read); >>>> } catch (/*synthetic*/ final Throwable t$) { >>>> primaryException0$ = t$; >>>> throw t$; >>>> } finally { >>>> if (primaryException0$ != null) try { >>>> in.close(); >>>> } catch (/*synthetic*/ Throwable x2) { >>>> primaryException0$.addSuppressed(x2); >>>> } else in.close(); >>>> } >>>> } >>>> --- >>>> >>>> Which seems fine, but when the try-finally construct is written into >>>> bytecode, the "finally" section is duplicated into all >>>> (non-exceptional) exit points from the try body (it would also be >>>> copied to non-exception exit points from all catches, but there are no >>>> such exit points in this case). A rough idea on how the bytecode looks >>>> like is below - please note that some try-catches don't embed nicely >>>> with the rest of the code, so are denoted in comments only. >>>> >>>> --- >>>> { >>>> final InputStream in = new FileInputStream(str); >>>> /*synthetic*/ Throwable primaryException0$ = null; >>>> // try >>>> int read = in.read(); >>>> if (read == (-1)) { >>>> // catch Throwable: goto CATCH >>>> // catch any: goto FINALLY [1] >>>> //start injected finally >>>> if (primaryException0$ != null) try { // [2] >>>> in.close(); >>>> } catch (/*synthetic*/ Throwable x2) { >>>> primaryException0$.addSuppressed(x2); >>>> } else in.close(); >>>> //end injected finally >>>> >>>> return; >>>> } >>>> >>>> // try >>>> System.err.println(read); >>>> // catch Throwable: goto CATCH >>>> // catch any: goto FINALLY [1] >>>> >>>> //start injected finally >>>> if (primaryException0$ != null) try { // [2] >>>> in.close(); >>>> } catch (/*synthetic*/ Throwable x2) { >>>> primaryException0$.addSuppressed(x2); >>>> } else in.close(); >>>> //end injected finally >>>> >>>> //goto END >>>> >>>> CATCH: // catch (/*synthetic*/ final Throwable t$) >>>> // try >>>> primaryException0$ = t$; >>>> throw t$; >>>> // catch any: goto FINALLY >>>> FINALLY: >>>> if (primaryException0$ != null) try {// [3] >>>> in.close(); >>>> } catch (/*synthetic*/ Throwable x2) { >>>> primaryException0$.addSuppressed(x2); >>>> } else in.close(); >>>> END: >>>> } >>>> --- >>>> >>>> A few comments about the code: >>>> -[1]: this catches seem unnecessary: all Throwables have already been >>>> caught? >>>> -[2]: at this place, it is clear that primaryException0$ is null, so >>>> the is-non-null section is not useful >>>> -[3]: at this place, it is mostly clear that primaryException0$ is >>>> not-null, so the is-null section is not useful >>>> >>>> So, it seems it might be possible to construct the code so that only >>>> the needed sections of the finally would be used at the appropriate >>>> places. I.e. the original try-with-resources would get desugared to >>>> something like: >>>> >>>> --- >>>> { >>>> final InputStream in = new FileInputStream(str); >>>> try { >>>> int read = in.read(); >>>> if (read == (-1)) return; >>>> System.err.println(read); >>>> } body-only-finally { //copied to exit points in try body >>>> //only, not used as a real finally >>>> in.close(); >>>> } catch (/*synthetic*/ final Throwable t$) { >>>> try { >>>> in.close(); >>>> } catch (/*synthetic*/ Throwable x2) { >>>> t$.addSuppressed(x2); >>>> } >>>> throw t$; >>>> } >>>> } >>>> --- >>>> >>>> Which would then get generated to bytecode as: >>>> --- >>>> { >>>> final InputStream in = new FileInputStream(str); >>>> //try >>>> int read = in.read(); >>>> if (read == (-1)) { >>>> // catch Throwable: goto CATCH >>>> in.close(); >>>> return; >>>> } >>>> >>>> //try >>>> System.err.println(read); >>>> // catch Throwable: goto CATCH >>>> >>>> in.close(); >>>> >>>> //goto END >>>> >>>> CATCH: // catch (/*synthetic*/ final Throwable t$) >>>> try { >>>> in.close(); >>>> } catch (/*synthetic*/ Throwable x2) { >>>> t$.addSuppressed(x2); >>>> } >>>> throw t$; >>>> END: >>>> } >>>> --- >>>> >>>> The current desugaring is trying to pull out the finally code into a >>>> separate method when that appears to be worthwhile, but this proposed >>>> desugaring seems to be producing a better bytecode with less javac >>>> code. >>>> >>>> Does this updated desugaring/transformation look safe? >>>> >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8194978/webrev.00/ >>>> >>>> Thanks, >>>> Jan >>> > From mandy.chung at oracle.com Thu Mar 22 17:45:10 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 22 Mar 2018 10:45:10 -0700 Subject: RFR : JDK-8071367 - JMX: Remove SNMP support In-Reply-To: References: <5fed6078-624f-2c4b-b92c-5022fd07925c@oracle.com> Message-ID: On 3/22/18 6:12 AM, Alan Bateman wrote: > > > On 22/03/2018 10:03, Amit Sapre wrote: >> >> Thanks Alan and Mandy for inputs. >> >> This webrev : >> http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.01/ >> >> addresses your comments. >> >> I reverted changes for ?legacy.properties? and also rebased the patch >> for jdk/jdk repo. >> >> > This looks good, just a few typos in Agent's class description > > "This class also provide entrypoints for jcmd tool ..." => "This class > also provides entry points for the jcmd tool ...". > Looks good in general. Since you are cleaning up the comment, some suggestions: Replace line 60-67 with: This class provides the methods to start the management agent. 1.? {@link #startAgent} method is invoked by the VM if -Dcom.sun.management.* is set 2.? {@link #startLocalManagementAgent} or {@link #startRemoteManagementAgent} ???? is invoked to start the management agent after the VM starts ???? via jcmd ManagementAgent.start and start_local command. line 309-310 can be replaced with ?? /* ??? * Starts the local management agent. ??? * This method is invoked by either startAgent method or ??? * by the VM directly via jcmd ManagementAgent.start_local command. ??? */ line 332-335 can be replaced with ?? /* ??? * This method is invoked by the VM to start the remote management agent ??? * via jcmd ManagementAgent.start command. ??? */ Add the javadoc to startAgent() /* ?* This method is invoked by the VM to start the management agent ?* when -Dcom.sun.management.* is set during startup. ?*/ Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Mar 22 21:23:25 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 22 Mar 2018 22:23:25 +0100 Subject: RFR: JDK-8200136: Problem list test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java Message-ID: <5AB41ECD.7000709@oracle.com> Hi, The fix for JDK-8194978 unfortunately broke test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java. I'd like to propose problem listing that test, until it is fixed: http://cr.openjdk.java.net/~jlahoda/8200136/webrev.00/ I apologize for any inconvenience this may cause. Thanks, Jan From joe.darcy at oracle.com Thu Mar 22 21:27:06 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 22 Mar 2018 14:27:06 -0700 Subject: RFR: JDK-8200136: Problem list test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java In-Reply-To: <5AB41ECD.7000709@oracle.com> References: <5AB41ECD.7000709@oracle.com> Message-ID: Looks good Jan; thanks, -Joe On 3/22/2018 2:23 PM, Jan Lahoda wrote: > Hi, > > The fix for JDK-8194978 unfortunately broke > test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java. > I'd like to propose problem listing that test, until it is fixed: > http://cr.openjdk.java.net/~jlahoda/8200136/webrev.00/ > > I apologize for any inconvenience this may cause. > > Thanks, > ??? Jan From vladimir.kozlov at oracle.com Thu Mar 22 21:32:26 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Mar 2018 14:32:26 -0700 Subject: RFR: JDK-8200136: Problem list test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java In-Reply-To: <5AB41ECD.7000709@oracle.com> References: <5AB41ECD.7000709@oracle.com> Message-ID: <0bd22d6b-a659-7ac0-2c61-52a568a1b0c7@oracle.com> Looks good. Thanks, Vladimir On 3/22/18 2:23 PM, Jan Lahoda wrote: > Hi, > > The fix for JDK-8194978 unfortunately broke > test/hotspot/jtreg/compiler/jvmci/compilerToVM/GetExceptionTableTest.java. I'd like to propose > problem listing that test, until it is fixed: > http://cr.openjdk.java.net/~jlahoda/8200136/webrev.00/ > > I apologize for any inconvenience this may cause. > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Fri Mar 23 10:57:00 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 23 Mar 2018 10:57:00 +0000 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> Message-ID: <9247f431-8244-9847-efee-08d3fd11aa95@oracle.com> Ping :-) Maurizio On 21/03/18 20:56, Maurizio Cimadamore wrote: > > Here's an updated webrev - passes all tests. > > In addition to the tests already provided, I also tweaked the LVTI > test harness to also use -g and report crashes (I verified that in > this mode the harness crashes w/o the patch). > > Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/8199910-v3/ > > Cheers > Maurizio > > > On 21/03/18 17:08, ShinyaYoshida wrote: >> Hi Maurizio, >> Thank you for the pointing that. >> >> I've read the logic around your fix. It seems to me?it's reasonable. >> We don't need to handle intersection type in enterInner?because inner >> classes are handled triggered by a symbol?of another part. >> >> I could confirm the test passes. >> Please go ahead! >> >> Thank you for the opportunity?to learn the logic around that. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore >> >: >> >> Attached is my take on the problem. >> >> As I said, we added some logic to handle this with multi-catch, >> but unfortunately the current logic only handle cases where you >> have a type like A & B and not cases where you have Foo. >> >> I've enhanced the check to do a proper non-denotable visit on the >> type of the local variable, rather than just doing a simple check >> as before. >> >> Let me know what you think - and also if you'd like me to go >> ahead with it, or if you still want to take this. >> >> Cheers >> Maurizio >> >> >> On 21/03/18 16:09, Maurizio Cimadamore wrote: >>> >>> Hi Shinya, >>> thanks for the fix; unfortunately, I believe it is not correct. >>> An intersection type should be erased by the time we get here; >>> we had a similar issue in the past with multicatch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-6999635 >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-7005371 >>> >>> >>> I will take a closer look as to find out exactly what's going >>> on; the fix for multicatch should have taken care for this one >>> too... >>> >>> Maurizio >>> >>> >>> On 21/03/18 02:53, ShinyaYoshida wrote: >>>> Hi all and Kishida, >>>> >>>> Thank you for reporting the?issue. >>>> >>>> I've filed and created a patch: >>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>>> >>>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>>> >>>> >>>> Could someone review this? >>>> >>>> If it's fine, I'll commit to jdk repo and I'd like to backport >>>> to jdk10 after backport approval. >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> 2018-03-21 10:54 GMT+09:00 kishida naoki >>>> >: >>>> >>>> Hi all! >>>> >>>> I'm glad that JDK 10 is released. >>>> But I've faced a compiler bug with `var`. >>>> I'm using the build 46. >>>> >>>> This code crashes the compiler with `-g` option. >>>> ``` >>>> public class Main { >>>> ??? void m() { >>>> ??????? var s = java.util.List.of("a", 1); >>>> ??? } >>>> } >>>> ``` >>>> >>>> $ javac Main.java -g >>>> C:\src>javac Main.java -g >>>> java.lang.AssertionError: Unexpected intersection type: >>>> java.lang.Object&java.io >>>> .Serializable&java.lang.Comparable>>> extends java.lang.Object&java.io >>>> .Serializable&java.lang.Comparable> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>> >>>> The cause is about intersection. The variable type that is >>>> infered becomes as a type with intersection, and will crash >>>> the compiler when generating a debug info. >>>> These are no problem. >>>> ? var s=List.of("a"); >>>> ? var s=List.of("a", 1, Optional.empty()); >>>> ? var s=List.of("a", 1, List.of()); >>>> >>>> Best regards. >>>> >>>> -- >>>> Naoki Kishida >>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Fri Mar 23 12:11:54 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 23 Mar 2018 13:11:54 +0100 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: <9247f431-8244-9847-efee-08d3fd11aa95@oracle.com> References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> <9247f431-8244-9847-efee-08d3fd11aa95@oracle.com> Message-ID: On 23 March 2018 at 11:57, Maurizio Cimadamore wrote: > Ping :-) Hello Maurizio, You'll still need another review but this looks good to me, Bernard > Maurizio > > > On 21/03/18 20:56, Maurizio Cimadamore wrote: > > Here's an updated webrev - passes all tests. > > In addition to the tests already provided, I also tweaked the LVTI test > harness to also use -g and report crashes (I verified that in this mode the > harness crashes w/o the patch). > > Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/8199910-v3/ > > Cheers > Maurizio > > > On 21/03/18 17:08, ShinyaYoshida wrote: > > Hi Maurizio, > Thank you for the pointing that. > > I've read the logic around your fix. It seems to me it's reasonable. > We don't need to handle intersection type in enterInner because inner > classes are handled triggered by a symbol of another part. > > I could confirm the test passes. > Please go ahead! > > Thank you for the opportunity to learn the logic around that. > > Regards, > shinyafox(Shinya Yoshida) > > 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore > : >> >> Attached is my take on the problem. >> >> As I said, we added some logic to handle this with multi-catch, but >> unfortunately the current logic only handle cases where you have a type like >> A & B and not cases where you have Foo. >> >> I've enhanced the check to do a proper non-denotable visit on the type of >> the local variable, rather than just doing a simple check as before. >> >> Let me know what you think - and also if you'd like me to go ahead with >> it, or if you still want to take this. >> >> Cheers >> Maurizio >> >> >> On 21/03/18 16:09, Maurizio Cimadamore wrote: >> >> Hi Shinya, >> thanks for the fix; unfortunately, I believe it is not correct. An >> intersection type should be erased by the time we get here; we had a similar >> issue in the past with multicatch: >> >> https://bugs.openjdk.java.net/browse/JDK-6999635 >> >> https://bugs.openjdk.java.net/browse/JDK-7005371 >> >> I will take a closer look as to find out exactly what's going on; the fix >> for multicatch should have taken care for this one too... >> >> Maurizio >> >> >> On 21/03/18 02:53, ShinyaYoshida wrote: >> >> Hi all and Kishida, >> >> Thank you for reporting the issue. >> >> I've filed and created a patch: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >> >> Could someone review this? >> >> If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 >> after backport approval. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-21 10:54 GMT+09:00 kishida naoki : >>> >>> Hi all! >>> >>> I'm glad that JDK 10 is released. >>> But I've faced a compiler bug with `var`. >>> I'm using the build 46. >>> >>> This code crashes the compiler with `-g` option. >>> ``` >>> public class Main { >>> void m() { >>> var s = java.util.List.of("a", 1); >>> } >>> } >>> ``` >>> >>> $ javac Main.java -g >>> C:\src>javac Main.java -g >>> java.lang.AssertionError: Unexpected intersection type: >>> java.lang.Object&java.io.Serializable&java.lang.Comparable>> java.lang.Object&java.io.Serializable&java.lang.Comparable> >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>> at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>> at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>> at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>> at >>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>> at >>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>> at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>> at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>> at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>> >>> The cause is about intersection. The variable type that is infered >>> becomes as a type with intersection, and will crash the compiler when >>> generating a debug info. >>> These are no problem. >>> var s=List.of("a"); >>> var s=List.of("a", 1, Optional.empty()); >>> var s=List.of("a", 1, List.of()); >>> >>> Best regards. >>> >>> -- >>> Naoki Kishida >> >> >> >> > > > From bsrbnd at gmail.com Fri Mar 23 12:51:59 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 23 Mar 2018 13:51:59 +0100 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> <9247f431-8244-9847-efee-08d3fd11aa95@oracle.com> Message-ID: On 23 March 2018 at 13:11, B. Blaser wrote: > On 23 March 2018 at 11:57, Maurizio Cimadamore > wrote: >> Ping :-) > > Hello Maurizio, > > You'll still need another review but this looks good to me, > Bernard And I now see the "interest" (even if dangerous) of having intersection types involving final classes [1]. So, I suggest to close https://bugs.openjdk.java.net/browse/JDK-8189684 What do you think? Thanks, Bernard [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-November/011299.html >> Maurizio >> >> >> On 21/03/18 20:56, Maurizio Cimadamore wrote: >> >> Here's an updated webrev - passes all tests. >> >> In addition to the tests already provided, I also tweaked the LVTI test >> harness to also use -g and report crashes (I verified that in this mode the >> harness crashes w/o the patch). >> >> Webrev here: >> >> http://cr.openjdk.java.net/~mcimadamore/8199910-v3/ >> >> Cheers >> Maurizio >> >> >> On 21/03/18 17:08, ShinyaYoshida wrote: >> >> Hi Maurizio, >> Thank you for the pointing that. >> >> I've read the logic around your fix. It seems to me it's reasonable. >> We don't need to handle intersection type in enterInner because inner >> classes are handled triggered by a symbol of another part. >> >> I could confirm the test passes. >> Please go ahead! >> >> Thank you for the opportunity to learn the logic around that. >> >> Regards, >> shinyafox(Shinya Yoshida) >> >> 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore >> : >>> >>> Attached is my take on the problem. >>> >>> As I said, we added some logic to handle this with multi-catch, but >>> unfortunately the current logic only handle cases where you have a type like >>> A & B and not cases where you have Foo. >>> >>> I've enhanced the check to do a proper non-denotable visit on the type of >>> the local variable, rather than just doing a simple check as before. >>> >>> Let me know what you think - and also if you'd like me to go ahead with >>> it, or if you still want to take this. >>> >>> Cheers >>> Maurizio >>> >>> >>> On 21/03/18 16:09, Maurizio Cimadamore wrote: >>> >>> Hi Shinya, >>> thanks for the fix; unfortunately, I believe it is not correct. An >>> intersection type should be erased by the time we get here; we had a similar >>> issue in the past with multicatch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-6999635 >>> >>> https://bugs.openjdk.java.net/browse/JDK-7005371 >>> >>> I will take a closer look as to find out exactly what's going on; the fix >>> for multicatch should have taken care for this one too... >>> >>> Maurizio >>> >>> >>> On 21/03/18 02:53, ShinyaYoshida wrote: >>> >>> Hi all and Kishida, >>> >>> Thank you for reporting the issue. >>> >>> I've filed and created a patch: >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>> >>> Could someone review this? >>> >>> If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 >>> after backport approval. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-21 10:54 GMT+09:00 kishida naoki : >>>> >>>> Hi all! >>>> >>>> I'm glad that JDK 10 is released. >>>> But I've faced a compiler bug with `var`. >>>> I'm using the build 46. >>>> >>>> This code crashes the compiler with `-g` option. >>>> ``` >>>> public class Main { >>>> void m() { >>>> var s = java.util.List.of("a", 1); >>>> } >>>> } >>>> ``` >>>> >>>> $ javac Main.java -g >>>> C:\src>javac Main.java -g >>>> java.lang.AssertionError: Unexpected intersection type: >>>> java.lang.Object&java.io.Serializable&java.lang.Comparable>>> java.lang.Object&java.io.Serializable&java.lang.Comparable> >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>>> at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>>> at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>> at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>>> at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>>> at >>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>>> at >>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>>> at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>> >>>> The cause is about intersection. The variable type that is infered >>>> becomes as a type with intersection, and will crash the compiler when >>>> generating a debug info. >>>> These are no problem. >>>> var s=List.of("a"); >>>> var s=List.of("a", 1, Optional.empty()); >>>> var s=List.of("a", 1, List.of()); >>>> >>>> Best regards. >>>> >>>> -- >>>> Naoki Kishida >>> >>> >>> >>> >> >> >> From jan.lahoda at oracle.com Fri Mar 23 14:33:35 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 23 Mar 2018 15:33:35 +0100 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: <9247f431-8244-9847-efee-08d3fd11aa95@oracle.com> References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> <9247f431-8244-9847-efee-08d3fd11aa95@oracle.com> Message-ID: <5AB5103F.4090806@oracle.com> Seems OK to me. Jan On 23.3.2018 11:57, Maurizio Cimadamore wrote: > Ping :-) > > Maurizio > > > On 21/03/18 20:56, Maurizio Cimadamore wrote: >> >> Here's an updated webrev - passes all tests. >> >> In addition to the tests already provided, I also tweaked the LVTI >> test harness to also use -g and report crashes (I verified that in >> this mode the harness crashes w/o the patch). >> >> Webrev here: >> >> http://cr.openjdk.java.net/~mcimadamore/8199910-v3/ >> >> Cheers >> Maurizio >> >> >> On 21/03/18 17:08, ShinyaYoshida wrote: >>> Hi Maurizio, >>> Thank you for the pointing that. >>> >>> I've read the logic around your fix. It seems to me it's reasonable. >>> We don't need to handle intersection type in enterInner because inner >>> classes are handled triggered by a symbol of another part. >>> >>> I could confirm the test passes. >>> Please go ahead! >>> >>> Thank you for the opportunity to learn the logic around that. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore >>> >: >>> >>> Attached is my take on the problem. >>> >>> As I said, we added some logic to handle this with multi-catch, >>> but unfortunately the current logic only handle cases where you >>> have a type like A & B and not cases where you have Foo. >>> >>> I've enhanced the check to do a proper non-denotable visit on the >>> type of the local variable, rather than just doing a simple check >>> as before. >>> >>> Let me know what you think - and also if you'd like me to go >>> ahead with it, or if you still want to take this. >>> >>> Cheers >>> Maurizio >>> >>> >>> On 21/03/18 16:09, Maurizio Cimadamore wrote: >>>> >>>> Hi Shinya, >>>> thanks for the fix; unfortunately, I believe it is not correct. >>>> An intersection type should be erased by the time we get here; >>>> we had a similar issue in the past with multicatch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-6999635 >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-7005371 >>>> >>>> >>>> I will take a closer look as to find out exactly what's going >>>> on; the fix for multicatch should have taken care for this one >>>> too... >>>> >>>> Maurizio >>>> >>>> >>>> On 21/03/18 02:53, ShinyaYoshida wrote: >>>>> Hi all and Kishida, >>>>> >>>>> Thank you for reporting the issue. >>>>> >>>>> I've filed and created a patch: >>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>>>> >>>>> >>>>> Could someone review this? >>>>> >>>>> If it's fine, I'll commit to jdk repo and I'd like to backport >>>>> to jdk10 after backport approval. >>>>> >>>>> Regards, >>>>> shinyafox(Shinya Yoshida) >>>>> >>>>> 2018-03-21 10:54 GMT+09:00 kishida naoki >>>>> >: >>>>> >>>>> Hi all! >>>>> >>>>> I'm glad that JDK 10 is released. >>>>> But I've faced a compiler bug with `var`. >>>>> I'm using the build 46. >>>>> >>>>> This code crashes the compiler with `-g` option. >>>>> ``` >>>>> public class Main { >>>>> void m() { >>>>> var s = java.util.List.of("a", 1); >>>>> } >>>>> } >>>>> ``` >>>>> >>>>> $ javac Main.java -g >>>>> C:\src>javac Main.java -g >>>>> java.lang.AssertionError: Unexpected intersection type: >>>>> java.lang.Object&java.io >>>>> .Serializable&java.lang.Comparable>>>> extends java.lang.Object&java.io >>>>> .Serializable&java.lang.Comparable> >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>>> >>>>> The cause is about intersection. The variable type that is >>>>> infered becomes as a type with intersection, and will crash >>>>> the compiler when generating a debug info. >>>>> These are no problem. >>>>> var s=List.of("a"); >>>>> var s=List.of("a", 1, Optional.empty()); >>>>> var s=List.of("a", 1, List.of()); >>>>> >>>>> Best regards. >>>>> >>>>> -- >>>>> Naoki Kishida >>>>> >>>>> >>>> >>> >>> >> > From mandy.chung at oracle.com Fri Mar 23 15:08:17 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 23 Mar 2018 08:08:17 -0700 Subject: RFR : JDK-8071367 - JMX: Remove SNMP support In-Reply-To: <1dcc4fe3-8463-49c6-947d-ef31b92d51db@default> References: <5fed6078-624f-2c4b-b92c-5022fd07925c@oracle.com> <1dcc4fe3-8463-49c6-947d-ef31b92d51db@default> Message-ID: <7c68e8c6-aa6b-1cb7-482d-80df0a867346@oracle.com> On 3/23/18 3:43 AM, Amit Sapre wrote: > > Thanks all for the inputs. > > This webrev addresses the inputs : > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.02/ > > > Looks good. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Fri Mar 23 15:19:45 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 23 Mar 2018 16:19:45 +0100 Subject: RFR 8199910: Compiler crashes with -g option and variables of intersection type inferred by `var` In-Reply-To: References: <92146b88-e9a5-1539-27be-a860cb167d56@oracle.com> <3850e365-39d3-b367-bd56-dcfd77a80068@oracle.com> <9247f431-8244-9847-efee-08d3fd11aa95@oracle.com> Message-ID: On 23 March 2018 at 13:51, B. Blaser wrote: > On 23 March 2018 at 13:11, B. Blaser wrote: >> On 23 March 2018 at 11:57, Maurizio Cimadamore >> wrote: >>> Ping :-) >> >> Hello Maurizio, >> >> You'll still need another review but this looks good to me, >> Bernard > > And I now see the "interest" (even if dangerous) of having > intersection types involving final classes [1]. So, I suggest to close > https://bugs.openjdk.java.net/browse/JDK-8189684 I maybe went too fast, you previously wrote 'Foo' probably referring to the intersection type 'Object & Serializable & Comparable' present in the stack trace which was induced by the 'lub' of the union type 'List' from our example 'var s = java.util.List.of("a", 1)' ? In such a case, final classes are not dangerous;-) Bernard > What do you think? > > Thanks, > Bernard > > [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-November/011299.html > > >>> Maurizio >>> >>> >>> On 21/03/18 20:56, Maurizio Cimadamore wrote: >>> >>> Here's an updated webrev - passes all tests. >>> >>> In addition to the tests already provided, I also tweaked the LVTI test >>> harness to also use -g and report crashes (I verified that in this mode the >>> harness crashes w/o the patch). >>> >>> Webrev here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8199910-v3/ >>> >>> Cheers >>> Maurizio >>> >>> >>> On 21/03/18 17:08, ShinyaYoshida wrote: >>> >>> Hi Maurizio, >>> Thank you for the pointing that. >>> >>> I've read the logic around your fix. It seems to me it's reasonable. >>> We don't need to handle intersection type in enterInner because inner >>> classes are handled triggered by a symbol of another part. >>> >>> I could confirm the test passes. >>> Please go ahead! >>> >>> Thank you for the opportunity to learn the logic around that. >>> >>> Regards, >>> shinyafox(Shinya Yoshida) >>> >>> 2018-03-22 1:26 GMT+09:00 Maurizio Cimadamore >>> : >>>> >>>> Attached is my take on the problem. >>>> >>>> As I said, we added some logic to handle this with multi-catch, but >>>> unfortunately the current logic only handle cases where you have a type like >>>> A & B and not cases where you have Foo. >>>> >>>> I've enhanced the check to do a proper non-denotable visit on the type of >>>> the local variable, rather than just doing a simple check as before. >>>> >>>> Let me know what you think - and also if you'd like me to go ahead with >>>> it, or if you still want to take this. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> >>>> On 21/03/18 16:09, Maurizio Cimadamore wrote: >>>> >>>> Hi Shinya, >>>> thanks for the fix; unfortunately, I believe it is not correct. An >>>> intersection type should be erased by the time we get here; we had a similar >>>> issue in the past with multicatch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-6999635 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-7005371 >>>> >>>> I will take a closer look as to find out exactly what's going on; the fix >>>> for multicatch should have taken care for this one too... >>>> >>>> Maurizio >>>> >>>> >>>> On 21/03/18 02:53, ShinyaYoshida wrote: >>>> >>>> Hi all and Kishida, >>>> >>>> Thank you for reporting the issue. >>>> >>>> I've filed and created a patch: >>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199910 >>>> Webrev: http://cr.openjdk.java.net/~shinyafox/8199910/webrev/ >>>> >>>> Could someone review this? >>>> >>>> If it's fine, I'll commit to jdk repo and I'd like to backport to jdk10 >>>> after backport approval. >>>> >>>> Regards, >>>> shinyafox(Shinya Yoshida) >>>> >>>> 2018-03-21 10:54 GMT+09:00 kishida naoki : >>>>> >>>>> Hi all! >>>>> >>>>> I'm glad that JDK 10 is released. >>>>> But I've faced a compiler bug with `var`. >>>>> I'm using the build 46. >>>>> >>>>> This code crashes the compiler with `-g` option. >>>>> ``` >>>>> public class Main { >>>>> void m() { >>>>> var s = java.util.List.of("a", 1); >>>>> } >>>>> } >>>>> ``` >>>>> >>>>> $ javac Main.java -g >>>>> C:\src>javac Main.java -g >>>>> java.lang.AssertionError: Unexpected intersection type: >>>>> java.lang.Object&java.io.Serializable&java.lang.Comparable>>>> java.lang.Object&java.io.Serializable&java.lang.Comparable> >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:1043) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.classReference(ClassWriter.java:312) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5182) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5225) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleClassSig(Types.java:5201) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.code.Types$SignatureGenerator.assembleSig(Types.java:5114) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter$CWSignatureGenerator.assembleSig(ClassWriter.java:291) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.typeSig(ClassWriter.java:334) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeCode(ClassWriter.java:1271) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethod(ClassWriter.java:1158) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeMethods(ClassWriter.java:1653) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1761) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1679) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:749) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1627) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1595) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:965) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) >>>>> at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) >>>>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>>> >>>>> The cause is about intersection. The variable type that is infered >>>>> becomes as a type with intersection, and will crash the compiler when >>>>> generating a debug info. >>>>> These are no problem. >>>>> var s=List.of("a"); >>>>> var s=List.of("a", 1, Optional.empty()); >>>>> var s=List.of("a", 1, List.of()); >>>>> >>>>> Best regards. >>>>> >>>>> -- >>>>> Naoki Kishida >>>> >>>> >>>> >>>> >>> >>> >>> From Alan.Bateman at oracle.com Fri Mar 23 16:23:37 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Mar 2018 16:23:37 +0000 Subject: RFR : JDK-8071367 - JMX: Remove SNMP support In-Reply-To: <1dcc4fe3-8463-49c6-947d-ef31b92d51db@default> References: <5fed6078-624f-2c4b-b92c-5022fd07925c@oracle.com> <1dcc4fe3-8463-49c6-947d-ef31b92d51db@default> Message-ID: <559041cd-e695-3bc8-29a2-ae2d49797292@oracle.com> On 23/03/2018 10:43, Amit Sapre wrote: > > Thanks all for the inputs. > > This webrev addresses the inputs : > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.02/ > > > I think you need to put {@code ... } around "-Dcom.sun.management.*", otherwise looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Mon Mar 26 21:41:36 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 26 Mar 2018 14:41:36 -0700 (PDT) Subject: JEP 330: Launch Single-File Source-Code Programs Message-ID: <20180326214136.8FD1D196CA7@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/330 - Mark From forax at univ-mlv.fr Mon Mar 26 21:55:39 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Mar 2018 23:55:39 +0200 (CEST) Subject: JEP 330: Launch Single-File Source-Code Programs In-Reply-To: <20180326214136.8FD1D196CA7@eggemoggin.niobe.net> References: <20180326214136.8FD1D196CA7@eggemoggin.niobe.net> Message-ID: <1938873573.561078.1522101339688.JavaMail.zimbra@u-pem.fr> "All subsequent bytes are read with the default platform character encoding that is in effect." should we not mandate UTF8 instead ? R?mi ----- Mail original ----- > De: "mark reinhold" > ?: "jonathan gibbons" > Cc: "compiler-dev" > Envoy?: Lundi 26 Mars 2018 23:41:36 > Objet: JEP 330: Launch Single-File Source-Code Programs > New JEP Candidate: http://openjdk.java.net/jeps/330 > > - Mark From jonathan.gibbons at oracle.com Mon Mar 26 22:32:38 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 26 Mar 2018 15:32:38 -0700 Subject: JEP 330: Launch Single-File Source-Code Programs In-Reply-To: <1938873573.561078.1522101339688.JavaMail.zimbra@u-pem.fr> References: <20180326214136.8FD1D196CA7@eggemoggin.niobe.net> <1938873573.561078.1522101339688.JavaMail.zimbra@u-pem.fr> Message-ID: <5AB97506.1030709@oracle.com> R?mi, The problem is that the first line of a shebang file is effectively read twice. It is initially read by the operating system, as part of the operation of the shebang feature. That happens before the executable named in the first line is even invoked, and is therefore out of the control of any executable that might be named. Then, the executable is invoked giving the shebang file as an argument. The executable will read the file, including the first line. Since we have no ability to mandate any specific format, the best we can do is to go with what the operating system provides. -- Jon On 03/26/2018 02:55 PM, Remi Forax wrote: > "All subsequent bytes are read with the default platform character encoding that is in effect." > should we not mandate UTF8 instead ? > > R?mi > > ----- Mail original ----- >> De: "mark reinhold" >> ?: "jonathan gibbons" >> Cc: "compiler-dev" >> Envoy?: Lundi 26 Mars 2018 23:41:36 >> Objet: JEP 330: Launch Single-File Source-Code Programs >> New JEP Candidate: http://openjdk.java.net/jeps/330 >> >> - Mark From forax at univ-mlv.fr Tue Mar 27 05:28:03 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Mar 2018 05:28:03 +0000 Subject: JEP 330: Launch Single-File Source-Code Programs In-Reply-To: <5AB97506.1030709@oracle.com> References: <20180326214136.8FD1D196CA7@eggemoggin.niobe.net> <1938873573.561078.1522101339688.JavaMail.zimbra@u-pem.fr> <5AB97506.1030709@oracle.com> Message-ID: <58141891-275E-4CB7-8636-7E90E0795C45@univ-mlv.fr> Ok, thanks. Remi On March 26, 2018 10:32:38 PM UTC, Jonathan Gibbons wrote: >R?mi, > >The problem is that the first line of a shebang file is effectively >read >twice. > >It is initially read by the operating system, as part of the operation >of the shebang feature. That happens before the executable named in the > >first line is even invoked, and is therefore out of the control of any >executable that might be named. > >Then, the executable is invoked giving the shebang file as an argument. > >The executable will read the file, including the first line. Since we >have no ability to mandate any specific format, the best we can do is >to >go with what the operating system provides. > >-- Jon > > >On 03/26/2018 02:55 PM, Remi Forax wrote: >> "All subsequent bytes are read with the default platform character >encoding that is in effect." >> should we not mandate UTF8 instead ? >> >> R?mi >> >> ----- Mail original ----- >>> De: "mark reinhold" >>> ?: "jonathan gibbons" >>> Cc: "compiler-dev" >>> Envoy?: Lundi 26 Mars 2018 23:41:36 >>> Objet: JEP 330: Launch Single-File Source-Code Programs >>> New JEP Candidate: http://openjdk.java.net/jeps/330 >>> >>> - Mark -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Mar 28 10:16:11 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 28 Mar 2018 11:16:11 +0100 Subject: RFR 8200355: local variable inference regression test generates classfile in test folder Message-ID: <9436e11a-7111-a2fe-0f81-df891df24eb5@oracle.com> Hi, as the subject says, as a result of the tweaks done under JDK-8199910, the local variable inference test is generating spurious classfiles in the test/ folder. I've fixed the test to use jtreg's scratch dir as output folder for the file manager. Webrev: http://cr.openjdk.java.net/~mcimadamore/8200355/ Thanks Maurizio From maurizio.cimadamore at oracle.com Wed Mar 28 10:52:53 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 28 Mar 2018 11:52:53 +0100 Subject: RFR 8200199: javac suggests to use var even when var is used Message-ID: Hi, there is an issue with the local variable inference finder: the finder reports possible cases where 'var' could be used even when the developer has already used 'var'. This is due to a timing issue with which the analyzer runs - by the time it runs, variable types have already been written into the AST by Attr - so the call to JCVarDecl.isImplicitlyTyped() is moot, as that call will simply look to see as to whether the tree type == null. Since the var types corresponding to implicitly inferred types are synthetic and have no position set (see Attr::setSyntheticVariableType) I decided to use that property instead to decide as to whether the analyzer should, or should not consider a given variable declaration. This seems to be a good pragmatic solution. In the long run we should probably consolidate the treatment of implicitly inferred variables, and have some kind of common way to speak about them (e.g. both locals and implicit lambda parameters). Webrev: http://cr.openjdk.java.net/~mcimadamore/8200199/ Cheers Maurizio From jan.lahoda at oracle.com Wed Mar 28 10:56:13 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 28 Mar 2018 12:56:13 +0200 Subject: RFR 8200199: javac suggests to use var even when var is used In-Reply-To: References: Message-ID: <5ABB74CD.8000803@oracle.com> Looks good to me. Jan On 28.3.2018 12:52, Maurizio Cimadamore wrote: > Hi, > there is an issue with the local variable inference finder: the finder > reports possible cases where 'var' could be used even when the developer > has already used 'var'. This is due to a timing issue with which the > analyzer runs - by the time it runs, variable types have already been > written into the AST by Attr - so the call to > JCVarDecl.isImplicitlyTyped() is moot, as that call will simply look to > see as to whether the tree type == null. > > Since the var types corresponding to implicitly inferred types are > synthetic and have no position set (see Attr::setSyntheticVariableType) > I decided to use that property instead to decide as to whether the > analyzer should, or should not consider a given variable declaration. > This seems to be a good pragmatic solution. In the long run we should > probably consolidate the treatment of implicitly inferred variables, and > have some kind of common way to speak about them (e.g. both locals and > implicit lambda parameters). > > Webrev: > http://cr.openjdk.java.net/~mcimadamore/8200199/ > > Cheers > Maurizio > From vicente.romero at oracle.com Wed Mar 28 12:16:08 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 28 Mar 2018 08:16:08 -0400 Subject: RFR 8200355: local variable inference regression test generates classfile in test folder In-Reply-To: <9436e11a-7111-a2fe-0f81-df891df24eb5@oracle.com> References: <9436e11a-7111-a2fe-0f81-df891df24eb5@oracle.com> Message-ID: <38430741-163c-e395-67b6-0a859cff7fbc@oracle.com> looks good, Vicente On 03/28/2018 06:16 AM, Maurizio Cimadamore wrote: > Hi, > as the subject says, as a result of the tweaks done under JDK-8199910, > the local variable inference test is generating spurious classfiles in > the test/ folder. I've fixed the test to use jtreg's scratch dir as > output folder for the file manager. > > Webrev: > http://cr.openjdk.java.net/~mcimadamore/8200355/ > > Thanks > Maurizio > From vicente.romero at oracle.com Wed Mar 28 12:40:41 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 28 Mar 2018 08:40:41 -0400 Subject: RFR 8200199: javac suggests to use var even when var is used In-Reply-To: References: Message-ID: <68794705-88b1-8ac2-ef1f-2dd80f7ef224@oracle.com> question: shouldn't the fact that the vartype in the variable declaration doesn't have the position of `var` be a bug? Vicente On 03/28/2018 06:52 AM, Maurizio Cimadamore wrote: > Hi, > there is an issue with the local variable inference finder: the finder > reports possible cases where 'var' could be used even when the > developer has already used 'var'. This is due to a timing issue with > which the analyzer runs - by the time it runs, variable types have > already been written into the AST by Attr - so the call to > JCVarDecl.isImplicitlyTyped() is moot, as that call will simply look > to see as to whether the tree type == null. > > Since the var types corresponding to implicitly inferred types are > synthetic and have no position set (see > Attr::setSyntheticVariableType) I decided to use that property instead > to decide as to whether the analyzer should, or should not consider a > given variable declaration. This seems to be a good pragmatic > solution. In the long run we should probably consolidate the treatment > of implicitly inferred variables, and have some kind of common way to > speak about them (e.g. both locals and implicit lambda parameters). > > Webrev: > http://cr.openjdk.java.net/~mcimadamore/8200199/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Wed Mar 28 13:07:30 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 28 Mar 2018 14:07:30 +0100 Subject: RFR 8200199: javac suggests to use var even when var is used In-Reply-To: <68794705-88b1-8ac2-ef1f-2dd80f7ef224@oracle.com> References: <68794705-88b1-8ac2-ef1f-2dd80f7ef224@oracle.com> Message-ID: <82be47ab-f9ab-4bd8-69e0-d1e4284cef61@oracle.com> I think the fact that the position is unset is deliberate - after all the var type is not really there - it just appears magically as a special side-effect of attributing a 'var' declaration (so that the rest of the pipeline can work as usual). In that sense, I believe that not having a position is correct: there's no source position that corresponds to the (synthetic) variable type inferred for a 'var' declaration. This is consistent with other places where we generate synthetic trees. Maurizio On 28/03/18 13:40, Vicente Romero wrote: > question: shouldn't the fact that the vartype in the variable > declaration doesn't have the position of `var` be a bug? > > Vicente > > On 03/28/2018 06:52 AM, Maurizio Cimadamore wrote: >> Hi, >> there is an issue with the local variable inference finder: the >> finder reports possible cases where 'var' could be used even when the >> developer has already used 'var'. This is due to a timing issue with >> which the analyzer runs - by the time it runs, variable types have >> already been written into the AST by Attr - so the call to >> JCVarDecl.isImplicitlyTyped() is moot, as that call will simply look >> to see as to whether the tree type == null. >> >> Since the var types corresponding to implicitly inferred types are >> synthetic and have no position set (see >> Attr::setSyntheticVariableType) I decided to use that property >> instead to decide as to whether the analyzer should, or should not >> consider a given variable declaration. This seems to be a good >> pragmatic solution. In the long run we should probably consolidate >> the treatment of implicitly inferred variables, and have some kind of >> common way to speak about them (e.g. both locals and implicit lambda >> parameters). >> >> Webrev: >> http://cr.openjdk.java.net/~mcimadamore/8200199/ >> >> Cheers >> Maurizio >> > From vicente.romero at oracle.com Wed Mar 28 13:26:08 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 28 Mar 2018 09:26:08 -0400 Subject: RFR 8200199: javac suggests to use var even when var is used In-Reply-To: References: Message-ID: <6ce1d7f2-b26e-9215-97cb-b6c4ed5dded9@oracle.com> looks good, Vicente On 03/28/2018 06:52 AM, Maurizio Cimadamore wrote: > Hi, > there is an issue with the local variable inference finder: the finder > reports possible cases where 'var' could be used even when the > developer has already used 'var'. This is due to a timing issue with > which the analyzer runs - by the time it runs, variable types have > already been written into the AST by Attr - so the call to > JCVarDecl.isImplicitlyTyped() is moot, as that call will simply look > to see as to whether the tree type == null. > > Since the var types corresponding to implicitly inferred types are > synthetic and have no position set (see > Attr::setSyntheticVariableType) I decided to use that property instead > to decide as to whether the analyzer should, or should not consider a > given variable declaration. This seems to be a good pragmatic > solution. In the long run we should probably consolidate the treatment > of implicitly inferred variables, and have some kind of common way to > speak about them (e.g. both locals and implicit lambda parameters). > > Webrev: > http://cr.openjdk.java.net/~mcimadamore/8200199/ > > Cheers > Maurizio > From jan.lahoda at oracle.com Wed Mar 28 15:42:01 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 28 Mar 2018 17:42:01 +0200 Subject: RFR: JDK-8200166: Repeating annotations refering to to-be-generated classes don't work. Message-ID: <5ABBB7C9.5030304@oracle.com> Hi, javac in JDK 10 does not handle properly repeating annotations that contain attributes referring to classes that are generated by an annotation processor. E.g.: --- @Annot(Gen.class) @Annot(Gen.class) public class GeneratedInRepeating { } --- (where "Annot" is a repeating annotation, and "Gen" is a class generated by an annotation processor). This will fail to compile with (please see the bug for a complete example): --- ... error: expression not allowed as annotation value @Annot(Gen.class) --- The annotation processors won't run, so won't have a chance to generate the class. The issue is that Annotate.processRepeatedAnnotations creates a synthetic container annotation for the repeating annotation, constructs an AST for it and tries to attribute it (Annotate lines 821-832). But when the AST is created, as the class in the attribute value is missing, there is an JCErroneous tree generated. And then when Annotate.attributeAnnotationValue checks if the attribute's value is well-formed, it finds the erroneous tree and barks. The code was refactored in JDK-8181464, and was (AFAIK) accepting erroneous trees without producing the error before that. The proposed fix is to ignore the erroneous trees again. If there's an erroneous tree, there should have been an error produced already, so ignoring erroneous trees seems safe. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8200166 Thanks, Jan From jonathan.gibbons at oracle.com Wed Mar 28 15:49:13 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 28 Mar 2018 08:49:13 -0700 Subject: RFR: JDK-8200166: Repeating annotations refering to to-be-generated classes don't work. In-Reply-To: <5ABBB7C9.5030304@oracle.com> References: <5ABBB7C9.5030304@oracle.com> Message-ID: It seems surprising that a JCErroneous tree is used in this context. The syntax is well-formed; the problem is a semantic one of "name not found". "Expression not allowed"??? would seem to apply to something like ??? @Annot(System.out) But ??? @Annot(DoesNotExist.class) Should be "Name not found". -- Jon On 3/28/18 8:42 AM, Jan Lahoda wrote: > Hi, > > javac in JDK 10 does not handle properly repeating annotations that > contain attributes referring to classes that are generated by an > annotation processor. E.g.: > --- > @Annot(Gen.class) > @Annot(Gen.class) > public class GeneratedInRepeating { > } > --- > > (where "Annot" is a repeating annotation, and "Gen" is a class > generated by an annotation processor). This will fail to compile with > (please see the bug for a complete example): > --- > ... error: expression not allowed as annotation value > @Annot(Gen.class) > --- > > The annotation processors won't run, so won't have a chance to > generate the class. > > The issue is that Annotate.processRepeatedAnnotations creates a > synthetic container annotation for the repeating annotation, > constructs an AST for it and tries to attribute it (Annotate lines > 821-832). But when the AST is created, as the class in the attribute > value is missing, there is an JCErroneous tree generated. And then > when Annotate.attributeAnnotationValue checks if the attribute's value > is well-formed, it finds the erroneous tree and barks. > > The code was refactored in JDK-8181464, and was (AFAIK) accepting > erroneous trees without producing the error before that. > > The proposed fix is to ignore the erroneous trees again. If there's an > erroneous tree, there should have been an error produced already, so > ignoring erroneous trees seems safe. > > Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00 > Bug: https://bugs.openjdk.java.net/browse/JDK-8200166 > > Thanks, > ??? Jan From jan.lahoda at oracle.com Wed Mar 28 17:29:42 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 28 Mar 2018 19:29:42 +0200 Subject: RFR: JDK-8200166: Repeating annotations refering to to-be-generated classes don't work. In-Reply-To: References: <5ABBB7C9.5030304@oracle.com> Message-ID: <5ABBD106.3050500@oracle.com> On 28.3.2018 17:49, Jonathan Gibbons wrote: > It seems surprising that a JCErroneous tree is used in this context. The > syntax is well-formed; the problem is a semantic one of "name not found". > > "Expression not allowed" would seem to apply to something like > > @Annot(System.out) > > But > > @Annot(DoesNotExist.class) > > Should be "Name not found". When the parser sees it, it gets parsed OK. But when the annotation is attributed the missing class is modelled as Attribute.UnresolvedClass (a subclass of Attribute.Error). Then the repeating annotation framework takes this, wraps the annotation into the container annotation and creates a new AST for the attributes/compounds, which writes the Attribute.UnresolvedClass/Attribute.Error as JCErroneous. And when the new AST is reattributed using Annotate.attributeAnnotationValue, it will fail on that. I guess an alternate fix may be this: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00b/ Jan > > -- Jon > > > On 3/28/18 8:42 AM, Jan Lahoda wrote: >> Hi, >> >> javac in JDK 10 does not handle properly repeating annotations that >> contain attributes referring to classes that are generated by an >> annotation processor. E.g.: >> --- >> @Annot(Gen.class) >> @Annot(Gen.class) >> public class GeneratedInRepeating { >> } >> --- >> >> (where "Annot" is a repeating annotation, and "Gen" is a class >> generated by an annotation processor). This will fail to compile with >> (please see the bug for a complete example): >> --- >> ... error: expression not allowed as annotation value >> @Annot(Gen.class) >> --- >> >> The annotation processors won't run, so won't have a chance to >> generate the class. >> >> The issue is that Annotate.processRepeatedAnnotations creates a >> synthetic container annotation for the repeating annotation, >> constructs an AST for it and tries to attribute it (Annotate lines >> 821-832). But when the AST is created, as the class in the attribute >> value is missing, there is an JCErroneous tree generated. And then >> when Annotate.attributeAnnotationValue checks if the attribute's value >> is well-formed, it finds the erroneous tree and barks. >> >> The code was refactored in JDK-8181464, and was (AFAIK) accepting >> erroneous trees without producing the error before that. >> >> The proposed fix is to ignore the erroneous trees again. If there's an >> erroneous tree, there should have been an error produced already, so >> ignoring erroneous trees seems safe. >> >> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200166 >> >> Thanks, >> Jan > From jonathan.gibbons at oracle.com Wed Mar 28 17:33:52 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 28 Mar 2018 10:33:52 -0700 Subject: RFR: JDK-8200166: Repeating annotations refering to to-be-generated classes don't work. In-Reply-To: <5ABBD106.3050500@oracle.com> References: <5ABBB7C9.5030304@oracle.com> <5ABBD106.3050500@oracle.com> Message-ID: <1330b391-5f2a-581e-7a03-4b55f55448dd@oracle.com> Without having yet looked at the full webrev, the approach in webrev.00b to create a different sort of AST node looks good. -- Jon On 3/28/18 10:29 AM, Jan Lahoda wrote: > On 28.3.2018 17:49, Jonathan Gibbons wrote: >> It seems surprising that a JCErroneous tree is used in this context. The >> syntax is well-formed; the problem is a semantic one of "name not >> found". >> >> "Expression not allowed"??? would seem to apply to something like >> >> ???? @Annot(System.out) >> >> But >> >> ???? @Annot(DoesNotExist.class) >> >> Should be "Name not found". > > When the parser sees it, it gets parsed OK. But when the annotation is > attributed the missing class is modelled as Attribute.UnresolvedClass > (a subclass of Attribute.Error). > > Then the repeating annotation framework takes this, wraps the > annotation into the container annotation and creates a new AST for the > attributes/compounds, which writes the > Attribute.UnresolvedClass/Attribute.Error as JCErroneous. And when the > new AST is reattributed using Annotate.attributeAnnotationValue, it > will fail on that. > > I guess an alternate fix may be this: > http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00b/ > > Jan > >> >> -- Jon >> >> >> On 3/28/18 8:42 AM, Jan Lahoda wrote: >>> Hi, >>> >>> javac in JDK 10 does not handle properly repeating annotations that >>> contain attributes referring to classes that are generated by an >>> annotation processor. E.g.: >>> --- >>> @Annot(Gen.class) >>> @Annot(Gen.class) >>> public class GeneratedInRepeating { >>> } >>> --- >>> >>> (where "Annot" is a repeating annotation, and "Gen" is a class >>> generated by an annotation processor). This will fail to compile with >>> (please see the bug for a complete example): >>> --- >>> ... error: expression not allowed as annotation value >>> @Annot(Gen.class) >>> --- >>> >>> The annotation processors won't run, so won't have a chance to >>> generate the class. >>> >>> The issue is that Annotate.processRepeatedAnnotations creates a >>> synthetic container annotation for the repeating annotation, >>> constructs an AST for it and tries to attribute it (Annotate lines >>> 821-832). But when the AST is created, as the class in the attribute >>> value is missing, there is an JCErroneous tree generated. And then >>> when Annotate.attributeAnnotationValue checks if the attribute's value >>> is well-formed, it finds the erroneous tree and barks. >>> >>> The code was refactored in JDK-8181464, and was (AFAIK) accepting >>> erroneous trees without producing the error before that. >>> >>> The proposed fix is to ignore the erroneous trees again. If there's an >>> erroneous tree, there should have been an error produced already, so >>> ignoring erroneous trees seems safe. >>> >>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200166 >>> >>> Thanks, >>> ??? Jan >> From maurizio.cimadamore at oracle.com Thu Mar 29 17:31:33 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 29 Mar 2018 18:31:33 +0100 Subject: RFR 8199194: Add javac support for preview features Message-ID: <337174a4-d291-0f04-e154-24b29d305fa4@oracle.com> Hi, Here's a langtools patch to support preview language features as described in JEP 12 [1]. There's also a pending CSR [2] request that describes the set of changes introduced by this patch in great details. Webrev can be found here (the webrev contains also a preview of the new diagnostics emitted by javac, for a quicker evaluation) http://cr.openjdk.java.net/~mcimadamore/8199194/ Implementation-wise, the main decision was how to model preview support. Should it be an extra source (and target) level? I tried to go there, as it seems the path of least resistance, but was ultimately too messy. The main problem we face is that both Source and Target are enums - completely static entities; so we can't attach a lot of state to them (which is needed to generate some of the diagnostics required by the JEP). At the same time, that seems to break an important invariant, that all Source/Target versions should have a corresponding flag that can be passed to the -source/--release options. That is, if 'preview' is an hidden source level, javac has to start distinguishing about public levels and private ones. Instead, I came up with a different approach - there is a new Preview class in langtools, which acts as a 'coordinator' for the preview feature. This means that usages of preview features are reported through this Preview class by other javac classes. Thanks to this, we now can collect all uses of preview features in a single place, and generate diagnostics accordingly. The mapping of which features are preview features is completely ad-hoc, which I think it's desirable. We could add a 'preview' token to Source.Feature - but I think it's best to ask Preview directly if a given Feature is preview or not. This has some advantages: * when a feature goes from preview to stable, we only need to remove the mapping from Preview - Source stays as is * we can exploit the indirection to support test flavors which treat every feature as 'preview'. I used this extensively to be able to generate diagnostic tests. Diagnostic-wise, using preview features with --enable-preview, will generate a note similar to the one for unchecked warnings; users can recompile with the -Xlint:preview flag to get more detailed messages about preview feature usages. Note that by usages here I also mean attempts to load classfiles which have the minor version set to the special preview value (hence, some changes to ClassReader were needed). To demonstrate how the preview support could be leveraged, I tweaked the methods in JavacParser::checkSourceLevel and JavaTokenizer::checkSourceLevel - if the feature to be checked is a preview feature (this test can be forced using the -XDforcePreview flag), then extra checks are carried out, to make sure that preview support is indeed enabled. Since the set of preview features is currently empty, this patch should result in no observable change in the behavior of the javac compiler. Cheers Maurizio [1] - http://openjdk.java.net/jeps/12 [2] - https://bugs.openjdk.java.net/browse/JDK-8200312