From maurizio.cimadamore at oracle.com Wed May 1 08:04:34 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 1 May 2019 09:04:34 +0100 Subject: RFR: JDK-8222744: add support for generating method handles from a variable symbol In-Reply-To: References: Message-ID: <069fc1c9-1b5b-493c-0cc4-68f4cdb50a71@oracle.com> Looks good - an alternative would have been to use an anonymous inner class creation in VarSymbol::asMethodHandle, but I don't feel strongly either way, and I'll leave the decision to you. Maurizio On 22/04/2019 22:16, Vicente Romero wrote: > Please review the fix for [1] at [2]. This is a small follow up after > [3] which introduced a new internal constant pool API in javac. We > realized that it was not possible to generate with the new API method > handles with reference kinds: > > ?* REF_getField > ?* REF_putField > ?* REF_getStatic > ?* REF_putStatic > > This patch adds that feature, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8222744 > [2] http://cr.openjdk.java.net/~vromero/8222744/ > [3] https://bugs.openjdk.java.net/browse/JDK-8222289 From vicente.romero at oracle.com Wed May 1 12:42:46 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 1 May 2019 08:42:46 -0400 Subject: RFR: JDK-8222744: add support for generating method handles from a variable symbol In-Reply-To: <069fc1c9-1b5b-493c-0cc4-68f4cdb50a71@oracle.com> References: <069fc1c9-1b5b-493c-0cc4-68f4cdb50a71@oracle.com> Message-ID: <82a6db2c-2c87-f2de-9f42-7862850eaa7a@oracle.com> On 5/1/19 4:04 AM, Maurizio Cimadamore wrote: > Looks good - an alternative would have been to use an anonymous inner > class creation in VarSymbol::asMethodHandle, but I don't feel strongly > either way, and I'll leave the decision to you. Thanks for the review. I think I prefer the code this way as it is using the same approach as MethodSymbol::asHandle Vicente > > Maurizio > > On 22/04/2019 22:16, Vicente Romero wrote: >> Please review the fix for [1] at [2]. This is a small follow up after >> [3] which introduced a new internal constant pool API in javac. We >> realized that it was not possible to generate with the new API method >> handles with reference kinds: >> >> ?* REF_getField >> ?* REF_putField >> ?* REF_getStatic >> ?* REF_putStatic >> >> This patch adds that feature, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8222744 >> [2] http://cr.openjdk.java.net/~vromero/8222744/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8222289 From bsrbnd at gmail.com Wed May 1 13:42:56 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 1 May 2019 15:42:56 +0200 Subject: JDK-8221373 : Missing checkcast in void-returning lambda Message-ID: Hi, I looked quickly at Liam's example, but I don't think JDK-8203338 introduced any regression in javac. The target return type is 'void' and the unnecessary 'checkcast' is no more emitted before a simple 'return'. But trying the following example: public abstract class Checkcast { interface I { X d(); } abstract I c(); interface R { X run(); } void f() { R r = () -> this.c().d(); r.run(); } public static void main(String... args) { new Checkcast() { I c() { return new I() { public Long d() { System.out.println("OK"); return 0L; } }; } }.f(); } } the 'checkcast' is still emitted before 'areturn' along with an unchecked warning and a CCE occurs as expected: private java.lang.Void lambda$f$0(); Code: 0: aload_0 1: invokevirtual #7 // Method c:()LCheckcast$I; 4: invokeinterface #8, 1 // InterfaceMethod Checkcast$I.d:()Ljava/lang/Object; 9: checkcast #9 // class java/lang/Void 12: areturn Do we agree? Thanks, Bernard From james.laskey at oracle.com Wed May 1 20:42:43 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 1 May 2019 17:42:43 -0300 Subject: RFR (CSR) - JDK-8218285 ClassDesc should have a full name method Message-ID: Please review. Thank you. Cheers, -- Jim Summary: Add the method ClassDesc::displayFullName to return the fully qualified class name from a ClassDesc. Add a second method MethodTypeDesc::displayFullDescriptor which returns the MethodTypeDesc descriptor using fully qualified class names. csr: https://bugs.openjdk.java.net/browse/JDK-8218285 jbs: https://bugs.openjdk.java.net/browse/JDK-8212975 webrev: http://cr.openjdk.java.net/~jlaskey/8212975/webrev-03/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Wed May 1 21:01:19 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 1 May 2019 14:01:19 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> Message-ID: <6cb2d53a-0d67-cf80-67d1-2d0cc7015d46@oracle.com> Hi Joe, Thanks for the explanation of annotations and modules. I'll leave the exact circumstances of issuing warnings up to you. Since it's just about issuing warning messages, it's reasonable that it doesn't need to be precise. My concern is that the deduplication+warning code is hard to understand, and that someone in the future (maybe you!) will come across it and have a difficult time figuring it out; they might also worry about its precise behavior, not realizing that the warning policy isn't be precise. It seems to me like the core of the algorithm can be implemented as follows. Given a String[] array, the elements can be deduplicated into a set this way: List dups = new ArrayList<>(Arrays.asList(array)); Set result = new HashSet<>(); dups.removeIf(result::add); Now, 'result' contains the deduplicated items and 'dups' is a list (which might itself contain duplicates!) of duplicated items. The warning messages, if necessary, can then be generated from the 'dups' list after the fact. I'm not entirely sure of the best way to handle module prefix removal. If the index/substring logic were extracted into a message, the initialization of 'dups' could be replaced with a short stream that calls the module prefix removal function from map(). The exact behavior of the for-loop as it stands, though, would be difficult to implement this way. Then again, since the warning policy doesn't need to be precise, maybe this is ok. I'll leave it up to you whether you want to continue reworking this code. s'marks On 4/30/19 4:21 PM, Joe Darcy wrote: > Hi Stuart, > > On 4/29/2019 5:14 PM, Stuart Marks wrote: >> Hi Joe, >> >> Some nitpicky comments for you in AbstractProcessor.java. :-) > > > Thanks for the careful review. > > >> >> I'm finding the boolean flags to be fairly confusing. Consider the >> 'initialized' field. This has a synchronized getter; >> getSupportedAnnotationTypes() calls the getter and stores the result in a >> local for use within this method. However, arrayToSet() accesses the >> 'initialized' field directly, and it's called (unsynchronized) from >> getSupportedOptions() as well as getSupportedAnnotationTypes(). >> >> First, there's a potential memory visibility problem here, if you're concerned >> about multithreaded access. (At least some of the code in this class seems to >> try to handle thread-safety.) Second, the 'initialized' state is accessed from >> two different levels in the method call hierarchy, e.g. >> getSupportedAnnotationTypes() and arrayToSet(). This isn't necessarily a >> problem, but it does make me pause to try to think about what it means. > > > Yes; the is-initialized check should be done using the isInitalized method as > done elsewhere in the class; needed update made in > > ??? http://cr.openjdk.java.net/~darcy/8146726.6/ > >> >> Another flag is 'stripModulePrefixes' (parameter to arrayToSet()) and its >> dependent local variable 'stripped' which is set if anything was actually >> stripped from this element. These make arrayToSet() a bit of a puzzle for me. >> I think the following are true: >> >> 1) if we aren't stripping module prefixes, we'll issue a warning on any >> duplicates. >> >> 2) if we are stripping module prefixes, we won't issue a warning if a prefixes >> was stripped from this element. >> >> My first inclination is to think that there are really two different >> arrayToSet() methods wanted here. The first doesn't strip and may issue >> warnings, and the second does strip and doesn't issue warnings. It seems to me >> that two separate methods might be simpler than one bigger method with a bunch >> of flags. >> >> But that's not what the current implementation does. However, the current >> implementation doesn't quite make sense to me either. For example, the comment >> says that if module names are stripped, warnings aren't issued because they'd >> be spurious if the array is ["foo/a.B", "bar/a.B"]. However, I'm not sure this >> logic makes sense. It seems to me that if the array is >> >> ??? ["a.B", "foo/a.B"] >> >> then no warning is issued, but if the array is >> >> ??? ["foo/a.B", "a.B"] >> >> the a warning is issued. Am I reading this correctly, and is this the right >> behavior? >> >> > A bit of background on the intention of the AbstractProcessor class. The class > was a major usability improvement added in JSR 269 over the apt API . The > AbstractProcessor class provides a convenient "JDWIOWTD" - just do what I > obviously want to do - approach for common processor tasks. Of most relevance > here, it allows annotations on the processor class to succinctly indicate which > annotation types and options the processor supports. > > The semantics of the improved warnings in supported options proposed in this > change is straightforward: is there are any repeated elements in the array > retrieved from the annotation (and a messager to report a warning is available), > report that an element is repeated. > > Given some existing functionality to support annotation processing and modules, > the improved warnings support for the supported annotation types is more subtle. > Before modules, basically an annotation type name was an annotation type name, > like "a.B", and they could be compared for duplicates just like options > > The supported annotation type names are a set of strings built from a string > array of inputs. Originally pre-modules, the supported syntax of the type names > included fully qualified names and some wildcard support. These names could be > subject to the same style of duplicate checking as done for option names in this > patch. With modules, the recommended syntax for names includes a module prefix, > "foo/a.B" as distinct from "bar/a.B". Without a module prefix, "a.B" will match > a same-named annotation type in any module. > > One goal of AbstractProcessor in JDK 9 and later is to allow a processor to > smoothly support running in an environment with or without modules. Therefore > "a.B" retains its meaning by matching an annotation type in that name in any > module. Since the recommendation is to include a module name, if the compilation > environment doesn't support modules, > AbstractProcesso.getSupportedAnnotationTypes drop the module prefix if present. > Therefore, if the the annotation information is > > ??? @SupportedAnnotationTypes({"foo/a.B", "bar/a.B"}) > > AbstractProcessor.getSupportedAnnotationTypes treats this as equivalent to > > ??? @SupportedAnnotationTypes({"a.B", "a.B"}) > > which is of course semantically the same as "a.B". Now, in this case I think it > is acceptable to not get a warning when such a processor is run in an > environment without modules. However, the code as it is currently written will > *not* warning for > > ??? {"foo/a.B", "foo/a.B"} > > when run without modules. That input will get a warning if run *with* module > though. The input > > ??? ??? {"a.B", "a.B"} > > will generate a warning independent of modules being supported. > > Having jtreg @compile statements with different source levels allows this > behavior to be tested. > > The current minor complication in the checking loop are in lieu of a more > complicated check that would first compare for duplicates on the original set of > values and then preform a module stripping step where that was appropriate. I > didn't regard the extra warning coverage to be worth the effort, but I'm happy > to discuss the matter. > > HTH, > > -Joe > From joe.darcy at oracle.com Wed May 1 23:54:04 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 01 May 2019 16:54:04 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: <6cb2d53a-0d67-cf80-67d1-2d0cc7015d46@oracle.com> References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> <6cb2d53a-0d67-cf80-67d1-2d0cc7015d46@oracle.com> Message-ID: <5CCA319C.4030801@oracle.com> Hi Stuart, I think the current patch is a sufficient enough improvement to be pushed, reserving the ability for further improvements in the future :-) Thanks, -Joe On 5/1/2019 2:01 PM, Stuart Marks wrote: > Hi Joe, > > Thanks for the explanation of annotations and modules. I'll leave the > exact circumstances of issuing warnings up to you. Since it's just > about issuing warning messages, it's reasonable that it doesn't need > to be precise. > > My concern is that the deduplication+warning code is hard to > understand, and that someone in the future (maybe you!) will come > across it and have a difficult time figuring it out; they might also > worry about its precise behavior, not realizing that the warning > policy isn't be precise. > > It seems to me like the core of the algorithm can be implemented as > follows. Given a String[] array, the elements can be deduplicated into > a set this way: > > List dups = new ArrayList<>(Arrays.asList(array)); > Set result = new HashSet<>(); > dups.removeIf(result::add); > > Now, 'result' contains the deduplicated items and 'dups' is a list > (which might itself contain duplicates!) of duplicated items. The > warning messages, if necessary, can then be generated from the 'dups' > list after the fact. > > I'm not entirely sure of the best way to handle module prefix removal. > If the index/substring logic were extracted into a message, the > initialization of 'dups' could be replaced with a short stream that > calls the module prefix removal function from map(). The exact > behavior of the for-loop as it stands, though, would be difficult to > implement this way. Then again, since the warning policy doesn't need > to be precise, maybe this is ok. > > I'll leave it up to you whether you want to continue reworking this code. > > s'marks > From alex.buckley at oracle.com Mon May 6 19:06:22 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 06 May 2019 12:06:22 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CB0E11D.8070801@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> Message-ID: <5CD085AE.4050008@oracle.com> On 4/12/2019 12:03 PM, Alex Buckley wrote: > On 4/12/2019 5:34 AM, Jan Lahoda wrote: >> I've started with the CSR here: >> https://bugs.openjdk.java.net/browse/JDK-8222396 > > Looks pretty good. I made some edits to record both of your > single-module and multi-module invocations of javac. > > The use case of injecting test code is clear, but the exact connection > between automatic modules and test code is pretty opaque. Is the goal to > make the automatic test module read the explicit test module so that the > former module's code can access the latter module's code? Is the goal to > make the automatic module read (and therefore test) at least the same > set of modules as the explicit modules `requires`? Reviewing the CSR again, it seemed like the key scenario is multiple named modules, where for each named module: 1. We don't really care about its relationship with the other named modules; but 2. We do care about injecting it with test code, and letting that test code read other, completely arbitrary, modules (say, an assertion-building library that's been placed on the module path). I have refactored the CSR to more strongly separate the problem (patching an automatic module is possible, but readability is sub-par) from the solution (precedent for ALL-MODULE-PATH from the unnamed module scenario). JEP 261 should be updated to explain the awesome power of --patch-module at compile time, and that is progressing behind the scenes, but I don't think it needs to block JDK-8220702 -- the CSR is "good enough" documentation for now. Alex From vicente.romero at oracle.com Tue May 7 23:01:28 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 May 2019 19:01:28 -0400 Subject: RFR: JDK-8222949: add condy support to javac's pool API Message-ID: <012032e3-4d7f-21d0-d80b-712425bdf94f@oracle.com> Please review the fix for [1] at [2]. This enhancement is related to [3] which introduced a new API for constant pool reading / writing in javac. The current patch adds condy support that was missing. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8222949 [2] http://cr.openjdk.java.net/~vromero/8222949/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8222289 From christoph.langer at sap.com Wed May 8 08:02:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 May 2019 08:02:58 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler Message-ID: Hi, please review a small change that I'd like to see in OpenJDK to get rid of compilation errors in the Eclipse IDE. It seems the root cause for the compilation errors is that javac would sometimes widen capture variables and is hence able to compile the places that I touch here. The EC4J compiler claims that it's following the spec more strictly and bails out at these places. I had posted about this on compiler-dev but got no reaction [0]. So, as this seems to be some field of open work for the compiler/spec folks, I'd like to get EC4J quiesced by introducing some slight modifications to the original places which makes the code appeal a bit less elegant and fluent but will get rid of the compile errors. Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8223553 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ The modification to src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java belongs to JSR-166, so I don't know if it needs some special handling. Thanks & Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013054.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed May 8 09:37:39 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 May 2019 10:37:39 +0100 Subject: RFR: JDK-8222949: add condy support to javac's pool API In-Reply-To: <012032e3-4d7f-21d0-d80b-712425bdf94f@oracle.com> References: <012032e3-4d7f-21d0-d80b-712425bdf94f@oracle.com> Message-ID: Looks very good! One minor nit, unrelated to your patch, looking at the webrev I noted that DynamicItem::store is doing 'assert false' - I think a better idiom would be to use the Assert.error() facility, so that if this failure is triggered an exception will be thrown no matter what. Thanks Maurizio On 08/05/2019 00:01, Vicente Romero wrote: > Please review the fix for [1] at [2]. This enhancement is related to > [3] which introduced a new API for constant pool reading / writing in > javac. The current patch adds condy support that was missing. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8222949 > [2] http://cr.openjdk.java.net/~vromero/8222949/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8222289 From vicente.romero at oracle.com Wed May 8 12:23:22 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 May 2019 08:23:22 -0400 Subject: RFR: JDK-8222949: add condy support to javac's pool API In-Reply-To: References: <012032e3-4d7f-21d0-d80b-712425bdf94f@oracle.com> Message-ID: On 5/8/19 5:37 AM, Maurizio Cimadamore wrote: > Looks very good! :) thanks > > One minor nit, unrelated to your patch, looking at the webrev I noted > that DynamicItem::store is doing 'assert false' - I think a better > idiom would be to use the Assert.error() facility, so that if this > failure is triggered an exception will be thrown no matter what. right I will do that change before pushing the patch > > Thanks > Maurizio Thanks for the review, Vicente > > On 08/05/2019 00:01, Vicente Romero wrote: >> Please review the fix for [1] at [2]. This enhancement is related to >> [3] which introduced a new API for constant pool reading / writing in >> javac. The current patch adds condy support that was missing. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8222949 >> [2] http://cr.openjdk.java.net/~vromero/8222949/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8222289 From vicente.romero at oracle.com Wed May 8 18:56:47 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 May 2019 14:56:47 -0400 Subject: RFR: JDK-8222251: preflow visitor is not visiting lambda expressions Message-ID: Please review fix for [1] at [2]. This patch is fixing a regression introduced by [3]. The idea of [3] was to skip the preflow visitor from visiting inner classes and lambdas inside an "outer" lambda expression. But by passing the "outer" lambda expression to it, the whole lambda wasn't being visited. This patch fixes this issue by running the preflow visitor on the body of the "outer" lambda expression. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8222251 [2] http://cr.openjdk.java.net/~vromero/8222251/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8203277 From maurizio.cimadamore at oracle.com Wed May 8 22:24:09 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 8 May 2019 23:24:09 +0100 Subject: RFR: JDK-8222251: preflow visitor is not visiting lambda expressions In-Reply-To: References: Message-ID: <242fded7-396e-a40e-a39c-9dc683bfae2b@oracle.com> Looks good Maurizio On 08/05/2019 19:56, Vicente Romero wrote: > Please review fix for [1] at [2]. This patch is fixing a regression > introduced by [3]. The idea of [3] was to skip the preflow visitor > from visiting inner classes and lambdas inside an "outer" lambda > expression. But by passing the "outer" lambda expression to it, the > whole lambda wasn't being visited. This patch fixes this issue by > running the preflow visitor on the body of the "outer" lambda expression. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8222251 > [2] http://cr.openjdk.java.net/~vromero/8222251/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8203277 From vicente.romero at oracle.com Wed May 8 22:25:29 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 8 May 2019 18:25:29 -0400 Subject: RFR: JDK-8222795: post inc operator inside compute function of HashMap results in Exception Message-ID: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> Please review fix for regression [1] at [2]. The regression was introduced by [3] which introduced the support for switch expressions. The compiler is failing with an assertion error for code: import java.util.HashMap; import java.util.Map; public class LetExpressionAssertionTest { ??? void m() { ??????? Map m = new HashMap<>(); ??????? m.put("a",2); ??????? m.compute("a", (k, v) -> (v > 5) ? v-- : v++); ??? } } Where `v--` and `v++` are converted to let expressions. Recall that in this case `v` is of type integer so the let expressions are similar to: `(let /*synthetic*/ final Integer $373182087 = v in (let v = Integer.valueOf((int)(v.intValue() - 1)); in $373182087))` notice the cast, the ::intValue invocation etc. This patch, [3], also made some changes related to let expressions. In particular it changed a common idiom in Gen: `Assert.check(code.state.stacksize == 0);` by: Assert.check(code.isStatementStart()); where Code::isStatementStart is: public boolean isStatementStart() { return !alive ||state.stacksize ==letExprStackPos; } which is basically the same check as before, modulo the `alive` check. The problem is that at Gen::visitVarDef we had a more relaxed assertion check before [3]: Assert.check(letExprDepth != 0 || code.state.stacksize == 0); which was also substituted by: Assert.check(code.isStatementStart()); this implies a semantic change. In the old code `letExprDepth` was just a counter of "nestedness" of let expressions and the original condition in Gen::visitVarDef was mostly to check if the compiler was generating a let expression or not. Enforcing that code.state.stacksize has to be equal to the stack position of the let expression when we started generating the let expression, which is what the current assertion is checking is a too strong condition. Which can be false if, as in this case, the let expression has several method invocations inside, etc that will move the stack as get generated. This patch is proposing going back to a more relaxed assertion at Gen::visitVarDef, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8222795 [2] http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8206986 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu May 9 08:34:12 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 9 May 2019 10:34:12 +0200 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: References: Message-ID: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> Hi Bernard, I apologize for late reply. Thanks for the patch, looks OK to me, but I guess it would be good to have another review on this. Would it be possible to enhance the tests with the testcase below (and any other testcases needed)? Thanks, Jan On 27. 03. 19 19:20, B. Blaser wrote: > Hi, > > Please review the following fix for [1] which has already been > discussed in the corresponding thread [2]: > > http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.00/ > > It includes the variant I suggested to store the switch expression > result in a single temporary variable along with Jan's solution for > switch expressions used as conditions. Note that I had to do a tiny > correction to the latter (see 'code.resolve(value.trueJumps)') to make > the following example succeed: > > public static void test4() { > if (!switch (0) { > default -> { > try { > break switch(0) { default -> true; }; > } > finally { > break false; > } > } > }) { > System.out.println("OK!"); > } > } > > It also includes Jan's test case. > > Any feedback is welcome (tier1 is OK). > > Thanks, > Bernard > > [1] https://bugs.openjdk.java.net/browse/JDK-8220018 > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013073.html > From maurizio.cimadamore at oracle.com Thu May 9 12:35:24 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 May 2019 13:35:24 +0100 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> Message-ID: <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> Hi, I look at the code and discussed it offline with Jan extensively. I think the approach looks good, and it is inspired by what we already do for return expressions (where we use intermediate locals to store return expressions in case there's a finalizer). The only problem I have with this code is that it implicitly relies, in the conditional context case, on the fact that, should the finalizer complete abnormally (isAlive = false), then Code will refuse to emit any additional statements (such as the loads required to restore the stack state). I think the is brittle, and might bite us back in case we revisit this code and add another statement whose behavior is NOT guarded by isAlive. So, I suggest either adding explicit comments, saying that unwindBreak might affect isAlive and, as a result, following statements might not be generated - or, wrap the code in an explicit `if (isAlive)` guard, as done in the other branch of the visitBreak code. As bonus point, since we're restoring the stack in three different places, perhaps we can factor the restoring code out to some common function. Cheers Maurizio On 09/05/2019 09:34, Jan Lahoda wrote: > Hi Bernard, > > I apologize for late reply. Thanks for the patch, looks OK to me, but > I guess it would be good to have another review on this. > > Would it be possible to enhance the tests with the testcase below (and > any other testcases needed)? > > Thanks, > ??? Jan > > On 27. 03. 19 19:20, B. Blaser wrote: >> Hi, >> >> Please review the following fix for [1] which has already been >> discussed in the corresponding thread [2]: >> >> http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.00/ >> >> It includes the variant I suggested to store the switch expression >> result in a single temporary variable along with Jan's solution for >> switch expressions used as conditions. Note that I had to do a tiny >> correction to the latter (see 'code.resolve(value.trueJumps)') to make >> the following example succeed: >> >> ???? public static void test4() { >> ???????? if (!switch (0) { >> ???????????? default -> { >> ???????????????? try { >> ???????????????????? break switch(0) { default -> true; }; >> ???????????????? } >> ???????????????? finally { >> ???????????????????? break false; >> ???????????????? } >> ???????????? } >> ???????? }) { >> ???????????? System.out.println("OK!"); >> ???????? } >> ???? } >> >> It also includes Jan's test case. >> >> Any feedback is welcome (tier1 is OK). >> >> Thanks, >> Bernard >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8220018 >> [2] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013073.html >> From daniel.fuchs at oracle.com Thu May 9 15:23:31 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 9 May 2019 16:23:31 +0100 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Hi Christoph, I'm only commenting on the HttpClient changes, I'll let others comment on the other changes... http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html I have a profound dislike for using @SuppressedWarnings, unless it's the only alternative. My preference would be to introduce local variables, if that can make the compiler happy, until such time where the issue is actually resolved... For instance, it seems that the following would work: // Use local variable assignments to keep other java compilers // happy and avoid unchecked casts warnings BiFunction>> factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange, connection); Function>, CompletableFuture>> identity = (cf) -> cf; return c2f.handle(factory).thenCompose(identity); best regards, -- daniel On 08/05/2019 09:02, Langer, Christoph wrote: > Hi, > > please review a small change that I?d like to see in OpenJDK to get rid > of compilation errors in the Eclipse IDE. > > It seems the root cause for the compilation errors is that javac would > sometimes widen capture variables and is hence able to compile the > places that I touch here. The EC4J compiler claims that it?s following > the spec more strictly and bails out at these places. I had posted about > this on compiler-dev but got no reaction [0]. > > So, as this seems to be some field of open work for the compiler/spec > folks, I?d like to get EC4J quiesced by introducing some slight > modifications to the original places which makes the code appeal a bit > less elegant and fluent but will get rid of the compile errors. > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ > > The modification to > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > belongs to JSR-166, so I don?t know if it needs some special handling. > > Thanks & Best regards > > Christoph > > [0] > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013054.html > From jan.lahoda at oracle.com Thu May 9 15:39:06 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 9 May 2019 17:39:06 +0200 Subject: RFR: JDK-8223443: Calling Trees.getScope early changes names of local/anonymous classes Message-ID: <932af897-4fa3-d983-1a0f-d6cbdea7415d@oracle.com> Hi, In the Trees API, there is the (com.sun.source.util.)Trees.getScope method. It works by cloning the body of the enclosing method and attributing the clone, capturing the appropriate Env. There are a few issues with this method: 1. if getScope is called on an unattributed (but already entered) AST, while attributing the copy of the enclosing method, (some of) the names of the local/anonymous classes are assigned to the copy, and then not reused when actually attributing the real AST and generating classfiles. So calling getScope "early" may lead to generating different classfiles with different names for the local/anonymous classes. This can be fixed by un-entering the classes (which is already done in DeferredAttr). 2. the binary names of the TypeElements for local/anonymous classes in the returned Scope do not match those from the real AST. This can be fixed by assigning the correct flat/binary names to the returned ClassSymbols. 3. if there are (compile-time) errors in the enclosing method, these may be reported during this attribution for getScope. This can be fixed by ignoring errors reported from the attribution for getScope. The proposed fix for these is here: http://cr.openjdk.java.net/~jlahoda/8223443/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8223443 How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Thu May 9 18:15:52 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 9 May 2019 11:15:52 -0700 Subject: RFR: [simple,docs] JDK-8223654: Clean up @jls references in com.sun.source Message-ID: <63aa4310-aecb-b8db-9942-993c31abc114@oracle.com> Please review a simple update to the `@jls` tags in the docs for classes in the com.sun.source.tree API, to being them into stylistic consistency with other uses of `@jls` and `@jvms` elsewhere in the JDK docs. This will facilitate checking these tags for accuracy, and/or linking to the relevant sections of the specs. There's no semantic change here, so no CSR. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8223654 Webrev: http://cr.openjdk.java.net/~jjg/8223654/webrev.00/ From christoph.langer at sap.com Fri May 10 09:17:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 10 May 2019 09:17:29 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Hi Daniel, I fully agree, @SuppressWarnings should be avoided wherever possible. So, thanks for coming up with this alternative suggestion. It works and so I updated my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/ Any reviews for the other 3 files? Thanks Christoph > -----Original Message----- > From: Daniel Fuchs > Sent: Donnerstag, 9. Mai 2019 17:24 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; net-dev > Cc: compiler-dev at openjdk.java.net > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the > Eclipse Java Compiler > > Hi Christoph, > > I'm only commenting on the HttpClient changes, I'll let > others comment on the other changes... > > http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/s > hare/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html > > I have a profound dislike for using @SuppressedWarnings, unless > it's the only alternative. My preference would be to introduce > local variables, if that can make the compiler happy, until such time > where the issue is actually resolved... > > For instance, it seems that the following would work: > > // Use local variable assignments to keep other java compilers > // happy and avoid unchecked casts warnings > BiFunction ExchangeImpl>> > factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange, > connection); > Function>, > CompletableFuture>> > identity = (cf) -> cf; > return c2f.handle(factory).thenCompose(identity); > > > best regards, > > -- daniel > > On 08/05/2019 09:02, Langer, Christoph wrote: > > Hi, > > > > please review a small change that I'd like to see in OpenJDK to get rid > > of compilation errors in the Eclipse IDE. > > > > It seems the root cause for the compilation errors is that javac would > > sometimes widen capture variables and is hence able to compile the > > places that I touch here. The EC4J compiler claims that it's following > > the spec more strictly and bails out at these places. I had posted about > > this on compiler-dev but got no reaction [0]. > > > > So, as this seems to be some field of open work for the compiler/spec > > folks, I'd like to get EC4J quiesced by introducing some slight > > modifications to the original places which makes the code appeal a bit > > less elegant and fluent but will get rid of the compile errors. > > > > Please review: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ > > > > The modification to > > > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav > a > > belongs to JSR-166, so I don't know if it needs some special handling. > > > > Thanks & Best regards > > > > Christoph > > > > [0] > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019- > March/013054.html > > From joe.darcy at oracle.com Fri May 10 18:40:09 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 May 2019 11:40:09 -0700 Subject: RFR: [simple,docs] JDK-8223654: Clean up @jls references in com.sun.source In-Reply-To: <63aa4310-aecb-b8db-9942-993c31abc114@oracle.com> References: <63aa4310-aecb-b8db-9942-993c31abc114@oracle.com> Message-ID: <835a1275-d101-a511-7895-169b194228e5@oracle.com> Looks good Jon; cheers, -Joe On 5/9/2019 11:15 AM, Jonathan Gibbons wrote: > Please review a simple update to the `@jls` tags in the docs for > classes in the com.sun.source.tree API, to being them into stylistic > consistency with other uses of `@jls` and `@jvms` elsewhere in the JDK > docs. This will facilitate checking these tags for accuracy, and/or > linking to the relevant sections of the specs. > > There's no semantic change here, so no CSR. > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223654 > Webrev: http://cr.openjdk.java.net/~jjg/8223654/webrev.00/ > > From bsrbnd at gmail.com Sat May 11 11:29:53 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 11 May 2019 13:29:53 +0200 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> Message-ID: Hi Jan and Maurizio, Thanks for both feedback. On Thu, 9 May 2019 at 14:35, Maurizio Cimadamore wrote: > > Hi, > I look at the code and discussed it offline with Jan extensively. > > I think the approach looks good, and it is inspired by what we already > do for return expressions (where we use intermediate locals to store > return expressions in case there's a finalizer). > > The only problem I have with this code is that it implicitly relies, in > the conditional context case, on the fact that, should the finalizer > complete abnormally (isAlive = false), then Code will refuse to emit any > additional statements (such as the loads required to restore the stack > state). > > I think the is brittle, and might bite us back in case we revisit this > code and add another statement whose behavior is NOT guarded by isAlive. > > So, I suggest either adding explicit comments, saying that unwindBreak > might affect isAlive and, as a result, following statements might not be > generated - or, wrap the code in an explicit `if (isAlive)` guard, as > done in the other branch of the visitBreak code. As first step, I guess I'd be more for simply adding a comment but we can still rework and consolidate this part later on if necessary. > As bonus point, since > we're restoring the stack in three different places, perhaps we can > factor the restoring code out to some common function. Of course ;-) > Cheers > Maurizio > > > On 09/05/2019 09:34, Jan Lahoda wrote: > > Hi Bernard, > > > > I apologize for late reply. No problem, I'm rather busy too... > > Thanks for the patch, looks OK to me, but > > I guess it would be good to have another review on this. > > > > Would it be possible to enhance the tests with the testcase below (and > > any other testcases needed)? Yes, I'll also include this one. Cheers, Bernard > > Thanks, > > Jan > > > > On 27. 03. 19 19:20, B. Blaser wrote: > >> Hi, > >> > >> Please review the following fix for [1] which has already been > >> discussed in the corresponding thread [2]: > >> > >> http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.00/ > >> > >> It includes the variant I suggested to store the switch expression > >> result in a single temporary variable along with Jan's solution for > >> switch expressions used as conditions. Note that I had to do a tiny > >> correction to the latter (see 'code.resolve(value.trueJumps)') to make > >> the following example succeed: > >> > >> public static void test4() { > >> if (!switch (0) { > >> default -> { > >> try { > >> break switch(0) { default -> true; }; > >> } > >> finally { > >> break false; > >> } > >> } > >> }) { > >> System.out.println("OK!"); > >> } > >> } > >> > >> It also includes Jan's test case. > >> > >> Any feedback is welcome (tier1 is OK). > >> > >> Thanks, > >> Bernard > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8220018 > >> [2] > >> http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013073.html > >> From bsrbnd at gmail.com Sat May 11 14:11:34 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 11 May 2019 16:11:34 +0200 Subject: RFR: JDK-8222795: post inc operator inside compute function of HashMap results in Exception In-Reply-To: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> References: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> Message-ID: Hi Vicente, I worked on postfix unary operators long time ago and I believe your fix looks reasonable. However, the need of relaxing the assertion as you suggested is still tickling me a bit because 'visitLetExpr()' seems to correctly set the start position: http://hg.openjdk.java.net/jdk/jdk/file/fcf83b204c27/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java#l2313 which should be sufficient for this particular let-expression. Does the problem come from the conditional expression? Bernard On Thu, 9 May 2019 at 00:26, Vicente Romero wrote: > > Please review fix for regression [1] at [2]. The regression was introduced by [3] which introduced the support for switch expressions. The compiler is failing with an assertion error for code: > > import java.util.HashMap; > import java.util.Map; > > public class LetExpressionAssertionTest { > void m() { > Map m = new HashMap<>(); > m.put("a",2); > m.compute("a", (k, v) -> (v > 5) ? v-- : v++); > } > } > > Where `v--` and `v++` are converted to let expressions. Recall that in this case `v` is of type integer so the let expressions are similar to: > > `(let /*synthetic*/ final Integer $373182087 = v in (let v = Integer.valueOf((int)(v.intValue() - 1)); in $373182087))` > > notice the cast, the ::intValue invocation etc. > > This patch, [3], also made some changes related to let expressions. In particular it changed a common idiom in Gen: > > `Assert.check(code.state.stacksize == 0);` by: > Assert.check(code.isStatementStart()); > > where Code::isStatementStart is: > > public boolean isStatementStart() { > return !alive || state.stacksize == letExprStackPos; > } > > which is basically the same check as before, modulo the `alive` check. The problem is that at Gen::visitVarDef we had a more relaxed assertion check before [3]: > > Assert.check(letExprDepth != 0 || code.state.stacksize == 0); which was also substituted by: > Assert.check(code.isStatementStart()); > > this implies a semantic change. In the old code `letExprDepth` was just a counter of "nestedness" of let expressions and the original condition in Gen::visitVarDef was mostly to check if the compiler was generating a let expression or not. Enforcing that code.state.stacksize has to be equal to the stack position of the let expression when we started generating the let expression, which is what the current assertion is checking is a too strong condition. Which can be false if, as in this case, the let expression has several method invocations inside, etc that will move the stack as get generated. This patch is proposing going back to a more relaxed assertion at Gen::visitVarDef, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8222795 > [2] http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8206986 From christoph.langer at sap.com Mon May 13 07:29:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 13 May 2019 07:29:28 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Hi Daniel, unfortunately, your proposed solution does not work with javac. I get this in the build: ...\mercurial\jdk\src\java.net.http\share\classes\jdk\internal\net\http\ExchangeImpl.java:103: error: method thenCompose in class CompletableFuture cannot be applied to given types; return c2f.handle(factory).thenCompose(identity); ^ required: Function>,? extends CompletionStage> found: Function>,CompletableFuture>> reason: cannot infer type-variable(s) U#2 (argument mismatch; Function>,CompletableFuture>> cannot be converted to Function>,? extends CompletionStage>) where U#1,U#2,T are type-variables: U#1 extends Object declared in method get(Exchange,HttpConnection) U#2 extends Object declared in method thenCompose(Function>) T extends Object declared in class CompletableFuture 1 error So I think we need to go back to my initial proposal which works for both, IDE and javac: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ Thanks Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 10. Mai 2019 11:17 > To: Daniel Fuchs ; core-libs-dev dev at openjdk.java.net>; net-dev > Cc: compiler-dev at openjdk.java.net > Subject: RE: RFR: 8223553: Fix code constructs that do not compile with the > Eclipse Java Compiler > > Hi Daniel, > > I fully agree, @SuppressWarnings should be avoided wherever possible. > > So, thanks for coming up with this alternative suggestion. It works and so I > updated my webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8223553.1/ > > Any reviews for the other 3 files? > > Thanks > Christoph > > > -----Original Message----- > > From: Daniel Fuchs > > Sent: Donnerstag, 9. Mai 2019 17:24 > > To: Langer, Christoph ; core-libs-dev libs- > > dev at openjdk.java.net>; net-dev > > Cc: compiler-dev at openjdk.java.net > > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the > > Eclipse Java Compiler > > > > Hi Christoph, > > > > I'm only commenting on the HttpClient changes, I'll let > > others comment on the other changes... > > > > > http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/s > > hare/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html > > > > I have a profound dislike for using @SuppressedWarnings, unless > > it's the only alternative. My preference would be to introduce > > local variables, if that can make the compiler happy, until such time > > where the issue is actually resolved... > > > > For instance, it seems that the following would work: > > > > // Use local variable assignments to keep other java compilers > > // happy and avoid unchecked casts warnings > > BiFunction > ExchangeImpl>> > > factory = (h2c, t) -> createExchangeImpl(h2c, t, exchange, > > connection); > > Function>, > > CompletableFuture>> > > identity = (cf) -> cf; > > return c2f.handle(factory).thenCompose(identity); > > > > > > best regards, > > > > -- daniel > > > > On 08/05/2019 09:02, Langer, Christoph wrote: > > > Hi, > > > > > > please review a small change that I'd like to see in OpenJDK to get rid > > > of compilation errors in the Eclipse IDE. > > > > > > It seems the root cause for the compilation errors is that javac would > > > sometimes widen capture variables and is hence able to compile the > > > places that I touch here. The EC4J compiler claims that it's following > > > the spec more strictly and bails out at these places. I had posted about > > > this on compiler-dev but got no reaction [0]. > > > > > > So, as this seems to be some field of open work for the compiler/spec > > > folks, I'd like to get EC4J quiesced by introducing some slight > > > modifications to the original places which makes the code appeal a bit > > > less elegant and fluent but will get rid of the compile errors. > > > > > > Please review: > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223553 > > > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ > > > > > > The modification to > > > > > > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav > > a > > > belongs to JSR-166, so I don't know if it needs some special handling. > > > > > > Thanks & Best regards > > > > > > Christoph > > > > > > [0] > > > https://mail.openjdk.java.net/pipermail/compiler-dev/2019- > > March/013054.html > > > From daniel.fuchs at oracle.com Mon May 13 09:34:02 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 May 2019 10:34:02 +0100 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Hi Christoph, On 13/05/2019 08:29, Langer, Christoph wrote: > Hi Daniel, > > unfortunately, your proposed solution does not work with javac. I get this in the build: Oh darn. I should have double checked. Can we at least reduce the scope of the @SuppressedWarnings by introducing a private method that just has the return call? best regards, -- daniel > > ...\mercurial\jdk\src\java.net.http\share\classes\jdk\internal\net\http\ExchangeImpl.java:103: error: method thenCompose in class CompletableFuture cannot be applied to given types; > return c2f.handle(factory).thenCompose(identity); > ^ > required: Function>,? extends CompletionStage> > found: Function>,CompletableFuture>> > reason: cannot infer type-variable(s) U#2 > (argument mismatch; Function>,CompletableFuture>> cannot be converted to Function>,? extends CompletionStage>) > where U#1,U#2,T are type-variables: > U#1 extends Object declared in method get(Exchange,HttpConnection) > U#2 extends Object declared in method thenCompose(Function>) > T extends Object declared in class CompletableFuture > 1 error > > So I think we need to go back to my initial proposal which works for both, IDE and javac:http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/ > > Thanks > Christoph From jan.lahoda at oracle.com Mon May 13 13:02:18 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 13 May 2019 15:02:18 +0200 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CD085AE.4050008@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> <5CD085AE.4050008@oracle.com> Message-ID: Thanks Alex! Could I please get a review on the CSR? https://bugs.openjdk.java.net/browse/JDK-8222396 And also on the patch: http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ Thanks! Jan On 06. 05. 19 21:06, Alex Buckley wrote: > On 4/12/2019 12:03 PM, Alex Buckley wrote: >> On 4/12/2019 5:34 AM, Jan Lahoda wrote: >>> I've started with the CSR here: >>> https://bugs.openjdk.java.net/browse/JDK-8222396 >> >> Looks pretty good. I made some edits to record both of your >> single-module and multi-module invocations of javac. >> >> The use case of injecting test code is clear, but the exact connection >> between automatic modules and test code is pretty opaque. Is the goal to >> make the automatic test module read the explicit test module so that the >> former module's code can access the latter module's code? Is the goal to >> make the automatic module read (and therefore test) at least the same >> set of modules as the explicit modules `requires`? > > Reviewing the CSR again, it seemed like the key scenario is multiple > named modules, where for each named module: > > 1. We don't really care about its relationship with the other named > modules; but > > 2. We do care about injecting it with test code, and letting that test > code read other, completely arbitrary, modules (say, an > assertion-building library that's been placed on the module path). > > I have refactored the CSR to more strongly separate the problem > (patching an automatic module is possible, but readability is sub-par) > from the solution (precedent for ALL-MODULE-PATH from the unnamed module > scenario). > > JEP 261 should be updated to explain the awesome power of --patch-module > at compile time, and that is progressing behind the scenes, but I don't > think it needs to block JDK-8220702 -- the CSR is "good enough" > documentation for now. > > Alex From alex.buckley at oracle.com Mon May 13 16:02:45 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 13 May 2019 09:02:45 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> <5CD085AE.4050008@oracle.com> Message-ID: <5CD99525.10501@oracle.com> On 5/13/2019 6:02 AM, Jan Lahoda wrote: > Could I please get a review on the CSR? > > https://bugs.openjdk.java.net/browse/JDK-8222396 Added myself as a reviewer. Alex > And also on the patch: > http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ > > Thanks! > > Jan > > On 06. 05. 19 21:06, Alex Buckley wrote: >> On 4/12/2019 12:03 PM, Alex Buckley wrote: >>> On 4/12/2019 5:34 AM, Jan Lahoda wrote: >>>> I've started with the CSR here: >>>> https://bugs.openjdk.java.net/browse/JDK-8222396 >>> >>> Looks pretty good. I made some edits to record both of your >>> single-module and multi-module invocations of javac. >>> >>> The use case of injecting test code is clear, but the exact connection >>> between automatic modules and test code is pretty opaque. Is the goal to >>> make the automatic test module read the explicit test module so that the >>> former module's code can access the latter module's code? Is the goal to >>> make the automatic module read (and therefore test) at least the same >>> set of modules as the explicit modules `requires`? >> >> Reviewing the CSR again, it seemed like the key scenario is multiple >> named modules, where for each named module: >> >> 1. We don't really care about its relationship with the other named >> modules; but >> >> 2. We do care about injecting it with test code, and letting that test >> code read other, completely arbitrary, modules (say, an >> assertion-building library that's been placed on the module path). >> >> I have refactored the CSR to more strongly separate the problem >> (patching an automatic module is possible, but readability is sub-par) >> from the solution (precedent for ALL-MODULE-PATH from the unnamed >> module scenario). >> >> JEP 261 should be updated to explain the awesome power of >> --patch-module at compile time, and that is progressing behind the >> scenes, but I don't think it needs to block JDK-8220702 -- the CSR is >> "good enough" documentation for now. >> >> Alex From vicente.romero at oracle.com Mon May 13 22:07:55 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 13 May 2019 18:07:55 -0400 Subject: RFR: JDK-8222795: post inc operator inside compute function of HashMap results in Exception In-Reply-To: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> References: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> Message-ID: <14aadcd9-5459-b9cb-7557-d843bfeff446@oracle.com> ping, Thanks, Vicente On 5/8/19 6:25 PM, Vicente Romero wrote: > Please review fix for regression [1] at [2]. The regression was > introduced by [3] which introduced the support for switch expressions. > The compiler is failing with an assertion error for code: > > import java.util.HashMap; > import java.util.Map; > > public class LetExpressionAssertionTest { > ??? void m() { > ??????? Map m = new HashMap<>(); > ??????? m.put("a",2); > ??????? m.compute("a", (k, v) -> (v > 5) ? v-- : v++); > ??? } > } > > Where `v--` and `v++` are converted to let expressions. Recall that in > this case `v` is of type integer so the let expressions are similar to: > > `(let /*synthetic*/ final Integer $373182087 = v in (let v = > Integer.valueOf((int)(v.intValue() - 1)); in $373182087))` > > notice the cast, the ::intValue invocation etc. > > This patch, [3], also made some changes related to let expressions. In > particular it changed a common idiom in Gen: > > `Assert.check(code.state.stacksize == 0);` by: > Assert.check(code.isStatementStart()); > > where Code::isStatementStart is: > public boolean isStatementStart() { > return !alive ||state.stacksize ==letExprStackPos; > } > which is basically the same check as before, modulo the `alive` check. > The problem is that at Gen::visitVarDef we had a more relaxed > assertion check before [3]: > > Assert.check(letExprDepth != 0 || code.state.stacksize == 0); which > was also substituted by: > Assert.check(code.isStatementStart()); > > this implies a semantic change. In the old code `letExprDepth` was > just a counter of "nestedness" of let expressions and the original > condition in Gen::visitVarDef was mostly to check if the compiler was > generating a let expression or not. Enforcing that > code.state.stacksize has to be equal to the stack position of the let > expression when we started generating the let expression, which is > what the current assertion is checking is a too strong condition. > Which can be false if, as in this case, the let expression has several > method invocations inside, etc that will move the stack as get > generated. This patch is proposing going back to a more relaxed > assertion at Gen::visitVarDef, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8222795 > [2] http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8206986 -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue May 14 12:57:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 May 2019 12:57:07 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Hi Daniel, > > unfortunately, your proposed solution does not work with javac. I get this > in the build: > > Oh darn. I should have double checked. > Can we at least reduce the scope of the @SuppressedWarnings by > introducing a private method that just has the return call? Sure, what about this one: http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ? Thanks Christoph From vicente.romero at oracle.com Tue May 14 13:38:33 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 14 May 2019 09:38:33 -0400 Subject: RFR: JDK-8222795: post inc operator inside compute function of HashMap results in Exception In-Reply-To: References: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> Message-ID: <9e385c17-6b3b-d512-2a73-28a2c893a3d6@oracle.com> Hi Bernard, Thanks for your feedback, On 5/11/19 10:11 AM, B. Blaser wrote: > Hi Vicente, > > I worked on postfix unary operators long time ago and I believe your > fix looks reasonable. > > However, the need of relaxing the assertion as you suggested is still > tickling me a bit because 'visitLetExpr()' seems to correctly set the > start position: > http://hg.openjdk.java.net/jdk/jdk/file/fcf83b204c27/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java#l2313 > which should be sufficient for this particular let-expression. > > Does the problem come from the conditional expression? I believe that the need for relaxing the current assertion: Assert.check(code.isStatementStart()); comes from the definition of Code::isStatementStart which is checking against field: Code::letExprStackPos which in this case is set when Gen starts handling the let expression, Gen::visitLetExpr, but in this case the let expressions contain subexpressions that alter the stack pos, method invocations etc. To me it is too strict to expect at Gen::visitVarDef that the stack position will be the same as it was when Gen started generating the let expression. And I think this was the reason why this condition was more relaxed in the code previous to the switch expression patch. Thanks, Vicente > Bernard > > > On Thu, 9 May 2019 at 00:26, Vicente Romero wrote: >> Please review fix for regression [1] at [2]. The regression was introduced by [3] which introduced the support for switch expressions. The compiler is failing with an assertion error for code: >> >> import java.util.HashMap; >> import java.util.Map; >> >> public class LetExpressionAssertionTest { >> void m() { >> Map m = new HashMap<>(); >> m.put("a",2); >> m.compute("a", (k, v) -> (v > 5) ? v-- : v++); >> } >> } >> >> Where `v--` and `v++` are converted to let expressions. Recall that in this case `v` is of type integer so the let expressions are similar to: >> >> `(let /*synthetic*/ final Integer $373182087 = v in (let v = Integer.valueOf((int)(v.intValue() - 1)); in $373182087))` >> >> notice the cast, the ::intValue invocation etc. >> >> This patch, [3], also made some changes related to let expressions. In particular it changed a common idiom in Gen: >> >> `Assert.check(code.state.stacksize == 0);` by: >> Assert.check(code.isStatementStart()); >> >> where Code::isStatementStart is: >> >> public boolean isStatementStart() { >> return !alive || state.stacksize == letExprStackPos; >> } >> >> which is basically the same check as before, modulo the `alive` check. The problem is that at Gen::visitVarDef we had a more relaxed assertion check before [3]: >> >> Assert.check(letExprDepth != 0 || code.state.stacksize == 0); which was also substituted by: >> Assert.check(code.isStatementStart()); >> >> this implies a semantic change. In the old code `letExprDepth` was just a counter of "nestedness" of let expressions and the original condition in Gen::visitVarDef was mostly to check if the compiler was generating a let expression or not. Enforcing that code.state.stacksize has to be equal to the stack position of the let expression when we started generating the let expression, which is what the current assertion is checking is a too strong condition. Which can be false if, as in this case, the let expression has several method invocations inside, etc that will move the stack as get generated. This patch is proposing going back to a more relaxed assertion at Gen::visitVarDef, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8222795 >> [2] http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8206986 From jan.lahoda at oracle.com Tue May 14 14:19:43 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 14 May 2019 16:19:43 +0200 Subject: RFR: JDK-8222795: post inc operator inside compute function of HashMap results in Exception In-Reply-To: <14aadcd9-5459-b9cb-7557-d843bfeff446@oracle.com> References: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> <14aadcd9-5459-b9cb-7557-d843bfeff446@oracle.com> Message-ID: <3aa3257e-474b-c3c5-0bef-a34e7fce003d@oracle.com> Hi Vicente, This looks very similar to: JDK-8222169 https://bugs.openjdk.java.net/browse/JDK-8222169 I think the main issue here is that the stack size gets recorded in visitLetExpr, but the recorded stack size is wrong: there is a jump pending (the jump when "v > 5" is false, that jumps over the "v--" into "v++"), and when the jump is eventually resolved (in Code.addLocalVar in this case, probably) these will change (reduce) the stack size, and the asserts will fail. My plan for JDK-8222169 was to do "code.resolvePending();" at the beginning of Gen.visitLetExpr, which should ensure the recorded stack size is correct. I apologize for introducing this problem. Thanks, Jan On 14. 05. 19 0:07, Vicente Romero wrote: > ping, > > Thanks, > Vicente > > On 5/8/19 6:25 PM, Vicente Romero wrote: >> Please review fix for regression [1] at [2]. The regression was >> introduced by [3] which introduced the support for switch expressions. >> The compiler is failing with an assertion error for code: >> >> import java.util.HashMap; >> import java.util.Map; >> >> public class LetExpressionAssertionTest { >> ??? void m() { >> ??????? Map m = new HashMap<>(); >> ??????? m.put("a",2); >> ??????? m.compute("a", (k, v) -> (v > 5) ? v-- : v++); >> ??? } >> } >> >> Where `v--` and `v++` are converted to let expressions. Recall that in >> this case `v` is of type integer so the let expressions are similar to: >> >> `(let /*synthetic*/ final Integer $373182087 = v in (let v = >> Integer.valueOf((int)(v.intValue() - 1)); in $373182087))` >> >> notice the cast, the ::intValue invocation etc. >> >> This patch, [3], also made some changes related to let expressions. In >> particular it changed a common idiom in Gen: >> >> `Assert.check(code.state.stacksize == 0);` by: >> Assert.check(code.isStatementStart()); >> >> where Code::isStatementStart is: >> public boolean isStatementStart() { >> return !alive ||state.stacksize ==letExprStackPos; >> } >> which is basically the same check as before, modulo the `alive` check. >> The problem is that at Gen::visitVarDef we had a more relaxed >> assertion check before [3]: >> >> Assert.check(letExprDepth != 0 || code.state.stacksize == 0); which >> was also substituted by: >> Assert.check(code.isStatementStart()); >> >> this implies a semantic change. In the old code `letExprDepth` was >> just a counter of "nestedness" of let expressions and the original >> condition in Gen::visitVarDef was mostly to check if the compiler was >> generating a let expression or not. Enforcing that >> code.state.stacksize has to be equal to the stack position of the let >> expression when we started generating the let expression, which is >> what the current assertion is checking is a too strong condition. >> Which can be false if, as in this case, the let expression has several >> method invocations inside, etc that will move the stack as get >> generated. This patch is proposing going back to a more relaxed >> assertion at Gen::visitVarDef, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8222795 >> [2] http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8206986 > From vicente.romero at oracle.com Tue May 14 15:39:08 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 14 May 2019 11:39:08 -0400 Subject: RFR: JDK-8222795: post inc operator inside compute function of HashMap results in Exception In-Reply-To: <3aa3257e-474b-c3c5-0bef-a34e7fce003d@oracle.com> References: <99b4af91-7c63-c02f-7040-ffd586af73c4@oracle.com> <14aadcd9-5459-b9cb-7557-d843bfeff446@oracle.com> <3aa3257e-474b-c3c5-0bef-a34e7fce003d@oracle.com> Message-ID: Hi Jan, I have closed my bug as a duplicate of JDK-8222169, Thanks for the clarification, Vicente On 5/14/19 10:19 AM, Jan Lahoda wrote: > Hi Vicente, > > This looks very similar to: > JDK-8222169 > https://bugs.openjdk.java.net/browse/JDK-8222169 > > I think the main issue here is that the stack size gets recorded in > visitLetExpr, but the recorded stack size is wrong: there is a jump > pending (the jump when "v > 5" is false, that jumps over the "v--" > into "v++"), and when the jump is eventually resolved (in > Code.addLocalVar in this case, probably) these will change (reduce) > the stack size, and the asserts will fail. > > My plan for JDK-8222169 was to do "code.resolvePending();" at the > beginning of Gen.visitLetExpr, which should ensure the recorded stack > size is correct. > > I apologize for introducing this problem. > > Thanks, > ??? Jan > > On 14. 05. 19 0:07, Vicente Romero wrote: >> ping, >> >> Thanks, >> Vicente >> >> On 5/8/19 6:25 PM, Vicente Romero wrote: >>> Please review fix for regression [1] at [2]. The regression was >>> introduced by [3] which introduced the support for switch >>> expressions. The compiler is failing with an assertion error for code: >>> >>> import java.util.HashMap; >>> import java.util.Map; >>> >>> public class LetExpressionAssertionTest { >>> ??? void m() { >>> ??????? Map m = new HashMap<>(); >>> ??????? m.put("a",2); >>> ??????? m.compute("a", (k, v) -> (v > 5) ? v-- : v++); >>> ??? } >>> } >>> >>> Where `v--` and `v++` are converted to let expressions. Recall that >>> in this case `v` is of type integer so the let expressions are >>> similar to: >>> >>> `(let /*synthetic*/ final Integer $373182087 = v in (let v = >>> Integer.valueOf((int)(v.intValue() - 1)); in $373182087))` >>> >>> notice the cast, the ::intValue invocation etc. >>> >>> This patch, [3], also made some changes related to let expressions. >>> In particular it changed a common idiom in Gen: >>> >>> `Assert.check(code.state.stacksize == 0);` by: >>> Assert.check(code.isStatementStart()); >>> >>> where Code::isStatementStart is: >>> public boolean isStatementStart() { >>> ???? return !alive ||state.stacksize ==letExprStackPos; >>> } >>> which is basically the same check as before, modulo the `alive` >>> check. The problem is that at Gen::visitVarDef we had a more relaxed >>> assertion check before [3]: >>> >>> Assert.check(letExprDepth != 0 || code.state.stacksize == 0); which >>> was also substituted by: >>> Assert.check(code.isStatementStart()); >>> >>> this implies a semantic change. In the old code `letExprDepth` was >>> just a counter of "nestedness" of let expressions and the original >>> condition in Gen::visitVarDef was mostly to check if the compiler >>> was generating a let expression or not. Enforcing that >>> code.state.stacksize has to be equal to the stack position of the >>> let expression when we started generating the let expression, which >>> is what the current assertion is checking is a too strong condition. >>> Which can be false if, as in this case, the let expression has >>> several method invocations inside, etc that will move the stack as >>> get generated. This patch is proposing going back to a more relaxed >>> assertion at Gen::visitVarDef, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8222795 >>> [2] http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ >>> [3] https://bugs.openjdk.java.net/browse/JDK-8206986 >> From daniel.fuchs at oracle.com Tue May 14 16:03:45 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 May 2019 17:03:45 +0100 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Hi Christoph, That looks much better, thanks! (but still not commenting on the other changes ;-)) best regards, -- daniel On 14/05/2019 13:57, Langer, Christoph wrote: > Hi Daniel, > >>> unfortunately, your proposed solution does not work with javac. I get this >> in the build: >> >> Oh darn. I should have double checked. >> Can we at least reduce the scope of the @SuppressedWarnings by >> introducing a private method that just has the return call? > > Sure, what about this one: http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ? > > Thanks > Christoph > From christoph.langer at sap.com Tue May 14 21:03:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 May 2019 21:03:47 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: Thanks Daniel. Can anybody help reviewing the changes to: src/java.base/share/classes/java/lang/invoke/MethodHandles.java src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java and src/java.management/share/classes/java/lang/management/ManagementFactory.java ? Thanks Christoph > -----Original Message----- > From: Daniel Fuchs > Sent: Dienstag, 14. Mai 2019 18:04 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; net-dev > Cc: compiler-dev at openjdk.java.net > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the > Eclipse Java Compiler > > Hi Christoph, > > That looks much better, thanks! > (but still not commenting on the other changes ;-)) > > best regards, > > -- daniel > > On 14/05/2019 13:57, Langer, Christoph wrote: > > Hi Daniel, > > > >>> unfortunately, your proposed solution does not work with javac. I get > this > >> in the build: > >> > >> Oh darn. I should have double checked. > >> Can we at least reduce the scope of the @SuppressedWarnings by > >> introducing a private method that just has the return call? > > > > Sure, what about this one: > http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ? > > > > Thanks > > Christoph > > From david.holmes at oracle.com Tue May 14 22:05:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 08:05:20 +1000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: Message-ID: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> Hi Christoph, I'm very reluctant to see changes like this that the compiler folk have not determined are actually incorrect. That said ... On 15/05/2019 7:03 am, Langer, Christoph wrote: > Thanks Daniel. > > Can anybody help reviewing the changes to: > src/java.base/share/classes/java/lang/invoke/MethodHandles.java The introduction of the intermediate local variable seems harmless (though why it should be necessary is another matter). > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java As you note this should be ok'd by jsr166 folk so I've cc'd Martin Buccholz. I dislike seeing a raw type introduced here though. > and > src/java.management/share/classes/java/lang/management/ManagementFactory.java ? Introducing an unchecked cast seems very crude. I'd want the core-libs stream experts to comment on this. Cheers, David ---- > Thanks > Christoph > >> -----Original Message----- >> From: Daniel Fuchs >> Sent: Dienstag, 14. Mai 2019 18:04 >> To: Langer, Christoph ; core-libs-dev > dev at openjdk.java.net>; net-dev >> Cc: compiler-dev at openjdk.java.net >> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the >> Eclipse Java Compiler >> >> Hi Christoph, >> >> That looks much better, thanks! >> (but still not commenting on the other changes ;-)) >> >> best regards, >> >> -- daniel >> >> On 14/05/2019 13:57, Langer, Christoph wrote: >>> Hi Daniel, >>> >>>>> unfortunately, your proposed solution does not work with javac. I get >> this >>>> in the build: >>>> >>>> Oh darn. I should have double checked. >>>> Can we at least reduce the scope of the @SuppressedWarnings by >>>> introducing a private method that just has the return call? >>> >>> Sure, what about this one: >> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ? >>> >>> Thanks >>> Christoph >>> > From martinrb at google.com Wed May 15 04:16:33 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 14 May 2019 21:16:33 -0700 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> Message-ID: I feel the same as David - reluctant to change anything. Introducing a raw type makes an ugly cast uglier. *From: *David Holmes > > > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > > As you note this should be ok'd by jsr166 folk so I've cc'd Martin > Buccholz. I dislike seeing a raw type introduced here though. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed May 15 08:05:13 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 15 May 2019 10:05:13 +0200 Subject: RFR: JDK-8222169: java.lang.AssertionError switch expression in ternary operator - ? Message-ID: <26b45ff0-84e0-8e3d-7df7-da5b6d6d7553@oracle.com> Hi, There is a regression in how let expressions are handled in Gen, related to recent changes for switch expressions. Consider code like: int t(boolean b, Integer i) { return b ? 0 : i++; } This gets desugared into: int t(boolean b, Integer i) { return b ? 0 : (let /*synthetic*/ final Integer $1357563986 = i in (let i = Integer.valueOf((int)(i.intValue() + 1)); in $1357563986)).intValue(); } When Gen.visitLetExpr is generating the let expression, it records the stack size, so that for further statements, it can assert the statements start at an appropriate stack depth (at "statement start"). But, the issue here is that when the stack size is recorded, the state of the bytecode is before the target of the jump for "b == false", which jumps to the "else" section. I.e. the state of the bytecode is before the ':', not after. And so '0' is on the stack. But, the code for the let expression is after the target of the jump, and so the real stack at the beginning of the code for the let expression is empty. The proposed solution is to simply resolve the jumps before recording the size of the stack - that should ensure the correct stack size is recorded. We already do that for Gen.visitSwitchExpression, but missed it for visitLetExpr. Webrev: http://cr.openjdk.java.net/~jlahoda/8222169/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8222169 The patch also includes test based on Vicente's: http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ How does this look? Thanks, Jan From christoph.langer at sap.com Wed May 15 13:59:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 15 May 2019 13:59:08 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> Message-ID: Hi David, Martin, thanks for looking into this. Generally I share your view on this. It's not nice at all. However, it's the only way I can see currently to get rid of the Errors in the Eclipse IDE. Maybe an idea would be to get this in but at the same time open a ticket to evaluate this code again from a compiler/spec perspective and make the according modifications? Thanks Christoph > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 15. Mai 2019 00:05 > To: Langer, Christoph ; Daniel Fuchs > ; core-libs-dev dev at openjdk.java.net>; net-dev > Cc: compiler-dev at openjdk.java.net; Martin Buchholz > > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the > Eclipse Java Compiler > > Hi Christoph, > > I'm very reluctant to see changes like this that the compiler folk have > not determined are actually incorrect. That said ... > > On 15/05/2019 7:03 am, Langer, Christoph wrote: > > Thanks Daniel. > > > > Can anybody help reviewing the changes to: > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java > > The introduction of the intermediate local variable seems harmless > (though why it should be necessary is another matter). > > > > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav > a > > As you note this should be ok'd by jsr166 folk so I've cc'd Martin > Buccholz. I dislike seeing a raw type introduced here though. > > > and > > > src/java.management/share/classes/java/lang/management/ManagementF > actory.java ? > > Introducing an unchecked cast seems very crude. I'd want the core-libs > stream experts to comment on this. > > Cheers, > David > ---- > > > Thanks > > Christoph > > > >> -----Original Message----- > >> From: Daniel Fuchs > >> Sent: Dienstag, 14. Mai 2019 18:04 > >> To: Langer, Christoph ; core-libs-dev libs- > >> dev at openjdk.java.net>; net-dev > >> Cc: compiler-dev at openjdk.java.net > >> Subject: Re: RFR: 8223553: Fix code constructs that do not compile with > the > >> Eclipse Java Compiler > >> > >> Hi Christoph, > >> > >> That looks much better, thanks! > >> (but still not commenting on the other changes ;-)) > >> > >> best regards, > >> > >> -- daniel > >> > >> On 14/05/2019 13:57, Langer, Christoph wrote: > >>> Hi Daniel, > >>> > >>>>> unfortunately, your proposed solution does not work with javac. I get > >> this > >>>> in the build: > >>>> > >>>> Oh darn. I should have double checked. > >>>> Can we at least reduce the scope of the @SuppressedWarnings by > >>>> introducing a private method that just has the return call? > >>> > >>> Sure, what about this one: > >> http://cr.openjdk.java.net/~clanger/webrevs/8223553.2/ ? > >>> > >>> Thanks > >>> Christoph > >>> > > From vicente.romero at oracle.com Wed May 15 15:40:44 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 May 2019 11:40:44 -0400 Subject: RFR: JDK-8222169: java.lang.AssertionError switch expression in ternary operator - ? In-Reply-To: <26b45ff0-84e0-8e3d-7df7-da5b6d6d7553@oracle.com> References: <26b45ff0-84e0-8e3d-7df7-da5b6d6d7553@oracle.com> Message-ID: <28c78beb-a7b1-ebcf-ced1-32dce8c0ef59@oracle.com> looks good, Thanks, Vicente On 5/15/19 4:05 AM, Jan Lahoda wrote: > Hi, > > There is a regression in how let expressions are handled in Gen, > related to recent changes for switch expressions. Consider code like: > > int t(boolean b, Integer i) { > ??? return b ? 0 : i++; > } > > This gets desugared into: > int t(boolean b, Integer i) { > ??????? return b ? 0 : (let /*synthetic*/ final Integer $1357563986 = > i in (let i = Integer.valueOf((int)(i.intValue() + 1)); in > $1357563986)).intValue(); > ??? } > > When Gen.visitLetExpr is generating the let expression, it records the > stack size, so that for further statements, it can assert the > statements start at an appropriate stack depth (at "statement start"). > But, the issue here is that when the stack size is recorded, the state > of the bytecode is before the target of the jump for "b == false", > which jumps to the "else" section. I.e. the state of the bytecode is > before the ':', not after. And so '0' is on the stack. But, the code > for the let expression is after the target of the jump, and so the > real stack at the beginning of the code for the let expression is empty. > > The proposed solution is to simply resolve the jumps before recording > the size of the stack - that should ensure the correct stack size is > recorded. We already do that for Gen.visitSwitchExpression, but missed > it for visitLetExpr. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8222169/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8222169 > > The patch also includes test based on Vicente's: > http://cr.openjdk.java.net/~vromero/8222795/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From jan.lahoda at oracle.com Thu May 16 09:38:27 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 16 May 2019 11:38:27 +0200 Subject: RFR: JDK-8224031: Cannot parse switch expressions after type cast Message-ID: <7f358dd2-1966-a3ac-d6cc-fdc6e2876446@oracle.com> Hi, JavacParser.analyzeParens is used to categorize parentheses to be either cast, parenthesized expression or lambda parameters. It needs to be updated to categorize parentheses followed by switch as a cast: --- public class SE { private void t(Integer i) { String s = (String) switch (i) { default -> null; }; } } --- (Currently, it categorizes the above "(String)" as a parenthesized expression and then fails to parse the rest of the expression.) Proposed patch: http://cr.openjdk.java.net/~jlahoda/8224031/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8224031 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Thu May 16 10:44:25 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 16 May 2019 11:44:25 +0100 Subject: RFR: JDK-8224031: Cannot parse switch expressions after type cast In-Reply-To: <7f358dd2-1966-a3ac-d6cc-fdc6e2876446@oracle.com> References: <7f358dd2-1966-a3ac-d6cc-fdc6e2876446@oracle.com> Message-ID: <4bfc8083-3212-d81f-7d2e-7c23b85247fb@oracle.com> Looks good Maurizio On 16/05/2019 10:38, Jan Lahoda wrote: > Hi, > > JavacParser.analyzeParens is used to categorize parentheses to be > either cast, parenthesized expression or lambda parameters. It needs > to be updated to categorize parentheses followed by switch as a cast: > --- > public class SE { > ???? private void t(Integer i) { > ???????? String s = (String) switch (i) { default -> null; }; > ???? } > } > --- > > (Currently, it categorizes the above "(String)" as a parenthesized > expression and then fails to parse the rest of the expression.) > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8224031/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224031 > > How does this look? > > Thanks, > ??? Jan From stuart.marks at oracle.com Thu May 16 22:09:21 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 16 May 2019 15:09:21 -0700 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> Message-ID: On 5/14/19 9:16 PM, Martin Buchholz wrote: >> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java Regarding the change in this particular file, I'd suggest the following: diff -r 006dadb903ab -r 92e1fdce45e0 src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java Mon May 13 17:15:56 2019 -0700 +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java Thu May 16 15:04:30 2019 -0700 @@ -1712,9 +1712,7 @@ Map m = (Map) o; try { Comparator cmp = comparator; - @SuppressWarnings("unchecked") - Iterator> it = - (Iterator>)m.entrySet().iterator(); + Iterator> it = m.entrySet().iterator(); if (m instanceof SortedMap && ((SortedMap)m).comparator() == cmp) { Node b, n; I have no idea if it will be accepted by the Eclipse IDE, but this seems like a cleaner change to me than introducing a raw type. *** Christoph, On the general issue of compilation differences between javac and the Eclipse IDE, have you raised a bug with them? s'marks From ronshapiro at google.com Thu May 16 22:41:46 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Thu, 16 May 2019 18:41:46 -0400 Subject: Performance of Scope.getSymbolsByName() Message-ID: Hi, I'm observing a particularly bizarre compilation. It's a single file with annotation processing, and the type that is being compiled and processed has ~1000 declared and inherited methods combined. The total compilation is 3 minutes, but 65% of the entire compilation is spent in 3 methods: Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), and Resolve.findField(). Looking at profiles, it looks like getSymbolsByName() is the major culprit here. I initially thought the reason was that there were far too many overloads (this type had >600 overloads...) and that that was causing a bad regression for the pseudo-hashmap that ScopeImpl uses. However, renaming the methods did not alleviate the build pain and these methods continue to be taking long amounts of time. I was wondering what could be done to improve the performance of this code. It seemed to me that something like a Map> could be a reasonable+modern replacement for this table, which would naturally have a fast getSymbolsForName() implementation. I'm having some trouble implementing it correctly, and I believe it's partially related to not fully understanding some of the semantics of the class. Does what I wrote make sense to anyone, and maybe spark a lightbulb? I'm trying to put together a repro in case that helps, but I'm not 100% sure I even understand what the regression case is. Thanks for you help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri May 17 02:32:37 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 May 2019 19:32:37 -0700 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> Message-ID: Stuart's cool type system hack is hard for me to grok, but it seems alright to put into ConcurrentSkipListMap.java. We could add it to the current jsr166 integration. *From: *Stuart Marks *Date: *Thu, May 16, 2019 at 3:11 PM *To: *Martin Buchholz, David Holmes, Doug Lea, Langer, Christoph *Cc: *compiler-dev at openjdk.java.net, core-libs-dev, net-dev On 5/14/19 9:16 PM, Martin Buchholz wrote: > >> > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > > Regarding the change in this particular file, I'd suggest the following: > > > diff -r 006dadb903ab -r 92e1fdce45e0 > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > --- > a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > > Mon May 13 17:15:56 2019 -0700 > +++ > b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > > Thu May 16 15:04:30 2019 -0700 > @@ -1712,9 +1712,7 @@ > Map m = (Map) o; > try { > Comparator cmp = comparator; > - @SuppressWarnings("unchecked") > - Iterator> it = > - (Iterator>)m.entrySet().iterator(); > + Iterator> it = > m.entrySet().iterator(); > if (m instanceof SortedMap && > ((SortedMap)m).comparator() == cmp) { > Node b, n; > > > > I have no idea if it will be accepted by the Eclipse IDE, but this seems > like a > cleaner change to me than introducing a raw type. > > *** > > Christoph, > > On the general issue of compilation differences between javac and the > Eclipse > IDE, have you raised a bug with them? > > s'marks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Fri May 17 14:24:22 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 17 May 2019 10:24:22 -0400 Subject: RFR 8224114: Implement Scope.noFilter instead of using a null reference Message-ID: Please review this small refactoring to implement Scope.noFilter instead of maintaining several null checks throughout the code. bug: https://bugs.openjdk.java.net/browse/JDK-8224114 webrev: http://cr.openjdk.java.net/~ronsh/8224114/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri May 17 14:46:07 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 17 May 2019 10:46:07 -0400 Subject: RFR 8224114: Implement Scope.noFilter instead of using a null reference In-Reply-To: References: Message-ID: <8831b100-d590-18bb-078f-42dd09224248@oracle.com> looks good, Vicente On 5/17/19 10:24 AM, Ron Shapiro wrote: > Please review this small refactoring to implement?Scope.noFilter > instead of maintaining?several null checks throughout?the code. > > bug: https://bugs.openjdk.java.net/browse/JDK-8224114 > webrev: http://cr.openjdk.java.net/~ronsh/8224114/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri May 17 15:21:30 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 17 May 2019 17:21:30 +0200 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: Message-ID: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> Hi Ron, I am afraid it is hard to guess what is the problem without some testcase. So, at least to me, having a sample would be helpful. Thanks, Jan On 17. 05. 19 0:41, Ron Shapiro wrote: > Hi, > > I'm observing a particularly bizarre compilation. It's a single file > with annotation processing, and the type that is being compiled and > processed has ~1000 declared and inherited methods combined. The total > compilation is 3 minutes, but 65% of the entire compilation is spent in > 3 methods: > Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), > and?Resolve.findField(). > > Looking at profiles, it looks like getSymbolsByName() is the major > culprit here. I initially thought the reason was that there were far too > many overloads (this type had >600 overloads...) and that that was > causing a bad regression for the pseudo-hashmap that ScopeImpl uses. > However, renaming the methods did not alleviate the build pain and these > methods continue to be taking long amounts of time. > > I was wondering what could be done to improve the performance of this > code. It seemed to me that something like a Map> > could be a reasonable+modern replacement for this table, which would > naturally have a fast getSymbolsForName() implementation. I'm having > some trouble implementing it correctly, and I believe it's partially > related to not fully understanding some of the semantics of the class. > > Does what I wrote make sense to anyone, and maybe spark a lightbulb? > > I'm trying to put together a repro in case that helps, but I'm not 100% > sure I even understand what the regression case is. > > Thanks for you help! From ronshapiro at google.com Fri May 17 16:48:35 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 17 May 2019 12:48:35 -0400 Subject: RFR 8224114: Implement Scope.noFilter instead of using a null reference In-Reply-To: <8831b100-d590-18bb-078f-42dd09224248@oracle.com> References: <8831b100-d590-18bb-078f-42dd09224248@oracle.com> Message-ID: I found another location where a null symbol filter is being passed from Resolve.java - please hold off on accepting this change until I do a little bit more searching to find potentially other locations. On Fri, May 17, 2019 at 10:46 AM Vicente Romero wrote: > looks good, > Vicente > > On 5/17/19 10:24 AM, Ron Shapiro wrote: > > Please review this small refactoring to implement Scope.noFilter instead > of maintaining several null checks throughout the code. > > bug: https://bugs.openjdk.java.net/browse/JDK-8224114 > webrev: http://cr.openjdk.java.net/~ronsh/8224114/webrev.00/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Fri May 17 21:55:29 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 17 May 2019 17:55:29 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> Message-ID: I still have more to investigate to fully wrap my head around it, but I finally found a sample program that exhibits this. Filed a bug here: https://bugs.openjdk.java.net/browse/JDK-8224161 On Fri, May 17, 2019 at 11:21 AM Jan Lahoda wrote: > Hi Ron, > > I am afraid it is hard to guess what is the problem without some > testcase. So, at least to me, having a sample would be helpful. > > Thanks, > Jan > > On 17. 05. 19 0:41, Ron Shapiro wrote: > > Hi, > > > > I'm observing a particularly bizarre compilation. It's a single file > > with annotation processing, and the type that is being compiled and > > processed has ~1000 declared and inherited methods combined. The total > > compilation is 3 minutes, but 65% of the entire compilation is spent in > > 3 methods: > > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), > > and Resolve.findField(). > > > > Looking at profiles, it looks like getSymbolsByName() is the major > > culprit here. I initially thought the reason was that there were far too > > many overloads (this type had >600 overloads...) and that that was > > causing a bad regression for the pseudo-hashmap that ScopeImpl uses. > > However, renaming the methods did not alleviate the build pain and these > > methods continue to be taking long amounts of time. > > > > I was wondering what could be done to improve the performance of this > > code. It seemed to me that something like a Map> > > could be a reasonable+modern replacement for this table, which would > > naturally have a fast getSymbolsForName() implementation. I'm having > > some trouble implementing it correctly, and I believe it's partially > > related to not fully understanding some of the semantics of the class. > > > > Does what I wrote make sense to anyone, and maybe spark a lightbulb? > > > > I'm trying to put together a repro in case that helps, but I'm not 100% > > sure I even understand what the regression case is. > > > > Thanks for you help! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Fri May 17 22:56:27 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 17 May 2019 15:56:27 -0700 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> Message-ID: <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com> Hi Christoph, I'm still not entirely sure why this is so, but the introduction of a local variable in MethodHandles.java seems to make things work for Eclipse. Addition of a local variable seems to be minimally invasive, so it makes sense to see if this technique can be applied to other cases. (In ConcurrentSkipListMap the issue seems to be solved by addition of wildcards, as I had suggested previously, and it cleans up the unchecked cast that was there in the first place. So I think that one is ok already.) In ManagementFactory.java, an unchecked cast and warnings suppression is introduced, and in ExchangeImpl.java a helper method was introduced. I've found ways to introduce local variables that make Eclipse happy for these cases. (Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See diffs below. The type of the local variable in ExchangeImpl.java is a mouthful. Interestingly I had to change Function.identity() to the lambda x -> x. I think this is because Function.identity() returns a function that doesn't allow its return type to vary from its argument, whereas x -> x allows a widening conversion. (This might provide a clue as to the differences between javac and Eclipse here, but a full understanding eludes me.) s'marks diff -r 006dadb903ab src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java Mon May 13 17:15:56 2019 -0700 +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java Fri May 17 15:46:14 2019 -0700 @@ -1712,9 +1712,7 @@ Map m = (Map) o; try { Comparator cmp = comparator; - @SuppressWarnings("unchecked") - Iterator> it = - (Iterator>)m.entrySet().iterator(); + Iterator> it = m.entrySet().iterator(); if (m instanceof SortedMap && ((SortedMap)m).comparator() == cmp) { Node b, n; diff -r 006dadb903ab src/java.management/share/classes/java/lang/management/ManagementFactory.java --- a/src/java.management/share/classes/java/lang/management/ManagementFactory.java Mon May 13 17:15:56 2019 -0700 +++ b/src/java.management/share/classes/java/lang/management/ManagementFactory.java Fri May 17 15:46:14 2019 -0700 @@ -872,12 +872,12 @@ public static Set> getPlatformManagementInterfaces() { - return platformComponents() + Stream> pmos = platformComponents() .stream() .flatMap(pc -> pc.mbeanInterfaces().stream()) .filter(clazz -> PlatformManagedObject.class.isAssignableFrom(clazz)) - .map(clazz -> clazz.asSubclass(PlatformManagedObject.class)) - .collect(Collectors.toSet()); + .map(clazz -> clazz.asSubclass(PlatformManagedObject.class)); + return pmos.collect(Collectors.toSet()); } private static final String NOTIF_EMITTER = diff -r 006dadb903ab src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java --- a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java Mon May 13 17:15:56 2019 -0700 +++ b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java Fri May 17 15:46:14 2019 -0700 @@ -92,8 +92,9 @@ CompletableFuture c2f = c2.getConnectionFor(request, exchange); if (debug.on()) debug.log("get: Trying to get HTTP/2 connection"); - return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, connection)) - .thenCompose(Function.identity()); + CompletableFuture>> fxi = + c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, connection)); + return fxi.thenCompose(x -> x); } } From bsrbnd at gmail.com Sun May 19 14:46:41 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 19 May 2019 16:46:41 +0200 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> Message-ID: Hi Jan and Maurizio, I've updated the webrev [1] as you both suggested: * 'unwindBreak()' commented to warn for a possible dead code marking. * 'reloadStackBeforeSwitchExpr()' added to factorize the stack reloading. * 'test4()' below added to Jan's test cases. Does this look good to both of you (tier1 is OK)? Thanks, Bernard [1] http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.01/ On Sat, 11 May 2019 at 13:29, B. Blaser wrote: > > Hi Jan and Maurizio, > > Thanks for both feedback. > > On Thu, 9 May 2019 at 14:35, Maurizio Cimadamore > wrote: > > > > Hi, > > I look at the code and discussed it offline with Jan extensively. > > > > I think the approach looks good, and it is inspired by what we already > > do for return expressions (where we use intermediate locals to store > > return expressions in case there's a finalizer). > > > > The only problem I have with this code is that it implicitly relies, in > > the conditional context case, on the fact that, should the finalizer > > complete abnormally (isAlive = false), then Code will refuse to emit any > > additional statements (such as the loads required to restore the stack > > state). > > > > I think the is brittle, and might bite us back in case we revisit this > > code and add another statement whose behavior is NOT guarded by isAlive. > > > > So, I suggest either adding explicit comments, saying that unwindBreak > > might affect isAlive and, as a result, following statements might not be > > generated - or, wrap the code in an explicit `if (isAlive)` guard, as > > done in the other branch of the visitBreak code. > > As first step, I guess I'd be more for simply adding a comment but we > can still rework and consolidate this part later on if necessary. > > > As bonus point, since > > we're restoring the stack in three different places, perhaps we can > > factor the restoring code out to some common function. > > Of course ;-) > > > Cheers > > Maurizio > > > > > > On 09/05/2019 09:34, Jan Lahoda wrote: > > > Hi Bernard, > > > > > > I apologize for late reply. > > No problem, I'm rather busy too... > > > > Thanks for the patch, looks OK to me, but > > > I guess it would be good to have another review on this. > > > > > > Would it be possible to enhance the tests with the testcase below (and > > > any other testcases needed)? > > Yes, I'll also include this one. > > Cheers, > Bernard > > > > > Thanks, > > > Jan > > > > > > On 27. 03. 19 19:20, B. Blaser wrote: > > >> Hi, > > >> > > >> Please review the following fix for [1] which has already been > > >> discussed in the corresponding thread [2]: > > >> > > >> http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.00/ > > >> > > >> It includes the variant I suggested to store the switch expression > > >> result in a single temporary variable along with Jan's solution for > > >> switch expressions used as conditions. Note that I had to do a tiny > > >> correction to the latter (see 'code.resolve(value.trueJumps)') to make > > >> the following example succeed: > > >> > > >> public static void test4() { > > >> if (!switch (0) { > > >> default -> { > > >> try { > > >> break switch(0) { default -> true; }; > > >> } > > >> finally { > > >> break false; > > >> } > > >> } > > >> }) { > > >> System.out.println("OK!"); > > >> } > > >> } > > >> > > >> It also includes Jan's test case. > > >> > > >> Any feedback is welcome (tier1 is OK). > > >> > > >> Thanks, > > >> Bernard > > >> > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8220018 > > >> [2] > > >> http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013073.html > > >> From joe.darcy at oracle.com Mon May 20 06:36:05 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 19 May 2019 23:36:05 -0700 Subject: JDK 13 RFR of JDK-8224177: Harden annotation processing framework to irregular behavior from processors Message-ID: <7ad3b855-fe2d-6391-3a1b-88b5df0939b4@oracle.com> Hello, As a complement to the changes in AbstractProcessor done under JDK-8146726 , the annotation processing framework in javac could be hardened against various kinds of irregular results returned from processors. The hardening can include just warning about redundant but not strictly incorrect information. Webrev at: ??? http://cr.openjdk.java.net/~darcy/8224177.0/ Most of the code changes in JavacProcessingEnvironment are to guard against misbehaving Set implementations returned from Processors; perhaps this is an unnecessary degree of caution. There may be other test updates needed for account for the new warnings messages; I'll make any such update once there is review feedback and agreement on (what subset of) this change's checks should go back. Thanks, -Joe From james.laskey at oracle.com Mon May 20 12:58:51 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 20 May 2019 09:58:51 -0300 Subject: RFR: JDK-8223967: Implement Text Blocks (Preview) in the Java compiler Message-ID: <9A742B12-1490-4A17-82DB-4174F49064FC@oracle.com> Please review for Text Blocks. -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-01/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8223967 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Mon May 20 18:46:16 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 20 May 2019 15:46:16 -0300 Subject: RFR: JDK-8223967: Implement Text Blocks (Preview) in the Java compiler In-Reply-To: <9A742B12-1490-4A17-82DB-4174F49064FC@oracle.com> References: <9A742B12-1490-4A17-82DB-4174F49064FC@oracle.com> Message-ID: <6F3AC564-9326-447F-8CA1-05BD2B6164D1@oracle.com> Updated after first round review. webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-02/index.html > On May 20, 2019, at 9:58 AM, Jim Laskey wrote: > > Please review for Text Blocks. > > -- Jim > > webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-01/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8223967 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon May 20 20:07:38 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 20 May 2019 16:07:38 -0400 Subject: RFR: JDK-8223967: Implement Text Blocks (Preview) in the Java compiler In-Reply-To: <6F3AC564-9326-447F-8CA1-05BD2B6164D1@oracle.com> References: <9A742B12-1490-4A17-82DB-4174F49064FC@oracle.com> <6F3AC564-9326-447F-8CA1-05BD2B6164D1@oracle.com> Message-ID: I'm OK with v2, Thanks, Vicente On 5/20/19 2:46 PM, Jim Laskey wrote: > Updated after first round review. > > webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-02/index.html > > >> On May 20, 2019, at 9:58 AM, Jim Laskey > > wrote: >> >> Please review for Text Blocks. >> >> -- Jim >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-01/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223967 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon May 20 20:34:17 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 20 May 2019 16:34:17 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> Message-ID: This patch, which materializes the duplicate outer and inner Iterables first into a list. It removes the entire section of the CompoundIterator iteration from the profile. webrev: http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html I'm not sure it's the absolutely correct solution as it possibly masks an underlying issue. I'm still seeing some time spent in MethodSymbol.overrides, Types.isSubSignature, and Types.memberType, all of which happen in the inner loop. If we can remove those and collapse the nested loops into one, then this solution isn't necessary and it would also solve that performance issue. On Fri, May 17, 2019 at 5:55 PM Ron Shapiro wrote: > I still have more to investigate to fully wrap my head around it, but I > finally found a sample program that exhibits this. Filed a bug here: > https://bugs.openjdk.java.net/browse/JDK-8224161 > > On Fri, May 17, 2019 at 11:21 AM Jan Lahoda wrote: > >> Hi Ron, >> >> I am afraid it is hard to guess what is the problem without some >> testcase. So, at least to me, having a sample would be helpful. >> >> Thanks, >> Jan >> >> On 17. 05. 19 0:41, Ron Shapiro wrote: >> > Hi, >> > >> > I'm observing a particularly bizarre compilation. It's a single file >> > with annotation processing, and the type that is being compiled and >> > processed has ~1000 declared and inherited methods combined. The total >> > compilation is 3 minutes, but 65% of the entire compilation is spent in >> > 3 methods: >> > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), >> > and Resolve.findField(). >> > >> > Looking at profiles, it looks like getSymbolsByName() is the major >> > culprit here. I initially thought the reason was that there were far >> too >> > many overloads (this type had >600 overloads...) and that that was >> > causing a bad regression for the pseudo-hashmap that ScopeImpl uses. >> > However, renaming the methods did not alleviate the build pain and >> these >> > methods continue to be taking long amounts of time. >> > >> > I was wondering what could be done to improve the performance of this >> > code. It seemed to me that something like a Map> >> > could be a reasonable+modern replacement for this table, which would >> > naturally have a fast getSymbolsForName() implementation. I'm having >> > some trouble implementing it correctly, and I believe it's partially >> > related to not fully understanding some of the semantics of the class. >> > >> > Does what I wrote make sense to anyone, and maybe spark a lightbulb? >> > >> > I'm trying to put together a repro in case that helps, but I'm not 100% >> > sure I even understand what the regression case is. >> > >> > Thanks for you help! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon May 20 20:58:40 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 20 May 2019 16:58:40 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> Message-ID: In the real world example, I'm seeing the 40s that was previously spent in Check.checkOverrideClashes drop to to 9.5s when using this patch. Of that 9.5, 8.9 is spent in iterating through the CompoundIterator and calling getSymbolsByName. On Mon, May 20, 2019 at 4:34 PM Ron Shapiro wrote: > This patch, which materializes the duplicate outer and inner Iterables > first into a list. It removes the entire section of the CompoundIterator > iteration from the profile. > > webrev: > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html > > I'm not sure it's the absolutely correct solution as it possibly masks an > underlying issue. > > I'm still seeing some time spent in MethodSymbol.overrides, > Types.isSubSignature, and Types.memberType, all of which happen in the > inner loop. If we can remove those and collapse the nested loops into one, > then this solution isn't necessary and it would also solve that performance > issue. > > On Fri, May 17, 2019 at 5:55 PM Ron Shapiro wrote: > >> I still have more to investigate to fully wrap my head around it, but I >> finally found a sample program that exhibits this. Filed a bug here: >> https://bugs.openjdk.java.net/browse/JDK-8224161 >> >> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >> wrote: >> >>> Hi Ron, >>> >>> I am afraid it is hard to guess what is the problem without some >>> testcase. So, at least to me, having a sample would be helpful. >>> >>> Thanks, >>> Jan >>> >>> On 17. 05. 19 0:41, Ron Shapiro wrote: >>> > Hi, >>> > >>> > I'm observing a particularly bizarre compilation. It's a single file >>> > with annotation processing, and the type that is being compiled and >>> > processed has ~1000 declared and inherited methods combined. The total >>> > compilation is 3 minutes, but 65% of the entire compilation is spent >>> in >>> > 3 methods: >>> > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), >>> > and Resolve.findField(). >>> > >>> > Looking at profiles, it looks like getSymbolsByName() is the major >>> > culprit here. I initially thought the reason was that there were far >>> too >>> > many overloads (this type had >600 overloads...) and that that was >>> > causing a bad regression for the pseudo-hashmap that ScopeImpl uses. >>> > However, renaming the methods did not alleviate the build pain and >>> these >>> > methods continue to be taking long amounts of time. >>> > >>> > I was wondering what could be done to improve the performance of this >>> > code. It seemed to me that something like a Map> >>> > could be a reasonable+modern replacement for this table, which would >>> > naturally have a fast getSymbolsForName() implementation. I'm having >>> > some trouble implementing it correctly, and I believe it's partially >>> > related to not fully understanding some of the semantics of the class. >>> > >>> > Does what I wrote make sense to anyone, and maybe spark a lightbulb? >>> > >>> > I'm trying to put together a repro in case that helps, but I'm not >>> 100% >>> > sure I even understand what the regression case is. >>> > >>> > Thanks for you help! >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 21 09:58:54 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 21 May 2019 10:58:54 +0100 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> Message-ID: I think your fix is a good one. We spent some cycles optimizing this, a bit odd we have missed this :-) I'm very skeptical you can collapse into a single loop, as this implement the logic in JLS 8.4.8.3 [1] which, as you can see, is inherently quadratic (for each method, we have to scan all methods with same name in supertypes to see if there is an override clash). The algorithm that was there before wasn't - and it lead to the wrong answers in tricky cases - so while you can get 80% there with a non-quadratic algorithm, you will miss issues by doing so. One thing that would help would be, instead, to limit the analysis only in cases where it adds value - for instance, if your hierarchy is just non-generic classes (as in your example), then there's no way for you to accidentally override a 'bridge' method, since no bridges will be generated! But when looking at this, I couldn't find great ways to detect these conditions w/o spending more time than the check itself. [1] - https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 Maurizio On 20/05/2019 21:58, Ron Shapiro wrote: > In the real world example, I'm seeing the 40s that was previously > spent in Check.checkOverrideClashes drop to to 9.5s when using this > patch. Of that 9.5, 8.9 is spent in iterating through the > CompoundIterator and calling getSymbolsByName. > > On Mon, May 20, 2019 at 4:34 PM Ron Shapiro > wrote: > > This patch, which materializes the duplicate outer and inner > Iterables first into a list. It removes the entire section of the > CompoundIterator iteration from the profile. > > webrev: > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html > > I'm not sure it's the absolutely correct solution as it possibly > masks an underlying issue. > > I'm still seeing some time spent in MethodSymbol.overrides, > Types.isSubSignature, and Types.memberType, all of which happen in > the inner loop. If we can remove those and collapse the nested > loops into one, then this solution isn't necessary and it would > also solve that performance issue. > > On Fri, May 17, 2019 at 5:55 PM Ron Shapiro > wrote: > > I still have more to investigate to fully wrap my head around > it, but I finally found a sample program that exhibits this. > Filed a bug here: https://bugs.openjdk.java.net/browse/JDK-8224161 > > On Fri, May 17, 2019 at 11:21 AM Jan Lahoda > > wrote: > > Hi Ron, > > I am afraid it is hard to guess what is the problem > without some > testcase. So, at least to me, having a sample would be > helpful. > > Thanks, > ? ? ?Jan > > On 17. 05. 19 0:41, Ron Shapiro wrote: > > Hi, > > > > I'm observing a particularly bizarre compilation. It's a > single file > > with annotation processing, and the type that is being > compiled and > > processed has ~1000 declared and inherited methods > combined. The total > > compilation is 3 minutes, but 65% of the entire > compilation is spent in > > 3 methods: > > > Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), > > > and?Resolve.findField(). > > > > Looking at profiles, it looks like getSymbolsByName() is > the major > > culprit here. I initially thought the reason was that > there were far too > > many overloads (this type had >600 overloads...) and > that that was > > causing a bad regression for the pseudo-hashmap that > ScopeImpl uses. > > However, renaming the methods did not alleviate the > build pain and these > > methods continue to be taking long amounts of time. > > > > I was wondering what could be done to improve the > performance of this > > code. It seemed to me that something like a Map List> > > could be a reasonable+modern replacement for this table, > which would > > naturally have a fast getSymbolsForName() > implementation. I'm having > > some trouble implementing it correctly, and I believe > it's partially > > related to not fully understanding some of the semantics > of the class. > > > > Does what I wrote make sense to anyone, and maybe spark > a lightbulb? > > > > I'm trying to put together a repro in case that helps, > but I'm not 100% > > sure I even understand what the regression case is. > > > > Thanks for you help! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Tue May 21 11:16:01 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 21 May 2019 07:16:01 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> Message-ID: I still think that something to optimize the actual ScopeImpl Iterable is a worthwhile endeavor, as that would alleviate the need to materialize here (and solve hopefully the other issues I'm seeing), but I was having trouble figuring out how to do that. This may be a good interim option without much cost. On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I think your fix is a good one. We spent some cycles optimizing this, a > bit odd we have missed this :-) > > I'm very skeptical you can collapse into a single loop, as this implement > the logic in JLS 8.4.8.3 [1] which, as you can see, is inherently quadratic > (for each method, we have to scan all methods with same name in supertypes > to see if there is an override clash). The algorithm that was there before > wasn't - and it lead to the wrong answers in tricky cases - so while you > can get 80% there with a non-quadratic algorithm, you will miss issues by > doing so. > > One thing that would help would be, instead, to limit the analysis only in > cases where it adds value - for instance, if your hierarchy is just > non-generic classes (as in your example), then there's no way for you to > accidentally override a 'bridge' method, since no bridges will be > generated! But when looking at this, I couldn't find great ways to detect > these conditions w/o spending more time than the check itself. > > [1] - > https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 > > Maurizio > On 20/05/2019 21:58, Ron Shapiro wrote: > > In the real world example, I'm seeing the 40s that was previously spent in > Check.checkOverrideClashes drop to to 9.5s when using this patch. Of that > 9.5, 8.9 is spent in iterating through the CompoundIterator and calling > getSymbolsByName. > > On Mon, May 20, 2019 at 4:34 PM Ron Shapiro wrote: > >> This patch, which materializes the duplicate outer and inner Iterables >> first into a list. It removes the entire section of the CompoundIterator >> iteration from the profile. >> >> webrev: >> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >> >> I'm not sure it's the absolutely correct solution as it possibly masks an >> underlying issue. >> >> I'm still seeing some time spent in MethodSymbol.overrides, >> Types.isSubSignature, and Types.memberType, all of which happen in the >> inner loop. If we can remove those and collapse the nested loops into one, >> then this solution isn't necessary and it would also solve that performance >> issue. >> >> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >> wrote: >> >>> I still have more to investigate to fully wrap my head around it, but I >>> finally found a sample program that exhibits this. Filed a bug here: >>> https://bugs.openjdk.java.net/browse/JDK-8224161 >>> >>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >>> wrote: >>> >>>> Hi Ron, >>>> >>>> I am afraid it is hard to guess what is the problem without some >>>> testcase. So, at least to me, having a sample would be helpful. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 17. 05. 19 0:41, Ron Shapiro wrote: >>>> > Hi, >>>> > >>>> > I'm observing a particularly bizarre compilation. It's a single file >>>> > with annotation processing, and the type that is being compiled and >>>> > processed has ~1000 declared and inherited methods combined. The >>>> total >>>> > compilation is 3 minutes, but 65% of the entire compilation is spent >>>> in >>>> > 3 methods: >>>> > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), >>>> > and Resolve.findField(). >>>> > >>>> > Looking at profiles, it looks like getSymbolsByName() is the major >>>> > culprit here. I initially thought the reason was that there were far >>>> too >>>> > many overloads (this type had >600 overloads...) and that that was >>>> > causing a bad regression for the pseudo-hashmap that ScopeImpl uses. >>>> > However, renaming the methods did not alleviate the build pain and >>>> these >>>> > methods continue to be taking long amounts of time. >>>> > >>>> > I was wondering what could be done to improve the performance of this >>>> > code. It seemed to me that something like a Map> >>>> > could be a reasonable+modern replacement for this table, which would >>>> > naturally have a fast getSymbolsForName() implementation. I'm having >>>> > some trouble implementing it correctly, and I believe it's partially >>>> > related to not fully understanding some of the semantics of the class. >>>> > >>>> > Does what I wrote make sense to anyone, and maybe spark a lightbulb? >>>> > >>>> > I'm trying to put together a repro in case that helps, but I'm not >>>> 100% >>>> > sure I even understand what the regression case is. >>>> > >>>> > Thanks for you help! >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 21 12:05:03 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 21 May 2019 13:05:03 +0100 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> Message-ID: <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> On 21/05/2019 12:16, Ron Shapiro wrote: > I still think that something to optimize the actual ScopeImpl Iterable > is a worthwhile endeavor, as that would alleviate the need to > materialize here (and solve hopefully the other issues I'm seeing), > but I was having trouble figuring out how to do that. This may be a > good interim option without much cost. Sure - I'm not opposed to optimizing the iteration process - I was expressing my skepticism w.r.t. making checkOverrideClash simpler/non quadratic. Maurizio > > > > On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore > > wrote: > > I think your fix is a good one. We spent some cycles optimizing > this, a bit odd we have missed this :-) > > I'm very skeptical you can collapse into a single loop, as this > implement the logic in JLS 8.4.8.3 [1] which, as you can see, is > inherently quadratic (for each method, we have to scan all methods > with same name in supertypes to see if there is an override > clash). The algorithm that was there before wasn't - and it lead > to the wrong answers in tricky cases - so while you can get 80% > there with a non-quadratic algorithm, you will miss issues by > doing so. > > One thing that would help would be, instead, to limit the analysis > only in cases where it adds value - for instance, if your > hierarchy is just non-generic classes (as in your example), then > there's no way for you to accidentally override a 'bridge' method, > since no bridges will be generated! But when looking at this, I > couldn't find great ways to detect these conditions w/o spending > more time than the check itself. > > [1] - > https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 > > Maurizio > > On 20/05/2019 21:58, Ron Shapiro wrote: >> In the real world example, I'm seeing the 40s that was previously >> spent in Check.checkOverrideClashes drop to to 9.5s when using >> this patch. Of that 9.5, 8.9 is spent in iterating through the >> CompoundIterator and calling getSymbolsByName. >> >> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro >> > wrote: >> >> This patch, which materializes the duplicate outer and inner >> Iterables first into a list. It removes the entire section of >> the CompoundIterator iteration from the profile. >> >> webrev: >> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >> >> I'm not sure it's the absolutely correct solution as it >> possibly masks an underlying issue. >> >> I'm still seeing some time spent in MethodSymbol.overrides, >> Types.isSubSignature, and Types.memberType, all of which >> happen in the inner loop. If we can remove those and collapse >> the nested loops into one, then this solution isn't necessary >> and it would also solve that performance issue. >> >> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >> > wrote: >> >> I still have more to investigate to fully wrap my head >> around it, but I finally found a sample program that >> exhibits this. Filed a bug here: >> https://bugs.openjdk.java.net/browse/JDK-8224161 >> >> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >> > wrote: >> >> Hi Ron, >> >> I am afraid it is hard to guess what is the problem >> without some >> testcase. So, at least to me, having a sample would >> be helpful. >> >> Thanks, >> ? ? ?Jan >> >> On 17. 05. 19 0:41, Ron Shapiro wrote: >> > Hi, >> > >> > I'm observing a particularly bizarre compilation. >> It's a single file >> > with annotation processing, and the type that is >> being compiled and >> > processed has ~1000 declared and inherited methods >> combined. The total >> > compilation is 3 minutes, but 65% of the entire >> compilation is spent in >> > 3 methods: >> > >> Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), >> >> > and?Resolve.findField(). >> > >> > Looking at profiles, it looks like >> getSymbolsByName() is the major >> > culprit here. I initially thought the reason was >> that there were far too >> > many overloads (this type had >600 overloads...) >> and that that was >> > causing a bad regression for the pseudo-hashmap >> that ScopeImpl uses. >> > However, renaming the methods did not alleviate the >> build pain and these >> > methods continue to be taking long amounts of time. >> > >> > I was wondering what could be done to improve the >> performance of this >> > code. It seemed to me that something like a >> Map> >> > could be a reasonable+modern replacement for this >> table, which would >> > naturally have a fast getSymbolsForName() >> implementation. I'm having >> > some trouble implementing it correctly, and I >> believe it's partially >> > related to not fully understanding some of the >> semantics of the class. >> > >> > Does what I wrote make sense to anyone, and maybe >> spark a lightbulb? >> > >> > I'm trying to put together a repro in case that >> helps, but I'm not 100% >> > sure I even understand what the regression case is. >> > >> > Thanks for you help! >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Tue May 21 14:32:47 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 11:32:47 -0300 Subject: RFR - JDK-8203444 String::formatted (Preview) Message-ID: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> Please do a code review of the new String::formatted instance method. This method was originally introduced under the name "format" in conjunction with Raw String Literals. The method is being reintroduced in conjunction with Text Blocks and renamed to avoid method resolution conflicts against the static method String::format. Example of use: String name = "Smith, Pat"; String address = "123 Maple St., Anytown, Anywhere"; String phone = "999-555-1234"; String client = """ Name: %s Address: %s Phone: %s """.formatted(name, address, phone); Thank you. -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8203444/webrev-01 jbs: https://bugs.openjdk.java.net/browse/JDK-8203444 csr: https://bugs.openjdk.java.net/browse/JDK-8203630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Tue May 21 14:42:57 2019 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 21 May 2019 16:42:57 +0200 Subject: RFR - JDK-8203444 String::formatted (Preview) In-Reply-To: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> (Jim Laskey's message of "Tue, 21 May 2019 11:32:47 -0300") References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> Message-ID: <8736l798cu.fsf@oldenburg2.str.redhat.com> * Jim Laskey: > Please do a code review of the new String::formatted instance method. This method was originally introduced under the name "format" > in conjunction with Raw String Literals. The method is being reintroduced in conjunction with Text Blocks and renamed to avoid method > resolution conflicts against the static method String::format. > > Example of use: > > String name = "Smith, Pat"; > String address = "123 Maple St., Anytown, Anywhere"; > String phone = "999-555-1234"; > String client = """ > Name: %s > Address: %s > Phone: %s > """.formatted(name, address, phone); I'm a bit concerned by the ambiguity between the version with and without the Locale argument. Not sure if this is the kind of feedback you are looking for. (String::format does not have this ambiguity and had been able to avoid it easily, so it's not a good guide here.) Thanks, Florian From james.laskey at oracle.com Tue May 21 14:52:03 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 11:52:03 -0300 Subject: RFR - JDK-8203444 String::formatted (Preview) In-Reply-To: <8736l798cu.fsf@oldenburg2.str.redhat.com> References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> <8736l798cu.fsf@oldenburg2.str.redhat.com> Message-ID: <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com> All discussion is valid. I agree the ambiguity is tricky, but can be resolved by using explicit locale. Example: "%s".formatted(Locale.getDefault(), Locale.JAPAN); This guarantees the "public String formatted(Locale l, Object... args)" form is chosen with the second Locale as an argument. Cheers, -- Jim > On May 21, 2019, at 11:42 AM, Florian Weimer wrote: > > * Jim Laskey: > >> Please do a code review of the new String::formatted instance method. This method was originally introduced under the name "format" >> in conjunction with Raw String Literals. The method is being reintroduced in conjunction with Text Blocks and renamed to avoid method >> resolution conflicts against the static method String::format. >> >> Example of use: >> >> String name = "Smith, Pat"; >> String address = "123 Maple St., Anytown, Anywhere"; >> String phone = "999-555-1234"; >> String client = """ >> Name: %s >> Address: %s >> Phone: %s >> """.formatted(name, address, phone); > > I'm a bit concerned by the ambiguity between the version with and > without the Locale argument. Not sure if this is the kind of feedback > you are looking for. > > (String::format does not have this ambiguity and had been able to avoid > it easily, so it's not a good guide here.) > > Thanks, > Florian From james.laskey at oracle.com Tue May 21 14:56:45 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 11:56:45 -0300 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) Message-ID: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. Thank you. -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 csr: https://bugs.openjdk.java.net/browse/JDK-8223781 jep: https://bugs.openjdk.java.net/browse/JDK-8222530 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Tue May 21 14:56:42 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 11:56:42 -0300 Subject: RFR - JDK-8223775 String::stripIndent (Preview) Message-ID: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. Thank you. -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 csr: https://bugs.openjdk.java.net/browse/JDK-8223776 jep: https://bugs.openjdk.java.net/browse/JDK-8222530 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Tue May 21 15:44:28 2019 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 21 May 2019 17:44:28 +0200 Subject: RFR - JDK-8203444 String::formatted (Preview) In-Reply-To: <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com> (Jim Laskey's message of "Tue, 21 May 2019 11:52:03 -0300") References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> <8736l798cu.fsf@oldenburg2.str.redhat.com> <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com> Message-ID: <87h89n7qxv.fsf@oldenburg2.str.redhat.com> * Jim Laskey: > All discussion is valid. I agree the ambiguity is tricky, but can be > resolved by using explicit locale. > > Example: > > "%s".formatted(Locale.getDefault(), Locale.JAPAN); > > This guarantees the "public String formatted(Locale l, > Object... args)" form is chosen with the second Locale as an argument. There is also the cognitive overhead. I think the key question is whether this is so bad: String.format(Locale.US, """ %s """, Locale.JAPAN); Then perhaps we wouldn't need the formatted method which takes a Locale object. Thanks, Florian From james.laskey at oracle.com Tue May 21 15:56:11 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 12:56:11 -0300 Subject: RFR - JDK-8203444 String::formatted (Preview) In-Reply-To: <87h89n7qxv.fsf@oldenburg2.str.redhat.com> References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> <8736l798cu.fsf@oldenburg2.str.redhat.com> <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com> <87h89n7qxv.fsf@oldenburg2.str.redhat.com> Message-ID: <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com> Good point. To make sure I fully understand what you are stating, - The argument for having an instance method is reasonable to achieve "flowiness". - However, only one version is necessary or desired, that is, "public String formatted(Object... args)". - In cases where Locale needs to be overridden, then either use "String.format(Locale lc, String fmt, Object... args)" or globally set "Locale.setDefault(Locale lc)". Correct? -- Jim > On May 21, 2019, at 12:44 PM, Florian Weimer wrote: > > * Jim Laskey: > >> All discussion is valid. I agree the ambiguity is tricky, but can be >> resolved by using explicit locale. >> >> Example: >> >> "%s".formatted(Locale.getDefault(), Locale.JAPAN); >> >> This guarantees the "public String formatted(Locale l, >> Object... args)" form is chosen with the second Locale as an argument. > > There is also the cognitive overhead. I think the key question is > whether this is so bad: > > String.format(Locale.US, """ > %s > """, Locale.JAPAN); > > Then perhaps we wouldn't need the formatted method which takes a Locale > object. > > Thanks, > Florian From james.laskey at oracle.com Tue May 21 16:30:10 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 13:30:10 -0300 Subject: RFR - JDK-8203444 String::formatted (Preview) In-Reply-To: <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com> References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> <8736l798cu.fsf@oldenburg2.str.redhat.com> <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com> <87h89n7qxv.fsf@oldenburg2.str.redhat.com> <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com> Message-ID: I suppose String::formattedLocalized(Locale lc, Object... args) would also be reasonable. > On May 21, 2019, at 12:56 PM, Jim Laskey wrote: > > Good point. To make sure I fully understand what you are stating, > > - The argument for having an instance method is reasonable to achieve "flowiness". > - However, only one version is necessary or desired, that is, "public String formatted(Object... args)". > - In cases where Locale needs to be overridden, then either use "String.format(Locale lc, String fmt, Object... args)" or globally set "Locale.setDefault(Locale lc)". > > Correct? > > -- Jim > > > > >> On May 21, 2019, at 12:44 PM, Florian Weimer wrote: >> >> * Jim Laskey: >> >>> All discussion is valid. I agree the ambiguity is tricky, but can be >>> resolved by using explicit locale. >>> >>> Example: >>> >>> "%s".formatted(Locale.getDefault(), Locale.JAPAN); >>> >>> This guarantees the "public String formatted(Locale l, >>> Object... args)" form is chosen with the second Locale as an argument. >> >> There is also the cognitive overhead. I think the key question is >> whether this is so bad: >> >> String.format(Locale.US, """ >> %s >> """, Locale.JAPAN); >> >> Then perhaps we wouldn't need the formatted method which takes a Locale >> object. >> >> Thanks, >> Florian > From ronshapiro at google.com Tue May 21 16:39:15 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 21 May 2019 12:39:15 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: Are the checks of the inner loop symmetrical? Currently it's checking mi against (m0..n - mi). This second webrev below would check it against just (m0..i-1), which albeit still n^2, it divides by a factor of 2. (sorry if the subscripting here doesn't display correctly) http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ This feels conceptually logical to me, but I'm not seeing a measurable change by it. It looks a little bit cleaner to me, but I'm fine with either webrev given the benefits they both bring. I can take a look in another thread about speeding up CompoundScope iteration. On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 21/05/2019 12:16, Ron Shapiro wrote: > > I still think that something to optimize the actual ScopeImpl Iterable is > a worthwhile endeavor, as that would alleviate the need to materialize here > (and solve hopefully the other issues I'm seeing), but I was having trouble > figuring out how to do that. This may be a good interim option without much > cost. > > Sure - I'm not opposed to optimizing the iteration process - I was > expressing my skepticism w.r.t. making checkOverrideClash simpler/non > quadratic. > > Maurizio > > > > > On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> I think your fix is a good one. We spent some cycles optimizing this, a >> bit odd we have missed this :-) >> >> I'm very skeptical you can collapse into a single loop, as this implement >> the logic in JLS 8.4.8.3 [1] which, as you can see, is inherently quadratic >> (for each method, we have to scan all methods with same name in supertypes >> to see if there is an override clash). The algorithm that was there before >> wasn't - and it lead to the wrong answers in tricky cases - so while you >> can get 80% there with a non-quadratic algorithm, you will miss issues by >> doing so. >> >> One thing that would help would be, instead, to limit the analysis only >> in cases where it adds value - for instance, if your hierarchy is just >> non-generic classes (as in your example), then there's no way for you to >> accidentally override a 'bridge' method, since no bridges will be >> generated! But when looking at this, I couldn't find great ways to detect >> these conditions w/o spending more time than the check itself. >> >> [1] - >> https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 >> >> Maurizio >> On 20/05/2019 21:58, Ron Shapiro wrote: >> >> In the real world example, I'm seeing the 40s that was previously spent >> in Check.checkOverrideClashes drop to to 9.5s when using this patch. Of >> that 9.5, 8.9 is spent in iterating through the CompoundIterator and >> calling getSymbolsByName. >> >> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro >> wrote: >> >>> This patch, which materializes the duplicate outer and inner Iterables >>> first into a list. It removes the entire section of the CompoundIterator >>> iteration from the profile. >>> >>> webrev: >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >>> >>> I'm not sure it's the absolutely correct solution as it possibly masks >>> an underlying issue. >>> >>> I'm still seeing some time spent in MethodSymbol.overrides, >>> Types.isSubSignature, and Types.memberType, all of which happen in the >>> inner loop. If we can remove those and collapse the nested loops into one, >>> then this solution isn't necessary and it would also solve that performance >>> issue. >>> >>> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >>> wrote: >>> >>>> I still have more to investigate to fully wrap my head around it, but I >>>> finally found a sample program that exhibits this. Filed a bug here: >>>> https://bugs.openjdk.java.net/browse/JDK-8224161 >>>> >>>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >>>> wrote: >>>> >>>>> Hi Ron, >>>>> >>>>> I am afraid it is hard to guess what is the problem without some >>>>> testcase. So, at least to me, having a sample would be helpful. >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> On 17. 05. 19 0:41, Ron Shapiro wrote: >>>>> > Hi, >>>>> > >>>>> > I'm observing a particularly bizarre compilation. It's a single file >>>>> > with annotation processing, and the type that is being compiled and >>>>> > processed has ~1000 declared and inherited methods combined. The >>>>> total >>>>> > compilation is 3 minutes, but 65% of the entire compilation is spent >>>>> in >>>>> > 3 methods: >>>>> > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), >>>>> > and Resolve.findField(). >>>>> > >>>>> > Looking at profiles, it looks like getSymbolsByName() is the major >>>>> > culprit here. I initially thought the reason was that there were far >>>>> too >>>>> > many overloads (this type had >600 overloads...) and that that was >>>>> > causing a bad regression for the pseudo-hashmap that ScopeImpl uses. >>>>> > However, renaming the methods did not alleviate the build pain and >>>>> these >>>>> > methods continue to be taking long amounts of time. >>>>> > >>>>> > I was wondering what could be done to improve the performance of >>>>> this >>>>> > code. It seemed to me that something like a Map> >>>>> > could be a reasonable+modern replacement for this table, which would >>>>> > naturally have a fast getSymbolsForName() implementation. I'm having >>>>> > some trouble implementing it correctly, and I believe it's partially >>>>> > related to not fully understanding some of the semantics of the >>>>> class. >>>>> > >>>>> > Does what I wrote make sense to anyone, and maybe spark a lightbulb? >>>>> > >>>>> > I'm trying to put together a repro in case that helps, but I'm not >>>>> 100% >>>>> > sure I even understand what the regression case is. >>>>> > >>>>> > Thanks for you help! >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Tue May 21 17:34:04 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 14:34:04 -0300 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> Message-ID: <7ED4E127-25C5-4E3C-A996-EE6324E5FA06@oracle.com> Code has been updated to use IllegalArgumentException instead of new exception type. http://cr.openjdk.java.net/~jlaskey/8223780/webrev-02 > On May 21, 2019, at 11:56 AM, Jim Laskey wrote: > > Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. > > Thank you. > > -- Jim > > webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 > jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 > csr: https://bugs.openjdk.java.net/browse/JDK-8223781 > jep: https://bugs.openjdk.java.net/browse/JDK-8222530 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue May 21 17:57:01 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 21 May 2019 10:57:01 -0700 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> Message-ID: Hi Jim! A few comments: 1) Probably, there's no need to update ch in these cases: case '\'': ch = '\''; break; case '\"': ch = '\"'; break; 2) Character.digit(ch, 8) will accept non-Latin1 digits. So, a sequence \\3\uFF17\uFF17 will be parsed as \\377. (Note, that the first digit still can only be from range '0'-'9'). 3) It's not obvious how this condition can be triggered: if (0377 < code) { throw new MalformedEscapeException(from); } I might be missing something, but I cannot see how 'code' can become > 0377. 4) throw new MalformedEscapeException(from); This will report the next index after the error. Was it intentional? With kind regards, Ivan On 5/21/19 7:56 AM, Jim Laskey wrote: > Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. > > Thank you. > > -- Jim > > webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 > jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 > csr: https://bugs.openjdk.java.net/browse/JDK-8223781 > jep: https://bugs.openjdk.java.net/browse/JDK-8222530 > > -- With kind regards, Ivan Gerasimov From alex.buckley at oracle.com Tue May 21 18:11:42 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 21 May 2019 11:11:42 -0700 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> Message-ID: <5CE43F5E.1050102@oracle.com> On 5/21/2019 7:56 AM, Jim Laskey wrote: > Please do a code review of the new String::stripIndent instance method. My interest is in the API spec because the JLS will make normative reference to it. "Removes horizontal white space margins from the essential body of a Text Block originated string, while preserving relative indentation." Lots of concepts here: margins, "essential body", a "Text Block originated string" (not just any string?). Looks like the removal happens in-place. While "essential" is a concept from the JEP, I think the sibling concept, "incidental", is the one to lead with. Alluding to multiple lines is also good. Recommend: "Returns a string whose value is this string, with incidental white space removed from the beginning and end of every line." That is, 'stripIndent' isn't quite as generic as its name suggests. It implements a particular policy about "incidental" white space that we will now explain... New paragraph: "Incidental white space is often present in a text block to align the content with the opening delimiter. For example, in the following code, dots represent incidental white space: String html = """ .............. .............. ..............

