From alex.buckley at oracle.com Sat Aug 3 00:07:17 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 2 Aug 2019 17:07:17 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> Message-ID: <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Hi Joe, On 6/20/2019 10:18 AM, Joe Darcy wrote:> Time is late in JDK 13, but for, say, JDK 14 it may be reasonable to add > a java.lang.Preview annotation type to mark preview API elements rather > than relying on overloading the deprecation mechanism. Such an > annotation type would be @Documented and applicable to the sort of > declarations @Deprecated can be applied to. I think @Preview is the right way to go for JDK 14+. It would underpin a number of scenarios where we wish to call developers' attention to preview features: 1. In javadoc -- A casual reader of String::stripIndent's javadoc should realize that this method is special: its association with a preview feature (text blocks) means that it might change or go away in the next release without going through a deprecate-and-wait cycle like normal Java SE methods. An @Documented annotation such as @Preview would let the standard doclet give special visual treatment to types/fields/methods ("API elements") associated with preview features. 2. At compile time -- If you compile with --enable-preview, then any source code reference to an API element associated with a preview feature should generate a (non-suppressible) warning. This warning, which would require JLS support, would be distinct from deprecation warnings; we would then be in a position in JDK 14+ to drop the terminally-deprecated-at-birth scheme adopted in JEP 12 as a stopgap. 3. At run time -- If you compile without --enable-preview, and the source code refers to an API element associated with a preview feature, then javac could give a (non-suppressible) warning and _mark the class file as depending on preview features_. It is important to handle this scenario firmly because the API element might be gone in a later release. Annotating the type/method gives grounds for javac to explain what's going on: "This method is marked @Preview; your class file is now preview-feature dependent." The annotation type that you defined in the webrev (j.l.a.PreviewFeature) looks good. However, I don't think the `release` element is needed. The API in SE $N is what it is; API elements associated with a preview feature are there because a JEP put them there. The `release` element would always be the current JDK release. Alex From stuart.marks at oracle.com Sat Aug 3 00:33:07 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 2 Aug 2019 17:33:07 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: <0daa9898-864b-0f24-033e-445b37c51a23@oracle.com> On 8/2/19 5:07 PM, Alex Buckley wrote: > 3. At run time -- If you compile without --enable-preview, and the source code > refers to an API element associated with a preview feature, then javac could > give a (non-suppressible) warning and _mark the class file as depending on > preview features_. It is important to handle this scenario firmly because the > API element might be gone in a later release. Annotating the type/method gives > grounds for javac to explain what's going on: "This method is marked @Preview; > your class file is now preview-feature dependent." Yes, I have this concern as well. The API might be removed from a later release. Worse, its behavior might change incompatibly in a future release, possibly silently giving results that are incorrect from the application's point of view. Thus, I completely agree that firm treatment is required here. Marking the compiled class as depending on preview features is good inasmuch as will prevent such errors. However, as we all know, people ignore warnings. They might end up with a build that produces an artifact that includes mostly normal class files but that includes a few preview class files. This artifact will work most of the time, until a preview-requiring class file is loaded, at which time the application will fail with an error that I think most people will find inexplicable. Maybe a cleaner approach is to make use of a @Preview API an error in the absence of the --enable-preview option. This is putting a lot of weight on an annotation, perhaps too much; but I think it would be safer to explore this avenue. s'marks From amaembo at gmail.com Sat Aug 3 00:45:20 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 3 Aug 2019 07:45:20 +0700 Subject: Improving compiler messages for preview API In-Reply-To: <0daa9898-864b-0f24-033e-445b37c51a23@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <0daa9898-864b-0f24-033e-445b37c51a23@oracle.com> Message-ID: > Maybe a cleaner approach is to make use of a @Preview API an error in the > absence of the --enable-preview option. This is putting a lot of weight on an > annotation, perhaps too much; but I think it would be safer to explore this avenue. Completely agree: using a @Preview API should be an error in the absence of the --enable-preview option. Just like as using a preview syntax without --enable-preview is an error; not a "non-suppressible warning and special class file version". I think preview API should be handled in the same way as preview language features. With best regards, Tagir Valeev. On Sat, Aug 3, 2019 at 7:36 AM Stuart Marks wrote: > > > On 8/2/19 5:07 PM, Alex Buckley wrote: > > 3. At run time -- If you compile without --enable-preview, and the > source code > > refers to an API element associated with a preview feature, then javac > could > > give a (non-suppressible) warning and _mark the class file as depending > on > > preview features_. It is important to handle this scenario firmly > because the > > API element might be gone in a later release. Annotating the type/method > gives > > grounds for javac to explain what's going on: "This method is marked > @Preview; > > your class file is now preview-feature dependent." > > Yes, I have this concern as well. The API might be removed from a later > release. > Worse, its behavior might change incompatibly in a future release, > possibly > silently giving results that are incorrect from the application's point of > view. > Thus, I completely agree that firm treatment is required here. > > Marking the compiled class as depending on preview features is good > inasmuch as > will prevent such errors. However, as we all know, people ignore warnings. > They > might end up with a build that produces an artifact that includes mostly > normal > class files but that includes a few preview class files. This artifact > will work > most of the time, until a preview-requiring class file is loaded, at which > time > the application will fail with an error that I think most people will find > inexplicable. > > Maybe a cleaner approach is to make use of a @Preview API an error in the > absence of the --enable-preview option. This is putting a lot of weight on > an > annotation, perhaps too much; but I think it would be safer to explore > this avenue. > > s'marks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Sat Aug 3 01:24:18 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 2 Aug 2019 18:24:18 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <0daa9898-864b-0f24-033e-445b37c51a23@oracle.com> Message-ID: On 8/2/2019 5:45 PM, Tagir Valeev wrote: > > Maybe a cleaner approach is to make use of a @Preview API an error in > the > > absence of the --enable-preview option. This is putting a lot of > weight on an > > annotation, perhaps too much; but I think it would be safer to > explore this avenue. > > Completely agree: using a?@Preview API should be an error in the absence > of the --enable-preview option. Just like as using a preview syntax > without --enable-preview is an error; not a "non-suppressible warning > and special class file version". I think preview API should be handled > in the same way as preview language features. I support the policy which Stuart and Tagir have described. A hard partitioning of the SE API into impermanent elements (everything marked @Preview) and permanent elements (everything else, even if marked @Deprecated!) is consistent with the first goal of JEP 12: "Define a model for partitioning new language and VM features ..." In effect, a Java compiler without preview features enabled will produce a compile-time error for any use of an @Preview program element if it would produce a removal warning for the same use of the element if it were @Deprecated(forRemoval=true) rather than @Preview (and assuming that none of the "unless..." clauses in JLS 9.6.4.6 apply). Alex From jonathan.gibbons at oracle.com Sat Aug 3 20:48:16 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 3 Aug 2019 13:48:16 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <0daa9898-864b-0f24-033e-445b37c51a23@oracle.com> Message-ID: <70559e37-f5e9-b4f1-5e5d-beb09f04eb04@oracle.com> On 8/2/19 6:24 PM, Alex Buckley wrote: > On 8/2/2019 5:45 PM, Tagir Valeev wrote: >> ?> Maybe a cleaner approach is to make use of a @Preview API an error >> in the >> ?> absence of the --enable-preview option. This is putting a lot of >> weight on an >> ?> annotation, perhaps too much; but I think it would be safer to >> explore this avenue. >> >> Completely agree: using a?@Preview API should be an error in the >> absence of the --enable-preview option. Just like as using a preview >> syntax without --enable-preview is an error; not a "non-suppressible >> warning and special class file version". I think preview API should >> be handled in the same way as preview language features. > > I support the policy which Stuart and Tagir have described. > > A hard partitioning of the SE API into impermanent elements > (everything marked @Preview) and permanent elements (everything else, > even if marked @Deprecated!) is consistent with the first goal of JEP > 12: "Define a model for partitioning new language and VM features ..." > > In effect, a Java compiler without preview features enabled will > produce a compile-time error for any use of an @Preview program > element if it would produce a removal warning for the same use of the > element if it were @Deprecated(forRemoval=true) rather than @Preview > (and assuming that none of the "unless..." clauses in JLS 9.6.4.6 apply). > > Alex Alex, One topic for discussion is the interaction with the javac --release option. For older releases, you can't use --enable-preview, so I guess the behavior follows from that; for the current release, is there any reason to allow or restrict the combination with --enable-preview? -- Jon From jonathan.gibbons at oracle.com Sat Aug 3 20:57:54 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 3 Aug 2019 13:57:54 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <07dfe47e-0c68-01eb-951f-563153c8cfaa@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <07dfe47e-0c68-01eb-951f-563153c8cfaa@oracle.com> Message-ID: <29672d84-2ded-872f-8198-f20df4efa410@oracle.com> On 6/21/19 10:38 AM, Joe Darcy wrote: > > PS Prototype version of what this sort of message improvement could > look like, initially coded with a JDK-internal annotation type as > opposed to one in java.lang: > > http://cr.openjdk.java.net/~darcy/8226585.0/ > Joe, Could you expand more on the expected use of the "feature" string? 48 /** 49 * Name of the preview feature the annotated API is associated 50 * with. 51 */ 52 String feature() default ""; Could you maybe give some examples of what feature strings might be, and how you might expect the string to be used, especially in a non-English locale? Would you expect to see any enforcement of the set of permitted strings? -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Sun Aug 4 02:47:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 3 Aug 2019 19:47:38 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <29672d84-2ded-872f-8198-f20df4efa410@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <07dfe47e-0c68-01eb-951f-563153c8cfaa@oracle.com> <29672d84-2ded-872f-8198-f20df4efa410@oracle.com> Message-ID: Hi Jon, On 8/3/2019 1:57 PM, Jonathan Gibbons wrote: > > > On 6/21/19 10:38 AM, Joe Darcy wrote: >> >> PS Prototype version of what this sort of message improvement could >> look like, initially coded with a JDK-internal annotation type as >> opposed to one in java.lang: >> >> http://cr.openjdk.java.net/~darcy/8226585.0/ >> > Joe, > > Could you expand more on the expected use of the "feature" string? > > 48 /** > 49 * Name of the preview feature the annotated API is associated > 50 * with. > 51 */ > 52 String feature() default ""; > > > Could you maybe give some examples of what feature strings might be, > and how you might expect the string to be used, especially in a > non-English locale? Would you expect to see any enforcement of the set > of permitted strings? > > Hmm. What I had in mind was a way of approximating the feature-specific messages javac generates for language features where the feature is named. So instead of a message like 1629 # 0: symbol, 1: symbol 1630 compiler.note.preview.api=\ 1631???? {0} in {1} is a preview API and may be removed in a future release a message closer to ???? {0} in {1} is a preview API associated with {2} and may be removed in a future release If the string is not used in the compiler message due to localization issues, it might still be informative as part of the javadoc of the method, especially if some APIs are less obviously associated with a feature than the string method to text blocks. HTH, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sun Aug 4 14:32:36 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 4 Aug 2019 07:32:36 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <07dfe47e-0c68-01eb-951f-563153c8cfaa@oracle.com> <29672d84-2ded-872f-8198-f20df4efa410@oracle.com> Message-ID: On 8/3/19 7:47 PM, Joe Darcy wrote: > > Hi Jon, > > On 8/3/2019 1:57 PM, Jonathan Gibbons wrote: >> >> >> On 6/21/19 10:38 AM, Joe Darcy wrote: >>> >>> PS Prototype version of what this sort of message improvement could >>> look like, initially coded with a JDK-internal annotation type as >>> opposed to one in java.lang: >>> >>> http://cr.openjdk.java.net/~darcy/8226585.0/ >>> >> Joe, >> >> Could you expand more on the expected use of the "feature" string? >> >> 48 /** >> 49 * Name of the preview feature the annotated API is associated >> 50 * with. >> 51 */ >> 52 String feature() default ""; >> >> >> Could you maybe give some examples of what feature strings might be, >> and how you might expect the string to be used, especially in a >> non-English locale? Would you expect to see any enforcement of the >> set of permitted strings? >> >> > > Hmm. What I had in mind was a way of approximating the > feature-specific messages javac generates for language features where > the feature is named. > > So instead of a message like > > 1629 # 0: symbol, 1: symbol > 1630 compiler.note.preview.api=\ > 1631???? {0} in {1} is a preview API and may be removed in a future > release > > a message closer to > > ???? {0} in {1} is a preview API associated with {2} and may be > removed in a future release > > If the string is not used in the compiler message due to localization > issues, it might still be informative as part of the javadoc of the > method, especially if some APIs are less obviously associated with a > feature than the string method to text blocks. > > HTH, > > -Joe > If the string was well enough defined, it could be used as a key in a resource file to generate a localized string. Yes, it would mean updating the resource file in each release, but that would be just a small part of providing a preview feature in a release. Indeed, it could be a required part of defining a preview feature to specify the string to use in preview API annotations. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon Aug 5 12:24:08 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 5 Aug 2019 15:24:08 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: Message-ID: Friendly ping ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro ?: > Hi, > > Please review this change to speed up Resolve.findMethod for large classes > that have large numbers of (super)interfaces > > webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8228675 > > Thanks, > Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Aug 5 15:04:35 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 5 Aug 2019 11:04:35 -0400 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: Message-ID: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> Hi Ron, Just out of curiosity, what is the context in which this issue arises? Naturally consuming more memory we can speed up javac but this can lead to other problems too. Thanks, Vicente On 8/5/19 8:24 AM, Ron Shapiro wrote: > Friendly ping > > ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro > ?>: > > Hi, > > Please review this change to speed up Resolve.findMethod for large > classes that have large numbers of (super)interfaces > > webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8228675 > > Thanks, > Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon Aug 5 14:32:13 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 5 Aug 2019 17:32:13 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> Message-ID: Fair question. github.com/google/dagger generates implementations of interfaces that implement a dependency injection graph. Sometimes, though not always, these interfaces have dozens if not hundreds of (super)interfaces which allow for builds to be sharded: each subsection of the build refers to the superinterface and then at the root of the build there is a union of them all. Naturally, this means this must be rebuilt on most/all changes to any subproject of the build. ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero ?< vicente.romero at oracle.com>: > Hi Ron, > > Just out of curiosity, what is the context in which this issue arises? > Naturally consuming more memory we can speed up javac but this can lead to > other problems too. > > Thanks, > Vicente > > On 8/5/19 8:24 AM, Ron Shapiro wrote: > > Friendly ping > > ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro ?: > >> Hi, >> >> Please review this change to speed up Resolve.findMethod for large >> classes that have large numbers of (super)interfaces >> >> webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >> >> Thanks, >> Ron >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Aug 5 17:24:26 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 5 Aug 2019 13:24:26 -0400 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> Message-ID: <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> not sure if we should add yet another cache to javac but in any case it should be implemented with a: WeakHashMap, Thanks, Vicente On 8/5/19 10:32 AM, Ron Shapiro wrote: > Fair question. > > github.com/google/dagger generates > implementations of interfaces that implement a dependency injection > graph. Sometimes, though not always, these interfaces have dozens if > not hundreds of (super)interfaces which allow for builds to be > sharded: each subsection of the build refers to the superinterface and > then at the root of the build there is a union of them all. Naturally, > this means this must be rebuilt on most/all changes to any subproject > of the build. > > ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero > ?>: > > Hi Ron, > > Just out of curiosity, what is the context in which this issue > arises? Naturally consuming more memory we can speed up javac but > this can lead to other problems too. > > Thanks, > Vicente > > On 8/5/19 8:24 AM, Ron Shapiro wrote: >> Friendly ping >> >> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >> ?>: >> >> Hi, >> >> Please review this change to speed up Resolve.findMethod for >> large classes that have large numbers of (super)interfaces >> >> webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >> >> Thanks, >> Ron >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Aug 5 17:13:36 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 5 Aug 2019 10:13:36 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <70559e37-f5e9-b4f1-5e5d-beb09f04eb04@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <0daa9898-864b-0f24-033e-445b37c51a23@oracle.com> <70559e37-f5e9-b4f1-5e5d-beb09f04eb04@oracle.com> Message-ID: <7513057a-c30d-ffd3-f49c-6bb8687d5cec@oracle.com> On 8/3/2019 1:48 PM, Jonathan Gibbons wrote: > One topic for discussion is the interaction with the javac --release > option. For older releases, you can't use --enable-preview, so I guess > the behavior follows from that; for the current release, is there any > reason to allow or restrict the combination with --enable-preview? You mean that JDK 13 would allow `javac --release 13 --enable-preview` but not `javac --release 12 --enable-preview`, on the grounds that when switch expressions previewed in SE 12, they could have been associated with an API which was potentially changed in SE 13? Alex From jonathan.gibbons at oracle.com Mon Aug 5 17:40:01 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 5 Aug 2019 10:40:01 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: On 8/2/19 5:07 PM, Alex Buckley wrote: > Hi Joe, > > On 6/20/2019 10:18 AM, Joe Darcy wrote:> Time is late in JDK 13, but > for, say, JDK 14 it may be reasonable to add >> a java.lang.Preview annotation type to mark preview API elements >> rather than relying on overloading the deprecation mechanism. Such an >> annotation type would be @Documented and applicable to the sort of >> declarations @Deprecated can be applied to. > > I think @Preview is the right way to go for JDK 14+. It would underpin > a number of scenarios where we wish to call developers' attention to > preview features: > > 1. In javadoc -- A casual reader of String::stripIndent's javadoc > should realize that this method is special: its association with a > preview feature (text blocks) means that it might change or go away in > the next release without going through a deprecate-and-wait cycle like > normal Java SE methods. An @Documented annotation such as @Preview > would let the standard doclet give special visual treatment to > types/fields/methods ("API elements") associated with preview features. > > 2. At compile time -- If you compile with --enable-preview, then any > source code reference to an API element associated with a preview > feature should generate a (non-suppressible) warning. This warning, > which would require JLS support, would be distinct from deprecation > warnings; we would then be in a position in JDK 14+ to drop the > terminally-deprecated-at-birth scheme adopted in JEP 12 as a stopgap. > > 3. At run time -- If you compile without --enable-preview, and the > source code refers to an API element associated with a preview > feature, then javac could give a (non-suppressible) warning and _mark > the class file as depending on preview features_. It is important to > handle this scenario firmly because the API element might be gone in a > later release. Annotating the type/method gives grounds for javac to > explain what's going on: "This method is marked @Preview; your class > file is now preview-feature dependent." > > The annotation type that you defined in the webrev > (j.l.a.PreviewFeature) looks good. However, I don't think the > `release` element is needed. The API in SE $N is what it is; API > elements associated with a preview feature are there because a JEP put > them there. The `release` element would always be the current JDK > release. > > Alex What are the arguments for and against using a public Java SE annotation for this (e.g. j.l.a.PreviewFeature) when the only reasonable/expected usage is within Java SE and the JDK implementation.? There's a tiny tiny code smell defining an annotation type that no other users of Java SE will ever use. That being said, I guess it will enable non-JDK tools to behave appropriately when such an annotation is found. -- Jon From alex.buckley at oracle.com Mon Aug 5 17:52:01 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 5 Aug 2019 10:52:01 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: On 8/5/2019 10:40 AM, Jonathan Gibbons wrote: > What are the arguments for and against using a public Java SE annotation > for this (e.g. j.l.a.PreviewFeature) when the only reasonable/expected > usage is within Java SE and the JDK implementation.? There's a tiny tiny > code smell defining an annotation type that no other users of Java SE > will ever use. That being said, I guess it will enable non-JDK tools to > behave appropriately when such an annotation is found. Some preview language features depend inexorably on APIs, so those APIs need to be in java.* (e.g. String::stripIndent for text blocks). Use of those APIs when preview features are not enabled is extremely dangerous, because the APIs might change or disappear depending on the fate of the associated preview feature. Leaving the developer notification up to individual compilers is inadequate. JEP 12 already mandates a policy for highlighting the changeability of these APIs -- terminal deprecation at birth. Conveniently, that required no JLS or compiler changes. Joe has made a number of arguments, that I hope he will record in JDK-8226585, against using terminal-deprecation-at-birth. Per this thread, a compile-time error is even better than a warning when the developer fails to enable preview features. The only way to get all Java compilers to give an error is with a JLS change and a Java SE annotation. It would not be an error to _apply_ this annotation to declarations outside the Java SE API, but compilers would be required to give an error only when code uses an annotated element which is part of the Java SE API. Alex From jonathan.gibbons at oracle.com Mon Aug 5 18:07:43 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 5 Aug 2019 11:07:43 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: <5a5acf18-f6c8-a10b-6605-a741328a747b@oracle.com> On 08/05/2019 10:52 AM, Alex Buckley wrote: > On 8/5/2019 10:40 AM, Jonathan Gibbons wrote: >> What are the arguments for and against using a public Java SE >> annotation for this (e.g. j.l.a.PreviewFeature) when the only >> reasonable/expected usage is within Java SE and the JDK >> implementation.? There's a tiny tiny code smell defining an >> annotation type that no other users of Java SE will ever use. That >> being said, I guess it will enable non-JDK tools to behave >> appropriately when such an annotation is found. > > Some preview language features depend inexorably on APIs, so those > APIs need to be in java.* (e.g. String::stripIndent for text blocks). > > Use of those APIs when preview features are not enabled is extremely > dangerous, because the APIs might change or disappear depending on the > fate of the associated preview feature. > > Leaving the developer notification up to individual compilers is > inadequate. JEP 12 already mandates a policy for highlighting the > changeability of these APIs -- terminal deprecation at birth. > Conveniently, that required no JLS or compiler changes. > > Joe has made a number of arguments, that I hope he will record in > JDK-8226585, against using terminal-deprecation-at-birth. Per this > thread, a compile-time error is even better than a warning when the > developer fails to enable preview features. > > The only way to get all Java compilers to give an error is with a JLS > change and a Java SE annotation. > > It would not be an error to _apply_ this annotation to declarations > outside the Java SE API, but compilers would be required to give an > error only when code uses an annotated element which is part of the > Java SE API. > > Alex Your last point is a good one, and duly noted. To the rest, yes, while other users may not want to *use* the annotation type, it is definitely of interest to them, and to the tools that they may use, that the annotation has been provided on API related to preview features. -- Jon From jonathan.gibbons at oracle.com Mon Aug 5 18:19:38 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 5 Aug 2019 11:19:38 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <5a5acf18-f6c8-a10b-6605-a741328a747b@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <5a5acf18-f6c8-a10b-6605-a741328a747b@oracle.com> Message-ID: On 08/05/2019 11:07 AM, Jonathan Gibbons wrote: > > > On 08/05/2019 10:52 AM, Alex Buckley wrote: >> On 8/5/2019 10:40 AM, Jonathan Gibbons wrote: >>> What are the arguments for and against using a public Java SE >>> annotation for this (e.g. j.l.a.PreviewFeature) when the only >>> reasonable/expected usage is within Java SE and the JDK >>> implementation.? There's a tiny tiny code smell defining an >>> annotation type that no other users of Java SE will ever use. That >>> being said, I guess it will enable non-JDK tools to behave >>> appropriately when such an annotation is found. >> >> Some preview language features depend inexorably on APIs, so those >> APIs need to be in java.* (e.g. String::stripIndent for text blocks). >> >> Use of those APIs when preview features are not enabled is extremely >> dangerous, because the APIs might change or disappear depending on >> the fate of the associated preview feature. >> >> Leaving the developer notification up to individual compilers is >> inadequate. JEP 12 already mandates a policy for highlighting the >> changeability of these APIs -- terminal deprecation at birth. >> Conveniently, that required no JLS or compiler changes. >> >> Joe has made a number of arguments, that I hope he will record in >> JDK-8226585, against using terminal-deprecation-at-birth. Per this >> thread, a compile-time error is even better than a warning when the >> developer fails to enable preview features. >> >> The only way to get all Java compilers to give an error is with a JLS >> change and a Java SE annotation. >> >> It would not be an error to _apply_ this annotation to declarations >> outside the Java SE API, but compilers would be required to give an >> error only when code uses an annotated element which is part of the >> Java SE API. >> >> Alex > > Your last point is a good one, and duly noted. > > To the rest, yes, while other users may not want to *use* the > annotation type, it is definitely of interest to them, and to the > tools that they may use, that the annotation has been provided on API > related to preview features. > > -- Jon I note that I would want to use the annotation on non-Java SE API, and the com.sun.source.tree API in particular, where we define the compiler AST classes, including any new elements for preview features. -- Jon From alex.buckley at oracle.com Mon Aug 5 18:40:55 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 5 Aug 2019 11:40:55 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <5a5acf18-f6c8-a10b-6605-a741328a747b@oracle.com> Message-ID: <3d2c8c7d-6710-4815-e14f-bbc70827d4fc@oracle.com> On 8/5/2019 11:19 AM, Jonathan Gibbons wrote: > On 08/05/2019 11:07 AM, Jonathan Gibbons wrote: >> On 08/05/2019 10:52 AM, Alex Buckley wrote: >>> On 8/5/2019 10:40 AM, Jonathan Gibbons wrote: >>>> What are the arguments for and against using a public Java SE >>>> annotation for this (e.g. j.l.a.PreviewFeature) when the only >>>> reasonable/expected usage is within Java SE and the JDK >>>> implementation.? There's a tiny tiny code smell defining an >>>> annotation type that no other users of Java SE will ever use. That >>>> being said, I guess it will enable non-JDK tools to behave >>>> appropriately when such an annotation is found. >>> >>> Some preview language features depend inexorably on APIs, so those >>> APIs need to be in java.* (e.g. String::stripIndent for text blocks). >>> >>> Use of those APIs when preview features are not enabled is extremely >>> dangerous, because the APIs might change or disappear depending on >>> the fate of the associated preview feature. >>> >>> Leaving the developer notification up to individual compilers is >>> inadequate. JEP 12 already mandates a policy for highlighting the >>> changeability of these APIs -- terminal deprecation at birth. >>> Conveniently, that required no JLS or compiler changes. >>> >>> Joe has made a number of arguments, that I hope he will record in >>> JDK-8226585, against using terminal-deprecation-at-birth. Per this >>> thread, a compile-time error is even better than a warning when the >>> developer fails to enable preview features. >>> >>> The only way to get all Java compilers to give an error is with a JLS >>> change and a Java SE annotation. >>> >>> It would not be an error to _apply_ this annotation to declarations >>> outside the Java SE API, but compilers would be required to give an >>> error only when code uses an annotated element which is part of the >>> Java SE API. >>> >>> Alex >> >> Your last point is a good one, and duly noted. >> >> To the rest, yes, while other users may not want to *use* the >> annotation type, it is definitely of interest to them, and to the >> tools that they may use, that the annotation has been provided on API >> related to preview features. >> >> -- Jon > > I note that I would want to use the annotation on non-Java SE API, and > the com.sun.source.tree API in particular, where we define the compiler > AST classes, including any new elements for preview features. To be clear about this case, a compiler would be required to do nothing about the use of such an API -- no warning, no error. The definition of java.lang.annotation.PreviewFeature will refer to marking "essential" and "reflective" Java SE APIs connected with preview features; the annotation has no meaning if applied to a non-Java SE API. Alex From jonathan.gibbons at oracle.com Mon Aug 5 19:05:56 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 5 Aug 2019 12:05:56 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <3d2c8c7d-6710-4815-e14f-bbc70827d4fc@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <5a5acf18-f6c8-a10b-6605-a741328a747b@oracle.com> <3d2c8c7d-6710-4815-e14f-bbc70827d4fc@oracle.com> Message-ID: <9b14398c-05a7-4044-f881-ecfc32c3fb50@oracle.com> On 8/5/19 11:40 AM, Alex Buckley wrote: > On 8/5/2019 11:19 AM, Jonathan Gibbons wrote: >> On 08/05/2019 11:07 AM, Jonathan Gibbons wrote: >>> On 08/05/2019 10:52 AM, Alex Buckley wrote: >>>> On 8/5/2019 10:40 AM, Jonathan Gibbons wrote: >>>>> What are the arguments for and against using a public Java SE >>>>> annotation for this (e.g. j.l.a.PreviewFeature) when the only >>>>> reasonable/expected usage is within Java SE and the JDK >>>>> implementation. There's a tiny tiny code smell defining an >>>>> annotation type that no other users of Java SE will ever use. That >>>>> being said, I guess it will enable non-JDK tools to behave >>>>> appropriately when such an annotation is found. >>>> >>>> Some preview language features depend inexorably on APIs, so those >>>> APIs need to be in java.* (e.g. String::stripIndent for text blocks). >>>> >>>> Use of those APIs when preview features are not enabled is >>>> extremely dangerous, because the APIs might change or disappear >>>> depending on the fate of the associated preview feature. >>>> >>>> Leaving the developer notification up to individual compilers is >>>> inadequate. JEP 12 already mandates a policy for highlighting the >>>> changeability of these APIs -- terminal deprecation at birth. >>>> Conveniently, that required no JLS or compiler changes. >>>> >>>> Joe has made a number of arguments, that I hope he will record in >>>> JDK-8226585, against using terminal-deprecation-at-birth. Per this >>>> thread, a compile-time error is even better than a warning when the >>>> developer fails to enable preview features. >>>> >>>> The only way to get all Java compilers to give an error is with a >>>> JLS change and a Java SE annotation. >>>> >>>> It would not be an error to _apply_ this annotation to declarations >>>> outside the Java SE API, but compilers would be required to give an >>>> error only when code uses an annotated element which is part of the >>>> Java SE API. >>>> >>>> Alex >>> >>> Your last point is a good one, and duly noted. >>> >>> To the rest, yes, while other users may not want to *use* the >>> annotation type, it is definitely of interest to them, and to the >>> tools that they may use, that the annotation has been provided on >>> API related to preview features. >>> >>> -- Jon >> >> I note that I would want to use the annotation on non-Java SE API, >> and the com.sun.source.tree API in particular, where we define the >> compiler AST classes, including any new elements for preview features. > > To be clear about this case, a compiler would be required to do > nothing about the use of such an API -- no warning, no error. The > definition of java.lang.annotation.PreviewFeature will refer to > marking "essential" and "reflective" Java SE APIs connected with > preview features; the annotation has no meaning if applied to a > non-Java SE API. > > Alex Hmm. Understood, but disappointed.? That's a fairly big use case you're eliminating (going by the number of declared elements). -- Jon From joe.darcy at oracle.com Mon Aug 5 19:59:13 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 5 Aug 2019 12:59:13 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <5a5acf18-f6c8-a10b-6605-a741328a747b@oracle.com> Message-ID: On 8/5/2019 11:19 AM, Jonathan Gibbons wrote: > > > On 08/05/2019 11:07 AM, Jonathan Gibbons wrote: >> >> >> On 08/05/2019 10:52 AM, Alex Buckley wrote: >>> On 8/5/2019 10:40 AM, Jonathan Gibbons wrote: >>>> What are the arguments for and against using a public Java SE >>>> annotation for this (e.g. j.l.a.PreviewFeature) when the only >>>> reasonable/expected usage is within Java SE and the JDK >>>> implementation.? There's a tiny tiny code smell defining an >>>> annotation type that no other users of Java SE will ever use. That >>>> being said, I guess it will enable non-JDK tools to behave >>>> appropriately when such an annotation is found. >>> >>> Some preview language features depend inexorably on APIs, so those >>> APIs need to be in java.* (e.g. String::stripIndent for text blocks). >>> >>> Use of those APIs when preview features are not enabled is extremely >>> dangerous, because the APIs might change or disappear depending on >>> the fate of the associated preview feature. >>> >>> Leaving the developer notification up to individual compilers is >>> inadequate. JEP 12 already mandates a policy for highlighting the >>> changeability of these APIs -- terminal deprecation at birth. >>> Conveniently, that required no JLS or compiler changes. >>> >>> Joe has made a number of arguments, that I hope he will record in >>> JDK-8226585, against using terminal-deprecation-at-birth. Per this >>> thread, a compile-time error is even better than a warning when the >>> developer fails to enable preview features. >>> >>> The only way to get all Java compilers to give an error is with a >>> JLS change and a Java SE annotation. >>> >>> It would not be an error to _apply_ this annotation to declarations >>> outside the Java SE API, but compilers would be required to give an >>> error only when code uses an annotated element which is part of the >>> Java SE API. >>> >>> Alex >> >> Your last point is a good one, and duly noted. >> >> To the rest, yes, while other users may not want to *use* the >> annotation type, it is definitely of interest to them, and to the >> tools that they may use, that the annotation has been provided on API >> related to preview features. >> >> -- Jon > > I note that I would want to use the annotation on non-Java SE API, and > the com.sun.source.tree API in particular, where we define the > compiler AST classes, including any new elements for preview features. > > Subject to the usual bootstrapping issues of com.sun.source.* being constrained to APIs from Java SE (N-1). Cheers, -Joe From ronshapiro at google.com Wed Aug 7 10:25:23 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 7 Aug 2019 13:25:23 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> Message-ID: Made the change for a WeakHashMap: http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. Perhaps it would make better sense for this to be a field on ClassType? That would avoid the need for managing a cache with weak keys. Do you have any guidance on how you approach tradeoffs in memory vs. speed? On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero wrote: > not sure if we should add yet another cache to javac but in any case it > should be implemented with a: WeakHashMap, > > Thanks, > Vicente > > On 8/5/19 10:32 AM, Ron Shapiro wrote: > > Fair question. > > github.com/google/dagger generates implementations of interfaces that > implement a dependency injection graph. Sometimes, though not always, these > interfaces have dozens if not hundreds of (super)interfaces which allow for > builds to be sharded: each subsection of the build refers to the > superinterface and then at the root of the build there is a union of them > all. Naturally, this means this must be rebuilt on most/all changes to any > subproject of the build. > > ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero ?< > vicente.romero at oracle.com>: > >> Hi Ron, >> >> Just out of curiosity, what is the context in which this issue arises? >> Naturally consuming more memory we can speed up javac but this can lead to >> other problems too. >> >> Thanks, >> Vicente >> >> On 8/5/19 8:24 AM, Ron Shapiro wrote: >> >> Friendly ping >> >> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro ?> >: >> >>> Hi, >>> >>> Please review this change to speed up Resolve.findMethod for large >>> classes that have large numbers of (super)interfaces >>> >>> webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>> >>> Thanks, >>> Ron >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Aug 7 18:52:22 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 7 Aug 2019 11:52:22 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: Hi Alex, On 8/2/2019 5:07 PM, Alex Buckley wrote: > Hi Joe, > > On 6/20/2019 10:18 AM, Joe Darcy wrote:> Time is late in JDK 13, but > for, say, JDK 14 it may be reasonable to add >> a java.lang.Preview annotation type to mark preview API elements >> rather than relying on overloading the deprecation mechanism. Such an >> annotation type would be @Documented and applicable to the sort of >> declarations @Deprecated can be applied to. > > I think @Preview is the right way to go for JDK 14+. It would underpin > a number of scenarios where we wish to call developers' attention to > preview features: > > 1. In javadoc -- A casual reader of String::stripIndent's javadoc > should realize that this method is special: its association with a > preview feature (text blocks) means that it might change or go away in > the next release without going through a deprecate-and-wait cycle like > normal Java SE methods. An @Documented annotation such as @Preview > would let the standard doclet give special visual treatment to > types/fields/methods ("API elements") associated with preview features. > > 2. At compile time -- If you compile with --enable-preview, then any > source code reference to an API element associated with a preview > feature should generate a (non-suppressible) warning. This warning, > which would require JLS support, would be distinct from deprecation > warnings; we would then be in a position in JDK 14+ to drop the > terminally-deprecated-at-birth scheme adopted in JEP 12 as a stopgap. To be precise on terminology, if compiling with --enable-preview, I think the warnings generated for using preview languages feature and associated API elements should be a little-w warnings. That is, messages from the compiler that still allows the compile to exist with a zero exit code. Operationally, such messages would be Diagnostic.Kind.NOTE rather than Diagnostic.Kind.{WARNING, MANDATORY_WARNING}. The goal would be to allow a clean compile under "-Xlint:all -Werror" when preview features were being used. Not allowing "successful" compile of preview features would further complicate adding preview features to CI pipelines, etc. > > 3. At run time -- If you compile without --enable-preview, and the > source code refers to an API element associated with a preview > feature, then javac could give a (non-suppressible) warning and _mark > the class file as depending on preview features_. It is important to > handle this scenario firmly because the API element might be gone in a > later release. Annotating the type/method gives grounds for javac to > explain what's going on: "This method is marked @Preview; your class > file is now preview-feature dependent." As I understand it, currently the call file target to use in javac is determined solely from the command line arguments at the start of the compile. It may be awkward to change this during the compile. (And would it change only for the for the types using the preview feature or fall all types in the compile?) > > The annotation type that you defined in the webrev > (j.l.a.PreviewFeature) looks good. However, I don't think the > `release` element is needed. The API in SE $N is what it is; API > elements associated with a preview feature are there because a JEP put > them there. The `release` element would always be the current JDK > release. > > It isn't necessarily the case an API associated with a preview feature will have been introduced in the most recent JDK. For example, treating JEP 325: "Switch Expressions (Preview)" in 12 and JEP 354: "Switch Expressions (Preview)" in 13 as iterations of the same feature, the tree API has methods to support switch expression support from both JDK 12 and 13: SwitchExpressionTree introduced in 12, still in use in 13: https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/SwitchExpressionTree.html YieldTree introduced in 13: https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/YieldTree.html This situation hasn't occurred yet in the Java SE APIs, but if the iterations of a feature are previewed over multiple releases, it certainly could. The "release" element was modeled after the "since" element in java.lang.Deprecated. It isn't essential information, but I think it is useful to have it presented. -Joe From alex.buckley at oracle.com Wed Aug 7 20:22:52 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 7 Aug 2019 13:22:52 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: On 8/7/2019 11:52 AM, Joe Darcy wrote: > To be precise on terminology, if compiling with --enable-preview, I > think the warnings generated for using preview languages feature and > associated API elements should be a little-w warnings. That is, messages > from the compiler that still allows the compile to exist with a zero > exit code. Operationally, such messages would be Diagnostic.Kind.NOTE > rather than Diagnostic.Kind.{WARNING, MANDATORY_WARNING}. Sure, that is a decision for javac. >> 3. At run time -- If you compile without --enable-preview, and the >> source code refers to an API element associated with a preview >> feature, then javac could give a (non-suppressible) warning and _mark >> the class file as depending on preview features_. It is important to >> handle this scenario firmly because the API element might be gone in a >> later release. Annotating the type/method gives grounds for javac to >> explain what's going on: "This method is marked @Preview; your class >> file is now preview-feature dependent." > > As I understand it, currently the call file target to use in javac is > determined solely from the command line arguments at the start of the > compile. It may be awkward to change this during the compile. (And would > it change only for the for the types using the preview feature or fall > all types in the compile?) Does "call file target" mean "class file target", e.g. 57.0 versus 57.65535? I suspect it's moot anyway -- this thread has already moved on from "give a warning, and mark the class file as depending on preview features", to "give an error, so no class file to worry about." >> The annotation type that you defined in the webrev >> (j.l.a.PreviewFeature) looks good. However, I don't think the >> `release` element is needed. The API in SE $N is what it is; API >> elements associated with a preview feature are there because a JEP put >> them there. The `release` element would always be the current JDK >> release. >> > It isn't necessarily the case an API associated with a preview feature > will have been introduced in the most recent JDK. For example, treating > JEP 325: "Switch Expressions (Preview)" in 12 and JEP 354: "Switch > Expressions (Preview)" in 13 as iterations of the same feature, the tree > API has methods to support switch expression support from both JDK 12 > and 13: > > SwitchExpressionTree introduced in 12, still in use in 13: > https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/SwitchExpressionTree.html > > YieldTree introduced in 13: > https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/YieldTree.html > > This situation hasn't occurred yet in the Java SE APIs, but if the > iterations of a feature are previewed over multiple releases, it > certainly could. > > The "release" element was modeled after the "since" element in > java.lang.Deprecated. It isn't essential information, but I think it is > useful to have it presented. Sorry, I am not concerned with how to mark compiler-internal APIs that support preview features, whether in javac or in any other compiler. The audience of developers who might accidentally over-rely on such APIs is tiny. I am concerned about how to mark Java SE APIs as being associated with preview features, because the audience of developers who might accidentally over-rely on them is enormous. In that vein, if an SE 12 preview feature re-previews in SE 13, then any associated API in 13 should NOT say @PreviewFeature(release="12") -- even if the API is unchanged between 12's preview feature and 13's preview feature. The JEP which does the re-previewing is responsible for saying how associated APIs from the first round evolve in the second round, so by definition, any associated API present in 13 is the 13 version, and `release="13"` is unnecessary. Alex From jonathan.gibbons at oracle.com Wed Aug 7 20:30:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 7 Aug 2019 13:30:55 -0700 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: <077e128c-d4c8-3035-db29-6ac63178a50e@oracle.com> On 8/7/19 1:22 PM, Alex Buckley wrote: > On 8/7/2019 11:52 AM, Joe Darcy wrote: >> To be precise on terminology, if compiling with --enable-preview, I >> think the warnings generated for using preview languages feature and >> associated API elements should be a little-w warnings. That is, >> messages from the compiler that still allows the compile to exist >> with a zero exit code. Operationally, such messages would be >> Diagnostic.Kind.NOTE rather than Diagnostic.Kind.{WARNING, >> MANDATORY_WARNING}. > Sure, that is a decision for javac. > >>> 3. At run time -- If you compile without --enable-preview, and the >>> source code refers to an API element associated with a preview >>> feature, then javac could give a (non-suppressible) warning and >>> _mark the class file as depending on preview features_. It is >>> important to handle this scenario firmly because the API element >>> might be gone in a later release. Annotating the type/method gives >>> grounds for javac to explain what's going on: "This method is marked >>> @Preview; your class file is now preview-feature dependent." >> >> As I understand it, currently the call file target to use in javac is >> determined solely from the command line arguments at the start of the >> compile. It may be awkward to change this during the compile. (And >> would it change only for the for the types using the preview feature >> or fall all types in the compile?) > > Does "call file target" mean "class file target", e.g. 57.0 versus > 57.65535? I suspect it's moot anyway -- this thread has already moved > on from "give a warning, and mark the class file as depending on > preview features", to "give an error, so no class file to worry about." > >>> The annotation type that you defined in the webrev >>> (j.l.a.PreviewFeature) looks good. However, I don't think the >>> `release` element is needed. The API in SE $N is what it is; API >>> elements associated with a preview feature are there because a JEP >>> put them there. The `release` element would always be the current >>> JDK release. >>> >> It isn't necessarily the case an API associated with a preview >> feature will have been introduced in the most recent JDK. For >> example, treating JEP 325: "Switch Expressions (Preview)" in 12 and >> JEP 354: "Switch Expressions (Preview)" in 13 as iterations of the >> same feature, the tree API has methods to support switch expression >> support from both JDK 12 and 13: >> >> SwitchExpressionTree introduced in 12, still in use in 13: >> https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/SwitchExpressionTree.html >> >> YieldTree introduced in 13: >> https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/YieldTree.html >> > >> This situation hasn't occurred yet in the Java SE APIs, but if the >> iterations of a feature are previewed over multiple releases, it >> certainly could. >> >> The "release" element was modeled after the "since" element in >> java.lang.Deprecated. It isn't essential information, but I think it >> is useful to have it presented. > > Sorry, I am not concerned with how to mark compiler-internal APIs that > support preview features, whether in javac or in any other compiler. > The audience of developers who might accidentally over-rely on such > APIs is tiny. I am concerned about how to mark Java SE APIs as being > associated with preview features, because the audience of developers > who might accidentally over-rely on them is enormous. In that vein, if > an SE 12 preview feature re-previews in SE 13, then any associated API > in 13 should NOT say @PreviewFeature(release="12") -- even if the API > is unchanged between 12's preview feature and 13's preview feature. > The JEP which does the re-previewing is responsible for saying how > associated APIs from the first round evolve in the second round, so by > definition, any associated API present in 13 is the 13 version, and > `release="13"` is unnecessary. > > Alex While I accept that you may not be concerned with non-SE API, I note that the APIs I'm talking about are public documented supported JDK APIs, and not just compiler-internal APIs. https://docs.oracle.com/en/java/javase/11/docs/api/jdk.compiler/com/sun/source/tree/package-summary.html -- Jon From maurizio.cimadamore at oracle.com Wed Aug 7 21:04:19 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 7 Aug 2019 22:04:19 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> Message-ID: <5b7142ca-c5eb-04ec-43d5-484f3cdf4d8d@oracle.com> I've been catching up on this discussion - having written this code, I know this is tricky and also hard to optimize. Some efforts were already put in trying to minimize the lookups, but it seems now you are being affected by the cost of calling types.closure, which I understand. Looking at the code again, I wonder if, before doing something, I'd like to step back and look at what the code is doing - specifically, I'm looking at this: for (Type itype : itypes[iphase2.ordinal()]) { ??????????????? if (!itype.isInterface()) continue; //skip j.l.Object (included by Types.closure()) ??????????????? if (iphase2 == InterfaceLookupPhase.DEFAULT_OK && ??????????????????????? (itype.tsym.flags() & DEFAULT) == 0) continue; So there are two cases where the type in the itypes array is actually not even looked at: * the type is Object - ok, this is a corner case - because closure() will return also Object, fine * if we're looking for defaults, and the type we have on our hands does not have the DEFAULT flag set, quit the search Now it would be tempting to say that if a type doesn't have the DEFAULT flag set, then we can avoid adding its closure to the set - but that's wishful thinking; the flag is (currently) only set for interfaces that declare some default methods themselves. So, even if an interface doesn't declare any default method, we still have to search its superinterfaces, as some of those might. And this is where the big lookup cost associated with default methods is coming from - we have to scan all superinterfaces in case _one_ might have some default in it that is more specific than the method we have already found. I think one possible way to optimize this algorithm would be to actually do the opposite - e.g. to mark (as we scan them) interfaces whose hierarchies are NOT known to have any default methods in them. If we had such a detection mechanism, we could then prune entire families of interfaces (and their parents) from the findMethod lookup - which would bring back lookup performances with what we had before 8 (I'm assuming that was fast enough for the use cases brought up here?). If you think that such an optimization is likely to give good results, then I'd rather invest on that: since here we'd simply require a flag to cache the interface hierarchy status w.r.t. default methods, I'm less worried that the caching mechanism will backfire and turn into cases of horrible memory footprint regression (we have seen that happening in the past with cases like these). Thoughts? Cheers Maurizio On 07/08/2019 11:25, Ron Shapiro wrote: > Made the change for a WeakHashMap: > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. > > Perhaps it would make better sense for this to be a field on > ClassType? That would avoid the need for managing a cache with weak keys. > > Do you have any guidance on how you approach tradeoffs in memory vs. > speed? > > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero > > wrote: > > not sure if we should add yet another cache to javac but in any > case it should be implemented with a: WeakHashMap, > > Thanks, > Vicente > > On 8/5/19 10:32 AM, Ron Shapiro wrote: >> Fair question. >> >> github.com/google/dagger >> generates implementations of interfaces that implement a >> dependency injection graph. Sometimes, though not always, these >> interfaces have dozens if not hundreds of (super)interfaces which >> allow for builds to be sharded: each subsection of the build >> refers to the superinterface and then at the root of the build >> there is a union of them all. Naturally, this means this must be >> rebuilt on most/all changes to any subproject of the build. >> >> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >> ?>: >> >> Hi Ron, >> >> Just out of curiosity, what is the context in which this >> issue arises? Naturally consuming more memory we can speed up >> javac but this can lead to other problems too. >> >> Thanks, >> Vicente >> >> On 8/5/19 8:24 AM, Ron Shapiro wrote: >>> Friendly ping >>> >>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >>> ?>: >>> >>> Hi, >>> >>> Please review this change to speed up Resolve.findMethod >>> for large classes that have large numbers of >>> (super)interfaces >>> >>> webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>> >>> Thanks, >>> Ron >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrjarviscraft at gmail.com Thu Aug 8 17:16:05 2019 From: mrjarviscraft at gmail.com (JARvis PROgrammer) Date: Thu, 8 Aug 2019 20:16:05 +0300 Subject: Possible bug: compiler generating `ldc` instead of `sipush` and `iconst_m1` for characters in range [32768; 65535] Message-ID: Hi there, it seems that the javac compiler generates non-optimal bytecode for pushing values of (compile-time) type `char`. In order to test it I've first written a class which has a method accepting `char`s which writes them to a file (so that results can be easily compared): private static void consumeChar(final char character) throws IOException { try (final BufferedWriter writer = new BufferedWriter(new FileWriter(new File("Javac.txt"), true))) { writer.write(Character.toString(character)); } } And then added code to `main` which simply invokes this method for all corner cases and nearby char values {(char) 0, (char) 1, (char) 2, (char) 3, (char) 4, (char) 5, (char) 6, (char) 7, (char) 126, (char) 127, (char) 128, (char) 129, (char) 32766, (char) 32767, (char) 32768, (char) 32769, (char) 65534, (char) 65535}. After this the class was compiled using `javac` (both tested on release 11 and early-access 13). The resulting bytecode uses *iconst#* for range [(char) 0; (char) 5], *bipush* for range from [(char) 6; (char) 127], *sipush* for range [(char) 128; (char) 32767] and (strangely) *ldc* for range [(char) 32768; (char) 65535]. In order to check if the strange behavour is not the only way to achieve pushing "big" `char` values onto the stack, I've recreated the similar class using ObjectWeb ASM using *iconst_m1* instruction for pusing ((char) 65535) and *sipush* (with negative values) for pushing values of range [(char) 32768; (char) 65534]. The following function describes this behaviour: private static void pushChar(final MethodVisitor method, final int charCode) { switch (charCode) { case 65535: { method.visitInsn(ICONST_M1); break; } case 1: { method.visitInsn(ICONST_1); break; } case 2: { method.visitInsn(ICONST_2); break; } case 3: { method.visitInsn(ICONST_3); break; } case 4: { method.visitInsn(ICONST_4); break; } case 5: { method.visitInsn(ICONST_5); break; } default: { if (charCode <= Byte.MAX_VALUE) method.visitIntInsn(BIPUSH, charCode else method.visitIntInsn(SIPUSH, (short) charCode); } } } (PS, in theory, *bipush* might also be aplicable for some values where *sipush* is used, but I didn't test it) The generated class once run via java (release 11 and early-access 13 were used) generated the file with content equal to the one of the javac-compiled class. And so, it seems to be a bug that `javac` uses *ldc* instruction instead of more primitive ones while those may handle all range of characters. All files used for test purposes (including javap call results) are attached to this message: JavacMain.java - source code of class compiled via javac JavacMain.class - compiled JavacMain.java (javac -g:none --enable-preview) JavacMain.javap - disassembled JavacMain.class (javac -v -p -s -c) Javac.txt - file written by running JavacMain.class AsmMain_Generator.java - source code of class generating AsmMain.class AsmMain.class - generated replica of JavacMain.class using *iconst_m1* instruction for pusing ((char) 65535) and *sipush* (with negative values) for pushing values of range [(char) 32768; (char) 65534] Asm Main.javap - disassembled AsmMain.class (javac -v -p -s -c) Asm.txt - file written by running AsmMain.class -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ~???????? -------------- next part -------------- A non-text attachment was scrubbed... Name: JavacMain.java Type: application/octet-stream Size: 1190 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JavacMain.class Type: application/octet-stream Size: 904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JavacMain.javap Type: application/octet-stream Size: 8513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AsmMain_Generator.java Type: application/octet-stream Size: 9158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AsmMain.class Type: application/octet-stream Size: 883 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AsmMain.javap Type: application/octet-stream Size: 8252 bytes Desc: not available URL: -------------- next part -------------- ~???????? From alex.buckley at oracle.com Thu Aug 8 23:27:34 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 8 Aug 2019 16:27:34 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <077e128c-d4c8-3035-db29-6ac63178a50e@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <077e128c-d4c8-3035-db29-6ac63178a50e@oracle.com> Message-ID: On 8/7/2019 1:30 PM, Jonathan Gibbons wrote: > While I accept that you may not be concerned with non-SE API, I note > that the APIs I'm talking about are public documented supported JDK > APIs, and not just compiler-internal APIs. There is an SE-oriented variant of supported compiler APIs: what JEP 12 calls "reflective" APIs. For example, if record types preview in SE 14, then should associated methods in Core Reflection such as Class::isRecord be marked @PreviewFeature? On the one hand, no -- enthusiastic framework authors should be able to use Class::isRecord to handle user-defined records in an appropriate way, without the framework's own classes having to be compiled and run with --enable-preview. On the other hand, yes -- the possibility of records changing in future means that any class's use of Class::isRecord should be strictly boxed in by having to enable preview features; framework authors can use MRJARs to separate 14-era class files from the rest. One option is to say that use of essential @PreviewFeature APIs without --enable-preview gets an error, but use of reflective @PreviewFeature APIs without --enable-preview gets a warning -- but now that warning needs to be defined and engineered, and there will be requests to handle non-SE APIs in the same manner as reflective SE APIs. So, I plan to stick with JEP 12's current policy and treat essential and reflective APIs the same: their use requires --enable-preview. Alex From maurizio.cimadamore at oracle.com Thu Aug 8 23:52:12 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Aug 2019 00:52:12 +0100 Subject: Possible bug: compiler generating `ldc` instead of `sipush` and `iconst_m1` for characters in range [32768; 65535] In-Reply-To: References: Message-ID: Yes, there seems to be some suboptimality here - which I have also been able to reproduce with other compilers (namely ecj). I guess the code didn't check for all the possible optimization opportunities - yes, values from 128 to 255 can still be encoded in a (negative) byte and values from 32768 to 65535 can be encoded in a (negative) short, so no ldc should be needed, at least in principle. In terms of perfomances though - this is hardly going to make any difference, as the JIT will easily see through the redundancy. An argument can be made though that we are wasting valuable constant pool estate when we can avoid it, so, IMHO that would be the main reason to fix something like this. Cheers Maurizio On 08/08/2019 18:16, JARvis PROgrammer wrote: > Hi there, it seems that the javac compiler generates non-optimal > bytecode for pushing values of (compile-time) type `char`. > In order to test it I've first written a class which has a method > accepting `char`s which writes them to a file (so that results can be > easily compared): > private static void consumeChar(final char character)throws IOException { > try (final BufferedWriter writer =new BufferedWriter(new FileWriter(new File("Javac.txt"), true))) { > writer.write(Character.toString(character)); } > } > And then added code to `main` which simply invokes this method for all > corner cases and nearby char values {(char) 0, (char) 1, (char) 2, > (char) 3, (char) 4, (char) 5, (char) 6, (char) 7, (char) 126, (char) > 127, (char) 128, (char) 129, (char) 32766, (char) 32767, (char) 32768, > (char) 32769, (char) 65534, (char) 65535}. After this the class was > compiled using `javac` (both tested on release 11 and early-access 13). > The resulting bytecode uses /iconst#/ for range [(char)?0; (char)?5], > /bipush/ for range from [(char)?6; (char)?127], /sipush/ for range > [(char)?128; (char)?32767] and (strangely) /ldc/ for range [(char) > 32768; (char)?65535]. > In order to check if the strange behavour is not the only way to > achieve pushing "big" `char` values onto the stack, I've recreated the > similar class using ObjectWeb ASM using /iconst_m1/ instruction for > pusing ((char) 65535) and /sipush/ (with negative values) for pushing > values of range [(char) 32768; (char) 65534]. > The following function describes this behaviour: > private static void pushChar(final MethodVisitor method, final int charCode) { > switch (charCode) { > case 65535: { > method.visitInsn(ICONST_M1);break;} > case 1: { > method.visitInsn(ICONST_1);break;} > case 2: { > method.visitInsn(ICONST_2);break;} > case 3: { > method.visitInsn(ICONST_3);break;} > case 4: { > method.visitInsn(ICONST_4);break;} > case 5: { > method.visitInsn(ICONST_5);break;}default: { > if (charCode <= Byte.MAX_VALUE) method.visitIntInsn(BIPUSH, charCode > else method.visitIntInsn(SIPUSH, (short) charCode);} > } > } > (PS, in theory, /bipush/ might also be aplicable for some values where > /sipush/ is used, but I didn't test it) > The generated class once run via java (release 11 and early-access 13 > were used) generated the file with content equal to the one of the > javac-compiled class. > > And so, it seems to be a bug that `javac` uses /ldc/ instruction > instead of more primitive ones while those may handle all range of > characters. > > All files used for test purposes (including javap call results) are > attached to this message: > JavacMain.java - source code of class compiled via javac > JavacMain.class - compiled JavacMain.java (javac -g:none --enable-preview) > JavacMain.javap - disassembled?JavacMain.class?(javac??-v -p -s -c) > Javac.txt - file written by running JavacMain.class > > AsmMain_Generator.java - source code of class generating AsmMain.class > AsmMain.class - generated replica of JavacMain.class using > /iconst_m1/?instruction for pusing ((char) 65535) and /sipush/?(with > negative values) for pushing values of range [(char) 32768; (char) 65534] > Asm? Main.javap - disassembled AsmMain.class?(javac??-v -p -s -c) > Asm.txt - file written by running?AsmMain.class -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Aug 9 00:08:59 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Aug 2019 01:08:59 +0100 Subject: Improving compiler messages for preview API In-Reply-To: References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> Message-ID: <4b7d5502-24cb-4e55-ccf8-e9e2b6976834@oracle.com> Late to the party There is a tension between having an annotation - and then claim that said annotation can only be used in A, B, C. Another possible path would be to explicitly list in the compiler the set of preview method symbols - I'm pretty sure this can be made to work reliably - but it kind of miss a big point: an annotation is not just there for telling javac what to do (which we can do in other ways), it's also there as a source of _documentation_ - both for the source and, more importantly, Javadoc. Ideally, what you want is to add @Preview in a non-exported package, (pretty much as @ForceInline) so that it can be used wherever (including non SE APIs) in the JDK (provided the package is qualified-exported accordingly) - and that takes care of the fact that the annotation could not be placed on code outside of the JDK. The big problem of this approach is that, of course, it would be a bit odd to define what the behavior of the preview feature should be, especially, what the compiler should do when encountering a method marked with @Preview, if @Preview itself is not part of the Java SE API - meaning a spec (e.g. JLS) cant really refer to it. But, is there a need for the spec to refer to it? Could we get away with saying that "there must be a way to mark preview API methods" without saying _what_ way that is? Maurizio On 07/08/2019 21:22, Alex Buckley wrote: > On 8/7/2019 11:52 AM, Joe Darcy wrote: >> To be precise on terminology, if compiling with --enable-preview, I >> think the warnings generated for using preview languages feature and >> associated API elements should be a little-w warnings. That is, >> messages from the compiler that still allows the compile to exist >> with a zero exit code. Operationally, such messages would be >> Diagnostic.Kind.NOTE rather than Diagnostic.Kind.{WARNING, >> MANDATORY_WARNING}. > Sure, that is a decision for javac. > >>> 3. At run time -- If you compile without --enable-preview, and the >>> source code refers to an API element associated with a preview >>> feature, then javac could give a (non-suppressible) warning and >>> _mark the class file as depending on preview features_. It is >>> important to handle this scenario firmly because the API element >>> might be gone in a later release. Annotating the type/method gives >>> grounds for javac to explain what's going on: "This method is marked >>> @Preview; your class file is now preview-feature dependent." >> >> As I understand it, currently the call file target to use in javac is >> determined solely from the command line arguments at the start of the >> compile. It may be awkward to change this during the compile. (And >> would it change only for the for the types using the preview feature >> or fall all types in the compile?) > > Does "call file target" mean "class file target", e.g. 57.0 versus > 57.65535? I suspect it's moot anyway -- this thread has already moved > on from "give a warning, and mark the class file as depending on > preview features", to "give an error, so no class file to worry about." > >>> The annotation type that you defined in the webrev >>> (j.l.a.PreviewFeature) looks good. However, I don't think the >>> `release` element is needed. The API in SE $N is what it is; API >>> elements associated with a preview feature are there because a JEP >>> put them there. The `release` element would always be the current >>> JDK release. >>> >> It isn't necessarily the case an API associated with a preview >> feature will have been introduced in the most recent JDK. For >> example, treating JEP 325: "Switch Expressions (Preview)" in 12 and >> JEP 354: "Switch Expressions (Preview)" in 13 as iterations of the >> same feature, the tree API has methods to support switch expression >> support from both JDK 12 and 13: >> >> SwitchExpressionTree introduced in 12, still in use in 13: >> https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/SwitchExpressionTree.html >> >> YieldTree introduced in 13: >> https://download.java.net/java/early_access/jdk13/docs/api/jdk.compiler/com/sun/source/tree/YieldTree.html >> > >> This situation hasn't occurred yet in the Java SE APIs, but if the >> iterations of a feature are previewed over multiple releases, it >> certainly could. >> >> The "release" element was modeled after the "since" element in >> java.lang.Deprecated. It isn't essential information, but I think it >> is useful to have it presented. > > Sorry, I am not concerned with how to mark compiler-internal APIs that > support preview features, whether in javac or in any other compiler. > The audience of developers who might accidentally over-rely on such > APIs is tiny. I am concerned about how to mark Java SE APIs as being > associated with preview features, because the audience of developers > who might accidentally over-rely on them is enormous. In that vein, if > an SE 12 preview feature re-previews in SE 13, then any associated API > in 13 should NOT say @PreviewFeature(release="12") -- even if the API > is unchanged between 12's preview feature and 13's preview feature. > The JEP which does the re-previewing is responsible for saying how > associated APIs from the first round evolve in the second round, so by > definition, any associated API present in 13 is the 13 version, and > `release="13"` is unnecessary. > > Alex From alex.buckley at oracle.com Fri Aug 9 00:54:21 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 8 Aug 2019 17:54:21 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <4b7d5502-24cb-4e55-ccf8-e9e2b6976834@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <4b7d5502-24cb-4e55-ccf8-e9e2b6976834@oracle.com> Message-ID: <91b1b04a-4934-d847-39ac-cf759845738f@oracle.com> On 8/8/2019 5:08 PM, Maurizio Cimadamore wrote: > Ideally, what you want is to add @Preview in a non-exported package, > (pretty much as @ForceInline) so that it can be used wherever (including > non SE APIs) in the JDK (provided the package is qualified-exported > accordingly) - and that takes care of the fact that the annotation could > not be placed on code outside of the JDK. This was Joe's initial intent -- jdk.internal.Preview to be precise -- but it would be inappropriate for such an annotation type to be @Documented and show up in the javadoc on String::stripIndent. There is also the other problem you raise: > what the compiler should do when encountering a method > marked with @Preview, if @Preview itself is not part of the Java SE API > - meaning a spec (e.g. JLS) cant really refer to it. But, is there a > need for the spec to refer to it? Could we get away with saying that > "there must be a way to mark preview API methods" without saying _what_ > way that is? The JLS is not and cannot be "open". In order for the JLS to mandate an error (or even a warning) about use of a preview-feature-connected API, the Java SE Platform has to be the ultimate authority for identifying such APIs. The identification must be normative, though it can be lightweight -- a simple mention of "Text Blocks (JEP 355)" in the Platform JSR is enough to get String::stripIndent on the list. Now, I would be mostly OK with dropping the SE-defined @PreviewFeature annotation if compiler vendors were eager to incorporate knowledge of such Platform-identified APIs, but it was made clear (internally) that javac did not want to do this. So, we have a marker annotation (in SE), and we have some consensus about wanting an error when identified APIs (in SE) are used without enabling preview features, and those two design choices work together. Let's not spend more time pondering how non-SE APIs can play in the preview sandpit please. Alex From maurizio.cimadamore at oracle.com Fri Aug 9 10:20:32 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Aug 2019 11:20:32 +0100 Subject: Possible bug: compiler generating `ldc` instead of `sipush` and `iconst_m1` for characters in range [32768; 65535] In-Reply-To: References: Message-ID: <2172cb11-6709-6159-71d9-164ec7a1f21a@oracle.com> Actually, thinking more about this... I'm not convinced it is a bug. Consider the following simple example: class Foo { ?? public static int m(char c) { ????? return c; ?? } ?? public static void main(String[] args) { ????? System.out.println(m((char)-1)); ?? } } This currently prints "65535". The bytecode for the invocation in 'main' is as follows: 3: ldc?????????? #3????????????????? // int 65535 5: invokestatic? #4????????????????? // Method m:(C)I Now, if we were to replace the "ldc 65535" with a iconst_m1, the net effect would be to load a 32-bit wide -1 constant. So this example would end up printing -1, that is, no overflow/truncation behavior would be exposed. So, I think that the reason why 'less optimal' opcodes are used is precisely that: to respect the semantics of truncation vs. sign extension. sipush has a similar issue - as the JVMS says: "The immediate unsigned /byte1/ and /byte2/ values are assembled into an intermediate |short|, where the value of the |short| is (/byte1/ |<<| 8) | /byte2/. *The intermediate value is then sign-extended to an **|int|****/value/*. That /value/ is pushed onto the operand stack." So again, you have a sign extension, which will not respect the truncation semantics of the language. The instruction bipush is similar. So, bipush, sipush can only be safely use to handle chars if they handle positive values - if they are used with negative values, the sign extension embedded in the opcode would lead to the same results as using iconst_m1. The only way then to use these bytecodes in the "right" way would be to immediately follow the load instruction with a i2c instruction. So it's a trade off between number of instructions and constant pool pressure. In conlusion, I don't think anything needs to be changed here. Maurizio On 09/08/2019 00:52, Maurizio Cimadamore wrote: > > Yes, there seems to be some suboptimality here - which I have also > been able to reproduce with other compilers (namely ecj). > > I guess the code didn't check for all the possible optimization > opportunities - yes, values from 128 to 255 can still be encoded in a > (negative) byte and values from 32768 to 65535 can be encoded in a > (negative) short, so no ldc should be needed, at least in principle. > > In terms of perfomances though - this is hardly going to make any > difference, as the JIT will easily see through the redundancy. An > argument can be made though that we are wasting valuable constant pool > estate when we can avoid it, so, IMHO that would be the main reason to > fix something like this. > > Cheers > Maurizio > > On 08/08/2019 18:16, JARvis PROgrammer wrote: >> Hi there, it seems that the javac compiler generates non-optimal >> bytecode for pushing values of (compile-time) type `char`. >> In order to test it I've first written a class which has a method >> accepting `char`s which writes them to a file (so that results can be >> easily compared): >> private static void consumeChar(final char character)throws IOException { >> try (final BufferedWriter writer =new BufferedWriter(new FileWriter(new File("Javac.txt"), true))) { >> writer.write(Character.toString(character)); } >> } >> And then added code to `main` which simply invokes this method for >> all corner cases and nearby char values {(char) 0, (char) 1, (char) >> 2, (char) 3, (char) 4, (char) 5, (char) 6, (char) 7, (char) 126, >> (char) 127, (char) 128, (char) 129, (char) 32766, (char) 32767, >> (char) 32768, (char) 32769, (char) 65534, (char) 65535}. After this >> the class was compiled using `javac` (both tested on release 11 and >> early-access 13). >> The resulting bytecode uses /iconst#/ for range [(char)?0; (char)?5], >> /bipush/ for range from [(char)?6; (char)?127], /sipush/ for range >> [(char)?128; (char)?32767] and (strangely) /ldc/ for range [(char) >> 32768; (char)?65535]. >> In order to check if the strange behavour is not the only way to >> achieve pushing "big" `char` values onto the stack, I've recreated >> the similar class using ObjectWeb ASM using /iconst_m1/ instruction >> for pusing ((char) 65535) and /sipush/ (with negative values) for >> pushing values of range [(char) 32768; (char) 65534]. >> The following function describes this behaviour: >> private static void pushChar(final MethodVisitor method, final int charCode) { >> switch (charCode) { >> case 65535: { >> method.visitInsn(ICONST_M1);break;} >> case 1: { >> method.visitInsn(ICONST_1);break;} >> case 2: { >> method.visitInsn(ICONST_2);break;} >> case 3: { >> method.visitInsn(ICONST_3);break;} >> case 4: { >> method.visitInsn(ICONST_4);break;} >> case 5: { >> method.visitInsn(ICONST_5);break;}default: { >> if (charCode <= Byte.MAX_VALUE) method.visitIntInsn(BIPUSH, charCode >> else method.visitIntInsn(SIPUSH, (short) charCode);} >> } >> } >> (PS, in theory, /bipush/ might also be aplicable for some values >> where /sipush/ is used, but I didn't test it) >> The generated class once run via java (release 11 and early-access 13 >> were used) generated the file with content equal to the one of the >> javac-compiled class. >> >> And so, it seems to be a bug that `javac` uses /ldc/ instruction >> instead of more primitive ones while those may handle all range of >> characters. >> >> All files used for test purposes (including javap call results) are >> attached to this message: >> JavacMain.java - source code of class compiled via javac >> JavacMain.class - compiled JavacMain.java (javac -g:none >> --enable-preview) >> JavacMain.javap - disassembled?JavacMain.class?(javac??-v -p -s -c) >> Javac.txt - file written by running JavacMain.class >> >> AsmMain_Generator.java - source code of class generating AsmMain.class >> AsmMain.class - generated replica of JavacMain.class using >> /iconst_m1/?instruction for pusing ((char) 65535) and /sipush/?(with >> negative values) for pushing values of range [(char) 32768; (char) 65534] >> Asm? Main.javap - disassembled? AsmMain.class?(javac??-v -p -s -c) >> Asm.txt - file written by running?AsmMain.class -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Fri Aug 9 11:08:40 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 9 Aug 2019 14:08:40 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: <5b7142ca-c5eb-04ec-43d5-484f3cdf4d8d@oracle.com> References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <5b7142ca-c5eb-04ec-43d5-484f3cdf4d8d@oracle.com> Message-ID: I don't actually understand what any of those code is doing, so I don't think I really have much _preference_. But if I understand correctly, it does seem like what you propose would not suffice should there be at least one default method in the hierarchy. In our specific case I don't believe there is, but it seems like possibly a more narrow optimization. If you have a patch for what you're suggesting, I can apply it and see if it does at least have the same effects as the above webrevs On Thu, Aug 8, 2019 at 12:04 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I've been catching up on this discussion - having written this code, I > know this is tricky and also hard to optimize. Some efforts were already > put in trying to minimize the lookups, but it seems now you are being > affected by the cost of calling types.closure, which I understand. > > Looking at the code again, I wonder if, before doing something, I'd like > to step back and look at what the code is doing - specifically, I'm looking > at this: > > for (Type itype : itypes[iphase2.ordinal()]) { > if (!itype.isInterface()) continue; //skip j.l.Object > (included by Types.closure()) > if (iphase2 == InterfaceLookupPhase.DEFAULT_OK && > (itype.tsym.flags() & DEFAULT) == 0) continue; > > So there are two cases where the type in the itypes array is actually not > even looked at: > > * the type is Object - ok, this is a corner case - because closure() will > return also Object, fine > > * if we're looking for defaults, and the type we have on our hands does > not have the DEFAULT flag set, quit the search > > Now it would be tempting to say that if a type doesn't have the DEFAULT > flag set, then we can avoid adding its closure to the set - but that's > wishful thinking; the flag is (currently) only set for interfaces that > declare some default methods themselves. So, even if an interface doesn't > declare any default method, we still have to search its superinterfaces, as > some of those might. > > And this is where the big lookup cost associated with default methods is > coming from - we have to scan all superinterfaces in case _one_ might have > some default in it that is more specific than the method we have already > found. > > I think one possible way to optimize this algorithm would be to actually > do the opposite - e.g. to mark (as we scan them) interfaces whose > hierarchies are NOT known to have any default methods in them. If we had > such a detection mechanism, we could then prune entire families of > interfaces (and their parents) from the findMethod lookup - which would > bring back lookup performances with what we had before 8 (I'm assuming that > was fast enough for the use cases brought up here?). > > If you think that such an optimization is likely to give good results, > then I'd rather invest on that: since here we'd simply require a flag to > cache the interface hierarchy status w.r.t. default methods, I'm less > worried that the caching mechanism will backfire and turn into cases of > horrible memory footprint regression (we have seen that happening in the > past with cases like these). > > Thoughts? > > Cheers > Maurizio > > On 07/08/2019 11:25, Ron Shapiro wrote: > > Made the change for a WeakHashMap: > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. > > Perhaps it would make better sense for this to be a field on ClassType? > That would avoid the need for managing a cache with weak keys. > > Do you have any guidance on how you approach tradeoffs in memory vs. speed? > > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero > wrote: > >> not sure if we should add yet another cache to javac but in any case it >> should be implemented with a: WeakHashMap, >> >> Thanks, >> Vicente >> >> On 8/5/19 10:32 AM, Ron Shapiro wrote: >> >> Fair question. >> >> github.com/google/dagger generates implementations of interfaces that >> implement a dependency injection graph. Sometimes, though not always, these >> interfaces have dozens if not hundreds of (super)interfaces which allow for >> builds to be sharded: each subsection of the build refers to the >> superinterface and then at the root of the build there is a union of them >> all. Naturally, this means this must be rebuilt on most/all changes to any >> subproject of the build. >> >> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero ?< >> vicente.romero at oracle.com>: >> >>> Hi Ron, >>> >>> Just out of curiosity, what is the context in which this issue arises? >>> Naturally consuming more memory we can speed up javac but this can lead to >>> other problems too. >>> >>> Thanks, >>> Vicente >>> >>> On 8/5/19 8:24 AM, Ron Shapiro wrote: >>> >>> Friendly ping >>> >>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro ?>> >: >>> >>>> Hi, >>>> >>>> Please review this change to speed up Resolve.findMethod for large >>>> classes that have large numbers of (super)interfaces >>>> >>>> webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>>> >>>> Thanks, >>>> Ron >>>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrjarviscraft at gmail.com Fri Aug 9 11:13:06 2019 From: mrjarviscraft at gmail.com (JARvis PROgrammer) Date: Fri, 9 Aug 2019 14:13:06 +0300 Subject: Possible bug: compiler generating `ldc` instead of `sipush` and `iconst_m1` for characters in range [32768; 65535] In-Reply-To: <2172cb11-6709-6159-71d9-164ec7a1f21a@oracle.com> References: <2172cb11-6709-6159-71d9-164ec7a1f21a@oracle.com> Message-ID: Yes, have had it tested now with int casting and it does really produce wrong results. Thanks again for participation ??, 9 ???. 2019 ?., 13:20 Maurizio Cimadamore < maurizio.cimadamore at oracle.com>: > Actually, thinking more about this... > > I'm not convinced it is a bug. > > Consider the following simple example: > > class Foo { > public static int m(char c) { > return c; > } > > public static void main(String[] args) { > System.out.println(m((char)-1)); > } > } > > This currently prints "65535". The bytecode for the invocation in 'main' > is as follows: > > 3: ldc #3 // int 65535 > 5: invokestatic #4 // Method m:(C)I > > Now, if we were to replace the "ldc 65535" with a iconst_m1, the net > effect would be to load a 32-bit wide -1 constant. So this example would > end up printing -1, that is, no overflow/truncation behavior would be > exposed. So, I think that the reason why 'less optimal' opcodes are used is > precisely that: to respect the semantics of truncation vs. sign extension. > > sipush has a similar issue - as the JVMS says: > > "The immediate unsigned *byte1* and *byte2* values are assembled into an > intermediate short, where the value of the short is (*byte1* << 8) | > *byte2*. *The intermediate value is then sign-extended to an **int* > *value*. That *value* is pushed onto the operand stack." > > So again, you have a sign extension, which will not respect the truncation > semantics of the language. The instruction bipush is similar. > > So, bipush, sipush can only be safely use to handle chars if they handle > positive values - if they are used with negative values, the sign extension > embedded in the opcode would lead to the same results as using iconst_m1. > > The only way then to use these bytecodes in the "right" way would be to > immediately follow the load instruction with a i2c instruction. So it's a > trade off between number of instructions and constant pool pressure. > > In conlusion, I don't think anything needs to be changed here. > > Maurizio > On 09/08/2019 00:52, Maurizio Cimadamore wrote: > > Yes, there seems to be some suboptimality here - which I have also been > able to reproduce with other compilers (namely ecj). > > I guess the code didn't check for all the possible optimization > opportunities - yes, values from 128 to 255 can still be encoded in a > (negative) byte and values from 32768 to 65535 can be encoded in a > (negative) short, so no ldc should be needed, at least in principle. > > In terms of perfomances though - this is hardly going to make any > difference, as the JIT will easily see through the redundancy. An argument > can be made though that we are wasting valuable constant pool estate when > we can avoid it, so, IMHO that would be the main reason to fix something > like this. > > Cheers > Maurizio > On 08/08/2019 18:16, JARvis PROgrammer wrote: > > Hi there, it seems that the javac compiler generates non-optimal bytecode > for pushing values of (compile-time) type `char`. > In order to test it I've first written a class which has a method > accepting `char`s which writes them to a file (so that results can be > easily compared): > > private static void consumeChar(final char character) throws IOException { > try (final BufferedWriter writer = new BufferedWriter(new FileWriter(new File("Javac.txt"), true))) { > writer.write(Character.toString(character)); } > } > > And then added code to `main` which simply invokes this method for all > corner cases and nearby char values {(char) 0, (char) 1, (char) 2, (char) > 3, (char) 4, (char) 5, (char) 6, (char) 7, (char) 126, (char) 127, (char) > 128, (char) 129, (char) 32766, (char) 32767, (char) 32768, (char) 32769, > (char) 65534, (char) 65535}. After this the class was compiled using > `javac` (both tested on release 11 and early-access 13). > The resulting bytecode uses *iconst#* for range [(char) 0; (char) 5], > *bipush* for range from [(char) 6; (char) 127], *sipush* for range > [(char) 128; (char) 32767] and (strangely) *ldc* for range [(char) 32768; > (char) 65535]. > In order to check if the strange behavour is not the only way to achieve > pushing "big" `char` values onto the stack, I've recreated the similar > class using ObjectWeb ASM using *iconst_m1* instruction for pusing > ((char) 65535) and *sipush* (with negative values) for pushing values of > range [(char) 32768; (char) 65534]. > The following function describes this behaviour: > > private static void pushChar(final MethodVisitor method, final int charCode) { > switch (charCode) { > case 65535: { > method.visitInsn(ICONST_M1); break; } > case 1: { > method.visitInsn(ICONST_1); break; } > case 2: { > method.visitInsn(ICONST_2); break; } > case 3: { > method.visitInsn(ICONST_3); break; } > case 4: { > method.visitInsn(ICONST_4); break; } > case 5: { > method.visitInsn(ICONST_5); break; } default: { > if (charCode <= Byte.MAX_VALUE) method.visitIntInsn(BIPUSH, charCode > else method.visitIntInsn(SIPUSH, (short) charCode); } > } > } > > (PS, in theory, *bipush* might also be aplicable for some values where > *sipush* is used, but I didn't test it) > The generated class once run via java (release 11 and early-access 13 were > used) generated the file with content equal to the one of the > javac-compiled class. > > And so, it seems to be a bug that `javac` uses *ldc* instruction instead > of more primitive ones while those may handle all range of characters. > > All files used for test purposes (including javap call results) are > attached to this message: > JavacMain.java - source code of class compiled via javac > JavacMain.class - compiled JavacMain.java (javac -g:none --enable-preview) > JavacMain.javap - disassembled JavacMain.class (javac -v -p -s -c) > Javac.txt - file written by running JavacMain.class > > AsmMain_Generator.java - source code of class generating AsmMain.class > AsmMain.class - generated replica of JavacMain.class using *iconst_m1* instruction > for pusing ((char) 65535) and *sipush* (with negative values) for pushing > values of range [(char) 32768; (char) 65534] > Asm Main.javap - disassembled AsmMain.class (javac -v -p -s -c) > Asm.txt - file written by running AsmMain.class > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Aug 9 11:38:21 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Aug 2019 12:38:21 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <5b7142ca-c5eb-04ec-43d5-484f3cdf4d8d@oracle.com> Message-ID: On 09/08/2019 12:08, Ron Shapiro wrote: > I don't actually understand what any of those code is doing, so I > don't think I really have much _preference_. But if I understand > correctly, it does seem like what you propose would not suffice should > there be at least one default method in the hierarchy. > > In our specific?case I don't believe there is, but it seems like > possibly a more narrow optimization. Sure, it is more narrow - but I think this optimization is really only needed when there are lots of auto-generated files, in which case it's very likely (I'm assuming) that plain interfaces (w/o default methods) will be used; it is also a less risky optimization, with less chances for introducing accidental memory footprint regression in a core area of the compiler, so I'd be more confident in starting there, and see where it leads us. Maurizio > > If you?have a patch for what you're suggesting, I can apply it and see > if it does at least have the same effects as the above webrevs > > On Thu, Aug 8, 2019 at 12:04 AM Maurizio Cimadamore > > wrote: > > I've been catching up on this discussion - having written this > code, I know this is tricky and also hard to optimize. Some > efforts were already put in trying to minimize the lookups, but it > seems now you are being affected by the cost of calling > types.closure, which I understand. > > Looking at the code again, I wonder if, before doing something, > I'd like to step back and look at what the code is doing - > specifically, I'm looking at this: > > for (Type itype : itypes[iphase2.ordinal()]) { > ??????????????? if (!itype.isInterface()) continue; //skip > j.l.Object (included by Types.closure()) > ??????????????? if (iphase2 == InterfaceLookupPhase.DEFAULT_OK && > ??????????????????????? (itype.tsym.flags() & DEFAULT) == 0) continue; > > > So there are two cases where the type in the itypes array is > actually not even looked at: > > * the type is Object - ok, this is a corner case - because > closure() will return also Object, fine > > * if we're looking for defaults, and the type we have on our hands > does not have the DEFAULT flag set, quit the search > > Now it would be tempting to say that if a type doesn't have the > DEFAULT flag set, then we can avoid adding its closure to the set > - but that's wishful thinking; the flag is (currently) only set > for interfaces that declare some default methods themselves. So, > even if an interface doesn't declare any default method, we still > have to search its superinterfaces, as some of those might. > > And this is where the big lookup cost associated with default > methods is coming from - we have to scan all superinterfaces in > case _one_ might have some default in it that is more specific > than the method we have already found. > > I think one possible way to optimize this algorithm would be to > actually do the opposite - e.g. to mark (as we scan them) > interfaces whose hierarchies are NOT known to have any default > methods in them. If we had such a detection mechanism, we could > then prune entire families of interfaces (and their parents) from > the findMethod lookup - which would bring back lookup performances > with what we had before 8 (I'm assuming that was fast enough for > the use cases brought up here?). > > If you think that such an optimization is likely to give good > results, then I'd rather invest on that: since here we'd simply > require a flag to cache the interface hierarchy status w.r.t. > default methods, I'm less worried that the caching mechanism will > backfire and turn into cases of horrible memory footprint > regression (we have seen that happening in the past with cases > like these). > > Thoughts? > > Cheers > Maurizio > > On 07/08/2019 11:25, Ron Shapiro wrote: >> Made the change for a WeakHashMap: >> http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >> >> Perhaps it would make better sense for this to be a field on >> ClassType? That would avoid the need for managing a cache with >> weak keys. >> >> Do you have any guidance on how you approach tradeoffs in memory >> vs. speed? >> >> On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero >> > wrote: >> >> not sure if we should add yet another cache to javac but in >> any case it should be implemented with a: WeakHashMap, >> >> Thanks, >> Vicente >> >> On 8/5/19 10:32 AM, Ron Shapiro wrote: >>> Fair question. >>> >>> github.com/google/dagger >>> generates implementations of interfaces that implement a >>> dependency injection graph. Sometimes, though not always, >>> these interfaces have dozens if not hundreds of >>> (super)interfaces which allow for builds to be sharded: each >>> subsection of the build refers to the superinterface and >>> then at the root of the build there is a union of them all. >>> Naturally, this means this must be rebuilt on most/all >>> changes to any subproject of the build. >>> >>> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >>> ?>: >>> >>> Hi Ron, >>> >>> Just out of curiosity, what is the context in which this >>> issue arises? Naturally consuming more memory we can >>> speed up javac but this can lead to other problems too. >>> >>> Thanks, >>> Vicente >>> >>> On 8/5/19 8:24 AM, Ron Shapiro wrote: >>>> Friendly ping >>>> >>>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >>>> ?>: >>>> >>>> Hi, >>>> >>>> Please review this change to speed up >>>> Resolve.findMethod for large classes that have >>>> large numbers of (super)interfaces >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>>> >>>> Thanks, >>>> Ron >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Fri Aug 9 12:38:04 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 9 Aug 2019 15:38:04 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <5b7142ca-c5eb-04ec-43d5-484f3cdf4d8d@oracle.com> Message-ID: Happy to give that a try. On Fri, Aug 9, 2019 at 2:38 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 09/08/2019 12:08, Ron Shapiro wrote: > > I don't actually understand what any of those code is doing, so I don't > think I really have much _preference_. But if I understand correctly, it > does seem like what you propose would not suffice should there be at least > one default method in the hierarchy. > > In our specific case I don't believe there is, but it seems like possibly > a more narrow optimization. > > Sure, it is more narrow - but I think this optimization is really only > needed when there are lots of auto-generated files, in which case it's very > likely (I'm assuming) that plain interfaces (w/o default methods) will be > used; it is also a less risky optimization, with less chances for > introducing accidental memory footprint regression in a core area of the > compiler, so I'd be more confident in starting there, and see where it > leads us. > > Maurizio > > > > If you have a patch for what you're suggesting, I can apply it and see if > it does at least have the same effects as the above webrevs > > On Thu, Aug 8, 2019 at 12:04 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> I've been catching up on this discussion - having written this code, I >> know this is tricky and also hard to optimize. Some efforts were already >> put in trying to minimize the lookups, but it seems now you are being >> affected by the cost of calling types.closure, which I understand. >> >> Looking at the code again, I wonder if, before doing something, I'd like >> to step back and look at what the code is doing - specifically, I'm looking >> at this: >> >> for (Type itype : itypes[iphase2.ordinal()]) { >> if (!itype.isInterface()) continue; //skip j.l.Object >> (included by Types.closure()) >> if (iphase2 == InterfaceLookupPhase.DEFAULT_OK && >> (itype.tsym.flags() & DEFAULT) == 0) continue; >> >> So there are two cases where the type in the itypes array is actually not >> even looked at: >> >> * the type is Object - ok, this is a corner case - because closure() will >> return also Object, fine >> >> * if we're looking for defaults, and the type we have on our hands does >> not have the DEFAULT flag set, quit the search >> >> Now it would be tempting to say that if a type doesn't have the DEFAULT >> flag set, then we can avoid adding its closure to the set - but that's >> wishful thinking; the flag is (currently) only set for interfaces that >> declare some default methods themselves. So, even if an interface doesn't >> declare any default method, we still have to search its superinterfaces, as >> some of those might. >> >> And this is where the big lookup cost associated with default methods is >> coming from - we have to scan all superinterfaces in case _one_ might have >> some default in it that is more specific than the method we have already >> found. >> >> I think one possible way to optimize this algorithm would be to actually >> do the opposite - e.g. to mark (as we scan them) interfaces whose >> hierarchies are NOT known to have any default methods in them. If we had >> such a detection mechanism, we could then prune entire families of >> interfaces (and their parents) from the findMethod lookup - which would >> bring back lookup performances with what we had before 8 (I'm assuming that >> was fast enough for the use cases brought up here?). >> >> If you think that such an optimization is likely to give good results, >> then I'd rather invest on that: since here we'd simply require a flag to >> cache the interface hierarchy status w.r.t. default methods, I'm less >> worried that the caching mechanism will backfire and turn into cases of >> horrible memory footprint regression (we have seen that happening in the >> past with cases like these). >> >> Thoughts? >> >> Cheers >> Maurizio >> >> On 07/08/2019 11:25, Ron Shapiro wrote: >> >> Made the change for a WeakHashMap: >> http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >> >> Perhaps it would make better sense for this to be a field on ClassType? >> That would avoid the need for managing a cache with weak keys. >> >> Do you have any guidance on how you approach tradeoffs in memory vs. >> speed? >> >> On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero >> wrote: >> >>> not sure if we should add yet another cache to javac but in any case it >>> should be implemented with a: WeakHashMap, >>> >>> Thanks, >>> Vicente >>> >>> On 8/5/19 10:32 AM, Ron Shapiro wrote: >>> >>> Fair question. >>> >>> github.com/google/dagger generates implementations of interfaces that >>> implement a dependency injection graph. Sometimes, though not always, these >>> interfaces have dozens if not hundreds of (super)interfaces which allow for >>> builds to be sharded: each subsection of the build refers to the >>> superinterface and then at the root of the build there is a union of them >>> all. Naturally, this means this must be rebuilt on most/all changes to any >>> subproject of the build. >>> >>> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero ?< >>> vicente.romero at oracle.com>: >>> >>>> Hi Ron, >>>> >>>> Just out of curiosity, what is the context in which this issue arises? >>>> Naturally consuming more memory we can speed up javac but this can lead to >>>> other problems too. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> On 8/5/19 8:24 AM, Ron Shapiro wrote: >>>> >>>> Friendly ping >>>> >>>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro ?< >>>> ronshapiro at google.com>: >>>> >>>>> Hi, >>>>> >>>>> Please review this change to speed up Resolve.findMethod for large >>>>> classes that have large numbers of (super)interfaces >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>>>> >>>>> Thanks, >>>>> Ron >>>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Aug 9 14:33:56 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Aug 2019 07:33:56 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <91b1b04a-4934-d847-39ac-cf759845738f@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <4b7d5502-24cb-4e55-ccf8-e9e2b6976834@oracle.com> <91b1b04a-4934-d847-39ac-cf759845738f@oracle.com> Message-ID: <8176f574-ba50-9c2e-202d-9f7365794dde@oracle.com> On 8/8/19 5:54 PM, Alex Buckley wrote: > On 8/8/2019 5:08 PM, Maurizio Cimadamore wrote: >> Ideally, what you want is to add @Preview in a non-exported package, >> (pretty much as @ForceInline) so that it can be used wherever >> (including non SE APIs) in the JDK (provided the package is >> qualified-exported accordingly) - and that takes care of the fact >> that the annotation could not be placed on code outside of the JDK. > > This was Joe's initial intent -- jdk.internal.Preview to be precise -- > but it would be inappropriate for such an annotation type to be > @Documented and show up in the javadoc on String::stripIndent. There > is also the other problem you raise: It does not need to be @Documented. We could use a combination of the current deprecation mechanism combined with a JDK-internal annotation to modify the text of the warnings generated by javac and the text generated by javadoc. >> what the compiler should do when encountering a method marked with >> @Preview, if @Preview itself is not part of the Java SE API - meaning >> a spec (e.g. JLS) cant really refer to it. But, is there a need for >> the spec to refer to it? Could we get away with saying that "there >> must be a way to mark preview API methods" without saying _what_ way >> that is? > > The JLS is not and cannot be "open". In order for the JLS to mandate > an error (or even a warning) about use of a preview-feature-connected > API, the Java SE Platform has to be the ultimate authority for > identifying such APIs. The identification must be normative, though it > can be lightweight -- a simple mention of "Text Blocks (JEP 355)" in > the Platform JSR is enough to get String::stripIndent on the list. > Now, I would be mostly OK with dropping the SE-defined @PreviewFeature > annotation if compiler vendors were eager to incorporate knowledge of > such Platform-identified APIs, but it was made clear (internally) that > javac did not want to do this. So, we have a marker annotation (in > SE), and we have some consensus about wanting an error when identified > APIs (in SE) are used without enabling preview features, and those two > design choices work together. Let's not spend more time pondering how > non-SE APIs can play in the preview sandpit please. > > Alex In the discussion about having a list of preview APIs, the context was a list hard-coded into the compiler source code. If the list could be determined "dynamically" at JDK-build time, such as by an annotation processor, that might be different. -- Jon From alex.buckley at oracle.com Fri Aug 9 17:28:48 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 9 Aug 2019 10:28:48 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <8176f574-ba50-9c2e-202d-9f7365794dde@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <4b7d5502-24cb-4e55-ccf8-e9e2b6976834@oracle.com> <91b1b04a-4934-d847-39ac-cf759845738f@oracle.com> <8176f574-ba50-9c2e-202d-9f7365794dde@oracle.com> Message-ID: <77817f15-ed45-384a-51e9-687c431e7f32@oracle.com> On 8/9/2019 7:33 AM, Jonathan Gibbons wrote: > We could use a combination of the current deprecation mechanism combined > with a JDK-internal annotation to modify the text of the warnings > generated by javac and the text generated by javadoc. ...> In the discussion about having a list of preview APIs, the context was a > list hard-coded into the compiler source code. If the list could be > determined "dynamically" at JDK-build time, such as by an annotation > processor, that might be different. My goal is to move away from terminal deprecation as the mechanism for flagging preview-related APIs in Java SE. Therefore, I do not support the proposal above, which keeps the deprecation mechanism for SE APIs _and_ rigs up a pile of JDK-specific machinery to work as a secondary flagging mechanism for SE APIs and as a new flagging mechanism for non-SE APIs (in the JDK). It may be that use of reflective Java SE and JDK-supported APIs takes on a bigger role later in 14, as records head towards preview status. (Making no commitments of course!) But my focus at present is use of essential Java SE APIs, because 13 is unfortunately heading out the door with @Deprecated(forRemoval=true) on public methods in java.lang, and that shouldn't happen again. Alex From jonathan.gibbons at oracle.com Fri Aug 9 17:43:32 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Aug 2019 10:43:32 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <77817f15-ed45-384a-51e9-687c431e7f32@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <369dca06-7acb-c7fd-c63e-4437be7b7c43@oracle.com> <4b7d5502-24cb-4e55-ccf8-e9e2b6976834@oracle.com> <91b1b04a-4934-d847-39ac-cf759845738f@oracle.com> <8176f574-ba50-9c2e-202d-9f7365794dde@oracle.com> <77817f15-ed45-384a-51e9-687c431e7f32@oracle.com> Message-ID: On 8/9/19 10:28 AM, Alex Buckley wrote: > On 8/9/2019 7:33 AM, Jonathan Gibbons wrote: >> We could use a combination of the current deprecation mechanism >> combined with a JDK-internal annotation to modify the text of the >> warnings generated by javac and the text generated by javadoc. > ...> In the discussion about having a list of preview APIs, the > context was a >> list hard-coded into the compiler source code. If the list could be >> determined "dynamically" at JDK-build time, such as by an annotation >> processor, that might be different. > > My goal is to move away from terminal deprecation as the mechanism for > flagging preview-related APIs in Java SE. Therefore, I do not support > the proposal above, which keeps the deprecation mechanism for SE APIs > _and_ rigs up a pile of JDK-specific machinery to work as a secondary > flagging mechanism for SE APIs and as a new flagging mechanism for > non-SE APIs (in the JDK). > > It may be that use of reflective Java SE and JDK-supported APIs takes > on a bigger role later in 14, as records head towards preview status. > (Making no commitments of course!) But my focus at present is use of > essential Java SE APIs, because 13 is unfortunately heading out the > door with @Deprecated(forRemoval=true) on public methods in java.lang, > and that shouldn't happen again. > > Alex Yes, there are clearly two related but somewhat separate discussions going on here. One is the discussion for the evolution of JEP 12: Preview Language and VM Features, which I acknowledge has "SE" scope, and which currently does not address the issue of incremental evolution of existing APIs, and the current recommendation to use incubating APIs is not realistic in practice. The other discussion is if and how to mitigate the impact of JEP 12 on JDK APIs and tools, given that JEP 12 is causing an instability in some supported JDK APIs. That is a reasonable discussion for those of us interested in improving the implementation of our JDK tools to better support JEP 12. -- Jon From jonathan.gibbons at oracle.com Fri Aug 9 22:11:53 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Aug 2019 15:11:53 -0700 Subject: RFR: JDK-8229386 Typo "lables" in doc comment Message-ID: <1dd45777-ad43-6d93-31c0-3f5303515664@oracle.com> Please review a trivial fix for a typo in a doc comment.? What should be "labels" is incorrectly spelt as "lables". -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8229386 Patch: $ hg diff -R open diff -r 072f27397b69 src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java --- a/src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java Fri Aug 09 12:27:05 2019 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java Fri Aug 09 15:00:41 2019 -0700 @@ -49,7 +49,7 @@ ?????/** ??????* Returns the expression for the case, or ??????* {@code null} if this is the default case. - * If this case has multiple lables, returns the first label. + * If this case has multiple labels, returns the first label. ??????* @return the expression for the case, or null ??????*/ ?????ExpressionTree getExpression(); From mandy.chung at oracle.com Fri Aug 9 22:22:46 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Aug 2019 15:22:46 -0700 Subject: RFR: JDK-8229386 Typo "lables" in doc comment In-Reply-To: <1dd45777-ad43-6d93-31c0-3f5303515664@oracle.com> References: <1dd45777-ad43-6d93-31c0-3f5303515664@oracle.com> Message-ID: <0b1ebfcc-5348-d74e-a04a-2f73b2c0358a@oracle.com> +1 Mandy On 8/9/19 3:11 PM, Jonathan Gibbons wrote: > Please review a trivial fix for a typo in a doc comment.? What should > be "labels" is incorrectly spelt as "lables". > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8229386 > > Patch: > > $ hg diff -R open > diff -r 072f27397b69 > src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java > --- a/src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java > Fri Aug 09 12:27:05 2019 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java > Fri Aug 09 15:00:41 2019 -0700 > @@ -49,7 +49,7 @@ > ?????/** > ??????* Returns the expression for the case, or > ??????* {@code null} if this is the default case. > - * If this case has multiple lables, returns the first label. > + * If this case has multiple labels, returns the first label. > ??????* @return the expression for the case, or null > ??????*/ > ?????ExpressionTree getExpression(); > From jan.lahoda at oracle.com Mon Aug 12 14:50:01 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 12 Aug 2019 16:50:01 +0200 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> Message-ID: <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> I wonder if this will work with annotation processors? (As these may create new interfaces into the hierarchy.) Jan On 07. 08. 19 12:25, Ron Shapiro wrote: > Made the change for a WeakHashMap: > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. > > Perhaps it would make better sense for this to be a field on ClassType? > That would avoid the need for managing a cache with weak keys. > > Do you have any guidance on how you approach tradeoffs in memory vs. speed? > > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero > wrote: > > not sure if we should add yet another cache to javac but in any case > it should be implemented with a: WeakHashMap, > > Thanks, > Vicente > > On 8/5/19 10:32 AM, Ron Shapiro wrote: >> Fair question. >> >> github.com/google/dagger >> generates implementations of interfaces that implement a >> dependency injection graph. Sometimes, though not always, these >> interfaces have dozens if not hundreds of (super)interfaces which >> allow for builds to be sharded: each subsection of the build >> refers to the superinterface and then at the root of the build >> there is a union of them all. Naturally, this means this must be >> rebuilt on most/all changes to any subproject of the build. >> >> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >> ?>: >> >> Hi Ron, >> >> Just out of curiosity, what is the context in which this issue >> arises? Naturally consuming more memory we can speed up javac >> but this can lead to other problems too. >> >> Thanks, >> Vicente >> >> On 8/5/19 8:24 AM, Ron Shapiro wrote: >>> Friendly ping >>> >>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >>> ?>: >>> >>> Hi, >>> >>> Please review this change to speed up Resolve.findMethod >>> for large classes that have large numbers of >>> (super)interfaces >>> >>> webrev: http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>> >>> Thanks, >>> Ron >>> >> > From andrew_m_leonard at uk.ibm.com Mon Aug 12 16:31:15 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 12 Aug 2019 17:31:15 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: (try again!) cc original maillist, see below.. Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: jdk8u-dev at openjdk.java.net Date: 12/08/2019 17:15 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Hi, Please can I request a review of this updated patch for 8067429 to backport to jdk8u/langtools. We have seen problem reports from clients seeing this issue with jdk8 and would like to request a backport please. The patch is essentially the same as published to jdk9+, but jdk8 the file paths are in a different location. I have built and tested all "tier1" and "langtools_all" successfully, and the patch new testcase passes. http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 Once reviewed I will add the jdk8u-fix-request. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Aug 12 20:27:27 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 12 Aug 2019 16:27:27 -0400 Subject: RFR: JDK-8226561: javac throws NullPointerException in Check.checkClassOverrideEqualsAndHash In-Reply-To: <534f0484-0c9e-73e9-7770-397473cf4b3a@oracle.com> References: <534f0484-0c9e-73e9-7770-397473cf4b3a@oracle.com> Message-ID: <0d5fb5a7-594c-99dc-2889-d01dc7dc35e7@oracle.com> ping, Thanks, Vicente On 7/25/19 12:23 PM, Vicente Romero wrote: > Please review the fix for [1] at [2]. This patch fixes a NPE produced > at a lint warning checking that a class overriding ::equals should > override ::hashCode too. The thing is that if the class is an > inexistent symbol then the method symbol returned by > Types::implementation is null. The fix is checking for this null case, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8226561 > [2] http://cr.openjdk.java.net/~vromero/8226561/webrev.00/ From jonathan.gibbons at oracle.com Mon Aug 12 20:36:47 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Aug 2019 13:36:47 -0700 Subject: RFR: JDK-8226561: javac throws NullPointerException in Check.checkClassOverrideEqualsAndHash In-Reply-To: <0d5fb5a7-594c-99dc-2889-d01dc7dc35e7@oracle.com> References: <534f0484-0c9e-73e9-7770-397473cf4b3a@oracle.com> <0d5fb5a7-594c-99dc-2889-d01dc7dc35e7@oracle.com> Message-ID: Shouldn't the test cover the 2x2 cases of (equals defined or not, hashCode defined or not) ? -- Jon On 08/12/2019 01:27 PM, Vicente Romero wrote: > ping, > > Thanks, > Vicente > > On 7/25/19 12:23 PM, Vicente Romero wrote: >> Please review the fix for [1] at [2]. This patch fixes a NPE produced >> at a lint warning checking that a class overriding ::equals should >> override ::hashCode too. The thing is that if the class is an >> inexistent symbol then the method symbol returned by >> Types::implementation is null. The fix is checking for this null case, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8226561 >> [2] http://cr.openjdk.java.net/~vromero/8226561/webrev.00/ > From ronshapiro at google.com Tue Aug 13 05:12:52 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 13 Aug 2019 08:12:52 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> Message-ID: Aren't types recreated across rounds if there are any transitive error types? That was at least my assumption. On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda wrote: > I wonder if this will work with annotation processors? (As these may > create new interfaces into the hierarchy.) > > Jan > > On 07. 08. 19 12:25, Ron Shapiro wrote: > > Made the change for a WeakHashMap: > > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. > > > > Perhaps it would make better sense for this to be a field on ClassType? > > That would avoid the need for managing a cache with weak keys. > > > > Do you have any guidance on how you approach tradeoffs in memory vs. > speed? > > > > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero > > wrote: > > > > not sure if we should add yet another cache to javac but in any case > > it should be implemented with a: WeakHashMap, > > > > Thanks, > > Vicente > > > > On 8/5/19 10:32 AM, Ron Shapiro wrote: > >> Fair question. > >> > >> github.com/google/dagger > >> generates implementations of interfaces that implement a > >> dependency injection graph. Sometimes, though not always, these > >> interfaces have dozens if not hundreds of (super)interfaces which > >> allow for builds to be sharded: each subsection of the build > >> refers to the superinterface and then at the root of the build > >> there is a union of them all. Naturally, this means this must be > >> rebuilt on most/all changes to any subproject of the build. > >> > >> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero > >> ?>: > >> > >> Hi Ron, > >> > >> Just out of curiosity, what is the context in which this issue > >> arises? Naturally consuming more memory we can speed up javac > >> but this can lead to other problems too. > >> > >> Thanks, > >> Vicente > >> > >> On 8/5/19 8:24 AM, Ron Shapiro wrote: > >>> Friendly ping > >>> > >>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro > >>> ?>: > >>> > >>> Hi, > >>> > >>> Please review this change to speed up Resolve.findMethod > >>> for large classes that have large numbers of > >>> (super)interfaces > >>> > >>> webrev: > http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 > >>> > >>> Thanks, > >>> Ron > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Thu Aug 15 08:38:23 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 15 Aug 2019 09:38:23 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: Any offers to review this please? Thanks Andrew From: Andrew Leonard/UK/IBM To: jdk8u-dev at openjdk.java.net Date: 12/08/2019 17:15 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Hi, Please can I request a review of this updated patch for 8067429 to backport to jdk8u/langtools. We have seen problem reports from clients seeing this issue with jdk8 and would like to request a backport please. The patch is essentially the same as published to jdk9+, but jdk8 the file paths are in a different location. I have built and tested all "tier1" and "langtools_all" successfully, and the patch new testcase passes. http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 Once reviewed I will add the jdk8u-fix-request. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Aug 19 18:59:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 19 Aug 2019 14:59:57 -0400 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: References: Message-ID: <16723387-7f3e-bc37-c533-9c63700d897a@oracle.com> the backport looks good to me, Vicente On 8/15/19 4:38 AM, Andrew Leonard wrote: > Any offers to review this please? > Thanks > Andrew > > > > > From: Andrew Leonard/UK/IBM > To: jdk8u-dev at openjdk.java.net > Date: 12/08/2019 17:15 > Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: > Inconsistent stackmap frames at branch target > > > Hi, > Please can I request a review of this updated patch for 8067429 to > backport to jdk8u/langtools. We have seen problem reports from clients > seeing this issue with jdk8 and would like to request a backport please. > The patch is essentially the same as published to jdk9+, but jdk8 the file > paths are in a different location. I have built and tested all "tier1" and > "langtools_all" successfully, and the patch new testcase passes. > http://cr.openjdk.java.net/~aleonard/8067429/webrev.00 > Once reviewed I will add the jdk8u-fix-request. > > Many thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From andrew_m_leonard at uk.ibm.com Tue Aug 20 08:45:34 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 20 Aug 2019 09:45:34 +0100 Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target In-Reply-To: <16723387-7f3e-bc37-c533-9c63700d897a@oracle.com> References: <16723387-7f3e-bc37-c533-9c63700d897a@oracle.com> Message-ID: Thank you Vincente, i'll request approval.. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Vicente Romero To: Andrew Leonard , jdk8u-dev at openjdk.java.net Cc: compiler-dev at openjdk.java.net Date: 19/08/2019 20:00 Subject: Re: [8u] RFR Backport of 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target the backport looks good to me, Vicente On 8/15/19 4:38 AM, Andrew Leonard wrote: > Any offers to review this please? > Thanks > Andrew > > > > > From: Andrew Leonard/UK/IBM > To: jdk8u-dev at openjdk.java.net > Date: 12/08/2019 17:15 > Subject: [8u] RFR Backport of 8067429: java.lang.VerifyError: > Inconsistent stackmap frames at branch target > > > Hi, > Please can I request a review of this updated patch for 8067429 to > backport to jdk8u/langtools. We have seen problem reports from clients > seeing this issue with jdk8 and would like to request a backport please. > The patch is essentially the same as published to jdk9+, but jdk8 the file > paths are in a different location. I have built and tested all "tier1" and > "langtools_all" successfully, and the patch new testcase passes. > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ealeonard_8067429_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=1jq899yhiTZEKwvfBlQDLl4IJLHPNwrWr9Ee9y-TSek&s=OxsfFEnFwWH4k-vJMXXgjYaUISo-OM0CpI8bn_PRNoY&e= > Once reviewed I will add the jdk8u-fix-request. > > Many thanks > Andrew > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Aug 26 10:50:54 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 26 Aug 2019 12:50:54 +0200 Subject: RFR: JDK-8230105: -XDfind=diamond crashes Message-ID: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> Hi, JBS: https://bugs.openjdk.java.net/browse/JDK-8230105 Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8230105/webrev.00/ Consider this code: --- public class AnalyzerNotQuiteSpeculative { private void test() { Subclass1 c1 = null; Subclass2 c2 = null; Base b = null; t(new C(c1).set(c2)); t(new C(b).set(c2)); } public static class Base {} public static class Subclass1 extends Base {} public static class Subclass2 extends Base {} public class C { public C(T t) {} public C set(T t) { return this; } } void t(C l) {} } --- When run with -XDfind=diamond, this crashes with: --- at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) at jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:581) ... --- The embedded (thrown away) exception is: --- java.lang.NullPointerException at jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:261) at jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:225) at jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579) at jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:552) at jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:594) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1412) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:972) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) 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 reason for this exception seems to be that when the Analyzer is speculatively analyzing "t(new C(c1).set(c2));", ArgumentAttr.setResult will set a deferred type to "new C(c1).set(c2)" (because isSpeculative is true), which in turn will prevent the tree from being actually attributed. So when the analyzer asks for type of "new C(c1)", it gets null. It ultimate problem appears to be that analyzers want to analyze a piece of AST "as if" it was part of the source code, but without having permanent side effects. But, currently, there is only the AttrContext.isSpeculative boolean, which means both "no permanent sideeffects" and "the tree is a scratch tree, that can be modified in any way", and the latter is not quite the case when doing spec attribution for analyzers. The proposed solution is to make the isSpeculative flag 3 tristate (by using enum and renaming the field), which should allow us to differentiate between "actual AST", "AST in analyzer" and "actual speculative AST". I also created a patch that runs analyzers on all source code which building and testing JDK, and fixed a few smallish trouble it found. The patch to run the analyzers is not part of the proposed patch, but can be seen here: http://cr.openjdk.java.net/~jlahoda/8230105/webrev.runall/ How does this look? Thanks, Jan From ronshapiro at google.com Mon Aug 26 16:12:25 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 26 Aug 2019 19:12:25 +0300 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance Message-ID: Hi Please review the following patch to address O(N) performance in ScopeImpl.remove(). bug: https://bugs.openjdk.java.net/browse/JDK-8230162 webrev: http://cr.openjdk.java.net/~ronsh/8230162/webrev.00/ Note that the patch was prepared by my coworker, Brad (cc'd). I wasn't sure what to do to make sure that he was attributed correctly. Thanks, Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Aug 26 16:38:21 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 26 Aug 2019 09:38:21 -0700 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: Message-ID: <0192e683-04a4-90a3-48f0-06f2c17d8a32@oracle.com> Do you have any estimates of the increase in size in typical usage, due to the extra field in Scope? Since DPrinter is explicitly a "debug printer", you want consider tweaking it to show both the prev and next sibilings. -- Jon On 8/26/19 9:12 AM, Ron Shapiro wrote: > Hi > > Please review the following patch to address O(N) performance in > ScopeImpl.remove(). > > bug: https://bugs.openjdk.java.net/browse/JDK-8230162 > webrev: http://cr.openjdk.java.net/~ronsh/8230162/webrev.00/ > > Note that the patch was prepared by my coworker, Brad (cc'd). I wasn't > sure what to do to make sure that he was attributed correctly. > > Thanks, > Ron From jonathan.gibbons at oracle.com Mon Aug 26 16:40:21 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 26 Aug 2019 09:40:21 -0700 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: Message-ID: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> On 8/26/19 9:12 AM, Ron Shapiro wrote: > > Note that the patch was prepared by my coworker, Brad (cc'd). I wasn't > sure what to do to make sure that he was attributed correctly. Mention this when you have a sponsor to push the changeset, so that it can be marked with "Contributed-By:" -- Jon From ronshapiro at google.com Mon Aug 26 20:52:54 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 26 Aug 2019 23:52:54 +0300 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> Message-ID: Adding Brad back in to the thread since he would know best ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan Gibbons ?< jonathan.gibbons at oracle.com>: > > On 8/26/19 9:12 AM, Ron Shapiro wrote: > > > > Note that the patch was prepared by my coworker, Brad (cc'd). I wasn't > > sure what to do to make sure that he was attributed correctly. > > > Mention this when you have a sponsor to push the changeset, so that it > can be marked with "Contributed-By:" > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcorso at google.com Mon Aug 26 22:06:28 2019 From: bcorso at google.com (Brad Corso) Date: Mon, 26 Aug 2019 15:06:28 -0700 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> Message-ID: Sorry, what's the question? On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro wrote: > Adding Brad back in to the thread since he would know best > > ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan Gibbons ?< > jonathan.gibbons at oracle.com>: > >> >> On 8/26/19 9:12 AM, Ron Shapiro wrote: >> > >> > Note that the patch was prepared by my coworker, Brad (cc'd). I wasn't >> > sure what to do to make sure that he was attributed correctly. >> >> >> Mention this when you have a sponsor to push the changeset, so that it >> can be marked with "Contributed-By:" >> >> -- Jon >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue Aug 27 07:05:43 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 27 Aug 2019 09:05:43 +0200 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> Message-ID: On 27. 08. 19 0:06, Brad Corso wrote: > Sorry, what's the question? I believe "Do you have any estimates of the increase in size in typical usage, due to the extra field in Scope?" (Jon) I'd add, is there a chance to get an improvement in Scope.remove speed without making ScopeImpl.Entry bigger (assuming it gets bigger(?))? One possibility that occurred to me is that we could try not to remove the things from elems, but only mark them as removed. We would need to do filtering (and possibly the actual removal) while reading from the Scope (in getSymbols), so this is a different kind of trade-off. (Overall, I guess the question is whether we are trading problems with Scope.remove speed in some cases for out-of-memory problems in other cases.) Jan > > On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro > wrote: > > Adding Brad back in to the thread since he would know best > > ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan Gibbons > ?>: > > > On 8/26/19 9:12 AM, Ron Shapiro wrote: > > > > Note that the patch was prepared by my coworker, Brad (cc'd). > I wasn't > > sure what to do to make sure that he was attributed correctly. > > > Mention this when you have a sponsor to push the changeset, so > that it > can be marked with "Contributed-By:" > > -- Jon > From bcorso at google.com Tue Aug 27 23:40:26 2019 From: bcorso at google.com (Brad Corso) Date: Tue, 27 Aug 2019 16:40:26 -0700 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> Message-ID: > > I believe "Do you have any estimates of the increase in size in typical > usage, due to the extra field in Scope?" (Jon) I was seeing noticeably bad performance once the size of the Entry.sibling linked list reached ~10000, and the max I saw was ~30000 in a single scope. Given that an additional reference adds 32/64b, this could add up to 120/240Kb for the cases I saw. I'd add, is there a chance to get an improvement in Scope.remove speed > without making ScopeImpl.Entry bigger (assuming it gets bigger(?))? One > possibility that occurred to me is that we could try not to remove the > things from elems, but only mark them as removed. We would need to do > filtering (and possibly the actual removal) while reading from the Scope > (in getSymbols), so this is a different kind of trade-off. (Overall, I guess the question is whether we are trading problems with > Scope.remove speed in some cases for out-of-memory problems in other cases.) Thanks, I've verified your suggestion also gives us the performance improvements, so this change is okay with me. On Tue, Aug 27, 2019 at 12:05 AM Jan Lahoda wrote: > On 27. 08. 19 0:06, Brad Corso wrote: > > Sorry, what's the question? > > I believe "Do you have any estimates of the increase in size in typical > usage, due to the extra field in Scope?" (Jon) > > I'd add, is there a chance to get an improvement in Scope.remove speed > without making ScopeImpl.Entry bigger (assuming it gets bigger(?))? One > possibility that occurred to me is that we could try not to remove the > things from elems, but only mark them as removed. We would need to do > filtering (and possibly the actual removal) while reading from the Scope > (in getSymbols), so this is a different kind of trade-off. > > (Overall, I guess the question is whether we are trading problems with > Scope.remove speed in some cases for out-of-memory problems in other > cases.) > > Jan > > > > > On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro > > wrote: > > > > Adding Brad back in to the thread since he would know best > > > > ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan Gibbons > > ?>: > > > > > > On 8/26/19 9:12 AM, Ron Shapiro wrote: > > > > > > Note that the patch was prepared by my coworker, Brad (cc'd). > > I wasn't > > > sure what to do to make sure that he was attributed correctly. > > > > > > Mention this when you have a sponsor to push the changeset, so > > that it > > can be marked with "Contributed-By:" > > > > -- Jon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Aug 28 14:12:35 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 28 Aug 2019 16:12:35 +0200 Subject: RFR: JDK-8177068: incomplete classpath causes NPE in Flow Message-ID: <6b9e7075-51f7-0642-2296-8e18e11132de@oracle.com> Hi, If a class cannot be load during speculative attribution due to a CompletionFailure, the CompletionFailure may not be happening again during the ordinary attribution, which may lead to errors not being reported (as the error is a consequence of the CompletionFailure). Producing the error only on CompletionFailures helps with error recovery by not producing unnecessary errors. A similar problem with completion in user code was solved by restoring the ClassSymbol for which the completion failed to the original state when the user code finishes. Something similar could be done for speculative attribution, undoing the completion for ClassSymbols which fail to complete during speculative attribution, so that their completion will fail again during ordinary attribution and the error is reported properly. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8177068/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8177068 How does this look? Thanks, Jan From vicente.romero at oracle.com Wed Aug 28 19:03:49 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 28 Aug 2019 15:03:49 -0400 Subject: RFR: JDK-8230105: -XDfind=diamond crashes In-Reply-To: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> References: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> Message-ID: <11093bee-b098-1485-c8ef-29d75240b36b@oracle.com> Hi Jan, I like the patch, I think it is very sensible. I just have a cosmetic comment. I think that rebranding speculative attribution to a concept based on its side-effects could bring confusion in the future as the concept of speculative attribution is very deep in the understanding we have of the attribution process. So what I'm proposing is just a change in the name to the three states you defined, just a proposal: enum AttributionMode { ??? NON_SPECULATIVE(false), ??? ANALYZER(true) ??? SPECULATIVE(true); ??? AttributionMode(boolean isSpeculative) { ??????? this.isSpeculative = isSpeculative; ??? } ??? boolean isSpeculative() { ??????? return isSpeculative; ??? } ??? final isSpeculative; } we can work on the names but my proposal is to put the speculative-ness of the attribution foremost and the side-effect-ness in second place. What do you think? Vicente On 8/26/19 6:50 AM, Jan Lahoda wrote: > Hi, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230105 > Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8230105/webrev.00/ > > Consider this code: > --- > public class AnalyzerNotQuiteSpeculative { > ??? private void test() { > ??????? Subclass1 c1 = null; > ??????? Subclass2 c2 = null; > ??????? Base b = null; > > ??????? t(new C(c1).set(c2)); > ??????? t(new C(b).set(c2)); > ??? } > > ??? public static class Base {} > ??? public static class Subclass1 extends Base {} > ??? public static class Subclass2 extends Base {} > ??? public class C { > ??????? public C(T t) {} > ??????? public C set(T t) { return this; } > ??? } > ??? void t(C l) {} > } > --- > > When run with -XDfind=diamond, this crashes with: > --- > > ????at > jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) > ????at > jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:581) > ... > --- > > The embedded (thrown away) exception is: > --- > java.lang.NullPointerException > ????at > jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:261) > ????at > jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:225) > ????at > jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579) > ????at > jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:552) > ????at > jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:594) > ????at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1412) > ????at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380) > ????at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:972) > ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) > ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > ????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 reason for this exception seems to be that when the Analyzer is > speculatively analyzing "t(new C(c1).set(c2));", > ArgumentAttr.setResult will set a deferred type to "new > C(c1).set(c2)" (because isSpeculative is true), which in turn > will prevent the tree from being actually attributed. So when the > analyzer asks for type of "new C(c1)", it gets null. > > It ultimate problem appears to be that analyzers want to analyze a > piece of AST "as if" it was part of the source code, but without > having permanent side effects. But, currently, there is only the > AttrContext.isSpeculative boolean, which means both "no permanent > sideeffects" and "the tree is a scratch tree, that can be modified in > any way", and the latter is not quite the case when doing spec > attribution for analyzers. > > The proposed solution is to make the isSpeculative flag 3 tristate (by > using enum and renaming the field), which should allow us to > differentiate between "actual AST", "AST in analyzer" and "actual > speculative AST". > > I also created a patch that runs analyzers on all source code which > building and testing JDK, and fixed a few smallish trouble it found. > The patch to run the analyzers is not part of the proposed patch, but > can be seen here: > http://cr.openjdk.java.net/~jlahoda/8230105/webrev.runall/ > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Wed Aug 28 20:02:18 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 28 Aug 2019 16:02:18 -0400 Subject: RFR: JDK-8230105: -XDfind=diamond crashes In-Reply-To: <9c77530c-61f2-dcbd-2af6-bf9d69541da1@oracle.com> References: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> <11093bee-b098-1485-c8ef-29d75240b36b@oracle.com> <9c77530c-61f2-dcbd-2af6-bf9d69541da1@oracle.com> Message-ID: On 8/28/19 4:00 PM, Maurizio Cimadamore wrote: > I agree with Vicente, maybe replacing NON_SPECULATIVE with NORMAL (or > FULL) :-) yep I like FULL too > > Maurizio Vicente > > On 28/08/2019 20:03, Vicente Romero wrote: >> Hi Jan, >> >> I like the patch, I think it is very sensible. I just have a cosmetic >> comment. I think that rebranding speculative attribution to a concept >> based on its side-effects could bring confusion in the future as the >> concept of speculative attribution is very deep in the understanding >> we have of the attribution process. So what I'm proposing is just a >> change in the name to the three states you defined, just a proposal: >> >> enum AttributionMode { >> ??? NON_SPECULATIVE(false), >> ??? ANALYZER(true) >> ??? SPECULATIVE(true); >> >> ??? AttributionMode(boolean isSpeculative) { >> ??????? this.isSpeculative = isSpeculative; >> ??? } >> >> ??? boolean isSpeculative() { >> ??????? return isSpeculative; >> ??? } >> >> ??? final isSpeculative; >> } >> >> we can work on the names but my proposal is to put the >> speculative-ness of the attribution foremost and the side-effect-ness >> in second place. What do you think? >> >> Vicente >> >> On 8/26/19 6:50 AM, Jan Lahoda wrote: >>> Hi, >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8230105 >>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8230105/webrev.00/ >>> >>> Consider this code: >>> --- >>> public class AnalyzerNotQuiteSpeculative { >>> ??? private void test() { >>> ??????? Subclass1 c1 = null; >>> ??????? Subclass2 c2 = null; >>> ??????? Base b = null; >>> >>> ??????? t(new C(c1).set(c2)); >>> ??????? t(new C(b).set(c2)); >>> ??? } >>> >>> ??? public static class Base {} >>> ??? public static class Subclass1 extends Base {} >>> ??? public static class Subclass2 extends Base {} >>> ??? public class C { >>> ??????? public C(T t) {} >>> ??????? public C set(T t) { return this; } >>> ??? } >>> ??? void t(C l) {} >>> } >>> --- >>> >>> When run with -XDfind=diamond, this crashes with: >>> --- >>> >>> ????at >>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) >>> ????at >>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:581) >>> ... >>> --- >>> >>> The embedded (thrown away) exception is: >>> --- >>> java.lang.NullPointerException >>> ????at >>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:261) >>> ????at >>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:225) >>> ????at >>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579) >>> ????at >>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:552) >>> ????at >>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:594) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1412) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:972) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) >>> ????at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) >>> ????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 reason for this exception seems to be that when the Analyzer is >>> speculatively analyzing "t(new C(c1).set(c2));", >>> ArgumentAttr.setResult will set a deferred type to "new >>> C(c1).set(c2)" (because isSpeculative is true), which in turn >>> will prevent the tree from being actually attributed. So when the >>> analyzer asks for type of "new C(c1)", it gets null. >>> >>> It ultimate problem appears to be that analyzers want to analyze a >>> piece of AST "as if" it was part of the source code, but without >>> having permanent side effects. But, currently, there is only the >>> AttrContext.isSpeculative boolean, which means both "no permanent >>> sideeffects" and "the tree is a scratch tree, that can be modified >>> in any way", and the latter is not quite the case when doing spec >>> attribution for analyzers. >>> >>> The proposed solution is to make the isSpeculative flag 3 tristate >>> (by using enum and renaming the field), which should allow us to >>> differentiate between "actual AST", "AST in analyzer" and "actual >>> speculative AST". >>> >>> I also created a patch that runs analyzers on all source code which >>> building and testing JDK, and fixed a few smallish trouble it found. >>> The patch to run the analyzers is not part of the proposed patch, >>> but can be seen here: >>> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.runall/ >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From maurizio.cimadamore at oracle.com Wed Aug 28 20:00:09 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 28 Aug 2019 21:00:09 +0100 Subject: RFR: JDK-8230105: -XDfind=diamond crashes In-Reply-To: <11093bee-b098-1485-c8ef-29d75240b36b@oracle.com> References: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> <11093bee-b098-1485-c8ef-29d75240b36b@oracle.com> Message-ID: <9c77530c-61f2-dcbd-2af6-bf9d69541da1@oracle.com> I agree with Vicente, maybe replacing NON_SPECULATIVE with NORMAL (or FULL) :-) Maurizio On 28/08/2019 20:03, Vicente Romero wrote: > Hi Jan, > > I like the patch, I think it is very sensible. I just have a cosmetic > comment. I think that rebranding speculative attribution to a concept > based on its side-effects could bring confusion in the future as the > concept of speculative attribution is very deep in the understanding > we have of the attribution process. So what I'm proposing is just a > change in the name to the three states you defined, just a proposal: > > enum AttributionMode { > ??? NON_SPECULATIVE(false), > ??? ANALYZER(true) > ??? SPECULATIVE(true); > > ??? AttributionMode(boolean isSpeculative) { > ??????? this.isSpeculative = isSpeculative; > ??? } > > ??? boolean isSpeculative() { > ??????? return isSpeculative; > ??? } > > ??? final isSpeculative; > } > > we can work on the names but my proposal is to put the > speculative-ness of the attribution foremost and the side-effect-ness > in second place. What do you think? > > Vicente > > On 8/26/19 6:50 AM, Jan Lahoda wrote: >> Hi, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8230105 >> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8230105/webrev.00/ >> >> Consider this code: >> --- >> public class AnalyzerNotQuiteSpeculative { >> ??? private void test() { >> ??????? Subclass1 c1 = null; >> ??????? Subclass2 c2 = null; >> ??????? Base b = null; >> >> ??????? t(new C(c1).set(c2)); >> ??????? t(new C(b).set(c2)); >> ??? } >> >> ??? public static class Base {} >> ??? public static class Subclass1 extends Base {} >> ??? public static class Subclass2 extends Base {} >> ??? public class C { >> ??????? public C(T t) {} >> ??????? public C set(T t) { return this; } >> ??? } >> ??? void t(C l) {} >> } >> --- >> >> When run with -XDfind=diamond, this crashes with: >> --- >> >> ????at >> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) >> ????at >> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:581) >> ... >> --- >> >> The embedded (thrown away) exception is: >> --- >> java.lang.NullPointerException >> ????at >> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:261) >> ????at >> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:225) >> ????at >> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579) >> ????at >> jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:552) >> ????at >> jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:594) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1412) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380) >> ????at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:972) >> ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) >> ????at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) >> ????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 reason for this exception seems to be that when the Analyzer is >> speculatively analyzing "t(new C(c1).set(c2));", >> ArgumentAttr.setResult will set a deferred type to "new >> C(c1).set(c2)" (because isSpeculative is true), which in turn >> will prevent the tree from being actually attributed. So when the >> analyzer asks for type of "new C(c1)", it gets null. >> >> It ultimate problem appears to be that analyzers want to analyze a >> piece of AST "as if" it was part of the source code, but without >> having permanent side effects. But, currently, there is only the >> AttrContext.isSpeculative boolean, which means both "no permanent >> sideeffects" and "the tree is a scratch tree, that can be modified in >> any way", and the latter is not quite the case when doing spec >> attribution for analyzers. >> >> The proposed solution is to make the isSpeculative flag 3 tristate >> (by using enum and renaming the field), which should allow us to >> differentiate between "actual AST", "AST in analyzer" and "actual >> speculative AST". >> >> I also created a patch that runs analyzers on all source code which >> building and testing JDK, and fixed a few smallish trouble it found. >> The patch to run the analyzers is not part of the proposed patch, but >> can be seen here: >> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.runall/ >> >> How does this look? >> >> Thanks, >> ??? Jan > From jan.lahoda at oracle.com Thu Aug 29 08:53:22 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 29 Aug 2019 10:53:22 +0200 Subject: RFR: JDK-8230105: -XDfind=diamond crashes In-Reply-To: References: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> <11093bee-b098-1485-c8ef-29d75240b36b@oracle.com> <9c77530c-61f2-dcbd-2af6-bf9d69541da1@oracle.com> Message-ID: Thanks for the comments! Updated webrev using the AttributionMode.FULL/ANALYZER/SPECULATIVE: http://cr.openjdk.java.net/~jlahoda/8230105/webrev.01/ Jan On 28. 08. 19 22:02, Vicente Romero wrote: > > > On 8/28/19 4:00 PM, Maurizio Cimadamore wrote: >> I agree with Vicente, maybe replacing NON_SPECULATIVE with NORMAL (or >> FULL) :-) > yep I like FULL too >> >> Maurizio > > Vicente >> >> On 28/08/2019 20:03, Vicente Romero wrote: >>> Hi Jan, >>> >>> I like the patch, I think it is very sensible. I just have a cosmetic >>> comment. I think that rebranding speculative attribution to a concept >>> based on its side-effects could bring confusion in the future as the >>> concept of speculative attribution is very deep in the understanding >>> we have of the attribution process. So what I'm proposing is just a >>> change in the name to the three states you defined, just a proposal: >>> >>> enum AttributionMode { >>> ??? NON_SPECULATIVE(false), >>> ??? ANALYZER(true) >>> ??? SPECULATIVE(true); >>> >>> ??? AttributionMode(boolean isSpeculative) { >>> ??????? this.isSpeculative = isSpeculative; >>> ??? } >>> >>> ??? boolean isSpeculative() { >>> ??????? return isSpeculative; >>> ??? } >>> >>> ??? final isSpeculative; >>> } >>> >>> we can work on the names but my proposal is to put the >>> speculative-ness of the attribution foremost and the side-effect-ness >>> in second place. What do you think? >>> >>> Vicente >>> >>> On 8/26/19 6:50 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8230105 >>>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8230105/webrev.00/ >>>> >>>> Consider this code: >>>> --- >>>> public class AnalyzerNotQuiteSpeculative { >>>> ??? private void test() { >>>> ??????? Subclass1 c1 = null; >>>> ??????? Subclass2 c2 = null; >>>> ??????? Base b = null; >>>> >>>> ??????? t(new C(c1).set(c2)); >>>> ??????? t(new C(b).set(c2)); >>>> ??? } >>>> >>>> ??? public static class Base {} >>>> ??? public static class Subclass1 extends Base {} >>>> ??? public static class Subclass2 extends Base {} >>>> ??? public class C { >>>> ??????? public C(T t) {} >>>> ??????? public C set(T t) { return this; } >>>> ??? } >>>> ??? void t(C l) {} >>>> } >>>> --- >>>> >>>> When run with -XDfind=diamond, this crashes with: >>>> --- >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:581) >>>> >>>> ... >>>> --- >>>> >>>> The embedded (thrown away) exception is: >>>> --- >>>> java.lang.NullPointerException >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:261) >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:225) >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579) >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:552) >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:594) >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1412) >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380) >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:972) >>>> >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) >>>> ????at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) >>>> ????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 reason for this exception seems to be that when the Analyzer is >>>> speculatively analyzing "t(new C(c1).set(c2));", >>>> ArgumentAttr.setResult will set a deferred type to "new >>>> C(c1).set(c2)" (because isSpeculative is true), which in turn >>>> will prevent the tree from being actually attributed. So when the >>>> analyzer asks for type of "new C(c1)", it gets null. >>>> >>>> It ultimate problem appears to be that analyzers want to analyze a >>>> piece of AST "as if" it was part of the source code, but without >>>> having permanent side effects. But, currently, there is only the >>>> AttrContext.isSpeculative boolean, which means both "no permanent >>>> sideeffects" and "the tree is a scratch tree, that can be modified >>>> in any way", and the latter is not quite the case when doing spec >>>> attribution for analyzers. >>>> >>>> The proposed solution is to make the isSpeculative flag 3 tristate >>>> (by using enum and renaming the field), which should allow us to >>>> differentiate between "actual AST", "AST in analyzer" and "actual >>>> speculative AST". >>>> >>>> I also created a patch that runs analyzers on all source code which >>>> building and testing JDK, and fixed a few smallish trouble it found. >>>> The patch to run the analyzers is not part of the proposed patch, >>>> but can be seen here: >>>> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.runall/ >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> ??? Jan >>> > From maurizio.cimadamore at oracle.com Thu Aug 29 10:13:05 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 29 Aug 2019 11:13:05 +0100 Subject: RFR: JDK-8230105: -XDfind=diamond crashes In-Reply-To: References: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> <11093bee-b098-1485-c8ef-29d75240b36b@oracle.com> <9c77530c-61f2-dcbd-2af6-bf9d69541da1@oracle.com> Message-ID: Looks good - I've checked all the usages of the tri-state flag and they look good (and I noted the actual resolution of this issue, which is to tweak the check in ArgumentAttr.setResult). Maurizio On 29/08/2019 09:53, Jan Lahoda wrote: > Thanks for the comments! > > Updated webrev using the AttributionMode.FULL/ANALYZER/SPECULATIVE: > http://cr.openjdk.java.net/~jlahoda/8230105/webrev.01/ > > Jan > > On 28. 08. 19 22:02, Vicente Romero wrote: >> >> >> On 8/28/19 4:00 PM, Maurizio Cimadamore wrote: >>> I agree with Vicente, maybe replacing NON_SPECULATIVE with NORMAL >>> (or FULL) :-) >> yep I like FULL too >>> >>> Maurizio >> >> Vicente >>> >>> On 28/08/2019 20:03, Vicente Romero wrote: >>>> Hi Jan, >>>> >>>> I like the patch, I think it is very sensible. I just have a >>>> cosmetic comment. I think that rebranding speculative attribution >>>> to a concept based on its side-effects could bring confusion in the >>>> future as the concept of speculative attribution is very deep in >>>> the understanding we have of the attribution process. So what I'm >>>> proposing is just a change in the name to the three states you >>>> defined, just a proposal: >>>> >>>> enum AttributionMode { >>>> ??? NON_SPECULATIVE(false), >>>> ??? ANALYZER(true) >>>> ??? SPECULATIVE(true); >>>> >>>> ??? AttributionMode(boolean isSpeculative) { >>>> ??????? this.isSpeculative = isSpeculative; >>>> ??? } >>>> >>>> ??? boolean isSpeculative() { >>>> ??????? return isSpeculative; >>>> ??? } >>>> >>>> ??? final isSpeculative; >>>> } >>>> >>>> we can work on the names but my proposal is to put the >>>> speculative-ness of the attribution foremost and the >>>> side-effect-ness in second place. What do you think? >>>> >>>> Vicente >>>> >>>> On 8/26/19 6:50 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8230105 >>>>> Proposed webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.00/ >>>>> >>>>> Consider this code: >>>>> --- >>>>> public class AnalyzerNotQuiteSpeculative { >>>>> ??? private void test() { >>>>> ??????? Subclass1 c1 = null; >>>>> ??????? Subclass2 c2 = null; >>>>> ??????? Base b = null; >>>>> >>>>> ??????? t(new C(c1).set(c2)); >>>>> ??????? t(new C(b).set(c2)); >>>>> ??? } >>>>> >>>>> ??? public static class Base {} >>>>> ??? public static class Subclass1 extends Base {} >>>>> ??? public static class Subclass2 extends Base {} >>>>> ??? public class C { >>>>> ??????? public C(T t) {} >>>>> ??????? public C set(T t) { return this; } >>>>> ??? } >>>>> ??? void t(C l) {} >>>>> } >>>>> --- >>>>> >>>>> When run with -XDfind=diamond, this crashes with: >>>>> --- >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:581) >>>>> >>>>> ... >>>>> --- >>>>> >>>>> The embedded (thrown away) exception is: >>>>> --- >>>>> java.lang.NullPointerException >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:261) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:225) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:552) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:594) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1412) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:972) >>>>> >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) >>>>> ????at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) >>>>> ????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 reason for this exception seems to be that when the Analyzer >>>>> is speculatively analyzing "t(new C(c1).set(c2));", >>>>> ArgumentAttr.setResult will set a deferred type to "new >>>>> C(c1).set(c2)" (because isSpeculative is true), which in >>>>> turn will prevent the tree from being actually attributed. So when >>>>> the analyzer asks for type of "new C(c1)", it gets null. >>>>> >>>>> It ultimate problem appears to be that analyzers want to analyze a >>>>> piece of AST "as if" it was part of the source code, but without >>>>> having permanent side effects. But, currently, there is only the >>>>> AttrContext.isSpeculative boolean, which means both "no permanent >>>>> sideeffects" and "the tree is a scratch tree, that can be modified >>>>> in any way", and the latter is not quite the case when doing spec >>>>> attribution for analyzers. >>>>> >>>>> The proposed solution is to make the isSpeculative flag 3 tristate >>>>> (by using enum and renaming the field), which should allow us to >>>>> differentiate between "actual AST", "AST in analyzer" and "actual >>>>> speculative AST". >>>>> >>>>> I also created a patch that runs analyzers on all source code >>>>> which building and testing JDK, and fixed a few smallish trouble >>>>> it found. The patch to run the analyzers is not part of the >>>>> proposed patch, but can be seen here: >>>>> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.runall/ >>>>> >>>>> How does this look? >>>>> >>>>> Thanks, >>>>> ??? Jan >>>> >> From vicente.romero at oracle.com Thu Aug 29 14:35:45 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 29 Aug 2019 10:35:45 -0400 Subject: RFR: JDK-8230105: -XDfind=diamond crashes In-Reply-To: References: <69689699-ed73-aa36-f6fc-389b2c2e4202@oracle.com> <11093bee-b098-1485-c8ef-29d75240b36b@oracle.com> <9c77530c-61f2-dcbd-2af6-bf9d69541da1@oracle.com> Message-ID: looks good, Thanks, Vicente On 8/29/19 6:13 AM, Maurizio Cimadamore wrote: > Looks good - I've checked all the usages of the tri-state flag and > they look good (and I noted the actual resolution of this issue, which > is to tweak the check in ArgumentAttr.setResult). > > Maurizio > > On 29/08/2019 09:53, Jan Lahoda wrote: >> Thanks for the comments! >> >> Updated webrev using the AttributionMode.FULL/ANALYZER/SPECULATIVE: >> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.01/ >> >> Jan >> >> On 28. 08. 19 22:02, Vicente Romero wrote: >>> >>> >>> On 8/28/19 4:00 PM, Maurizio Cimadamore wrote: >>>> I agree with Vicente, maybe replacing NON_SPECULATIVE with NORMAL >>>> (or FULL) :-) >>> yep I like FULL too >>>> >>>> Maurizio >>> >>> Vicente >>>> >>>> On 28/08/2019 20:03, Vicente Romero wrote: >>>>> Hi Jan, >>>>> >>>>> I like the patch, I think it is very sensible. I just have a >>>>> cosmetic comment. I think that rebranding speculative attribution >>>>> to a concept based on its side-effects could bring confusion in >>>>> the future as the concept of speculative attribution is very deep >>>>> in the understanding we have of the attribution process. So what >>>>> I'm proposing is just a change in the name to the three states you >>>>> defined, just a proposal: >>>>> >>>>> enum AttributionMode { >>>>> ??? NON_SPECULATIVE(false), >>>>> ??? ANALYZER(true) >>>>> ??? SPECULATIVE(true); >>>>> >>>>> ??? AttributionMode(boolean isSpeculative) { >>>>> ??????? this.isSpeculative = isSpeculative; >>>>> ??? } >>>>> >>>>> ??? boolean isSpeculative() { >>>>> ??????? return isSpeculative; >>>>> ??? } >>>>> >>>>> ??? final isSpeculative; >>>>> } >>>>> >>>>> we can work on the names but my proposal is to put the >>>>> speculative-ness of the attribution foremost and the >>>>> side-effect-ness in second place. What do you think? >>>>> >>>>> Vicente >>>>> >>>>> On 8/26/19 6:50 AM, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8230105 >>>>>> Proposed webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.00/ >>>>>> >>>>>> Consider this code: >>>>>> --- >>>>>> public class AnalyzerNotQuiteSpeculative { >>>>>> ??? private void test() { >>>>>> ??????? Subclass1 c1 = null; >>>>>> ??????? Subclass2 c2 = null; >>>>>> ??????? Base b = null; >>>>>> >>>>>> ??????? t(new C(c1).set(c2)); >>>>>> ??????? t(new C(b).set(c2)); >>>>>> ??? } >>>>>> >>>>>> ??? public static class Base {} >>>>>> ??? public static class Subclass1 extends Base {} >>>>>> ??? public static class Subclass2 extends Base {} >>>>>> ??? public class C { >>>>>> ??????? public C(T t) {} >>>>>> ??????? public C set(T t) { return this; } >>>>>> ??? } >>>>>> ??? void t(C l) {} >>>>>> } >>>>>> --- >>>>>> >>>>>> When run with -XDfind=diamond, this crashes with: >>>>>> --- >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:581) >>>>>> >>>>>> ... >>>>>> --- >>>>>> >>>>>> The embedded (thrown away) exception is: >>>>>> --- >>>>>> java.lang.NullPointerException >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:261) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:225) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:552) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:594) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1412) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:972) >>>>>> >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:318) >>>>>> ????at >>>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) >>>>>> ????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 reason for this exception seems to be that when the Analyzer >>>>>> is speculatively analyzing "t(new C(c1).set(c2));", >>>>>> ArgumentAttr.setResult will set a deferred type to "new >>>>>> C(c1).set(c2)" (because isSpeculative is true), which in >>>>>> turn will prevent the tree from being actually attributed. So >>>>>> when the analyzer asks for type of "new C(c1)", it gets null. >>>>>> >>>>>> It ultimate problem appears to be that analyzers want to analyze >>>>>> a piece of AST "as if" it was part of the source code, but >>>>>> without having permanent side effects. But, currently, there is >>>>>> only the AttrContext.isSpeculative boolean, which means both "no >>>>>> permanent sideeffects" and "the tree is a scratch tree, that can >>>>>> be modified in any way", and the latter is not quite the case >>>>>> when doing spec attribution for analyzers. >>>>>> >>>>>> The proposed solution is to make the isSpeculative flag 3 >>>>>> tristate (by using enum and renaming the field), which should >>>>>> allow us to differentiate between "actual AST", "AST in analyzer" >>>>>> and "actual speculative AST". >>>>>> >>>>>> I also created a patch that runs analyzers on all source code >>>>>> which building and testing JDK, and fixed a few smallish trouble >>>>>> it found. The patch to run the analyzers is not part of the >>>>>> proposed patch, but can be seen here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8230105/webrev.runall/ >>>>>> >>>>>> How does this look? >>>>>> >>>>>> Thanks, >>>>>> ??? Jan >>>>> >>> From joe.darcy at oracle.com Thu Aug 29 18:30:34 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 29 Aug 2019 11:30:34 -0700 Subject: JDK 14 RFR of JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} Message-ID: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> Hello, Responding to some off-list comments from Jon, please review the proposed spec changes for ??? JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8230357 ??? webrev: http://cr.openjdk.java.net/~darcy/8230337.0/ Diff with below. A summary of the change is to formalize the informal (and implicit) "enclosing package" and "enclosing module" relationship. Once the wording is finalized, I'll review the tests of this area. Thanks, -Joe @@ -451,14 +451,19 @@ ???? /** ????? * Returns the package of an element.? The package of a package is ????? * itself. ????? * The package of a module is {@code null}. ????? * -???? * @param type the element being examined +???? * The package of a top-level type is its {@linkplain +???? * TypeElement#getEnclosingElement enclosing package}. Otherwise, +???? * the package of an element is equal to the package of the +???? * {@linkplain Element#getEnclosingElement enclosing element}. +???? * +???? * @param e the element being examined ????? * @return the package of an element ????? */ -??? PackageElement getPackageOf(Element type); +??? PackageElement getPackageOf(Element e); ???? /** ????? * Returns the module of an element.? The module of a module is ????? * itself. ????? * If there is no module for the element, null is returned. One situation where there is @@ -466,19 +471,25 @@ ????? * an annotation processing environment configured for ????? * a {@linkplain ????? * javax.annotation.processing.ProcessingEnvironment#getSourceVersion ????? * source version} without modules. ????? * +???? * If a package has a module as its {@linkplain +???? * PackageElement#getEnclosingElement enclosing element}, that +???? * module is the module of the package. Otherwise, the module of +???? * an element is equal to the module {@linkplain +???? * #getPackageOf(Element) of the package} of the element. +???? * ????? * @implSpec The default implementation of this method returns ????? * {@code null}. ????? * -???? * @param type the element being examined +???? * @param e the element being examined ????? * @return the module of an element ????? * @since 9 ????? * @spec JPMS ????? */ -??? default ModuleElement getModuleOf(Element type) { +??? default ModuleElement getModuleOf(Element e) { ???????? return null; ???? } ???? /** ????? * Returns all members of a type element, whether inherited or From jonathan.gibbons at oracle.com Thu Aug 29 21:05:35 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 29 Aug 2019 14:05:35 -0700 Subject: JDK 14 RFR of JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} In-Reply-To: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> References: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> Message-ID: Joe, The if-otherwise doesn't work here as you might have intended. If the package doesn't have a module for its enclosing element you fall into infinitely recursive "otherwise". -- Jon On 8/29/19 11:30 AM, Joe Darcy wrote: > > +???? * If a package has a module as its {@linkplain > +???? * PackageElement#getEnclosingElement enclosing element}, that > +???? * module is the module of the package. Otherwise, the module of > +???? * an element is equal to the module {@linkplain > +???? * #getPackageOf(Element) of the package} of the element. > +???? * From joe.darcy at oracle.com Thu Aug 29 23:45:59 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 29 Aug 2019 16:45:59 -0700 Subject: JDK 14 RFR of JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} In-Reply-To: References: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> Message-ID: <77056b27-5890-617c-8e97-2d6472ea8005@oracle.com> Hi Jon, For getModuleOf, how about: ??? /** ???? * Returns the module of an element.? The module of a module is ???? * itself. ???? * ???? * If a package has a module as its {@linkplain ???? * PackageElement#getEnclosingElement enclosing element}, that ???? * module is the module of the package. If the enclosing element ???? * of a package is {@code null}, {@code null} is returned for the ???? * package's module. ???? * ???? * (One situation where a package may have a {@code null} module ???? * is if the environment does not include modules, such as an ???? * annotation processing environment configured for a {@linkplain ???? * javax.annotation.processing.ProcessingEnvironment#getSourceVersion ???? * source version} without modules.) ???? * ???? * Otherwise, the module of an element is equal to the module ???? * {@linkplain #getPackageOf(Element) of the package} of the ???? * element. ???? * ???? * @implSpec The default implementation of this method returns ???? * {@code null}. ???? * ???? * @param e the element being examined ???? * @return the module of an element ???? * @since 9 ???? * @spec JPMS ???? */ ??? default ModuleElement getModuleOf(Element e) -Joe On 8/29/2019 2:05 PM, Jonathan Gibbons wrote: > Joe, > > The if-otherwise doesn't work here as you might have intended. > > If the package doesn't have a module for its enclosing element you > fall into infinitely recursive "otherwise". > > -- Jon > > On 8/29/19 11:30 AM, Joe Darcy wrote: >> >> +???? * If a package has a module as its {@linkplain >> +???? * PackageElement#getEnclosingElement enclosing element}, that >> +???? * module is the module of the package. Otherwise, the module of >> +???? * an element is equal to the module {@linkplain >> +???? * #getPackageOf(Element) of the package} of the element. >> +???? * From wdietl at gmail.com Fri Aug 30 00:35:20 2019 From: wdietl at gmail.com (Werner Dietl) Date: Thu, 29 Aug 2019 20:35:20 -0400 Subject: Use of an annotation without @Target meta-annotation on a module declaration Message-ID: Since Java 8, the JavaDoc for java.lang.annotation.Target contains: "If an @Target meta-annotation is not present on an annotation type T, then an annotation of type T may be written as a modifier for any declaration except a type parameter declaration." In Java 9, the additional constant MODULE was added to java.lang.annotation.ElementType for module declarations. Should an annotation without @Target meta-annotation be usable on a module declaration or not? Take a file module-info.java: @pkg.Anno module moduletest {} and a file pgk/Anno.java: package pkg; public @interface Anno {} The above specification would seem to allow the use of @Anno on moduletest and ecj (tested with version 3.16.0) compiles the test case above. However, javac version 11.0.1 gives the following error: module-info.java:1: error: annotation type not applicable to this kind of declaration @pkg.Anno ^ 1 error The javac error goes away when adding a @Target(ElementType.MODULE) meta-annotation. Is this a bug in javac or is this a problem with the JavaDoc? Best, cu, WMD. -- https://ece.uwaterloo.ca/~wdietl/ From alex.buckley at oracle.com Fri Aug 30 01:44:59 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 29 Aug 2019 18:44:59 -0700 Subject: Use of an annotation without @Target meta-annotation on a module declaration In-Reply-To: References: Message-ID: <4137c111-8f14-562b-c889-59fef8867493@oracle.com> On 8/29/2019 5:35 PM, Werner Dietl wrote: > Since Java 8, the JavaDoc for java.lang.annotation.Target contains: > > "If an @Target meta-annotation is not present on an annotation type T, > then an annotation of type T may be written as a modifier for any > declaration except a type parameter declaration." > > In Java 9, the additional constant MODULE was added to > java.lang.annotation.ElementType for module declarations. > > Should an annotation without @Target meta-annotation be usable on a > module declaration or not? The API spec of j.l.a.Target agrees with JLS 9.6.4.1 which defines the meaning of @Target when it appears (and when it doesn't) on annotation type declarations. Without @Target on its declaration, an annotation type is applicable on module declarations. Below, ecj is right and javac is wrong. JSR 308 introduced the "all declaration contexts except type parameter declarations" rule in an attempt to constrain no- at Target to SE 7 contexts only. As the Java language gets more kinds of declarations -- modules, records, values -- the open-ended wording of the rule ("all") is at odds with its closed-ended intent. The ongoing maintenance burden for javac and the API spec and the JLS is unwelcome. Frankly, I think the SE 7-only intent was misguided; no- at Target should have meant "all declaration contexts", end of story, no more threads like this ever again. Any objections to changing the rule in a future SE release? Alex > Take a file module-info.java: > > @pkg.Anno > module moduletest {} > > and a file pgk/Anno.java: > > package pkg; > public @interface Anno {} > > The above specification would seem to allow the use of @Anno on > moduletest and ecj (tested with version 3.16.0) compiles the test case > above. > However, javac version 11.0.1 gives the following error: > > module-info.java:1: error: annotation type not applicable to this kind > of declaration > @pkg.Anno > ^ > 1 error > > The javac error goes away when adding a @Target(ElementType.MODULE) > meta-annotation. > > Is this a bug in javac or is this a problem with the JavaDoc? > > Best, > cu, WMD. > From jonathan.gibbons at oracle.com Fri Aug 30 04:16:13 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 29 Aug 2019 21:16:13 -0700 Subject: JDK 14 RFR of JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} In-Reply-To: <77056b27-5890-617c-8e97-2d6472ea8005@oracle.com> References: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> <77056b27-5890-617c-8e97-2d6472ea8005@oracle.com> Message-ID: <0fbacdd5-cdcb-9193-2a69-2fbd8e53e104@oracle.com> +1 -- Jon On 8/29/19 4:45 PM, Joe Darcy wrote: > Hi Jon, > > For getModuleOf, how about: > > ??? /** > ???? * Returns the module of an element.? The module of a module is > ???? * itself. > ???? * > ???? * If a package has a module as its {@linkplain > ???? * PackageElement#getEnclosingElement enclosing element}, that > ???? * module is the module of the package. If the enclosing element > ???? * of a package is {@code null}, {@code null} is returned for the > ???? * package's module. > ???? * > ???? * (One situation where a package may have a {@code null} module > ???? * is if the environment does not include modules, such as an > ???? * annotation processing environment configured for a {@linkplain > ???? * javax.annotation.processing.ProcessingEnvironment#getSourceVersion > ???? * source version} without modules.) > ???? * > ???? * Otherwise, the module of an element is equal to the module > ???? * {@linkplain #getPackageOf(Element) of the package} of the > ???? * element. > ???? * > ???? * @implSpec The default implementation of this method returns > ???? * {@code null}. > ???? * > ???? * @param e the element being examined > ???? * @return the module of an element > ???? * @since 9 > ???? * @spec JPMS > ???? */ > ??? default ModuleElement getModuleOf(Element e) > > -Joe > > On 8/29/2019 2:05 PM, Jonathan Gibbons wrote: >> Joe, >> >> The if-otherwise doesn't work here as you might have intended. >> >> If the package doesn't have a module for its enclosing element you >> fall into infinitely recursive "otherwise". >> >> -- Jon >> >> On 8/29/19 11:30 AM, Joe Darcy wrote: >>> >>> +???? * If a package has a module as its {@linkplain >>> +???? * PackageElement#getEnclosingElement enclosing element}, that >>> +???? * module is the module of the package. Otherwise, the module of >>> +???? * an element is equal to the module {@linkplain >>> +???? * #getPackageOf(Element) of the package} of the element. >>> +???? * From joe.darcy at oracle.com Fri Aug 30 17:59:17 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Aug 2019 10:59:17 -0700 Subject: JDK 14 RFR of JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} In-Reply-To: <0fbacdd5-cdcb-9193-2a69-2fbd8e53e104@oracle.com> References: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> <77056b27-5890-617c-8e97-2d6472ea8005@oracle.com> <0fbacdd5-cdcb-9193-2a69-2fbd8e53e104@oracle.com> Message-ID: <33900ce5-ef64-e96a-563c-b74625432e07@oracle.com> Now with tests: ??? http://cr.openjdk.java.net/~darcy/8230337.2/ Jon, I'll update the CSR to match the spec text you previously approved and add you as a reviewer there. Thanks, -Joe On 8/29/2019 9:16 PM, Jonathan Gibbons wrote: > +1 > > -- Jon > > On 8/29/19 4:45 PM, Joe Darcy wrote: >> Hi Jon, >> >> For getModuleOf, how about: >> >> ??? /** >> ???? * Returns the module of an element.? The module of a module is >> ???? * itself. >> ???? * >> ???? * If a package has a module as its {@linkplain >> ???? * PackageElement#getEnclosingElement enclosing element}, that >> ???? * module is the module of the package. If the enclosing element >> ???? * of a package is {@code null}, {@code null} is returned for the >> ???? * package's module. >> ???? * >> ???? * (One situation where a package may have a {@code null} module >> ???? * is if the environment does not include modules, such as an >> ???? * annotation processing environment configured for a {@linkplain >> ???? * >> javax.annotation.processing.ProcessingEnvironment#getSourceVersion >> ???? * source version} without modules.) >> ???? * >> ???? * Otherwise, the module of an element is equal to the module >> ???? * {@linkplain #getPackageOf(Element) of the package} of the >> ???? * element. >> ???? * >> ???? * @implSpec The default implementation of this method returns >> ???? * {@code null}. >> ???? * >> ???? * @param e the element being examined >> ???? * @return the module of an element >> ???? * @since 9 >> ???? * @spec JPMS >> ???? */ >> ??? default ModuleElement getModuleOf(Element e) >> >> -Joe >> >> On 8/29/2019 2:05 PM, Jonathan Gibbons wrote: >>> Joe, >>> >>> The if-otherwise doesn't work here as you might have intended. >>> >>> If the package doesn't have a module for its enclosing element you >>> fall into infinitely recursive "otherwise". >>> >>> -- Jon >>> >>> On 8/29/19 11:30 AM, Joe Darcy wrote: >>>> >>>> +???? * If a package has a module as its {@linkplain >>>> +???? * PackageElement#getEnclosingElement enclosing element}, that >>>> +???? * module is the module of the package. Otherwise, the module of >>>> +???? * an element is equal to the module {@linkplain >>>> +???? * #getPackageOf(Element) of the package} of the element. >>>> +???? * From jonathan.gibbons at oracle.com Fri Aug 30 18:07:38 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 30 Aug 2019 11:07:38 -0700 Subject: JDK 14 RFR of JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} In-Reply-To: <33900ce5-ef64-e96a-563c-b74625432e07@oracle.com> References: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> <77056b27-5890-617c-8e97-2d6472ea8005@oracle.com> <0fbacdd5-cdcb-9193-2a69-2fbd8e53e104@oracle.com> <33900ce5-ef64-e96a-563c-b74625432e07@oracle.com> Message-ID: <5c42216e-ac03-81a7-5a34-517127af2206@oracle.com> Style typo, but otherwise OK. http://cr.openjdk.java.net/~darcy/8230337.2/test/langtools/tools/javac/processing/model/util/elements/TestGetPackageOf.java.sdiff.html 65 for(var testCase : testCases.entrySet()) { add space between 'for' and '('. -- Jon On 8/30/19 10:59 AM, Joe Darcy wrote: > Now with tests: > > ??? http://cr.openjdk.java.net/~darcy/8230337.2/ > > Jon, I'll update the CSR to match the spec text you previously > approved and add you as a reviewer there. > > Thanks, > > -Joe > > On 8/29/2019 9:16 PM, Jonathan Gibbons wrote: >> +1 >> >> -- Jon >> >> On 8/29/19 4:45 PM, Joe Darcy wrote: >>> Hi Jon, >>> >>> For getModuleOf, how about: >>> >>> ??? /** >>> ???? * Returns the module of an element.? The module of a module is >>> ???? * itself. >>> ???? * >>> ???? * If a package has a module as its {@linkplain >>> ???? * PackageElement#getEnclosingElement enclosing element}, that >>> ???? * module is the module of the package. If the enclosing element >>> ???? * of a package is {@code null}, {@code null} is returned for the >>> ???? * package's module. >>> ???? * >>> ???? * (One situation where a package may have a {@code null} module >>> ???? * is if the environment does not include modules, such as an >>> ???? * annotation processing environment configured for a {@linkplain >>> ???? * >>> javax.annotation.processing.ProcessingEnvironment#getSourceVersion >>> ???? * source version} without modules.) >>> ???? * >>> ???? * Otherwise, the module of an element is equal to the module >>> ???? * {@linkplain #getPackageOf(Element) of the package} of the >>> ???? * element. >>> ???? * >>> ???? * @implSpec The default implementation of this method returns >>> ???? * {@code null}. >>> ???? * >>> ???? * @param e the element being examined >>> ???? * @return the module of an element >>> ???? * @since 9 >>> ???? * @spec JPMS >>> ???? */ >>> ??? default ModuleElement getModuleOf(Element e) >>> >>> -Joe >>> >>> On 8/29/2019 2:05 PM, Jonathan Gibbons wrote: >>>> Joe, >>>> >>>> The if-otherwise doesn't work here as you might have intended. >>>> >>>> If the package doesn't have a module for its enclosing element you >>>> fall into infinitely recursive "otherwise". >>>> >>>> -- Jon >>>> >>>> On 8/29/19 11:30 AM, Joe Darcy wrote: >>>>> >>>>> +???? * If a package has a module as its {@linkplain >>>>> +???? * PackageElement#getEnclosingElement enclosing element}, that >>>>> +???? * module is the module of the package. Otherwise, the module of >>>>> +???? * an element is equal to the module {@linkplain >>>>> +???? * #getPackageOf(Element) of the package} of the element. >>>>> +???? * -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Aug 30 18:27:24 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Aug 2019 11:27:24 -0700 Subject: JDK 14 RFR of JDK-8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} In-Reply-To: <5c42216e-ac03-81a7-5a34-517127af2206@oracle.com> References: <16d76ad9-bf72-3e44-a86b-37fb57f69c75@oracle.com> <77056b27-5890-617c-8e97-2d6472ea8005@oracle.com> <0fbacdd5-cdcb-9193-2a69-2fbd8e53e104@oracle.com> <33900ce5-ef64-e96a-563c-b74625432e07@oracle.com> <5c42216e-ac03-81a7-5a34-517127af2206@oracle.com> Message-ID: On 8/30/2019 11:07 AM, Jonathan Gibbons wrote: > > Style typo, but otherwise OK. > > http://cr.openjdk.java.net/~darcy/8230337.2/test/langtools/tools/javac/processing/model/util/elements/TestGetPackageOf.java.sdiff.html > > 65 for(var testCase : testCases.entrySet()) { > add space between 'for' and '('. > > - Addressed before pushing; thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: