From brian.goetz at oracle.com Wed Jun 1 13:55:44 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 1 Jun 2022 09:55:44 -0400 Subject: Purpose of parenthesised patterns In-Reply-To: References: Message-ID: <6058dc95-6192-982d-2071-e1c0b50b0aa2@oracle.com> You are right, that without guards they are of limited use.? We considered pulling them out, but in future, we are likely to see AND patterns, which would again require parenthesized patterns. On 5/31/2022 1:35 PM, Izz Rainy wrote: > With guard patterns removed and no composite "and"/"or" patterns, what's > the purpose of parenthesised patterns? Is it simply an oversight, or am I > missing something? From duke at openjdk.java.net Wed Jun 1 14:23:06 2022 From: duke at openjdk.java.net (Tesla I. =?UTF-8?B?WmhhbmfigK4=?=) Date: Wed, 1 Jun 2022 14:23:06 GMT Subject: [amber-docs] RFR: Apply markdown formatting on GitHub Message-ID: Renamed README to README.md so the file will be displayed with markdown rendering on GitHub. ------------- Commit messages: - Apply markdown formatting on GitHub Changes: https://git.openjdk.java.net/amber-docs/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=amber-docs&pr=17&range=00 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/amber-docs/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/amber-docs pull/17/head:pull/17 PR: https://git.openjdk.java.net/amber-docs/pull/17 From vab2048 at gmail.com Sat Jun 11 12:06:11 2022 From: vab2048 at gmail.com (Vikram Bakshi) Date: Sat, 11 Jun 2022 13:06:11 +0100 Subject: Pattern matching on Class Message-ID: Hello, Apologies if code formatting does not appear well (I'm not used to mailing lists). All code blocks are available to view here: https://stackoverflow.com/questions/72545671/pattern-matching-on-classt I asked a question on stackoverflow about why we cannot match on Class in the way I expect. Suppose we have: sealed interface Animal permits Dog, Cat, Bear {} record Dog() implements Animal {} record Cat() implements Animal {} record Bear() implements Animal {} This would work: static String makeNoise(Class cls) { if(cls.equals(Dog.class)) { return "WOOF"; } else if(cls.equals(Cat.class)) { return "MEOW"; } else if(cls.equals(Bear.class)) { return "ROAR"; } else { throw new IllegalStateException("Unknown state"); } } But this wouldn't: static String makeNoisePatternMatch(Class cls) { return switch(cls) { case Dog.class c -> "WOOF"; case Cat.class c -> "MEOW"; case Bear.class c -> "ROAR"; }; } I got the answer on Stack Overflow that this is not allowed by the spec. My question to the mailing list is: will the current restriction be lifted in the future? Will we be able to pattern match like the above? And if not - how come it is restricted (I'm not criticising but rather just asking more out of curiosity to understand the decision to maintain the restriction)? Regards, From numeralnathan at gmail.com Sat Jun 11 13:18:12 2022 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Sat, 11 Jun 2022 07:18:12 -0600 Subject: Pattern matching on Class In-Reply-To: References: Message-ID: I have hit this same idea several times in the past 2 weeks. I too would like to switch on Class. On Sat, Jun 11, 2022 at 6:06 AM Vikram Bakshi wrote: > Hello, > > Apologies if code formatting does not appear well (I'm not used to mailing > lists). All code blocks are available to view here: > https://stackoverflow.com/questions/72545671/pattern-matching-on-classt > > I asked a question on stackoverflow about why we cannot match on Class > in the way I expect. Suppose we have: > > sealed interface Animal permits Dog, Cat, Bear {} > record Dog() implements Animal {} > record Cat() implements Animal {} > record Bear() implements Animal {} > > This would work: > > static String makeNoise(Class cls) { > if(cls.equals(Dog.class)) { > return "WOOF"; > } else if(cls.equals(Cat.class)) { > return "MEOW"; > } else if(cls.equals(Bear.class)) { > return "ROAR"; > } else { > throw new IllegalStateException("Unknown state"); > } > } > > But this wouldn't: > > static String makeNoisePatternMatch(Class Animal> cls) { > return switch(cls) { > case Dog.class c -> "WOOF"; > case Cat.class c -> "MEOW"; > case Bear.class c -> "ROAR"; > }; > } > > I got the answer on Stack Overflow that this is not allowed by the spec. My > question to the mailing list is: will the current restriction be lifted in > the future? > > Will we be able to pattern match like the above? And if not - how come it > is restricted (I'm not criticising but rather just asking more out of > curiosity to understand the decision to maintain the restriction)? > > Regards, > From brian.goetz at oracle.com Sat Jun 11 14:20:13 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 11 Jun 2022 10:20:13 -0400 Subject: Pattern matching on Class In-Reply-To: References: Message-ID: <8e2582de-19d2-97c1-fb2f-a9e3cbe8ed31@oracle.com> This has been raised before, and it goes in the category of "not a terrible idea, but much lower priority that a lot of other things." First, this feature is bigger than you are imagining.? Switch has an ad-hoc set of allowed constant switch labels (integers, strings, enums).? And, if we never thought about pattern matching, adding another ad-hoc set of constant labels might have seemed a reasonable extension.? But now that we have patterns, it becomes clear that these are only "switch-deep", because while you might be able to say: ??? case Foo.class: you can't use `Foo.class` as a constant pattern in a nested context: ??? case Bar(Foo.class): We need to settle our story for constant patterns first.? And, that one is also not at the top of the priority list. That's the cost side; on the benefit side, the benefit is pretty marginal.? (It's not zero, but its marginal.)? If you have an Animal in hand, you can use a type pattern.? (Having two ways to do it, which are subtly different, also is likely to be a source of bugs.) And, if you really want to switch on class literals in O(1) time, you can use a Map.? Your example can be written as: ??? Map, String> sounds ??????? = Map.of(entry(Dog.class, "WOOF"), ???????????????? entry(Cat.class, "MEOW"), ???????????????? ...); And, if you want behavior, you can put a lambda in the map.? So the power of the feature is pretty limited; its mostly notational.? But its not notational in a way that (currently) synergizes with other notations, making it weak. On 6/11/2022 8:06 AM, Vikram Bakshi wrote: > Hello, > > Apologies if code formatting does not appear well (I'm not used to mailing > lists). All code blocks are available to view here: > https://stackoverflow.com/questions/72545671/pattern-matching-on-classt > > I asked a question on stackoverflow about why we cannot match on Class > in the way I expect. Suppose we have: > > sealed interface Animal permits Dog, Cat, Bear {} > record Dog() implements Animal {} > record Cat() implements Animal {} > record Bear() implements Animal {} > > This would work: > > static String makeNoise(Class cls) { > if(cls.equals(Dog.class)) { > return "WOOF"; > } else if(cls.equals(Cat.class)) { > return "MEOW"; > } else if(cls.equals(Bear.class)) { > return "ROAR"; > } else { > throw new IllegalStateException("Unknown state"); > } > } > > But this wouldn't: > > static String makeNoisePatternMatch(Class Animal> cls) { > return switch(cls) { > case Dog.class c -> "WOOF"; > case Cat.class c -> "MEOW"; > case Bear.class c -> "ROAR"; > }; > } > > I got the answer on Stack Overflow that this is not allowed by the spec. My > question to the mailing list is: will the current restriction be lifted in > the future? > > Will we be able to pattern match like the above? And if not - how come it > is restricted (I'm not criticising but rather just asking more out of > curiosity to understand the decision to maintain the restriction)? > > Regards, From nathan.h.walker at gmail.com Sun Jun 12 00:39:22 2022 From: nathan.h.walker at gmail.com (Nathan Walker) Date: Sat, 11 Jun 2022 20:39:22 -0400 Subject: JEP 405 Record Patterns and Backwards Compatible Changes Message-ID: Currently in Java 18 we can make backwards compatible changes to the contents of a record. Given: record Point(int x, int y){ } We can add point z with: record Point(int x, int y, int z) { @Deprecated Point(int x, int y){ this(x, y, 0); } } Or given: record Point(int x, int y, int z){ } We can remove point z with: record Point(int x, int y) { @Deprecated Point(int x, int y, int z){ this(x, y); } @Deprecated public z(){ return 0; } } If they are marked serializable then even the serialized forms maintain backwards compatibility, with the z value in the first example being defaulted to 0 during deserialization, and the z in the second example being ignored during deserialization. But if I understood JEP 405 correctly, a record pattern depends on matching the exact record components. So is there a way in JEP 405 to change a record's components without breaking everywhere that is using the record in a pattern match statement? I would be concerned about using records in any public API if every minor change to a record's structure will require a new major version release under semantic versioning rules. Thanks for your time. From brian.goetz at oracle.com Mon Jun 13 02:38:32 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 12 Jun 2022 22:38:32 -0400 Subject: JEP 405 Record Patterns and Backwards Compatible Changes In-Reply-To: References: Message-ID: First, the JLS does not commit that changing the record descriptor is a compatible change of any kind, binary or source.? But as you say, you can render this "mostly compatible" by adding a constructor with the old record descriptor, which provides a reasonable default for the new components (if they are added at the end; if added in the middle, you're just out of luck.) Binary compatibility: given the current implementation, old match sites will continue to link after adding a record parameter, because both the instanceof test and the accessor invocations based on the old record descriptor still work the same way based on the new descriptor. As to source compatibility, you are correct that you are not yet able to declare the deconstruction pattern with the old record descriptor the same way you can currently with the constructor; eventually you will be able to do so, gaining parity with the constructor. On 6/11/2022 8:39 PM, Nathan Walker wrote: > Currently in Java 18 we can make backwards compatible changes to the > contents of a record. > > Given: > > record Point(int x, int y){ } > > We can add point z with: > > record Point(int x, int y, int z) { > > @Deprecated > Point(int x, int y){ this(x, y, 0); } > } > > Or given: > > record Point(int x, int y, int z){ } > > We can remove point z with: > > record Point(int x, int y) { > > @Deprecated > Point(int x, int y, int z){ this(x, y); } > > @Deprecated > public z(){ return 0; } > } > > If they are marked serializable then even the serialized forms maintain > backwards compatibility, with the z value in the first example being > defaulted to 0 during deserialization, and the z in the second example > being ignored during deserialization. > > But if I understood JEP 405 correctly, a record pattern depends on matching > the exact record components. So is there a way in JEP 405 to change a > record's components without breaking everywhere that is using the record in > a pattern match statement? I would be concerned about using records in any > public API if every minor change to a record's structure will require a new > major version release under semantic versioning rules. > > Thanks for your time. From forax at univ-mlv.fr Mon Jun 13 08:26:24 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 13 Jun 2022 10:26:24 +0200 (CEST) Subject: JEP 405 Record Patterns and Backwards Compatible Changes In-Reply-To: References: Message-ID: <817845311.6408907.1655108784515.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "Nathan Walker" , "amber-dev" > Sent: Monday, June 13, 2022 4:38:32 AM > Subject: Re: JEP 405 Record Patterns and Backwards Compatible Changes > First, the JLS does not commit that changing the record descriptor is a > compatible change of any kind, binary or source.? But as you say, you > can render this "mostly compatible" by adding a constructor with the old > record descriptor, which provides a reasonable default for the new > components (if they are added at the end; if added in the middle, you're > just out of luck.) > > Binary compatibility: given the current implementation, old match sites > will continue to link after adding a record parameter, because both the > instanceof test and the accessor invocations based on the old record > descriptor still work the same way based on the new descriptor. > > As to source compatibility, you are correct that you are not yet able to > declare the deconstruction pattern with the old record descriptor the > same way you can currently with the constructor; eventually you will be > able to do so, gaining parity with the constructor. Brian, I'm not convinced that source compatibility with deconstructors is a goal worth pursuing, as you say, it's only in the case where you add new components at the end, those components must have meaningful default values and the record is not serializable. So this is an awfully a very specific corner case. For me, this is equivalent to the question: when to use a type pattern + accessors and when to use a record pattern ? In term of backward compatibility, a type pattern + accessors enables better backward compatibility than a record pattern, because you can add new components even in the middle, it will still work. So it's not clear to me why someone will want to use a record pattern if backward compatibility is a concern. Record patterns, by construction, matches a shape which is fixed and ordered, you only recognize those components of that length in this particular order. That adds a lot of constraints to a class/record you want to be backward compatible. Perhaps a better road to help with backward compatibility is to have a way to specify at declaration site that using a record pattern on a record/class is disallowed, like you can have a private constructor. And obviously, non-overloadable named pattern methods can be used in case of components that are co-dependents. R?mi PS: being able to juggle with several definition of a data piece with optional values, default values, etc. is a real use case, but i think it is better tackled by serializer/deserializer (in the generic sense e.g. jackson/object mapper/grpc-protobuf, etc) libraries than by the record itself. > > On 6/11/2022 8:39 PM, Nathan Walker wrote: >> Currently in Java 18 we can make backwards compatible changes to the >> contents of a record. >> >> Given: >> >> record Point(int x, int y){ } >> >> We can add point z with: >> >> record Point(int x, int y, int z) { >> >> @Deprecated >> Point(int x, int y){ this(x, y, 0); } >> } >> >> Or given: >> >> record Point(int x, int y, int z){ } >> >> We can remove point z with: >> >> record Point(int x, int y) { >> >> @Deprecated >> Point(int x, int y, int z){ this(x, y); } >> >> @Deprecated >> public z(){ return 0; } >> } >> >> If they are marked serializable then even the serialized forms maintain >> backwards compatibility, with the z value in the first example being >> defaulted to 0 during deserialization, and the z in the second example >> being ignored during deserialization. >> >> But if I understood JEP 405 correctly, a record pattern depends on matching >> the exact record components. So is there a way in JEP 405 to change a >> record's components without breaking everywhere that is using the record in >> a pattern match statement? I would be concerned about using records in any >> public API if every minor change to a record's structure will require a new >> major version release under semantic versioning rules. >> > > Thanks for your time. From brian.goetz at oracle.com Mon Jun 13 14:37:21 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Jun 2022 10:37:21 -0400 Subject: JEP 405 Record Patterns and Backwards Compatible Changes In-Reply-To: <817845311.6408907.1655108784515.JavaMail.zimbra@u-pem.fr> References: <817845311.6408907.1655108784515.JavaMail.zimbra@u-pem.fr> Message-ID: While not guaranteed, what the OP has observed is that adding new components at the end can be made *effectively* compatible by adding a constructor -- and this is something we deliberately considered in the design.? And as the dual of constructors, deconstruction patterns have the same property.? When classes can declare deconstruction patterns, records will be able to do so too, and not "for compatibility", but because deconstruction pattern completes a part of the object model. (As to serialization, the serialization strategy, which is based on default serialization for the fields but runs through the ctor, is tolerant to adding fields, as long as their default values are not rejected by the constructor.) But I think the whole first paragraph of your reply is mostly a distraction.? I think what you really mean is: what should we recommend people do in terms of exposing records in APIs?? This is the key question: > So it's not clear to me why someone will want to use a record pattern if backward compatibility is a concern. And indeed, the JDK -- the library that cares more about backward compatibility than any other on earth -- is likely to be conservative about putting records in public APIs.? But, as observed above, you can go a long way with adding extra ctors and dtors and be mostly compatible -- and I think its reasonable for libraries to do that too, with their eyes open of course. > Brian, > I'm not convinced that source compatibility with deconstructors is a goal worth pursuing, as you say, it's only in the case where you add new components at the end, those components must have meaningful default values and the record is not serializable. So this is an awfully a very specific corner case. > > For me, this is equivalent to the question: when to use a type pattern + accessors and when to use a record pattern ? > > In term of backward compatibility, a type pattern + accessors enables better backward compatibility than a record pattern, because you can add new components even in the middle, it will still work. So it's not clear to me why someone will want to use a record pattern if backward compatibility is a concern. > > Record patterns, by construction, matches a shape which is fixed and ordered, you only recognize those components of that length in this particular order. That adds a lot of constraints to a class/record you want to be backward compatible. > > Perhaps a better road to help with backward compatibility is to have a way to specify at declaration site that using a record pattern on a record/class is disallowed, like you can have a private constructor. But the canonical constructor of a record cannot be private, and neither can the canonical deconstructor (because you can always simulate it with instanceof and accessor calls.) > And obviously, non-overloadable named pattern methods can be used in case of components that are co-dependents. > > R?mi > > PS: being able to juggle with several definition of a data piece with optional values, default values, etc. is a real use case, but i think it is better tackled by serializer/deserializer (in the generic sense e.g. jackson/object mapper/grpc-protobuf, etc) libraries than by the record itself. > >> On 6/11/2022 8:39 PM, Nathan Walker wrote: >>> Currently in Java 18 we can make backwards compatible changes to the >>> contents of a record. >>> >>> Given: >>> >>> record Point(int x, int y){ } >>> >>> We can add point z with: >>> >>> record Point(int x, int y, int z) { >>> >>> @Deprecated >>> Point(int x, int y){ this(x, y, 0); } >>> } >>> >>> Or given: >>> >>> record Point(int x, int y, int z){ } >>> >>> We can remove point z with: >>> >>> record Point(int x, int y) { >>> >>> @Deprecated >>> Point(int x, int y, int z){ this(x, y); } >>> >>> @Deprecated >>> public z(){ return 0; } >>> } >>> >>> If they are marked serializable then even the serialized forms maintain >>> backwards compatibility, with the z value in the first example being >>> defaulted to 0 during deserialization, and the z in the second example >>> being ignored during deserialization. >>> >>> But if I understood JEP 405 correctly, a record pattern depends on matching >>> the exact record components. So is there a way in JEP 405 to change a >>> record's components without breaking everywhere that is using the record in >>> a pattern match statement? I would be concerned about using records in any >>> public API if every minor change to a record's structure will require a new >>> major version release under semantic versioning rules. >>> >>> Thanks for your time. From brian.goetz at oracle.com Mon Jun 13 23:04:13 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Jun 2022 19:04:13 -0400 Subject: JEP 405 Record Patterns and Backwards Compatible Changes In-Reply-To: <1639871569.6973480.1655152086622.JavaMail.zimbra@u-pem.fr> References: <817845311.6408907.1655108784515.JavaMail.zimbra@u-pem.fr> <1639871569.6973480.1655152086622.JavaMail.zimbra@u-pem.fr> Message-ID: <57792da5-741f-5509-f36c-8a264e7550e6@oracle.com> > I agree, but i think this duality is restricted to the canonical > constructor and the (canonical) deconstructor, as we can see with "with". No, there's a story for how overload selection will be done on ctor/dtor pairs from `with`.? Until then, records can prefer the canonical pair; it so happens to turn out that the story will be compatible with this selection.? We'll get there in steps. > Constructors get overloading for free from being methods even if > usually what the user want is just default values. > Deconstructors can not re-use the same overloading algorithm as > methods (cf refining overloading of > reconstruction-records-and-classes.md), so the duality breaks here. They will have a different set of overload rules, which basically come from "reversing the arrows" in the constructor overload restrictions / selection.? So they're different in exactly the way you'd expect a dual to be different. > Also i think that named pattern methods are a better mechanism than > deconstructors overloading because a pattern methods is not > unconditional while a deconstructor is, Remember, this is not the list for language design discussions. But the two are not inconsistent; just as users can choose between constructors or factories, they can choose between deconstruction and named patterns.? Hopefully they will choose consistently; ctors+dtors, or factories+named patterns.? But again, not the place to have the "I think it should work differently" discussion. From izzeldeen03 at gmail.com Tue Jun 14 18:30:01 2022 From: izzeldeen03 at gmail.com (Izz Rainy) Date: Tue, 14 Jun 2022 19:30:01 +0100 Subject: Reconstruction expressions questions Message-ID: First off - sorry if this is the wrong list (still a little confused between -dev and -spec-comments for in-design features). Reconstruction expressions sounds like a very useful feature, just a few "minor" nitpicks/questions: Pattern overload selection seems overly complex and restrictive for a limited use-case. - It's "magic", bringing new names into context as they are requested, so long as they match. This on its own is probably fine, but it does create (IMO unnecessary) complications around assigning to other local variables and using undeclared variables (can usages affect overloading?). - There's no proper way to choose any particular overload without redundant `x = x;` assignments. - It might not work for a private-representation use-case if you only modify variables shared with public representation & the private one is not "maximal", but want to ensure the internal representation stays the same for whatever reason. - Access control-based selection might help, but that would stray even further from regular overload selection ("it's only used when private?"), and at that point, why not just use access control instead of overloads at all? My simplest solution would be to only allow one public byname deconstructor and one private, and use the private one when accessible/when using `with-private` or something. My favourite solution would be to allow naming byname deconstructors, defaulting to the maximal one and allowing `with-` for selecting a particular one, given that `private` is possibly a valid name. (Overload resolution does have the advantage of allowing the use of a faster smaller deconstructor if available, but I don't know how much speedup is possible there and whether it's worth introducing another complex form of overloading for it. Brian mentions that avoiding an accessor call is unlikely to have any effect, though a less-trivial deconstructor might see more of a difference - but patterns aren't supposed to do non-trivial work anyways, especially anything impure or observable.) Related, JS has a similar sort of `with(x)` *statement* that brings all of the components/fields of `x` into scope as "locals". Since JS resolves references at runtime, and these locals take precedence over other parameters or variables, the definition of `x` could be updated to include new variables and change how your unchanged code runs to use random other values of a different type, and is deprecated for that reason. Here, that would require a recompilation and for the types to happen to be similar enough, and we don't have methods-as-fields, but I do think that's still likely enough to be a concern. At the least, it necessitates an "outer scope" syntax or `let in`-ing every value to actually ensure forward compatibility. (Only kind of vaguely somewhat related, in my "ideal Java" you'd be able to name constructors too, and specify a particular one in e.g. `new sized X()` to avoid as much usage of static factories and allow constructors with the same signature. Here, you only need the ability to possibly-name deconstructors though. Perhaps named constructors could help in overload resolution for constructors with default parameter values? lol) Other questions: - Would it make sense to be able to `yield` from a `with` block to skip the rest of the block and finish evaluation? - Very minor, but having an explicit form for cloning from now would be useful to avoid `x with {}`, which looks like a no-op and is confusing if you don't know the underlying goings-on of `with`, from becoming a best-practice "free" clone function. Maybe being able to generate `clone` bodies from deconstructors down the line, maybe a syntax like `x with _` or `x cloned` (bad strawmen) would work, just not a "no-op". - Would it make sense to (at some point) have `with` for arrays? Say, `x with { [0] = 1; }`? Given array patterns, it would complete the circle of "breaking down and putting back together with identical syntax" (yes that's not the proper wording but it's the general idea). - Probably something else that I forgot while writing this email. Thank you for you time and consideration. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue Jun 14 18:51:19 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Jun 2022 14:51:19 -0400 Subject: Reconstruction expressions questions In-Reply-To: References: Message-ID: <0fbfe2b9-9361-5416-55ee-1894fe01291f@oracle.com> > Pattern overload selection seems overly complex and restrictive for a > limited use-case. > ?- It's "magic", bringing new names into context as they are > requested, so long as they match. This on its own is probably fine, > but it does create (IMO unnecessary) complications around assigning to > other local variables and using undeclared variables (can usages > affect overloading?). > ?- There's no proper way to choose any particular overload without > redundant `x = x;` assignments. > ?- It might not work for a private-representation use-case if you only > modify variables shared with public representation & the private one > is not "maximal", but want to ensure the internal representation stays > the same for whatever reason. > ?- Access control-based selection might help, but that would stray > even further from regular overload selection ("it's only used when > private?"), and at that point, why not just use access control instead > of overloads at all? This isn't actually about pattern overload selection -- that's defined largely as the dual of method overload selection.? What you're asking about is how reconstruction expressions would select their patterns.? (This is probably just a terminology blip.) I think you might be placing a little too much authority in the reconstruction writeup, though.? That's a sketch, whose purpose is (a) to explain a possible direction and its underpinnings and (b) provide a strawman argument than the end-to-end issues can be addressed.? We put these out early to get high-level feedback on the direction and concept.? That said, I also think answers to several of the above questions are implicit in the model described (e.g., there's no case where a redundant `x=x` would make a difference in selection, given the requirements for disjoint chains and selecting the maximal ctor/dtor of the (sole) chain that is matched.? The only case where this gets weird is if there are no assignments at all, in which case it might match multiple chains.) I think what you're questioning is, essentially, "is this the optimal tradeoff between simplicity and specificity?"? And that's a fair question -- and one we'll take up when we start to design reconstruction for arbitrary classes.? The one that gets written up first is usually the first credible design, but often it can be simplified further.? The good news is that for records, many of the answers are already chosen for us. > My simplest solution would be to only allow one public byname > deconstructor and one private, and use the private one when > accessible/when using `with-private` or something. We did pass through the "only one" point in the initial design exploration, but this quickly felt unstable.? And having a separate feature to select the private one (and, what about other forms of access control?) is not a simplifying move.? But these can all be more carefully evaluated when we get closer. > ?- Would it make sense to be able to `yield` from a `with` block to > skip the rest of the block and finish evaluation? This feels like mixing two different things.? The block is a transform on the state, not an expression on its own. > ?- Would it make sense to (at some point) have `with` for arrays? Say, > `x with { [0] = 1; }`? Given array patterns, it would complete the > circle of "breaking down and putting back together with identical > syntax" (yes that's not the proper wording but it's the general idea). That would certainly be nice, but it falls afoul of an existing simplifying move which is "the block is just an ordinary block of Java code."? Introducing a restricted form of assignment statement or lvalue-expression is a pretty significant departure. From hunor.szegi at gmail.com Sat Jun 18 22:42:12 2022 From: hunor.szegi at gmail.com (Hunor Szegi) Date: Sat, 18 Jun 2022 23:42:12 +0100 Subject: Totality at switch statements Message-ID: Hi All, I really like the progress of adding pattern matching to Java (and a lot of other features). I can not wait to use it in productive code (non-preview). But I would like to give you feedback about a tiny detail, about the totality of switch statements. Surely, the totality is necessary at switch expressions, but forcing it at a statement is questionable. It can be helpful for the programmers to check the totality in those cases when the intent is that. But it is quite common to create a switch statement that doesn't handle all of the possibilities. Why would it be different using patterns? Why is it beneficial to force totality? This check can be an IDE feature. (Or the programmer can try adding a default clause, and the duplicated totality will be shown as an error. But I know it isn't convenient.) Honestly I feel that the rule, when the totality is forced, is dictated simply by the necessity of backward compatibility. What will happen if a new type (for example double) will be allowed for the selector expression? The backward compatibility wouldn't be an issue, but it would be weird behaving differently with an int compared to a double, so I guess the totality won't be forced. What would happen if the finality requirement was removed, and the equality could be checked for all types? What about the totality check in this imagined future? Of course the best would be to allow the totality check somehow if the intent is that. A warning could be a solution, but that can be annoying. It will force the programmers to suppress it, or to add a default clause (what is the current solution). Adding a default clause could be treated as marking the intent: we don't want totality. But the actual syntax does not represent it clearly. Additionally, there are issues with the "empty" default clause. In the JEP the "default: break;" was recommended, but interestingly it doesn't work with the arrow syntax. ("default -> break;" is a compile time error, only the "default: {break;}" is possible.) We can use both the "default: {}" and "default -> {}", which is fine. But while the "default:" is possible (without body), the "default ->" is an error. I don't know what is the reason behind it. Allowing an empty body with the arrow syntax would make the actual solution a little bit cleaner. I think forcing the totality at statements is partly an intent for uniformity. The best would be if the same rules were applied to all cases, regardless if it is a statement or expression, old or arrow syntax. But backward compatibility can't allow full uniformity, it moves the separation into the middle of a box, instead of a clear distinction between a statement and expression. It creates more cases. It would be possible, forcing the totality only at the arrow syntax. But that would move some of the programmers using the old syntax, which may be less fortunate. It would be possible to allow the programmer to mark the intended totality. Maybe a new keyword would be too much for this purpose. Alternatively I can imagine allowing annotations at a switch statement/expression in the future. For example: @total switch (x) { ... } If this syntax isn't possible, the annotation could be added right before the opening curly bracket. Alternatively a warning suppress annotation could be used specifically for the switch. But this is only a brainstorming. My main point is that I don't think the totality should be forced at switch statements. Or it should cause only a warning. I hope my feedback isn't pointless. I'd be very interested to hear other people's opinions. Thank you in advance, Regards, Hunor -------------- next part -------------- An HTML attachment was scrubbed... URL: From numeralnathan at gmail.com Sun Jun 19 01:11:16 2022 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Sat, 18 Jun 2022 19:11:16 -0600 Subject: Totality at switch statements In-Reply-To: References: Message-ID: I haven't played with switch expressions, but I think of them kind of like this but much more performant... int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6; This statement assigns a value to y no matter what x is since the 6 is the "default" case. The following wouldn't make any sense. What gets assigned to y in the last case? int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? ; Note: I realize that switch statements are based on a table (e.g., enum) or hash table lookup (e.g., String). This provides O(1) case selection; whereas, the above is O(n) where n is the number of == + 1. On Sat, Jun 18, 2022 at 4:42 PM Hunor Szegi wrote: > Hi All, > > I really like the progress of adding pattern matching to Java (and a > lot of other features). I can not wait to use it in productive code > (non-preview). But I would like to give you feedback about a tiny detail, > about the totality of switch statements. > > Surely, the totality is necessary at switch expressions, but forcing it at > a statement is questionable. > > It can be helpful for the programmers to check the totality in those cases > when the intent is that. But it is quite common to create a switch > statement that doesn't handle all of the possibilities. Why would it be > different using patterns? Why is it beneficial to force totality? This > check can be an IDE feature. (Or the programmer can try adding a default > clause, and the duplicated totality will be shown as an error. But I know > it isn't convenient.) > > Honestly I feel that the rule, when the totality is forced, is dictated > simply by the necessity of backward compatibility. What will happen if a > new type (for example double) will be allowed for the selector expression? > The backward compatibility wouldn't be an issue, but it would be weird > behaving differently with an int compared to a double, so I guess the > totality won't be forced. What would happen if the finality requirement was > removed, and the equality could be checked for all types? What about the > totality check in this imagined future? > > Of course the best would be to allow the totality check somehow if the > intent is that. A warning could be a solution, but that can be annoying. It > will force the programmers to suppress it, or to add a default clause (what > is the current solution). Adding a default clause could be treated as > marking the intent: we don't want totality. But the actual syntax does not > represent it clearly. > > Additionally, there are issues with the "empty" default clause. In the JEP > the "default: break;" was recommended, but interestingly it doesn't work > with the arrow syntax. ("default -> break;" is a compile time error, only > the "default: {break;}" is possible.) We can use both the "default: {}" and > "default -> {}", which is fine. But while the "default:" is > possible (without body), the "default ->" is an error. I don't know what is > the reason behind it. Allowing an empty body with the arrow syntax would > make the actual solution a little bit cleaner. > > I think forcing the totality at statements is partly an intent for > uniformity. The best would be if the same rules were applied to all cases, > regardless if it is a statement or expression, old or arrow syntax. But > backward compatibility can't allow full uniformity, it moves the separation > into the middle of a box, instead of a clear distinction between a > statement and expression. It creates more cases. > > It would be possible, forcing the totality only at the arrow syntax. But > that would move some of the programmers using the old syntax, which may be > less fortunate. > > It would be possible to allow the programmer to mark the intended > totality. Maybe a new keyword would be too much for this purpose. > Alternatively I can imagine allowing annotations at a switch > statement/expression in the future. For example: > > @total > switch (x) { > ... > } > > If this syntax isn't possible, the annotation could be added right before > the opening curly bracket. Alternatively a warning suppress annotation > could be used specifically for the switch. > But this is only a brainstorming. My main point is that I don't think the > totality should be forced at switch statements. Or it should cause only a > warning. > > I hope my feedback isn't pointless. I'd be very interested to hear other > people's opinions. > > Thank you in advance, > > Regards, > Hunor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sun Jun 19 13:31:20 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 19 Jun 2022 09:31:20 -0400 Subject: Totality at switch statements In-Reply-To: References: Message-ID: <4f6a7068-daf9-3618-2e83-77bcaf5b346f@oracle.com> > Surely, the totality is necessary at switch?expressions, but forcing > it at a statement is questionable. I understand why you might feel this way; indeed, when we made this decision, I knew that we would get mails like this one.? There were a number of forces that pushed us in this direction; I will try to explain some of them, but I don't expect the explanation to be compelling to all readers. One of the things that makes upgrading `switch` difficult is that developers have an existing mental model of what switch "is" or "is for", and attempted upgrades often challenge these models.? But the goal here is not simply to make switch "better" in a number of ways (better exhaustiveness checking, better null handling, patterns, smoother syntax).? Of course we like these improvements, but the goal is bigger.? But it's easier to be aware of the role switch plays today, than the role we expect it to play tomorrow, so these improvements might feel more like "forced improvements for the sake of some abstract ivory tower purity." > It can be helpful for the programmers to check the?totality in those > cases when the intent is that. But it is quite common to create a > switch statement that doesn't handle all of the possibilities. This raises two questions: ?- Why is it so common? ?- Is it good that it is common? One of the reasons it is common is that the switch statement we had is so weak!? The set of types you can switch over is limited.? The set of things you can put in case labels is limited.? The set of things you can do is limited (until recently, you were forced to do everything with side-effects.)? The switch statement we have in Java was copied almost literally from C, which was designed for writing things like lexers that look at characters and accumulate them conditionally into buffers.? Partiality is common in these weak use cases, but in the use cases we want to support, partiality is more often a bug than a feature.? So saying "it is common" is really saying "this is what we've managed to do with the broken, limited switch statement we have today."? Great that we've been able to do something with it, but we shouldn't limit our imagination to what we've been able to achieve with such a limited tool. To my other question, try this thought experiment: if switch was total from day 1, requiring a `default: ;` case to terminate the switch (which really isn't that burdensome), when you were learning it back then, would you even have thought to complain?? Would you even have *noticed*?? If there was a budget for complaining about switch in that hypothetical world, I would think 99% of it would have been spent on fallthrough, rather than "forced default". > Why would it be different using?patterns? Why is it beneficial to > force totality? Because patterns don't exist in a vacuum.? There's a reason we did records, sealed classes, and patterns together; because they work together.? Records let us easily model aggregates, and sealed types let us easily model exhaustive choices (records + sealed classes = algebraic data types); record patterns make it easy to recover the aggregated state, and exhaustive switches make it easy to recover the original choice.? We expect that the things people are going to switch over with patterns, will have often been modeled with sealed classes. Java has succeeded despite having gotten many of the defaults wrong.? We've all had to learn "make things private unless they need to be public."? "Make fields final unless they need to be mutable." It would have been nice if the language gave us more of a nudge, but we had to learn the hard way.? Switch partiality is indeed another of those wrong defaults; you don't notice it until it is pointed out to you, but then when you think about it for enough time, you realize what a mistake it was. In the current world, partiality is the default, and even if a switch is total, it may not be obvious (unless you explicitly say "default"); flipping this around, a switch with default is a sign that says "hey, I'm partial."? Partiality is an error-prone condition that is worth calling attention to, so flipping this default is valuable -- and we have an opportunity to do so without breaking compatibility. The value of totality checking is under-appreciated, in part because until recently there were so few sources of exhaustiveness information in the language (basically, enums).? But many non-exhaustive switches are an error waiting to happen; the user thinks they have covered all the cases (either in fact, or in practicality).? But something may happen elsewhere that undermines this assumption (e.g., a new enum constant or subtype was added.) With totality, we are made aware of this immediately, rather than having to debug the runtime case where a surprising value showed up. Worse, now the language has switch expressions, which *must* be total.? Having one kind of switch be total and another not is cognitive load that users (and students) have to carry.? (Yes, there are still asymmetries in switch that have this effect; that's not a reason to load up with more.)? But it gets even worse, because refactoring from a switch expression to a switch statement means you lost some safety that you were depending on when you wrote the original code, and may not be aware of this. If you've not programmed with sealed types or equivalent, it is easy to underestimate how powerful this is.? I'd like us to be able to get to a world where we almost never use "default" in switch, unless we are deliberately opting into partiality -- in which case the "default" is a reminder to future maintainers that this is a deliberately partial switch. > This check can be an IDE feature. Yes, that was one of the choices.? And we considered that.? And it is reasonable that you wish we'd made another choice.? But, be aware you are really arguing "make the language less safe and more error-prone, please" -- and ask yourself why you think its a good idea to make the language less uniform and less safe?? I think you'll find that the reason is mostly "someone moved my cheese." (https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F). > Honestly I feel that the rule, when the totality is forced, is > dictated simply by the necessity?of backward compatibility. What will > happen if a new type (for example double) will be allowed for the > selector expression? The backward compatibility?wouldn't be an issue, > but it would be weird behaving differently with an int compared to a > double, so I guess the totality won't be forced. What would happen if > the finality requirement was removed, and the equality could be > checked for all types? What about the totality check in this imagined > future? I don't really understand what you're getting at in this paragraph, but I'll just point out that it really underscores the value of a uniform switch construct.? You're saying "but I don't see how you'll get there from legacy int switches, so therefore its inconsistent" (and implicitly, one unit of inconsistency is as bad as a million.) But you don't seem to be equally bothered by the much more impactful inconsistency we'd have if expression switches were total and statement switches were not. You are correct that there are legacy considerations that will make it harder to get to a fully uniform construct (but, there's still things we can do there.)? But that's not an excuse to not design towards the language we want to have, when we can do so at such minor inconvenience. But the main thing I want you to consider is: right now, the switch we have is very, very limited, and so we've convinced ourselves it is "for" the few things we've been able to do with it.? By making it more powerful (and combining it with complementary features such as pattern matching, and sealing), these few cases -- which right now feel like the whole world of switch -- will eventually recede into being the quirky odd cases. > Additionally, there are?issues with the "empty" default clause. In the > JEP the "default: break;" was recommended, but interestingly it > doesn't work with the arrow syntax. ("default -> break;" is a compile > time error, only the "default: {break;}" is possible.) We can use both > the "default: {}" and "default -> {}", which is fine. But while the > "default:" is possible?(without body), the "default ->" is an error. I > don't know what is the reason behind it. Allowing an empty body with > the arrow syntax would make the actual solution a little bit cleaner. This is a fair observation; this should probably be cleaned up. > It would be possible to allow the programmer to mark the intended > totality. Maybe a new keyword would be too much for this purpose. Yes, we considered this, and came to the conclusion that the problem is the wrong default.? Adding a new keyword for "total switch" is bad in three ways: it is, as you say, "too much"; it doesn't fix the underlying problem; and the cases in which it most needs to be used, people will probably forget to use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sun Jun 19 13:42:25 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 19 Jun 2022 09:42:25 -0400 Subject: Totality at switch statements In-Reply-To: References: Message-ID: > I haven't played with switch expressions, but I think of them kind of > like this but much more performant... > > int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6; I encourage you to broaden how you think of this.? Yes, they might be more performant (though they might not be -- a good compiler can chew this up too), but that is is both a secondary, and a dependent, benefit.? The alternative is: ??? int y = switch (x) { ??????? case 0 -> 0; ??????? case 1 -> 2; ??????? case 2 -> 4; ?? ? ?? default -> 6; ??? } which I'm sure everyone finds more readable. The primary benefit is that you are using a simpler, more constrained concept.? A chain of ternaries or if-else can have arbitrary and unrelated predicates, and offers less opportunity for exhaustiveness checking.? It involves unneeded repetition ("x == ") which is a place for errors to hide in.? The fact that each predicate in the chain above is of the form `x == ` is neither mandated nor checked nor even obvious at first glance; this makes it harder to read and more error-prone; you could easily fumble this for "z == 2" and it would be hard to notice.? Whereras a switch has a distinguished operand; you are saying "this operand should match one of these cases", and readers know it will match *exactly* one of those cases.? That is a more constrained statement, and by using a more specialized tool, you can make the calculation more readable and less error-prone. The performance benefit, if there is one, comes from the fact that you have performed a semantic "strength reduction", which is potentially more optimizable.? But that's a totally dependent benefit, one which flows from having written more clear, specific code in the first place. From numeralnathan at gmail.com Sun Jun 19 18:04:07 2022 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Sun, 19 Jun 2022 12:04:07 -0600 Subject: Totality at switch statements In-Reply-To: References: Message-ID: As always, your answers are well thought out and have good points. I wonder if it would make sense to write up a design page, document the choices and why one choice was picked over another. Then, have your team review it and then the world via JEP. This way future and other language designers can benefit from the information. If some future designer wants to change the language, they can read the document and realize all the constraints and hidden pits. Eclipse will give me a warning if there are missing cases but not missing ternaries. I really like that feature. It means I can add an enum and Eclipse will let me know all the places I need to fix. Sadly, I can ignore these warnings and waste a lot of time debugging the missing cases. I love that Java will require exhaustiveness in switch and provide the feature for more data types. It will do one of two things. I can either put all the cases and know that all situations are handled, OR I can add a default and add error handling for an unexpected situation. It will help me write more robust code without having to write as many unit tests. As you pointed out, I will spend less time debugging and furthermore writing a unit test to reproduce the problem. On Sun, Jun 19, 2022 at 7:42 AM Brian Goetz wrote: > > > I haven't played with switch expressions, but I think of them kind of > > like this but much more performant... > > > > int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6; > > I encourage you to broaden how you think of this. Yes, they might be > more performant (though they might not be -- a good compiler can chew > this up too), but that is is both a secondary, and a dependent, > benefit. The alternative is: > > int y = switch (x) { > case 0 -> 0; > case 1 -> 2; > case 2 -> 4; > default -> 6; > } > > which I'm sure everyone finds more readable. > > The primary benefit is that you are using a simpler, more constrained > concept. A chain of ternaries or if-else can have arbitrary and > unrelated predicates, and offers less opportunity for exhaustiveness > checking. It involves unneeded repetition ("x == ") which is > a place for errors to hide in. The fact that each predicate in the > chain above is of the form `x == ` is neither mandated nor > checked nor even obvious at first glance; this makes it harder to read > and more error-prone; you could easily fumble this for "z == 2" and it > would be hard to notice. Whereras a switch has a distinguished operand; > you are saying "this operand should match one of these cases", and > readers know it will match *exactly* one of those cases. That is a more > constrained statement, and by using a more specialized tool, you can > make the calculation more readable and less error-prone. > > The performance benefit, if there is one, comes from the fact that you > have performed a semantic "strength reduction", which is potentially > more optimizable. But that's a totally dependent benefit, one which > flows from having written more clear, specific code in the first place. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sun Jun 19 18:27:30 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 19 Jun 2022 14:27:30 -0400 Subject: Totality at switch statements In-Reply-To: References: Message-ID: <8b6a776a-6162-0db4-8c7d-e688bc4f3300@oracle.com> > As always, your answers are well thought out and have good points.? I > wonder if it would make sense to write up a design page, document the > choices and why one choice was picked over another.? Then, have your > team review it and then the world via JEP.? This way future and other > language designers can benefit from the information.? If some future > designer wants to change the language, they can read the document and > realize all the constraints and hidden pits. We did something like that for a few of the features (see the FAQ / style guides Stuart Marks put together for Local Variable Type Inference, and for Text Blocks.)? It would be great to have them for all the features, and keep them updated as new questions come up and get answered here.? In a perfect world, we would!? But sometimes there are too many things to do.? We'd welcome contributions on this. > I love that Java will require exhaustiveness in switch and provide the > feature for more data types.? It will do one of two things.? I can > either put all the cases and know that all situations are handled, OR > I can add a default and add error handling for an unexpected > situation.? It will help me write more robust code without having to > write as many unit tests.? As you pointed out, I will spend less time > debugging and furthermore writing a unit test to reproduce the problem. Exactly!? And another benefit is that someone reading the code can tell whether you intended the switch to cover all the cases, or not, just by looking for a default / total case.? (Right now the positioning of `default` is unconstrained, as it always was, but we may require it float to the bottom, to make it easier to find the catch-all case.) A subtle point about exhaustiveness that people don't often realize is that, when switching over a domain with exhaustiveness information (enums or sealed types), it is better *not* to have a default, and instead let the compiler insert a throwing default to catch separate compilation errors.? Because then, if someone adds a new enum constant or subtype later, you find out next compile time, rather than at run time. (Which reminds me of another thing to add to my response to Hunor on the topic: because we add a throwing default to total switches that don't already have a catch-all case, this would be yet another subtle and surprising difference between switch expressions and switch statements.) > > On Sun, Jun 19, 2022 at 7:42 AM Brian Goetz > wrote: > > > > I haven't played with switch expressions, but I think of them > kind of > > like this but much more performant... > > > > int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6; > > I encourage you to broaden how you think of this.? Yes, they might be > more performant (though they might not be -- a good compiler can chew > this up too), but that is is both a secondary, and a dependent, > benefit.? The alternative is: > > ???? int y = switch (x) { > ???????? case 0 -> 0; > ???????? case 1 -> 2; > ???????? case 2 -> 4; > ??? ? ?? default -> 6; > ???? } > > which I'm sure everyone finds more readable. > > The primary benefit is that you are using a simpler, more constrained > concept.? A chain of ternaries or if-else can have arbitrary and > unrelated predicates, and offers less opportunity for exhaustiveness > checking.? It involves unneeded repetition ("x == ") > which is > a place for errors to hide in.? The fact that each predicate in the > chain above is of the form `x == ` is neither mandated nor > checked nor even obvious at first glance; this makes it harder to > read > and more error-prone; you could easily fumble this for "z == 2" > and it > would be hard to notice.? Whereras a switch has a distinguished > operand; > you are saying "this operand should match one of these cases", and > readers know it will match *exactly* one of those cases.? That is > a more > constrained statement, and by using a more specialized tool, you can > make the calculation more readable and less error-prone. > > The performance benefit, if there is one, comes from the fact that > you > have performed a semantic "strength reduction", which is potentially > more optimizable.? But that's a totally dependent benefit, one which > flows from having written more clear, specific code in the first > place. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From numeralnathan at gmail.com Sun Jun 19 19:34:43 2022 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Sun, 19 Jun 2022 13:34:43 -0600 Subject: Totality at switch statements In-Reply-To: <8b6a776a-6162-0db4-8c7d-e688bc4f3300@oracle.com> References: <8b6a776a-6162-0db4-8c7d-e688bc4f3300@oracle.com> Message-ID: > Right now the positioning of `default` is unconstrained, as it always was, but we may require it float to the bottom, to make it easier to find the catch-all case. Please don't require default to be at the bottom. There are some situations where the default case can recover from unhandled input with a satisfactory response. See the code below. The default case logs the problem and falls through to return false. If the "NO" case were more complex and if default were required at the bottom, then the requirement would cause duplicate code. In some situations, the duplicate code could be extracted to a separate method. In other situations, there are too many local variables being changed by the case in a loop to make it possible. public static boolean isYes(String value) { switch (value) { case "YES": return true; default: LOGGER.error("Unhandled value: {}", value); // break; case "NO": return false; } } On Sun, Jun 19, 2022 at 12:27 PM Brian Goetz wrote: > > As always, your answers are well thought out and have good points. I > wonder if it would make sense to write up a design page, document the > choices and why one choice was picked over another. Then, have your team > review it and then the world via JEP. This way future and other language > designers can benefit from the information. If some future designer wants > to change the language, they can read the document and realize all the > constraints and hidden pits. > > > We did something like that for a few of the features (see the FAQ / style > guides Stuart Marks put together for Local Variable Type Inference, and for > Text Blocks.) It would be great to have them for all the features, and > keep them updated as new questions come up and get answered here. In a > perfect world, we would! But sometimes there are too many things to do. > We'd welcome contributions on this. > > I love that Java will require exhaustiveness in switch and provide the > feature for more data types. It will do one of two things. I can either > put all the cases and know that all situations are handled, OR I can add a > default and add error handling for an unexpected situation. It will help > me write more robust code without having to write as many unit tests. As > you pointed out, I will spend less time debugging and furthermore writing a > unit test to reproduce the problem. > > > Exactly! And another benefit is that someone reading the code can tell > whether you intended the switch to cover all the cases, or not, just by > looking for a default / total case. (Right now the positioning of > `default` is unconstrained, as it always was, but we may require it float > to the bottom, to make it easier to find the catch-all case.) > > A subtle point about exhaustiveness that people don't often realize is > that, when switching over a domain with exhaustiveness information (enums > or sealed types), it is better *not* to have a default, and instead let the > compiler insert a throwing default to catch separate compilation errors. > Because then, if someone adds a new enum constant or subtype later, you > find out next compile time, rather than at run time. > > (Which reminds me of another thing to add to my response to Hunor on the > topic: because we add a throwing default to total switches that don't > already have a catch-all case, this would be yet another subtle and > surprising difference between switch expressions and switch statements.) > > > On Sun, Jun 19, 2022 at 7:42 AM Brian Goetz > wrote: > >> >> > I haven't played with switch expressions, but I think of them kind of >> > like this but much more performant... >> > >> > int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6; >> >> I encourage you to broaden how you think of this. Yes, they might be >> more performant (though they might not be -- a good compiler can chew >> this up too), but that is is both a secondary, and a dependent, >> benefit. The alternative is: >> >> int y = switch (x) { >> case 0 -> 0; >> case 1 -> 2; >> case 2 -> 4; >> default -> 6; >> } >> >> which I'm sure everyone finds more readable. >> >> The primary benefit is that you are using a simpler, more constrained >> concept. A chain of ternaries or if-else can have arbitrary and >> unrelated predicates, and offers less opportunity for exhaustiveness >> checking. It involves unneeded repetition ("x == ") which is >> a place for errors to hide in. The fact that each predicate in the >> chain above is of the form `x == ` is neither mandated nor >> checked nor even obvious at first glance; this makes it harder to read >> and more error-prone; you could easily fumble this for "z == 2" and it >> would be hard to notice. Whereras a switch has a distinguished operand; >> you are saying "this operand should match one of these cases", and >> readers know it will match *exactly* one of those cases. That is a more >> constrained statement, and by using a more specialized tool, you can >> make the calculation more readable and less error-prone. >> >> The performance benefit, if there is one, comes from the fact that you >> have performed a semantic "strength reduction", which is potentially >> more optimizable. But that's a totally dependent benefit, one which >> flows from having written more clear, specific code in the first place. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sun Jun 19 20:02:22 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 19 Jun 2022 16:02:22 -0400 Subject: Totality at switch statements In-Reply-To: References: <8b6a776a-6162-0db4-8c7d-e688bc4f3300@oracle.com> Message-ID: <93dc4982-bea5-189f-f003-3d6aefcd3ae1@oracle.com> > Please don't require default to be at the bottom.? There are some > situations where the default case can recover from unhandled input > with a satisfactory response. See the code below. Yes, but such cases happen almost exclusively in conjunction with fallthrough, and case patterns can't fall through (because then the bindings might not be DA.)?? Right now, we make a distinction between "legacy switch" (old types, constant case labels, no patterns) and other switches (expressions, or statements with patterns.)? We have to carve out the code you cite below for compatibility reasons, but we don't have to let it infect the new world. The things we know from "old switch" are not necessarily representative of the new world.... > The default case logs the problem and falls through to return false.? > If the "NO" case were more complex and if default were required at the > bottom, then the requirement would cause duplicate code.? In some > situations, the duplicate code could be extracted to a separate > method.? In other situations, there are too many local variables being > changed by the case in a loop to make it possible. > > public static boolean isYes(String value) > { > ?? switch (value) > ?? { > ????? case "YES": > ???????? return true; > > ????? default: > ???????? LOGGER.error("Unhandled value: {}", value); > ???????? // break; > > ????? case "NO": > ???????? return false; > ?? } > } > > On Sun, Jun 19, 2022 at 12:27 PM Brian Goetz > wrote: > > >> As always, your answers are well thought out and have good >> points.? I wonder if it would make sense to write up a design >> page, document the choices and why one choice was picked over >> another.? Then, have your team review it and then the world via >> JEP.? This way future and other language designers can benefit >> from the information.? If some future designer wants to change >> the language, they can read the document and realize all the >> constraints and hidden pits. > > We did something like that for a few of the features (see the FAQ > / style guides Stuart Marks put together for Local Variable Type > Inference, and for Text Blocks.)? It would be great to have them > for all the features, and keep them updated as new questions come > up and get answered here.? In a perfect world, we would!? But > sometimes there are too many things to do.? We'd welcome > contributions on this. > >> I love that Java will require exhaustiveness in switch and >> provide the feature for more data types.? It will do one of two >> things.? I can either put all the cases and know that all >> situations are handled, OR I can add a default and add error >> handling for an unexpected situation.? It will help me write more >> robust code without having to write as many unit tests.? As you >> pointed out, I will spend less time debugging and furthermore >> writing a unit test to reproduce the problem. > > Exactly!? And another benefit is that someone reading the code can > tell whether you intended the switch to cover all the cases, or > not, just by looking for a default / total case.? (Right now the > positioning of `default` is unconstrained, as it always was, but > we may require it float to the bottom, to make it easier to find > the catch-all case.) > > A subtle point about exhaustiveness that people don't often > realize is that, when switching over a domain with exhaustiveness > information (enums or sealed types), it is better *not* to have a > default, and instead let the compiler insert a throwing default to > catch separate compilation errors.? Because then, if someone adds > a new enum constant or subtype later, you find out next compile > time, rather than at run time. > > (Which reminds me of another thing to add to my response to Hunor > on the topic: because we add a throwing default to total switches > that don't already have a catch-all case, this would be yet > another subtle and surprising difference between switch > expressions and switch statements.) > >> >> On Sun, Jun 19, 2022 at 7:42 AM Brian Goetz >> wrote: >> >> >> > I haven't played with switch expressions, but I think of >> them kind of >> > like this but much more performant... >> > >> > int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6; >> >> I encourage you to broaden how you think of this. Yes, they >> might be >> more performant (though they might not be -- a good compiler >> can chew >> this up too), but that is is both a secondary, and a dependent, >> benefit.? The alternative is: >> >> ???? int y = switch (x) { >> ???????? case 0 -> 0; >> ???????? case 1 -> 2; >> ???????? case 2 -> 4; >> ??? ? ?? default -> 6; >> ???? } >> >> which I'm sure everyone finds more readable. >> >> The primary benefit is that you are using a simpler, more >> constrained >> concept.? A chain of ternaries or if-else can have arbitrary and >> unrelated predicates, and offers less opportunity for >> exhaustiveness >> checking.? It involves unneeded repetition ("x == >> ") which is >> a place for errors to hide in.? The fact that each predicate >> in the >> chain above is of the form `x == ` is neither >> mandated nor >> checked nor even obvious at first glance; this makes it >> harder to read >> and more error-prone; you could easily fumble this for "z == >> 2" and it >> would be hard to notice.? Whereras a switch has a >> distinguished operand; >> you are saying "this operand should match one of these >> cases", and >> readers know it will match *exactly* one of those cases.? >> That is a more >> constrained statement, and by using a more specialized tool, >> you can >> make the calculation more readable and less error-prone. >> >> The performance benefit, if there is one, comes from the fact >> that you >> have performed a semantic "strength reduction", which is >> potentially >> more optimizable.? But that's a totally dependent benefit, >> one which >> flows from having written more clear, specific code in the >> first place. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From numeralnathan at gmail.com Sun Jun 19 20:05:09 2022 From: numeralnathan at gmail.com (Nathan Reynolds) Date: Sun, 19 Jun 2022 14:05:09 -0600 Subject: Totality at switch statements In-Reply-To: <93dc4982-bea5-189f-f003-3d6aefcd3ae1@oracle.com> References: <8b6a776a-6162-0db4-8c7d-e688bc4f3300@oracle.com> <93dc4982-bea5-189f-f003-3d6aefcd3ae1@oracle.com> Message-ID: Hmm... it seems you have some deep insights into the new switch that I have yet to learn. This is understandable since I haven't played with the new switch yet. I hope to move to Java 17 in a few months and then stay on top of every Java release once CI/CD is in better shape. On Sun, Jun 19, 2022 at 2:02 PM Brian Goetz wrote: > > Please don't require default to be at the bottom. There are some > situations where the default case can recover from unhandled input with a > satisfactory response. See the code below. > > > Yes, but such cases happen almost exclusively in conjunction with > fallthrough, and case patterns can't fall through (because then the > bindings might not be DA.) Right now, we make a distinction between > "legacy switch" (old types, constant case labels, no patterns) and other > switches (expressions, or statements with patterns.) We have to carve out > the code you cite below for compatibility reasons, but we don't have to let > it infect the new world. > > The things we know from "old switch" are not necessarily representative of > the new world.... > > The default case logs the problem and falls through to return false. If > the "NO" case were more complex and if default were required at the bottom, > then the requirement would cause duplicate code. In some situations, the > duplicate code could be extracted to a separate method. In other > situations, there are too many local variables being changed by the case in > a loop to make it possible. > > public static boolean isYes(String value) > { > switch (value) > { > case "YES": > return true; > > default: > LOGGER.error("Unhandled value: {}", value); > // break; > > case "NO": > return false; > } > } > > On Sun, Jun 19, 2022 at 12:27 PM Brian Goetz > wrote: > >> >> As always, your answers are well thought out and have good points. I >> wonder if it would make sense to write up a design page, document the >> choices and why one choice was picked over another. Then, have your team >> review it and then the world via JEP. This way future and other language >> designers can benefit from the information. If some future designer wants >> to change the language, they can read the document and realize all the >> constraints and hidden pits. >> >> >> We did something like that for a few of the features (see the FAQ / style >> guides Stuart Marks put together for Local Variable Type Inference, and for >> Text Blocks.) It would be great to have them for all the features, and >> keep them updated as new questions come up and get answered here. In a >> perfect world, we would! But sometimes there are too many things to do. >> We'd welcome contributions on this. >> >> I love that Java will require exhaustiveness in switch and provide the >> feature for more data types. It will do one of two things. I can either >> put all the cases and know that all situations are handled, OR I can add a >> default and add error handling for an unexpected situation. It will help >> me write more robust code without having to write as many unit tests. As >> you pointed out, I will spend less time debugging and furthermore writing a >> unit test to reproduce the problem. >> >> >> Exactly! And another benefit is that someone reading the code can tell >> whether you intended the switch to cover all the cases, or not, just by >> looking for a default / total case. (Right now the positioning of >> `default` is unconstrained, as it always was, but we may require it float >> to the bottom, to make it easier to find the catch-all case.) >> >> A subtle point about exhaustiveness that people don't often realize is >> that, when switching over a domain with exhaustiveness information (enums >> or sealed types), it is better *not* to have a default, and instead let the >> compiler insert a throwing default to catch separate compilation errors. >> Because then, if someone adds a new enum constant or subtype later, you >> find out next compile time, rather than at run time. >> >> (Which reminds me of another thing to add to my response to Hunor on the >> topic: because we add a throwing default to total switches that don't >> already have a catch-all case, this would be yet another subtle and >> surprising difference between switch expressions and switch statements.) >> >> >> On Sun, Jun 19, 2022 at 7:42 AM Brian Goetz >> wrote: >> >>> >>> > I haven't played with switch expressions, but I think of them kind of >>> > like this but much more performant... >>> > >>> > int y = x == 0 ? 0 : x == 1 ? 2 : x == 2 ? 4 : x == 3 ? 6; >>> >>> I encourage you to broaden how you think of this. Yes, they might be >>> more performant (though they might not be -- a good compiler can chew >>> this up too), but that is is both a secondary, and a dependent, >>> benefit. The alternative is: >>> >>> int y = switch (x) { >>> case 0 -> 0; >>> case 1 -> 2; >>> case 2 -> 4; >>> default -> 6; >>> } >>> >>> which I'm sure everyone finds more readable. >>> >>> The primary benefit is that you are using a simpler, more constrained >>> concept. A chain of ternaries or if-else can have arbitrary and >>> unrelated predicates, and offers less opportunity for exhaustiveness >>> checking. It involves unneeded repetition ("x == ") which is >>> a place for errors to hide in. The fact that each predicate in the >>> chain above is of the form `x == ` is neither mandated nor >>> checked nor even obvious at first glance; this makes it harder to read >>> and more error-prone; you could easily fumble this for "z == 2" and it >>> would be hard to notice. Whereras a switch has a distinguished operand; >>> you are saying "this operand should match one of these cases", and >>> readers know it will match *exactly* one of those cases. That is a more >>> constrained statement, and by using a more specialized tool, you can >>> make the calculation more readable and less error-prone. >>> >>> The performance benefit, if there is one, comes from the fact that you >>> have performed a semantic "strength reduction", which is potentially >>> more optimizable. But that's a totally dependent benefit, one which >>> flows from having written more clear, specific code in the first place. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hunor.szegi at gmail.com Mon Jun 20 09:55:47 2022 From: hunor.szegi at gmail.com (Hunor Szegi) Date: Mon, 20 Jun 2022 10:55:47 +0100 Subject: Totality at switch statements In-Reply-To: <4f6a7068-daf9-3618-2e83-77bcaf5b346f@oracle.com> References: <4f6a7068-daf9-3618-2e83-77bcaf5b346f@oracle.com> Message-ID: Thank you for your detailed answer. I agree that the developers will have to change their way of thinking using the new Java features. I am primarily a Java developer, but I use Scala as well. I remember how challenging it was to use it "properly". There was no strict force, at least not always, but we adapted to the new programming paradigm. (For example we always use immutable variables, while the language allows the mutability as well.) Of course we use pattern matching and sealed classes as well, so I fully get that the Java switch enhancement isn't only about the switch. It will have a much bigger effect, but possibly not everything should be forced by the language, the community and the usefulness can have a similar effect. Surely with pattern matching the intended totality will be much more frequent compared to the use cases with the old switch. And I agree, the totality check is useful. I have only reservation against forcing to make the switch statement total. For my taste this is a good practice, but not a compulsory requirement. Looking at your example, when an additional sealed subclass will be added. Yes, it would be very useful to warn the programmers. But imagine a situation when the totality isn't intended, so the programmer wants a side effect only in a few cases. She will be forced to add an empty default clause. And later, when a new sealed subclass will be added, there won't be any alert, as the switch is already total, forever. Surely, it helped a little bit to increase the safety initially (the programmer was forced to think about the missing cases), but with a lot of empty default clauses this safety will be partial. You are right, a partial benefit could be better than nothing. But a false belief of safety can be dangerous as well. If you want to minimize the usages of the empty default clauses, a strict force creating those looks counterproductive. Raising a warning is a lesser force. Checking the totality only when the programmer asked it (with a @total annotation for example) seems the optimal solution. (Or the other way round, marking it with a @partial annotation.) I like safety as a requirement, like static typing against dynamic, maybe I'm just too liberal here. :-) I agree, the cognitive load on the new learners must also be taken into account. But again, I think that it is more difficult to understand why the enums are treated differently to sealed classes. (Historical, backward compatibility reasons.) While that is very easy to understand why totality is necessary at switch expressions, and why optional at switch statements. It is logical. You are right, with my preferred way, theoretically it is possible to lose some safety by refactoring a switch expression to a statement. But the original expression was forced to be total, possibly had a default clause, so it isn't something that can be forgotten. And the original returned a value, the statement will contain only the side effects. If there was no side effect in some cases, why should the developer make a total statement? Is it really a loss in safety? BTW, Scala allows switch expressions without totality, only a warning is raised. This seems a safety risk to me, no idea why it was implemented this way. >>* Additionally, there are issues with the "empty" default clause **>> ...* > This is a fair observation; this should probably be cleaned up. Thank you, I hope it will be fixed by a non-preview release. (Hopefully by the next LTS release.) If I have to use an empty default, my preferred way would be the "default ->" syntax, which isn't possible now. I have read your messages to Nathan as well. I agree with you, the default clause would be better floated to the bottom with a fixed manner. In spite of that fall though example, which is a possible code, but hard to read. Placing an empty default somewhere in the middle shows even less clearly we don't want totality. But even without the totality requirements, or with a body, it seems breaking the logic, the more specific case should be placed before a more universal one at pattern matching. Regarding the automatically added throwing default if there was no default case. Yes, this would be an additional difference between the statement and expression, if the statement could lack totality. I agree that it would be good if the programmer could show her intent about the totality. And yes, adding an empty default clause shows that intent, the totality isn't necessary. You are right about it. I'm just worried that an empty clause isn't as explicit as something else could be. Finally, I have an important point against me. :-) Forcing the totality can be removed later without backward compatibility issues, while it isn't possible to make the rules stricter later. I can imagine you are right, and in the future, with more experience using the new features I will be glad this decision was made. So it's only an attempt to raise my thoughts before it will be too late for a change. I am glad you shared your motivations. Thank you very much, Regards, Hunor On Sun, 19 Jun 2022 at 14:31, Brian Goetz wrote: > > Surely, the totality is necessary at switch expressions, but forcing it at > a statement is questionable. > > > I understand why you might feel this way; indeed, when we made this > decision, I knew that we would get mails like this one. There were a > number of forces that pushed us in this direction; I will try to explain > some of them, but I don't expect the explanation to be compelling to all > readers. > > One of the things that makes upgrading `switch` difficult is that > developers have an existing mental model of what switch "is" or "is for", > and attempted upgrades often challenge these models. But the goal here is > not simply to make switch "better" in a number of ways (better > exhaustiveness checking, better null handling, patterns, smoother syntax). > Of course we like these improvements, but the goal is bigger. But it's > easier to be aware of the role switch plays today, than the role we expect > it to play tomorrow, so these improvements might feel more like "forced > improvements for the sake of some abstract ivory tower purity." > > It can be helpful for the programmers to check the totality in those cases > when the intent is that. But it is quite common to create a switch > statement that doesn't handle all of the possibilities. > > > This raises two questions: > > - Why is it so common? > - Is it good that it is common? > > One of the reasons it is common is that the switch statement we had is so > weak! The set of types you can switch over is limited. The set of things > you can put in case labels is limited. The set of things you can do is > limited (until recently, you were forced to do everything with > side-effects.) The switch statement we have in Java was copied almost > literally from C, which was designed for writing things like lexers that > look at characters and accumulate them conditionally into buffers. > Partiality is common in these weak use cases, but in the use cases we want > to support, partiality is more often a bug than a feature. So saying "it > is common" is really saying "this is what we've managed to do with the > broken, limited switch statement we have today." Great that we've been > able to do something with it, but we shouldn't limit our imagination to > what we've been able to achieve with such a limited tool. > > To my other question, try this thought experiment: if switch was total > from day 1, requiring a `default: ;` case to terminate the switch (which > really isn't that burdensome), when you were learning it back then, would > you even have thought to complain? Would you even have *noticed*? If > there was a budget for complaining about switch in that hypothetical world, > I would think 99% of it would have been spent on fallthrough, rather than > "forced default". > > Why would it be different using patterns? Why is it beneficial to force > totality? > > > Because patterns don't exist in a vacuum. There's a reason we did > records, sealed classes, and patterns together; because they work > together. Records let us easily model aggregates, and sealed types let us > easily model exhaustive choices (records + sealed classes = algebraic data > types); record patterns make it easy to recover the aggregated state, and > exhaustive switches make it easy to recover the original choice. We expect > that the things people are going to switch over with patterns, will have > often been modeled with sealed classes. > > Java has succeeded despite having gotten many of the defaults wrong. > We've all had to learn "make things private unless they need to be > public." "Make fields final unless they need to be mutable." It would > have been nice if the language gave us more of a nudge, but we had to learn > the hard way. Switch partiality is indeed another of those wrong defaults; > you don't notice it until it is pointed out to you, but then when you think > about it for enough time, you realize what a mistake it was. > > In the current world, partiality is the default, and even if a switch is > total, it may not be obvious (unless you explicitly say "default"); > flipping this around, a switch with default is a sign that says "hey, I'm > partial." Partiality is an error-prone condition that is worth calling > attention to, so flipping this default is valuable -- and we have an > opportunity to do so without breaking compatibility. > > The value of totality checking is under-appreciated, in part because until > recently there were so few sources of exhaustiveness information in the > language (basically, enums). But many non-exhaustive switches are an error > waiting to happen; the user thinks they have covered all the cases (either > in fact, or in practicality). But something may happen elsewhere that > undermines this assumption (e.g., a new enum constant or subtype was > added.) With totality, we are made aware of this immediately, rather than > having to debug the runtime case where a surprising value showed up. > > Worse, now the language has switch expressions, which *must* be total. > Having one kind of switch be total and another not is cognitive load that > users (and students) have to carry. (Yes, there are still asymmetries in > switch that have this effect; that's not a reason to load up with more.) > But it gets even worse, because refactoring from a switch expression to a > switch statement means you lost some safety that you were depending on when > you wrote the original code, and may not be aware of this. > > If you've not programmed with sealed types or equivalent, it is easy to > underestimate how powerful this is. I'd like us to be able to get to a > world where we almost never use "default" in switch, unless we are > deliberately opting into partiality -- in which case the "default" is a > reminder to future maintainers that this is a deliberately partial switch. > > This check can be an IDE feature. > > > Yes, that was one of the choices. And we considered that. And it is > reasonable that you wish we'd made another choice. But, be aware you are > really arguing "make the language less safe and more error-prone, please" > -- and ask yourself why you think its a good idea to make the language less > uniform and less safe? I think you'll find that the reason is mostly > "someone moved my cheese." ( > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Who_Moved_My_Cheese*3F__;JQ!!ACWV5N9M2RV99hQ!OGvj_ez3M-Rb0G93AvynF_Hcdr-5f8cE-sTr7OxEXJEnGxKl-jHXYwLubpyZnfpkvDgjAf8ZARG71rKaN0DcpX0$ ). > > Honestly I feel that the rule, when the totality is forced, is dictated > simply by the necessity of backward compatibility. What will happen if a > new type (for example double) will be allowed for the selector expression? > The backward compatibility wouldn't be an issue, but it would be weird > behaving differently with an int compared to a double, so I guess the > totality won't be forced. What would happen if the finality requirement was > removed, and the equality could be checked for all types? What about the > totality check in this imagined future? > > > I don't really understand what you're getting at in this paragraph, but > I'll just point out that it really underscores the value of a uniform > switch construct. You're saying "but I don't see how you'll get there from > legacy int switches, so therefore its inconsistent" (and implicitly, one > unit of inconsistency is as bad as a million.) But you don't seem to be > equally bothered by the much more impactful inconsistency we'd have if > expression switches were total and statement switches were not. > > You are correct that there are legacy considerations that will make it > harder to get to a fully uniform construct (but, there's still things we > can do there.) But that's not an excuse to not design towards the language > we want to have, when we can do so at such minor inconvenience. > > But the main thing I want you to consider is: right now, the switch we > have is very, very limited, and so we've convinced ourselves it is "for" > the few things we've been able to do with it. By making it more powerful > (and combining it with complementary features such as pattern matching, and > sealing), these few cases -- which right now feel like the whole world of > switch -- will eventually recede into being the quirky odd cases. > > Additionally, there are issues with the "empty" default clause. In the JEP > the "default: break;" was recommended, but interestingly it doesn't work > with the arrow syntax. ("default -> break;" is a compile time error, only > the "default: {break;}" is possible.) We can use both the "default: {}" and > "default -> {}", which is fine. But while the "default:" is > possible (without body), the "default ->" is an error. I don't know what is > the reason behind it. Allowing an empty body with the arrow syntax would > make the actual solution a little bit cleaner. > > > This is a fair observation; this should probably be cleaned up. > > It would be possible to allow the programmer to mark the intended > totality. Maybe a new keyword would be too much for this purpose. > > > Yes, we considered this, and came to the conclusion that the problem is > the wrong default. Adding a new keyword for "total switch" is bad in three > ways: it is, as you say, "too much"; it doesn't fix the underlying problem; > and the cases in which it most needs to be used, people will probably > forget to use it. > > On Sun, 19 Jun 2022 at 14:31, Brian Goetz wrote: > > Surely, the totality is necessary at switch expressions, but forcing it at > a statement is questionable. > > > I understand why you might feel this way; indeed, when we made this > decision, I knew that we would get mails like this one. There were a > number of forces that pushed us in this direction; I will try to explain > some of them, but I don't expect the explanation to be compelling to all > readers. > > One of the things that makes upgrading `switch` difficult is that > developers have an existing mental model of what switch "is" or "is for", > and attempted upgrades often challenge these models. But the goal here is > not simply to make switch "better" in a number of ways (better > exhaustiveness checking, better null handling, patterns, smoother syntax). > Of course we like these improvements, but the goal is bigger. But it's > easier to be aware of the role switch plays today, than the role we expect > it to play tomorrow, so these improvements might feel more like "forced > improvements for the sake of some abstract ivory tower purity." > > It can be helpful for the programmers to check the totality in those cases > when the intent is that. But it is quite common to create a switch > statement that doesn't handle all of the possibilities. > > > This raises two questions: > > - Why is it so common? > - Is it good that it is common? > > One of the reasons it is common is that the switch statement we had is so > weak! The set of types you can switch over is limited. The set of things > you can put in case labels is limited. The set of things you can do is > limited (until recently, you were forced to do everything with > side-effects.) The switch statement we have in Java was copied almost > literally from C, which was designed for writing things like lexers that > look at characters and accumulate them conditionally into buffers. > Partiality is common in these weak use cases, but in the use cases we want > to support, partiality is more often a bug than a feature. So saying "it > is common" is really saying "this is what we've managed to do with the > broken, limited switch statement we have today." Great that we've been > able to do something with it, but we shouldn't limit our imagination to > what we've been able to achieve with such a limited tool. > > To my other question, try this thought experiment: if switch was total > from day 1, requiring a `default: ;` case to terminate the switch (which > really isn't that burdensome), when you were learning it back then, would > you even have thought to complain? Would you even have *noticed*? If > there was a budget for complaining about switch in that hypothetical world, > I would think 99% of it would have been spent on fallthrough, rather than > "forced default". > > Why would it be different using patterns? Why is it beneficial to force > totality? > > > Because patterns don't exist in a vacuum. There's a reason we did > records, sealed classes, and patterns together; because they work > together. Records let us easily model aggregates, and sealed types let us > easily model exhaustive choices (records + sealed classes = algebraic data > types); record patterns make it easy to recover the aggregated state, and > exhaustive switches make it easy to recover the original choice. We expect > that the things people are going to switch over with patterns, will have > often been modeled with sealed classes. > > Java has succeeded despite having gotten many of the defaults wrong. > We've all had to learn "make things private unless they need to be > public." "Make fields final unless they need to be mutable." It would > have been nice if the language gave us more of a nudge, but we had to learn > the hard way. Switch partiality is indeed another of those wrong defaults; > you don't notice it until it is pointed out to you, but then when you think > about it for enough time, you realize what a mistake it was. > > In the current world, partiality is the default, and even if a switch is > total, it may not be obvious (unless you explicitly say "default"); > flipping this around, a switch with default is a sign that says "hey, I'm > partial." Partiality is an error-prone condition that is worth calling > attention to, so flipping this default is valuable -- and we have an > opportunity to do so without breaking compatibility. > > The value of totality checking is under-appreciated, in part because until > recently there were so few sources of exhaustiveness information in the > language (basically, enums). But many non-exhaustive switches are an error > waiting to happen; the user thinks they have covered all the cases (either > in fact, or in practicality). But something may happen elsewhere that > undermines this assumption (e.g., a new enum constant or subtype was > added.) With totality, we are made aware of this immediately, rather than > having to debug the runtime case where a surprising value showed up. > > Worse, now the language has switch expressions, which *must* be total. > Having one kind of switch be total and another not is cognitive load that > users (and students) have to carry. (Yes, there are still asymmetries in > switch that have this effect; that's not a reason to load up with more.) > But it gets even worse, because refactoring from a switch expression to a > switch statement means you lost some safety that you were depending on when > you wrote the original code, and may not be aware of this. > > If you've not programmed with sealed types or equivalent, it is easy to > underestimate how powerful this is. I'd like us to be able to get to a > world where we almost never use "default" in switch, unless we are > deliberately opting into partiality -- in which case the "default" is a > reminder to future maintainers that this is a deliberately partial switch. > > This check can be an IDE feature. > > > Yes, that was one of the choices. And we considered that. And it is > reasonable that you wish we'd made another choice. But, be aware you are > really arguing "make the language less safe and more error-prone, please" > -- and ask yourself why you think its a good idea to make the language less > uniform and less safe? I think you'll find that the reason is mostly > "someone moved my cheese." ( > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Who_Moved_My_Cheese*3F__;JQ!!ACWV5N9M2RV99hQ!OGvj_ez3M-Rb0G93AvynF_Hcdr-5f8cE-sTr7OxEXJEnGxKl-jHXYwLubpyZnfpkvDgjAf8ZARG71rKaN0DcpX0$ ). > > Honestly I feel that the rule, when the totality is forced, is dictated > simply by the necessity of backward compatibility. What will happen if a > new type (for example double) will be allowed for the selector expression? > The backward compatibility wouldn't be an issue, but it would be weird > behaving differently with an int compared to a double, so I guess the > totality won't be forced. What would happen if the finality requirement was > removed, and the equality could be checked for all types? What about the > totality check in this imagined future? > > > I don't really understand what you're getting at in this paragraph, but > I'll just point out that it really underscores the value of a uniform > switch construct. You're saying "but I don't see how you'll get there from > legacy int switches, so therefore its inconsistent" (and implicitly, one > unit of inconsistency is as bad as a million.) But you don't seem to be > equally bothered by the much more impactful inconsistency we'd have if > expression switches were total and statement switches were not. > > You are correct that there are legacy considerations that will make it > harder to get to a fully uniform construct (but, there's still things we > can do there.) But that's not an excuse to not design towards the language > we want to have, when we can do so at such minor inconvenience. > > But the main thing I want you to consider is: right now, the switch we > have is very, very limited, and so we've convinced ourselves it is "for" > the few things we've been able to do with it. By making it more powerful > (and combining it with complementary features such as pattern matching, and > sealing), these few cases -- which right now feel like the whole world of > switch -- will eventually recede into being the quirky odd cases. > > Additionally, there are issues with the "empty" default clause. In the JEP > the "default: break;" was recommended, but interestingly it doesn't work > with the arrow syntax. ("default -> break;" is a compile time error, only > the "default: {break;}" is possible.) We can use both the "default: {}" and > "default -> {}", which is fine. But while the "default:" is > possible (without body), the "default ->" is an error. I don't know what is > the reason behind it. Allowing an empty body with the arrow syntax would > make the actual solution a little bit cleaner. > > > This is a fair observation; this should probably be cleaned up. > > It would be possible to allow the programmer to mark the intended > totality. Maybe a new keyword would be too much for this purpose. > > > Yes, we considered this, and came to the conclusion that the problem is > the wrong default. Adding a new keyword for "total switch" is bad in three > ways: it is, as you say, "too much"; it doesn't fix the underlying problem; > and the cases in which it most needs to be used, people will probably > forget to use it. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hunor.szegi at gmail.com Mon Jun 20 12:03:54 2022 From: hunor.szegi at gmail.com (Hunor Szegi) Date: Mon, 20 Jun 2022 13:03:54 +0100 Subject: Break in non-fall through switch Message-ID: Hi All, I would like to ask you to consider banning the break statement at the non-fall through switch. First, this statement does nothing here. The return value is presented using a different keyword (yield), so there's really no purpose left for the break statement. Additionally, it is confusing, as there's no control flow here that could be interrupted. If we want an empty case body, currently it is possible to provide an empty block. (I would recommend allowing the completely empty case bodies, similarly to the legacy switch.) In a switch expression it isn't possible to use it, because we have to yield a value, and can't break the flow before that. So this is already an asymmetry, we won't make it worse allowing the break only at a fall through switch statement, at the only case it makes sense. It could be possible to use the break statement within the switch, but that would be related only to the outer control flow, like a for loop. In this way it would be possible to break the outer flow without using a label. Thank you, Regards, Hunor -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Jun 19 12:32:07 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 19 Jun 2022 14:32:07 +0200 (CEST) Subject: Totality at switch statements In-Reply-To: References: Message-ID: <1710723284.1579281.1655641927021.JavaMail.zimbra@u-pem.fr> > From: "Hunor Szegi" > To: amber-dev at openjdk.org > Sent: Sunday, June 19, 2022 12:42:12 AM > Subject: Totality at switch statements Hi Hunor, thanks for your feedback. Let's start to understand why we want pattern matching, until now, if you want to describe an algorithm on a recursive data structure, you put the data and the parts of the algorithm in the same place ; you declare an interface with an abstract method corresponding to the algorithm and you implement the interface with different classes/records. In that case, the code of the algorithm is as important as the data, they are intermingled. Now, we want to introduce pattern matching, the idea of the pattern matching is to separate the data from the algorithm, the data are still defined using an interface and records, but the algorithm is not defined as an abstract method of the interface but as a method outside the data definition. You may ask why doing that, it's because the definition of the data is more important than the algorithm itself. Unlike with an abstract method which tied the data and the algorithm, here the data structure more important than the code itself. We have decided to express the pattern matching using switch, this means retrofitting the switch this new purpose. We have done that in several moves, first fix the semantics inherited from the C by adding the arrow syntax, then extends the semantics to allow switch expression and add patterns on types (type pattern and record patterns). All these moves as to be backward compatible so switch statement on int, String and enum must be still work as before. Totality is essential for pattern matching, it's the way to detect discrepancies between the definition of the data and the code of the pattern matching itself. Unlike with an abstract method, with pattern matching the data and the algorithm are defined in two different places so the data can be updated without the switch being updated. We want the compiler to fail in that case. So all the new switch constructs (switch on null, switch with guards, switch on patterns, switch expression) fails if the switch is not total, detecting when the data and the switch are not aligned anymore. This means that using "default" is now a blunder because while it makes the switch total it disable the compiler to warn the user when the data change. In the details, it's not fully true because we can switch on an infinity of values (or on a range big enough that it's like infinity in practice) so we can not enumerate all possibles combinations. Switches on ints and strings are in this category, so for them, there is no other solution than having a default. In the future a warning may be a good idea to ask for a default at the end of the switch. For the switch on enum, a user can enumerate all the cases but because of backward compatibility, we need a backward compatible way to opt-in to totality, my preferred way to do that is to add a "case null -> throw null", which transforms the old switch on an enum to a new switch on an enum which asks for totality. Now, to answer your questions, yes we want totality even in a switch statement to detect when the data change, default is kind of an anti-pattern so i don't see the need to have a special syntax for default -> {}, i prefer to keep the lambda syntax and the switch syntax aligned. Forcing totality on arrow syntax is something we have debated and we believe it's better to separate the two concerns: fix the semantics inherited from the C and totality, among other things it allows automatic conversion by tools between the colon syntax to the arrow syntax. Anyway, given that the arrow syntax is not a preview anymore, this option is not on the table anymore. About @total, you can use "case null -> throw null" instead. We may come with a true syntax later but not using an annotation because we have this rule that an annotation can not changed the semantics of the language. I hope this helps to understand why we wan totality, regards, R?mi > Hi All, > I really like the progress of adding pattern matching to Java (and a lot of > other features). I can not wait to use it in productive code (non-preview). But > I would like to give you feedback about a tiny detail, about the totality of > switch statements. > Surely, the totality is necessary at switch expressions, but forcing it at a > statement is questionable. > It can be helpful for the programmers to check the totality in those cases when > the intent is that. But it is quite common to create a switch statement that > doesn't handle all of the possibilities. Why would it be different using > patterns? Why is it beneficial to force totality? This check can be an IDE > feature. (Or the programmer can try adding a default clause, and the duplicated > totality will be shown as an error. But I know it isn't convenient.) > Honestly I feel that the rule, when the totality is forced, is dictated simply > by the necessity of backward compatibility. What will happen if a new type (for > example double) will be allowed for the selector expression? The backward > compatibility wouldn't be an issue, but it would be weird behaving differently > with an int compared to a double, so I guess the totality won't be forced. What > would happen if the finality requirement was removed, and the equality could be > checked for all types? What about the totality check in this imagined future? > Of course the best would be to allow the totality check somehow if the intent is > that. A warning could be a solution, but that can be annoying. It will force > the programmers to suppress it, or to add a default clause (what is the current > solution). Adding a default clause could be treated as marking the intent: we > don't want totality. But the actual syntax does not represent it clearly. > Additionally, there are issues with the "empty" default clause. In the JEP the > "default: break;" was recommended, but interestingly it doesn't work with the > arrow syntax. ("default -> break;" is a compile time error, only the "default: > {break;}" is possible.) We can use both the "default: {}" and "default -> {}", > which is fine. But while the "default:" is possible (without body), the > "default ->" is an error. I don't know what is the reason behind it. Allowing > an empty body with the arrow syntax would make the actual solution a little bit > cleaner. > I think forcing the totality at statements is partly an intent for uniformity. > The best would be if the same rules were applied to all cases, regardless if it > is a statement or expression, old or arrow syntax. But backward compatibility > can't allow full uniformity, it moves the separation into the middle of a box, > instead of a clear distinction between a statement and expression. It creates > more cases. > It would be possible, forcing the totality only at the arrow syntax. But that > would move some of the programmers using the old syntax, which may be less > fortunate. > It would be possible to allow the programmer to mark the intended totality. > Maybe a new keyword would be too much for this purpose. Alternatively I can > imagine allowing annotations at a switch statement/expression in the future. > For example: > @total > switch (x) { > ... > } > If this syntax isn't possible, the annotation could be added right before the > opening curly bracket. Alternatively a warning suppress annotation could be > used specifically for the switch. > But this is only a brainstorming. My main point is that I don't think the > totality should be forced at switch statements. Or it should cause only a > warning. > I hope my feedback isn't pointless. I'd be very interested to hear other > people's opinions. > Thank you in advance, > Regards, > Hunor -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Jun 20 14:25:02 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 20 Jun 2022 16:25:02 +0200 (CEST) Subject: Totality at switch statements In-Reply-To: <1710723284.1579281.1655641927021.JavaMail.zimbra@u-pem.fr> References: <1710723284.1579281.1655641927021.JavaMail.zimbra@u-pem.fr> Message-ID: <1520631870.2292834.1655735102910.JavaMail.zimbra@u-pem.fr> Wow, one day to deliver an email, that's not fast :) I suppose it was stuck somewhere. R?mi >> From: "Hunor Szegi" >> To: amber-dev at openjdk.org >> Sent: Sunday, June 19, 2022 12:42:12 AM >> Subject: Totality at switch statements > Hi Hunor, > thanks for your feedback. > Let's start to understand why we want pattern matching, until now, if you want > to describe an algorithm on a recursive data structure, you put the data and > the parts of the algorithm in the same place ; you declare an interface with an > abstract method corresponding to the algorithm and you implement the interface > with different classes/records. > In that case, the code of the algorithm is as important as the data, they are > intermingled. > Now, we want to introduce pattern matching, the idea of the pattern matching is > to separate the data from the algorithm, the data are still defined using an > interface and records, but the algorithm is not defined as an abstract method > of the interface but as a method outside the data definition. You may ask why > doing that, it's because the definition of the data is more important than the > algorithm itself. Unlike with an abstract method which tied the data and the > algorithm, here the data structure more important than the code itself. > We have decided to express the pattern matching using switch, this means > retrofitting the switch this new purpose. > We have done that in several moves, first fix the semantics inherited from the C > by adding the arrow syntax, then extends the semantics to allow switch > expression and add patterns on types (type pattern and record patterns). All > these moves as to be backward compatible so switch statement on int, String and > enum must be still work as before. > Totality is essential for pattern matching, it's the way to detect discrepancies > between the definition of the data and the code of the pattern matching itself. > Unlike with an abstract method, with pattern matching the data and the > algorithm are defined in two different places so the data can be updated > without the switch being updated. We want the compiler to fail in that case. > So all the new switch constructs (switch on null, switch with guards, switch on > patterns, switch expression) fails if the switch is not total, detecting when > the data and the switch are not aligned anymore. > This means that using "default" is now a blunder because while it makes the > switch total it disable the compiler to warn the user when the data change. > In the details, it's not fully true because we can switch on an infinity of > values (or on a range big enough that it's like infinity in practice) so we can > not enumerate all possibles combinations. > Switches on ints and strings are in this category, so for them, there is no > other solution than having a default. In the future a warning may be a good > idea to ask for a default at the end of the switch. > For the switch on enum, a user can enumerate all the cases but because of > backward compatibility, we need a backward compatible way to opt-in to > totality, my preferred way to do that is to add a "case null -> throw null", > which transforms the old switch on an enum to a new switch on an enum which > asks for totality. > Now, to answer your questions, yes we want totality even in a switch statement > to detect when the data change, default is kind of an anti-pattern so i don't > see the need to have a special syntax for default -> {}, i prefer to keep the > lambda syntax and the switch syntax aligned. Forcing totality on arrow syntax > is something we have debated and we believe it's better to separate the two > concerns: fix the semantics inherited from the C and totality, among other > things it allows automatic conversion by tools between the colon syntax to the > arrow syntax. Anyway, given that the arrow syntax is not a preview anymore, > this option is not on the table anymore. About @total, you can use "case null > -> throw null" instead. We may come with a true syntax later but not using an > annotation because we have this rule that an annotation can not changed the > semantics of the language. > I hope this helps to understand why we wan totality, > regards, > R?mi >> Hi All, >> I really like the progress of adding pattern matching to Java (and a lot of >> other features). I can not wait to use it in productive code (non-preview). But >> I would like to give you feedback about a tiny detail, about the totality of >> switch statements. >> Surely, the totality is necessary at switch expressions, but forcing it at a >> statement is questionable. >> It can be helpful for the programmers to check the totality in those cases when >> the intent is that. But it is quite common to create a switch statement that >> doesn't handle all of the possibilities. Why would it be different using >> patterns? Why is it beneficial to force totality? This check can be an IDE >> feature. (Or the programmer can try adding a default clause, and the duplicated >> totality will be shown as an error. But I know it isn't convenient.) >> Honestly I feel that the rule, when the totality is forced, is dictated simply >> by the necessity of backward compatibility. What will happen if a new type (for >> example double) will be allowed for the selector expression? The backward >> compatibility wouldn't be an issue, but it would be weird behaving differently >> with an int compared to a double, so I guess the totality won't be forced. What >> would happen if the finality requirement was removed, and the equality could be >> checked for all types? What about the totality check in this imagined future? >> Of course the best would be to allow the totality check somehow if the intent is >> that. A warning could be a solution, but that can be annoying. It will force >> the programmers to suppress it, or to add a default clause (what is the current >> solution). Adding a default clause could be treated as marking the intent: we >> don't want totality. But the actual syntax does not represent it clearly. >> Additionally, there are issues with the "empty" default clause. In the JEP the >> "default: break;" was recommended, but interestingly it doesn't work with the >> arrow syntax. ("default -> break;" is a compile time error, only the "default: >> {break;}" is possible.) We can use both the "default: {}" and "default -> {}", >> which is fine. But while the "default:" is possible (without body), the >> "default ->" is an error. I don't know what is the reason behind it. Allowing >> an empty body with the arrow syntax would make the actual solution a little bit >> cleaner. >> I think forcing the totality at statements is partly an intent for uniformity. >> The best would be if the same rules were applied to all cases, regardless if it >> is a statement or expression, old or arrow syntax. But backward compatibility >> can't allow full uniformity, it moves the separation into the middle of a box, >> instead of a clear distinction between a statement and expression. It creates >> more cases. >> It would be possible, forcing the totality only at the arrow syntax. But that >> would move some of the programmers using the old syntax, which may be less >> fortunate. >> It would be possible to allow the programmer to mark the intended totality. >> Maybe a new keyword would be too much for this purpose. Alternatively I can >> imagine allowing annotations at a switch statement/expression in the future. >> For example: >> @total >> switch (x) { >> ... >> } >> If this syntax isn't possible, the annotation could be added right before the >> opening curly bracket. Alternatively a warning suppress annotation could be >> used specifically for the switch. >> But this is only a brainstorming. My main point is that I don't think the >> totality should be forced at switch statements. Or it should cause only a >> warning. >> I hope my feedback isn't pointless. I'd be very interested to hear other >> people's opinions. >> Thank you in advance, >> Regards, >> Hunor -------------- next part -------------- An HTML attachment was scrubbed... URL: From hunor.szegi at gmail.com Mon Jun 20 14:40:32 2022 From: hunor.szegi at gmail.com (Hunor Szegi) Date: Mon, 20 Jun 2022 15:40:32 +0100 Subject: Questions about the record pattern Message-ID: Hi All, I'm looking at the record pattern (JEP 405): "A record pattern consists of a type, a (possibly empty) record component pattern list which is used to match against the corresponding record components, and an optional identifier." (I guess the pattern should be matching to the original list of record components, and it isn't related to the constructors. (Or is it possible that the non-canonical constructors could be used here?) I presume not, as then a pattern check could have side effects as well.) So let's see an example record: record Box(Object content, int size) {} The following pattern case label won't work: "case Box(i, j) ->" , as "i" and "j" are not patterns. I see the point to describe the structure as simply as possible. And given that a single variable can't be a pattern, it's difficult to cover both the "Box(i, j)" and a compound "Box(String i, int j)" pattern. But from the user perspective it would be the most straightforward. If the type of the components are given (no "overloaded" constructor could play a role), why is it necessary to provide the type in the pattern? Of course the possibility of providing a subtype of the component is beneficial, but that can be treated as a compound pattern - a record pattern, which optionally can contain type patterns. I saw this example: "Point(var x, var y) - so this is a special case of the type pattern, where the component type is inferred. But why is the "var" necessary here? Isn't it a counterexample, which breaks the specification, as "var x" isn't a pattern. Indeed it is very similar to a type pattern, but not exactly that. (You can't write "case var i ->".) I can imagine a modified specification, instead of a list of patterns, using a list of "pattern variable or pattern". Maybe I misunderstood something, as of course I wasn't able to try it. In this case sorry in advance. Finally some questions: case Box(Box(String x, int y) a, int z) b -> I haven't seen a similar example in the JEP, but based on the description, both the "a" and "b" pattern variables should be allowed, isn't it? (It would be good.) And can we use a constant as pattern, or the null pattern? For example: case Box(Box(null, int y) a, 3) b -> Thank you in advance, Regards, Hunor -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Jun 20 14:45:19 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 20 Jun 2022 10:45:19 -0400 Subject: Totality at switch statements In-Reply-To: References: <4f6a7068-daf9-3618-2e83-77bcaf5b346f@oracle.com> Message-ID: <4e04688e-dcc5-a209-f196-31215a45b50a@oracle.com> > Looking at your example, when an additional sealed subclass will be > added. Yes, it would be very useful to warn the programmers. But > imagine a situation when the totality isn't intended,?so the > programmer wants a side effect only in a few cases. She will be forced > to add an?empty default clause. And later, when a new sealed subclass > will be added, there won't be any alert,?as the switch is already > total, forever. Surely, it helped a little bit to increase the safety > initially (the programmer was forced to think about the missing > cases), but with a lot of empty default clauses this safety will be > partial. Well, it depends how many cases your sealed type has.? If it has few, then you can totalize by naming all the cases.? Now, right now that is a little cumbersome, but in the future you will probably be able to do: ??? switch (x) { ??????? case GoodCase g: ... ??????? case AlsoGoodCase g: ... ??????? case BadCase _, ReallyBadCase _, AwfulCase _: throw ... ??? } which, depending on how many permitted types there are, still preserves the "tell me when something changes" behavior.? (You can't do this now because you can't merge patterns with bindings, and you can't yet suppress a binding.? All in due time.) > BTW, Scala allows switch expressions without totality, only a warning > is raised. This seems a safety?risk to me, no idea why it was > implemented this way. FWIW, Haskell also allows functions defined by case to be partial too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Jun 20 14:52:17 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 20 Jun 2022 10:52:17 -0400 Subject: Questions about the record pattern In-Reply-To: References: Message-ID: <96732aed-9334-ca5d-a29c-aa7464daece0@oracle.com> > (I guess the pattern should be matching to the original list of record > components, and it isn't related to the constructors. (Or is it > possible that the non-canonical constructors could be used here?) I > presume not, as then a pattern check could have side?effects as well.) Currently, records have a single deconstruction pattern -- the one matching the record descriptor / canonical constructor.? But in the future, records, like other classes, could have more than one deconstruction pattern, in which case we'd do overload selection prior to matching. Just as with method invocation, first we do overload selection, then we do what we have to do to convert the arguments to the types of the parameters.? Similarly, with patterns, we do overload selection (trivial right now with records), and then match the subpatterns to the bindings. > record Box(Object content, int size) {} > > The following pattern case label won't work: "case Box(i, j) ->" , as > "i" and "j" are not patterns. I see the point to describe?the > structure?as simply as possible. And given that a single variable > can't be a pattern, it's difficult to cover both the "Box(i, j)" and a > compound "Box(String i, int j)" pattern. But from the user perspective > it would be the most straightforward. Our principle here is: variables should be declared.? Having i and j spring into existence by virtual of being named in a pattern, *which looks an awful lot like a method invocation*, is too subtle. > If the type of the components are given (no "overloaded" constructor > could play a role) As said, this is a short-term state of affairs. > I saw this example: "Point(var x, var y) - so this is a special case > of the type pattern, where the component type is inferred. But why is > the "var" necessary here? Isn't it a counterexample, which breaks the > specification, as "var x" isn't a pattern. Indeed it is very similar > to a type pattern, but not exactly that. (You can't write "case var i > ->".) Because x should have a declaration. I realize Python does it differently, but then again, it's dynamically typed, so it's not really a fair comparison. > Finally some questions: > > case Box(Box(String x, int y) a, int z) b -> > > I haven't seen a similar example in the JEP, but based on the > description, both the "a" and "b" pattern variables?should be allowed, > isn't it? (It would be good.) Correct, the inner `Box(String x, int y) a` is what we call a _named record pattern_.?? This is not unlike the @ patterns in Haskell or Scala. > And can we use a constant as pattern, or the null pattern? For example: No, not yet.? Constants (and null) are not currently patterns. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier at zwitserloot.com Mon Jun 20 15:57:03 2022 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 20 Jun 2022 08:57:03 -0700 Subject: Questions about the record pattern In-Reply-To: References: Message-ID: On 20 Jun 2022 at 16:40:32, Hunor Szegi wrote: > ?. > The following pattern case label won?t work: "case Box(i, j) ->" , as "i" > and "j" are not patterns. > Even money interprets this as 'i and j are valid, in-scope variables from where the switch is being defined, and this is attempting to match the case of a Box such that its deconstructed values are equal to i and j'. In other words, Moving to Point instead: var x = 5; var y = 10; switch (point) { case Point(x, y) -> ? } This could reasonably be interpreted as ?match the case where x=5 and y = 10?, i.e. as if that said case Point(5, 10) -> ... There?s some fairly severe limits on how far one should take ?in a world where nobody knows how to read these things, let?s enumerate the many many ways folks might interpret some completely new language feature?, but java does have rather a large amount of existing coders, so introducing new features in a way that causes lots of confusion is best avoided, no doubt. At any rate, one extra reason as to why omitting the var is stylistically problematic. I assume, given that the feature has been rolled out and is seeing active additions, debates on syntax are valid :) --Reinier Zwitserloot -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Jun 20 16:00:42 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 20 Jun 2022 12:00:42 -0400 Subject: Questions about the record pattern In-Reply-To: References: Message-ID: <3644845c-e9e6-99c8-2c01-dde5927a31a0@oracle.com> > I assume, given that the feature has been rolled out and is seeing > active additions, debates on syntax are valid :) *Debates* on syntax are never valid :) Reasoned, respectful, bounded, value-adding discourse about the pros and cons, tradeoffs, potential for confusion, expressiveness, etc, are tolerated to the extent they shed light and not heat. From hunor.szegi at gmail.com Tue Jun 21 09:26:34 2022 From: hunor.szegi at gmail.com (Hunor Szegi) Date: Tue, 21 Jun 2022 10:26:34 +0100 Subject: Questions about the record pattern In-Reply-To: <96732aed-9334-ca5d-a29c-aa7464daece0@oracle.com> References: <96732aed-9334-ca5d-a29c-aa7464daece0@oracle.com> Message-ID: Thank you for the answers. True, with overloaded deconstructors in the future the type should be provided, so this is the best solution, and possibly the least confusing. On Mon, 20 Jun 2022 at 15:52, Brian Goetz wrote: > > (I guess the pattern should be matching to the original list of record > components, and it isn't related to the constructors. (Or is it possible > that the non-canonical constructors could be used here?) I presume not, as > then a pattern check could have side effects as well.) > > > Currently, records have a single deconstruction pattern -- the one > matching the record descriptor / canonical constructor. But in the future, > records, like other classes, could have more than one deconstruction > pattern, in which case we'd do overload selection prior to matching. > > Just as with method invocation, first we do overload selection, then we do > what we have to do to convert the arguments to the types of the > parameters. Similarly, with patterns, we do overload selection (trivial > right now with records), and then match the subpatterns to the bindings. > > record Box(Object content, int size) {} > > The following pattern case label won't work: "case Box(i, j) ->" , as "i" > and "j" are not patterns. I see the point to describe the structure as > simply as possible. And given that a single variable can't be a pattern, > it's difficult to cover both the "Box(i, j)" and a compound "Box(String i, > int j)" pattern. But from the user perspective it would be the most > straightforward. > > > Our principle here is: variables should be declared. Having i and j > spring into existence by virtual of being named in a pattern, *which looks > an awful lot like a method invocation*, is too subtle. > > If the type of the components are given (no "overloaded" constructor could > play a role) > > > As said, this is a short-term state of affairs. > > I saw this example: "Point(var x, var y) - so this is a special case of > the type pattern, where the component type is inferred. But why is the > "var" necessary here? Isn't it a counterexample, which breaks the > specification, as "var x" isn't a pattern. Indeed it is very similar to a > type pattern, but not exactly that. (You can't write "case var i ->".) > > > Because x should have a declaration. > > I realize Python does it differently, but then again, it's dynamically > typed, so it's not really a fair comparison. > > Finally some questions: > > case Box(Box(String x, int y) a, int z) b -> > > I haven't seen a similar example in the JEP, but based on the description, > both the "a" and "b" pattern variables should be allowed, isn't it? (It > would be good.) > > > Correct, the inner `Box(String x, int y) a` is what we call a _named > record pattern_. This is not unlike the @ patterns in Haskell or Scala. > > And can we use a constant as pattern, or the null pattern? For example: > > > No, not yet. Constants (and null) are not currently patterns. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hunor.szegi at gmail.com Tue Jun 21 09:44:10 2022 From: hunor.szegi at gmail.com (Hunor Szegi) Date: Tue, 21 Jun 2022 10:44:10 +0100 Subject: Totality at switch statements In-Reply-To: <4e04688e-dcc5-a209-f196-31215a45b50a@oracle.com> References: <4f6a7068-daf9-3618-2e83-77bcaf5b346f@oracle.com> <4e04688e-dcc5-a209-f196-31215a45b50a@oracle.com> Message-ID: Thank you. Yes, that is the best we can do if we want to know about the changes, listing the cases we are aware of, using a concise syntax. With leftovers it would be possible listing multiple type patterns under a single label. Currently it is possible only using multiple case entries. I could imagine a syntax like this: case (BadCase, ReallyBadCase, AwfulCase) i -> .... but here the i should be an Object type - or the lowest common type. (In spite of that it isn't the same as "case Object i ->") BTW, playing with the syntax I realised Java 18 accepts both the "default" and "case default" labels (using legacy and arrow syntax as well). Java 8 accepts only "default". (In the specs I found only this format.) On Mon, 20 Jun 2022 at 15:45, Brian Goetz wrote: > > > Looking at your example, when an additional sealed subclass will be added. > Yes, it would be very useful to warn the programmers. But imagine a > situation when the totality isn't intended, so the programmer wants a side > effect only in a few cases. She will be forced to add an empty default > clause. And later, when a new sealed subclass will be added, there won't be > any alert, as the switch is already total, forever. Surely, it helped a > little bit to increase the safety initially (the programmer was forced to > think about the missing cases), but with a lot of empty default clauses > this safety will be partial. > > > Well, it depends how many cases your sealed type has. If it has few, then > you can totalize by naming all the cases. Now, right now that is a little > cumbersome, but in the future you will probably be able to do: > > switch (x) { > case GoodCase g: ... > case AlsoGoodCase g: ... > case BadCase _, ReallyBadCase _, AwfulCase _: throw ... > } > > which, depending on how many permitted types there are, still preserves > the "tell me when something changes" behavior. (You can't do this now > because you can't merge patterns with bindings, and you can't yet suppress > a binding. All in due time.) > > > BTW, Scala allows switch expressions without totality, only a warning is > raised. This seems a safety risk to me, no idea why it was implemented this > way. > > > FWIW, Haskell also allows functions defined by case to be partial too. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hunor.szegi at gmail.com Tue Jun 21 10:02:21 2022 From: hunor.szegi at gmail.com (Hunor Szegi) Date: Tue, 21 Jun 2022 11:02:21 +0100 Subject: Totality at switch statements In-Reply-To: <1520631870.2292834.1655735102910.JavaMail.zimbra@u-pem.fr> References: <1710723284.1579281.1655641927021.JavaMail.zimbra@u-pem.fr> <1520631870.2292834.1655735102910.JavaMail.zimbra@u-pem.fr> Message-ID: Thank you for the explanation. True, separating the data and the data processing into different classes makes it more important to know about the changes. A compile time error or a warning can show you the changes. But using the default clause will eliminate this help. I can imagine an IDE check, which shows you the uncovered cases, in spite there's a default clause. But the best practice would be listing all the known types you are aware of but for some reason don't want to process or can't accept. (Hopefully using a concise syntax in the future.) I still think so, forcing the totality of switch statements will result in a lot of default clauses, which eliminates the totality check, and makes some switches one line longer unnecessarily. But maybe I am wrong, and it will help the developers to think about the pros and cons of this situation and will result in better practices. Regards, Hunor On Mon, 20 Jun 2022 at 15:26, Remi Forax wrote: > Wow, one day to deliver an email, that's not fast :) > I suppose it was stuck somewhere. > > R?mi > > > > ------------------------------ > > *From: *"Hunor Szegi" > *To: *amber-dev at openjdk.org > *Sent: *Sunday, June 19, 2022 12:42:12 AM > *Subject: *Totality at switch statements > > > Hi Hunor, > thanks for your feedback. > > Let's start to understand why we want pattern matching, until now, if you > want to describe an algorithm on a recursive data structure, you put the > data and the parts of the algorithm in the same place ; you declare an > interface with an abstract method corresponding to the algorithm and you > implement the interface with different classes/records. > In that case, the code of the algorithm is as important as the data, they > are intermingled. > > Now, we want to introduce pattern matching, the idea of the pattern > matching is to separate the data from the algorithm, the data are still > defined using an interface and records, but the algorithm is not defined as > an abstract method of the interface but as a method outside the data > definition. You may ask why doing that, it's because the definition of the > data is more important than the algorithm itself. Unlike with an abstract > method which tied the data and the algorithm, here the data structure more > important than the code itself. > > We have decided to express the pattern matching using switch, this means > retrofitting the switch this new purpose. > We have done that in several moves, first fix the semantics inherited from > the C by adding the arrow syntax, then extends the semantics to allow > switch expression and add patterns on types (type pattern and record > patterns). All these moves as to be backward compatible so switch statement > on int, String and enum must be still work as before. > > Totality is essential for pattern matching, it's the way to detect > discrepancies between the definition of the data and the code of the > pattern matching itself. Unlike with an abstract method, with pattern > matching the data and the algorithm are defined in two different places so > the data can be updated without the switch being updated. We want the > compiler to fail in that case. > So all the new switch constructs (switch on null, switch with guards, > switch on patterns, switch expression) fails if the switch is not total, > detecting when the data and the switch are not aligned anymore. > > This means that using "default" is now a blunder because while it makes > the switch total it disable the compiler to warn the user when the data > change. > In the details, it's not fully true because we can switch on an infinity > of values (or on a range big enough that it's like infinity in practice) so > we can not enumerate all possibles combinations. > Switches on ints and strings are in this category, so for them, there is > no other solution than having a default. In the future a warning may be a > good idea to ask for a default at the end of the switch. > For the switch on enum, a user can enumerate all the cases but because of > backward compatibility, we need a backward compatible way to opt-in to > totality, my preferred way to do that is to add a "case null -> throw > null", which transforms the old switch on an enum to a new switch on an > enum which asks for totality. > > Now, to answer your questions, yes we want totality even in a switch > statement to detect when the data change, default is kind of an > anti-pattern so i don't see the need to have a special syntax for default > -> {}, i prefer to keep the lambda syntax and the switch syntax aligned. > Forcing totality on arrow syntax is something we have debated and we > believe it's better to separate the two concerns: fix the semantics > inherited from the C and totality, among other things it allows automatic > conversion by tools between the colon syntax to the arrow syntax. Anyway, > given that the arrow syntax is not a preview anymore, this option is not on > the table anymore. About @total, you can use "case null -> throw null" > instead. We may come with a true syntax later but not using an annotation > because we have this rule that an annotation can not changed the semantics > of the language. > > I hope this helps to understand why we wan totality, > regards, > R?mi > > > Hi All, > > I really like the progress of adding pattern matching to Java (and a > lot of other features). I can not wait to use it in productive code > (non-preview). But I would like to give you feedback about a tiny detail, > about the totality of switch statements. > > Surely, the totality is necessary at switch expressions, but forcing it at > a statement is questionable. > > It can be helpful for the programmers to check the totality in those cases > when the intent is that. But it is quite common to create a switch > statement that doesn't handle all of the possibilities. Why would it be > different using patterns? Why is it beneficial to force totality? This > check can be an IDE feature. (Or the programmer can try adding a default > clause, and the duplicated totality will be shown as an error. But I know > it isn't convenient.) > > Honestly I feel that the rule, when the totality is forced, is dictated > simply by the necessity of backward compatibility. What will happen if a > new type (for example double) will be allowed for the selector expression? > The backward compatibility wouldn't be an issue, but it would be weird > behaving differently with an int compared to a double, so I guess the > totality won't be forced. What would happen if the finality requirement was > removed, and the equality could be checked for all types? What about the > totality check in this imagined future? > > Of course the best would be to allow the totality check somehow if the > intent is that. A warning could be a solution, but that can be annoying. It > will force the programmers to suppress it, or to add a default clause (what > is the current solution). Adding a default clause could be treated as > marking the intent: we don't want totality. But the actual syntax does not > represent it clearly. > > Additionally, there are issues with the "empty" default clause. In the JEP > the "default: break;" was recommended, but interestingly it doesn't work > with the arrow syntax. ("default -> break;" is a compile time error, only > the "default: {break;}" is possible.) We can use both the "default: {}" and > "default -> {}", which is fine. But while the "default:" is > possible (without body), the "default ->" is an error. I don't know what is > the reason behind it. Allowing an empty body with the arrow syntax would > make the actual solution a little bit cleaner. > > I think forcing the totality at statements is partly an intent for > uniformity. The best would be if the same rules were applied to all cases, > regardless if it is a statement or expression, old or arrow syntax. But > backward compatibility can't allow full uniformity, it moves the separation > into the middle of a box, instead of a clear distinction between a > statement and expression. It creates more cases. > > It would be possible, forcing the totality only at the arrow syntax. But > that would move some of the programmers using the old syntax, which may be > less fortunate. > > It would be possible to allow the programmer to mark the intended > totality. Maybe a new keyword would be too much for this purpose. > Alternatively I can imagine allowing annotations at a switch > statement/expression in the future. For example: > > @total > switch (x) { > ... > } > > If this syntax isn't possible, the annotation could be added right before > the opening curly bracket. Alternatively a warning suppress annotation > could be used specifically for the switch. > But this is only a brainstorming. My main point is that I don't think the > totality should be forced at switch statements. Or it should cause only a > warning. > > I hope my feedback isn't pointless. I'd be very interested to hear other > people's opinions. > > Thank you in advance, > > Regards, > Hunor > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jun 24 13:35:40 2022 From: duke at openjdk.org (duke) Date: Fri, 24 Jun 2022 13:35:40 GMT Subject: git: openjdk/amber: templated-strings: Merge jdk Message-ID: <5299fc4e-9975-4afc-864e-0f3fe3da96ae@openjdk.org> Changeset: 859ad79b Author: Jim Laskey Date: 2022-06-24 10:26:48 +0000 URL: https://git.openjdk.org/amber/commit/859ad79beec0d68adffc3c36264b22b23c1e6d0d Merge jdk ! .github/workflows/submit.yml ! .jcheck/conf ! make/Docs.gmk ! make/autoconf/basic.m4 ! make/autoconf/boot-jdk.m4 ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags.m4 ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/lib-bundled.m4 ! make/autoconf/lib-hsdis.m4 ! make/autoconf/lib-std.m4 ! make/autoconf/platform.m4 ! make/autoconf/spec.gmk.in ! make/autoconf/toolchain.m4 ! make/autoconf/toolchain_microsoft.m4 ! make/common/modules/LauncherCommon.gmk ! make/conf/docs-modules.conf ! make/conf/jib-profiles.js ! make/conf/module-loader-map.conf ! make/conf/version-numbers.conf ! make/data/hotspot-symbols/symbols-unix ! make/devkit/createWindowsDevkit.sh ! make/hotspot/gensrc/GensrcAdlc.gmk ! make/hotspot/lib/CompileJvm.gmk ! make/ide/idea/jdk/template/src/idea/JdkIdeaAntLogger.java ! make/ide/idea/langtools/template/src/idea/LangtoolsIdeaAntLogger.java ! make/ide/netbeans/langtools/build.xml ! make/jdk/src/classes/build/tools/charsetmapping/EUC_TW.java ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java ! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java ! make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java ! make/langtools/build.xml ! make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java ! make/modules/java.base/Copy.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! make/modules/jdk.hotspot.agent/Gensrc.gmk ! make/modules/jdk.jdi/Lib.gmk ! make/scripts/fixpath.sh ! make/scripts/generate-symbol-data.sh ! make/scripts/logger.sh ! make/scripts/shell-profiler.sh ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java ! make/test/JtregNativeJdk.gmk ! src/demo/share/java2d/J2DBench/src/j2dbench/Result.java ! src/demo/share/java2d/J2DBench/src/j2dbench/TestEnvironment.java ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp + src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp + src/hotspot/cpu/aarch64/foreignGlobals_aarch64.cpp + src/hotspot/cpu/aarch64/foreignGlobals_aarch64.hpp - src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp - src/hotspot/cpu/aarch64/foreign_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/immediate_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp ! src/hotspot/cpu/aarch64/pauth_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp - src/hotspot/cpu/aarch64/universalNativeInvoker_aarch64.cpp - src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp + src/hotspot/cpu/aarch64/upcallLinker_aarch64.cpp ! src/hotspot/cpu/aarch64/vmStructs_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp ! src/hotspot/cpu/aarch64/vmreg_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/arm_32.ad + src/hotspot/cpu/arm/downcallLinker_arm.cpp + src/hotspot/cpu/arm/foreignGlobals_arm.cpp + src/hotspot/cpu/arm/foreignGlobals_arm.hpp - src/hotspot/cpu/arm/foreign_globals_arm.cpp - src/hotspot/cpu/arm/foreign_globals_arm.hpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.hpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/arm/globals_arm.hpp ! src/hotspot/cpu/arm/methodHandles_arm.cpp ! src/hotspot/cpu/arm/methodHandles_arm.hpp ! src/hotspot/cpu/arm/nativeInst_arm_32.cpp ! src/hotspot/cpu/arm/nativeInst_arm_32.hpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp - src/hotspot/cpu/arm/universalNativeInvoker_arm.cpp - src/hotspot/cpu/arm/universalUpcallHandle_arm.cpp + src/hotspot/cpu/arm/upcallLinker_arm.cpp ! src/hotspot/cpu/arm/vmreg_arm.cpp ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp + src/hotspot/cpu/ppc/downcallLinker_ppc.cpp + src/hotspot/cpu/ppc/foreignGlobals_ppc.cpp + src/hotspot/cpu/ppc/foreignGlobals_ppc.hpp - src/hotspot/cpu/ppc/foreign_globals_ppc.cpp - src/hotspot/cpu/ppc/foreign_globals_ppc.hpp ! src/hotspot/cpu/ppc/frame_ppc.cpp ! src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/globals_ppc.hpp ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/ppc/methodHandles_ppc.hpp - src/hotspot/cpu/ppc/parse_ppc.cpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp - src/hotspot/cpu/ppc/universalNativeInvoker_ppc.cpp - src/hotspot/cpu/ppc/universalUpcallHandle_ppc.cpp + src/hotspot/cpu/ppc/upcallLinker_ppc.cpp ! src/hotspot/cpu/ppc/vmreg_ppc.cpp ! src/hotspot/cpu/riscv/assembler_riscv.cpp + src/hotspot/cpu/riscv/downcallLinker_riscv.cpp + src/hotspot/cpu/riscv/foreignGlobals_riscv.cpp + src/hotspot/cpu/riscv/foreignGlobals_riscv.hpp - src/hotspot/cpu/riscv/foreign_globals_riscv.cpp - src/hotspot/cpu/riscv/foreign_globals_riscv.hpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp ! src/hotspot/cpu/riscv/globals_riscv.hpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/methodHandles_riscv.cpp ! src/hotspot/cpu/riscv/methodHandles_riscv.hpp ! src/hotspot/cpu/riscv/nativeInst_riscv.cpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_v.ad ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp - src/hotspot/cpu/riscv/universalNativeInvoker_riscv.cpp - src/hotspot/cpu/riscv/universalUpcallHandle_riscv.cpp + src/hotspot/cpu/riscv/upcallLinker_riscv.cpp ! src/hotspot/cpu/riscv/vmreg_riscv.cpp ! src/hotspot/cpu/s390/assembler_s390.inline.hpp ! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp + src/hotspot/cpu/s390/downcallLinker_s390.cpp + src/hotspot/cpu/s390/foreignGlobals_s390.cpp + src/hotspot/cpu/s390/foreignGlobals_s390.hpp - src/hotspot/cpu/s390/foreign_globals_s390.cpp - src/hotspot/cpu/s390/foreign_globals_s390.hpp ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/s390/globals_s390.hpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp ! src/hotspot/cpu/s390/methodHandles_s390.hpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp - src/hotspot/cpu/s390/universalNativeInvoker_s390.cpp - src/hotspot/cpu/s390/universalUpcallHandle_s390.cpp + src/hotspot/cpu/s390/upcallLinker_s390.cpp ! src/hotspot/cpu/s390/vmreg_s390.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp + src/hotspot/cpu/x86/downcallLinker_x86_32.cpp + src/hotspot/cpu/x86/downcallLinker_x86_64.cpp + src/hotspot/cpu/x86/foreignGlobals_x86.hpp + src/hotspot/cpu/x86/foreignGlobals_x86_32.cpp + src/hotspot/cpu/x86/foreignGlobals_x86_64.cpp - src/hotspot/cpu/x86/foreign_globals_x86.cpp - src/hotspot/cpu/x86/foreign_globals_x86.hpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp ! src/hotspot/cpu/x86/matcher_x86.hpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/cpu/x86/methodHandles_x86.hpp - src/hotspot/cpu/x86/parse_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp - src/hotspot/cpu/x86/universalNativeInvoker_x86_32.cpp - src/hotspot/cpu/x86/universalNativeInvoker_x86_64.cpp - src/hotspot/cpu/x86/universalUpcallHandler_x86_32.cpp - src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp + src/hotspot/cpu/x86/upcallLinker_x86_32.cpp + src/hotspot/cpu/x86/upcallLinker_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/vmreg_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad + src/hotspot/cpu/zero/downcallLinker_zero.cpp + src/hotspot/cpu/zero/foreignGlobals_zero.cpp + src/hotspot/cpu/zero/foreignGlobals_zero.hpp - src/hotspot/cpu/zero/foreign_globals_zero.cpp - src/hotspot/cpu/zero/foreign_globals_zero.hpp ! src/hotspot/cpu/zero/frame_zero.cpp ! src/hotspot/cpu/zero/gc/shared/barrierSetNMethod_zero.cpp ! src/hotspot/cpu/zero/globals_zero.hpp - src/hotspot/cpu/zero/universalNativeInvoker_zero.cpp - src/hotspot/cpu/zero/universalUpcallHandle_zero.cpp + src/hotspot/cpu/zero/upcallLinker_zero.cpp ! src/hotspot/cpu/zero/vmreg_zero.cpp ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/posix/jvm_posix.cpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/jvm_windows.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/perfMemory_windows.cpp ! src/hotspot/os_cpu/aix_ppc/atomic_aix_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_ppc/atomic_linux_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_riscv/os_linux_riscv.cpp ! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp ! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp ! src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/adlc/main.cpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_IR.hpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_LinearScan.hpp ! src/hotspot/share/cds/dumpTimeClassInfo.cpp ! src/hotspot/share/cds/dumpTimeClassInfo.hpp ! src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/ci/ciClassList.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp - src/hotspot/share/ci/ciNativeEntryPoint.cpp - src/hotspot/share/ci/ciNativeEntryPoint.hpp ! src/hotspot/share/ci/ciObject.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciTypeFlow.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/javaAssertions.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/classfile/stackMapTable.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/verifier.hpp ! src/hotspot/share/classfile/vmClassMacros.hpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.inline.hpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/debugInfoRec.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/pcDesc.hpp ! src/hotspot/share/code/scopeDesc.hpp ! src/hotspot/share/code/vmreg.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compilerDirectives.hpp ! src/hotspot/share/compiler/compilerEvent.cpp ! src/hotspot/share/compiler/disassembler.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1BatchedTask.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1RemSetSummary.hpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGenSizer.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/shared/generation.cpp ! src/hotspot/share/gc/shared/plab.cpp ! src/hotspot/share/gc/shared/plab.hpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/space.hpp ! src/hotspot/share/gc/shared/spaceDecorator.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/verifyOption.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp ! src/hotspot/share/include/cds.h ! src/hotspot/share/include/jvm.h ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/bytecodeUtils.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/instrumentation/jfrResolution.cpp ! src/hotspot/share/jfr/jfr.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/metadata/metadata.xsd ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.hpp ! src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp - src/hotspot/share/jfr/support/jfrEpochSynchronization.cpp - src/hotspot/share/jfr/support/jfrEpochSynchronization.hpp ! src/hotspot/share/jfr/support/jfrThreadLocal.cpp ! src/hotspot/share/jfr/support/jfrThreadLocal.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/logging/log.hpp ! src/hotspot/share/logging/logHandle.hpp ! src/hotspot/share/logging/logMessage.hpp ! src/hotspot/share/logging/logStream.cpp ! src/hotspot/share/logging/logStream.hpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/logging/logTagSet.hpp ! src/hotspot/share/memory/heap.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/array.hpp ! src/hotspot/share/oops/method.cpp + src/hotspot/share/oops/oopCast.inline.hpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/divnode.cpp ! src/hotspot/share/opto/divnode.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/escape.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/intrinsicnode.cpp ! src/hotspot/share/opto/intrinsicnode.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macro.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/parse3.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subnode.hpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp + src/hotspot/share/prims/downcallLinker.hpp + src/hotspot/share/prims/foreignGlobals.cpp + src/hotspot/share/prims/foreignGlobals.hpp + src/hotspot/share/prims/foreignGlobals.inline.hpp - src/hotspot/share/prims/foreign_globals.cpp - src/hotspot/share/prims/foreign_globals.hpp - src/hotspot/share/prims/foreign_globals.inline.hpp ! src/hotspot/share/prims/forte.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/nativeEntryPoint.cpp ! src/hotspot/share/prims/nativeLookup.cpp - src/hotspot/share/prims/universalNativeInvoker.cpp - src/hotspot/share/prims/universalNativeInvoker.hpp - src/hotspot/share/prims/universalUpcallHandler.cpp - src/hotspot/share/prims/universalUpcallHandler.hpp ! src/hotspot/share/prims/unsafe.cpp + src/hotspot/share/prims/upcallLinker.cpp + src/hotspot/share/prims/upcallLinker.hpp ! src/hotspot/share/prims/upcallStubs.cpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/continuation.hpp ! src/hotspot/share/runtime/continuationEntry.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/continuationEntry.inline.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/escapeBarrier.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/init.cpp ! src/hotspot/share/runtime/javaFrameAnchor.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/perfData.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vframe.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/services/memReporter.cpp ! src/hotspot/share/services/threadService.cpp ! src/hotspot/share/services/threadService.hpp ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/bitMap.hpp ! src/hotspot/share/utilities/compilerWarnings.hpp ! src/hotspot/share/utilities/compilerWarnings_gcc.hpp ! src/hotspot/share/utilities/compilerWarnings_visCPP.hpp ! src/hotspot/share/utilities/events.cpp ! src/hotspot/share/utilities/events.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp ! src/hotspot/share/utilities/resourceHash.hpp ! src/hotspot/share/utilities/vmError.cpp ! src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java ! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/java.base/macosx/native/libjli/java_md_macosx.m ! src/java.base/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/DESedeCipher.java ! src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/java.base/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/java.base/share/classes/com/sun/crypto/provider/RC2Cipher.java ! src/java.base/share/classes/java/io/ByteArrayInputStream.java ! src/java.base/share/classes/java/io/ByteArrayOutputStream.java ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/io/FileOutputStream.java ! src/java.base/share/classes/java/io/FilterInputStream.java ! src/java.base/share/classes/java/io/FilterOutputStream.java ! src/java.base/share/classes/java/io/InputStream.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/io/ObjectOutputStream.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/io/OutputStream.java ! src/java.base/share/classes/java/io/PipedInputStream.java ! src/java.base/share/classes/java/io/PipedOutputStream.java ! src/java.base/share/classes/java/io/SequenceInputStream.java ! src/java.base/share/classes/java/io/StringBufferInputStream.java ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java + src/java.base/share/classes/java/lang/BaseVirtualThread.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/InterruptedException.java ! src/java.base/share/classes/java/lang/Long.java + src/java.base/share/classes/java/lang/MatchException.java ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/ThreadBuilders.java ! src/java.base/share/classes/java/lang/VirtualMachineError.java ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/java/lang/foreign/Linker.java ! src/java.base/share/classes/java/lang/foreign/MemoryLayout.java ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java ! src/java.base/share/classes/java/lang/foreign/MemorySession.java ! src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java ! src/java.base/share/classes/java/lang/foreign/VaList.java ! src/java.base/share/classes/java/lang/foreign/ValueLayout.java ! src/java.base/share/classes/java/lang/foreign/package-info.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/math/RoundingMode.java ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/java/nio/channels/FileChannel.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/nio/file/CopyMoveHelper.java ! src/java.base/share/classes/java/nio/file/FileTreeIterator.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/security/SignatureSpi.java ! src/java.base/share/classes/java/time/chrono/Chronology.java ! src/java.base/share/classes/java/time/chrono/IsoChronology.java ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/java/time/chrono/JapaneseDate.java ! src/java.base/share/classes/java/time/chrono/MinguoChronology.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/java.base/share/classes/java/time/format/DecimalStyle.java ! src/java.base/share/classes/java/time/temporal/IsoFields.java ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/HashSet.java ! src/java.base/share/classes/java/util/LinkedHashSet.java ! src/java.base/share/classes/java/util/Locale.java ! src/java.base/share/classes/java/util/Random.java ! src/java.base/share/classes/java/util/SplittableRandom.java ! src/java.base/share/classes/java/util/TimeZone.java ! src/java.base/share/classes/java/util/random/RandomGenerator.java ! src/java.base/share/classes/java/util/random/package-info.java ! src/java.base/share/classes/java/util/spi/ToolProvider.java ! src/java.base/share/classes/java/util/zip/InflaterInputStream.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/java.base/share/classes/javax/crypto/Cipher.java ! src/java.base/share/classes/javax/crypto/CipherSpi.java ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java ! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java ! src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java ! src/java.base/share/classes/jdk/internal/foreign/abi/ABIDescriptor.java + src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java + src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java - src/java.base/share/classes/jdk/internal/foreign/abi/BufferLayout.java ! src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java ! src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java + src/java.base/share/classes/jdk/internal/foreign/abi/DowncallLinker.java + src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java - src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java - src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java + src/java.base/share/classes/jdk/internal/foreign/abi/SoftReferenceCache.java + src/java.base/share/classes/jdk/internal/foreign/abi/UpcallLinker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Architecture.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/X86_64Architecture.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java - src/java.base/share/classes/jdk/internal/invoke/ABIDescriptorProxy.java - src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java - src/java.base/share/classes/jdk/internal/invoke/VMStorageProxy.java ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java ! src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java ! src/java.base/share/classes/jdk/internal/math/DoubleConsts.java + src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java ! src/java.base/share/classes/jdk/internal/math/FloatConsts.java + src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java + src/java.base/share/classes/jdk/internal/math/MathUtils.java ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/RecordComponentWriter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeQualifiedObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeQualifiedStaticObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeStaticObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/util/Preconditions.java ! src/java.base/share/classes/jdk/internal/util/StaticProperty.java ! src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java ! src/java.base/share/classes/jdk/internal/vm/Continuation.java + src/java.base/share/classes/jdk/internal/vm/ContinuationSupport.java ! src/java.base/share/classes/jdk/internal/vm/FillerObject.java ! src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/net/www/MimeTable.java ! src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/nio/cs/StreamDecoder.java ! src/java.base/share/classes/sun/nio/fs/AbstractPoller.java ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java ! src/java.base/share/classes/sun/reflect/misc/MethodUtil.java ! src/java.base/share/classes/sun/security/pkcs/PKCS7.java ! src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/java.base/share/classes/sun/security/provider/SHA.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java ! src/java.base/share/classes/sun/security/provider/certpath/ConstraintsChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/java.base/share/classes/sun/security/provider/certpath/KeyChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/PolicyChecker.java ! src/java.base/share/classes/sun/security/ssl/CertificateMessage.java ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java ! src/java.base/share/classes/sun/security/util/DerOutputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java ! src/java.base/share/classes/sun/security/util/ECKeySizeParameterSpec.java ! src/java.base/share/classes/sun/security/util/SignatureUtil.java ! src/java.base/share/classes/sun/security/validator/EndEntityChecker.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/classes/sun/security/x509/X500Name.java ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/locale/InternalLocaleBuilder.java ! src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/java.base/share/conf/security/java.security ! src/java.base/share/data/lsrdata/language-subtag-registry.txt ! src/java.base/share/lib/security/default.policy ! src/java.base/share/man/java.1 + src/java.base/share/native/libjava/ContinuationSupport.c ! src/java.base/share/native/libjava/PreviewFeatures.c ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/parse_manifest.c ! src/java.base/unix/classes/java/lang/ProcessEnvironment.java ! src/java.base/unix/classes/java/lang/ProcessImpl.java ! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java ! src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/java.base/unix/native/libjli/java_md.c ! src/java.base/unix/native/libjli/java_md_common.c ! src/java.base/unix/native/libnio/ch/FileChannelImpl.c ! src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/java.base/windows/native/libnio/ch/FileChannelImpl.c ! src/java.base/windows/native/libnio/ch/wepoll.c ! src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java ! src/java.compiler/share/classes/javax/annotation/processing/package-info.java ! src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java ! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java ! src/java.compiler/share/classes/javax/lang/model/element/package-info.java ! src/java.compiler/share/classes/javax/lang/model/package-info.java ! src/java.compiler/share/classes/javax/lang/model/type/package-info.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/package-info.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibleText.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLRenderQueue.m ! src/java.desktop/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/ReaderUtil.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageReaderSpi.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/java.desktop/share/classes/java/awt/SystemTray.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/java.desktop/share/classes/javax/sound/midi/Track.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioInputStream.java ! src/java.desktop/share/classes/javax/swing/TablePrintable.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/java.desktop/share/classes/sun/awt/ExtendedKeyCodes.java ! src/java.desktop/unix/classes/sun/awt/PlatformGraphicsInfo.java ! src/java.desktop/unix/native/common/awt/CUPSfuncs.c ! src/java.desktop/unix/native/common/awt/X11Color.c ! src/java.desktop/unix/native/common/awt/awt.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java ! src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java ! src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h ! src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp ! src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.h ! src/java.instrument/share/classes/java/lang/instrument/package-info.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.logging/share/classes/java/util/logging/XMLFormatter.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/HashedPasswordManager.java ! src/java.management/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/ThreadInfo.java ! src/java.management/share/classes/javax/management/AttributeValueExp.java ! src/java.management/share/classes/javax/management/NotificationBroadcasterSupport.java ! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/java.management/share/classes/javax/management/openmbean/ArrayType.java ! src/java.management/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/java.management/share/classes/javax/management/openmbean/CompositeType.java ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanConstructorInfoSupport.java ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanOperationInfoSupport.java ! src/java.management/share/classes/javax/management/openmbean/OpenType.java ! src/java.management/share/classes/javax/management/openmbean/SimpleType.java ! src/java.management/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/java.management/share/classes/javax/management/openmbean/TabularType.java ! src/java.management/share/classes/javax/management/relation/RelationNotification.java ! src/java.management/share/classes/javax/management/relation/RelationService.java ! src/java.management/share/classes/javax/management/relation/RelationSupport.java ! src/java.management/share/classes/sun/management/MappedMXBeanType.java ! src/java.management/share/classes/sun/management/ThreadImpl.java ! src/java.management/share/classes/sun/management/Util.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapAttribute.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapName.java ! src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/PoolCallback.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/AtomicDirContext.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/ComponentDirContext.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/java.naming/share/classes/javax/naming/NameImpl.java ! src/java.naming/share/classes/javax/naming/directory/BasicAttributes.java ! src/java.naming/share/classes/javax/naming/directory/InitialDirContext.java ! src/java.net.http/share/classes/java/net/http/HttpClient.java ! src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientBuilderImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java ! src/java.net.http/share/classes/jdk/internal/net/http/websocket/OpeningHandshake.java ! src/java.prefs/windows/classes/java/util/prefs/WindowsPreferences.java ! src/java.rmi/share/classes/java/rmi/MarshalledObject.java ! src/java.rmi/share/classes/java/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoaderSpi.java ! src/java.rmi/share/classes/sun/rmi/log/LogHandler.java ! src/java.rmi/share/classes/sun/rmi/log/LogInputStream.java ! src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java ! src/java.rmi/share/classes/sun/rmi/transport/GC.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java ! src/java.scripting/share/classes/javax/script/SimpleScriptContext.java ! src/java.se/share/data/jdwp/jdwp.spec ! src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/EncryptionKey.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosCredMessage.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosKey.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/java.security.jgss/share/classes/org/ietf/jgss/ChannelBinding.java ! src/java.security.jgss/share/classes/org/ietf/jgss/GSSContext.java ! src/java.security.jgss/share/classes/org/ietf/jgss/GSSCredential.java ! src/java.security.jgss/share/classes/org/ietf/jgss/GSSException.java ! src/java.security.jgss/share/classes/org/ietf/jgss/GSSManager.java ! src/java.security.jgss/share/classes/org/ietf/jgss/GSSName.java ! src/java.security.jgss/share/classes/org/ietf/jgss/Oid.java ! src/java.security.jgss/share/classes/org/ietf/jgss/package-info.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSCaller.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSExceptionImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSHeader.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java ! src/java.security.jgss/share/classes/sun/security/jgss/JgssExtender.java ! src/java.security.jgss/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/java.security.jgss/share/classes/sun/security/jgss/ProviderList.java ! src/java.security.jgss/share/classes/sun/security/jgss/SunProvider.java ! src/java.security.jgss/share/classes/sun/security/jgss/TokenTracker.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5CredElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/MicToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/MicToken_v2.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/WrapToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/WrapToken_v2.java ! src/java.security.jgss/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/java.security.jgss/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/java.security.jgss/share/classes/sun/security/jgss/spi/GSSNameSpi.java ! src/java.security.jgss/share/classes/sun/security/jgss/spi/MechanismFactory.java ! src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenInit.java ! src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java ! src/java.security.jgss/share/classes/sun/security/jgss/spnego/SpNegoToken.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSLibStub.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/Krb5Util.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSFactory.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java ! src/java.security.jgss/share/classes/sun/security/krb5/Config.java ! src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/EncASRepPart.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCCacheConstants.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/MemoryCredentialsCache.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/Tag.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/util/KrbDataOutputStream.java ! src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/java.security.jgss/windows/native/libw2k_lsa_auth/NativeCreds.c ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/ChannelImpl.java ! src/java.smartcardio/unix/legal/pcsclite.md ! src/java.smartcardio/unix/native/libj2pcsc/MUSCLE/pcsclite.h ! src/java.smartcardio/unix/native/libj2pcsc/MUSCLE/winscard.h ! src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/java.sql.rowset/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/java.sql.rowset/share/classes/com/sun/rowset/providers/RIOptimisticProvider.java ! src/java.sql.rowset/share/classes/com/sun/rowset/providers/RIXMLProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/java.sql/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/java.transaction.xa/share/classes/javax/transaction/xa/XAException.java ! src/java.transaction.xa/share/classes/javax/transaction/xa/XAResource.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/java.xml/share/classes/com/sun/java_cup/internal/runtime/lr_parser.java ! src/java.xml/share/classes/com/sun/java_cup/internal/runtime/virtual_parse_stack.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDecl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSet.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/XPath.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/axes/PredicatedNodeTest.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/XPathParser.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtFunction.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPVariableStack.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFragSelectWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityReader.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLInputFactoryImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/DTDGrammarUtil.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/CharacterEvent.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/EntityDeclarationImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/ProcessingInstructionEvent.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/events/XMLEventFactoryImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/WriterUtility.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLWriter.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.java ! src/java.xml/share/classes/javax/xml/parsers/DocumentBuilder.java ! src/java.xml/share/classes/javax/xml/parsers/SAXParser.java ! src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java ! src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java ! src/java.xml/share/classes/javax/xml/stream/XMLStreamWriter.java ! src/java.xml/share/classes/javax/xml/stream/events/EntityDeclaration.java ! src/java.xml/share/classes/javax/xml/transform/OutputKeys.java ! src/java.xml/share/classes/javax/xml/transform/Transformer.java ! src/java.xml/share/classes/javax/xml/transform/TransformerException.java ! src/java.xml/share/classes/javax/xml/transform/TransformerFactory.java ! src/java.xml/share/classes/javax/xml/transform/dom/DOMResult.java ! src/java.xml/share/classes/javax/xml/transform/dom/DOMSource.java ! src/java.xml/share/classes/javax/xml/transform/overview.html ! src/java.xml/share/classes/javax/xml/validation/TypeInfoProvider.java ! src/java.xml/share/classes/javax/xml/validation/package-info.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactoryFinder.java ! src/java.xml/share/classes/javax/xml/xpath/package-info.java ! src/java.xml/share/classes/jdk/xml/internal/JdkXmlUtils.java ! src/java.xml/share/classes/org/w3c/dom/CDATASection.java ! src/java.xml/share/classes/org/w3c/dom/ls/LSParser.java ! src/java.xml/share/classes/org/xml/sax/HandlerBase.java ! src/java.xml/share/classes/org/xml/sax/ext/EntityResolver2.java ! src/java.xml/share/legal/xerces.md ! src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java ! src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java + src/jdk.compiler/share/classes/com/sun/source/tree/ConstantCaseLabelTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/DeconstructionPatternTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ExpressionTree.java - src/jdk.compiler/share/classes/com/sun/source/tree/GuardedPatternTree.java + src/jdk.compiler/share/classes/com/sun/source/tree/PatternCaseLabelTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java ! src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavacToolProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Assert.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/dependencies/NewDependencyCollector.java ! src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java ! src/jdk.compiler/share/classes/module-info.java + src/jdk.compiler/share/data/symbols/java.base-J.sym.txt + src/jdk.compiler/share/data/symbols/java.compiler-J.sym.txt + src/jdk.compiler/share/data/symbols/java.datatransfer-J.sym.txt + src/jdk.compiler/share/data/symbols/java.desktop-J.sym.txt + src/jdk.compiler/share/data/symbols/java.instrument-J.sym.txt + src/jdk.compiler/share/data/symbols/java.logging-J.sym.txt + src/jdk.compiler/share/data/symbols/java.management-J.sym.txt + src/jdk.compiler/share/data/symbols/java.management.rmi-J.sym.txt + src/jdk.compiler/share/data/symbols/java.naming-J.sym.txt + src/jdk.compiler/share/data/symbols/java.net.http-J.sym.txt + src/jdk.compiler/share/data/symbols/java.rmi-J.sym.txt + src/jdk.compiler/share/data/symbols/java.scripting-J.sym.txt + src/jdk.compiler/share/data/symbols/java.security.jgss-J.sym.txt + src/jdk.compiler/share/data/symbols/java.security.sasl-J.sym.txt + src/jdk.compiler/share/data/symbols/java.smartcardio-J.sym.txt + src/jdk.compiler/share/data/symbols/java.sql-J.sym.txt + src/jdk.compiler/share/data/symbols/java.sql.rowset-J.sym.txt + src/jdk.compiler/share/data/symbols/java.xml-J.sym.txt + src/jdk.compiler/share/data/symbols/java.xml.crypto-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.accessibility-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.attach-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.compiler-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.dynalink-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.httpserver-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.incubator.vector-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jartool-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.javadoc-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jconsole-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jdi-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jfr-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jshell-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jsobject-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.management-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.management.agent-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.net-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.sctp-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.security.auth-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.security.jgss-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.unsupported-J.sym.txt + src/jdk.compiler/share/data/symbols/jdk.xml.dom-J.sym.txt ! src/jdk.compiler/share/data/symbols/symbols ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11RuntimeException.java ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_general.c ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sessmgmt.c ! src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c ! src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/p11_md.c ! src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/p11_md.h ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECKeyFactory.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp ! src/jdk.hotspot.agent/doc/transported_core.html ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.h ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c ! src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c ! src/jdk.hotspot.agent/share/classes/com/sun/java/swing/action/OkAction.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/DebugServer.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/PageCache.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/SharedObject.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/SharedObject.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/posix/elf/ELFHashTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/posix/elf/ELFProgramHeader.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/posix/elf/ELFSymbol.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc/SharedObject.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/win32/coff/DebugVC50SymbolIterator.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/MemRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThreadState.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/NativeSignatureIterator.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux/LinuxSignals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_x86/LinuxSignals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/posix/POSIXSignals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/ObjectHistogramPanel.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/action/ThreadInfoAction.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/table/SortHeaderMouseAdapter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/treetable/AbstractTreeTableModel.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/treetable/JTreeTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/treetable/TreeTableModel.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/RBTree.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/StreamMonitor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/WorkerThread.java ! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpContext.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java + src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructureViolationException.java + src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java + src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/package-info.java + src/jdk.incubator.concurrent/share/classes/module-info.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorIntrinsics.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorSpecies.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/package-info.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVm.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBufferPrologue.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/MonitoredHostProvider.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBufferPrologue.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/TerminalBuilder.java ! src/jdk.internal.le/share/legal/jline.md ! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/WindowsAnsiWriter.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java ! src/jdk.jartool/share/classes/sun/tools/jar/JarToolProvider.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkInfo.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NewAPIListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableHeader.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/BodyContents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ContentBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery-ui.overrides.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.min.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.structure.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.structure.min.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Content.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/DocletElement.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Messages.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PackageSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ParamTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ReturnTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ThrowsTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ClassTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ClassUseMapper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Messages.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocToolProvider.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ColumnFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jconsole/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/Plotter.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/Main.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Main.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java ! src/jdk.jdi/share/classes/com/sun/jdi/Location.java ! src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java ! src/jdk.jdi/share/classes/com/sun/jdi/VMMismatchException.java ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java ! src/jdk.jdi/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/jdk.jdi/share/classes/com/sun/jdi/event/Event.java ! src/jdk.jdi/share/classes/com/sun/jdi/event/EventSet.java ! src/jdk.jdi/share/classes/com/sun/jdi/request/EventRequest.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/Packet.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SDE.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketConnection.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VMModifiers.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi.properties ! src/jdk.jdi/share/man/jdb.1 ! src/jdk.jdi/share/native/libdt_shmem/shmemBase.c ! src/jdk.jdi/share/native/libdt_shmem/shmemBase.h ! src/jdk.jdi/windows/classes/com/sun/tools/jdi/SharedMemoryConnection.java ! src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c ! src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c ! src/jdk.jdwp.agent/share/native/libjdwp/SDE.c ! src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c ! src/jdk.jdwp.agent/share/native/libjdwp/debugDispatch.c ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ! src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h ! src/jdk.jfr/share/classes/jdk/jfr/AnnotationElement.java ! src/jdk.jfr/share/classes/jdk/jfr/EventFactory.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveSettingEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/ASMToolkit.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/AnnotationConstruct.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/ChunksChannel.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Control.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataDescriptor.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataLoader.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataReader.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SettingsManager.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkHeader.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ConstantLookup.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/FinishedStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ParserFactory.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/ConstructorTracerWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/ConstructorWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Configure.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Filters.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Main.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Scrub.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/StructuredWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Summary.java ! src/jdk.jlink/linux/classes/jdk/tools/jlink/internal/plugins/StripNativeDebugSymbolsPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PerfectHashBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PostProcessor.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java ! src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/macosx/native/applauncher/MacLauncher.cpp ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageBundler.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/BundleParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/I18N.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/JPackageToolProvider.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/OverridableResource.java + src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackageFile.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java ! src/jdk.jpackage/share/native/applauncher/AppLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.h ! src/jdk.jpackage/share/native/applauncher/CfgFile.cpp + src/jdk.jpackage/share/native/applauncher/PackageFile.cpp + src/jdk.jpackage/share/native/applauncher/PackageFile.h ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WindowsAppImageBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/overrides.wxi ! src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp ! src/jdk.jpackage/windows/native/common/Resources.cpp ! src/jdk.jpackage/windows/native/common/WinSysInfo.cpp ! src/jdk.jpackage/windows/native/libjpackage/WindowsRegistry.cpp ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! src/jdk.jshell/share/classes/jdk/jshell/Diag.java ! src/jdk.jshell/share/classes/jdk/jshell/DiagList.java ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteCodes.java ! src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java ! src/jdk.jstatd/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java ! src/jdk.management.agent/windows/native/libmanagement_agent/FileSystemImpl.c ! src/jdk.management/share/classes/com/sun/management/internal/HotSpotDiagnostic.java ! src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c ! src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java ! src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/ElementCSSInlineStyle.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java ! src/jdk.zipfs/share/classes/module-info.java ! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java ! test/failure_handler/src/share/conf/mac.properties ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/gtest/code/test_codestrings.cpp ! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp ! test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp ! test/hotspot/gtest/gtestMain.cpp ! test/hotspot/gtest/logging/test_logStream.cpp + test/hotspot/gtest/opto/test_compress_expand_bits.cpp + test/hotspot/gtest/unittest.cpp ! test/hotspot/gtest/unittest.hpp ! test/hotspot/gtest/utilities/test_bitMap.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.ROOT ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/compiler/c2/TestRemoveMemBarPrecEdge.java + test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java ! test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java + test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java + test/hotspot/jtreg/compiler/ciTypeFlow/TestSharedLoopHead.java ! test/hotspot/jtreg/compiler/compilercontrol/share/scenario/JcmdCommand.java - test/hotspot/jtreg/compiler/integerArithmetic/TestDivision.java + test/hotspot/jtreg/compiler/intrinsics/TestBitShuffleOpers.java + test/hotspot/jtreg/compiler/intrinsics/TestDoubleClassCheck.java + test/hotspot/jtreg/compiler/intrinsics/TestFloatClassCheck.java + test/hotspot/jtreg/compiler/jsr292/NullConstantMHReceiver.java ! test/hotspot/jtreg/compiler/jsr292/cr8026328/libTest8026328.c ! test/hotspot/jtreg/compiler/jvmci/errors/TestInvalidDebugInfo.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java ! test/hotspot/jtreg/compiler/lib/ir_framework/Test.java ! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/AbstractLine.java + test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/Block.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/BlockLine.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/BlockOutputReader.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/HotSpotPidFileParser.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/Line.java + test/hotspot/jtreg/compiler/loopopts/TestMaxLoopOptsCountReached.java + test/hotspot/jtreg/compiler/loopopts/TestOverUnrolling2.java + test/hotspot/jtreg/compiler/loopopts/TestPeelingSkeletonPredicateInitialization.java + test/hotspot/jtreg/compiler/loopopts/superword/TestHoistedReductionNode.java ! test/hotspot/jtreg/compiler/oracle/CheckCompileCommandOption.java + test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckCmpUOverflow.java + test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckCmpUUnderflow.java + test/hotspot/jtreg/compiler/types/TestEACheckCastPP.java ! test/hotspot/jtreg/compiler/unsafe/TestLoopUnswitching.java ! test/hotspot/jtreg/compiler/vectorapi/TestIntrinsicBailOut.java ! test/hotspot/jtreg/compiler/vectorapi/TestVectorErgonomics.java ! test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java ! test/hotspot/jtreg/compiler/vectorapi/VectorRebracket128Test.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastAVX1.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastAVX2.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastAVX512.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastAVX512BW.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastAVX512DQ.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastNeon.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastSVE.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorReinterpret.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/tests/TestVectorDoubleExpandShrink.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/tests/TestVectorExpandShrink.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/VectorReshapeHelper.java ! test/hotspot/jtreg/compiler/vectorization/TestPopCountVectorLong.java + test/hotspot/jtreg/compiler/vectorization/TestPopulateIndex.java + test/hotspot/jtreg/compiler/vectorization/TestRotateByteAndShortVector.java + test/hotspot/jtreg/compiler/vectorization/TestSmallVectorPopIndex.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicShortOpTest.java ! test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java + test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java ! test/hotspot/jtreg/gc/stress/TestStressRSetCoarsening.java ! test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ! test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java ! test/hotspot/jtreg/runtime/Thread/StopAtExit.java ! test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java ! test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java ! test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java ! test/hotspot/jtreg/runtime/cds/appcds/TestSerialGCWithCDS.java + test/hotspot/jtreg/runtime/cds/appcds/VerifyObjArrayCloneTest.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/VerifyObjArrayCloneTest.java ! test/hotspot/jtreg/runtime/cds/appcds/redefineClass/RedefineRunningMethods_Shared.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/VerifyObjArrayCloneTestApp.java ! test/hotspot/jtreg/runtime/cds/serviceability/ReplaceCriticalClasses.java ! test/hotspot/jtreg/runtime/jni/FastGetField/libFastGetField.c + test/hotspot/jtreg/runtime/verifier/InvokeClone.java + test/hotspot/jtreg/runtime/verifier/InvokeCloneInvalid.jasm + test/hotspot/jtreg/runtime/verifier/InvokeCloneValid.jasm ! test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java ! test/hotspot/jtreg/serviceability/dcmd/thread/ThreadDumpToFileTest.java ! test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/libFieldAccessWatch.c ! test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.cpp ! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java ! test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorStackDepthInfo/GetOwnedMonitorStackDepthInfoTest.java ! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRunningMethodsWithBacktrace.java ! test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/breakpoint01.java ! test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/classload01.java ! test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/classprep01.java ! test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/exception01.java ! test/hotspot/jtreg/serviceability/jvmti/events/ExceptionCatch/excatch01/excatch01.java ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc01/fieldacc01.java ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc02/fieldacc02.java ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc03/fieldacc03.java ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc04/fieldacc04.java ! test/hotspot/jtreg/serviceability/jvmti/events/FieldModification/fieldmod01/fieldmod01.java ! test/hotspot/jtreg/serviceability/jvmti/events/FieldModification/fieldmod02/fieldmod02.java ! test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop01/framepop01.java ! test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/framepop02.java ! test/hotspot/jtreg/serviceability/jvmti/events/MethodEntry/mentry01/mentry01.java ! test/hotspot/jtreg/serviceability/jvmti/events/MethodEntry/mentry02/mentry02.java ! test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/mexit01/mexit01.java ! test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/mexit02/mexit02.java ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/mcontenter01.java ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEntered/mcontentered01/mcontentered01.java ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWait/monitorwait01/monitorwait01.java ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWaited/monitorwaited01/monitorwaited01.java ! test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/singlestep01.java ! test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep03/singlestep03.java ! test/hotspot/jtreg/serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java ! test/hotspot/jtreg/serviceability/jvmti/stress/StackTrace/Suspended/GetStackTraceSuspendedStressTest.java ! test/hotspot/jtreg/serviceability/jvmti/stress/ThreadLocalStorage/SetGetThreadLocalStorageStressTest/SetGetThreadLocalStorageStressTest.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon02/contmon02.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceCurrentThreadTest/GetStackTraceCurrentThreadTest.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr04/getstacktr04.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr05/getstacktr05.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr06/getstacktr06.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr07/getstacktr07.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr08/getstacktr08.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadInfo/thrinfo01/thrinfo01.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat01/thrstat01.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat03/thrstat03.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat05/thrstat05.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/BreakpointInYieldTest/BreakpointInYieldTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContFramePopTest/ContFramePopTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContYieldBreakPointTest/ContYieldBreakPointTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContinuationTest/ContinuationTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/GetSetLocalTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptThreadTest/InterruptThreadTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/MethodExitTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/NullAsCurrentThreadTest/NullAsCurrentThreadTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/PinnedTaskTest/PinnedTaskTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/RawMonitorTest/RawMonitorTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/RedefineClasses/RedefineRunningMethods.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResumeAll/SuspendResumeAll.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadMonitorTest/VThreadMonitorTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/VThreadTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadUnsupportedTest/VThreadUnsupportedTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/WaitNotifySuspendedVThreadTest/WaitNotifySuspendedVThreadTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAs.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompLevels.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestControls.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestScenarios.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/Utils.java ! test/hotspot/jtreg/vmTestbase/gc/gctests/WeakReference/weak006/weak006.java ! test/hotspot/jtreg/vmTestbase/gc/memory/Churn/Churn.README ! test/hotspot/jtreg/vmTestbase/jit/FloatingPoint/FPCompare/TestFPBinop/TestFPBinop.gold ! test/hotspot/jtreg/vmTestbase/jit/t/t047/t047.gold ! test/hotspot/jtreg/vmTestbase/jit/wide/wide01/wide01.java ! test/hotspot/jtreg/vmTestbase/jit/wide/wide02/wide02.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/resume/resume002/resume002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/threads/threads002/threads002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/isSuspended/issuspended004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses024.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass031/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass031/redefclass031.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/ji03t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h ! test/hotspot/jtreg/vmTestbase/vm/gc/concurrent/Concurrent.java ! test/hotspot/jtreg/vmTestbase/vm/share/options/test/ExampleWithNonprimitiveOptions.java ! test/jaxp/javax/xml/jaxp/functional/javax/xml/transform/ptests/TfClearParamTest.java ! test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/IsValidatingTest.java + test/jaxp/javax/xml/jaxp/unittest/validation/IDREFS_length006.xsd + test/jaxp/javax/xml/jaxp/unittest/validation/NMTOKENS_length006.xsd ! test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java ! test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExceptionTest.java ! test/jdk/ProblemList-Xcomp.txt ! test/jdk/ProblemList.txt ! test/jdk/TEST.ROOT ! test/jdk/TEST.groups ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/OutputSizeTest.java ! test/jdk/com/sun/crypto/provider/Cipher/PBE/DecryptWithoutParameters.java ! test/jdk/com/sun/jdi/JdbOptions.java ! test/jdk/com/sun/jdi/OomDebugTest.java ! test/jdk/com/sun/jdi/RedefineAbstractClass.java ! test/jdk/com/sun/jdi/RedefineClasses.java ! test/jdk/com/sun/jdi/VarargsTest.java - test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java ! test/jdk/com/sun/jdi/lib/jdb/JdbTest.java ! test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java ! test/jdk/java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java ! test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java + test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java ! test/jdk/java/awt/a11y/AccessibleActionsTest.java ! test/jdk/java/awt/a11y/AccessibleJTableTest.java + test/jdk/java/awt/dnd/DropTargetInInternalFrameTest.java ! test/jdk/java/awt/geom/Path2D/UnitTest.java ! test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java ! test/jdk/java/beans/XMLEncoder/Test4631471.java ! test/jdk/java/foreign/TestByteBuffer.java - test/jdk/java/foreign/TestDowncall.java + test/jdk/java/foreign/TestDowncallBase.java + test/jdk/java/foreign/TestDowncallScope.java + test/jdk/java/foreign/TestDowncallStack.java ! test/jdk/java/foreign/TestMemorySession.java ! test/jdk/java/foreign/TestMismatch.java ! test/jdk/java/foreign/TestNulls.java ! test/jdk/java/foreign/TestScopedOperations.java ! test/jdk/java/foreign/TestSegments.java ! test/jdk/java/foreign/TestSharedAccess.java ! test/jdk/java/foreign/TestSlices.java ! test/jdk/java/foreign/TestVarArgs.java ! test/jdk/java/foreign/callarranger/CallArrangerTestBase.java ! test/jdk/java/foreign/callarranger/TestAarch64CallArranger.java ! test/jdk/java/foreign/callarranger/TestSysVCallArranger.java ! test/jdk/java/foreign/callarranger/TestWindowsCallArranger.java ! test/jdk/java/foreign/channels/TestSocketChannels.java ! test/jdk/java/foreign/libAsyncInvokers.cpp ! test/jdk/java/foreign/libTestDowncall.c - test/jdk/java/foreign/libTestDowncall.h ! test/jdk/java/foreign/libTestDowncallStack.c ! test/jdk/java/foreign/libTestUpcall.c - test/jdk/java/foreign/libTestUpcall.h ! test/jdk/java/foreign/libTestUpcallStack.c ! test/jdk/java/foreign/libVarArgs.c + test/jdk/java/foreign/shared.h ! test/jdk/java/io/InputStreamReader/ReadCharBuffer.java ! test/jdk/java/io/RandomAccessFile/UnreferencedRAFClosesFd.java ! test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java - test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/NullCallerClassLoaderTest.java - test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/exeNullCallerClassLoaderTest.c ! test/jdk/java/lang/CompressExpandSanityTest.java ! test/jdk/java/lang/CompressExpandTest.java ! test/jdk/java/lang/ProcessBuilder/Basic.java ! test/jdk/java/lang/SecurityManager/CheckSecurityProvider.java ! test/jdk/java/lang/StackWalker/ReflectionFrames.java ! test/jdk/java/lang/String/concat/ImplicitStringConcatBoundaries.java ! test/jdk/java/lang/System/Logger/custom/CustomLoggerTest.java ! test/jdk/java/lang/System/Logger/default/DefaultLoggerTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/LoggerBridgeTest/LoggerBridgeTest.java ! test/jdk/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java ! test/jdk/java/lang/System/MacEncoding/TestFileEncoding.java + test/jdk/java/lang/System/i18nEnvArg.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java ! test/jdk/java/lang/Thread/virtual/GetStackTraceWhenRunnable.java ! test/jdk/java/lang/Thread/virtual/HoldsLock.java ! test/jdk/java/lang/Thread/virtual/JfrEvents.java ! test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java ! test/jdk/java/lang/Thread/virtual/Reflection.java ! test/jdk/java/lang/Thread/virtual/StackTraces.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java ! test/jdk/java/lang/Thread/virtual/ThreadBuilders.java ! test/jdk/java/lang/Thread/virtual/TracePinnedThreads.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALot.java ! test/jdk/java/lang/Thread/virtual/stress/Skynet.java ! test/jdk/java/lang/Thread/virtual/stress/SleepALot.java ! test/jdk/java/lang/Thread/virtual/stress/TimedGet.java ! test/jdk/java/lang/instrument/NoTransformerAddedTest.java ! test/jdk/java/lang/instrument/NullTransformerAddTest.java ! test/jdk/java/lang/instrument/NullTransformerRemoveTest.java ! test/jdk/java/lang/instrument/ParallelTransformerLoaderTest.java ! test/jdk/java/lang/instrument/PremainClass/README ! test/jdk/java/lang/invoke/AccessControlTest.java - test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/NullCallerLookupTest.java - test/jdk/java/lang/invoke/MethodHandles/exeNullCallerLookup/exeNullCallerLookupTest.c ! test/jdk/java/lang/invoke/lambda/LambdaAccessControlTest.java ! test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java ! test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java - test/jdk/java/lang/module/exeNullCallerGetResource/NullCallerGetResource.java - test/jdk/java/lang/module/exeNullCallerGetResource/exeNullCallerGetResource.c + test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java ! test/jdk/java/lang/templatedstring/Basic.java ! test/jdk/java/math/BigDecimal/SquareRootTests.java ! test/jdk/java/math/BigDecimal/StringConstructor.java ! test/jdk/java/net/InetAddress/ptr/Lookup.java ! test/jdk/java/net/InterfaceAddress/Equals.java ! test/jdk/java/net/Socket/SoTimeout.java ! test/jdk/java/net/Socks/SocksSocketImplTest.java ! test/jdk/java/net/URLConnection/contentHandler/COM/foo/content/text/plain.java + test/jdk/java/net/httpclient/ContentLengthHeaderTest.java + test/jdk/java/net/httpclient/ExpectContinueTest.java ! test/jdk/java/net/httpclient/HttpClientBuilderTest.java + test/jdk/java/net/httpclient/HttpClientLocalAddrTest.java ! test/jdk/java/net/httpclient/HttpServerAdapters.java ! test/jdk/java/net/httpclient/MessageHeadersTest.java ! test/jdk/java/net/httpclient/ReferenceTracker.java ! test/jdk/java/net/httpclient/TEST.properties ! test/jdk/java/net/httpclient/http2/PushPromiseContinuation.java ! test/jdk/java/net/httpclient/http2/server/Http2TestServer.java ! test/jdk/java/net/httpclient/http2/server/Http2TestServerConnection.java ! test/jdk/java/net/httpclient/http2/server/OutgoingPushPromise.java + test/jdk/java/net/httpclient/httpclient-localaddr-security.policy ! test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/IdentityProcessorVerification.java ! test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/SubscriberWhiteboxVerification.java ! test/jdk/java/net/httpclient/websocket/BlowupOutputQueue.java ! test/jdk/java/net/httpclient/websocket/PendingBinaryPingClose.java ! test/jdk/java/net/httpclient/websocket/PendingBinaryPongClose.java ! test/jdk/java/net/httpclient/websocket/PendingOperations.java ! test/jdk/java/net/httpclient/websocket/PendingPingBinaryClose.java ! test/jdk/java/net/httpclient/websocket/PendingPingTextClose.java ! test/jdk/java/net/httpclient/websocket/PendingPongBinaryClose.java ! test/jdk/java/net/httpclient/websocket/PendingPongTextClose.java ! test/jdk/java/net/httpclient/websocket/PendingTextPingClose.java ! test/jdk/java/net/httpclient/websocket/PendingTextPongClose.java ! test/jdk/java/net/vthread/BlockingSocketOps.java + test/jdk/java/nio/channels/FileChannel/LargeMapTest.java ! test/jdk/java/nio/channels/SocketChannel/ConnectState.java ! test/jdk/java/nio/channels/vthread/BlockingChannelOps.java + test/jdk/java/nio/file/Files/CopyToNonDefaultFS.java ! test/jdk/java/nio/file/Files/Misc.java ! test/jdk/java/nio/file/Files/ReadWriteString.java + test/jdk/java/nio/file/Files/copy.policy ! test/jdk/java/nio/file/Files/probeContentType/Basic.java ! test/jdk/java/security/SecureRandom/SerializedSeedTest.java ! test/jdk/java/security/Signature/ResetAfterException.java ! test/jdk/java/text/Format/common/FormatIteratorTest.java ! test/jdk/java/time/tck/java/time/chrono/TCKChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKTestServiceLoader.java ! test/jdk/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/jdk/java/time/test/java/time/chrono/TestServiceLoader.java + test/jdk/java/time/test/java/time/temporal/TestIsoFields.java ! test/jdk/java/time/test/java/time/temporal/TestIsoWeekFields.java ! test/jdk/java/util/Currency/PropertiesTest.sh ! test/jdk/java/util/HashMap/WhiteBoxResizeTest.java ! test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java ! test/jdk/java/util/Random/RandomNextDoubleBoundary.java - test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/NullCallerResourceBundle.java - test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/exeNullCallerResourceBundle.c ! test/jdk/java/util/TimeZone/TimeZoneTest.java + test/jdk/java/util/TimeZone/ZoneIdRoundTripTest.java + test/jdk/java/util/spi/ToolProviderDescriptionTest.java + test/jdk/javax/accessibility/4702233/AccessibleActionConstants.java + test/jdk/javax/accessibility/4702233/AccessibleContextConstants.java + test/jdk/javax/accessibility/4702233/AccessiblePropertiesTest.java + test/jdk/javax/accessibility/4702233/AccessibleRelationConstants.java + test/jdk/javax/accessibility/4702233/AccessibleRoleConstants.java + test/jdk/javax/accessibility/4702233/AccessibleStateConstants.java + test/jdk/javax/accessibility/AccessibleJTableSelectionTest.java + test/jdk/javax/accessibility/JRootPaneAccessiblAtTest.java + test/jdk/javax/accessibility/JScrollPaneAccessibleRelationsTest.java + test/jdk/javax/accessibility/JSlider/AccessibleAction/JSliderAccessibleAction.java + test/jdk/javax/imageio/plugins/gif/GIFLargeTableIndexTest.java + test/jdk/javax/imageio/plugins/shared/CanDecodeTest.java ! test/jdk/javax/imageio/plugins/wbmp/CanDecodeTest.java ! test/jdk/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java ! test/jdk/javax/security/auth/callback/PasswordCallback/CheckCleanerBound.java ! test/jdk/javax/sound/midi/Devices/ClosedReceiver.java ! test/jdk/javax/sound/midi/Devices/InitializationHang.java ! test/jdk/javax/sound/midi/Devices/MidiDeviceGetReceivers.java ! test/jdk/javax/sound/midi/Devices/MidiIO.java ! test/jdk/javax/sound/midi/Devices/MidiOutGetMicrosecondPositionBug.java ! test/jdk/javax/sound/midi/Devices/OpenClose.java ! test/jdk/javax/sound/midi/Devices/ReceiverTransmitterAvailable.java ! test/jdk/javax/sound/midi/Devices/Reopen.java ! test/jdk/javax/sound/midi/MidiSystem/DefaultDevices.java ! test/jdk/javax/sound/midi/MidiSystem/GetSequencer.java ! test/jdk/javax/sound/midi/Sequence/GetMicrosecondLength.java ! test/jdk/javax/sound/midi/Sequencer/LoopIAE.java ! test/jdk/javax/sound/midi/Sequencer/MetaCallback.java ! test/jdk/javax/sound/midi/Sequencer/Recording.java ! test/jdk/javax/sound/midi/Sequencer/SeqRecordDoesNotCopy.java ! test/jdk/javax/sound/midi/Sequencer/SeqRecordsRealTimeEvents.java ! test/jdk/javax/sound/midi/Sequencer/SeqStartRecording.java ! test/jdk/javax/sound/midi/Sequencer/SequencerCacheValues.java ! test/jdk/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java ! test/jdk/javax/sound/midi/Sequencer/SequencerSetMuteSolo.java ! test/jdk/javax/sound/midi/Sequencer/SequencerState.java ! test/jdk/javax/sound/midi/Sequencer/SetTickPosition.java ! test/jdk/javax/sound/midi/Sequencer/TickLength.java ! test/jdk/javax/sound/midi/Soundbanks/ExtraCharInSoundbank.java ! test/jdk/javax/sound/sampled/AudioSystem/DefaultMixers.java ! test/jdk/javax/sound/sampled/Clip/ClipCloseLoss.java ! test/jdk/javax/sound/sampled/Clip/ClipFlushCrash.java ! test/jdk/javax/sound/sampled/Clip/Drain/ClipDrain.java ! test/jdk/javax/sound/sampled/Clip/Duration/ClipDuration.java ! test/jdk/javax/sound/sampled/Clip/Endpoint/ClipSetEndPoint.java ! test/jdk/javax/sound/sampled/Controls/FloatControl/FloatControlBug.java ! test/jdk/javax/sound/sampled/DataLine/DataLineInfoNegBufferSize.java ! test/jdk/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java ! test/jdk/javax/sound/sampled/DataLine/LineDefFormat.java ! test/jdk/javax/sound/sampled/Lines/16and32KHz/Has16and32KHz.java ! test/jdk/javax/sound/sampled/Lines/BufferSizeCheck.java ! test/jdk/javax/sound/sampled/Lines/ChangingBuffer.java ! test/jdk/javax/sound/sampled/Lines/ClickInPlay/Test4218609.java ! test/jdk/javax/sound/sampled/Lines/ClipOpenException.java ! test/jdk/javax/sound/sampled/Lines/FrameSize/FrameSizeTest.java ! test/jdk/javax/sound/sampled/Lines/SDLwrite.java ! test/jdk/javax/sound/sampled/Lines/SourceDataLineDefaultBufferSizeCrash.java ! test/jdk/javax/sound/sampled/Lines/StopStart.java ! test/jdk/javax/sound/sampled/LinuxBlock/PlaySine.java ! test/jdk/javax/sound/sampled/LinuxCrash/ClipLinuxCrash.java ! test/jdk/javax/sound/sampled/LinuxCrash/ClipLinuxCrash2.java ! test/jdk/javax/sound/sampled/LinuxCrash/SDLLinuxCrash.java ! test/jdk/javax/sound/sampled/Mixers/BogusMixers.java ! test/jdk/javax/sound/sampled/Mixers/BothEndiansAndSigns.java ! test/jdk/javax/sound/sampled/Mixers/DirectSoundRepeatingBuffer/Test4997635.java ! test/jdk/javax/sound/sampled/Mixers/DirectSoundUnderrunSilence/Test5032020.java ! test/jdk/javax/sound/sampled/Mixers/NoSimpleInputDevice.java ! test/jdk/javax/sound/sampled/Mixers/PhantomMixers.java ! test/jdk/javax/sound/sampled/Mixers/PlugHwMonoAnd8bitAvailable.java ! test/jdk/javax/sound/sampled/Mixers/UnexpectedIAE.java ! test/jdk/javax/sound/sampled/Recording/TargetDataLineFlush.java ! test/jdk/javax/sound/sampled/spi/MixerProvider/ExpectedNPEOnNull.java ! test/jdk/javax/sql/testng/test/rowset/serial/SerialClobTests.java ! test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java ! test/jdk/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java + test/jdk/javax/swing/JRadioButton/bug4380543.java + test/jdk/javax/swing/JTable/PrintAllPagesTest.java + test/jdk/javax/swing/JTableHeader/TableHeaderRendererTest.java + test/jdk/javax/swing/JToolTip/bug5047379.java ! test/jdk/javax/swing/border/TestTitledBorderLeak.java ! test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java + test/jdk/jdk/incubator/concurrent/StructuredTaskScope/PreviewFeaturesNotEnabled.java + test/jdk/jdk/incubator/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java + test/jdk/jdk/incubator/concurrent/StructuredTaskScope/StructuredThreadDumpTest.java ! test/jdk/jdk/incubator/vector/AbstractVectorLoadStoreTest.java ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/VectorReshapeTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh ! test/jdk/jdk/incubator/vector/gen-tests.sh ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-Scalar-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Broadcast.template ! test/jdk/jdk/incubator/vector/templates/Unit-Compare-Broadcast.template ! test/jdk/jdk/incubator/vector/templates/Unit-Compare-Masked.template ! test/jdk/jdk/incubator/vector/templates/Unit-Compare.template + test/jdk/jdk/incubator/vector/templates/Unit-CompressExpand.template ! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-Scalar-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Single-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Scalar-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Test.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Zero.template ! test/jdk/jdk/incubator/vector/templates/Unit-footer.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template ! test/jdk/jdk/internal/math/FloatingDecimal/OldFloatingDecimalForTest.java + test/jdk/jdk/internal/math/ToDecimal/DoubleToDecimalTest.java + test/jdk/jdk/internal/math/ToDecimal/FloatToDecimalTest.java + test/jdk/jdk/internal/math/ToDecimal/MathUtilsTest.java + test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/BasicChecker.java + test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/DoubleToDecimalChecker.java + test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/FloatToDecimalChecker.java + test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/MathUtilsChecker.java + test/jdk/jdk/internal/math/ToDecimal/java.base/jdk/internal/math/ToDecimalChecker.java ! test/jdk/jdk/internal/misc/Unsafe/CopyCommon.java ! test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java ! test/jdk/jdk/internal/vm/Continuation/Basic.java ! test/jdk/jdk/internal/vm/Continuation/ClassUnloading.java ! test/jdk/jdk/internal/vm/Continuation/Fuzz.java ! test/jdk/jdk/internal/vm/Continuation/HumongousStack.java ! test/jdk/jdk/internal/vm/Continuation/LiveFramesDriver.java ! test/jdk/jdk/internal/vm/Continuation/Scoped.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnEvent.java + test/jdk/jdk/jfr/api/recording/dump/TestDumpDevNull.java ! test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java ! test/jdk/jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java ! test/jdk/jdk/jfr/event/runtime/TestThreadEndEvent.java ! test/jdk/jdk/jfr/event/runtime/TestThreadSleepEvent.java ! test/jdk/jdk/jfr/event/runtime/TestThreadStartEvent.java ! test/jdk/jdk/jfr/event/runtime/TestVirtualThreadEndEvent.java ! test/jdk/jdk/jfr/event/runtime/TestVirtualThreadStartEvent.java ! test/jdk/jdk/jfr/jmx/streaming/TestClose.java ! test/jdk/jdk/jfr/jvm/TestThreadExclusion.java ! test/jdk/jdk/jfr/jvm/TestVirtualThreadExclusion.java ! test/jdk/jdk/jfr/threading/TestDeepVirtualStackTrace.java ! test/jdk/jdk/jfr/threading/TestManyVirtualThreads.java ! test/jdk/jdk/jfr/threading/TestNestedVirtualThreads.java - test/jdk/jdk/jfr/tool/JSONValue.java ! test/jdk/jdk/jfr/tool/TestPrintJSON.java ! test/jdk/jdk/jfr/tool/TestScrub.java ! test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java ! test/jdk/jdk/nio/zipfs/testng/util/ZipFsBaseTest.java + test/jdk/jni/nullCaller/CallHelper.hpp + test/jdk/jni/nullCaller/NullCallerTest.java + test/jdk/jni/nullCaller/exeNullCallerTest.cpp = test/jdk/jni/nullCaller/src/n/closed/ClosedResources.java + test/jdk/jni/nullCaller/src/n/closed/test.txt = test/jdk/jni/nullCaller/src/n/module-info.java + test/jdk/jni/nullCaller/src/n/open/NullCallerResource.properties = test/jdk/jni/nullCaller/src/n/open/OpenResources.java + test/jdk/jni/nullCaller/src/n/open/test.txt ! test/jdk/performance/client/RenderPerfTest/Makefile ! test/jdk/performance/client/RenderPerfTest/build.xml - test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfLCDTest.java ! test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java ! test/jdk/sanity/client/SwingSet/src/ScrollPaneDemoTest.java ! test/jdk/sanity/client/lib/Extensions/src/org/jemmy2ext/JemmyExt.java ! test/jdk/sun/java2d/cmm/ColorConvertOp/MTPerLineTransformValidation.java ! test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java + test/jdk/sun/security/ec/SignatureParameters.java ! test/jdk/sun/security/jgss/GssContextCleanup.java ! test/jdk/sun/security/jgss/GssNameCleanup.java ! test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java + test/jdk/sun/security/mscapi/AllTypes.java + test/jdk/sun/security/ssl/SSLCipher/ReadOnlyEngine.java ! test/jdk/sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java - test/jdk/sun/security/ssl/X509TrustManagerImpl/Symantec/appleistca2g1-chain.pem - test/jdk/sun/security/ssl/X509TrustManagerImpl/Symantec/geotrustglobalca-chain.pem ! test/jdk/sun/security/tools/jarsigner/OldSig.java + test/jdk/sun/security/tools/keytool/EmptyField.java ! test/jdk/sun/security/tools/keytool/WeakSecretKeyTest.java + test/jdk/sun/security/x509/AlgorithmId/PBES2.java ! test/jdk/sun/util/locale/provider/Bug8038436.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Functional.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherIconVerifier.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java ! test/jdk/tools/jpackage/junit/jdk/jpackage/internal/AppImageFileTest.java + test/jdk/tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java + test/jdk/tools/jpackage/macosx/MacAppStoreRuntimeTest.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java + test/jdk/tools/jpackage/macosx/SigningAppImageTwoStepsTest.java ! test/jdk/tools/jpackage/run_tests.sh ! test/jdk/tools/jpackage/share/AddLShortcutTest.java ! test/jdk/tools/jpackage/share/AddLauncherTest.java ! test/jdk/tools/jpackage/share/AppContentTest.java ! test/jdk/tools/jpackage/share/ArgumentsTest.java ! test/jdk/tools/jpackage/share/IconTest.java ! test/jdk/tools/jpackage/share/MultiLauncherTwoPhaseTest.java ! test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java + test/jdk/tools/jpackage/share/PerUserCfgTest.java ! test/jdk/tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java + test/jdk/tools/jpackage/share/jdk/jpackage/tests/PredefinedAppImageErrorTest.java ! test/jdk/tools/launcher/SourceMode.java ! test/jdk/tools/launcher/TooSmallStackSize.java ! test/jtreg-ext/requires/VMProps.java ! test/langtools/ProblemList.txt ! test/langtools/TEST.ROOT ! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testAuthor/TestAuthor.java ! test/langtools/jdk/javadoc/doclet/testDocletExample/TestDocletExample.java + test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java ! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlDocument/TestHtmlDocument.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewApiList/TestNewApiList.java ! test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestAnnotation.java ! test/langtools/jdk/javadoc/doclet/testNewApiList/mdl/pkg/TestClass.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSimpleTagInherit/TestSimpleTagInherit.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetUnnamedPackage.java ! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java ! test/langtools/jdk/javadoc/doclet/testVersionTag/TestVersionTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java ! test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java ! test/langtools/jdk/javadoc/tool/doclint/DocLintTest.java ! test/langtools/jdk/jshell/ClassesTest.java ! test/langtools/jdk/jshell/CompletionSuggestionTest.java ! test/langtools/jdk/jshell/ErrorRecoveryTest.java ! test/langtools/jdk/jshell/ToolEnablePreviewTest.java + test/langtools/tools/EnumAccessible.java ! test/langtools/tools/doclint/EmptyDescriptionTest.out ! test/langtools/tools/javac/ConditionalExpressionResolvePending.java ! test/langtools/tools/javac/Paths/Util.sh + test/langtools/tools/javac/T8286057.java + test/langtools/tools/javac/T8286057.out + test/langtools/tools/javac/T8286797.java + test/langtools/tools/javac/T8286797.out ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/Patterns.java ! test/langtools/tools/javac/api/T6838467.java ! test/langtools/tools/javac/api/TestGetSourceVersions.java ! test/langtools/tools/javac/api/snippets/TestJavaxToolsSnippets.java ! test/langtools/tools/javac/classfiles/ClassVersionChecker.java ! test/langtools/tools/javac/classfiles/attributes/LineNumberTable/RuleSwitchBreaks.java ! test/langtools/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/langtools/tools/javac/diags/examples/DeconstructionPatternOnlyRecords.java - test/langtools/tools/javac/diags/examples/DuplicateTotalPattern.java + test/langtools/tools/javac/diags/examples/DuplicateUnconditionalPattern.java + test/langtools/tools/javac/diags/examples/EnumsCantBeGeneric.java + test/langtools/tools/javac/diags/examples/FeatureUnconditionalPatternsInInstanceof.java + test/langtools/tools/javac/diags/examples/GuardHasConstantFalse.java + test/langtools/tools/javac/diags/examples/IncorrectNumberOfNestedPatterns.java + test/langtools/tools/javac/diags/examples/NotApplicableTypes.java + test/langtools/tools/javac/diags/examples/RawDeconstructionPattern.java - test/langtools/tools/javac/diags/examples/TotalPatternAndDefault.java + test/langtools/tools/javac/diags/examples/UnconditionalPatternAndDefault.java ! test/langtools/tools/javac/file/LimitedImage.java + test/langtools/tools/javac/lambda/SerializableObjectMethods.java ! test/langtools/tools/javac/lambda/deduplication/Deduplication.java ! test/langtools/tools/javac/lambda/deduplication/DeduplicationTest.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/langtools/tools/javac/modules/T8168854/module-info.java ! test/langtools/tools/javac/patterns/CaseStructureTest.java + test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java + test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out ! test/langtools/tools/javac/patterns/DisambiguatePatterns.java ! test/langtools/tools/javac/patterns/Domination.java + test/langtools/tools/javac/patterns/EmptyRecordClass.java ! test/langtools/tools/javac/patterns/EnumTypeChanges.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java + test/langtools/tools/javac/patterns/GenericRecordDeconstructionPattern.java ! test/langtools/tools/javac/patterns/Guards.java ! test/langtools/tools/javac/patterns/GuardsErrors.java ! test/langtools/tools/javac/patterns/GuardsErrors.out + test/langtools/tools/javac/patterns/InstanceofTotalPattern-15.out + test/langtools/tools/javac/patterns/InstanceofTotalPattern-16.out + test/langtools/tools/javac/patterns/InstanceofTotalPattern-preview.out + test/langtools/tools/javac/patterns/InstanceofTotalPattern.java + test/langtools/tools/javac/patterns/NestedDeconstructionPattern.java ! test/langtools/tools/javac/patterns/NestedPatternVariablesBytecode.java + test/langtools/tools/javac/patterns/NestedPrimitiveDeconstructionPattern.java ! test/langtools/tools/javac/patterns/NullSwitch.java + test/langtools/tools/javac/patterns/NullsInDeconstructionPatterns.java = test/langtools/tools/javac/patterns/NullsInDeconstructionPatterns.out ! test/langtools/tools/javac/patterns/Parenthesized.java + test/langtools/tools/javac/patterns/PrettyTest.java ! test/langtools/tools/javac/patterns/RawTypeBindingWarning.java ! test/langtools/tools/javac/patterns/RawTypeBindingWarning.out ! test/langtools/tools/javac/patterns/SealedTypeChanges.java ! test/langtools/tools/javac/patterns/SimpleAndGuardPattern.java + test/langtools/tools/javac/patterns/SimpleDeconstructionPattern.java + test/langtools/tools/javac/patterns/SimpleDeconstructionPatternNoPreview.out ! test/langtools/tools/javac/patterns/SwitchErrors.java ! test/langtools/tools/javac/patterns/SwitchErrors.out ! test/langtools/tools/javac/patterns/Switches.java + test/langtools/tools/javac/patterns/TypedDeconstructionPatternExc.java + test/langtools/tools/javac/patterns/VarErrors.java + test/langtools/tools/javac/patterns/VarErrors.out ! test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out ! test/langtools/tools/javac/preview/classReaderTest/Client.preview.out ! test/langtools/tools/javac/processing/warnings/au_8.out ! test/langtools/tools/javac/processing/warnings/au_current.out + test/langtools/tools/javac/recovery/NoCrashForError.java + test/langtools/tools/javac/recovery/NoCrashForError.out ! test/langtools/tools/javac/sealed/BinaryCompatibilityTests.java + test/langtools/tools/javac/switchexpr/SwitchExpressionNoValue.java ! test/langtools/tools/javac/switchextra/RuleParsingTest.java ! test/langtools/tools/javac/sym/ElementStructureTest.java ! test/langtools/tools/javac/tree/SourceTreeScannerTest.java ! test/langtools/tools/javac/versions/Versions.java ! test/langtools/tools/lib/builder/ClassBuilder.java ! test/langtools/tools/lib/snippets/SnippetUtils.java ! test/langtools/tools/lib/toolbox/JavacTask.java ! test/lib-test/jdk/test/whitebox/CPUInfoTest.java ! test/lib/jdk/test/lib/SecurityTools.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java ! test/lib/jdk/test/lib/cds/CDSOptions.java ! test/lib/jdk/test/lib/containers/docker/Common.java ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java ! test/lib/jdk/test/lib/hexdump/HexPrinter.java ! test/lib/jdk/test/lib/jfr/Events.java + test/lib/jdk/test/lib/json/JSONValue.java + test/lib/jdk/test/lib/threaddump/ThreadDump.java ! test/lib/jdk/test/lib/util/ForceGC.java ! test/micro/org/openjdk/bench/java/lang/ArrayCopy.java ! test/micro/org/openjdk/bench/java/lang/ArrayCopyAligned.java ! test/micro/org/openjdk/bench/java/lang/ArrayCopyObject.java ! test/micro/org/openjdk/bench/java/lang/ArrayCopyUnalignedBoth.java ! test/micro/org/openjdk/bench/java/lang/ArrayCopyUnalignedDst.java ! test/micro/org/openjdk/bench/java/lang/ArrayCopyUnalignedSrc.java ! test/micro/org/openjdk/bench/java/lang/ArrayFiddle.java ! test/micro/org/openjdk/bench/java/lang/Characters.java ! test/micro/org/openjdk/bench/java/lang/ClassForName.java ! test/micro/org/openjdk/bench/java/lang/Clone.java + test/micro/org/openjdk/bench/java/lang/DoubleClassCheck.java + test/micro/org/openjdk/bench/java/lang/FPComparison.java + test/micro/org/openjdk/bench/java/lang/FloatClassCheck.java ! test/micro/org/openjdk/bench/java/lang/FloatingDecimal.java ! test/micro/org/openjdk/bench/java/lang/GetStackTrace.java ! test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java ! test/micro/org/openjdk/bench/java/lang/Integers.java ! test/micro/org/openjdk/bench/java/lang/LongDivMod.java ! test/micro/org/openjdk/bench/java/lang/Longs.java ! test/micro/org/openjdk/bench/java/lang/NewInstance.java ! test/micro/org/openjdk/bench/java/lang/ObjectHashCode.java ! test/micro/org/openjdk/bench/java/lang/RotateBenchmark.java ! test/micro/org/openjdk/bench/java/lang/StackWalkBench.java ! test/micro/org/openjdk/bench/java/lang/StrictMathBench.java ! test/micro/org/openjdk/bench/java/lang/StringBuffers.java + test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java ! test/micro/org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java ! test/micro/org/openjdk/bench/java/lang/StringEquals.java ! test/micro/org/openjdk/bench/java/lang/StringFormat.java ! test/micro/org/openjdk/bench/java/lang/StringHashCode.java - test/micro/org/openjdk/bench/java/lang/StringHttp.java ! test/micro/org/openjdk/bench/java/lang/StringIndexOf.java ! test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java ! test/micro/org/openjdk/bench/java/lang/StringOther.java ! test/micro/org/openjdk/bench/java/lang/StringReplace.java ! test/micro/org/openjdk/bench/java/lang/StringUpperLower.java ! test/micro/org/openjdk/bench/java/lang/SystemTime.java ! test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWait.java ! test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java ! test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitSharedCounter.java ! test/micro/org/openjdk/bench/java/lang/ThreadStartJoin.java + test/micro/org/openjdk/bench/java/lang/foreign/JavaLayouts.java + test/micro/org/openjdk/bench/java/lang/foreign/LinkUpcall.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverConstant.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNew.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNewHeap.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstant.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantFP.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantHeap.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantMapped.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantShared.java ! test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java ! test/micro/org/openjdk/bench/java/lang/foreign/ParallelSum.java ! test/micro/org/openjdk/bench/java/lang/foreign/TestAdaptVarHandles.java ! test/micro/org/openjdk/bench/java/lang/foreign/UnrolledAccess.java ! test/micro/org/openjdk/bench/java/lang/invoke/CallSiteSetTarget.java ! test/micro/org/openjdk/bench/java/lang/invoke/CallSiteSetTargetSelf.java ! test/micro/org/openjdk/bench/java/lang/invoke/CallSiteStable.java ! test/micro/org/openjdk/bench/java/lang/invoke/LookupAcquire.java ! test/micro/org/openjdk/bench/java/lang/invoke/LookupDefaultFind.java ! test/micro/org/openjdk/bench/java/lang/invoke/LookupPublicFind.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleAsCollector.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleAsSpreader.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleAsVarargsCollector.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleBasicInvoke.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleBindToBinding.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleBindToCurry.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleConvertBoxing.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleConvertCast.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleConvertReturnPrimitive.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleConvertReturnReference.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleConvertReturnVoid.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleConvertUnboxing.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleConvertWidening.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleInvokeWithArgs.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesAsIFInstance.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandleProxiesSuppl.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesArrayElementGetter.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesArrayElementSetter.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesCatchException.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesDropArguments.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesExactInvoker.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesFilterArgs.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesFilterReturn.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesFoldArguments.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesGuardWithTest.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesInsertArguments.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesInvoker.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesPermuteArguments.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesSpreadInvoker.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java ! test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java ! test/micro/org/openjdk/bench/java/lang/invoke/StringConcatFactoryBootstraps.java ! test/micro/org/openjdk/bench/java/lang/invoke/SwitchPointAdhoc.java ! test/micro/org/openjdk/bench/java/lang/invoke/SwitchPointGuard.java ! test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java ! test/micro/org/openjdk/bench/java/lang/reflect/ClazzWithSecurityManager.java ! test/micro/org/openjdk/bench/java/lang/reflect/MethodInvoke.java ! test/micro/org/openjdk/bench/java/lang/runtime/ObjectMethods.java ! test/micro/org/openjdk/bench/java/math/BigDecimals.java ! test/micro/org/openjdk/bench/java/math/BigIntegers.java ! test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java - test/micro/org/openjdk/bench/java/math/VectorSignum.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java + test/micro/org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java + test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCastOperationsBenchmark.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/MaskQueryOperationsBenchmark.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/MaskedLogicOpts.java + test/micro/org/openjdk/bench/jdk/incubator/vector/MemorySegmentVectorAccess.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java + test/micro/org/openjdk/bench/jdk/incubator/vector/StoreMaskedBenchmark.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java - test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShort.java + test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShorts.java ! test/micro/org/openjdk/bench/vm/compiler/VectorShiftRight.java + test/micro/org/openjdk/bench/vm/compiler/VectorSignum.java ! test/micro/org/openjdk/bench/vm/gc/Alloc.java From forax at univ-mlv.fr Mon Jun 27 08:54:14 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 27 Jun 2022 10:54:14 +0200 (CEST) Subject: Bug in the record pattern translation / record pattern spec Message-ID: <54047224.5937423.1656320054130.JavaMail.zimbra@u-pem.fr> Hi all, i've already reported that issue but it was theoretical because the support of the record pattern was not integrated into the jdk 19 at that time and i was not able to explain int clearly. Now that the support is available, this code should throw a StackOverflow error but it creates a linked list of MatchException which makes it hard to debug. Wrapping all exceptions into a runtime exception is not a good idea when you have recursive calls which is a kind of natural when you have pattern matching, for me it's a spec issue but i want to be sure. BTW, the bug here lies in the fact that deconstructing Cons(int value, int size, RecChain next) calls the accessor size() which itself calls RecChain::size which is a nice puzzler by itself. public sealed interface RecChain { default int size() { return switch (this) { case Nil __ -> 0; case Cons(int value, int size, RecChain next) -> 1 + next.size(); }; } record Nil() implements RecChain { } record Cons(int value, int size, RecChain next) implements RecChain { @Override public int size() { return size != -1? size: RecChain.super.size(); } } public static void main(String[] args){ RecChain chain = new Nil(); for (var i = 0; i < 100; i++) { chain = new Cons(i, -1, chain); } System.out.println(chain.size()); } } regards, R?mi