Hello, world

.............. .............. .............."""; Another new para, to link this high-falutin' incidental concept to the workmanlike name of this method: "This method treats the incidental white space as indentation to be stripped, producing a string that preserves the relative indentation of the content. Using | to visualize the start of each line of the string: | | |

Hello, world

| | Now, the algo. "This string is first conceptually separated into lines as if by {@link String#lines()}." -- phrasing: "First, this string is conceptually ..." "Then, the minimum indentation (min) is determined as follows. For each non-blank line (as defined by {@link String#isBlank()}), the leading {@link Character#isWhitespace(int) white space} characters are counted. The leading {@link Character#isWhitespace(int) white space} characters on the last line are are also counted even if blank. The min value is the smallest of these counts." No more "common white space prefix" like in the JEP? OK, fair enough, we're now fully rotated to "indentation" rather than "white space". "For each non-blank line, min leading white space characters are removed. Each white space character is treated as a single character. In particular, the tab character {@code "\t"} (U+0009) is considered a single character; it is not expanded. The trailing white space of each line is also removed." The trailing white space characters are just as "treated as a single character" as the leading white space characters. Recommend: "For each non-blank line, min leading white space characters are removed, and any trailing white space characters are removed." Recommend handling escape sequences in a separate para. Showing "\t", a two character sequence, and then alluding to \u0009, a single character, is confusing. "Each line is suffixed with a line feed character {@code "\n"} (U+000A), except for the last line. The last line is suffixed with a line feed character {@code "\n"} (U+000A) only if the original last line was blank." The phrasing "except for the last line" is odd because it suggests the last line never gets a suffix. Except, oh, it might. And "suffixed" is an unusual word. If you're going to allude to the original string's last line, then isn't there a way to lean on it more? e.g. "A line feed character is appended to every line if the corresponding line in the original string was terminated with a line feed character." (Not saying that is correct or desirable, but is easier to visualize.) "Finally, the lines are concatenated into a single string and returned." Recommend: "Finally, the lines are concatenated into a string, which is the result." Alex From james.laskey at oracle.com Tue May 21 18:23:06 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 15:23:06 -0300 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> Message-ID: <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com> > On May 21, 2019, at 2:57 PM, Ivan Gerasimov wrote: > > Hi Jim! > > A few comments: > > 1) > Probably, there's no need to update ch in these cases: > case '\'': > ch = '\''; > break; > case '\"': > ch = '\"'; > break; True > > 2) > Character.digit(ch, 8) will accept non-Latin1 digits. > So, a sequence \\3\uFF17\uFF17 will be parsed as \\377. > (Note, that the first digit still can only be from range '0'-'9'). Also true. Subtlety in UnicodeReader. > > 3) > It's not obvious how this condition can be triggered: > if (0377 < code) { > throw new MalformedEscapeException(from); > } > I might be missing something, but I cannot see how 'code' can become > 0377. I removed this check in round 2. > > 4) > throw new MalformedEscapeException(from); > This will report the next index after the error. Was it intentional? > I switched to using an IllegalArgumentError and displaying the actual character. > With kind regards, > Ivan Much thanks. > > > On 5/21/19 7:56 AM, Jim Laskey wrote: >> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. >> >> Thank you. >> >> -- Jim >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 >> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 >> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 >> >> > > -- > With kind regards, > Ivan Gerasimov > From vicente.romero at oracle.com Tue May 21 18:27:21 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 21 May 2019 14:27:21 -0400 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> Message-ID: Hi Jim, Some minor comments: - the javadoc for String::stripIndent needs some formating. There is a solitary "counted. The" - at method String::stripIndent, you can bail out and do nothing if outdent==0 - suggestion: method String::outdent could return a Map to indicate the first index of a non-whitespace per line. I concede that you probably won't be able to use a lambda at the end but you will avoid invoking String::indexOfNonWhitespace per line again at String::stripIndent Thanks, Vicente On 5/21/19 10:56 AM, Jim Laskey wrote: > Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. > > Thank you. > > -- Jim > > webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 > jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 > csr: https://bugs.openjdk.java.net/browse/JDK-8223776 > jep: https://bugs.openjdk.java.net/browse/JDK-8222530 > > From james.laskey at oracle.com Tue May 21 18:30:58 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 15:30:58 -0300 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <5CE43F5E.1050102@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> <5CE43F5E.1050102@oracle.com> Message-ID: <2AF761BB-8323-46AA-8392-55E80A7E15DD@oracle.com> Thank you. I haven't really put the API out for CSR review as yet. This is current state remnant from Stuart's Raw String Literals CSR review. He and I hope to reform this very soon. Your comments will provide a good starting point. Cheers, -- Jim > On May 21, 2019, at 3:11 PM, Alex Buckley wrote: > > On 5/21/2019 7:56 AM, Jim Laskey wrote: >> Please do a code review of the new String::stripIndent instance method. > > My interest is in the API spec because the JLS will make normative reference to it. > > > "Removes horizontal white space margins from the essential body of a > Text Block originated string, while preserving relative indentation." > > Lots of concepts here: margins, "essential body", a "Text Block originated string" (not just any string?). Looks like the removal happens in-place. While "essential" is a concept from the JEP, I think the sibling concept, "incidental", is the one to lead with. Alluding to multiple lines is also good. Recommend: > > "Returns a string whose value is this string, with incidental white space removed from the beginning and end of every line." > > That is, 'stripIndent' isn't quite as generic as its name suggests. It implements a particular policy about "incidental" white space that we will now explain... > > > New paragraph: "Incidental white space is often present in a text block to align the content with the opening delimiter. For example, in the following code, dots represent incidental white space: > > String html = """ > .............. > .............. > ..............

Hello, world

> .............. > .............. > .............."""; > > > Another new para, to link this high-falutin' incidental concept to the workmanlike name of this method: "This method treats the incidental white space as indentation to be stripped, producing a string that preserves the relative indentation of the content. Using | to visualize the start of each line of the string: > > | > | > |

Hello, world

> | > | > > > Now, the algo. "This string is first conceptually separated into lines as if by {@link String#lines()}." -- phrasing: "First, this string is conceptually ..." > > > "Then, the minimum indentation (min) is determined as follows. For each non-blank line (as defined by {@link String#isBlank()}), the > leading {@link Character#isWhitespace(int) white space} characters are > counted. The leading {@link Character#isWhitespace(int) white space} characters on the last line are are also counted even if blank. > The min value is the smallest of these counts." > > No more "common white space prefix" like in the JEP? OK, fair enough, we're now fully rotated to "indentation" rather than "white space". > > > "For each non-blank line, min leading white space characters are > removed. Each white space character is treated as a single character. In > particular, the tab character {@code "\t"} (U+0009) is considered a > single character; it is not expanded. > > The trailing white space of each line is also removed." > > The trailing white space characters are just as "treated as a single character" as the leading white space characters. Recommend: "For each non-blank line, min leading white space characters are removed, and any trailing white space characters are removed." > > > Recommend handling escape sequences in a separate para. Showing "\t", a two character sequence, and then alluding to \u0009, a single character, is confusing. > > > "Each line is suffixed with a line feed character {@code "\n"} (U+000A), > except for the last line. The last line is suffixed with a line feed > character {@code "\n"} (U+000A) only if the original last line was blank." > > The phrasing "except for the last line" is odd because it suggests the last line never gets a suffix. Except, oh, it might. And "suffixed" is an unusual word. If you're going to allude to the original string's last line, then isn't there a way to lean on it more? e.g. "A line feed character is appended to every line if the corresponding line in the original string was terminated with a line feed character." (Not saying that is correct or desirable, but is easier to visualize.) > > > "Finally, the lines are concatenated into a single string and returned." > > Recommend: "Finally, the lines are concatenated into a string, which is the result." > > Alex From james.laskey at oracle.com Tue May 21 18:37:48 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 15:37:48 -0300 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> Message-ID: > On May 21, 2019, at 3:27 PM, Vicente Romero wrote: > > Hi Jim, > > Some minor comments: > > - the javadoc for String::stripIndent needs some formating. There is a solitary "counted. The" Looking for a code review at this point. Will get to API soon. > - at method String::stripIndent, you can bail out and do nothing if outdent==0 Not really, we still need to stripTrailing, but I could optimize that case. > - suggestion: method String::outdent could return a Map to indicate the first index of a non-whitespace per line. I concede that you probably won't be able to use a lambda at the end but you will avoid invoking String::indexOfNonWhitespace per line again at String::stripIndent Considered using an int array but it's a time vs memory situation. Cost of managing the map would outweigh the cost of recomputation. The scan is pretty quick. > > Thanks, > Vicente Thank you. > > On 5/21/19 10:56 AM, Jim Laskey wrote: >> Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. >> >> Thank you. >> >> -- Jim >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 >> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 >> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 >> >> > From james.laskey at oracle.com Tue May 21 19:24:36 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 16:24:36 -0300 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com> References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com> Message-ID: Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html > On May 21, 2019, at 3:23 PM, Jim Laskey wrote: > > > >> On May 21, 2019, at 2:57 PM, Ivan Gerasimov wrote: >> >> Hi Jim! >> >> A few comments: >> >> 1) >> Probably, there's no need to update ch in these cases: >> case '\'': >> ch = '\''; >> break; >> case '\"': >> ch = '\"'; >> break; > > True > >> >> 2) >> Character.digit(ch, 8) will accept non-Latin1 digits. >> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377. >> (Note, that the first digit still can only be from range '0'-'9'). > > Also true. Subtlety in UnicodeReader. > >> >> 3) >> It's not obvious how this condition can be triggered: >> if (0377 < code) { >> throw new MalformedEscapeException(from); >> } >> I might be missing something, but I cannot see how 'code' can become > 0377. > > I removed this check in round 2. > >> >> 4) >> throw new MalformedEscapeException(from); >> This will report the next index after the error. Was it intentional? >> > > I switched to using an IllegalArgumentError and displaying the actual character. > > >> With kind regards, >> Ivan > > Much thanks. > > >> >> >> On 5/21/19 7:56 AM, Jim Laskey wrote: >>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. >>> >>> Thank you. >>> >>> -- Jim >>> >>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 >>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 >>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 >>> >>> >> >> -- >> With kind regards, >> Ivan Gerasimov >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue May 21 19:41:22 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 21 May 2019 15:41:22 -0400 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> Message-ID: <65795019-4e7a-8d72-958c-196b35e36cf1@oracle.com> Hi, On 5/21/19 2:37 PM, Jim Laskey wrote: > >> On May 21, 2019, at 3:27 PM, Vicente Romero wrote: >> >> Hi Jim, >> >> Some minor comments: >> >> - the javadoc for String::stripIndent needs some formating. There is a solitary "counted. The" > Looking for a code review at this point. Will get to API soon. > >> - at method String::stripIndent, you can bail out and do nothing if outdent==0 > Not really, we still need to stripTrailing, but I could optimize that case. rigth > >> - suggestion: method String::outdent could return a Map to indicate the first index of a non-whitespace per line. I concede that you probably won't be able to use a lambda at the end but you will avoid invoking String::indexOfNonWhitespace per line again at String::stripIndent > Considered using an int array but it's a time vs memory situation. Cost of managing the map would outweigh the cost of recomputation. The scan is pretty quick. ok, no more comments, Vicente > >> Thanks, >> Vicente > Thank you. > > >> On 5/21/19 10:56 AM, Jim Laskey wrote: >>> Please do a code review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. >>> >>> Thank you. >>> >>> -- Jim >>> >>> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 >>> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 >>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 >>> >>> From maurizio.cimadamore at oracle.com Tue May 21 20:21:15 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 21 May 2019 21:21:15 +0100 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: I see what you have done - I have to think about it a bit to see if I can come up with some counter example. Thanks Maurizio On 21/05/2019 17:39, Ron Shapiro wrote: > Are the checks of the inner loop symmetrical? > > Currently it's checking m_i against (m_0..n - m_i ). This second > webrev below would check it against just?(m_0..i-1 ), which albeit > still n^2, it divides by a factor of 2. > > (sorry if the subscripting here doesn't display correctly) > > http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ > > This feels conceptually logical to me, but I'm not seeing a > measurable?change by it. It looks a little bit cleaner to me, but I'm > fine with either webrev given the benefits they both bring. > > I can take a look in another thread about speeding up CompoundScope > iteration. > > On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore > > wrote: > > > On 21/05/2019 12:16, Ron Shapiro wrote: >> I still think that something to optimize the actual ScopeImpl >> Iterable is a worthwhile endeavor, as that would alleviate the >> need to materialize here (and solve hopefully the other issues >> I'm seeing), but I was having trouble figuring out how to do >> that. This may be a good interim option without much cost. > > Sure - I'm not opposed to optimizing the iteration process - I was > expressing my skepticism w.r.t. making checkOverrideClash > simpler/non quadratic. > > Maurizio > >> >> >> >> On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore >> > > wrote: >> >> I think your fix is a good one. We spent some cycles >> optimizing this, a bit odd we have missed this :-) >> >> I'm very skeptical you can collapse into a single loop, as >> this implement the logic in JLS 8.4.8.3 [1] which, as you can >> see, is inherently quadratic (for each method, we have to >> scan all methods with same name in supertypes to see if there >> is an override clash). The algorithm that was there before >> wasn't - and it lead to the wrong answers in tricky cases - >> so while you can get 80% there with a non-quadratic >> algorithm, you will miss issues by doing so. >> >> One thing that would help would be, instead, to limit the >> analysis only in cases where it adds value - for instance, if >> your hierarchy is just non-generic classes (as in your >> example), then there's no way for you to accidentally >> override a 'bridge' method, since no bridges will be >> generated! But when looking at this, I couldn't find great >> ways to detect these conditions w/o spending more time than >> the check itself. >> >> [1] - >> https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 >> >> Maurizio >> >> On 20/05/2019 21:58, Ron Shapiro wrote: >>> In the real world example, I'm seeing the 40s that was >>> previously spent in Check.checkOverrideClashes drop to to >>> 9.5s when using this patch. Of that 9.5, 8.9 is spent in >>> iterating through the CompoundIterator and calling >>> getSymbolsByName. >>> >>> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro >>> > wrote: >>> >>> This patch, which materializes the duplicate outer and >>> inner Iterables first into a list. It removes the entire >>> section of the CompoundIterator iteration from the profile. >>> >>> webrev: >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >>> >>> I'm not sure it's the absolutely correct solution as it >>> possibly masks an underlying issue. >>> >>> I'm still seeing some time spent in >>> MethodSymbol.overrides, Types.isSubSignature, and >>> Types.memberType, all of which happen in the inner loop. >>> If we can remove those and collapse the nested loops >>> into one, then this solution isn't necessary and it >>> would also solve that performance issue. >>> >>> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >>> > >>> wrote: >>> >>> I still have more to investigate to fully wrap my >>> head around it, but I finally found a sample program >>> that exhibits this. Filed a bug here: >>> https://bugs.openjdk.java.net/browse/JDK-8224161 >>> >>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >>> >> > wrote: >>> >>> Hi Ron, >>> >>> I am afraid it is hard to guess what is the >>> problem without some >>> testcase. So, at least to me, having a sample >>> would be helpful. >>> >>> Thanks, >>> ? ? ?Jan >>> >>> On 17. 05. 19 0:41, Ron Shapiro wrote: >>> > Hi, >>> > >>> > I'm observing a particularly bizarre >>> compilation. It's a single file >>> > with annotation processing, and the type that >>> is being compiled and >>> > processed has ~1000 declared and inherited >>> methods combined. The total >>> > compilation is 3 minutes, but 65% of the >>> entire compilation is spent in >>> > 3 methods: >>> > >>> Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), >>> >>> > and?Resolve.findField(). >>> > >>> > Looking at profiles, it looks like >>> getSymbolsByName() is the major >>> > culprit here. I initially thought the reason >>> was that there were far too >>> > many overloads (this type had >600 >>> overloads...) and that that was >>> > causing a bad regression for the >>> pseudo-hashmap that ScopeImpl uses. >>> > However, renaming the methods did not >>> alleviate the build pain and these >>> > methods continue to be taking long amounts of >>> time. >>> > >>> > I was wondering what could be done to improve >>> the performance of this >>> > code. It seemed to me that something like a >>> Map> >>> > could be a reasonable+modern replacement for >>> this table, which would >>> > naturally have a fast getSymbolsForName() >>> implementation. I'm having >>> > some trouble implementing it correctly, and I >>> believe it's partially >>> > related to not fully understanding some of the >>> semantics of the class. >>> > >>> > Does what I wrote make sense to anyone, and >>> maybe spark a lightbulb? >>> > >>> > I'm trying to put together a repro in case >>> that helps, but I'm not 100% >>> > sure I even understand what the regression >>> case is. >>> > >>> > Thanks for you help! >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Tue May 21 21:10:31 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 21 May 2019 18:10:31 -0300 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <5CE43F5E.1050102@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> <5CE43F5E.1050102@oracle.com> Message-ID: <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com> Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 > On May 21, 2019, at 3:11 PM, Alex Buckley wrote: > > On 5/21/2019 7:56 AM, Jim Laskey wrote: >> Please do a code review of the new String::stripIndent instance method. > > My interest is in the API spec because the JLS will make normative reference to it. > > > "Removes horizontal white space margins from the essential body of a > Text Block originated string, while preserving relative indentation." > > Lots of concepts here: margins, "essential body", a "Text Block originated string" (not just any string?). Looks like the removal happens in-place. While "essential" is a concept from the JEP, I think the sibling concept, "incidental", is the one to lead with. Alluding to multiple lines is also good. Recommend: > > "Returns a string whose value is this string, with incidental white space removed from the beginning and end of every line." > > That is, 'stripIndent' isn't quite as generic as its name suggests. It implements a particular policy about "incidental" white space that we will now explain... > > > New paragraph: "Incidental white space is often present in a text block to align the content with the opening delimiter. For example, in the following code, dots represent incidental white space: > > String html = """ > .............. > .............. > ..............

Hello, world

> .............. > .............. > .............."""; > > > Another new para, to link this high-falutin' incidental concept to the workmanlike name of this method: "This method treats the incidental white space as indentation to be stripped, producing a string that preserves the relative indentation of the content. Using | to visualize the start of each line of the string: > > | > | > |

Hello, world

> | > | > > > Now, the algo. "This string is first conceptually separated into lines as if by {@link String#lines()}." -- phrasing: "First, this string is conceptually ..." > > > "Then, the minimum indentation (min) is determined as follows. For each non-blank line (as defined by {@link String#isBlank()}), the > leading {@link Character#isWhitespace(int) white space} characters are > counted. The leading {@link Character#isWhitespace(int) white space} characters on the last line are are also counted even if blank. > The min value is the smallest of these counts." > > No more "common white space prefix" like in the JEP? OK, fair enough, we're now fully rotated to "indentation" rather than "white space". > > > "For each non-blank line, min leading white space characters are > removed. Each white space character is treated as a single character. In > particular, the tab character {@code "\t"} (U+0009) is considered a > single character; it is not expanded. > > The trailing white space of each line is also removed." > > The trailing white space characters are just as "treated as a single character" as the leading white space characters. Recommend: "For each non-blank line, min leading white space characters are removed, and any trailing white space characters are removed." > > > Recommend handling escape sequences in a separate para. Showing "\t", a two character sequence, and then alluding to \u0009, a single character, is confusing. > > > "Each line is suffixed with a line feed character {@code "\n"} (U+000A), > except for the last line. The last line is suffixed with a line feed > character {@code "\n"} (U+000A) only if the original last line was blank." > > The phrasing "except for the last line" is odd because it suggests the last line never gets a suffix. Except, oh, it might. And "suffixed" is an unusual word. If you're going to allude to the original string's last line, then isn't there a way to lean on it more? e.g. "A line feed character is appended to every line if the corresponding line in the original string was terminated with a line feed character." (Not saying that is correct or desirable, but is easier to visualize.) > > > "Finally, the lines are concatenated into a single string and returned." > > Recommend: "Finally, the lines are concatenated into a string, which is the result." > > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue May 21 23:19:13 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 21 May 2019 16:19:13 -0700 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> <5CE43F5E.1050102@oracle.com> <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com> Message-ID: <5CE48771.6030509@oracle.com> On 5/21/2019 2:10 PM, Jim Laskey wrote: > Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 This webrev substantially updates the API spec, which is really a topic for amber-spec-experts (keep reading to see why). Cross-posting between -dev and -spec-experts lists is not good, so maybe we can wrap this up here without prolonged discussion. API spec looks good, but it was a surprise to learn that stripIndent performs normalization of line terminators: "@return string with margins removed and line terminators normalized" The processing steps in the JEP (and the JLS) are clear that normalization happens before incidental white space removal. I realize that stripIndent performs separation and joining in such a way as to produce a string that looks like it was normalized prior to stripIndent, so the @return isn't wrong, but it's still confusing to make a big deal of normalization-first only for stripIndent to suggest normalization-last. I think we should leave the JEP alone, since it interleaves behavior with motivation and examples in order to aid the reader, but we should align the JLS with the API: ----- The string represented by a text block is not the literal sequence of characters in the content. Instead, the string represented by a text block is the result of applying the following transformations to the content, in order: 1. _Incidental white space_ is removed and line terminators are _normalized_, as if by execution of String::stripIndent on the characters in the content. [The emphasized terms are a hint to the API spec to define the term, which is not currently the case for the second term.] 2. Escape sequences are interpreted, as in a string literal. ----- String::indent also says "normalizes line termination characters" without defining it. Separately, String::stripIndent is not at all like the strip, stripLeading, and stripTrailing methods which sound related to it -- they would pointlessly strip the first row of white space dots from a multi-line string and leave the other rows. Taking all this together, I think it's time to upgrade the class-level spec of String: to advertise the new methods added in 11+, and to show text blocks, and to get some terms defined for the benefit of multiple methods. I realize this wasn't on your radar, but it's inevitable -- the same thing happened for the class-level spec of Class when nestmates were introduced. So, here goes: ----- The String class represents character strings. ~~All~~ String literals **and text blocks** in Java programs ~~, such as "abc",~~ are implemented as instances of this class. The strings represented this class are constant; their values cannot be changed after they are created. (For mutable strings, see StringBuffer and StringBuilder.) Because instances of `String` are immutable, they can be shared. For example: ... [The example with a char[] is quite subtle for a beginner, but I'm skipping over it right now.] The class String includes methods for examining individual characters of the sequence, for comparing strings, for searching strings, for extracting substrings, and for creating a copy of a string with all characters translated to uppercase or to lowercase. Case mapping is based on the Unicode Standard version specified by the Character class. Here are some examples of how strings can be used: System.out.println("abc"); String cde = "cde"; String c = "abc".substring(2,3); String d = cde.substring(1, 2); Unless otherwise noted, methods for comparing Strings do not take locale into account. The Collator class provides methods for finer-grain, locale-sensitive String comparison. Unless otherwise noted, passing a null argument to a constructor or method in this class will cause a NullPointerException to be thrown. [This doesn't fit anywhere. j.l.Character doesn't bother with it, even though its methods throw NPEs too. Maybe time to drop. We have lots more important stuff to say.] ### String concatenation The Java language provides special support for the string concatenation operator (`+`), and for conversion of other objects to strings. For additional information on string concatenation and conversion, see The Java? Language Specification. [Somehow this manages to skip the valueOf methods, which in conjunction with things like Integer::parseInt are worthy of a paragraph by themselves. Future work.] Here are some examples of string concatenation: String cde = "cde"; System.out.println("abc" + cde); [These examples are dull, and don't describe their output, and need to show text blocks. Future work.] ### String processing The strings represented by this class may span multiple lines by including _line terminators_ among their characters. A line terminator is one of the following: a line feed character LF (U+000A), a carriage return character CR (U+000D), or a carriage return followed immediately by a line feed CRLF (U+000D U+000A). [Don't want to show escape sequences like \n yet.] A string has _normalized_ line terminators if LF is the only line terminator which appears in the string. Many methods of this class _normalize_ the strings they return by ensuring that CR and CRLF are translated to LF. The class String also includes methods for manipulating non-alphanumeric characters in strings, such as converting escape sequences into non-graphic characters, and stripping white space. [This paragraph is a jumping off point for describing stripIndent's special relationship with text blocks.] ### Unicode A String represents a string in the UTF-16 format in which supplementary characters are represented by surrogate pairs (see the section Unicode Character Representations in the Character class for more information). Index values refer to char code units, so a supplementary character uses two positions in a String. The String class provides methods for dealing with Unicode code points (i.e., characters), in addition to those for dealing with Unicode code units (i.e., char values). ----- Alex From brent.christian at oracle.com Tue May 21 23:15:22 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 21 May 2019 16:15:22 -0700 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com> Message-ID: <59ddca70-013e-07d7-ede4-09f1a9c15456@oracle.com> Hi, Jim I have some comments on the CSR and the Webrev. CSR: ==== "This method takes the receiver String a replaces escape sequences with character equivalents." a -> and -- In the specification, I like emphasizing that nothing happens to 'this', but rather to the returned string, so maybe something like: "Returns a string with all escape sequences translated into characters represented by..." Webrev: ======= src/java.base/share/classes/java/lang/String.java 3006 case '\'': case '\"': case '\\': I would find this easier to read with one case per line, so: case '\'': case '\"': case '\\': break; test/jdk/java/lang/String/TranslateEscapes.java The test should cover octal escapes, and cases that throw IllegalArgumentException. Why does the test need to run in othervm ? Thanks, -Brent On 5/21/19 12:24 PM, Jim Laskey wrote: > Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html > > > >> On May 21, 2019, at 3:23 PM, Jim Laskey wrote: >> >> >> >>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov wrote: >>> >>> Hi Jim! >>> >>> A few comments: >>> >>> 1) >>> Probably, there's no need to update ch in these cases: >>> case '\'': >>> ch = '\''; >>> break; >>> case '\"': >>> ch = '\"'; >>> break; >> >> True >> >>> >>> 2) >>> Character.digit(ch, 8) will accept non-Latin1 digits. >>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377. >>> (Note, that the first digit still can only be from range '0'-'9'). >> >> Also true. Subtlety in UnicodeReader. >> >>> >>> 3) >>> It's not obvious how this condition can be triggered: >>> if (0377 < code) { >>> throw new MalformedEscapeException(from); >>> } >>> I might be missing something, but I cannot see how 'code' can become > 0377. >> >> I removed this check in round 2. >> >>> >>> 4) >>> throw new MalformedEscapeException(from); >>> This will report the next index after the error. Was it intentional? >>> >> >> I switched to using an IllegalArgumentError and displaying the actual character. >> >> >>> With kind regards, >>> Ivan >> >> Much thanks. >> >> >>> >>> >>> On 5/21/19 7:56 AM, Jim Laskey wrote: >>>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. >>>> >>>> Thank you. >>>> >>>> -- Jim >>>> >>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 >>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 >>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 >>>> >>>> >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >> > From joe.darcy at oracle.com Wed May 22 00:55:54 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 21 May 2019 17:55:54 -0700 Subject: JDK 13 RFR of JDK-8224177: Harden annotation processing framework to irregular behavior from processors In-Reply-To: <7ad3b855-fe2d-6391-3a1b-88b5df0939b4@oracle.com> References: <7ad3b855-fe2d-6391-3a1b-88b5df0939b4@oracle.com> Message-ID: <5CE49E1A.9090708@oracle.com> Hello, Updated with test cases so that CheckExamples.java will pass for the new messages: http://cr.openjdk.java.net/~darcy/8224177.1 Thanks, -Joe On 5/19/2019 11:36 PM, Joe Darcy wrote: > Hello, > > As a complement to the changes in AbstractProcessor done under > JDK-8146726 , the annotation processing framework in javac could be > hardened against various kinds of irregular results returned from > processors. The hardening can include just warning about redundant but > not strictly incorrect information. > > Webrev at: > > http://cr.openjdk.java.net/~darcy/8224177.0/ > > Most of the code changes in JavacProcessingEnvironment are to guard > against misbehaving Set implementations returned from Processors; > perhaps this is an unnecessary degree of caution. > > There may be other test updates needed for account for the new > warnings messages; I'll make any such update once there is review > feedback and agreement on (what subset of) this change's checks should > go back. > > Thanks, > > -Joe > From fweimer at redhat.com Wed May 22 08:21:54 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 22 May 2019 10:21:54 +0200 Subject: RFR - JDK-8203444 String::formatted (Preview) In-Reply-To: <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com> (Jim Laskey's message of "Tue, 21 May 2019 12:56:11 -0300") References: <9489E03F-4F27-4520-B19C-3972035CED6D@oracle.com> <8736l798cu.fsf@oldenburg2.str.redhat.com> <52D62A3A-97D9-4A0D-AA9A-EF76810D22E8@oracle.com> <87h89n7qxv.fsf@oldenburg2.str.redhat.com> <664BC60B-C09A-4F4F-8045-A70B1DF09401@oracle.com> Message-ID: <87imu26grh.fsf@oldenburg2.str.redhat.com> * Jim Laskey: > Good point. To make sure I fully understand what you are stating, > > - The argument for having an instance method is reasonable to achieve > "flowiness". Right. > - However, only one version is necessary or desired, that is, "public > String formatted(Object... args)". Yes, this appears to be the common use case to me. I doubt the overload with its ambiguity is sufficiently widely used to be worth the potential confusion it can create. Adding the method with the Locale parameter under a different name would be okay (except that I'm not sure how widely it is going to be used). My totally random set of Java classes (mostly from Fedora and downstream) shows this: SELECT jr.descriptor, COUNT(*) descriptor FROM symboldb.java_reference jr WHERE jr.class_name = 'java/lang/String' AND jr.name = 'format' GROUP BY jr.descriptor; descriptor | descriptor -----------------------------------------------------------------------------+------------ (Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String; | 9220 (Ljava/util/Locale;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String; | 436 (2 rows) So for the existing String::format method, the version without the explicit Locale argument is much more commonly used. > - In cases where Locale needs to be overridden, then either use > "String.format(Locale lc, String fmt, Object... args)" or globally set > "Locale.setDefault(Locale lc)". I wouldn't recommend changing global state in this way. Thanks, Florian From maurizio.cimadamore at oracle.com Wed May 22 10:24:02 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 22 May 2019 11:24:02 +0100 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: This doesn't work. You are basically relying on the order in which symbols are entered in the members closure scope. In simple example like these: class A { ??? int m(List l) {return 0;} } class B extends A { ?? int m(List l) {return 0;} } The logic you proposed will not work. That's because we first see B::m - and 'symbolByName' is empty at that stage; so we add it there. Then we do another round and see A::m - but we don't really look there - given that we first check to see if the symbol we're considering (sym) is override-equivalent with B::m (the only symbol in symbolByName). And that happens to be the case, since they are the same symbol. So we exit the loop, w/o having found any clash. In other words, symbolByName would need to also contain A::m for the code to see the clash - but that never happens; by the time A::m is added, is already too late. I think caching the result of types.membersClosure(site, false).getSymbolsByName(sym.name, cf) is a good measure. I'm a bit surprised that iteration is so slow (membersClosure is slow to set up, but once you do it the results are cached). So, rather than tweaking the algorithm, I think it'd be better to investigate the reason was to why asking a compound scope iterator is so slow, which then would yield dividends for the rest of the code as well. Maurizio On 21/05/2019 21:21, Maurizio Cimadamore wrote: > > I see what you have done - I have to think about it a bit to see if I > can come up with some counter example. > > Thanks > Maurizio > > On 21/05/2019 17:39, Ron Shapiro wrote: >> Are the checks of the inner loop symmetrical? >> >> Currently it's checking m_i against (m_0..n - m_i ). This second >> webrev below would check it against just?(m_0..i-1 ), which albeit >> still n^2, it divides by a factor of 2. >> >> (sorry if the subscripting here doesn't display correctly) >> >> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ >> >> This feels conceptually logical to me, but I'm not seeing a >> measurable?change by it. It looks a little bit cleaner to me, but I'm >> fine with either webrev given the benefits they both bring. >> >> I can take a look in another thread about speeding up CompoundScope >> iteration. >> >> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore >> > > wrote: >> >> >> On 21/05/2019 12:16, Ron Shapiro wrote: >>> I still think that something to optimize the actual ScopeImpl >>> Iterable is a worthwhile endeavor, as that would alleviate the >>> need to materialize here (and solve hopefully the other issues >>> I'm seeing), but I was having trouble figuring out how to do >>> that. This may be a good interim option without much cost. >> >> Sure - I'm not opposed to optimizing the iteration process - I >> was expressing my skepticism w.r.t. making checkOverrideClash >> simpler/non quadratic. >> >> Maurizio >> >>> >>> >>> >>> On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore >>> >> > wrote: >>> >>> I think your fix is a good one. We spent some cycles >>> optimizing this, a bit odd we have missed this :-) >>> >>> I'm very skeptical you can collapse into a single loop, as >>> this implement the logic in JLS 8.4.8.3 [1] which, as you >>> can see, is inherently quadratic (for each method, we have >>> to scan all methods with same name in supertypes to see if >>> there is an override clash). The algorithm that was there >>> before wasn't - and it lead to the wrong answers in tricky >>> cases - so while you can get 80% there with a non-quadratic >>> algorithm, you will miss issues by doing so. >>> >>> One thing that would help would be, instead, to limit the >>> analysis only in cases where it adds value - for instance, >>> if your hierarchy is just non-generic classes (as in your >>> example), then there's no way for you to accidentally >>> override a 'bridge' method, since no bridges will be >>> generated! But when looking at this, I couldn't find great >>> ways to detect these conditions w/o spending more time than >>> the check itself. >>> >>> [1] - >>> https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 >>> >>> Maurizio >>> >>> On 20/05/2019 21:58, Ron Shapiro wrote: >>>> In the real world example, I'm seeing the 40s that was >>>> previously spent in Check.checkOverrideClashes drop to to >>>> 9.5s when using this patch. Of that 9.5, 8.9 is spent in >>>> iterating through the CompoundIterator and calling >>>> getSymbolsByName. >>>> >>>> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro >>>> > wrote: >>>> >>>> This patch, which materializes the duplicate outer and >>>> inner Iterables first into a list. It removes the >>>> entire section of the CompoundIterator iteration from >>>> the profile. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >>>> >>>> I'm not sure it's the absolutely correct solution as it >>>> possibly masks an underlying issue. >>>> >>>> I'm still seeing some time spent in >>>> MethodSymbol.overrides, Types.isSubSignature, and >>>> Types.memberType, all of which happen in the inner >>>> loop. If we can remove those and collapse the nested >>>> loops into one, then this solution isn't necessary and >>>> it would also solve that performance issue. >>>> >>>> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >>>> > >>>> wrote: >>>> >>>> I still have more to investigate to fully wrap my >>>> head around it, but I finally found a sample >>>> program that exhibits this. Filed a bug here: >>>> https://bugs.openjdk.java.net/browse/JDK-8224161 >>>> >>>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >>>> >>> > wrote: >>>> >>>> Hi Ron, >>>> >>>> I am afraid it is hard to guess what is the >>>> problem without some >>>> testcase. So, at least to me, having a sample >>>> would be helpful. >>>> >>>> Thanks, >>>> ? ? ?Jan >>>> >>>> On 17. 05. 19 0:41, Ron Shapiro wrote: >>>> > Hi, >>>> > >>>> > I'm observing a particularly bizarre >>>> compilation. It's a single file >>>> > with annotation processing, and the type that >>>> is being compiled and >>>> > processed has ~1000 declared and inherited >>>> methods combined. The total >>>> > compilation is 3 minutes, but 65% of the >>>> entire compilation is spent in >>>> > 3 methods: >>>> > >>>> Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), >>>> >>>> > and?Resolve.findField(). >>>> > >>>> > Looking at profiles, it looks like >>>> getSymbolsByName() is the major >>>> > culprit here. I initially thought the reason >>>> was that there were far too >>>> > many overloads (this type had >600 >>>> overloads...) and that that was >>>> > causing a bad regression for the >>>> pseudo-hashmap that ScopeImpl uses. >>>> > However, renaming the methods did not >>>> alleviate the build pain and these >>>> > methods continue to be taking long amounts of >>>> time. >>>> > >>>> > I was wondering what could be done to improve >>>> the performance of this >>>> > code. It seemed to me that something like a >>>> Map> >>>> > could be a reasonable+modern replacement for >>>> this table, which would >>>> > naturally have a fast getSymbolsForName() >>>> implementation. I'm having >>>> > some trouble implementing it correctly, and I >>>> believe it's partially >>>> > related to not fully understanding some of >>>> the semantics of the class. >>>> > >>>> > Does what I wrote make sense to anyone, and >>>> maybe spark a lightbulb? >>>> > >>>> > I'm trying to put together a repro in case >>>> that helps, but I'm not 100% >>>> > sure I even understand what the regression >>>> case is. >>>> > >>>> > Thanks for you help! >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed May 22 13:06:16 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 22 May 2019 15:06:16 +0200 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: Sorry, I was too busy last few days. I was peeking at some possible improvements, but I think I like Ron's first (.00) patch - that caches what can be cached nicely. Looking at the testcase generated by Ron's reproducer using: python test.py 7 and the (biggest) size of the outcome of: types.membersClosure(site, false).getSymbolsByName(sym.name, cf) seems to be 13700 elements - which means the Scope lookup and iteration runs ~13700 times, so avoiding these additional lookup costs seems like a clear win. I have an idea that might speed up the iterations through deeply nested CompoundScopes, although the effect of that in combination with Ron's is going to be fairly limited, if any, I think. Jan On 22. 05. 19 12:24, Maurizio Cimadamore wrote: > This doesn't work. You are basically relying on the order in which > symbols are entered in the members closure scope. > > In simple example like these: > > class A { > ??? int m(List l) {return 0;} > } > > class B extends A { > ?? int m(List l) {return 0;} > } > > > The logic you proposed will not work. That's because we first see B::m - > and 'symbolByName' is empty at that stage; so we add it there. Then we > do another round and see A::m - but we don't really look there - given > that we first check to see if the symbol we're considering (sym) is > override-equivalent with B::m (the only symbol in symbolByName). And > that happens to be the case, since they are the same symbol. So we exit > the loop, w/o having found any clash. > > In other words, symbolByName would need to also contain A::m for the > code to see the clash - but that never happens; by the time A::m is > added, is already too late. > > > I think caching the result of > > types.membersClosure(site, false).getSymbolsByName(sym.name, cf) > > is a good measure. > > I'm a bit surprised that iteration is so slow (membersClosure is slow to > set up, but once you do it the results are cached). So, rather than > tweaking the algorithm, I think it'd be better to investigate the reason > was to why asking a compound scope iterator is so slow, which then would > yield dividends for the rest of the code as well. > > Maurizio > > > On 21/05/2019 21:21, Maurizio Cimadamore wrote: >> >> I see what you have done - I have to think about it a bit to see if I >> can come up with some counter example. >> >> Thanks >> Maurizio >> >> On 21/05/2019 17:39, Ron Shapiro wrote: >>> Are the checks of the inner loop symmetrical? >>> >>> Currently it's checking m_i against (m_0..n - m_i ). This second >>> webrev below would check it against just?(m_0..i-1 ), which albeit >>> still n^2, it divides by a factor of 2. >>> >>> (sorry if the subscripting here doesn't display correctly) >>> >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ >>> >>> This feels conceptually logical to me, but I'm not seeing a >>> measurable?change by it. It looks a little bit cleaner to me, but I'm >>> fine with either webrev given the benefits they both bring. >>> >>> I can take a look in another thread about speeding up CompoundScope >>> iteration. >>> >>> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore >>> >> > wrote: >>> >>> >>> On 21/05/2019 12:16, Ron Shapiro wrote: >>>> I still think that something to optimize the actual ScopeImpl >>>> Iterable is a worthwhile endeavor, as that would alleviate the >>>> need to materialize here (and solve hopefully the other issues >>>> I'm seeing), but I was having trouble figuring out how to do >>>> that. This may be a good interim option without much cost. >>> >>> Sure - I'm not opposed to optimizing the iteration process - I >>> was expressing my skepticism w.r.t. making checkOverrideClash >>> simpler/non quadratic. >>> >>> Maurizio >>> >>>> >>>> >>>> >>>> On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore >>>> >>> > wrote: >>>> >>>> I think your fix is a good one. We spent some cycles >>>> optimizing this, a bit odd we have missed this :-) >>>> >>>> I'm very skeptical you can collapse into a single loop, as >>>> this implement the logic in JLS 8.4.8.3 [1] which, as you >>>> can see, is inherently quadratic (for each method, we have >>>> to scan all methods with same name in supertypes to see if >>>> there is an override clash). The algorithm that was there >>>> before wasn't - and it lead to the wrong answers in tricky >>>> cases - so while you can get 80% there with a non-quadratic >>>> algorithm, you will miss issues by doing so. >>>> >>>> One thing that would help would be, instead, to limit the >>>> analysis only in cases where it adds value - for instance, >>>> if your hierarchy is just non-generic classes (as in your >>>> example), then there's no way for you to accidentally >>>> override a 'bridge' method, since no bridges will be >>>> generated! But when looking at this, I couldn't find great >>>> ways to detect these conditions w/o spending more time than >>>> the check itself. >>>> >>>> [1] - >>>> https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 >>>> >>>> Maurizio >>>> >>>> On 20/05/2019 21:58, Ron Shapiro wrote: >>>>> In the real world example, I'm seeing the 40s that was >>>>> previously spent in Check.checkOverrideClashes drop to to >>>>> 9.5s when using this patch. Of that 9.5, 8.9 is spent in >>>>> iterating through the CompoundIterator and calling >>>>> getSymbolsByName. >>>>> >>>>> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro >>>>> > wrote: >>>>> >>>>> This patch, which materializes the duplicate outer and >>>>> inner Iterables first into a list. It removes the >>>>> entire section of the CompoundIterator iteration from >>>>> the profile. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >>>>> >>>>> I'm not sure it's the absolutely correct solution as it >>>>> possibly masks an underlying issue. >>>>> >>>>> I'm still seeing some time spent in >>>>> MethodSymbol.overrides, Types.isSubSignature, and >>>>> Types.memberType, all of which happen in the inner >>>>> loop. If we can remove those and collapse the nested >>>>> loops into one, then this solution isn't necessary and >>>>> it would also solve that performance issue. >>>>> >>>>> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >>>>> > >>>>> wrote: >>>>> >>>>> I still have more to investigate to fully wrap my >>>>> head around it, but I finally found a sample >>>>> program that exhibits this. Filed a bug here: >>>>> https://bugs.openjdk.java.net/browse/JDK-8224161 >>>>> >>>>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >>>>> >>>> > wrote: >>>>> >>>>> Hi Ron, >>>>> >>>>> I am afraid it is hard to guess what is the >>>>> problem without some >>>>> testcase. So, at least to me, having a sample >>>>> would be helpful. >>>>> >>>>> Thanks, >>>>> ? ? ?Jan >>>>> >>>>> On 17. 05. 19 0:41, Ron Shapiro wrote: >>>>> > Hi, >>>>> > >>>>> > I'm observing a particularly bizarre >>>>> compilation. It's a single file >>>>> > with annotation processing, and the type that >>>>> is being compiled and >>>>> > processed has ~1000 declared and inherited >>>>> methods combined. The total >>>>> > compilation is 3 minutes, but 65% of the >>>>> entire compilation is spent in >>>>> > 3 methods: >>>>> > >>>>> Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), >>>>> >>>>> > and?Resolve.findField(). >>>>> > >>>>> > Looking at profiles, it looks like >>>>> getSymbolsByName() is the major >>>>> > culprit here. I initially thought the reason >>>>> was that there were far too >>>>> > many overloads (this type had >600 >>>>> overloads...) and that that was >>>>> > causing a bad regression for the >>>>> pseudo-hashmap that ScopeImpl uses. >>>>> > However, renaming the methods did not >>>>> alleviate the build pain and these >>>>> > methods continue to be taking long amounts of >>>>> time. >>>>> > >>>>> > I was wondering what could be done to improve >>>>> the performance of this >>>>> > code. It seemed to me that something like a >>>>> Map> >>>>> > could be a reasonable+modern replacement for >>>>> this table, which would >>>>> > naturally have a fast getSymbolsForName() >>>>> implementation. I'm having >>>>> > some trouble implementing it correctly, and I >>>>> believe it's partially >>>>> > related to not fully understanding some of >>>>> the semantics of the class. >>>>> > >>>>> > Does what I wrote make sense to anyone, and >>>>> maybe spark a lightbulb? >>>>> > >>>>> > I'm trying to put together a repro in case >>>>> that helps, but I'm not 100% >>>>> > sure I even understand what the regression >>>>> case is. >>>>> > >>>>> > Thanks for you help! >>>>> From james.laskey at oracle.com Wed May 22 13:23:18 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 22 May 2019 10:23:18 -0300 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: <59ddca70-013e-07d7-ede4-09f1a9c15456@oracle.com> References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com> <59ddca70-013e-07d7-ede4-09f1a9c15456@oracle.com> Message-ID: Thank you. Will integrate your suggested changes. > On May 21, 2019, at 8:15 PM, Brent Christian wrote: > > Hi, Jim > > I have some comments on the CSR and the Webrev. > > > CSR: > ==== > > "This method takes the receiver String a replaces escape sequences with character equivalents." > > a -> and > > -- > > In the specification, I like emphasizing that nothing happens to 'this', but rather to the returned string, so maybe something like: > > "Returns a string with all escape sequences translated into characters represented by..." > > > Webrev: > ======= > > src/java.base/share/classes/java/lang/String.java > > 3006 case '\'': case '\"': case '\\': > > I would find this easier to read with one case per line, so: > > case '\'': > case '\"': > case '\\': > break; > > > test/jdk/java/lang/String/TranslateEscapes.java > > > The test should cover octal escapes, and cases that throw IllegalArgumentException. > > Why does the test need to run in othervm ? > > Thanks, > -Brent > > > On 5/21/19 12:24 PM, Jim Laskey wrote: >> Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html >>> On May 21, 2019, at 3:23 PM, Jim Laskey wrote: >>> >>> >>> >>>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov wrote: >>>> >>>> Hi Jim! >>>> >>>> A few comments: >>>> >>>> 1) >>>> Probably, there's no need to update ch in these cases: >>>> case '\'': >>>> ch = '\''; >>>> break; >>>> case '\"': >>>> ch = '\"'; >>>> break; >>> >>> True >>> >>>> >>>> 2) >>>> Character.digit(ch, 8) will accept non-Latin1 digits. >>>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377. >>>> (Note, that the first digit still can only be from range '0'-'9'). >>> >>> Also true. Subtlety in UnicodeReader. >>> >>>> >>>> 3) >>>> It's not obvious how this condition can be triggered: >>>> if (0377 < code) { >>>> throw new MalformedEscapeException(from); >>>> } >>>> I might be missing something, but I cannot see how 'code' can become > 0377. >>> >>> I removed this check in round 2. >>> >>>> >>>> 4) >>>> throw new MalformedEscapeException(from); >>>> This will report the next index after the error. Was it intentional? >>>> >>> >>> I switched to using an IllegalArgumentError and displaying the actual character. >>> >>> >>>> With kind regards, >>>> Ivan >>> >>> Much thanks. >>> >>> >>>> >>>> >>>> On 5/21/19 7:56 AM, Jim Laskey wrote: >>>>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. >>>>> >>>>> Thank you. >>>>> >>>>> -- Jim >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 >>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 >>>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 >>>>> >>>>> >>>> >>>> -- >>>> With kind regards, >>>> Ivan Gerasimov >>>> >>> From jan.lahoda at oracle.com Wed May 22 13:31:00 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 22 May 2019 15:31:00 +0200 Subject: RFR: JDK-8223967: Implement Text Blocks (Preview) in the Java compiler In-Reply-To: <6F3AC564-9326-447F-8CA1-05BD2B6164D1@oracle.com> References: <9A742B12-1490-4A17-82DB-4174F49064FC@oracle.com> <6F3AC564-9326-447F-8CA1-05BD2B6164D1@oracle.com> Message-ID: <83ab5ad1-07ed-29c8-227b-17c3209dc9f2@oracle.com> Looks OK to me. Do we want to include changes for JShell here as well? Thanks, Jan On 20. 05. 19 20:46, Jim Laskey wrote: > Updated after first round review. > > webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-02/index.html > > >> On May 20, 2019, at 9:58 AM, Jim Laskey > > wrote: >> >> Please review for Text Blocks. >> >> -- Jim >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-01/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223967 >> > From james.laskey at oracle.com Wed May 22 13:58:31 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 22 May 2019 10:58:31 -0300 Subject: RFR: JDK-8223967: Implement Text Blocks (Preview) in the Java compiler In-Reply-To: <83ab5ad1-07ed-29c8-227b-17c3209dc9f2@oracle.com> References: <9A742B12-1490-4A17-82DB-4174F49064FC@oracle.com> <6F3AC564-9326-447F-8CA1-05BD2B6164D1@oracle.com> <83ab5ad1-07ed-29c8-227b-17c3209dc9f2@oracle.com> Message-ID: <4A9F52AC-28B5-49DA-8671-58F3087CC291@oracle.com> That is covered by a separate bug https://bugs.openjdk.java.net/browse/JDK-8223782, but we could coordinate the push. -- Jim > On May 22, 2019, at 10:31 AM, Jan Lahoda wrote: > > Looks OK to me. Do we want to include changes for JShell here as well? > > Thanks, > Jan > > On 20. 05. 19 20:46, Jim Laskey wrote: >> Updated after first round review. >> webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-02/index.html >>> On May 20, 2019, at 9:58 AM, Jim Laskey > wrote: >>> >>> Please review for Text Blocks. >>> >>> -- Jim >>> >>> webrev: http://cr.openjdk.java.net/~jlaskey/8223967/webrev-01/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223967 >>> From ronshapiro at google.com Wed May 22 15:00:23 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 22 May 2019 11:00:23 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: I think there still would be benefit in that as well, as I'm seeing that come up in other contexts (as referenced in the bug). On Wed, May 22, 2019 at 9:06 AM Jan Lahoda wrote: > Sorry, I was too busy last few days. > > I was peeking at some possible improvements, but I think I like Ron's > first (.00) patch - that caches what can be cached nicely. > > Looking at the testcase generated by Ron's reproducer using: > python test.py 7 > > and the (biggest) size of the outcome of: > types.membersClosure(site, false).getSymbolsByName(sym.name, cf) > > seems to be 13700 elements - which means the Scope lookup and iteration > runs ~13700 times, so avoiding these additional lookup costs seems like > a clear win. > > I have an idea that might speed up the iterations through deeply nested > CompoundScopes, although the effect of that in combination with Ron's is > going to be fairly limited, if any, I think. > > Jan > > On 22. 05. 19 12:24, Maurizio Cimadamore wrote: > > This doesn't work. You are basically relying on the order in which > > symbols are entered in the members closure scope. > > > > In simple example like these: > > > > class A { > > int m(List l) {return 0;} > > } > > > > class B extends A { > > int m(List l) {return 0;} > > } > > > > > > The logic you proposed will not work. That's because we first see B::m - > > and 'symbolByName' is empty at that stage; so we add it there. Then we > > do another round and see A::m - but we don't really look there - given > > that we first check to see if the symbol we're considering (sym) is > > override-equivalent with B::m (the only symbol in symbolByName). And > > that happens to be the case, since they are the same symbol. So we exit > > the loop, w/o having found any clash. > > > > In other words, symbolByName would need to also contain A::m for the > > code to see the clash - but that never happens; by the time A::m is > > added, is already too late. > > > > > > I think caching the result of > > > > types.membersClosure(site, false).getSymbolsByName(sym.name, cf) > > > > is a good measure. > > > > I'm a bit surprised that iteration is so slow (membersClosure is slow to > > set up, but once you do it the results are cached). So, rather than > > tweaking the algorithm, I think it'd be better to investigate the reason > > was to why asking a compound scope iterator is so slow, which then would > > yield dividends for the rest of the code as well. > > > > Maurizio > > > > > > On 21/05/2019 21:21, Maurizio Cimadamore wrote: > >> > >> I see what you have done - I have to think about it a bit to see if I > >> can come up with some counter example. > >> > >> Thanks > >> Maurizio > >> > >> On 21/05/2019 17:39, Ron Shapiro wrote: > >>> Are the checks of the inner loop symmetrical? > >>> > >>> Currently it's checking m_i against (m_0..n - m_i ). This second > >>> webrev below would check it against just (m_0..i-1 ), which albeit > >>> still n^2, it divides by a factor of 2. > >>> > >>> (sorry if the subscripting here doesn't display correctly) > >>> > >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ > >>> > >>> This feels conceptually logical to me, but I'm not seeing a > >>> measurable change by it. It looks a little bit cleaner to me, but I'm > >>> fine with either webrev given the benefits they both bring. > >>> > >>> I can take a look in another thread about speeding up CompoundScope > >>> iteration. > >>> > >>> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore > >>> >>> > wrote: > >>> > >>> > >>> On 21/05/2019 12:16, Ron Shapiro wrote: > >>>> I still think that something to optimize the actual ScopeImpl > >>>> Iterable is a worthwhile endeavor, as that would alleviate the > >>>> need to materialize here (and solve hopefully the other issues > >>>> I'm seeing), but I was having trouble figuring out how to do > >>>> that. This may be a good interim option without much cost. > >>> > >>> Sure - I'm not opposed to optimizing the iteration process - I > >>> was expressing my skepticism w.r.t. making checkOverrideClash > >>> simpler/non quadratic. > >>> > >>> Maurizio > >>> > >>>> > >>>> > >>>> > >>>> On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore > >>>> >>>> > wrote: > >>>> > >>>> I think your fix is a good one. We spent some cycles > >>>> optimizing this, a bit odd we have missed this :-) > >>>> > >>>> I'm very skeptical you can collapse into a single loop, as > >>>> this implement the logic in JLS 8.4.8.3 [1] which, as you > >>>> can see, is inherently quadratic (for each method, we have > >>>> to scan all methods with same name in supertypes to see if > >>>> there is an override clash). The algorithm that was there > >>>> before wasn't - and it lead to the wrong answers in tricky > >>>> cases - so while you can get 80% there with a non-quadratic > >>>> algorithm, you will miss issues by doing so. > >>>> > >>>> One thing that would help would be, instead, to limit the > >>>> analysis only in cases where it adds value - for instance, > >>>> if your hierarchy is just non-generic classes (as in your > >>>> example), then there's no way for you to accidentally > >>>> override a 'bridge' method, since no bridges will be > >>>> generated! But when looking at this, I couldn't find great > >>>> ways to detect these conditions w/o spending more time than > >>>> the check itself. > >>>> > >>>> [1] - > >>>> > https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 > >>>> > >>>> Maurizio > >>>> > >>>> On 20/05/2019 21:58, Ron Shapiro wrote: > >>>>> In the real world example, I'm seeing the 40s that was > >>>>> previously spent in Check.checkOverrideClashes drop to to > >>>>> 9.5s when using this patch. Of that 9.5, 8.9 is spent in > >>>>> iterating through the CompoundIterator and calling > >>>>> getSymbolsByName. > >>>>> > >>>>> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro > >>>>> > > wrote: > >>>>> > >>>>> This patch, which materializes the duplicate outer and > >>>>> inner Iterables first into a list. It removes the > >>>>> entire section of the CompoundIterator iteration from > >>>>> the profile. > >>>>> > >>>>> webrev: > >>>>> > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html > >>>>> > >>>>> I'm not sure it's the absolutely correct solution as it > >>>>> possibly masks an underlying issue. > >>>>> > >>>>> I'm still seeing some time spent in > >>>>> MethodSymbol.overrides, Types.isSubSignature, and > >>>>> Types.memberType, all of which happen in the inner > >>>>> loop. If we can remove those and collapse the nested > >>>>> loops into one, then this solution isn't necessary and > >>>>> it would also solve that performance issue. > >>>>> > >>>>> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro > >>>>> > > >>>>> wrote: > >>>>> > >>>>> I still have more to investigate to fully wrap my > >>>>> head around it, but I finally found a sample > >>>>> program that exhibits this. Filed a bug here: > >>>>> https://bugs.openjdk.java.net/browse/JDK-8224161 > >>>>> > >>>>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda > >>>>> >>>>> > wrote: > >>>>> > >>>>> Hi Ron, > >>>>> > >>>>> I am afraid it is hard to guess what is the > >>>>> problem without some > >>>>> testcase. So, at least to me, having a sample > >>>>> would be helpful. > >>>>> > >>>>> Thanks, > >>>>> Jan > >>>>> > >>>>> On 17. 05. 19 0:41, Ron Shapiro wrote: > >>>>> > Hi, > >>>>> > > >>>>> > I'm observing a particularly bizarre > >>>>> compilation. It's a single file > >>>>> > with annotation processing, and the type that > >>>>> is being compiled and > >>>>> > processed has ~1000 declared and inherited > >>>>> methods combined. The total > >>>>> > compilation is 3 minutes, but 65% of the > >>>>> entire compilation is spent in > >>>>> > 3 methods: > >>>>> > > >>>>> > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), > >>>>> > >>>>> > and Resolve.findField(). > >>>>> > > >>>>> > Looking at profiles, it looks like > >>>>> getSymbolsByName() is the major > >>>>> > culprit here. I initially thought the reason > >>>>> was that there were far too > >>>>> > many overloads (this type had >600 > >>>>> overloads...) and that that was > >>>>> > causing a bad regression for the > >>>>> pseudo-hashmap that ScopeImpl uses. > >>>>> > However, renaming the methods did not > >>>>> alleviate the build pain and these > >>>>> > methods continue to be taking long amounts of > >>>>> time. > >>>>> > > >>>>> > I was wondering what could be done to improve > >>>>> the performance of this > >>>>> > code. It seemed to me that something like a > >>>>> Map> > >>>>> > could be a reasonable+modern replacement for > >>>>> this table, which would > >>>>> > naturally have a fast getSymbolsForName() > >>>>> implementation. I'm having > >>>>> > some trouble implementing it correctly, and I > >>>>> believe it's partially > >>>>> > related to not fully understanding some of > >>>>> the semantics of the class. > >>>>> > > >>>>> > Does what I wrote make sense to anyone, and > >>>>> maybe spark a lightbulb? > >>>>> > > >>>>> > I'm trying to put together a repro in case > >>>>> that helps, but I'm not 100% > >>>>> > sure I even understand what the regression > >>>>> case is. > >>>>> > > >>>>> > Thanks for you help! > >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed May 22 17:49:29 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 May 2019 10:49:29 -0700 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <5CE48771.6030509@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> <5CE43F5E.1050102@oracle.com> <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com> <5CE48771.6030509@oracle.com> Message-ID: <5CE58BA9.2090706@oracle.com> On 5/21/2019 4:19 PM, Alex Buckley wrote: > On 5/21/2019 2:10 PM, Jim Laskey wrote: >> Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 > > API spec looks good, but it was a surprise to learn that stripIndent > performs normalization of line terminators: > > "@return string with margins removed and line terminators normalized" > > The processing steps in the JEP (and the JLS) are clear that > normalization happens before incidental white space removal. I realize > that stripIndent performs separation and joining in such a way as to > produce a string that looks like it was normalized prior to stripIndent, > so the @return isn't wrong, but it's still confusing to make a big deal > of normalization-first only for stripIndent to suggest normalization-last. Stepping back, normalization is a nice thing for the multi-line-aware methods to do, but it's fundamentally just a "finishing touch". By mentioning it in the class-level spec as a general policy, we can dial back its appearance in stripIndent and indent. The rest of this mail will appear disjointed, but put it all together in the javadoc (and imagine the class-level spec explains the goals of normalization) and it'll look nice. There are some tone changes below to make the method descriptions stop talking about what's "returned" and instead flow into the @return. For stripIndent, bearing in mind that "margins" is no longer in the method summary: @return a string with no incidental white space and with line terminators normalized Description: First, the individual lines of this string are extracted as if by using lines(). [If we're going to lean on lines(), then take its concept of extraction, rather than "conceptually separating" things. In the JLS I would say "as if by the execution of lines()" but the informal "using" phrase is fine for popular javadoc.] ... Finally, the lines are joined into a new string, using the LF character (U+000A) to separate lines. [The last clause is carefully chosen. We don't want to speak of a "line separator" because we already have "line terminator". We don't want to say "using the LF character to terminate lines" because joining embodies separation, not termination; see the @param of `join`.] For indent, greater readability and consistency: ----- public String indent?(int n) Adjusts the indentation of each line of this string based on the value of n. The individual lines of this string are extracted as if by using lines(). Each line is adjusted as described below, then all the adjusted lines are joined into a new string, using the LF character (U+000A) to separate lines. If n > 0 ... If n < 0 ... If n == 0 ... Returns: a string with indentation adjusted and line terminators normalized ----- Finally, looking at lines: "Returns a stream of lines extracted from this string, separated by line terminators." makes it sound like the stream includes a line terminator element after every line element. The separation happened during the extraction, not the streaming. Recommend: "Returns a stream of lines extracted from this string, split at line terminators." Alex From joe.darcy at oracle.com Thu May 23 00:14:26 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 22 May 2019 17:14:26 -0700 Subject: JDK 13 RFR of JDK-8224628: Note that type parameters are not visited by ElementScanners Message-ID: <62b84901-fe91-879a-3886-162a66e1280d@oracle.com> Hello, Please review the spec clarification below to address ??? JDK-8224628: Note that type parameters are not visited by ElementScanners As this is not a change of the semantics of the spec, no CSR is needed. Thanks, -Joe diff -r a978d86ac389 src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java --- a/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java Mon May 20 17:29:44 2019 -0700 +++ b/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java Wed May 22 17:12:32 2019 -0700 @@ -180,6 +180,10 @@ ????? * {@inheritDoc} ????? * ????? * @implSpec This implementation scans the enclosed elements. +???? * Note that type parameters are not scanned by this +???? * implementation since type parameters are not considered to be +???? * {@linkplain TypeElement#getEnclosedElements enclosed elements +???? * of a type}. ????? * ????? * @param e? {@inheritDoc} ????? * @param p? {@inheritDoc} @@ -211,6 +215,8 @@ ????? * {@inheritDoc} ????? * ????? * @implSpec This implementation scans the parameters. +???? * Note that type parameters are not scanned by this +???? * implementation. ????? * ????? * @param e? {@inheritDoc} ????? * @param p? {@inheritDoc} From jonathan.gibbons at oracle.com Thu May 23 00:20:18 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 22 May 2019 17:20:18 -0700 Subject: JDK 13 RFR of JDK-8224628: Note that type parameters are not visited by ElementScanners In-Reply-To: <62b84901-fe91-879a-3886-162a66e1280d@oracle.com> References: <62b84901-fe91-879a-3886-162a66e1280d@oracle.com> Message-ID: <96dd3c48-5e62-35bb-0057-497af680e11e@oracle.com> OK, but the second part does leave the reader asking, "why not?" It is also curious, and a potential candidate for a Java Puzzlers talk, why there is not a two-way relationship between "TypeParameterElement.getEnclosingElement()" and the relevant "getEnclosedElements". -- Jon On 05/22/2019 05:14 PM, Joe Darcy wrote: > Hello, > > Please review the spec clarification below to address > > ??? JDK-8224628: Note that type parameters are not visited by > ElementScanners > > As this is not a change of the semantics of the spec, no CSR is needed. > > Thanks, > > -Joe > > diff -r a978d86ac389 > src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java > --- > a/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java > Mon May 20 17:29:44 2019 -0700 > +++ > b/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner6.java > Wed May 22 17:12:32 2019 -0700 > @@ -180,6 +180,10 @@ > ????? * {@inheritDoc} > ????? * > ????? * @implSpec This implementation scans the enclosed elements. > +???? * Note that type parameters are not scanned by this > +???? * implementation since type parameters are not considered to be > +???? * {@linkplain TypeElement#getEnclosedElements enclosed elements > +???? * of a type}. > ????? * > ????? * @param e? {@inheritDoc} > ????? * @param p? {@inheritDoc} > @@ -211,6 +215,8 @@ > ????? * {@inheritDoc} > ????? * > ????? * @implSpec This implementation scans the parameters. > +???? * Note that type parameters are not scanned by this > +???? * implementation. > ????? * > ????? * @param e? {@inheritDoc} > ????? * @param p? {@inheritDoc} > From joe.darcy at oracle.com Thu May 23 00:33:46 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 22 May 2019 17:33:46 -0700 Subject: JDK 13 RFR of JDK-8224628: Note that type parameters are not visited by ElementScanners In-Reply-To: <96dd3c48-5e62-35bb-0057-497af680e11e@oracle.com> References: <62b84901-fe91-879a-3886-162a66e1280d@oracle.com> <96dd3c48-5e62-35bb-0057-497af680e11e@oracle.com> Message-ID: <5CE5EA6A.2060807@oracle.com> On 5/22/2019 5:20 PM, Jonathan Gibbons wrote: > OK, but the second part does leave the reader asking, "why not?" It was an oversight in the original implementation of the API. I've filed JDK-8224630: "ElementScannerN, N > 9 should scan type parameters" to address the issues once it comes time to add "ElementScanner14", or whatever the successor type happens to be named. > > It is also curious, and a potential candidate for a Java Puzzlers > talk, why there is not a two-way relationship between > "TypeParameterElement.getEnclosingElement()" and the relevant > "getEnclosedElements". It is a detail the spec lead of JSR 269 failed to catch and address before it was time for the JSR to go final ;-) This is one instance where the enclosed elements / enclosing element methods do not have the the inclusion relationship one would want. Another desirable invariant that doesn't quite hold is mapping between type and their element, such as there not being standard elements corresponding to primitive types. Thanks, -Joe From amalloy at google.com Thu May 23 00:50:50 2019 From: amalloy at google.com (Alan Malloy) Date: Wed, 22 May 2019 17:50:50 -0700 Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod Message-ID: Hello. Please review this patch to eliminate an unnecessary upcast and method call in LambdaToMethod. bug: https://bugs.openjdk.java.net/browse/JDK-8224629 webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/ Testing: All of jtreg:test/langtools/tools/javac pass locally. No new test added, as no behavior change is intended. Thanks, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu May 23 13:39:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 23 May 2019 13:39:08 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com> References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com> Message-ID: Hi Stuart, big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/ So, for ConcurrentSkipListMap.java, the new coding is a real improvement, removing a @SuppressWarnings("unchecked") and a cast which are both unnecessary then. @Martin Buchholz: What do I have to do to get this into the jsr166 integration 2019-06? Shall I open a separate bug? Or shall it be committed with the fix to JDK-8223553? Please guide me. In the other 3 locations, we're able to eliminate the EC4J issues by introducing a local variable with the right type declaration. Sounds like a viable workaround. At Eclipse we have the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236. It refers to the OpenJDK bug https://bugs.openjdk.java.net/browse/JDK-8016207. I'm wondering whether this should be submitted and I should at the same time submit another bug to evaluate these code places at a time when the final resolution for JDK-8016207 was provided? Thank you Christoph > -----Original Message----- > From: Stuart Marks > Sent: Samstag, 18. Mai 2019 00:56 > To: Langer, Christoph > Cc: David Holmes ; Daniel Fuchs > ; core-libs-dev dev at openjdk.java.net>; net-dev ; compiler- > dev at openjdk.java.net > Subject: Re: RFR: 8223553: Fix code constructs that do not compile with the > Eclipse Java Compiler > > Hi Christoph, > > I'm still not entirely sure why this is so, but the introduction of a local > variable in MethodHandles.java seems to make things work for Eclipse. > Addition > of a local variable seems to be minimally invasive, so it makes sense to see if > this technique can be applied to other cases. > > (In ConcurrentSkipListMap the issue seems to be solved by addition of > wildcards, > as I had suggested previously, and it cleans up the unchecked cast that was > there in the first place. So I think that one is ok already.) > > In ManagementFactory.java, an unchecked cast and warnings suppression is > introduced, and in ExchangeImpl.java a helper method was introduced. I've > found > ways to introduce local variables that make Eclipse happy for these cases. > (Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See > diffs below. > > The type of the local variable in ExchangeImpl.java is a mouthful. > Interestingly > I had to change Function.identity() to the lambda x -> x. I think this is > because Function.identity() returns a function that doesn't allow its return > type to vary from its argument, whereas x -> x allows a widening conversion. > (This might provide a clue as to the differences between javac and Eclipse > here, > but a full understanding eludes me.) > > s'marks > > > > diff -r 006dadb903ab > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.jav > a > --- > a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.j > ava > Mon May 13 17:15:56 2019 -0700 > +++ > b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.j > ava > Fri May 17 15:46:14 2019 -0700 > @@ -1712,9 +1712,7 @@ > Map m = (Map) o; > try { > Comparator cmp = comparator; > - @SuppressWarnings("unchecked") > - Iterator> it = > - (Iterator>)m.entrySet().iterator(); > + Iterator> it = m.entrySet().iterator(); > if (m instanceof SortedMap && > ((SortedMap)m).comparator() == cmp) { > Node b, n; > diff -r 006dadb903ab > src/java.management/share/classes/java/lang/management/ManagementF > actory.java > --- > a/src/java.management/share/classes/java/lang/management/Managemen > tFactory.java > Mon May 13 17:15:56 2019 -0700 > +++ > b/src/java.management/share/classes/java/lang/management/Managemen > tFactory.java > Fri May 17 15:46:14 2019 -0700 > @@ -872,12 +872,12 @@ > public static Set> > getPlatformManagementInterfaces() > { > - return platformComponents() > + Stream> pmos = > platformComponents() > .stream() > .flatMap(pc -> pc.mbeanInterfaces().stream()) > .filter(clazz -> > PlatformManagedObject.class.isAssignableFrom(clazz)) > - .map(clazz -> clazz.asSubclass(PlatformManagedObject.class)) > - .collect(Collectors.toSet()); > + .map(clazz -> clazz.asSubclass(PlatformManagedObject.class)); > + return pmos.collect(Collectors.toSet()); > } > > private static final String NOTIF_EMITTER = > diff -r 006dadb903ab > src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java > --- > a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java > Mon May 13 17:15:56 2019 -0700 > +++ > b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java > Fri May 17 15:46:14 2019 -0700 > @@ -92,8 +92,9 @@ > CompletableFuture c2f = > c2.getConnectionFor(request, exchange); > if (debug.on()) > debug.log("get: Trying to get HTTP/2 connection"); > - return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, > connection)) > - .thenCompose(Function.identity()); > + CompletableFuture ExchangeImpl>> fxi = > + c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange, > connection)); > + return fxi.thenCompose(x -> x); > } > } > From daniel.fuchs at oracle.com Thu May 23 13:47:26 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 23 May 2019 14:47:26 +0100 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com> Message-ID: On 23/05/2019 14:39, Langer, Christoph wrote: > big thanks for your great updates here. This all looks a lot cleaner:http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/ I concur. Thanks Stuart! best regards, -- daniel From cushon at google.com Thu May 23 17:57:25 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 23 May 2019 10:57:25 -0700 Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod In-Reply-To: References: Message-ID: Looks OK to me, for what it's worth. Calling MethodHandleSymbol#asHandle is definitely a no-op: http://hg.openjdk.java.net/jdk/jdk/file/2218f9d57d2f/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l2210 On Wed, May 22, 2019 at 5:51 PM Alan Malloy wrote: > Hello. Please review this patch to eliminate an unnecessary upcast and > method call in LambdaToMethod. > > bug: https://bugs.openjdk.java.net/browse/JDK-8224629 > webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/ > > Testing: All of jtreg:test/langtools/tools/javac pass locally. No new test > added, as no behavior change is intended. > > Thanks, > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Thu May 23 19:10:52 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 23 May 2019 12:10:52 -0700 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com> Message-ID: <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com> On 5/23/19 6:39 AM, Langer, Christoph wrote: > big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/ Great, glad to help. While I'm still unsure about the underlying reasons for this disagreement between the compilers, that might take a while to resolve. Putting in these fixes isn't very intrusive and it seems to make people's lives easier, so I don't have any objection to them going in. > In the other 3 locations, we're able to eliminate the EC4J issues by introducing a local variable with the right type declaration. Sounds like a viable workaround. > > At Eclipse we have the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236. It refers to the OpenJDK bug https://bugs.openjdk.java.net/browse/JDK-8016207. > > I'm wondering whether this should be submitted and I should at the same time submit another bug to evaluate these code places at a time when the final resolution for JDK-8016207 was provided? Overall, introducing a local variable is more-or-less reasonable even if it's used only once. One point is that somebody might come along and "clean up" the code and inline local variables and reintroduce the problem. Another point is that, hypothetically, if in the future Eclipse is changed to match javac's behavior, these changes should be reverted. The bug database is a good place to capture actions that need to take place in the future. Unfortunately, it's pretty far from these locations, so the existence of such a bug wouldn't prevent the accidental cleanup from happening. That would indicate having a comment in the code at these locations. On the other hand, if Eclipse is "fixed" and these locations don't get cleaned up for a long time, it doesn't seem like that big a deal. I'd suggest to put a comment at these 3 locations, something like: // local variable required here; see JDK-8223553 and not bother with filing another bug report to track this. I'll defer to Martin as to how he wants to handle the ConcurrentSkipListMap.java change. s'marks From brent.christian at oracle.com Thu May 23 19:39:30 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 23 May 2019 12:39:30 -0700 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <5CE58BA9.2090706@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> <5CE43F5E.1050102@oracle.com> <008FA8AC-7CC8-4352-A90F-7B459288F364@oracle.com> <5CE48771.6030509@oracle.com> <5CE58BA9.2090706@oracle.com> Message-ID: Hi, I have a couple questions/comments about the special treatment of the last line in a text block. -- In the CSR we have: "3. If the last line in the list of individual lines (i.e., the line with the text block closing delimiter) is blank, then add it to the set of determining lines. (The indentation of the closing delimiter should influence the indentation of the content as a whole -- a "significant trailing line" policy.)" Doesn't this mean that the last line will *always* be included in the set of determining lines (if it's blank, and also if it's not blank) ? That could be stated more clearly. -- Given that, one could put the closing delimiter at the beginning of a line to prevent any indent stripping, e.g.: .............. .............. """; (I guess this is what 'optOut' is for in the webrev.) Is it worth pointing out this possible usage more clearly? (Or perhaps it's not expected to be used very often.) Thanks, -Brent From christoph.langer at sap.com Thu May 23 21:23:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 23 May 2019 21:23:27 +0000 Subject: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler In-Reply-To: <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com> References: <368fedd8-d3fc-ab2e-b9ac-fa67f724ea1c@oracle.com> <9a085abd-95e0-9cf2-79e6-84c3615a6bbf@oracle.com> <52ff8820-c73c-1c56-e3f2-71ac174cfb57@oracle.com> Message-ID: > Overall, introducing a local variable is more-or-less reasonable even if it's > used only once. One point is that somebody might come along and "clean > up" the > code and inline local variables and reintroduce the problem. Another point is > that, hypothetically, if in the future Eclipse is changed to match javac's > behavior, these changes should be reverted. > > The bug database is a good place to capture actions that need to take place in > the future. Unfortunately, it's pretty far from these locations, so the > existence of such a bug wouldn't prevent the accidental cleanup from > happening. > That would indicate having a comment in the code at these locations. > > On the other hand, if Eclipse is "fixed" and these locations don't get cleaned > up for a long time, it doesn't seem like that big a deal. > > I'd suggest to put a comment at these 3 locations, something like: > > // local variable required here; see JDK-8223553 > > and not bother with filing another bug report to track this. Ok, good idea. I'll add the comment before I push. > I'll defer to Martin as to how he wants to handle the > ConcurrentSkipListMap.java > change. As Martin has taken this to the jsr166 integration 2019-06, I'll push the change without ConcurrentSkipListMap.java tomorrow. Thanks to all involved in this review! /Christoph From jonathan.gibbons at oracle.com Thu May 23 21:31:09 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 23 May 2019 14:31:09 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> <5CB0E11D.8070801@oracle.com> <5CD085AE.4050008@oracle.com> Message-ID: CSR and patch look good to me. -- Jon On 05/13/2019 06:02 AM, Jan Lahoda wrote: > Thanks Alex! > > Could I please get a review on the CSR? > > https://bugs.openjdk.java.net/browse/JDK-8222396 > > And also on the patch: > http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ > > Thanks! > > Jan > > On 06. 05. 19 21:06, Alex Buckley wrote: >> On 4/12/2019 12:03 PM, Alex Buckley wrote: >>> On 4/12/2019 5:34 AM, Jan Lahoda wrote: >>>> I've started with the CSR here: >>>> https://bugs.openjdk.java.net/browse/JDK-8222396 >>> >>> Looks pretty good. I made some edits to record both of your >>> single-module and multi-module invocations of javac. >>> >>> The use case of injecting test code is clear, but the exact connection >>> between automatic modules and test code is pretty opaque. Is the >>> goal to >>> make the automatic test module read the explicit test module so that >>> the >>> former module's code can access the latter module's code? Is the >>> goal to >>> make the automatic module read (and therefore test) at least the same >>> set of modules as the explicit modules `requires`? >> >> Reviewing the CSR again, it seemed like the key scenario is multiple >> named modules, where for each named module: >> >> 1. We don't really care about its relationship with the other named >> modules; but >> >> 2. We do care about injecting it with test code, and letting that >> test code read other, completely arbitrary, modules (say, an >> assertion-building library that's been placed on the module path). >> >> I have refactored the CSR to more strongly separate the problem >> (patching an automatic module is possible, but readability is >> sub-par) from the solution (precedent for ALL-MODULE-PATH from the >> unnamed module scenario). >> >> JEP 261 should be updated to explain the awesome power of >> --patch-module at compile time, and that is progressing behind the >> scenes, but I don't think it needs to block JDK-8220702 -- the CSR is >> "good enough" documentation for now. >> >> Alex From jonathan.gibbons at oracle.com Thu May 23 21:47:18 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 23 May 2019 14:47:18 -0700 Subject: JDK 13 RFR of JDK-8224177: Harden annotation processing framework to irregular behavior from processors In-Reply-To: <5CE49E1A.9090708@oracle.com> References: <7ad3b855-fe2d-6391-3a1b-88b5df0939b4@oracle.com> <5CE49E1A.9090708@oracle.com> Message-ID: +1 -- Jon On 05/21/2019 05:55 PM, Joseph D. Darcy wrote: > Hello, > > Updated with test cases so that CheckExamples.java will pass for the > new messages: > > ??? http://cr.openjdk.java.net/~darcy/8224177.1 > > Thanks, > > -Joe > > On 5/19/2019 11:36 PM, Joe Darcy wrote: >> Hello, >> >> As a complement to the changes in AbstractProcessor done under >> JDK-8146726 , the annotation processing framework in javac could be >> hardened against various kinds of irregular results returned from >> processors. The hardening can include just warning about redundant >> but not strictly incorrect information. >> >> Webrev at: >> >> ??? http://cr.openjdk.java.net/~darcy/8224177.0/ >> >> Most of the code changes in JavacProcessingEnvironment are to guard >> against misbehaving Set implementations returned from Processors; >> perhaps this is an unnecessary degree of caution. >> >> There may be other test updates needed for account for the new >> warnings messages; I'll make any such update once there is review >> feedback and agreement on (what subset of) this change's checks >> should go back. >> >> Thanks, >> >> -Joe >> > From brent.christian at oracle.com Thu May 23 22:52:13 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 23 May 2019 15:52:13 -0700 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <65795019-4e7a-8d72-958c-196b35e36cf1@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> <65795019-4e7a-8d72-958c-196b35e36cf1@oracle.com> Message-ID: Hi, Jim I have a few comments on the webrev. src/java.base/share/classes/java/lang/String.java 2982 private static int outdent(List lines) { Can you please add a doc comment for what this method does? 2973 .map(line -> { 2974 int firstNonWhitespace = line.indexOfNonWhitespace(); 2975 int lastNonWhitespace = line.lastIndexOfNonWhitespace(); 2976 return firstNonWhitespace > lastNonWhitespace 2977 ? "" : line.substring(Math.min(outdent, firstNonWhitespace), lastNonWhitespace); 2978 }) 2979 .collect(Collectors.joining("\n", "", optOut ? "\n" : "")); Like Vicente mentioned, it would be nice if less of this work were done when 'optOut' is true. test/jdk/java/lang/String/StripIndent.java I'd like for the test to be made easier to read, so it's clear which edge cases are covered (the last line determines a non-0 outdent, the last line opts out of all outdenting, etc). Splitting the test data onto multiple lines would be a good start (though ironic, for this feature :). And maybe even add a description of the case being tested, where not obvious. Thanks, -Brent From peter.levart at gmail.com Fri May 24 06:35:04 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 24 May 2019 08:35:04 +0200 Subject: RFR - JDK-8223775 String::stripIndent (Preview) In-Reply-To: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> References: <42C41E65-1FDC-4FDF-8D1F-8C50AA2B0777@oracle.com> Message-ID: <9caee86d-c89b-9142-2742-5ce325349b08@gmail.com> Hi, Excuse me for asking, but I can't find any text describing motivation for introduction of this method in JEP-355 other than "Developers will have access to this algorithm via String::stripIndent instance method"... If I understand the JEP correctly, this is an algorithm that is applied to Text Blocks during compilation. Is this method intended for developers writing java compilers? Regards, Peter On 5/21/19 4:56 PM, Jim Laskey wrote: > Please do a code review of the new String::stripIndent instance > method. This instance method is being introduced to support JEP-355: > Text Blocks, by removing incidental indentation from the text block > content. The algorithm used is defined in the JEP and also described > in the JBS entry. > > Thank you. > > -- Jim > > webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-01 > jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 > csr: https://bugs.openjdk.java.net/browse/JDK-8223776 > jep: https://bugs.openjdk.java.net/browse/JDK-8222530 > > From james.laskey at oracle.com Fri May 24 12:17:45 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 24 May 2019 09:17:45 -0300 Subject: RFR (CSR) - JDK-8223776 String::stripIndent (Preview) Message-ID: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com> Please do a CSR review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. Thank you. -- Jim csr: https://bugs.openjdk.java.net/browse/JDK-8223776 webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 jep: https://bugs.openjdk.java.net/browse/JDK-8222530 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Fri May 24 12:22:35 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 24 May 2019 09:22:35 -0300 Subject: RFR (CSR) - JDK-8223781 String::translateEscapes (Preview) Message-ID: <7AEBFD4E-8A86-4F2D-BC93-C16ABA759CFB@oracle.com> Please do a CSR review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. Thank you. -- Jim csr: https://bugs.openjdk.java.net/browse/JDK-8223781 webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03 jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 jep: https://bugs.openjdk.java.net/browse/JDK-8222530 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri May 24 14:48:36 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 24 May 2019 16:48:36 +0200 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions Message-ID: Hi, I'd like to ask for a review of changes to update javac to follow the current spec for switch expressions, in particular the break -> yield change: http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html Webrev: http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8223305 Feedback is welcome! Thanks, Jan From alex.buckley at oracle.com Fri May 24 17:35:06 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 24 May 2019 10:35:06 -0700 Subject: RFR (CSR) - JDK-8223781 String::translateEscapes (Preview) In-Reply-To: <7AEBFD4E-8A86-4F2D-BC93-C16ABA759CFB@oracle.com> References: <7AEBFD4E-8A86-4F2D-BC93-C16ABA759CFB@oracle.com> Message-ID: <5CE82B4A.3090801@oracle.com> It's a bit heavy to cite a JLS section in the summary of a method. Recommend: "Returns a string whose value is this string, with escape sequences translated as if in a string literal." [Not mentioning text blocks for simplicity. Plus, if you mention them, then it looks like you forgot character literals.] @jls 3.10.7 Escape Sequences [note the new shorter name] @deprecated This method is associated with text blocks, a preview language feature. Text blocks and/or this method may be changed or removed in a future release. [Also for stripIndent] Alex On 5/24/2019 5:22 AM, Jim Laskey wrote: > Please do a CSR review of the new String:: translateEscapes instance > method. This instance method is being introduced to support JEP-355: > Text Blocks, by translating escape sequences in the text block content. > > Thank you. > > -- Jim > > csr: https://bugs.openjdk.java.net/browse/JDK-8223781 > webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03 > jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 > jep: https://bugs.openjdk.java.net/browse/JDK-8222530 From brent.christian at oracle.com Fri May 24 21:00:43 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 24 May 2019 14:00:43 -0700 Subject: RFR (CSR) - JDK-8223776 String::stripIndent (Preview) In-Reply-To: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com> References: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com> Message-ID: Hi, In the description of the re-indentation algorithm, I think it's worth clarifying that the last line is always included. So perhaps: "3. The last line (i.e., the line with the text block closing delimiter) is included in the set of determining lines, even if it is blank. (The indentation of the closing delimiter should influence the indentation of the content as a whole -- a "significant trailing line" policy.)" I think the corresponding portion of the JavaDoc is good. Thanks, -Brent On 5/24/19 5:17 AM, Jim Laskey wrote: > Please do a CSR review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. > > Thank you. > > -- Jim > > csr: https://bugs.openjdk.java.net/browse/JDK-8223776 > webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 > jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 > jep: https://bugs.openjdk.java.net/browse/JDK-8222530 > From james.laskey at oracle.com Mon May 27 13:11:42 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 27 May 2019 10:11:42 -0300 Subject: RFR (CSR) - JDK-8223776 String::stripIndent (Preview) In-Reply-To: References: <22C33F78-63B8-42C7-A36D-1E420598BC54@oracle.com> Message-ID: <66CB7ACE-A4B3-4D11-AED6-355804DDBCD1@oracle.com> I think I have to leave it as is, since the Javadoc will become THE spec for text blocks, i.e., there is a direct correspondence between the JavaDoc and the JEP. > On May 24, 2019, at 6:00 PM, Brent Christian wrote: > > Hi, > > In the description of the re-indentation algorithm, I think it's worth clarifying that the last line is always included. So perhaps: > > "3. The last line (i.e., the line with the text block closing delimiter) is included in the set of determining lines, even if it is blank. (The indentation of the closing delimiter should influence the indentation of the content as a whole -- a "significant trailing line" policy.)" > > I think the corresponding portion of the JavaDoc is good. > > Thanks, > -Brent > > On 5/24/19 5:17 AM, Jim Laskey wrote: >> Please do a CSR review of the new String::stripIndent instance method. This instance method is being introduced to support JEP-355: Text Blocks, by removing incidental indentation from the text block content. The algorithm used is defined in the JEP and also described in the JBS entry. >> Thank you. >> -- Jim >> csr: https://bugs.openjdk.java.net/browse/JDK-8223776 >> webrev: http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8223775 >> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 From ivan.gerasimov at oracle.com Tue May 28 06:18:04 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 27 May 2019 23:18:04 -0700 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com> Message-ID: Hi Jim! I wonder why it was chosen to represent octal values as \[0-3][0-9][0-9] | \[0-9][0-9] | \[0-9] ? First, it will allow multiple leading zeroes. Second, it does not require a leading zero, while, I think, many users are used to octal numbers starting with a mandatory leading zero. Was it considered to mirror the syntax from regex [1] ? [1] https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/regex/Pattern.html#sum With kind regards, Ivan On 5/21/19 12:24 PM, Jim Laskey wrote: > Revised at > http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html > > > > > >> On May 21, 2019, at 3:23 PM, Jim Laskey > > wrote: >> >> >> >>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov >>> > wrote: >>> >>> Hi Jim! >>> >>> A few comments: >>> >>> 1) >>> Probably, there's no need to update ch in these cases: >>> case '\'': >>> ch = '\''; >>> break; >>> case '\"': >>> ch = '\"'; >>> break; >> >> True >> >>> >>> 2) >>> Character.digit(ch, 8) will accept non-Latin1 digits. >>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377. >>> (Note, that the first digit still can only be from range '0'-'9'). >> >> Also true. Subtlety in UnicodeReader. >> >>> >>> 3) >>> It's not obvious how this condition can be triggered: >>> if (0377 < code) { >>> throw new MalformedEscapeException(from); >>> } >>> I might be missing something, but I cannot see how 'code' can become >>> > 0377. >> >> I removed this check in round 2. >> >>> >>> 4) >>> throw new MalformedEscapeException(from); >>> This will report the next index after the error. Was it intentional? >>> >> >> I switched to using an IllegalArgumentError and displaying the actual >> character. >> >> >>> With kind regards, >>> Ivan >> >> Much thanks. >> >> >>> >>> >>> On 5/21/19 7:56 AM, Jim Laskey wrote: >>>> Please do a code review of the new String:: translateEscapes >>>> instance method. This instance method is being introduced to >>>> support JEP-355: Text Blocks, by translating escape sequences in >>>> the text block content. >>>> >>>> Thank you. >>>> >>>> -- Jim >>>> >>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 >>>> >>>> >>> > >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 >>>> >>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 >>>> >>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 >>>> >>>> >>>> >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >> > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 28 09:11:35 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 May 2019 10:11:35 +0100 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: References: Message-ID: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> Looks good. Just few comments/questions: * I think the error keys in compiler.properties could use some renaming. e.g. compiler.err.break.complex.value.no.switch.expression -> compiler.err.no.switch.expression compiler.err.break.complex.value.no.switch.expression.qualify -> compiler.err.no.switch.expression.qualify * what is the new Log.hasErrorOn - and why has Flow been changed to use it? Thanks Maurizio It seems like a whitespace got remove here? On 24/05/2019 15:48, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of changes to update javac to follow the > current spec for switch expressions, in particular the break -> yield > change: > http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8223305 > > Feedback is welcome! > > Thanks, > ?? Jan From jan.lahoda at oracle.com Tue May 28 09:37:11 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 28 May 2019 11:37:11 +0200 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> Message-ID: <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> On 28. 05. 19 11:11, Maurizio Cimadamore wrote: > Looks good. Just few comments/questions: Thanks! > > * I think the error keys in compiler.properties could use some renaming. > e.g. > > compiler.err.break.complex.value.no.switch.expression -> > compiler.err.no.switch.expression > compiler.err.break.complex.value.no.switch.expression.qualify -> > compiler.err.no.switch.expression.qualify Sure, will do. > > * what is the new Log.hasErrorOn - and why has Flow been changed to use it? Consider code like this: --- public class Y2 { private void t() { break; } } --- When compiled like this: javac -XDdev -XDshould-stop.at=FLOW Y2.java It will crash: --- Y2.java:4: error: break outside switch or loop break; ^ 1 error An exception has occurred in the compiler (11.0.3). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) at jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) 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 is that javac asserts that it has properly processed the exits - but here the original code is broken, and an error has already been reported and this given spot, so it seems safe to not crash javac here. Thanks, Jan > > Thanks > Maurizio > > > It seems like a whitespace got remove here? > > On 24/05/2019 15:48, Jan Lahoda wrote: >> Hi, >> >> I'd like to ask for a review of changes to update javac to follow the >> current spec for switch expressions, in particular the break -> yield >> change: >> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >> >> Webrev: >> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8223305 >> >> Feedback is welcome! >> >> Thanks, >> ?? Jan From maurizio.cimadamore at oracle.com Tue May 28 10:09:12 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 May 2019 11:09:12 +0100 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> Message-ID: <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> Hi I thought a bit more about the code (the Attr part) and I have few more comments: * I don't immediately see the need for having another field in AttrContext. After all we could rename/repurpose the existing resultInfo. * of course, to do that, we need a way to detect whether we're inside a switch expression, but that should be possible by looking at the env? Or you could even exploit the check context, after all, the check context for a case arm is always created in the switchExpressionContext method. * it seems like when you are in visitYield, you should first check if there's a target for the yield - and if there's not you log an error. That will also remove some dependencies from yieldResult. Of course you can also leave the code as is. It just occurred that having a separate ResultInfo specifically for yield (or break with value, as the code was also there before) seemed a bit redundant. But I can also believe that the current approach leads to more sensible code. Also, one small comment inline below. On 28/05/2019 10:37, Jan Lahoda wrote: > On 28. 05. 19 11:11, Maurizio Cimadamore wrote: >> Looks good. Just few comments/questions: > > Thanks! > >> >> * I think the error keys in compiler.properties could use some >> renaming. e.g. >> >> compiler.err.break.complex.value.no.switch.expression -> >> compiler.err.no.switch.expression >> compiler.err.break.complex.value.no.switch.expression.qualify -> >> compiler.err.no.switch.expression.qualify > > Sure, will do. > >> >> * what is the new Log.hasErrorOn - and why has Flow been changed to >> use it? > > Consider code like this: > --- > public class Y2 { > ??? private void t() { > ??????? break; > ??? } > } > --- > > When compiled like this: > javac -XDdev -XDshould-stop.at=FLOW Y2.java ah ok - it's the failover logic. I was trying to think of an example w/o shouldStopAt and could not think of much. Thanks Maurizio > It will crash: > --- > Y2.java:4: error: break outside switch or loop > ???????????? break; > ???????????? ^ > 1 error > An exception has occurred in the compiler (11.0.3). Please file a bug > against the Java compiler via the Java bug reporting page > (http://bugreport.java.com) after checking the Bug Database > (http://bugs.java.com) for duplicates. Include your program and the > following diagnostic in your report. Thank you. > java.lang.AssertionError > ??????? at > jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > ??????? at > jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) > ??????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) > ??????? at > jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) > ??????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) > ??????? at > jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) > ??????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > ??????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > ??????? 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 is that javac asserts that it has properly processed the > exits - but here the original code is broken, and an error has already > been reported and this given spot, so it seems safe to not crash javac > here. > > Thanks, > ??? Jan > >> >> Thanks >> Maurizio >> >> >> It seems like a whitespace got remove here? >> >> On 24/05/2019 15:48, Jan Lahoda wrote: >>> Hi, >>> >>> I'd like to ask for a review of changes to update javac to follow >>> the current spec for switch expressions, in particular the break -> >>> yield change: >>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8223305 >>> >>> Feedback is welcome! >>> >>> Thanks, >>> ?? Jan From james.laskey at oracle.com Tue May 28 11:43:32 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 28 May 2019 08:43:32 -0300 Subject: RFR - JDK-8223780 String::translateEscapes (Preview) In-Reply-To: References: <837A1D40-7AA4-4164-B5B0-D8748536EEE0@oracle.com> <955CE59F-C1E6-451E-9A30-D91679129AC2@oracle.com> Message-ID: <05F974A6-202D-40F5-A331-736BD4AF4B07@oracle.com> It is critical to replicate what the javac compiler is doing presently, otherwise we break existing code. char leadch = reader.ch; int oct = reader.digit(pos, 8); reader.scanChar(); if ('0' <= reader.ch && reader.ch <= '7') { oct = oct * 8 + reader.digit(pos, 8); reader.scanChar(); if (leadch <= '3' && '0' <= reader.ch && reader.ch <= '7') { oct = oct * 8 + reader.digit(pos, 8); reader.scanChar(); } } If you look at the JSL 3.10.6, this is also the pattern used. OctalEscape: \ OctalDigit \ OctalDigit OctalDigit \ ZeroToThree OctalDigit OctalDigit Cheers, -- Jim > On May 28, 2019, at 3:18 AM, Ivan Gerasimov wrote: > > Hi Jim! > > I wonder why it was chosen to represent octal values as \[0-3][0-9][0-9] | \[0-9][0-9] | \[0-9] ? > > First, it will allow multiple leading zeroes. > > Second, it does not require a leading zero, while, I think, many users are used to octal numbers starting with a mandatory leading zero. > > Was it considered to mirror the syntax from regex [1] ? > > [1] https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/regex/Pattern.html#sum > With kind regards, > > Ivan > > > On 5/21/19 12:24 PM, Jim Laskey wrote: >> Revised at http://cr.openjdk.java.net/~jlaskey/8223780/webrev-03/src/java.base/share/classes/java/lang/String.java.frames.html >> >> >> >>> On May 21, 2019, at 3:23 PM, Jim Laskey > wrote: >>> >>> >>> >>>> On May 21, 2019, at 2:57 PM, Ivan Gerasimov > wrote: >>>> >>>> Hi Jim! >>>> >>>> A few comments: >>>> >>>> 1) >>>> Probably, there's no need to update ch in these cases: >>>> case '\'': >>>> ch = '\''; >>>> break; >>>> case '\"': >>>> ch = '\"'; >>>> break; >>> >>> True >>> >>>> >>>> 2) >>>> Character.digit(ch, 8) will accept non-Latin1 digits. >>>> So, a sequence \\3\uFF17\uFF17 will be parsed as \\377. >>>> (Note, that the first digit still can only be from range '0'-'9'). >>> >>> Also true. Subtlety in UnicodeReader. >>> >>>> >>>> 3) >>>> It's not obvious how this condition can be triggered: >>>> if (0377 < code) { >>>> throw new MalformedEscapeException(from); >>>> } >>>> I might be missing something, but I cannot see how 'code' can become > 0377. >>> >>> I removed this check in round 2. >>> >>>> >>>> 4) >>>> throw new MalformedEscapeException(from); >>>> This will report the next index after the error. Was it intentional? >>>> >>> >>> I switched to using an IllegalArgumentError and displaying the actual character. >>> >>> >>>> With kind regards, >>>> Ivan >>> >>> Much thanks. >>> >>> >>>> >>>> >>>> On 5/21/19 7:56 AM, Jim Laskey wrote: >>>>> Please do a code review of the new String:: translateEscapes instance method. This instance method is being introduced to support JEP-355: Text Blocks, by translating escape sequences in the text block content. >>>>> >>>>> Thank you. >>>>> >>>>> -- Jim >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8223780/webrev-01 > >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8223780 > >>>>> csr: https://bugs.openjdk.java.net/browse/JDK-8223781 > >>>>> jep: https://bugs.openjdk.java.net/browse/JDK-8222530 > >>>>> >>>>> >>>> >>>> -- >>>> With kind regards, >>>> Ivan Gerasimov >>>> >>> >> > > -- > With kind regards, > Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue May 28 14:50:01 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 28 May 2019 10:50:01 -0400 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: References: Message-ID: looks good to me, Vicente On 5/24/19 10:48 AM, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of changes to update javac to follow the > current spec for switch expressions, in particular the break -> yield > change: > http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8223305 > > Feedback is welcome! > > Thanks, > ?? Jan From vicente.romero at oracle.com Tue May 28 16:29:01 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 28 May 2019 12:29:01 -0400 Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod In-Reply-To: References: Message-ID: I think that I prefer the flexibility that invoking the ::asHandle method brings. Suppose that a subclass wants to provide an implementation of the asHandle method that will return the non-obvious result. Not a high probability case but we have seen similar uses to the Symbol::baseSymbol method. I think I prefer to have options, Vicente On 5/22/19 8:50 PM, Alan Malloy wrote: > Hello. Please review this patch?to eliminate an unnecessary upcast and > method call in LambdaToMethod. > > bug: https://bugs.openjdk.java.net/browse/JDK-8224629 > webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/ > > Testing: All of?jtreg:test/langtools/tools/javac pass locally. No new > test added, as no behavior change is intended. > > Thanks, > ? ? Alan From amalloy at google.com Tue May 28 16:50:22 2019 From: amalloy at google.com (Alan Malloy) Date: Tue, 28 May 2019 09:50:22 -0700 Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod In-Reply-To: References: Message-ID: We already have a MethodHandleSymbol, though. You're envisioning something like this? class FancySymbol extends MethodHandleSymbol { public MethodHandleSymbol asHandle() { return new DelegatingFancySymbol(this); } } I'd argue that if FancySymbol wants to require you to call asHandle() before you can treat it as a MethodHandleSymbol, it should have made itself a MethodSymbol, not a MethodHandleSymbol. Then, of course clients would be required to use its asHandle method, invoking whatever non-obvious logic it represents, in order to get a MethodHandleSymbol. I don't see any value in catering to classes like this. If someone someday really does add FancySymbol and needs all users of MethodHandleSymbol to call asHandle() on all instances, they'll have more use sites than this one to refactor (right now, I see LambdaToMethod.addDeserializationCase, PoolWriter.writeConstant, and perhaps DynamicMethodSymbol will need some rethinking). But if you are sure, then we should at least remove the meaningless upcast. On Tue, May 28, 2019 at 9:29 AM Vicente Romero wrote: > I think that I prefer the flexibility that invoking the ::asHandle > method brings. Suppose that a subclass wants to provide an > implementation of the asHandle method that will return the non-obvious > result. Not a high probability case but we have seen similar uses to the > Symbol::baseSymbol method. I think I prefer to have options, > > Vicente > > On 5/22/19 8:50 PM, Alan Malloy wrote: > > Hello. Please review this patch to eliminate an unnecessary upcast and > > method call in LambdaToMethod. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8224629 > > webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/ > > > > Testing: All of jtreg:test/langtools/tools/javac pass locally. No new > > test added, as no behavior change is intended. > > > > Thanks, > > Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue May 28 17:42:20 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 28 May 2019 13:42:20 -0400 Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod In-Reply-To: References: Message-ID: <8ba6f699-4634-0800-c5cd-601b1d97c0f8@oracle.com> On 5/28/19 12:50 PM, Alan Malloy wrote: > We already have a MethodHandleSymbol, though. You're envisioning > something like this? > > class FancySymbol extends MethodHandleSymbol { > ? ? public MethodHandleSymbol asHandle() { > ? ? ? ? return new DelegatingFancySymbol(this); > ? ? } > } it would be more common to create an anonymous inner class, but yes the idea is the same. > > I'd argue that if FancySymbol wants to require you to call asHandle() > before you can treat it as a MethodHandleSymbol, it should have made > itself a MethodSymbol, not a MethodHandleSymbol. Then, of course > clients would be required to use its asHandle method, invoking > whatever non-obvious logic it represents, in order to get a > MethodHandleSymbol. I don't see any value in catering to classes like > this. If someone someday really does add FancySymbol and needs all > users of MethodHandleSymbol to call asHandle() on all instances, > they'll have more use sites than this one to refactor (right now, I > see LambdaToMethod.addDeserializationCase, PoolWriter.writeConstant, > and perhaps DynamicMethodSymbol will need some rethinking). > > But if you are sure, then we should at least remove the meaningless > upcast. yep I agree on removing the upcast, Vicente > > On Tue, May 28, 2019 at 9:29 AM Vicente Romero > > wrote: > > I think that I prefer the flexibility that invoking the ::asHandle > method brings. Suppose that a subclass wants to provide an > implementation of the asHandle method that will return the > non-obvious > result. Not a high probability case but we have seen similar uses > to the > Symbol::baseSymbol method. I think I prefer to have options, > > Vicente > > On 5/22/19 8:50 PM, Alan Malloy wrote: > > Hello. Please review this patch?to eliminate an unnecessary > upcast and > > method call in LambdaToMethod. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8224629 > > webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/ > > > > Testing: All of?jtreg:test/langtools/tools/javac pass locally. > No new > > test added, as no behavior change is intended. > > > > Thanks, > > ? ? Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Tue May 28 18:15:58 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 28 May 2019 14:15:58 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: Here's my attempt so far: http://cr.openjdk.java.net/~ronsh/scopeimpl_with_hashmap/webrev.00/ It's not working, but I'm not understanding the failures. Perhaps the bug(s) may jump out at you? I'm not doing anything with the removeCount, and maybe that's the issue. I haven't tracked it because I wasn't sure what was going on in that part of the code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed May 29 00:45:42 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 28 May 2019 17:45:42 -0700 Subject: OpenJDK "Compiler Group" page updated Message-ID: <798f43c7-e521-4c74-a3e6-7afb3895b37a@oracle.com> FYI, I've updated or deleted some of the more egregiously obsolete content on the OpenJDK Compiler Group page, and broadened the description of the page to specifically include javadoc and javap as well. [1] I've also linked in two recent new documents, * Processing Code(Or:/Doclets, Annotation Processors and Plugins: Oh My!/) * Using the new Doclet API -- Jon [1] http://openjdk.java.net/groups/compiler/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed May 29 22:27:25 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 29 May 2019 18:27:25 -0400 Subject: RFR: JDK-8224083: javadoc Reporter generates "warning" for Kind.NOTE Message-ID: <93b428fd-4b2b-c38d-c520-c753743ac9d5@oracle.com> Please review fix for [1] and [2] at [3]. These are two separate issues for which the same test is provided so this one patch will fix both. The first issue is related to jdk.javadoc.internal.tool.Messager, producing warnings at method: print(Kind kind, Element e, String msg) even if it was instructed to produce notes. A case for Kind.NOTE was added. The other issue was this same class throwing a NPE if it couldn't find an element at method ::getDiagSource. In this case a check for null is done and `programName` is returned as it is done already for a similar case in that method, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8224083 [2] https://bugs.openjdk.java.net/browse/JDK-8224082 [3] http://cr.openjdk.java.net/~vromero/8224083/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed May 29 23:10:02 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 29 May 2019 16:10:02 -0700 Subject: RFR: JDK-8224083: javadoc Reporter generates "warning" for Kind.NOTE In-Reply-To: <93b428fd-4b2b-c38d-c520-c753743ac9d5@oracle.com> References: <93b428fd-4b2b-c38d-c520-c753743ac9d5@oracle.com> Message-ID: <5adf6be0-8dc7-13b1-245b-609e03524f61@oracle.com> Hi Vicente, The fix for the source file looks good, but there are a few things to note with the test. 1. You check that "warning" does not appear, but you don't check that NullPointerException does not appear, which is the other bug you are fixing. 2. Tests that strings do not appear are typically very weak tests. If the test were to do nothing, or crash on startup, the designated text would not appear and the test would pass as a false positive.? While it is not wrong to test that text does not appear, it is generally better to augment it with a test to verify that some expected output does appear. 3. Using javac.util.Assert is a bit of overkill, since it means you have to expose it in the @modules clause.? I think it is better to just test the condition and throw an exception directly. Depending on and using javac internal classes is an anti-pattern we should avoid as much as possible. 4. You can simplify the test by combining the doclet into the test class itself, avoiding the use of a long multi-line string; this also has the side effect of compiling the doclet for you for free, so that you don't need to compile that string.You can see this technique used in a number of javadoc tests: try the following code to get a list of examples: ?? ??? grep -r 'implements Doclet' open/test/langtools You should be able to merge the classes since your test code just "extends TestRunner" and a doclet "implements Doclet", which can both be accomplished in a single class. If all that sounds too clever, I would move the demo doclet into a new source file, so that it can easily be modified (if needed) by a standard IDE, instead of having to be careful about editing Java source code embedded in a long string constant. Even if you move it into a new source file in a subdirectory of the test directory (test/langtools/jdk/javadoc/tool/reporter_generates_warnings/) you can still use jtreg to compile the file with an obvious use of @build.? Given that the NPE was triggered by the doclet analyzing code in a named package, this is probably the better way to go ... to ensure that the pathway that used to generate NPE is also tested. -- Jon On 05/29/2019 03:27 PM, Vicente Romero wrote: > Please review fix for [1] and [2] at [3]. These are two separate > issues for which the same test is provided so this one patch will fix > both. The first issue is related to > jdk.javadoc.internal.tool.Messager, producing warnings at method: > print(Kind kind, Element e, String msg) > even if it was instructed to produce notes. A case for Kind.NOTE was > added. The other issue was this same class throwing a NPE if it > couldn't find an element at method ::getDiagSource. In this case a > check for null is done and `programName` is returned as it is done > already for a similar case in that method, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8224083 > [2] https://bugs.openjdk.java.net/browse/JDK-8224082 > [3] http://cr.openjdk.java.net/~vromero/8224083/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu May 30 00:24:04 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 May 2019 17:24:04 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces Message-ID: Hello, Please review the webrev and CSR for: ??? JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 Thanks, -Joe From jan.lahoda at oracle.com Thu May 30 13:58:06 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 30 May 2019 15:58:06 +0200 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> Message-ID: Hi, Thanks for all the comments so far. I've uploaded a new version of the patch here: http://cr.openjdk.java.net/~jlahoda/8223303/webrev.01/ delta webrev from the previous state: http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.00.01/ The changes are: -adjustment to the updated spec, where yield is a restricted identifier (this required generalization of current error messages for var) -placing yield-related elements at the end for changes in com.sun.source, to better reflect alphabet order -simplification of error code from compiler.err.break.complex.value.no.switch.expression to compiler.err.no.switch.expression. This patch does not include unification of the AttrContext.returnResult/yieldResult, but I've done that here: http://cr.openjdk.java.net/~jlahoda/8223303/webrev.unified.attrcontext.result/ There is a small issue in return handling, as return needs to look and the enclosing Envs to see if there is a switch expression or not. But if this looks OK, I can fold it into the main patch. Further feedback is welcome! Thanks, Jan On 28. 05. 19 12:09, Maurizio Cimadamore wrote: > Hi > I thought a bit more about the code (the Attr part) and I have few more > comments: > > * I don't immediately see the need for having another field in > AttrContext. After all we could rename/repurpose the existing resultInfo. > > * of course, to do that, we need a way to detect whether we're inside a > switch expression, but that should be possible by looking at the env? Or > you could even exploit the check context, after all, the check context > for a case arm is always created in the switchExpressionContext method. > > * it seems like when you are in visitYield, you should first check if > there's a target for the yield - and if there's not you log an error. > That will also remove some dependencies from yieldResult. > > Of course you can also leave the code as is. It just occurred that > having a separate ResultInfo specifically for yield (or break with > value, as the code was also there before) seemed a bit redundant. But I > can also believe that the current approach leads to more sensible code. > > > Also, one small comment inline below. > > > On 28/05/2019 10:37, Jan Lahoda wrote: >> On 28. 05. 19 11:11, Maurizio Cimadamore wrote: >>> Looks good. Just few comments/questions: >> >> Thanks! >> >>> >>> * I think the error keys in compiler.properties could use some >>> renaming. e.g. >>> >>> compiler.err.break.complex.value.no.switch.expression -> >>> compiler.err.no.switch.expression >>> compiler.err.break.complex.value.no.switch.expression.qualify -> >>> compiler.err.no.switch.expression.qualify >> >> Sure, will do. >> >>> >>> * what is the new Log.hasErrorOn - and why has Flow been changed to >>> use it? >> >> Consider code like this: >> --- >> public class Y2 { >> ??? private void t() { >> ??????? break; >> ??? } >> } >> --- >> >> When compiled like this: >> javac -XDdev -XDshould-stop.at=FLOW Y2.java > > ah ok - it's the failover logic. I was trying to think of an example w/o > shouldStopAt and could not think of much. > > Thanks > Maurizio > >> It will crash: >> --- >> Y2.java:4: error: break outside switch or loop >> ???????????? break; >> ???????????? ^ >> 1 error >> An exception has occurred in the compiler (11.0.3). Please file a bug >> against the Java compiler via the Java bug reporting page >> (http://bugreport.java.com) after checking the Bug Database >> (http://bugs.java.com) for duplicates. Include your program and the >> following diagnostic in your report. Thank you. >> java.lang.AssertionError >> ??????? at >> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >> ??????? at >> jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >> ??????? at >> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >> >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >> ??????? at >> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >> ??????? 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 is that javac asserts that it has properly processed the >> exits - but here the original code is broken, and an error has already >> been reported and this given spot, so it seems safe to not crash javac >> here. >> >> Thanks, >> ??? Jan >> >>> >>> Thanks >>> Maurizio >>> >>> >>> It seems like a whitespace got remove here? >>> >>> On 24/05/2019 15:48, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I'd like to ask for a review of changes to update javac to follow >>>> the current spec for switch expressions, in particular the break -> >>>> yield change: >>>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8223305 >>>> >>>> Feedback is welcome! >>>> >>>> Thanks, >>>> ?? Jan From maurizio.cimadamore at oracle.com Thu May 30 14:15:05 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 30 May 2019 15:15:05 +0100 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> Message-ID: <6906dd66-0893-f479-d916-e95850059884@oracle.com> Looks great! You only missed one rename in Resolve: private Symbol checkVarType(Symbol bestSoFar, Name name) { I guess that should be checkRestrictedType, or something like it? Maurizio On 30/05/2019 14:58, Jan Lahoda wrote: > Hi, > > Thanks for all the comments so far. I've uploaded a new version of the > patch here: > http://cr.openjdk.java.net/~jlahoda/8223303/webrev.01/ > delta webrev from the previous state: > http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.00.01/ > > The changes are: > -adjustment to the updated spec, where yield is a restricted > identifier (this required generalization of current error messages for > var) > -placing yield-related elements at the end for changes in > com.sun.source, to better reflect alphabet order > -simplification of error code from > compiler.err.break.complex.value.no.switch.expression? to > compiler.err.no.switch.expression. > > This patch does not include unification of the > AttrContext.returnResult/yieldResult, but I've done that here: > http://cr.openjdk.java.net/~jlahoda/8223303/webrev.unified.attrcontext.result/ > > > There is a small issue in return handling, as return needs to look and > the enclosing Envs to see if there is a switch expression or not. But > if this looks OK, I can fold it into the main patch. > > Further feedback is welcome! > > Thanks, > ??? Jan > > On 28. 05. 19 12:09, Maurizio Cimadamore wrote: >> Hi >> I thought a bit more about the code (the Attr part) and I have few >> more comments: >> >> * I don't immediately see the need for having another field in >> AttrContext. After all we could rename/repurpose the existing >> resultInfo. >> >> * of course, to do that, we need a way to detect whether we're inside >> a switch expression, but that should be possible by looking at the >> env? Or you could even exploit the check context, after all, the >> check context for a case arm is always created in the >> switchExpressionContext method. >> >> * it seems like when you are in visitYield, you should first check if >> there's a target for the yield - and if there's not you log an error. >> That will also remove some dependencies from yieldResult. >> >> Of course you can also leave the code as is. It just occurred that >> having a separate ResultInfo specifically for yield (or break with >> value, as the code was also there before) seemed a bit redundant. But >> I can also believe that the current approach leads to more sensible >> code. >> >> >> Also, one small comment inline below. >> >> >> On 28/05/2019 10:37, Jan Lahoda wrote: >>> On 28. 05. 19 11:11, Maurizio Cimadamore wrote: >>>> Looks good. Just few comments/questions: >>> >>> Thanks! >>> >>>> >>>> * I think the error keys in compiler.properties could use some >>>> renaming. e.g. >>>> >>>> compiler.err.break.complex.value.no.switch.expression -> >>>> compiler.err.no.switch.expression >>>> compiler.err.break.complex.value.no.switch.expression.qualify -> >>>> compiler.err.no.switch.expression.qualify >>> >>> Sure, will do. >>> >>>> >>>> * what is the new Log.hasErrorOn - and why has Flow been changed to >>>> use it? >>> >>> Consider code like this: >>> --- >>> public class Y2 { >>> ??? private void t() { >>> ??????? break; >>> ??? } >>> } >>> --- >>> >>> When compiled like this: >>> javac -XDdev -XDshould-stop.at=FLOW Y2.java >> >> ah ok - it's the failover logic. I was trying to think of an example >> w/o shouldStopAt and could not think of much. >> >> Thanks >> Maurizio >> >>> It will crash: >>> --- >>> Y2.java:4: error: break outside switch or loop >>> ???????????? break; >>> ???????????? ^ >>> 1 error >>> An exception has occurred in the compiler (11.0.3). Please file a >>> bug against the Java compiler via the Java bug reporting page >>> (http://bugreport.java.com) after checking the Bug Database >>> (http://bugs.java.com) for duplicates. Include your program and the >>> following diagnostic in your report. Thank you. >>> java.lang.AssertionError >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >>> >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >>> ??????? at >>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >>> ??????? 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 is that javac asserts that it has properly processed the >>> exits - but here the original code is broken, and an error has >>> already been reported and this given spot, so it seems safe to not >>> crash javac here. >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> Thanks >>>> Maurizio >>>> >>>> >>>> It seems like a whitespace got remove here? >>>> >>>> On 24/05/2019 15:48, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I'd like to ask for a review of changes to update javac to follow >>>>> the current spec for switch expressions, in particular the break >>>>> -> yield change: >>>>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8223305 >>>>> >>>>> Feedback is welcome! >>>>> >>>>> Thanks, >>>>> ?? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu May 30 14:19:22 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 30 May 2019 15:19:22 +0100 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: <6906dd66-0893-f479-d916-e95850059884@oracle.com> References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> <6906dd66-0893-f479-d916-e95850059884@oracle.com> Message-ID: <556fa4eb-cdf2-ef8a-1586-59c4bb67b76f@oracle.com> As for the unification, let's discuss that separately and let's focus on the first webrev for now. I think what I'd like to see there (if anything) is also an attempt to unify "findJumpTargetNoError" for both cases, so that we can use same logic in both visitYield and visitReturn. Maurizio On 30/05/2019 15:15, Maurizio Cimadamore wrote: > > Looks great! You only missed one rename in Resolve: > > private Symbol checkVarType(Symbol bestSoFar, Name name) { > > I guess that should be checkRestrictedType, or something like it? > > Maurizio > > On 30/05/2019 14:58, Jan Lahoda wrote: >> Hi, >> >> Thanks for all the comments so far. I've uploaded a new version of >> the patch here: >> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.01/ >> delta webrev from the previous state: >> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.00.01/ >> >> The changes are: >> -adjustment to the updated spec, where yield is a restricted >> identifier (this required generalization of current error messages >> for var) >> -placing yield-related elements at the end for changes in >> com.sun.source, to better reflect alphabet order >> -simplification of error code from >> compiler.err.break.complex.value.no.switch.expression? to >> compiler.err.no.switch.expression. >> >> This patch does not include unification of the >> AttrContext.returnResult/yieldResult, but I've done that here: >> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.unified.attrcontext.result/ >> >> >> There is a small issue in return handling, as return needs to look >> and the enclosing Envs to see if there is a switch expression or not. >> But if this looks OK, I can fold it into the main patch. >> >> Further feedback is welcome! >> >> Thanks, >> ??? Jan >> >> On 28. 05. 19 12:09, Maurizio Cimadamore wrote: >>> Hi >>> I thought a bit more about the code (the Attr part) and I have few >>> more comments: >>> >>> * I don't immediately see the need for having another field in >>> AttrContext. After all we could rename/repurpose the existing >>> resultInfo. >>> >>> * of course, to do that, we need a way to detect whether we're >>> inside a switch expression, but that should be possible by looking >>> at the env? Or you could even exploit the check context, after all, >>> the check context for a case arm is always created in the >>> switchExpressionContext method. >>> >>> * it seems like when you are in visitYield, you should first check >>> if there's a target for the yield - and if there's not you log an >>> error. That will also remove some dependencies from yieldResult. >>> >>> Of course you can also leave the code as is. It just occurred that >>> having a separate ResultInfo specifically for yield (or break with >>> value, as the code was also there before) seemed a bit redundant. >>> But I can also believe that the current approach leads to more >>> sensible code. >>> >>> >>> Also, one small comment inline below. >>> >>> >>> On 28/05/2019 10:37, Jan Lahoda wrote: >>>> On 28. 05. 19 11:11, Maurizio Cimadamore wrote: >>>>> Looks good. Just few comments/questions: >>>> >>>> Thanks! >>>> >>>>> >>>>> * I think the error keys in compiler.properties could use some >>>>> renaming. e.g. >>>>> >>>>> compiler.err.break.complex.value.no.switch.expression -> >>>>> compiler.err.no.switch.expression >>>>> compiler.err.break.complex.value.no.switch.expression.qualify -> >>>>> compiler.err.no.switch.expression.qualify >>>> >>>> Sure, will do. >>>> >>>>> >>>>> * what is the new Log.hasErrorOn - and why has Flow been changed >>>>> to use it? >>>> >>>> Consider code like this: >>>> --- >>>> public class Y2 { >>>> ??? private void t() { >>>> ??????? break; >>>> ??? } >>>> } >>>> --- >>>> >>>> When compiled like this: >>>> javac -XDdev -XDshould-stop.at=FLOW Y2.java >>> >>> ah ok - it's the failover logic. I was trying to think of an example >>> w/o shouldStopAt and could not think of much. >>> >>> Thanks >>> Maurizio >>> >>>> It will crash: >>>> --- >>>> Y2.java:4: error: break outside switch or loop >>>> ???????????? break; >>>> ???????????? ^ >>>> 1 error >>>> An exception has occurred in the compiler (11.0.3). Please file a >>>> bug against the Java compiler via the Java bug reporting page >>>> (http://bugreport.java.com) after checking the Bug Database >>>> (http://bugs.java.com) for duplicates. Include your program and the >>>> following diagnostic in your report. Thank you. >>>> java.lang.AssertionError >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >>>> ??????? 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 is that javac asserts that it has properly processed the >>>> exits - but here the original code is broken, and an error has >>>> already been reported and this given spot, so it seems safe to not >>>> crash javac here. >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>>> >>>>> Thanks >>>>> Maurizio >>>>> >>>>> >>>>> It seems like a whitespace got remove here? >>>>> >>>>> On 24/05/2019 15:48, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to ask for a review of changes to update javac to follow >>>>>> the current spec for switch expressions, in particular the break >>>>>> -> yield change: >>>>>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223305 >>>>>> >>>>>> Feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> ?? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu May 30 14:50:09 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 30 May 2019 16:50:09 +0200 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: <6906dd66-0893-f479-d916-e95850059884@oracle.com> References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> <6906dd66-0893-f479-d916-e95850059884@oracle.com> Message-ID: On 30. 05. 19 16:15, Maurizio Cimadamore wrote: > Looks great! You only missed one rename in Resolve: > > private Symbol checkVarType(Symbol bestSoFar, Name name) { > > > I guess that should be checkRestrictedType, or something like it? Yes, thanks for noticing. Will fix. Jan > > Maurizio > > On 30/05/2019 14:58, Jan Lahoda wrote: >> Hi, >> >> Thanks for all the comments so far. I've uploaded a new version of the >> patch here: >> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.01/ >> delta webrev from the previous state: >> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.00.01/ >> >> The changes are: >> -adjustment to the updated spec, where yield is a restricted >> identifier (this required generalization of current error messages for >> var) >> -placing yield-related elements at the end for changes in >> com.sun.source, to better reflect alphabet order >> -simplification of error code from >> compiler.err.break.complex.value.no.switch.expression? to >> compiler.err.no.switch.expression. >> >> This patch does not include unification of the >> AttrContext.returnResult/yieldResult, but I've done that here: >> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.unified.attrcontext.result/ >> >> >> There is a small issue in return handling, as return needs to look and >> the enclosing Envs to see if there is a switch expression or not. But >> if this looks OK, I can fold it into the main patch. >> >> Further feedback is welcome! >> >> Thanks, >> ??? Jan >> >> On 28. 05. 19 12:09, Maurizio Cimadamore wrote: >>> Hi >>> I thought a bit more about the code (the Attr part) and I have few >>> more comments: >>> >>> * I don't immediately see the need for having another field in >>> AttrContext. After all we could rename/repurpose the existing >>> resultInfo. >>> >>> * of course, to do that, we need a way to detect whether we're inside >>> a switch expression, but that should be possible by looking at the >>> env? Or you could even exploit the check context, after all, the >>> check context for a case arm is always created in the >>> switchExpressionContext method. >>> >>> * it seems like when you are in visitYield, you should first check if >>> there's a target for the yield - and if there's not you log an error. >>> That will also remove some dependencies from yieldResult. >>> >>> Of course you can also leave the code as is. It just occurred that >>> having a separate ResultInfo specifically for yield (or break with >>> value, as the code was also there before) seemed a bit redundant. But >>> I can also believe that the current approach leads to more sensible >>> code. >>> >>> >>> Also, one small comment inline below. >>> >>> >>> On 28/05/2019 10:37, Jan Lahoda wrote: >>>> On 28. 05. 19 11:11, Maurizio Cimadamore wrote: >>>>> Looks good. Just few comments/questions: >>>> >>>> Thanks! >>>> >>>>> >>>>> * I think the error keys in compiler.properties could use some >>>>> renaming. e.g. >>>>> >>>>> compiler.err.break.complex.value.no.switch.expression -> >>>>> compiler.err.no.switch.expression >>>>> compiler.err.break.complex.value.no.switch.expression.qualify -> >>>>> compiler.err.no.switch.expression.qualify >>>> >>>> Sure, will do. >>>> >>>>> >>>>> * what is the new Log.hasErrorOn - and why has Flow been changed to >>>>> use it? >>>> >>>> Consider code like this: >>>> --- >>>> public class Y2 { >>>> ??? private void t() { >>>> ??????? break; >>>> ??? } >>>> } >>>> --- >>>> >>>> When compiled like this: >>>> javac -XDdev -XDshould-stop.at=FLOW Y2.java >>> >>> ah ok - it's the failover logic. I was trying to think of an example >>> w/o shouldStopAt and could not think of much. >>> >>> Thanks >>> Maurizio >>> >>>> It will crash: >>>> --- >>>> Y2.java:4: error: break outside switch or loop >>>> ???????????? break; >>>> ???????????? ^ >>>> 1 error >>>> An exception has occurred in the compiler (11.0.3). Please file a >>>> bug against the Java compiler via the Java bug reporting page >>>> (http://bugreport.java.com) after checking the Bug Database >>>> (http://bugs.java.com) for duplicates. Include your program and the >>>> following diagnostic in your report. Thank you. >>>> java.lang.AssertionError >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >>>> >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >>>> ??????? at >>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >>>> ??????? 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 is that javac asserts that it has properly processed the >>>> exits - but here the original code is broken, and an error has >>>> already been reported and this given spot, so it seems safe to not >>>> crash javac here. >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>>> >>>>> Thanks >>>>> Maurizio >>>>> >>>>> >>>>> It seems like a whitespace got remove here? >>>>> >>>>> On 24/05/2019 15:48, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to ask for a review of changes to update javac to follow >>>>>> the current spec for switch expressions, in particular the break >>>>>> -> yield change: >>>>>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223305 >>>>>> >>>>>> Feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> ?? Jan From vicente.romero at oracle.com Thu May 30 16:48:04 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 30 May 2019 12:48:04 -0400 Subject: RFR: JDK-8224083: javadoc Reporter generates "warning" for Kind.NOTE In-Reply-To: <5adf6be0-8dc7-13b1-245b-609e03524f61@oracle.com> References: <93b428fd-4b2b-c38d-c520-c753743ac9d5@oracle.com> <5adf6be0-8dc7-13b1-245b-609e03524f61@oracle.com> Message-ID: Hi Jon, I have published another iteration at [1], some comments below, On 5/29/19 7:10 PM, Jonathan Gibbons wrote: > > Hi Vicente, > > The fix for the source file looks good, but there are a few things to > note with the test. > > 1. You check that "warning" does not appear, but you don't check that > NullPointerException does not appear, which is the other bug you are > fixing. > the test fails if a NPE happens that's why I didn't see necessary to add a specific check for that > 2. Tests that strings do not appear are typically very weak tests. If > the test were to do nothing, or crash on startup, the designated text > would not appear and the test would pass as a false positive.? While > it is not wrong to test that text does not appear, it is generally > better to augment it with a test to verify that some expected output > does appear. > I have modified the check and now I'm checking for a specific output. > 3. Using javac.util.Assert is a bit of overkill, since it means you > have to expose it in the @modules clause.? I think it is better to > just test the condition and throw an exception directly. Depending on > and using javac internal classes is an anti-pattern we should avoid as > much as possible. > I removed the use of Assert > > 4. You can simplify the test by combining the doclet into the test > class itself, avoiding the use of a long multi-line string; this also > has the side effect of compiling the doclet for you for free, so that > you don't need to compile that string.You can see this technique used > in a number of javadoc tests: try the following code to get a list of > examples: > > ?? ??? grep -r 'implements Doclet' open/test/langtools > > You should be able to merge the classes since your test code just > "extends TestRunner" and a doclet "implements Doclet", which can both > be accomplished in a single class. > > If all that sounds too clever, I would move the demo doclet into a new > source file, so that it can easily be modified (if needed) by a > standard IDE, instead of having to be careful about editing Java > source code embedded in a long string constant. Even if you move it > into a new source file in a subdirectory of the test directory > (test/langtools/jdk/javadoc/tool/reporter_generates_warnings/) you can > still use jtreg to compile the file with an obvious use of @build.? > Given that the NPE was triggered by the doclet analyzing code in a > named package, this is probably the better way to go ... to ensure > that the pathway that used to generate NPE is also tested. > > -- Jon Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8224083/webrev.01/ > > > On 05/29/2019 03:27 PM, Vicente Romero wrote: >> Please review fix for [1] and [2] at [3]. These are two separate >> issues for which the same test is provided so this one patch will fix >> both. The first issue is related to >> jdk.javadoc.internal.tool.Messager, producing warnings at method: >> print(Kind kind, Element e, String msg) >> even if it was instructed to produce notes. A case for Kind.NOTE was >> added. The other issue was this same class throwing a NPE if it >> couldn't find an element at method ::getDiagSource. In this case a >> check for null is done and `programName` is returned as it is done >> already for a similar case in that method, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8224083 >> [2] https://bugs.openjdk.java.net/browse/JDK-8224082 >> [3] http://cr.openjdk.java.net/~vromero/8224083/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 30 17:15:34 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 10:15:34 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: References: Message-ID: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> On 05/29/2019 05:24 PM, Joe Darcy wrote: > Hello, > > Please review the webrev and CSR for: > > ??? JDK-8224687: Add clarifying overrides of Element.asType to more > specific subinterfaces > ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 > > Thanks, > > -Joe > Joe, CSR Reviewed. In the new test, I don't understand lines 119, 128, regarding ElementKind.FIELD. Either the code is a copy-paste error, or the description elsewhere of DeclaredType and TypeKind.DECLARED is incorrect, since these only refer to declared types (class, interface, etc) and not fields. Surprising or maybe not, the test actually passes, suggesting that this is the current behavior even if it is unexpected.? That being said, the output from the test would be easier to understand if it included the ElementKind and simple name of the element, as well as the typeMirror, typeMirror class and typeKind. -- Jon From jonathan.gibbons at oracle.com Thu May 30 17:23:19 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 10:23:19 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> Message-ID: <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> On 05/30/2019 10:15 AM, Jonathan Gibbons wrote: > > > On 05/29/2019 05:24 PM, Joe Darcy wrote: >> Hello, >> >> Please review the webrev and CSR for: >> >> ??? JDK-8224687: Add clarifying overrides of Element.asType to more >> specific subinterfaces >> ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 >> >> Thanks, >> >> -Joe >> > > Joe, > > CSR Reviewed. > > In the new test, I don't understand lines 119, 128, regarding > ElementKind.FIELD. > Either the code is a copy-paste error, or the description elsewhere of > DeclaredType > and TypeKind.DECLARED is incorrect, since these only refer to declared > types > (class, interface, etc) and not fields. > > Surprising or maybe not, the test actually passes, suggesting that > this is the > current behavior even if it is unexpected.? That being said, the > output from the > test would be easier to understand if it included the ElementKind and > simple name > of the element, as well as the typeMirror, typeMirror class and typeKind. > > -- Jon I guess what is happening is that the mapping to TypeMirror for ElementKind.FIELD varies, depending on the field being declared. If so, that deserves mention in the spec for VariableElement.asType, and also deserves a comment in the test code. I'll stop short of suggesting that the test code should have more fields in it, such as a field of primitive type, but if you could find an easy way to adapt the test for that, that would be good too. -- Jon From ronshapiro at google.com Thu May 30 17:44:05 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Thu, 30 May 2019 13:44:05 -0400 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> Message-ID: Is it within scope to return the specific subtypes as covariant return types? e.g. TypeParameterElement could return TypeVariable, TypeElement could return DeclaredType, etc. On Thu, May 30, 2019 at 1:25 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 05/30/2019 10:15 AM, Jonathan Gibbons wrote: > > > > > > On 05/29/2019 05:24 PM, Joe Darcy wrote: > >> Hello, > >> > >> Please review the webrev and CSR for: > >> > >> JDK-8224687: Add clarifying overrides of Element.asType to more > >> specific subinterfaces > >> webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ > >> CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 > >> > >> Thanks, > >> > >> -Joe > >> > > > > Joe, > > > > CSR Reviewed. > > > > In the new test, I don't understand lines 119, 128, regarding > > ElementKind.FIELD. > > Either the code is a copy-paste error, or the description elsewhere of > > DeclaredType > > and TypeKind.DECLARED is incorrect, since these only refer to declared > > types > > (class, interface, etc) and not fields. > > > > Surprising or maybe not, the test actually passes, suggesting that > > this is the > > current behavior even if it is unexpected. That being said, the > > output from the > > test would be easier to understand if it included the ElementKind and > > simple name > > of the element, as well as the typeMirror, typeMirror class and typeKind. > > > > -- Jon > > I guess what is happening is that the mapping to TypeMirror for > ElementKind.FIELD > varies, depending on the field being declared. If so, that deserves > mention in the > spec for VariableElement.asType, and also deserves a comment in the test > code. > I'll stop short of suggesting that the test code should have more fields > in it, such as > a field of primitive type, but if you could find an easy way to adapt > the test for that, > that would be good too. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 30 17:59:30 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 10:59:30 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> Message-ID: Ron, On the face of it, that sounds like a good idea, but (1) this RFE was mostly about improving docs and (2) in many cases, the possibility of ErrorType forces the return type to be TypeMirror. If we could easily determine the most specific subtype for each method, that might be a good, separate enhancement. -- Jon On 05/30/2019 10:44 AM, Ron Shapiro wrote: > Is it within scope to return the specific subtypes as covariant return > types? e.g. TypeParameterElement could return TypeVariable, > TypeElement could return DeclaredType, etc. > > On Thu, May 30, 2019 at 1:25 PM Jonathan Gibbons > > wrote: > > > > On 05/30/2019 10:15 AM, Jonathan Gibbons wrote: > > > > > > On 05/29/2019 05:24 PM, Joe Darcy wrote: > >> Hello, > >> > >> Please review the webrev and CSR for: > >> > >> ??? JDK-8224687: Add clarifying overrides of Element.asType to > more > >> specific subinterfaces > >> ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ > > >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 > >> > >> Thanks, > >> > >> -Joe > >> > > > > Joe, > > > > CSR Reviewed. > > > > In the new test, I don't understand lines 119, 128, regarding > > ElementKind.FIELD. > > Either the code is a copy-paste error, or the description > elsewhere of > > DeclaredType > > and TypeKind.DECLARED is incorrect, since these only refer to > declared > > types > > (class, interface, etc) and not fields. > > > > Surprising or maybe not, the test actually passes, suggesting that > > this is the > > current behavior even if it is unexpected.? That being said, the > > output from the > > test would be easier to understand if it included the > ElementKind and > > simple name > > of the element, as well as the typeMirror, typeMirror class and > typeKind. > > > > -- Jon > > I guess what is happening is that the mapping to TypeMirror for > ElementKind.FIELD > varies, depending on the field being declared. If so, that deserves > mention in the > spec for VariableElement.asType, and also deserves a comment in > the test > code. > I'll stop short of suggesting that the test code should have more > fields > in it, such as > a field of primitive type, but if you could find an easy way to adapt > the test for that, > that would be good too. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu May 30 18:11:48 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 May 2019 11:11:48 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> Message-ID: <68537dbf-a74a-4833-160a-cca69b45aafd@oracle.com> Hi Ron, On 5/30/2019 10:44 AM, Ron Shapiro wrote: > Is it within scope to return the specific subtypes as covariant return > types? e.g. TypeParameterElement could return TypeVariable, > TypeElement could return DeclaredType, etc. > Based on experience with the earlier apt API, it was a conscious design choice for javax.lang.model to not use covariant returns in a case like this even though it seems appealing. The issue is the that the javax.lang.model is intended to be implemented by different compilers, including compilers where the native declaration and type hierarchies don't match the declaration and type hierarchies in the javax.lang.model modeling interfaces. In particular, some compilers might want to use a single type to implement many (or all) of the javax.lang.model.element interfaces. Having covariant overrides would interfere with such a reduced-type design. HTH, -Joe From jonathan.gibbons at oracle.com Thu May 30 18:47:24 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 11:47:24 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: <68537dbf-a74a-4833-160a-cca69b45aafd@oracle.com> References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> <68537dbf-a74a-4833-160a-cca69b45aafd@oracle.com> Message-ID: <92b2826d-55aa-a6e1-808f-8067f4d0e672@oracle.com> On 5/30/19 11:11 AM, Joe Darcy wrote: > Hi Ron, > > On 5/30/2019 10:44 AM, Ron Shapiro wrote: >> Is it within scope to return the specific subtypes as covariant >> return types? e.g. TypeParameterElement could return TypeVariable, >> TypeElement could return DeclaredType, etc. >> > Based on experience with the earlier apt API, it was a conscious > design choice for javax.lang.model to not use covariant returns in a > case like this even though it seems appealing. The issue is the that > the javax.lang.model is intended to be implemented by different > compilers, including compilers where the native declaration and type > hierarchies don't match the declaration and type hierarchies in the > javax.lang.model modeling interfaces. In particular, some compilers > might want to use a single type to implement many (or all) of the > javax.lang.model.element interfaces. Having covariant overrides would > interfere with such a reduced-type design. > > HTH, > > -Joe > Joe, I'm not sure I buy this variant of the "some compilers might want to use a single type" argument. If the "kind" (ElementKind or TypeKind) of the return is always a specific kind, then there is a presumption that it is safe to downcast the returned object to the corresponding specific subtype. That could be done equally well (or better) by declaring the return type of the method to be more specific. I understand the "some compilers might want to use a single type" argument, but that would only apply to internal implementation types, and surely not would not absolve the compiler from the responsibility of implementing specific subtypes where appropriate.? In other words, there should be specified correspondence between "kind" and implemented interfaces. -- Jon From joe.darcy at oracle.com Thu May 30 19:04:33 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 May 2019 12:04:33 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> Message-ID: Hi Jon, On 5/30/2019 10:23 AM, Jonathan Gibbons wrote: > > > On 05/30/2019 10:15 AM, Jonathan Gibbons wrote: >> >> >> On 05/29/2019 05:24 PM, Joe Darcy wrote: >>> Hello, >>> >>> Please review the webrev and CSR for: >>> >>> ??? JDK-8224687: Add clarifying overrides of Element.asType to more >>> specific subinterfaces >>> ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ >>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 >>> >>> Thanks, >>> >>> -Joe >>> >> >> Joe, >> >> CSR Reviewed. >> >> In the new test, I don't understand lines 119, 128, regarding >> ElementKind.FIELD. >> Either the code is a copy-paste error, or the description elsewhere >> of DeclaredType >> and TypeKind.DECLARED is incorrect, since these only refer to >> declared types >> (class, interface, etc) and not fields. >> >> Surprising or maybe not, the test actually passes, suggesting that >> this is the >> current behavior even if it is unexpected.? That being said, the >> output from the >> test would be easier to understand if it included the ElementKind and >> simple name >> of the element, as well as the typeMirror, typeMirror class and >> typeKind. >> >> -- Jon > > I guess what is happening is that the mapping to TypeMirror for > ElementKind.FIELD > varies, depending on the field being declared. If so, that deserves > mention in the > spec for VariableElement.asType, and also deserves a comment in the > test code. > I'll stop short of suggesting that the test code should have more > fields in it, such as > a field of primitive type, but if you could find an easy way to adapt > the test for that, > that would be good too. > Correct. I propose adding some additional documentation around the maps used by the test: > ??? /* > ???? * For both of the maps below, a ElementKind value is mapped to > ???? * one value related to an element's asType image. In some cases, > ???? * the ElementKind -> (TypeMirror type, TypeKind) mapping is > ???? * always the same, such as ElementKind.PACKAGE mapping to > ???? * (NoType.class, TypeKind.PACKAGE). In other cases, such as for a > ???? * field, there are many possible mappings and they are not > ???? * attempted to be examined exhaustively by this test. > ???? */ > ??? private static final Map> > elementKindToTypeClass = > ??????? Map.of(ElementKind.CLASS, DeclaredType.class, > ?????????????? ElementKind.CONSTRUCTOR, ExecutableType.class, > ?????????????? ElementKind.METHOD, ExecutableType.class, > ?????????????? ElementKind.PACKAGE, NoType.class, > ?????????????? ElementKind.MODULE, NoType.class, > ?????????????? ElementKind.TYPE_PARAMETER, TypeVariable.class, > ?????????????? // For the field NestedClass.name that is tested, a > ?????????????? // declared type is used. > ?????????????? ElementKind.FIELD, DeclaredType.class); > > ??? private static final Map > elementKindToTypeKind = > ??????? Map.of(ElementKind.CLASS, TypeKind.DECLARED, > ?????????????? ElementKind.CONSTRUCTOR, TypeKind.EXECUTABLE, > ?????????????? ElementKind.METHOD, TypeKind.EXECUTABLE, > ?????????????? ElementKind.PACKAGE, TypeKind.PACKAGE, > ?????????????? ElementKind.MODULE, TypeKind.MODULE, > ?????????????? ElementKind.TYPE_PARAMETER, TypeKind.TYPEVAR, > ?????????????? // For the field NestedClass.name that is tested, a > ?????????????? // declared type is used. > ?????????????? ElementKind.FIELD, TypeKind.DECLARED); > For the cases where only one flavor of mapping is possible, such as packages and modules, the revised map explicitly mentions the mapping. I'll work on crafting an additional sentence along the lines of "Note that a variable can have many possible kinds of types." Thanks, -Joe From jonathan.gibbons at oracle.com Thu May 30 20:32:27 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 13:32:27 -0700 Subject: RFR: [XS,doc] JDK-8225077: fix references to broken link in java.compiler module Message-ID: Please review a one line change to fix a 404 link in javax/annotation/processing/Filer.java With this fix, DocCheck finds no errors in the java.compiler module. JBS: https://bugs.openjdk.java.net/browse/JDK-8225077 -- Jon Patch inline: $ hg diff -R open diff -r a0d4e61acb6b src/java.compiler/share/classes/javax/annotation/processing/Filer.java --- a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java Thu May 30 12:45:02 2019 -0700 +++ b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java Thu May 30 13:27:15 2019 -0700 @@ -60,7 +60,7 @@ ? * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path ? * segments.? A valid relative name must match the ? * "path-rootless" rule of RFC 3986, section + * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section ? * 3.3. ? * ? *

The file creation methods take a variable number of arguments to From joe.darcy at oracle.com Thu May 30 20:34:18 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 30 May 2019 13:34:18 -0700 Subject: RFR: [XS, doc] JDK-8225077: fix references to broken link in java.compiler module In-Reply-To: References: Message-ID: <5CF03E4A.5090409@oracle.com> +1 Thanks Jon, -Joe On 5/30/2019 1:32 PM, Jonathan Gibbons wrote: > Please review a one line change to fix a 404 link in > javax/annotation/processing/Filer.java > With this fix, DocCheck finds no errors in the java.compiler module. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225077 > > -- Jon > > > Patch inline: > > $ hg diff -R open > diff -r a0d4e61acb6b > src/java.compiler/share/classes/javax/annotation/processing/Filer.java > --- > a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java > Thu May 30 12:45:02 2019 -0700 > +++ > b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java > Thu May 30 13:27:15 2019 -0700 > @@ -60,7 +60,7 @@ > * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path > * segments. A valid relative name must match the > * "path-rootless" rule of - * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section > + * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section > * 3.3. > * > *

The file creation methods take a variable number of arguments to > From lance.andersen at oracle.com Thu May 30 20:34:42 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 30 May 2019 16:34:42 -0400 Subject: RFR: [XS,doc] JDK-8225077: fix references to broken link in java.compiler module In-Reply-To: References: Message-ID: <57483BAC-9491-4832-BD26-B56147E12A7A@oracle.com> +1 > On May 30, 2019, at 4:32 PM, Jonathan Gibbons wrote: > > Please review a one line change to fix a 404 link in javax/annotation/processing/Filer.java > With this fix, DocCheck finds no errors in the java.compiler module. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225077 > > -- Jon > > > Patch inline: > > $ hg diff -R open > diff -r a0d4e61acb6b src/java.compiler/share/classes/javax/annotation/processing/Filer.java > --- a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java Thu May 30 12:45:02 2019 -0700 > +++ b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java Thu May 30 13:27:15 2019 -0700 > @@ -60,7 +60,7 @@ > * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path > * segments. A valid relative name must match the > * "path-rootless" rule of - * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section > + * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section > * 3.3. > * > *

The file creation methods take a variable number of arguments to > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From joe.darcy at oracle.com Thu May 30 21:22:34 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 May 2019 14:22:34 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> Message-ID: <168afc3e-89da-727f-20f9-168cdd332121@oracle.com> Updated webrev: ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.3/ More descriptive comments in the test, added more specific @see tags to the overridden methods (in part of suppress unwanted propagation of the all the @see entries from Element.asType), and gave guidance on the range of types for a variable. Diff of patches below, trimmed out some white space differences. Thanks, -Joe 27,29c29,40 < --- old/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java 2019-05-29 17:14:43.047376000 -0700 < +++ new/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java 2019-05-29 17:14:42.667376000 -0700 < @@ -41,6 +41,15 @@ --- >????? TypeMirror asType(); > > --- old/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java 2019-05-30 14:15:59.625000999 -0700 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java 2019-05-30 14:15:59.261000999 -0700 > @@ -1,5 +1,5 @@ >? /* > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >?? * >?? * This code is free software; you can redistribute it and/or modify it > @@ -41,6 +41,17 @@ 36a48,49 > +???? * > +???? * @see ExecutableType 45,46c58,59 < --- old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-05-29 17:14:43.735376000 -0700 < +++ new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-05-29 17:14:43.375376000 -0700 --- > --- old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-05-30 14:16:00.341000999 -0700 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-05-30 14:15:59.957000999 -0700 55c68 < @@ -37,6 +38,12 @@ --- > @@ -37,6 +38,16 @@ 60c73,74 < +???? * Returns a {@linkplain javax.lang.model.type.NoType pseudo-type} for this module. --- > +???? * Returns a {@linkplain javax.lang.model.type.NoType pseudo-type} > +???? * for this module. 61a76,78 > +???? * > +???? * @see javax.lang.model.type.NoType > +???? * @see javax.lang.model.type.TypeKind#MODULE 68,69c85,93 < --- old/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java 2019-05-29 17:14:44.439376000 -0700 < +++ new/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java 2019-05-29 17:14:44.071376000 -0700 --- > --- old/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java 2019-05-30 14:16:01.049000999 -0700 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java 2019-05-30 14:16:00.657000999 -0700 > @@ -1,5 +1,5 @@ >? /* > - * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >?? * >?? * This code is free software; you can redistribute it and/or modify it 78c102 < @@ -38,6 +39,12 @@ --- > @@ -38,6 +39,16 @@ 83c107,108 < +???? * Returns a {@linkplain javax.lang.model.type.NoType pseudo-type} for this package. --- > +???? * Returns a {@linkplain javax.lang.model.type.NoType pseudo-type} > +???? * for this package. 84a110,112 > +???? * > +???? * @see javax.lang.model.type.NoType > +???? * @see javax.lang.model.type.TypeKind#PACKAGE 91,93c119,128 < --- old/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java 2019-05-29 17:14:45.139376000 -0700 < +++ new/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java 2019-05-29 17:14:44.751376000 -0700 < @@ -60,6 +60,25 @@ --- > --- old/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java 2019-05-30 14:16:01.745000999 -0700 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java 2019-05-30 14:16:01.373000999 -0700 > @@ -1,5 +1,5 @@ >? /* > - * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >?? * >?? * This code is free software; you can redistribute it and/or modify it > @@ -60,6 +60,28 @@ 110a146,148 > +???? * > +???? * @see Types#asMemberOf(DeclaredType, Element) > +???? * @see Types#getDeclaredType(TypeElement, TypeMirror...) 119,120c157,165 < --- old/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java 2019-05-29 17:14:45.811376000 -0700 < +++ new/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java 2019-05-29 17:14:45.455376000 -0700 --- > --- old/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java 2019-05-30 14:16:02.509000999 -0700 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java 2019-05-30 14:16:02.109000999 -0700 > @@ -1,5 +1,5 @@ >? /* > - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >?? * >?? * This code is free software; you can redistribute it and/or modify it 137,139c182,191 < --- old/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java 2019-05-29 17:14:46.475376000 -0700 < +++ new/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java 2019-05-29 17:14:46.119376000 -0700 < @@ -26,6 +26,7 @@ --- > --- old/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java 2019-05-30 14:16:03.233000999 -0700 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java 2019-05-30 14:16:02.857000999 -0700 > @@ -1,5 +1,5 @@ >? /* > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >?? * >?? * This code is free software; you can redistribute it and/or modify it > @@ -26,6 +26,8 @@ 143a196 > +import javax.lang.model.type.TypeKind; 147c200 < @@ -38,6 +39,12 @@ --- > @@ -38,6 +40,19 @@ 152a206,210 > +???? * > +???? * Note that the types of variables range over {@linkplain > +???? * TypeKind many kinds} of types, including primitive types, > +???? * declared types, and array types, among others. > +???? * 153a212,213 > +???? * > +???? * @see TypeKind 161,162c221,222 < +++ new/test/langtools/tools/javac/processing/model/element/TestElementAsType.java 2019-05-29 17:14:46.795376000 -0700 < @@ -0,0 +1,139 @@ --- > +++ new/test/langtools/tools/javac/processing/model/element/TestElementAsType.java 2019-05-30 14:16:03.561000999 -0700 > @@ -0,0 +1,152 @@ 273a334,342 > +??? /* > +???? * For both of the maps below, a ElementKind value is mapped to > +???? * one value related to an element's asType image. In some cases, > +???? * the ElementKind -> (TypeMirror type, TypeKind) mapping is > +???? * always the same, such as ElementKind.PACKAGE mapping to > +???? * (NoType.class, TypeKind.PACKAGE). In other cases, such as for a > +???? * field, there are many possible mappings and they are not > +???? * attempted to be examined exhaustively by this test. > +???? */ 280a350,351 > +?????????????? // For the field NestedClass.name that is tested, a > +?????????????? // declared type is used. 289a361,362 > +?????????????? // For the field NestedClass.name that is tested, a > +?????????????? // declared type is used. On 5/30/2019 12:04 PM, Joe Darcy wrote: > Hi Jon, > > On 5/30/2019 10:23 AM, Jonathan Gibbons wrote: >> >> >> On 05/30/2019 10:15 AM, Jonathan Gibbons wrote: >>> >>> >>> On 05/29/2019 05:24 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Please review the webrev and CSR for: >>>> >>>> ??? JDK-8224687: Add clarifying overrides of Element.asType to more >>>> specific subinterfaces >>>> ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ >>>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>> >>> Joe, >>> >>> CSR Reviewed. >>> >>> In the new test, I don't understand lines 119, 128, regarding >>> ElementKind.FIELD. >>> Either the code is a copy-paste error, or the description elsewhere >>> of DeclaredType >>> and TypeKind.DECLARED is incorrect, since these only refer to >>> declared types >>> (class, interface, etc) and not fields. >>> >>> Surprising or maybe not, the test actually passes, suggesting that >>> this is the >>> current behavior even if it is unexpected.? That being said, the >>> output from the >>> test would be easier to understand if it included the ElementKind >>> and simple name >>> of the element, as well as the typeMirror, typeMirror class and >>> typeKind. >>> >>> -- Jon >> >> I guess what is happening is that the mapping to TypeMirror for >> ElementKind.FIELD >> varies, depending on the field being declared. If so, that deserves >> mention in the >> spec for VariableElement.asType, and also deserves a comment in the >> test code. >> I'll stop short of suggesting that the test code should have more >> fields in it, such as >> a field of primitive type, but if you could find an easy way to adapt >> the test for that, >> that would be good too. >> > > Correct. I propose adding some additional documentation around the > maps used by the test: > >> ??? /* >> ???? * For both of the maps below, a ElementKind value is mapped to >> ???? * one value related to an element's asType image. In some cases, >> ???? * the ElementKind -> (TypeMirror type, TypeKind) mapping is >> ???? * always the same, such as ElementKind.PACKAGE mapping to >> ???? * (NoType.class, TypeKind.PACKAGE). In other cases, such as for a >> ???? * field, there are many possible mappings and they are not >> ???? * attempted to be examined exhaustively by this test. >> ???? */ >> ??? private static final Map> >> elementKindToTypeClass = >> ??????? Map.of(ElementKind.CLASS, DeclaredType.class, >> ?????????????? ElementKind.CONSTRUCTOR, ExecutableType.class, >> ?????????????? ElementKind.METHOD, ExecutableType.class, >> ?????????????? ElementKind.PACKAGE, NoType.class, >> ?????????????? ElementKind.MODULE, NoType.class, >> ?????????????? ElementKind.TYPE_PARAMETER, TypeVariable.class, >> ?????????????? // For the field NestedClass.name that is tested, a >> ?????????????? // declared type is used. >> ?????????????? ElementKind.FIELD, DeclaredType.class); >> >> ??? private static final Map >> elementKindToTypeKind = >> ??????? Map.of(ElementKind.CLASS, TypeKind.DECLARED, >> ?????????????? ElementKind.CONSTRUCTOR, TypeKind.EXECUTABLE, >> ?????????????? ElementKind.METHOD, TypeKind.EXECUTABLE, >> ?????????????? ElementKind.PACKAGE, TypeKind.PACKAGE, >> ?????????????? ElementKind.MODULE, TypeKind.MODULE, >> ?????????????? ElementKind.TYPE_PARAMETER, TypeKind.TYPEVAR, >> ?????????????? // For the field NestedClass.name that is tested, a >> ?????????????? // declared type is used. >> ?????????????? ElementKind.FIELD, TypeKind.DECLARED); >> > For the cases where only one flavor of mapping is possible, such as > packages and modules, the revised map explicitly mentions the mapping. > I'll work on crafting an additional sentence along the lines of "Note > that a variable can have many possible kinds of types." > > Thanks, > > -Joe > > From joe.darcy at oracle.com Thu May 30 21:47:19 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 May 2019 14:47:19 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: <92b2826d-55aa-a6e1-808f-8067f4d0e672@oracle.com> References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> <68537dbf-a74a-4833-160a-cca69b45aafd@oracle.com> <92b2826d-55aa-a6e1-808f-8067f4d0e672@oracle.com> Message-ID: <8dbb6d13-2d75-31e6-a83a-0eb603f1e371@oracle.com> Hi Jon, On 5/30/2019 11:47 AM, Jonathan Gibbons wrote: > > On 5/30/19 11:11 AM, Joe Darcy wrote: >> Hi Ron, >> >> On 5/30/2019 10:44 AM, Ron Shapiro wrote: >>> Is it within scope to return the specific subtypes as covariant >>> return types? e.g. TypeParameterElement could return TypeVariable, >>> TypeElement could return DeclaredType, etc. >>> >> Based on experience with the earlier apt API, it was a conscious >> design choice for javax.lang.model to not use covariant returns in a >> case like this even though it seems appealing. The issue is the that >> the javax.lang.model is intended to be implemented by different >> compilers, including compilers where the native declaration and type >> hierarchies don't match the declaration and type hierarchies in the >> javax.lang.model modeling interfaces. In particular, some compilers >> might want to use a single type to implement many (or all) of the >> javax.lang.model.element interfaces. Having covariant overrides would >> interfere with such a reduced-type design. >> >> HTH, >> >> -Joe >> > Joe, > > I'm not sure I buy this variant of the "some compilers might want to > use a single type" argument. > > If the "kind" (ElementKind or TypeKind) of the return is always a > specific kind, then there is a presumption that it is safe to downcast > the returned object to the corresponding specific subtype. That could > be done equally well (or better) by declaring the return type of the > method to be more specific. The javax.lang.model spec makes statements in the root modeling hierarchies like: "To implement operations based on the class of an Element object, either use a visitor or use the result of the getKind() method. Using instanceof is not necessarily a reliable idiom for determining the effective class of an object in this modeling hierarchy since an implementation may choose to have a single object implement multiple Element subinterfaces." to document this situation. While it is true that if, say, the ElementKind is PACKAGE, a cast to PackageElement should succeed, it is *not* true that if an instanceof check against PackageElement succeeds, the kind can be inferred to be PACKAGE. If a compiler wanted to use the same implementation class for both TypeElement, PackageElement, and TypeParameterElement. That would work fine today since (by design) one class can implement all three interfaces. However, covariants returns would prevent that coding pattern since the return types of asType would not match (and bridge methods wouldn't help as there would be multiple specializations). > > I understand the "some compilers might want to use a single type" > argument, but that would only apply to internal implementation types, > and surely not would not absolve the compiler from the responsibility > of implementing specific subtypes where appropriate.? In other words, > there should be specified correspondence between "kind" and > implemented interfaces. During the development of JSR 269, the concerns over accommodating other compilers were not entirely theoretical :-) At least in this particular case, I don't see a lot of utility to pursue covariant overrides of the asType method at this time. (The current design also imposes fewer constraints on error handling situations.) Cheers, -Joe From jonathan.gibbons at oracle.com Thu May 30 23:03:47 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 16:03:47 -0700 Subject: JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces In-Reply-To: <168afc3e-89da-727f-20f9-168cdd332121@oracle.com> References: <05a8d594-020c-647c-987a-8241b1c87a1f@oracle.com> <84cd9ba5-091a-8737-4f71-e6809c30ffee@oracle.com> <168afc3e-89da-727f-20f9-168cdd332121@oracle.com> Message-ID: <8f874775-4f7c-f7f8-99dd-bd03fb269a34@oracle.com> There's a `type type` stutter in ExecutableElement. Otherwise, Looks Good To Me, and good to go -- Jon On 5/30/19 2:22 PM, Joe Darcy wrote: > Updated webrev: > > ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.3/ > > More descriptive comments in the test, added more specific @see tags > to the overridden methods (in part of suppress unwanted propagation of > the all the @see entries from Element.asType), and gave guidance on > the range of types for a variable. > > Diff of patches below, trimmed out some white space differences. > > Thanks, > > -Joe > > > 27,29c29,40 > < --- > old/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java > 2019-05-29 17:14:43.047376000 -0700 > < +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java > 2019-05-29 17:14:42.667376000 -0700 > < @@ -41,6 +41,15 @@ > --- > >????? TypeMirror asType(); > > > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java > 2019-05-30 14:15:59.625000999 -0700 > > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java > 2019-05-30 14:15:59.261000999 -0700 > > @@ -1,5 +1,5 @@ > >? /* > > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All > rights reserved. > > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >?? * > >?? * This code is free software; you can redistribute it and/or > modify it > > @@ -41,6 +41,17 @@ > 36a48,49 > > +???? * > > +???? * @see ExecutableType > 45,46c58,59 > < --- > old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java > 2019-05-29 17:14:43.735376000 -0700 > < +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java > 2019-05-29 17:14:43.375376000 -0700 > --- > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java > 2019-05-30 14:16:00.341000999 -0700 > > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java > 2019-05-30 14:15:59.957000999 -0700 > 55c68 > < @@ -37,6 +38,12 @@ > --- > > @@ -37,6 +38,16 @@ > 60c73,74 > < +???? * Returns a {@linkplain javax.lang.model.type.NoType > pseudo-type} for this module. > --- > > +???? * Returns a {@linkplain javax.lang.model.type.NoType pseudo-type} > > +???? * for this module. > 61a76,78 > > +???? * > > +???? * @see javax.lang.model.type.NoType > > +???? * @see javax.lang.model.type.TypeKind#MODULE > 68,69c85,93 > < --- > old/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java > 2019-05-29 17:14:44.439376000 -0700 > < +++ > new/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java > 2019-05-29 17:14:44.071376000 -0700 > --- > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java > 2019-05-30 14:16:01.049000999 -0700 > > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java > 2019-05-30 14:16:00.657000999 -0700 > > @@ -1,5 +1,5 @@ > >? /* > > - * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All > rights reserved. > > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >?? * > >?? * This code is free software; you can redistribute it and/or > modify it > 78c102 > < @@ -38,6 +39,12 @@ > --- > > @@ -38,6 +39,16 @@ > 83c107,108 > < +???? * Returns a {@linkplain javax.lang.model.type.NoType > pseudo-type} for this package. > --- > > +???? * Returns a {@linkplain javax.lang.model.type.NoType pseudo-type} > > +???? * for this package. > 84a110,112 > > +???? * > > +???? * @see javax.lang.model.type.NoType > > +???? * @see javax.lang.model.type.TypeKind#PACKAGE > 91,93c119,128 > < --- > old/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > 2019-05-29 17:14:45.139376000 -0700 > < +++ > new/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > 2019-05-29 17:14:44.751376000 -0700 > < @@ -60,6 +60,25 @@ > --- > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > 2019-05-30 14:16:01.745000999 -0700 > > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > 2019-05-30 14:16:01.373000999 -0700 > > @@ -1,5 +1,5 @@ > >? /* > > - * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All > rights reserved. > > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >?? * > >?? * This code is free software; you can redistribute it and/or > modify it > > @@ -60,6 +60,28 @@ > 110a146,148 > > +???? * > > +???? * @see Types#asMemberOf(DeclaredType, Element) > > +???? * @see Types#getDeclaredType(TypeElement, TypeMirror...) > 119,120c157,165 > < --- > old/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java > 2019-05-29 17:14:45.811376000 -0700 > < +++ > new/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java > 2019-05-29 17:14:45.455376000 -0700 > --- > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java > 2019-05-30 14:16:02.509000999 -0700 > > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java > 2019-05-30 14:16:02.109000999 -0700 > > @@ -1,5 +1,5 @@ > >? /* > > - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All > rights reserved. > > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >?? * > >?? * This code is free software; you can redistribute it and/or > modify it > 137,139c182,191 > < --- > old/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java > 2019-05-29 17:14:46.475376000 -0700 > < +++ > new/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java > 2019-05-29 17:14:46.119376000 -0700 > < @@ -26,6 +26,7 @@ > --- > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java > 2019-05-30 14:16:03.233000999 -0700 > > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java > 2019-05-30 14:16:02.857000999 -0700 > > @@ -1,5 +1,5 @@ > >? /* > > - * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All > rights reserved. > > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All > rights reserved. > >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >?? * > >?? * This code is free software; you can redistribute it and/or > modify it > > @@ -26,6 +26,8 @@ > 143a196 > > +import javax.lang.model.type.TypeKind; > 147c200 > < @@ -38,6 +39,12 @@ > --- > > @@ -38,6 +40,19 @@ > 152a206,210 > > +???? * > > +???? * Note that the types of variables range over {@linkplain > > +???? * TypeKind many kinds} of types, including primitive types, > > +???? * declared types, and array types, among others. > > +???? * > 153a212,213 > > +???? * > > +???? * @see TypeKind > 161,162c221,222 > < +++ > new/test/langtools/tools/javac/processing/model/element/TestElementAsType.java > 2019-05-29 17:14:46.795376000 -0700 > < @@ -0,0 +1,139 @@ > --- > > +++ > new/test/langtools/tools/javac/processing/model/element/TestElementAsType.java > 2019-05-30 14:16:03.561000999 -0700 > > @@ -0,0 +1,152 @@ > 273a334,342 > > +??? /* > > +???? * For both of the maps below, a ElementKind value is mapped to > > +???? * one value related to an element's asType image. In some cases, > > +???? * the ElementKind -> (TypeMirror type, TypeKind) mapping is > > +???? * always the same, such as ElementKind.PACKAGE mapping to > > +???? * (NoType.class, TypeKind.PACKAGE). In other cases, such as for a > > +???? * field, there are many possible mappings and they are not > > +???? * attempted to be examined exhaustively by this test. > > +???? */ > 280a350,351 > > +?????????????? // For the field NestedClass.name that is tested, a > > +?????????????? // declared type is used. > 289a361,362 > > +?????????????? // For the field NestedClass.name that is tested, a > > +?????????????? // declared type is used. > > > On 5/30/2019 12:04 PM, Joe Darcy wrote: >> Hi Jon, >> >> On 5/30/2019 10:23 AM, Jonathan Gibbons wrote: >>> >>> >>> On 05/30/2019 10:15 AM, Jonathan Gibbons wrote: >>>> >>>> >>>> On 05/29/2019 05:24 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> Please review the webrev and CSR for: >>>>> >>>>> ??? JDK-8224687: Add clarifying overrides of Element.asType to >>>>> more specific subinterfaces >>>>> ??? webrev: http://cr.openjdk.java.net/~darcy/8224687.2/ >>>>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225027 >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>> >>>> Joe, >>>> >>>> CSR Reviewed. >>>> >>>> In the new test, I don't understand lines 119, 128, regarding >>>> ElementKind.FIELD. >>>> Either the code is a copy-paste error, or the description elsewhere >>>> of DeclaredType >>>> and TypeKind.DECLARED is incorrect, since these only refer to >>>> declared types >>>> (class, interface, etc) and not fields. >>>> >>>> Surprising or maybe not, the test actually passes, suggesting that >>>> this is the >>>> current behavior even if it is unexpected.? That being said, the >>>> output from the >>>> test would be easier to understand if it included the ElementKind >>>> and simple name >>>> of the element, as well as the typeMirror, typeMirror class and >>>> typeKind. >>>> >>>> -- Jon >>> >>> I guess what is happening is that the mapping to TypeMirror for >>> ElementKind.FIELD >>> varies, depending on the field being declared. If so, that deserves >>> mention in the >>> spec for VariableElement.asType, and also deserves a comment in the >>> test code. >>> I'll stop short of suggesting that the test code should have more >>> fields in it, such as >>> a field of primitive type, but if you could find an easy way to >>> adapt the test for that, >>> that would be good too. >>> >> >> Correct. I propose adding some additional documentation around the >> maps used by the test: >> >>> ??? /* >>> ???? * For both of the maps below, a ElementKind value is mapped to >>> ???? * one value related to an element's asType image. In some cases, >>> ???? * the ElementKind -> (TypeMirror type, TypeKind) mapping is >>> ???? * always the same, such as ElementKind.PACKAGE mapping to >>> ???? * (NoType.class, TypeKind.PACKAGE). In other cases, such as for a >>> ???? * field, there are many possible mappings and they are not >>> ???? * attempted to be examined exhaustively by this test. >>> ???? */ >>> ??? private static final Map> >>> elementKindToTypeClass = >>> ??????? Map.of(ElementKind.CLASS, DeclaredType.class, >>> ?????????????? ElementKind.CONSTRUCTOR, ExecutableType.class, >>> ?????????????? ElementKind.METHOD, ExecutableType.class, >>> ?????????????? ElementKind.PACKAGE, NoType.class, >>> ?????????????? ElementKind.MODULE, NoType.class, >>> ?????????????? ElementKind.TYPE_PARAMETER, TypeVariable.class, >>> ?????????????? // For the field NestedClass.name that is tested, a >>> ?????????????? // declared type is used. >>> ?????????????? ElementKind.FIELD, DeclaredType.class); >>> >>> ??? private static final Map >>> elementKindToTypeKind = >>> ??????? Map.of(ElementKind.CLASS, TypeKind.DECLARED, >>> ?????????????? ElementKind.CONSTRUCTOR, TypeKind.EXECUTABLE, >>> ?????????????? ElementKind.METHOD, TypeKind.EXECUTABLE, >>> ?????????????? ElementKind.PACKAGE, TypeKind.PACKAGE, >>> ?????????????? ElementKind.MODULE, TypeKind.MODULE, >>> ?????????????? ElementKind.TYPE_PARAMETER, TypeKind.TYPEVAR, >>> ?????????????? // For the field NestedClass.name that is tested, a >>> ?????????????? // declared type is used. >>> ?????????????? ElementKind.FIELD, TypeKind.DECLARED); >>> >> For the cases where only one flavor of mapping is possible, such as >> packages and modules, the revised map explicitly mentions the >> mapping. I'll work on crafting an additional sentence along the lines >> of "Note that a variable can have many possible kinds of types." >> >> Thanks, >> >> -Joe >> >> From ronshapiro at google.com Thu May 30 23:09:17 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Thu, 30 May 2019 19:09:17 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: Do you have any other comments on the first webrev? Is there anything else we need to do to submit that? On Wed, May 22, 2019 at 11:00 AM Ron Shapiro wrote: > I think there still would be benefit in that as well, as I'm seeing that > come up in other contexts (as referenced in the bug). > > On Wed, May 22, 2019 at 9:06 AM Jan Lahoda wrote: > >> Sorry, I was too busy last few days. >> >> I was peeking at some possible improvements, but I think I like Ron's >> first (.00) patch - that caches what can be cached nicely. >> >> Looking at the testcase generated by Ron's reproducer using: >> python test.py 7 >> >> and the (biggest) size of the outcome of: >> types.membersClosure(site, false).getSymbolsByName(sym.name, cf) >> >> seems to be 13700 elements - which means the Scope lookup and iteration >> runs ~13700 times, so avoiding these additional lookup costs seems like >> a clear win. >> >> I have an idea that might speed up the iterations through deeply nested >> CompoundScopes, although the effect of that in combination with Ron's is >> going to be fairly limited, if any, I think. >> >> Jan >> >> On 22. 05. 19 12:24, Maurizio Cimadamore wrote: >> > This doesn't work. You are basically relying on the order in which >> > symbols are entered in the members closure scope. >> > >> > In simple example like these: >> > >> > class A { >> > int m(List l) {return 0;} >> > } >> > >> > class B extends A { >> > int m(List l) {return 0;} >> > } >> > >> > >> > The logic you proposed will not work. That's because we first see B::m >> - >> > and 'symbolByName' is empty at that stage; so we add it there. Then we >> > do another round and see A::m - but we don't really look there - given >> > that we first check to see if the symbol we're considering (sym) is >> > override-equivalent with B::m (the only symbol in symbolByName). And >> > that happens to be the case, since they are the same symbol. So we exit >> > the loop, w/o having found any clash. >> > >> > In other words, symbolByName would need to also contain A::m for the >> > code to see the clash - but that never happens; by the time A::m is >> > added, is already too late. >> > >> > >> > I think caching the result of >> > >> > types.membersClosure(site, false).getSymbolsByName(sym.name, cf) >> > >> > is a good measure. >> > >> > I'm a bit surprised that iteration is so slow (membersClosure is slow >> to >> > set up, but once you do it the results are cached). So, rather than >> > tweaking the algorithm, I think it'd be better to investigate the >> reason >> > was to why asking a compound scope iterator is so slow, which then >> would >> > yield dividends for the rest of the code as well. >> > >> > Maurizio >> > >> > >> > On 21/05/2019 21:21, Maurizio Cimadamore wrote: >> >> >> >> I see what you have done - I have to think about it a bit to see if I >> >> can come up with some counter example. >> >> >> >> Thanks >> >> Maurizio >> >> >> >> On 21/05/2019 17:39, Ron Shapiro wrote: >> >>> Are the checks of the inner loop symmetrical? >> >>> >> >>> Currently it's checking m_i against (m_0..n - m_i ). This second >> >>> webrev below would check it against just (m_0..i-1 ), which albeit >> >>> still n^2, it divides by a factor of 2. >> >>> >> >>> (sorry if the subscripting here doesn't display correctly) >> >>> >> >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ >> >>> >> >>> This feels conceptually logical to me, but I'm not seeing a >> >>> measurable change by it. It looks a little bit cleaner to me, but I'm >> >>> fine with either webrev given the benefits they both bring. >> >>> >> >>> I can take a look in another thread about speeding up CompoundScope >> >>> iteration. >> >>> >> >>> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore >> >>> > >>> > wrote: >> >>> >> >>> >> >>> On 21/05/2019 12:16, Ron Shapiro wrote: >> >>>> I still think that something to optimize the actual ScopeImpl >> >>>> Iterable is a worthwhile endeavor, as that would alleviate the >> >>>> need to materialize here (and solve hopefully the other issues >> >>>> I'm seeing), but I was having trouble figuring out how to do >> >>>> that. This may be a good interim option without much cost. >> >>> >> >>> Sure - I'm not opposed to optimizing the iteration process - I >> >>> was expressing my skepticism w.r.t. making checkOverrideClash >> >>> simpler/non quadratic. >> >>> >> >>> Maurizio >> >>> >> >>>> >> >>>> >> >>>> >> >>>> On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore >> >>>> > >>>> > wrote: >> >>>> >> >>>> I think your fix is a good one. We spent some cycles >> >>>> optimizing this, a bit odd we have missed this :-) >> >>>> >> >>>> I'm very skeptical you can collapse into a single loop, as >> >>>> this implement the logic in JLS 8.4.8.3 [1] which, as you >> >>>> can see, is inherently quadratic (for each method, we have >> >>>> to scan all methods with same name in supertypes to see if >> >>>> there is an override clash). The algorithm that was there >> >>>> before wasn't - and it lead to the wrong answers in tricky >> >>>> cases - so while you can get 80% there with a non-quadratic >> >>>> algorithm, you will miss issues by doing so. >> >>>> >> >>>> One thing that would help would be, instead, to limit the >> >>>> analysis only in cases where it adds value - for instance, >> >>>> if your hierarchy is just non-generic classes (as in your >> >>>> example), then there's no way for you to accidentally >> >>>> override a 'bridge' method, since no bridges will be >> >>>> generated! But when looking at this, I couldn't find great >> >>>> ways to detect these conditions w/o spending more time than >> >>>> the check itself. >> >>>> >> >>>> [1] - >> >>>> >> https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 >> >>>> >> >>>> Maurizio >> >>>> >> >>>> On 20/05/2019 21:58, Ron Shapiro wrote: >> >>>>> In the real world example, I'm seeing the 40s that was >> >>>>> previously spent in Check.checkOverrideClashes drop to to >> >>>>> 9.5s when using this patch. Of that 9.5, 8.9 is spent in >> >>>>> iterating through the CompoundIterator and calling >> >>>>> getSymbolsByName. >> >>>>> >> >>>>> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro >> >>>>> > >> wrote: >> >>>>> >> >>>>> This patch, which materializes the duplicate outer and >> >>>>> inner Iterables first into a list. It removes the >> >>>>> entire section of the CompoundIterator iteration from >> >>>>> the profile. >> >>>>> >> >>>>> webrev: >> >>>>> >> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >> >>>>> >> >>>>> I'm not sure it's the absolutely correct solution as it >> >>>>> possibly masks an underlying issue. >> >>>>> >> >>>>> I'm still seeing some time spent in >> >>>>> MethodSymbol.overrides, Types.isSubSignature, and >> >>>>> Types.memberType, all of which happen in the inner >> >>>>> loop. If we can remove those and collapse the nested >> >>>>> loops into one, then this solution isn't necessary and >> >>>>> it would also solve that performance issue. >> >>>>> >> >>>>> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >> >>>>> > >> >>>>> wrote: >> >>>>> >> >>>>> I still have more to investigate to fully wrap my >> >>>>> head around it, but I finally found a sample >> >>>>> program that exhibits this. Filed a bug here: >> >>>>> https://bugs.openjdk.java.net/browse/JDK-8224161 >> >>>>> >> >>>>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >> >>>>> > >>>>> > wrote: >> >>>>> >> >>>>> Hi Ron, >> >>>>> >> >>>>> I am afraid it is hard to guess what is the >> >>>>> problem without some >> >>>>> testcase. So, at least to me, having a sample >> >>>>> would be helpful. >> >>>>> >> >>>>> Thanks, >> >>>>> Jan >> >>>>> >> >>>>> On 17. 05. 19 0:41, Ron Shapiro wrote: >> >>>>> > Hi, >> >>>>> > >> >>>>> > I'm observing a particularly bizarre >> >>>>> compilation. It's a single file >> >>>>> > with annotation processing, and the type that >> >>>>> is being compiled and >> >>>>> > processed has ~1000 declared and inherited >> >>>>> methods combined. The total >> >>>>> > compilation is 3 minutes, but 65% of the >> >>>>> entire compilation is spent in >> >>>>> > 3 methods: >> >>>>> > >> >>>>> >> Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), >> >>>>> >> >>>>> > and Resolve.findField(). >> >>>>> > >> >>>>> > Looking at profiles, it looks like >> >>>>> getSymbolsByName() is the major >> >>>>> > culprit here. I initially thought the reason >> >>>>> was that there were far too >> >>>>> > many overloads (this type had >600 >> >>>>> overloads...) and that that was >> >>>>> > causing a bad regression for the >> >>>>> pseudo-hashmap that ScopeImpl uses. >> >>>>> > However, renaming the methods did not >> >>>>> alleviate the build pain and these >> >>>>> > methods continue to be taking long amounts of >> >>>>> time. >> >>>>> > >> >>>>> > I was wondering what could be done to improve >> >>>>> the performance of this >> >>>>> > code. It seemed to me that something like a >> >>>>> Map> >> >>>>> > could be a reasonable+modern replacement for >> >>>>> this table, which would >> >>>>> > naturally have a fast getSymbolsForName() >> >>>>> implementation. I'm having >> >>>>> > some trouble implementing it correctly, and I >> >>>>> believe it's partially >> >>>>> > related to not fully understanding some of >> >>>>> the semantics of the class. >> >>>>> > >> >>>>> > Does what I wrote make sense to anyone, and >> >>>>> maybe spark a lightbulb? >> >>>>> > >> >>>>> > I'm trying to put together a repro in case >> >>>>> that helps, but I'm not 100% >> >>>>> > sure I even understand what the regression >> >>>>> case is. >> >>>>> > >> >>>>> > Thanks for you help! >> >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Fri May 31 12:26:35 2019 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 31 May 2019 14:26:35 +0200 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions References: Message-ID: <87h89alshw.fsf@oldenburg2.str.redhat.com> * Jan Lahoda: > Hi, > > I'd like to ask for a review of changes to update javac to follow the > current spec for switch expressions, in particular the break -> yield > change: > http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html I think the purpose of these rules is to avoid certain forms of non-local control flow (and avoid specifying whether the loop control expression(s) are part of the loop or not): | It is a compile-time error if the break target of a break statement | contains any method, constructor, initializer, lambda expression, or | switch expression that encloses the break statement. | It is a compile-time error if the continue target contains any method, | constructor, initializer, lambda expression, or switch expression that | contains the continue statement. | It is a compile-time error if the return target contains any | initializer, or switch expression that encloses the return statement. Are these rules really technically correct? Maybe it's more obvious to define the target in such a way that it must be located within the same method, constructor, or initializer. I think then it's possible to require that the break/continue/return target must not contain any expression that also contains the break/continue/return statement. (And also define that do/for/switch/while statements contain both the body and the expression(s).) For a specification point of view, I think it might be more straightforward to specify statement expressions first and then use them to define switch expressions. Thanks, Florian From alex.buckley at oracle.com Fri May 31 16:30:01 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 31 May 2019 09:30:01 -0700 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: <87h89alshw.fsf@oldenburg2.str.redhat.com> References: <87h89alshw.fsf@oldenburg2.str.redhat.com> Message-ID: <5CF15689.30608@oracle.com> On 5/31/2019 5:26 AM, Florian Weimer wrote: > * Jan Lahoda: > >> Hi, >> >> I'd like to ask for a review of changes to update javac to follow the >> current spec for switch expressions, in particular the break -> yield >> change: >> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html > > I think the purpose of these rules is to avoid certain forms of > non-local control flow (and avoid specifying whether the loop control > expression(s) are part of the loop or not): I believe that Jan was asking for a review of the javac changes (appropriate for compiler-dev) rather than the spec changes (belongs on amber-spec-{experts,observers,comments}). > | It is a compile-time error if the break target of a break statement > | contains any method, constructor, initializer, lambda expression, or > | switch expression that encloses the break statement. > > | It is a compile-time error if the continue target contains any method, > | constructor, initializer, lambda expression, or switch expression that > | contains the continue statement. > > | It is a compile-time error if the return target contains any > | initializer, or switch expression that encloses the return statement. > > Are these rules really technically correct? Maybe it's more obvious to > define the target in such a way that it must be located within the same > method, constructor, or initializer. I think then it's possible to > require that the break/continue/return target must not contain any > expression that also contains the break/continue/return statement. (And > also define that do/for/switch/while statements contain both the body > and the expression(s).) The rules you quoted are a smooth extension (to include switch expressions) of the longstanding rules that prevent non-local jumps by `break` and `continue`, and bad jumps by `return`. You didn't quote the corresponding rule for `yield` whose form aligns with the rules above. Minimizing churn and maximizing alignment are very good things in a spec. The policy being implemented by the rules was given in https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-April/001232.html (for `break-with` and `break-e`, read `yield`). > For a specification point of view, I think it might be more > straightforward to specify statement expressions first and then use them > to define switch expressions. Not sure what you mean. Statement expressions exist so that an expression can appear either as a subexpression or as a top-level statement (followed by `;`, i.e., an expression statement). Defining a switch expression as a statement expression would imply that a top-level switch statement is followed by `;`, which is wrong. If you have further spec feedback, please send concrete proposals (rather than outlines of what might be possible) to amber-spec-comments. Alex From amalloy at google.com Fri May 31 20:25:21 2019 From: amalloy at google.com (Alan Malloy) Date: Fri, 31 May 2019 13:25:21 -0700 Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod In-Reply-To: <8ba6f699-4634-0800-c5cd-601b1d97c0f8@oracle.com> References: <8ba6f699-4634-0800-c5cd-601b1d97c0f8@oracle.com> Message-ID: New patch removes the cast but leaves the method call. Please take a look. http://cr.openjdk.java.net/~cushon/8224629/webrev.01/ On Tue, May 28, 2019 at 10:42 AM Vicente Romero wrote: > > > On 5/28/19 12:50 PM, Alan Malloy wrote: > > We already have a MethodHandleSymbol, though. You're envisioning something > like this? > > class FancySymbol extends MethodHandleSymbol { > public MethodHandleSymbol asHandle() { > return new DelegatingFancySymbol(this); > } > } > > > it would be more common to create an anonymous inner class, but yes the > idea is the same. > > > I'd argue that if FancySymbol wants to require you to call asHandle() > before you can treat it as a MethodHandleSymbol, it should have made itself > a MethodSymbol, not a MethodHandleSymbol. Then, of course clients would be > required to use its asHandle method, invoking whatever non-obvious logic it > represents, in order to get a MethodHandleSymbol. I don't see any value in > catering to classes like this. If someone someday really does add > FancySymbol and needs all users of MethodHandleSymbol to call asHandle() on > all instances, they'll have more use sites than this one to refactor (right > now, I see LambdaToMethod.addDeserializationCase, PoolWriter.writeConstant, > and perhaps DynamicMethodSymbol will need some rethinking). > > But if you are sure, then we should at least remove the meaningless upcast. > > > yep I agree on removing the upcast, > > Vicente > > > On Tue, May 28, 2019 at 9:29 AM Vicente Romero > wrote: > >> I think that I prefer the flexibility that invoking the ::asHandle >> method brings. Suppose that a subclass wants to provide an >> implementation of the asHandle method that will return the non-obvious >> result. Not a high probability case but we have seen similar uses to the >> Symbol::baseSymbol method. I think I prefer to have options, >> >> Vicente >> >> On 5/22/19 8:50 PM, Alan Malloy wrote: >> > Hello. Please review this patch to eliminate an unnecessary upcast and >> > method call in LambdaToMethod. >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8224629 >> > webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/ >> > >> > Testing: All of jtreg:test/langtools/tools/javac pass locally. No new >> > test added, as no behavior change is intended. >> > >> > Thanks, >> > Alan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri May 31 20:27:26 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 31 May 2019 16:27:26 -0400 Subject: RFR: 8224629: Unnecessary indirection in LambdaToMethod In-Reply-To: References: <8ba6f699-4634-0800-c5cd-601b1d97c0f8@oracle.com> Message-ID: <042722bc-7046-e943-23b0-c0fee39c0835@oracle.com> looks good, Vicente On 5/31/19 4:25 PM, Alan Malloy wrote: > New patch removes the cast but leaves the method call. Please take a > look. > > http://cr.openjdk.java.net/~cushon/8224629/webrev.01/ > > On Tue, May 28, 2019 at 10:42 AM Vicente Romero > > wrote: > > > > On 5/28/19 12:50 PM, Alan Malloy wrote: >> We already have a MethodHandleSymbol, though. You're envisioning >> something like this? >> >> class FancySymbol extends MethodHandleSymbol { >> ? ? public MethodHandleSymbol asHandle() { >> ? ? ? ? return new DelegatingFancySymbol(this); >> ? ? } >> } > > it would be more common to create an anonymous inner class, but > yes the idea is the same. >> >> I'd argue that if FancySymbol wants to require you to call >> asHandle() before you can treat it as a MethodHandleSymbol, it >> should have made itself a MethodSymbol, not a MethodHandleSymbol. >> Then, of course clients would be required to use its asHandle >> method, invoking whatever non-obvious logic it represents, in >> order to get a MethodHandleSymbol. I don't see any value in >> catering to classes like this. If someone someday really does add >> FancySymbol and needs all users of MethodHandleSymbol to call >> asHandle() on all instances, they'll have more use sites than >> this one to refactor (right now, I see >> LambdaToMethod.addDeserializationCase, PoolWriter.writeConstant, >> and perhaps DynamicMethodSymbol will need some rethinking). >> >> But if you are sure, then we should at least remove the >> meaningless upcast. > > yep I agree on removing the upcast, > > Vicente >> >> On Tue, May 28, 2019 at 9:29 AM Vicente Romero >> > wrote: >> >> I think that I prefer the flexibility that invoking the >> ::asHandle >> method brings. Suppose that a subclass wants to provide an >> implementation of the asHandle method that will return the >> non-obvious >> result. Not a high probability case but we have seen similar >> uses to the >> Symbol::baseSymbol method. I think I prefer to have options, >> >> Vicente >> >> On 5/22/19 8:50 PM, Alan Malloy wrote: >> > Hello. Please review this patch?to eliminate an unnecessary >> upcast and >> > method call in LambdaToMethod. >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8224629 >> > webrev: http://cr.openjdk.java.net/~cushon/8224629/webrev.00/ >> > >> > Testing: All of?jtreg:test/langtools/tools/javac pass >> locally. No new >> > test added, as no behavior change is intended. >> > >> > Thanks, >> > ? ? Alan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri May 31 22:01:24 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 31 May 2019 15:01:24 -0700 Subject: RFR: JDK-8224083: javadoc Reporter generates "warning" for Kind.NOTE In-Reply-To: References: <93b428fd-4b2b-c38d-c520-c753743ac9d5@oracle.com> <5adf6be0-8dc7-13b1-245b-609e03524f61@oracle.com> Message-ID: Nice; I like all the specific positive tests. -- Jon On 05/30/2019 09:48 AM, Vicente Romero wrote: > Hi Jon, > > I have published another iteration at [1], some comments below, > > On 5/29/19 7:10 PM, Jonathan Gibbons wrote: >> >> Hi Vicente, >> >> The fix for the source file looks good, but there are a few things to >> note with the test. >> >> 1. You check that "warning" does not appear, but you don't check that >> NullPointerException does not appear, which is the other bug you are >> fixing. >> > > the test fails if a NPE happens that's why I didn't see necessary to > add a specific check for that > >> 2. Tests that strings do not appear are typically very weak tests. If >> the test were to do nothing, or crash on startup, the designated text >> would not appear and the test would pass as a false positive.? While >> it is not wrong to test that text does not appear, it is generally >> better to augment it with a test to verify that some expected output >> does appear. >> > > I have modified the check and now I'm checking for a specific output. > >> 3. Using javac.util.Assert is a bit of overkill, since it means you >> have to expose it in the @modules clause.? I think it is better to >> just test the condition and throw an exception directly. Depending on >> and using javac internal classes is an anti-pattern we should avoid >> as much as possible. >> > I removed the use of Assert >> >> 4. You can simplify the test by combining the doclet into the test >> class itself, avoiding the use of a long multi-line string; this also >> has the side effect of compiling the doclet for you for free, so that >> you don't need to compile that string.You can see this technique used >> in a number of javadoc tests: try the following code to get a list of >> examples: >> >> ?? ??? grep -r 'implements Doclet' open/test/langtools >> >> You should be able to merge the classes since your test code just >> "extends TestRunner" and a doclet "implements Doclet", which can both >> be accomplished in a single class. >> >> If all that sounds too clever, I would move the demo doclet into a >> new source file, so that it can easily be modified (if needed) by a >> standard IDE, instead of having to be careful about editing Java >> source code embedded in a long string constant. Even if you move it >> into a new source file in a subdirectory of the test directory >> (test/langtools/jdk/javadoc/tool/reporter_generates_warnings/) you >> can still use jtreg to compile the file with an obvious use of >> @build.? Given that the NPE was triggered by the doclet analyzing >> code in a named package, this is probably the better way to go ... to >> ensure that the pathway that used to generate NPE is also tested. >> >> -- Jon > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8224083/webrev.01/ >> >> >> On 05/29/2019 03:27 PM, Vicente Romero wrote: >>> Please review fix for [1] and [2] at [3]. These are two separate >>> issues for which the same test is provided so this one patch will >>> fix both. The first issue is related to >>> jdk.javadoc.internal.tool.Messager, producing warnings at method: >>> print(Kind kind, Element e, String msg) >>> even if it was instructed to produce notes. A case for Kind.NOTE was >>> added. The other issue was this same class throwing a NPE if it >>> couldn't find an element at method ::getDiagSource. In this case a >>> check for null is done and `programName` is returned as it is done >>> already for a similar case in that method, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8224083 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8224082 >>> [3] http://cr.openjdk.java.net/~vromero/8224083/webrev.00/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri May 31 22:25:38 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 31 May 2019 18:25:38 -0400 Subject: RFR: JDK-8224083: javadoc Reporter generates "warning" for Kind.NOTE In-Reply-To: References: <93b428fd-4b2b-c38d-c520-c753743ac9d5@oracle.com> <5adf6be0-8dc7-13b1-245b-609e03524f61@oracle.com> Message-ID: thanks, Vicente On 5/31/19 6:01 PM, Jonathan Gibbons wrote: > > Nice; > > I like all the specific positive tests. > > -- Jon > > > > On 05/30/2019 09:48 AM, Vicente Romero wrote: >> Hi Jon, >> >> I have published another iteration at [1], some comments below, >> >> On 5/29/19 7:10 PM, Jonathan Gibbons wrote: >>> >>> Hi Vicente, >>> >>> The fix for the source file looks good, but there are a few things >>> to note with the test. >>> >>> 1. You check that "warning" does not appear, but you don't check >>> that NullPointerException does not appear, which is the other bug >>> you are fixing. >>> >> >> the test fails if a NPE happens that's why I didn't see necessary to >> add a specific check for that >> >>> 2. Tests that strings do not appear are typically very weak tests. >>> If the test were to do nothing, or crash on startup, the designated >>> text would not appear and the test would pass as a false positive.? >>> While it is not wrong to test that text does not appear, it is >>> generally better to augment it with a test to verify that some >>> expected output does appear. >>> >> >> I have modified the check and now I'm checking for a specific output. >> >>> 3. Using javac.util.Assert is a bit of overkill, since it means you >>> have to expose it in the @modules clause.? I think it is better to >>> just test the condition and throw an exception directly. Depending >>> on and using javac internal classes is an anti-pattern we should >>> avoid as much as possible. >>> >> I removed the use of Assert >>> >>> 4. You can simplify the test by combining the doclet into the test >>> class itself, avoiding the use of a long multi-line string; this >>> also has the side effect of compiling the doclet for you for free, >>> so that you don't need to compile that string.You can see this >>> technique used in a number of javadoc tests: try the following code >>> to get a list of examples: >>> >>> ?? ??? grep -r 'implements Doclet' open/test/langtools >>> >>> You should be able to merge the classes since your test code just >>> "extends TestRunner" and a doclet "implements Doclet", which can >>> both be accomplished in a single class. >>> >>> If all that sounds too clever, I would move the demo doclet into a >>> new source file, so that it can easily be modified (if needed) by a >>> standard IDE, instead of having to be careful about editing Java >>> source code embedded in a long string constant. Even if you move it >>> into a new source file in a subdirectory of the test directory >>> (test/langtools/jdk/javadoc/tool/reporter_generates_warnings/) you >>> can still use jtreg to compile the file with an obvious use of >>> @build.? Given that the NPE was triggered by the doclet analyzing >>> code in a named package, this is probably the better way to go ... >>> to ensure that the pathway that used to generate NPE is also tested. >>> >>> -- Jon >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8224083/webrev.01/ >>> >>> >>> On 05/29/2019 03:27 PM, Vicente Romero wrote: >>>> Please review fix for [1] and [2] at [3]. These are two separate >>>> issues for which the same test is provided so this one patch will >>>> fix both. The first issue is related to >>>> jdk.javadoc.internal.tool.Messager, producing warnings at method: >>>> print(Kind kind, Element e, String msg) >>>> even if it was instructed to produce notes. A case for Kind.NOTE >>>> was added. The other issue was this same class throwing a NPE if it >>>> couldn't find an element at method ::getDiagSource. In this case a >>>> check for null is done and `programName` is returned as it is done >>>> already for a similar case in that method, >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8224083 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8224082 >>>> [3] http://cr.openjdk.java.net/~vromero/8224083/webrev.00/ >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: