From public at negora.com Thu Mar 3 13:08:19 2022 From: public at negora.com (negora) Date: Thu, 3 Mar 2022 14:08:19 +0100 Subject: Proposal: Infer checked exceptions from private methods Message-ID: <4956da2b-ad7e-ab45-5d02-c88e5b9bf053@negora.com> Hi: I've seen many programmers propagate all checked exceptions up the call stack, from multiple private methods to the first non-private method of the class. There, some exceptions are allowed to propagate, whereas others are wrapped with one or more unchecked exceptions. So I would like to propose a variation of the `throws` clause, such as `throws uncaught` or `throws *`, so that the compiler infers which checked exceptions are thrown. **This feature would be limited to private methods,** so that developers are forced to think about their public APIs and don't let implementation details leak. Thanks to this, propagating exceptions inside a class would be super easy and would not clutter the code so much. I work in big server applications and some times the list of exceptions to "carry" between private methods is so long, that even the simplest method takes multiple lines of code, making it hard to read. In addition to this, if you changed the implementation in the future, you would have not to worry much about the exceptions thrown by the private methods, because you could make the necessary changes only in the non-private methods. Example with irrelevant parts omitted: ``` /* This method does nothing special. */ public void addStudentToRepository ( ??? String name, ??? String surname ??? Integer schoolID) ??? throws SchoolNotFoundException { ? try { ??? ... ??? School school = findSchool (schoolID); ??? ... ? } catch (UnavailableRepositoryException | WrongIDTypeException ex) { ??? throw new ImplementationException (ex); ? } } /* Here is the interesting part. */ private School findSchool (Integer id) ??? throws uncaught { ??????? /* ^^^ This is equivalent to throw ???????? * "UnavailableRepositoryException", ???????? * "WrongIDTypeException", ???????? * and "SchoolNotFoundException" separately. ???????? */ ? School school = repository.findObject (id, School.class); ????????????????????????? /* ^^^ This throws ?????????????????????????? * "UnavailableRepositoryException" ?????????????????????????? * and? "WrongIDTypeException". ?????????????????????????? */ ? if (school != null) { ??? return school; ? } else { ??? throw new SchoolNotFoundException (id); ? } } ``` This example is very basic. I know that `UnavailableRepositoryException` and `WrongIDTypeException` could inherit from a common `RepositoryException`, but: 1. You lose the specific types of the exceptions. 1. Sometimes that's not an option, because the exceptions come from different libraries or frameworks. Thank you! Best regards, negora. From brian.goetz at oracle.com Thu Mar 3 21:36:44 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 3 Mar 2022 16:36:44 -0500 Subject: Proposal: Infer checked exceptions from private methods In-Reply-To: <4956da2b-ad7e-ab45-5d02-c88e5b9bf053@negora.com> References: <4956da2b-ad7e-ab45-5d02-c88e5b9bf053@negora.com> Message-ID: While I understand the motivation for such a request, I suspect it would likely make things worse, not better. When we did type inference for local variables, we deliberately restricted it to local variables only, not fields or methods, because methods and fields are part of a classes API, and we wouldn't want the API to subtly change based on implementation detail, which would cause linkage errors. Clever folks observed: "but AHA, you could use inference for *private* method returns and fields without having that problem, why wouldn't you do that?" And we did have a reason for that: simplicity.? By not coupling inference to complex other details such as accessibility, it is easier to reason about when inference can be used (developers hate when they can't easily understand which features can be used where), and more importantly, means that making a private method public is simply a matter of changing the accessibility, not rewriting the method header.? Ad-hoc interactions between features (e.g., inference and accessibility) is a pernicious form of hidden complexity. Supporting inference of exceptions here is very similar to inference of return type. Such a feature is also likely to be misinterpreted; not all developers will immediately realize this is mere inference, they may well think it is "turning off checked exceptions" (and many of them will want to believe this.)? Which, for the vocal segment of Java users who think checked exceptions are the worst thing ever, would seem like a big slap in the face -- "you let me turn off checked exceptions, but only in the least important places!" On 3/3/2022 8:08 AM, negora wrote: > Hi: > > I've seen many programmers propagate all checked exceptions up the > call stack, > from multiple private methods to the first non-private method of the > class. > There, some exceptions are allowed to propagate, whereas others are > wrapped > with one or more unchecked exceptions. > > So I would like to propose a variation of the `throws` clause, such as > `throws > uncaught` or `throws *`, so that the compiler infers which checked > exceptions > are thrown. **This feature would be limited to private methods,** so that > developers are forced to think about their public APIs and don't let > implementation details leak. > > Thanks to this, propagating exceptions inside a class would be super > easy and > would not clutter the code so much. I work in big server applications > and some > times the list of exceptions to "carry" between private methods is so > long, > that even the simplest method takes multiple lines of code, making it > hard to > read. > > In addition to this, if you changed the implementation in the future, > you would > have not to worry much about the exceptions thrown by the private > methods, > because you could make the necessary changes only in the non-private > methods. > > Example with irrelevant parts omitted: > > ``` > /* This method does nothing special. */ > public void addStudentToRepository ( > ??? String name, > ??? String surname > ??? Integer schoolID) > ??? throws SchoolNotFoundException { > > ? try { > > ??? ... > ??? School school = findSchool (schoolID); > ??? ... > > ? } catch (UnavailableRepositoryException | WrongIDTypeException ex) { > ??? throw new ImplementationException (ex); > ? } > > } > > /* Here is the interesting part. */ > private School findSchool (Integer id) > ??? throws uncaught { > ??????? /* ^^^ This is equivalent to throw > ???????? * "UnavailableRepositoryException", > ???????? * "WrongIDTypeException", > ???????? * and "SchoolNotFoundException" separately. > ???????? */ > > ? School school = repository.findObject (id, School.class); > ????????????????????????? /* ^^^ This throws > ?????????????????????????? * "UnavailableRepositoryException" > ?????????????????????????? * and? "WrongIDTypeException". > ?????????????????????????? */ > ? if (school != null) { > ??? return school; > ? } else { > ??? throw new SchoolNotFoundException (id); > ? } > > } > ``` > > This example is very basic. I know that > `UnavailableRepositoryException` and > `WrongIDTypeException` could inherit from a common > `RepositoryException`, but: > > 1. You lose the specific types of the exceptions. > > 1. Sometimes that's not an option, because the exceptions come from > different > libraries or frameworks. > > Thank you! > > Best regards, > negora. From public at negora.com Mon Mar 7 07:55:39 2022 From: public at negora.com (negora) Date: Mon, 7 Mar 2022 08:55:39 +0100 Subject: Proposal: Infer checked exceptions from private methods In-Reply-To: References: <4956da2b-ad7e-ab45-5d02-c88e5b9bf053@negora.com> Message-ID: <2211365e-4c4f-d7d4-9358-559b6babbf31@negora.com> Thank you for your answer, Brian. > When we did type inference for local variables, we deliberately > restricted it to local variables only, not fields or methods, because > methods and fields are part of a classes API, and we wouldn't want the > API to subtly change based on implementation detail, which would cause > linkage errors. That's a good reason. But that's why this type of inference would be limited to private methods. Non-private methods would act as barriers to prevent unwanted changes in the public API (I use the term _public_ in the broadest sense). > And we did have a reason for that: simplicity. By not coupling > inference to complex other details such as accessibility, it is easier > to reason about when inference can be used (developers hate when they > can't easily understand which features can be used where), That seems reasonable. But, when you limit inference to the local scope, Aren't you also coupling that feature with another detail: variable scope in this case? > Supporting inference of exceptions here is very similar to inference > of return type. Sincerely, I don't like type inference in return types either. But there is something on checked exceptions that I see different from classic returns: you can't forget to handle or propagate a checked exception, because you're forced to do something with it. You're also forced to know the type of the exception. In this case you would be forced to, at least, use `throws uncaught`. In contrast, you may forget to return a value and the compiler wouldn't warn you until you tried to assign the return type to a variable. Or, more probably, you may return a type different from the one that you expected. > Such a feature is also likely to be misinterpreted; not all developers > will immediately realize this is mere inference, they may well think > it is "turning off checked exceptions" (and many of them will want to > believe this.) But this kind of misinterpretations also happened with other features. For example, with `var`, many people thought that you were giving up on static typing and using dynamic typing. > Which, for the vocal segment of Java users who think > checked exceptions are the worst thing ever, would seem like a > big slap in the face -- "you let me turn off checked exceptions, > but only in the least important places!" Hehehe. This is funny, because I've another proposal which is related to what you comment here. But I prefer to talk about it separately, in another thread. Because it's not directly related to this one. Going back to the main topic, I understand your concerns. But how can we make it more comfortable to work with checked exceptions? Checked exceptions are a valuable feature, in my opinion. But I also think that we should count with some aid to make them more "digestible". I've also thought on type aliases, but limited to the class internal scope. That way you could assign an union of exceptions to a name and throw that. The outer world (including the Javadocs) would only see the union, as always. But I feel that type aliases are even a more controversial feature. On 03/03/2022 22:36, Brian Goetz wrote: > While I understand the motivation for such a request, I suspect it would > likely make things worse, not better. > > When we did type inference for local variables, we deliberately > restricted it to local variables only, not fields or methods, because > methods and fields are part of a classes API, and we wouldn't want the > API to subtly change based on implementation detail, which would cause > linkage errors. > > Clever folks observed: "but AHA, you could use inference for *private* > method returns and fields without having that problem, why wouldn't you > do that?" > > And we did have a reason for that: simplicity.? By not coupling > inference to complex other details such as accessibility, it is easier > to reason about when inference can be used (developers hate when they > can't easily understand which features can be used where), and more > importantly, means that making a private method public is simply a > matter of changing the accessibility, not rewriting the method header. > Ad-hoc interactions between features (e.g., inference and accessibility) > is a pernicious form of hidden complexity. > > Supporting inference of exceptions here is very similar to inference of > return type. > > Such a feature is also likely to be misinterpreted; not all developers > will immediately realize this is mere inference, they may well think it > is "turning off checked exceptions" (and many of them will want to > believe this.)? Which, for the vocal segment of Java users who think > checked exceptions are the worst thing ever, would seem like a big slap > in the face -- "you let me turn off checked exceptions, but only in the > least important places!" > > On 3/3/2022 8:08 AM, negora wrote: >> Hi: >> >> I've seen many programmers propagate all checked exceptions up the >> call stack, >> from multiple private methods to the first non-private method of the >> class. >> There, some exceptions are allowed to propagate, whereas others are >> wrapped >> with one or more unchecked exceptions. >> >> So I would like to propose a variation of the `throws` clause, such as >> `throws >> uncaught` or `throws *`, so that the compiler infers which checked >> exceptions >> are thrown. **This feature would be limited to private methods,** so that >> developers are forced to think about their public APIs and don't let >> implementation details leak. >> >> Thanks to this, propagating exceptions inside a class would be super >> easy and >> would not clutter the code so much. I work in big server applications >> and some >> times the list of exceptions to "carry" between private methods is so >> long, >> that even the simplest method takes multiple lines of code, making it >> hard to >> read. >> >> In addition to this, if you changed the implementation in the future, >> you would >> have not to worry much about the exceptions thrown by the private >> methods, >> because you could make the necessary changes only in the non-private >> methods. >> >> Example with irrelevant parts omitted: >> >> ``` >> /* This method does nothing special. */ >> public void addStudentToRepository ( >> ??? String name, >> ??? String surname >> ??? Integer schoolID) >> ??? throws SchoolNotFoundException { >> >> ? try { >> >> ??? ... >> ??? School school = findSchool (schoolID); >> ??? ... >> >> ? } catch (UnavailableRepositoryException | WrongIDTypeException ex) { >> ??? throw new ImplementationException (ex); >> ? } >> >> } >> >> /* Here is the interesting part. */ >> private School findSchool (Integer id) >> ??? throws uncaught { >> ??????? /* ^^^ This is equivalent to throw >> ???????? * "UnavailableRepositoryException", >> ???????? * "WrongIDTypeException", >> ???????? * and "SchoolNotFoundException" separately. >> ???????? */ >> >> ? School school = repository.findObject (id, School.class); >> ????????????????????????? /* ^^^ This throws >> ?????????????????????????? * "UnavailableRepositoryException" >> ?????????????????????????? * and? "WrongIDTypeException". >> ?????????????????????????? */ >> ? if (school != null) { >> ??? return school; >> ? } else { >> ??? throw new SchoolNotFoundException (id); >> ? } >> >> } >> ``` >> >> This example is very basic. I know that >> `UnavailableRepositoryException` and >> `WrongIDTypeException` could inherit from a common >> `RepositoryException`, but: >> >> 1. You lose the specific types of the exceptions. >> >> 1. Sometimes that's not an option, because the exceptions come from >> different >> libraries or frameworks. >> >> Thank you! >> >> Best regards, >> negora. > From public at negora.com Mon Mar 7 11:07:35 2022 From: public at negora.com (negora) Date: Mon, 7 Mar 2022 12:07:35 +0100 Subject: Proposal: Operator to "demote" checked exceptions Message-ID: <62852f2f-225a-2748-8c86-42564e7fe525@negora.com> Hi: In their current form, many Java APIs make it impossible to throw checked exceptions when you implement their abstract methods (i.e. the interfaces in `java.util.function`). And, even if they allowed it, we would need a way to specify a variable number of exceptions, not just a fixed one. Since it's very unlikely that this feature is ever supported (I wish to be wrong), I think it's better to be pragmatic and look for a way to turn checked exceptions off (demote them) in those layers where they're unsupported, and then be able to turn them on again (promote them). Nowadays, in these situations, we're forced to wrap checked exceptions with unchecked ones, which has several disadvantages: 1. It adds a lot of noise to the code (lots of try-catch blocks). 2. The unchecked exception is just a mere wrapper, so people tend to reuse a single unchecked exception whose name usually is not meaningful in the current context. 3. If you want to rethrow the original exceptions, you're forced to catch the wrapper first, and then analyse and downcast the wrapped exceptions. 4. Other times, people is lazy and doesn't wrap the exceptions at all, leaving the `catch` block empty. ## Proposal. I propose an operator to demote checked exceptions. By _demoting_ I'm referring to making them behave as unchecked exceptions, so that they propagate transparently, but keeping their class hierarchy intact (they won't have any relation to `RuntimeException`). This operator would be used in the `throws` clause of the methods, and would be prepended to each checked exception that we wish to demote. I will use the `~` character as operator in my examples, but that's just an idea. This feature would be something like the `@SneakyThrows` annotation of [Project Lombok](https://projectlombok.org/), but more powerful: 1. It would be part of the Java language. 2. It could be used directly in the `throws` clause. 3. It could be used with lambdas too. For example, imagine a class that implements an `Iterator`, which lazily parses students from a file. This is the code (omitting non-important parts): ``` public final class StudentIterator implements Iterator { private Student student; public boolean hasNext () throws ~ParseException, ~IOException { // ^^^ The operator ~ demotes the checked exceptions, // so that they're propagated transparently. // It also makes that they are NOT part of the signature // of the method. if (student == null) { student = parseNextStudent (); } return (student != null) } private Student parseNextStudent () throws ParseException, IOException { } } ``` Now, to catch these exceptions in an upper layer, **Java would need to remove the rule that forbids catching a checked exception which is not explicitly thrown in the associated `try` block.** This is so because a demoted exception couldn't be detected by the compiler, obviously. The try-catch would look like always: ``` public void parseAndStoreStudents (Reader reader) { try { Iterator students = parseStudents (reader); storeStudents (students); } catch (ParseException | IOException ex) { // ^^^ Nothing special here. logAndNotifyByEmail (ex); } } ``` If we wanted to promote the demoted exceptions again, then we would simply do this: ``` public void parseAndStoreStudents (Reader reader) throws ParseException, IOException { // ^^^ Nothing special here, either. Iterator students = parseStudents (reader); storeStudents (students); } ``` In case that the method doesn't need to expose the exceptions because they're part of the implementation, we would simply let the demoted exceptions propagate: ``` public void obtainStudents () { Reader reader = getReader (); Iterator students = parseStudents (reader); storeStudents (students); } ``` ## Use with lambdas. Imagine a method that lazily parses students from text lines: ``` public Stream parseStudents (Reader reader) { Stream lines = parseLines (reader); return lines.map (line -> parseStudent ()); // ^^^ This makes the compilation fail // because the "ParseException" has not been // caught. } public Student parseStudent (String line) { throws ParseException { } ``` Java could introduce a variation of the `->` operator, such as `~>`: ``` public Stream parseStudents (Reader reader) { Stream lines = parseLines (reader); return lines.map (line ~> parseStudent ()); } ``` This would be equivalent to the following: ``` public Stream parseStudents (Reader reader) { Stream lines = parseLines (reader); return lines.map ( new Function<> () { @Override public Student apply (String line) throws ~ParseException { return parseStudent (line); } } ); ``` ## May programmers abuse this feature? People who hate checked exceptions might be tempted to demote every checked exception, that's true. But they are already doing that without this operator: they create utility classes and wrapper classes only for that purpose. Even specifications, such as JPA, or libraries, such as Hibernate or NIO, decided to use mostly or only unchecked exceptions. However, I believe that **this operator is an opportunity to encourage again the use of checked exceptions in our APIs** (where appropriate, of course), without the fear of causing a hell of try-catches to our users or to ourselves (if we write full applications). Those who find checked exceptions valuable (like me) will use them like always have done, but will count with a tool to: 1. Demote checked exceptions temporarily in those layers where they don't fit well (`Stream` I'm looking at you) and promote them again right after that. 2. Demote checked exceptions permanently where we don't want them to be exposed. From brian.goetz at oracle.com Mon Mar 7 20:38:39 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 7 Mar 2022 20:38:39 +0000 Subject: Proposal: Operator to "demote" checked exceptions In-Reply-To: <62852f2f-225a-2748-8c86-42564e7fe525@negora.com> References: <62852f2f-225a-2748-8c86-42564e7fe525@negora.com> Message-ID: <322D3D27-4177-40E5-8D04-9726D4E42AF0@oracle.com> Not going to engage on the ?should we give people the opportunity to turn off checked exceptions?, but I will make a few comments on how we might reduce the accidental cost of wrapping and unwrapping exceptions. > 3. If you want to rethrow the original exceptions, you're forced to catch the wrapper first, and then analyse and downcast the wrapped exceptions. We?re in the process of adding pattern matching to the language, in stages. Currently patterns are restricted to type patterns, and pattern-aware contexts are restricted to instanceof and switch, but both categories will expand over time. One context that could become pattern-aware is catch. And deconstruction patterns compose, so we could give exceptions deconstruction patterns to match their wrapping constructors, so that you could say catch (RuntimeException(SqlException se)) { ? } which reduces the syntactic overhead of unwrapping to basically zero. I?m much more compelled by directions like this, which embrace the tools we have, but reduce their accidental impact. (Obviously there?s work to do to make everything about wrapping this smooth.) From duke at openjdk.java.net Wed Mar 9 23:59:08 2022 From: duke at openjdk.java.net (Chad Arimura) Date: Wed, 9 Mar 2022 23:59:08 GMT Subject: [amber-docs] RFR: adding links to Inside.java and Dev.java Message-ID: Creating this PR because I wanted to point to Amber's wiki but realized it didn't point back to all the aggregated Amber content on Inside.java. I included Dev.java as well but can remove if it's not specific enough. It does have a lot of Amber coverage throughout. ------------- Commit messages: - adding links to Inside.java and Dev.java. The former is very specific to Amber. The latter is a general learning page for many of the Amber topics. Let me know if I should remove the Dev.java link. Changes: https://git.openjdk.java.net/amber-docs/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=amber-docs&pr=12&range=00 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/amber-docs/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/amber-docs pull/12/head:pull/12 PR: https://git.openjdk.java.net/amber-docs/pull/12 From duke at openjdk.java.net Thu Mar 10 12:54:15 2022 From: duke at openjdk.java.net (duke) Date: Thu, 10 Mar 2022 12:54:15 GMT Subject: git: openjdk/amber-docs: Fix typos in pattern-match-object-model.md (#8) Message-ID: Changeset: 83e606de Author: Sam Brannen Committer: GitHub Date: 2022-03-10 13:53:52 +0000 URL: https://git.openjdk.java.net/amber-docs/commit/83e606deddf8fe3aa2bb04d2a7ba8b04a3a460ae Fix typos in pattern-match-object-model.md (#8) ! site/design-notes/patterns/pattern-match-object-model.md From public at negora.com Wed Mar 16 09:12:29 2022 From: public at negora.com (negora) Date: Wed, 16 Mar 2022 10:12:29 +0100 Subject: Proposal: Operator to "demote" checked exceptions In-Reply-To: <322D3D27-4177-40E5-8D04-9726D4E42AF0@oracle.com> References: <62852f2f-225a-2748-8c86-42564e7fe525@negora.com> <322D3D27-4177-40E5-8D04-9726D4E42AF0@oracle.com> Message-ID: <3fb6b87d-c64d-24d3-1895-7847b0f68ece@negora.com> Hi Brian. Thank you for your answer and apologizes for the delay. I must admit that, in a first stage of my proposal, my idea was about adding some syntactic sugar to wrap/unwrap exceptions easily, without the need of try-catch blocks. But that led me to the idea of removing the need of wrapping altogether and, hence, propose the feature of switchable checked exceptions. My initial proposal looked like this: ``` public Student parseStudent (String line) throws StudentException wraps IOException, ParseException { // Code. } ``` Instead of this: ``` public Student parseStudent (String line) { try { // Code. } catch (IOException | ParseException ex) { throw new StudentException (ex); } } ``` Obviously, the wrapper exception should provide at least one constructor with a single parameter of type `Throwable`. And the signature of the method would not include the `wraps` clause. Maybe it's just me, but try-catch blocks introduce visual complexity that distracts me while reading the body of a method. It could be alleviated **a lot** with this. From my experience, many try-catch blocks are just to wrap checked exceptions between abstraction layers, so this would be very helpful in many parts of our code bases. In practice, the use of try-catch blocks would be reduced to those situations in which we need to do something different from just wrapping an exception. In contrast to the proposal of switchable exceptions, this syntax couldn't be directly applied to lambdas. But at least one could extract the code to a new method and keep it cleaner that with a try-catch. > One context that could become pattern-aware is catch. And > deconstruction patterns compose, so we could give exceptions > deconstruction patterns to match their wrapping constructors, so that > you could say > > catch (RuntimeException(SqlException se)) { ? } > > which reduces the syntactic overhead of unwrapping to basically > zero. That sounds interesting. But, Could the opposite concept be carried to the `throws` clause? I mean, a construction pattern instead of a deconstruction one. Something similar to my first example, but without the need of a new keyword: ``` public Student parseStudent (String line) throws StudentException (IOException | ParseException) { // Code. } ``` I really prefer the use of the `wraps` keyword, but I understand that introducing a new keyword has lots of side-effects. On 07/03/2022 21:38, Brian Goetz wrote: > Not going to engage on the ?should we give people the opportunity to turn off checked exceptions?, but I will make a few comments on how we might reduce the accidental cost of wrapping and unwrapping exceptions. > >> 3. If you want to rethrow the original exceptions, you're forced to catch the wrapper first, and then analyse and downcast the wrapped exceptions. > > We?re in the process of adding pattern matching to the language, in stages. Currently patterns are restricted to type patterns, and pattern-aware contexts are restricted to instanceof and switch, but both categories will expand over time. > > One context that could become pattern-aware is catch. And deconstruction patterns compose, so we could give exceptions deconstruction patterns to match their wrapping constructors, so that you could say > > catch (RuntimeException(SqlException se)) { ? } > > which reduces the syntactic overhead of unwrapping to basically zero. I?m much more compelled by directions like this, which embrace the tools we have, but reduce their accidental impact. (Obviously there?s work to do to make everything about wrapping this smooth.) From brian.goetz at oracle.com Wed Mar 16 15:17:01 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 16 Mar 2022 11:17:01 -0400 Subject: [External] : Re: Proposal: Operator to "demote" checked exceptions In-Reply-To: <3fb6b87d-c64d-24d3-1895-7847b0f68ece@negora.com> References: <62852f2f-225a-2748-8c86-42564e7fe525@negora.com> <322D3D27-4177-40E5-8D04-9726D4E42AF0@oracle.com> <3fb6b87d-c64d-24d3-1895-7847b0f68ece@negora.com> Message-ID: <396831f8-f02f-4153-0a7f-5c181f0f880f@oracle.com> Yes, the notion of "declarative checked exception wrapping" has been bouncing around the ecosystem for a long time (I think I even wrote a mail/RFE not unlike yours ~25 years ago about it, when I first arrived in the Java ecosystem.)? As directions for reducing the pain of checked exceptions go, I agree it is a promising one. To answer the syntax question in your mail, what you suggest would introduce a painful asymmetry between ??? catch (E1(E2)) and ??? throws E1(E2) because the nesting notation would mean two different things in the two places; in the first, describing only what is caught ("an E2 wrapped in an E1"), but in the latter, it is trying to say "if I throw an E2, catch it, and rewrap it in an E1, and throw that".? I think it is too much of a stretch to try to reuse the same syntax for two different things. So, my summary is that this is an understood and plausible direction, and something we might consider at some point, but not a feature that we are currently pursuing.? (Yes, we understand that checked exceptions can be painful.)? So, please let's not try to design the feature here -- and certainly let's not try to design the syntax here. On 3/16/2022 5:12 AM, negora wrote: > Hi Brian. Thank you for your answer and apologizes for the delay. > > I must admit that, in a first stage of my proposal, my idea was about > adding some syntactic sugar to wrap/unwrap exceptions easily, without > the need of try-catch blocks. But that led me to the idea of removing > the need of wrapping altogether and, hence, propose the feature of > switchable checked exceptions. > > My initial proposal looked like this: > > ``` > public Student parseStudent (String line) > ??? throws StudentException > ????? wraps IOException, ParseException { > ? // Code. > } > ``` > > Instead of this: > > ``` > public Student parseStudent (String line) { > ? try { > ??? // Code. > ? } catch (IOException | ParseException ex) { > ??? throw new StudentException (ex); > ? } > } > ``` > > Obviously, the wrapper exception should provide at least > one constructor with a single parameter of type `Throwable`. > And the signature of the method would not include > the `wraps` clause. > > Maybe it's just me, but try-catch blocks introduce visual > complexity that distracts me while reading the body of a method. > It could be alleviated **a lot** with this. > > From my experience, many try-catch blocks are just > to wrap checked exceptions between abstraction layers, > so this would be very helpful in many parts of our code bases. > In practice, the use of try-catch blocks would be reduced > to those situations in which we need to do something > different from just wrapping an exception. > > In contrast to the proposal of switchable exceptions, this > syntax couldn't be directly applied to lambdas. But at least > one could extract the code to a new method and keep it cleaner > that with a try-catch. > > > One context that could become pattern-aware is catch. And > > deconstruction patterns compose, so we could give exceptions > > deconstruction patterns to match their wrapping constructors, so that > > you could say > > > >????? catch (RuntimeException(SqlException se)) { ? } > > > > which reduces the syntactic overhead of unwrapping to basically > > zero. > > That sounds interesting. But, Could the opposite concept be carried > to the `throws` clause? I mean, a construction pattern > instead of a deconstruction one. Something similar to > my first example, but without the need of a new keyword: > > ``` > public Student parseStudent (String line) > ??? throws StudentException (IOException | ParseException) { > ? // Code. > } > ``` > > I really prefer the use of the `wraps` keyword, but I understand > that introducing a new keyword has lots of side-effects. > > > > On 07/03/2022 21:38, Brian Goetz wrote: >> Not going to engage on the ?should we give people the opportunity to >> turn off checked exceptions?, but I will make a few comments on how >> we might reduce the accidental cost of wrapping and unwrapping >> exceptions. >> >>> 3. If you want to rethrow the original exceptions, you're forced to >>> catch the wrapper first, and then analyse and downcast the wrapped >>> exceptions. >> >> We?re in the process of adding pattern matching to the language, in >> stages.? Currently patterns are restricted to type patterns, and >> pattern-aware contexts are restricted to instanceof and switch, but >> both categories will expand over time. >> >> One context that could become pattern-aware is catch.? And >> deconstruction patterns compose, so we could give exceptions >> deconstruction patterns to match their wrapping constructors, so that >> you could say >> >> ???? catch (RuntimeException(SqlException se)) { ? } >> >> which reduces the syntactic overhead of unwrapping to basically >> zero.? I?m much more compelled by directions like this, which embrace >> the tools we have, but reduce their accidental impact. (Obviously >> there?s work to do to make everything about wrapping this smooth.) From john.r.rose at oracle.com Wed Mar 16 17:36:08 2022 From: john.r.rose at oracle.com (John Rose) Date: Wed, 16 Mar 2022 11:36:08 -0600 Subject: generics vs. checked exceptions Message-ID: <05221468-717E-4C82-BB4D-86A0963FAE86@oracle.com> Negora?s use case for demotion (temporary erasure, suppression) of checked exceptions is streams. Streams are designed (quite nicely I might add) on top of Java generics. But generics are (very consciously) limited in their interactions with checked exceptions: There is no way to treat exception *sets* as generic parameters. You can treat individual exception types as generic parameters but this doesn?t scale to lambda bodies which throw two checked exceptions, or (less so) no checked exceptions. Exception tracking (including ?inferring? the throws of a lambda body) interoperates to some extent with generic type inference, allowing single exception types to be inferred and bound (constrained) to type variables, but the inference rules don?t provide well other than a single exception. In my mind this weakness of generics relative to checked exceptions is similar to the weakness of generics relative to primitives. (Also the weakness in not supporting variable-arity type abstraction; it?s hard but doable.) And, in my mind, such weaknesses are ones we could fix somehow, at some point when we have the bandwidth. But they are not simple to fix: You don?t just propose a syntax and say ?job done?. The really hard part is specifying how the new feature interacts with (pretty much) *every single pre-existing feature*. Oh, and it has to be backward compatible. And unsurprising to users. And fully specified with no gray areas. And more? I note that both generics and exceptions are erased in translation to classfiles; both depend on static checks in javac to maintain correctness. This suggests (to me) that some sort of erasable, statically checks inference of exception *sets* would be helpful. I think Ron Pressler has mentioned this point as well somewhere. The erasure in translation also unlocked a wide variety of retrofitting moves when generics were introduced. Even at this late date if we were to layer in a way to abstract over exception sets, we could hope (with a little like) to find that we could retrofit streams to handle checked exceptions. This would address Negora?s point (about streams) far better than adding a new flavor of throws clause and/or lambda. If we could stick a clause like ?throws X? in various places, both uses and defs of generic type variables, where X somehow was taken to denote a possibly-empty set of checked exceptions, and then do the hard work to specify the inference rules (with all the constraints mentioned above) we might have a road towards making streams (and other APIs) friendlier to checked exceptions. A stream would be retrofitted with some sort of ?throws X? variable which would advertise what the terminal operations might throw, and various transforms would accumulate exceptions. A new stream operation (non-terminal) for capturing and transforming exceptions might be added; if : filter :: catch : . (I didn?t say ?monad? there but I could have.) All that said, I don?t want to work on it now, because I have far more pressing things to get done: pressing in a good, exciting, and fruitful way. I imagine Brian has similar feelings. (Idle question: Does fruitful pressing eventually lead to good vintages? One hopes!) ? John P.S. On one of my many back burners, I?ve been experimenting with exposing checked exceptions through Java?s *existing* generics (nothing new) to find the limits of what they can do. Here?s a snapshot, FWIW, of small number of types which expose not only the possible normal result value of an expression, but also its possible exceptional result: http://cr.openjdk.java.net/~jrose/draft/exbox-javadoc It?s not done. But I find it thought-provoking and others might as well. From hjohn at xs4all.nl Wed Mar 16 20:24:20 2022 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 16 Mar 2022 21:24:20 +0100 Subject: generics vs. checked exceptions In-Reply-To: <05221468-717E-4C82-BB4D-86A0963FAE86@oracle.com> References: <05221468-717E-4C82-BB4D-86A0963FAE86@oracle.com> Message-ID: <7585fab4-9ba9-1f32-94e2-7d378d330593@xs4all.nl> On 16/03/2022 18:36, John Rose wrote: > All that said, I don?t want to work on it now, because I have far more > pressing things to get done: pressing in a good, exciting, and > fruitful way.? I imagine Brian has similar feelings. > > (Idle question:? Does fruitful pressing eventually lead to good > vintages?? One hopes!) > > ? John > > P.S. On one of my many back burners, I?ve been experimenting with > exposing checked exceptions through Java?s *existing* generics > (nothing new) to find the limits of what they can do.? Here?s a > snapshot, FWIW, of small number of types which expose not only the > possible normal result value of an expression, but also its possible > exceptional result: > > http://cr.openjdk.java.net/~jrose/draft/exbox-javadoc I've been playing with something similar :) Here is an implementation of Streams which allows checked exceptions (upto 3) with standard Java: https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-util/src/main/java/hs/mediasystem/util/checked The test case has readable examples: https://github.com/hjohn/MediaSystem-v2/blob/master/mediasystem-util/src/test/java/hs/mediasystem/util/checked/CheckedStreamsTest.java The exceptions are (re)thrown and declared by the terminal operations of Stream.? The lack of a generic type parameter that can indicate a set of exceptions makes it a bit cumbersome, but it does not cause any problems when no exceptions are thrown or only runtime exceptions are thrown.? In fact, surprisingly, declaring the same checked exception (through a generic parameter) several times is seemingly allowed without problem. --John From public at negora.com Thu Mar 17 12:07:08 2022 From: public at negora.com (negora) Date: Thu, 17 Mar 2022 13:07:08 +0100 Subject: [External] : Re: Proposal: Operator to "demote" checked exceptions In-Reply-To: <396831f8-f02f-4153-0a7f-5c181f0f880f@oracle.com> References: <62852f2f-225a-2748-8c86-42564e7fe525@negora.com> <322D3D27-4177-40E5-8D04-9726D4E42AF0@oracle.com> <3fb6b87d-c64d-24d3-1895-7847b0f68ece@negora.com> <396831f8-f02f-4153-0a7f-5c181f0f880f@oracle.com> Message-ID: <817ccf77-c97a-ad2a-9bd9-f67019054fb5@negora.com> > Yes, the notion of "declarative checked exception wrapping" has been > bouncing around the ecosystem for a long time (I think I even wrote a > mail/RFE not unlike yours ~25 years ago about it, when I first > arrived in the Java ecosystem.) As directions for reducing the pain > of checked exceptions go, I agree it is a promising one. Maybe I'm being too passionate, but I think that would be a game changer for those of us who still use checked exceptions. I admit that, from time to time, I feel tempted to use only unchecked exceptions. But I still keep the hope that checked exceptions get some love from the Java team and it becomes easier to work with them. > what you suggest would introduce a painful asymmetry True. I should have left only the example with the `wraps` keyword. > So, please let's not try to design the feature here -- and certainly let's not try to design the syntax here. Sorry, it was just a quick idea. I'm not familiar with this mailing list so I thought that type of matters could be commented here. Thank you. On 16/03/2022 16:17, Brian Goetz wrote: > Yes, the notion of "declarative checked exception wrapping" has been > bouncing around the ecosystem for a long time (I think I even wrote a > mail/RFE not unlike yours ~25 years ago about it, when I first arrived > in the Java ecosystem.)? As directions for reducing the pain of checked > exceptions go, I agree it is a promising one. > > To answer the syntax question in your mail, what you suggest would > introduce a painful asymmetry between > > ??? catch (E1(E2)) > > and > > ??? throws E1(E2) > > because the nesting notation would mean two different things in the two > places; in the first, describing only what is caught ("an E2 wrapped in > an E1"), but in the latter, it is trying to say "if I throw an E2, catch > it, and rewrap it in an E1, and throw that".? I think it is too much of > a stretch to try to reuse the same syntax for two different things. > > So, my summary is that this is an understood and plausible direction, > and something we might consider at some point, but not a feature that we > are currently pursuing.? (Yes, we understand that checked exceptions can > be painful.)? So, please let's not try to design the feature here -- and > certainly let's not try to design the syntax here. > > > > On 3/16/2022 5:12 AM, negora wrote: >> Hi Brian. Thank you for your answer and apologizes for the delay. >> >> I must admit that, in a first stage of my proposal, my idea was about >> adding some syntactic sugar to wrap/unwrap exceptions easily, without >> the need of try-catch blocks. But that led me to the idea of removing >> the need of wrapping altogether and, hence, propose the feature of >> switchable checked exceptions. >> >> My initial proposal looked like this: >> >> ``` >> public Student parseStudent (String line) >> ??? throws StudentException >> ????? wraps IOException, ParseException { >> ? // Code. >> } >> ``` >> >> Instead of this: >> >> ``` >> public Student parseStudent (String line) { >> ? try { >> ??? // Code. >> ? } catch (IOException | ParseException ex) { >> ??? throw new StudentException (ex); >> ? } >> } >> ``` >> >> Obviously, the wrapper exception should provide at least >> one constructor with a single parameter of type `Throwable`. >> And the signature of the method would not include >> the `wraps` clause. >> >> Maybe it's just me, but try-catch blocks introduce visual >> complexity that distracts me while reading the body of a method. >> It could be alleviated **a lot** with this. >> >> From my experience, many try-catch blocks are just >> to wrap checked exceptions between abstraction layers, >> so this would be very helpful in many parts of our code bases. >> In practice, the use of try-catch blocks would be reduced >> to those situations in which we need to do something >> different from just wrapping an exception. >> >> In contrast to the proposal of switchable exceptions, this >> syntax couldn't be directly applied to lambdas. But at least >> one could extract the code to a new method and keep it cleaner >> that with a try-catch. >> >> > One context that could become pattern-aware is catch. And >> > deconstruction patterns compose, so we could give exceptions >> > deconstruction patterns to match their wrapping constructors, so that >> > you could say >> > >> >????? catch (RuntimeException(SqlException se)) { ? } >> > >> > which reduces the syntactic overhead of unwrapping to basically >> > zero. >> >> That sounds interesting. But, Could the opposite concept be carried >> to the `throws` clause? I mean, a construction pattern >> instead of a deconstruction one. Something similar to >> my first example, but without the need of a new keyword: >> >> ``` >> public Student parseStudent (String line) >> ??? throws StudentException (IOException | ParseException) { >> ? // Code. >> } >> ``` >> >> I really prefer the use of the `wraps` keyword, but I understand >> that introducing a new keyword has lots of side-effects. >> >> >> >> On 07/03/2022 21:38, Brian Goetz wrote: >>> Not going to engage on the ?should we give people the opportunity to >>> turn off checked exceptions?, but I will make a few comments on how >>> we might reduce the accidental cost of wrapping and unwrapping >>> exceptions. >>> >>>> 3. If you want to rethrow the original exceptions, you're forced to >>>> catch the wrapper first, and then analyse and downcast the wrapped >>>> exceptions. >>> >>> We?re in the process of adding pattern matching to the language, in >>> stages.? Currently patterns are restricted to type patterns, and >>> pattern-aware contexts are restricted to instanceof and switch, but >>> both categories will expand over time. >>> >>> One context that could become pattern-aware is catch.? And >>> deconstruction patterns compose, so we could give exceptions >>> deconstruction patterns to match their wrapping constructors, so that >>> you could say >>> >>> ???? catch (RuntimeException(SqlException se)) { ? } >>> >>> which reduces the syntactic overhead of unwrapping to basically >>> zero.? I?m much more compelled by directions like this, which embrace >>> the tools we have, but reduce their accidental impact. (Obviously >>> there?s work to do to make everything about wrapping this smooth.) > From jlahoda at openjdk.java.net Tue Mar 22 07:52:48 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 22 Mar 2022 07:52:48 GMT Subject: git: openjdk/amber: created branch type-patterns-third based on the branch templated-string containing 818 unique commits Message-ID: <291e7da1-855c-45f4-a1a0-51f07dd21678@openjdk.org> The following commits are unique to the type-patterns-third branch: ======================================================== 8d0f385f: 8279520: SPNEGO has not passed channel binding info into the underlying mechanism 6a42fbaf: 8279258: Auto-vectorization enhancement for two-dimensional array operations 62d03c28: 8279547: [vectorapi] Enable vector cast tests after JDK-8278948 4243f4c9: 8279540: Shenandoah: Should only clear CLD::_claim_strong mark for strong CLD iterations d47af74e: 8279500: Remove FileMapHeader::_heap_obj_roots f203723f: 8279337: The MToolkit is still referenced in a few places 77757ba9: 8225122: Test AncestorResized.java fails when Windows desktop is scaled. e14fb4f4: 8279437: [JVMCI] exception in HotSpotJVMCIRuntime.translate can exit the VM 8d1a1e83: 8278228: C2: Improve identical back-to-back if elimination 2f8a2fd0: 8279568: IGV: Add bci and line number property for OSR compilations 4aefd8b8: 8279528: Unused TypeEnter.diag after JDK-8205187 5fa13bb4: 8279522: Serial: Remove unused Generation::clear_remembered_set 79b614cc: 8279523: Parallel: Remove unnecessary PSScavenge::_to_space_top_before_gc 1f101b04: 8278329: some TraceDeoptimization code not included in PRODUCT build 6613ce64: 8279300: [arm32] SIGILL when running GetObjectSizeIntrinsicsTest 4ff67205: 8183227: read/write APIs in class os shall return ssize_t 11d88ce8: 8218857: Confusing overloads for os::open 76477f8c: 8142362: Lots of code duplication in Copy class debaa28e: 8274679: Remove unnecessary conversion to String in security code in java.base dee447f8: 8274809: Update java.base classes to use try-with-resources 7c792f27: 8279333: Some JFR tests do not accept 'GCLocker Initiated GC' as a valid GC Cause 967ef0c4: 8278020: ~13% variation in Renaissance-Scrabble d65c6658: 8279527: Dereferencing segments backed by different scopes leads to pollution 642ab34a: 8278373: JavacTrees.searchMethod finds incorrect match 8f969a13: 8278930: javac tries to compile a file twice via PackageElement.getEnclosedElements 06b4d494: 8278344: sun/security/pkcs12/KeytoolOpensslInteropTest.java test fails because of different openssl output 354c9047: 8273452: DocTrees.getDocCommentTree should be specified as idempotent 928e3477: 8279032: compiler/loopopts/TestSkeletonPredicateNegation.java times out with -XX:TieredStopAtLevel < 4 ad34f03b: 8279515: C1: No inlining through invokedynamic and invokestatic call sites when resolved class is not linked 40df5df9: 8279398: jdk/jfr/api/recording/time/TestTimeMultiple.java failed with "RuntimeException: getStopTime() > afterStop" d9b1bb58: Merge 0d190961: 8279642: JFR: Remove unnecessary creation of Duration and Instant objects d7e6e9bd: 8279643: JFR: Explain why path is sometimes missing from FileRead and FileWrite events 4471e951: 8279645: JFR: The cacheEventType in Dispatcher is never assigned 2f7665b8: 8279644: hsdis may not work when it was built with --with-binutils=system 2f13872d: 8279646: JFR: Remove recursive call in jdk.jfr.internal.Control 6504458d: 8279647: JFR: Unclosed directory stream ec5a455e: 8279682: JFR: Remove dead code 126328cb: 8279560: AArch64: generate_compare_long_string_same_encoding and LARGE_LOOP_PREFETCH alignment bf7bcaac: 8277748: Obsolete the MinInliningThreshold flag in JDK 19 3121898c: 8279703: G1: Remove unused force_not_compacted local in G1CalculatePointersClosure::do_heap_region 2bbeae3f: 8279668: x86: AVX2 versions of vpxor should be asserted d46410c5: 8279785: JFR: 'jfr configure' should show default values 4c52eb39: 8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong condition c08b2ac3: 8225093: Special property jdk.boot.class.path.append should not default to empty string 08e14c60: 8278207: G1: Tighten verification in G1ResetSkipCompactingClosure 9e024476: 8279834: Alpine Linux fails to build when --with-source-date enabled c3d0a940: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 cfee4512: 8273914: Indy string concat changes order of operations 67141849: 8279700: Parallel: Simplify ScavengeRootsTask constructor API c4518e25: 8278868: Add x86 vectorization support for Long.bitCount() 36f41cbe: 8279884: Use better file for cygwin source permission check 3aaa0982: 8276694: Pattern trailing unescaped backslash causes internal error 1c688f41: 8279900: compiler/vectorization/TestPopCountVectorLong.java fails due to vpopcntdq is not supported f16f6a95: 8279821: JFR: Log warnings properly when loading a misconfigured .jfc file 13bfb497: 6496103: isFileHidingEnabled return false by default 319d2303: 8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in bd339aa6: 8277627: Fix copyright years in some jvmci files 4f0b6502: 8278581: Improve reference processing statistics log output 525b20fc: 8279676: Dubious YMM register clearing in x86_64 arraycopy stubs ece98d85: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code ff0cb989: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out f54ce844: 8238161: use os::fopen in HS code where possible 8fed8ab2: 8278065: Refactor subclassAudits to use ClassValue ddddec7d: 8274243: Implement fast-path for ASCII-compatible CharsetEncoders on aarch64 0a094d7c: 8268081: Upgrade Unicode Data Files to 14.0.0 d70545d7: 8258603: c1 IR::verify is expensive 1228b2f1: 8261455: Automatically generate the CDS archive if necessary cb250298: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards bbc1ddb4: 8278267: ARM32: several vector test failures for ASHR 92307e5a: 8278489: Preserve result in native wrapper with +UseHeavyMonitors 6d7db4b0: 8279356: Method linking fails with guarantee(mh->adapter() != NULL) failed: Adapter blob must already exist! 86d0abb6: 8279695: [TESTBUG] modify compiler/loopopts/TestSkeletonPredicateNegation.java to run on C1 also 5aecb372: 8206181: ExceptionInInitializerError: improve handling of exceptions in user-provided taglets 67e3d51d: Merge 48519480: 8279903: Redundant modulo operation in ECDHKeyAgreement 69339346: 8278597: Remove outdated comments regarding RMISecurityManager in HotSpotAgent.java b61a4af7: 8259774: Deprecate -XX:FlightRecorderOptions:samplethreads c17a0122: 8278961: Enable debug logging in java/net/DatagramSocket/SendDatagramToBadAddress.java 6fcaa322: 8262442: (windows) Use all proxy configuration sources when java.net.useSystemProxies=true 0a839b43: 8279801: EC KeyFactory and KeyPairGenerator do not have aliases for OID format 9209e6d6: 8279877: Document IDEA IDE setup in docs/ide.md 237f861e: 8273143: Transition to _thread_in_vm when handling a polling page exception 35172cda: 8278951: containers/cgroup/PlainRead.java fails on Ubuntu 21.10 965c64bc: 8279699: Parallel: More precise boundary in ObjectStartArray::object_starts_in_range 84976b45: 8278549: UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15 dd76a28d: 8280000: Remove unused CardTable::find_covering_region_containing 9f30ec17: 8278398: jwebserver: Add test to confirm maximum request time e8f494cd: 8279825: JFR: JFCModel shouldn't need FilePermission to read predefined .jfc files 35734ad0: 8279545: Buffer overrun in reverse_words of sharedRuntime_x86_64.cpp:3517 61b89443: 8278851: Correct signer logic for jars signed with multiple digestalgs ac98b220: 8280028: [BACKOUT] Parallel: More precise boundary in ObjectStartArray::object_starts_in_range f1805309: 8279918: Fix various doc typos cf283e2a: 8279570: IGV: Add source/destination property for load and store nodes with an associated field d9dd485b: 8280019: Remove unused code from metaspace fb8fdc0f: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) c359c358: 8280002: jmap -histo may leak stream 0d1a97f7: 8279064: New options for ktab to provide non-default salt eab4e6d6: 8280045: ProblemList 2 AppCDS tests until JDK-8279970 is fixed 9b0f6895: 8279947: Remove two redundant gvn.transform calls in Parse::do_one_bytecode() 22b7295e: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails 9a18190a: 8280048: Missing comma in copyright header fef8f2d3: 8279797: JFR: Show .jfc options in JFR.start help c6196662: 8276673: Optimize abs operations in C2 compiler 590eb860: 8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on large machines a30aa52b: 8279958: Provide configure hints for Alpine/apk package managers 431bd9a6: 8280001: Serial: Add documentation to heap memory layout 71ca85f5: 8278831: Use table lookup for the last two bytes in Integer.getChars 9e536b64: 8280032: Update jib-profiles.js to use JMH 1.34 devkit 3edcb132: 8280018: Remove obsolete VM_GenCollectFullConcurrent 5d52bf99: 8279910: G1: Simplify HeapRegionRemSet::add_reference 7b6738fa: 8278885: Remove Windows ARM64 int8_t workaround in G1 262f2efd: 8280059: Incorrect glibc version is used in a comment in os_linux.cpp 65eb066b: 8279837: C2: assert(is_Loop()) failed: invalid node class: Region 33814791: 8274007: [REDO] VM Exit does not abort concurrent mark 14a90e53: 8279370: jdk.jpackage/share/native/applauncher/JvmLauncher.cpp fails to build with GCC 6.3.0 ff856593: 8279833: Loop optimization issue in String.encodeUTF8_UTF16 37143c09: Merge 064ee6ae: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java 45f20633: 8279597: [TESTBUG] ReturnBlobToWrongHeapTest.java fails with -XX:TieredStopAtLevel=1 on machines with many cores c6b02755: 8279930: Synthetic cast causes generation of store barriers when using heap segments 4b520f00: 8279702: [macosx] ignore xcodebuild warnings on M1 c809d34f: 8279924: [PPC64, s390] implement frame::is_interpreted_frame_valid checks 09d61b61: 8280034: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 4d9b3f4c: 8279998: PPC64 debug builds fail with "untested: RangeCheckStub: predicate_failed_trap_id" 39f140a2: Merge 48c5f3c7: 8280026: Cleanup of IGV printing 94522626: 8278892: java.naming module description is missing @uses tags to document the services that it uses eb949953: 8280070: G1: Fix template parameters in G1SegmentedArraySegment 645b38d5: 8280089: compiler/c2/irTests/TestIRAbs.java fails on some arches 1725f77b: 8280029: G1: "Overflow during reference processing, can not continue" on x86_32 d175d33f: 8280079: Serial: Remove empty Generation::prepare_for_verify 64c0c0e1: 8276563: Undefined Behaviour in class Assembler 9eb50a5e: 8280010: Remove double buffering of InputStream for Properties.load 9e3f68d8: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations 88a8b239: 8280076: Unify IGV and IR printing 7acc4c7d: 8280058: JFR: StreamUtils::getJfrRepository(Process) should print stdout and stderr b734dc86: 8280055: JFR: Improve ObjectContext implementation 848b16a3: 8272746: ZipFile can't open big file (NegativeArraySizeException) fd9fb9a4: 8279194: Add Annotated Memory Viewer feature to SA's HSDB bdfa15d9: 8250801: Add clhsdb "threadcontext" command e314a4cf: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes 46fd6838: 8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10 1a206287: 8248404: AArch64: Remove uses of long and unsigned long 3a421e4b: 8280122: SupportedGroupsExtension should output "named groups" rather than "versions" 4f4da3b1: 8275318: loaded_classes_do may see ArrayKlass before InstanceKlass is loaded 4eb4f94d: 8279956: Useless method Scheduling::ComputeLocalLatenciesForward() b0496b0d: 8279970: two AppCDS tests fail after JDK-8261455 44fe958c: 6465404: some problems in CellEditor related API docs 5af7f258: 8274811: Remove superfluous use of boxing in java.base 39b1d75f: 8277822: Remove debug-only heap overrun checks in os::malloc and friends 68b40ec2: 8273139: C2: assert(f <= 1 && f >= 0) failed: Incorrect frequency 8931c122: 8280157: wrong texts Falied in a couple of tests cc2f474c: 8280024: Parallel: Remove unnecessary region resizing methods in PSCardTable 96114315: 8279936: Change shared code to use os:: system API's b20b11cf: 8258240: make vscode-project on Windows generates jdk.code-workspace file with unescaped '\' in paths e20c6bf9: 8280189: JFR: TestPrintXML should print mismatching XML 610a1290: 8268831: Improve javadoc tool handling of streams. 84fa0d8c: 8190264: JScrollBar ignores its border when using macOS Mac OS X Aqua look and feel dac15efc: 8280182: HotSpot Style Guide has stale link to chromium style guide 5523ddeb: 8279641: Create manual JTReg tests for Swing accessibility 6179e13b: 8266410: jdk/jfr/javaagent/TestLoadedAgent.java failed with "Mismatch in TestEvent count" d1efb0cc: 8267341: macos attempt_reserve_memory_at(arg1, arg2, true) failure 98d96a77: 8279796: Fix typo: Constucts -> Constructs e38df216: 8256291: RunThese30M fails "assert(_class_unload ? true : ((((JfrTraceIdBits::load(class_loader_klass)) & ((1 << 4) << 8)) != 0))) failed: invariant" bd35f974: 8278628: jdk/jfr/jmx/streaming/TestMaxSize.java Expected only one or two chunks 20ef9541: 8279227: Access Bridge: Wrong frame position and hit test result on HiDPI display feff0e55: 8264934: Enhance cross VM serialization 29f61b3b: 8269944: Better HTTP transport redux f18deeb6: 8268488: More valuable DerValues e069a3b8: 8268512: More content for ContentInfo 7ee905a8: 8270498: Improve SAX Parser configuration management 1fddb03d: 8271968: Better canonical naming 9a94fbc7: 8270952: Improve TIFF file handling fa47c368: 8270386: Better verification of scan methods b02ea6dc: 8270646: Improved scanning of XML entities afd0dc76: 8271962: Better TrueType font loading 51816035: 8272272: Enhance jcmd communication c372990f: 8268494: Better inlining of inlined interfaces 6b6f829b: 8269151: Better construction of EncryptedPrivateKeyInfo 5832a344: 8270416: Enhance construction of Identity maps 4be02d31: 8271987: Manifest improved manifest entries aa28430b: 8268813: Better String matching 3adc1117: 8272236: Improve serial forms for transport 78b2c841: 8270492: Better resolution of URIs ae7877df: 8273290: Enhance sound handling cb7482d5: 8272014: Better array indexing 4d3663a6: 8272026: Verify Jar Verification 12034273: 8272462: Enhance image handling 9c02c4c5: 8273756: Enhance BMP image support abf6fdd7: 8273968: JCK javax_xml tests fail in CI 4525a4b9: 8270392: Improve String constructions a6fd2c31: 8273838: Enhanced BMP processing 3603e754: 8274374: Additional fix for JDK-8272014 82d6afe6: 8274096: Improve decoding of image files 6d3fd860: 8278417: Closed test fails after JDK-8276108 on aarch64 af6c9aba: 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE 69cfa9cb: 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS f37bfead: 8280155: [PPC64, s390] frame size checks are not yet correct 28e02fa2: 8280234: AArch64 "core" variant does not build after JDK-8270947 f5de6fa7: 8272058: 25 Null pointer dereference defect groups in 4 files be0538d7: 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling 03680bea: 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl 4616c13c: Merge c4a624d4: 8279894: javax/swing/JInternalFrame/8020708/bug8020708.java timeouts on Windows 11 1022cbdf: 8280047: Broken link to Swing Connection document from javax.swing package docs e683d4ac: 8279921: Dump the .class file in jlink debug mode for any failure during transform() of a plugin 0bf95a1a: 8279607: Existing optimization "~x+1" -> "-x" can be generalized to "~x+c" -> "(c-1)-x". cf977e88: 8276166: Remove dead code from MimeTable and MimeEntry 3f747368: 8280123: C2: Infinite loop in CMoveINode::Ideal during IGVN 20297dea: 8280161: com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java fails with SSLException 98b157a7: 8280146: Parallel: Remove time log tag a4d20190: 8280178: Remove os:: API's that just call system API's ec8b6acf: 8234682: The order of @param in the generated docs should match the method signature 0ea2b390: 8280363: Minor correction of ALPN specification in SSLParameters 96365026: 8279008: G1: Calculate BOT threshold on-the-fly during Object Copy phase d48279b0: 8279009: CDS crashes when the source of an InstanceKlass is NULL 3419ff7b: 8277535: Remove redundant Stream.distinct()/sorted() steps 02390c79: 8279282: [vectorapi] Matcher::supports_vector_comparison_unsigned is not needed on x86 2426d58e: 8278472: Invalid value set to CANDIDATEFORM structure 293fb46f: 8280413: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on all X64 platforms 35ee0f38: 8258814: Compilation logging crashes for thread suspension / debugging tests 6352c020: 8280401: [sspi] gss_accept_sec_context leaves output_token uninitialized 19f87798: 8278784: C2: Refactor PhaseIdealLoop::remix_address_expressions() so it operates on longs 47b1c51b: 8277120: Use Optional.isEmpty instead of !Optional.isPresent in java.net.http ab2c8d3c: 8280393: Promote use of HtmlTree factory methods 6287ae37: 8277531: Print actual default stacksize on Windows thread logging 2920ce54: 8278036: Saving rscratch1 is optional in MacroAssembler::verify_heapbase c1e4f3dd: 8279397: Update --release 18 symbol information for JDK 18 build 32 b9ae7790: 8279675: CDS cannot handle non-existent JAR file in bootclassapth 54c9de26: 8275918: Remove unused local variables in java.base security code 30cd47d4: 8280499: runtime/cds/appcds/TestDumpClassListSource.java fails on platforms without AppCDS custom class loaders support 9bf6ffa1: 8279124: VM does not handle SIGQUIT during initialization d1569111: 8280459: Suspicious integer division in Hashtable.readHashtable 0567a84d: 8280457: Duplicate implementation of dprecision_rounding and dstore_rounding 7a0a6c95: 8274751: Drag And Drop hangs on Windows f05ff996: 8280174: Possible NPE in Thread.dispatchUncaughtException afd2805e: 8279534: Consolidate and remove oopDesc::klass_gap methods 4501ddda: 8214733: runtime/8176717/TestInheritFD.java timed out 44db4794: 8280391: NMT: Correct NMT tag on CollectedHeap 18c9cb07: 8280067: Incorrect code generated for unary - on char operand d53d8bd7: 8279315: Add Git support to update_copyright_year.sh script 2b133415: 8036019: Insufficient alternatives listed in some errors produced by the parser 4b329add: 8280496: Remove unused G1PageBasedVirtualSpace::pretouch_internal 1c7769d3: 8280437: Move G1BufferNodeList to gc/shared dae2226a: 8279795: Fix typo in BasicFileChooserUI: Constucts -> Constructs acd98294: 8279794: Fix typos in BasicScrollBarUI: Laysouts a vertical scroll bar 0b5c54be: 8279798: Javadoc for BasicTabbedPaneUI is inconsistent a825a4a1: 8279861: Clarify 'rect' parameters and description of paintTabBorder method in BasicTabbedPaneUI a5416669: 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md 8e82d002: 8280492: Use cross-module syntax for cross-module links 7d2ef9d9: 8279179: Update nroff pages in JDK 18 before RC ead9fecc: 8280441: Missing "classpath exception" in several files from jdk.httpserver 52ddbe2d: Merge e3076552: 8280403: RegEx: String.split can fail with NPE in Pattern.CharPredicate::match f35df5bf: 8280422: thread_from_jni_environment can never return NULL a59d717f: 8280289: Enhance debug pp() command with NMT info 53804720: 8280470: Confusing instanceof check in HijrahChronology.range b3277465: 8280384: Parallel: Remove VMThread specific ParCompactionManager 295b263f: 8279241: G1 Full GC does not always slide memory to bottom addresses 2155afe2: 8280503: Use allStatic.hpp instead of allocation.hpp where possible 1b141576: 8280274: Guard printing code of Compile::print_method in PRODUCT c43ce85f: 8278302: [s390] Implement fast-path for ASCII-compatible CharsetEncoders 28796cbd: 8163921: HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC 36fbec78: 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env 4503d043: 8280375: G1: Tighten mem region limit in G1RebuildRemSetHeapRegionClosure 496baada: 8280030: [REDO] Parallel: More precise boundary in ObjectStartArray::object_starts_in_range fe77250f: 8280414: Memory leak in DefaultProxySelector 674a97b2: 8280396: G1: Full gc mark stack draining should prefer to make work available to other threads f4575e40: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException cbe8395a: 8280168: Add Objects.toIdentityString cebaad1c: 8280041: Retry loop issues in java.io.ClassCache 76fe03fe: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases 841eae6f: 8269542: JDWP: EnableCollection support is no longer spec compliant after JDK-8255987 295c0474: 8279242: Reflection newInstance() error message when constructor has no access modifiers could use improvement 2eab86b5: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor a183bfb4: 8280377: MethodHandleProxies does not correctly invoke default methods with varags 2c64a7f2: 8280374: G1: Remove unnecessary prev bitmap mark e72eefd9: 8280531: Remove unused DeferredCloseInputStream a24f44d1: 8280526: x86_32 Math.sqrt performance regression with -XX:UseSSE={0,1} c180070c: 8280373: Update Xalan serializer / SystemIDResolver to align with JDK-8270492 ed0df2fa: 8268033: compiler/intrinsics/bmi/verifycode/BzhiTestI2L.java fails with "fatal error: Not compilable at tier 3: CodeBuffer overflow" a07e19d8: 8278410: Improve argument processing around UseHeavyMonitors f34f8d4d: 8277983: Remove unused fields from sun.net.www.protocol.jar.JarURLConnection e1d8f555: 8280402: Add new convenience forms to HtmlTree 4b2370e5: 8279294: NonblockingQueue::try_pop may improperly indicate queue is empty b8365aa4: 8268978: Document the javadoc software stack ef08e2c6: 8280592: Small javadoc tweaks to foreign API a5a11f14: Merge 0c42e43f: 8280550: SplittableRandom#nextDouble(double,double) can return result >= bound b5de2cc9: 8280546: Remove hard-coded 127.0.0.1 loopback address d2a50a64: 8279636: Update JCov version to 3.0.12 16e0ad0a: 8270199: Most SA tests are skipped on macosx-aarch64 because all executables are signed c2ee1b33: 8273236: keytool does not accurately warn about algorithms that are disabled but have additional constraints 89083019: 8076089: Cleanup: Inline & remove sun.management.Util.newException 2ea0edf2: 8279673: AudioClip.play doesn't work due to NullPointerException when creating DataPusher 0dba1707: 8278518: String(byte[], int, int, Charset) constructor and String.translateEscapes() miss bounds check elimination 94380d0e: 8278232: [macos] Wrong chars emitted when entering certain char-sequence of Indic language 7f68759c: 8280719: G1: Remove outdated comment in RemoveSelfForwardPtrObjClosure::apply cab59051: 8280583: Always build NMT a3a0dcd9: 8280353: -XX:ArchiveClassesAtExit should print warning if base archive failed to load b94ebaa0: 8280686: Remove Compile::print_method_impl ece89c6d: 8280366: (fs) Restore Files.createTempFile javadoc 6d242e40: 8280835: jdk/javadoc/tool/CheckManPageOptions.java depends on source hierarchy 40a2ce20: 8270476: Make floating-point test infrastructure more lambda and method reference friendly 78574057: 8280744: Allow SuppressWarnings to be used in all declaration contexts 094db1a3: 8277948: AArch64: Print the correct native stack if -XX:+PreserveFramePointer when crash a1d1e475: 8280823: Remove NULL check in DumpTimeClassInfo::is_excluded 178ac746: 8251466: test/java/io/File/GetXSpace.java fails on Windows with mapped network drives. 55f180fb: 8280004: DCmdArgument::parse_value() should handle NULL input 973dda5c: 8280804: Parallel: Remove unused variables in PSPromotionManager::drain_stacks_depth 8a3cca09: 8280784: VM_Cleanup unnecessarily processes all thread oops ed826f29: 8280397: Factor out task queue statistics printing 6de90ad9: 8280863: Update build README to reflect that MSYS2 is supported cb8a82ee: 8272317: jstatd has dependency on Security Manager which needs to be removed 409382ba: 8280703: CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption 95ee9bf7: 4774868: (fc spec) Unclear spec for FileChannel.force ff34d624: 8280898: ProblemList compiler/regalloc/TestC2IntPressure.java on macosx-aarch64 0740ac47: 8280555: serviceability/sa/TestObjectMonitorIterate.java is failing due to ObjectMonitor referencing a null Object 91391598: 8280843: macos-Aarch64 SEGV in frame::sender_for_compiled_frame after JDK-8277948 d366d15d: 8280903: javadoc build fails after JDK-4774868 268880b4: 8277412: Use String.isBlank to simplify code in sun.net.www.protocol.mailto.Handler be9f984c: 8280553: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java can fail if GC occurs 251351f4: 8280889: java/lang/instrument/GetObjectSizeIntrinsicsTest.java fails with -XX:-UseCompressedOops c6ed2046: 8278263: Remove redundant synchronized from URLStreamHandler.openConnection methods 61794c50: 8280817: Clean up and unify empty VM operations 091aff92: 8278908: [macOS] Unexpected text normalization on pasting from clipboard bdda43e0: 8280705: Parallel: Full gc mark stack draining should prefer to make work available to other threads dcc666d5: 8280139: Report more detailed statistics about task stealing in task queue stats 993a2488: 8280450: Add task queue printing to STW Full GCs 319b7749: 8277101: jcmd VM.cds dynamic_dump should not regenerate holder classes f991891b: 8280949: Correct the references for the Java Security Standard Algorithm Names specification 39165613: 8280543: Update the "java" and "jcmd" tool specification for CDS 74921e84: 8280738: Minor cleanup for HtmlStyle ee3be0bb: 8280488: doclint reference checks withstand warning suppression 96d0df72: 8272984: javadoc support for reproducible builds 4191b2b9: 8275337: C1: assert(false) failed: live_in set of first block must be empty 4dbebb62: 8280534: Enable compile-time doclint reference checking 9c0104b9: 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack 1ea01465: 8281007: Test jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java fails after JDK-8280738 0e70d450: 8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix de3113b9: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos 16ec47d5: 8279856: Parallel: Use PreservedMarks to record promotion-failed objects 18a7dc8c: 8279586: [macos] custom JCheckBox and JRadioBox with custom icon set: focus is still displayed after unchecking d37fb1df: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle 86debf42: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors c5a86120: 8280458: G1: Remove G1BlockOffsetTablePart::_next_offset_threshold 1f6fcbe2: 8278475: G1 dirty card refinement by Java threads may get unnecessarily paused 5080e815: 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr 4532c3a1: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered d1cc5fda: 8280941: os::print_memory_mappings() prints segment preceeding the inclusion range bde2b378: 8279954: java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails d95de5c7: 8255495: Support CDS Archived Heap for uncompressed oops fdd9ca74: 8280642: ObjectInputStream.readObject should throw InvalidClassException instead of IllegalAccessError a18beb47: 8280867: Cpuid1Ecx feature parsing is incorrect for AMD CPUs c74b8f48: 8275914: SHA3: changing java implementation to help C2 create high-performance code 9ca7ff3e: 8281082: Improve javadoc references to JOSS 85d839fb: 8280601: ClhsdbThreadContext.java test is triggering codecache related asserts d32f99ee: 8279219: [REDO] C2 crash when allocating array of size too large 97af3230: 8280842: Access violation in ciTypeFlow::profiled_count 48a32b5f: 8280976: Incorrect encoding of avx512 vpsraq instruction with mask and constant shift. ab638341: 8280885: Shenandoah: Some tests failed with "EA: missing allocation reference path" 4304a772: 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after JDK-8276116 de826ba1: 8280600: C2: assert(!had_error) failed: bad dominance ae2504b4: 8278254: Cleanup doclint warnings in java.desktop module 4ea6037e: 8281035: Serial: Move RemoveForwardedPointerClosure to local scope ce71e8b2: 8279917: Refactor subclassAudits in Thread to use ClassValue 87ab0994: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism 9d578537: 8281042: G1: Remove unused init_threshold in G1FullGCCompactionPoint 47800bf3: 8280868: LineBodyHandlerTest.java creates and discards too many clients e3d5c9e7: 8266974: duplicate property key in java.sql.rowset resource bundle fe0118f8: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC 2531c332: 8278871: [JVMCI] assert((uint)reason < 2* _trap_hist_limit) failed: oob a46307a7: Merge a95ee5ad: 8065422: Trailing dot in hostname causes TLS handshake to fail with SNI disabled fe547eac: 8280956: Re-examine copyright headers on files in src/java.desktop/macosx/native/libawt_lwawt/awt/a11y 5ab22e88: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations 63a00a0d: 8272777: Clean up remaining AccessController warnings in test library 010965c8: 8281023: NMT integration into pp debug command does not work 1f926609: 8281057: Fix doc references to overriding in JLS 86c24b31: 8240908: RetransformClass does not know about MethodParameters attribute cda9c301: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call 130cf46d: 4750574: (se spec) Selector spec should clarify calculation of select return value b6935dfb: 8251505: Use of types in compiler shared code should be consistent. e44dc638: 8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack 63e11cfa: 8280970: Cleanup dead code in java.security.Provider c936e705: 8280593: [PPC64, S390] redundant allocation of MacroAssembler in StubGenerator ctor 46c6c6f3: 8281043: Intrinsify recursive ObjectMonitor locking for PPC64 51b53a82: 8280913: Create a regression test for JRootPane.setDefaultButton() method 3d926dd6: 8277795: ldap connection timeout not honoured under contention 01f93ddf: 8279385: [test] Adjust sun/security/pkcs12/KeytoolOpensslInteropTest.java after 8278344 7207f2a3: Merge 66b2c3b6: 8280948: [TESTBUG] Write a regression test for JDK-4659800 d4b99bc0: 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to update_for_block f5d6fddc: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang 8e4ef818: 8280767: -XX:ArchiveClassesAtExit does not archive BoundMethodHandle$Species classes 48523b09: 8281049: man page update for jstatd Security Manager dependency removal 42e272e1: 8281289: Improve with List.copyOf 77b0240d: 8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 f7814c12: 8139173: [macosx] JInternalFrame shadow is not properly drawn 2f48a3f0: 8279878: java/awt/font/JNICheck/JNICheck.sh test fails on Ubuntu 21.10 5dfff740: 8166050: partialArray is not created in javax.swing.text.html.parser.NPrintWriter.println(...) method f2302822: 8281298: Revise the creation of unmodifiable list f5e08700: 8281117: Add regression test for JDK-8280587 95fd9d20: 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing f3e82426: 8280965: Tests com/sun/net/httpserver/simpleserver fail with FileSystemException on Windows 11 4c169495: 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled 76677716: 8281114: G1: Remove PreservedMarks::init_forwarded_mark 22a1a32c: 8268387: Rename maximum compaction to maximal compaction in G1 a0f6f240: 8280890: Cannot use '-Djava.system.class.loader' with class loader in signed JAR 2ed1f4cf: 8281175: Add a -providerPath option to jarsigner 1dfc94dd: 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. 8a662105: 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java 2f71a6b3: 8279613: JFR: Snippify Javadoc 4eacacb5: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages multipliers f2a9627c: 8279329: Remove hardcoded IPv4 available policy on Windows 861f2797: 8280917: Simplify G1ConcurrentRefineThread activation f5d8cebb: 8281296: Create a regression test for JDK-4515999 83d67452: 8281450: Remove unnecessary operator new and delete from ObjectMonitor 380378c5: 8281400: Remove unused wcslen() function 7f19c700: 8281061: [s390] JFR runs into assertions while validating interpreter frames 92f4f40d: 8281104: jar --create should create missing parent directories 5fb56dbb: 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java d658d945: 8280828: Improve invariants in NonblockingQueue::append fb17a8ec: 8278947: Support for array constants in constant table 2f46af05: 8280132: Incorrect comparator com.sun.beans.introspect.MethodInfo.MethodOrder 13f739d3: 8280830: Change NonblockingQueue::try_pop variable named "result" bce5dd17: 8280438: Improve BufferNode::Allocator::release to avoid walking pending list fc772178: 8281168: Micro-optimize VarForm.getMemberName for interpreter cb2f8cae: 8281338: NSAccessibilityPressAction action for tree node and NSAccessibilityShowMenuAcgtion action not working 072e7b4d: 8272807: Permit use of memory concurrent with pretouch f924e50c: 8281440: AWT: Conversion from string literal loses const qualifier f092baba: 8281195: Mistakenly used logging causes significant overhead in interpreter 69e390a0: 8262721: Add Tests to verify single iteration loops are properly optimized bb2e10cc: 8281274: deal with ActiveProcessorCount in os::Linux::print_container_info 8b384b98: 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" f823bed0: 8280007: Enable Neoverse N1 optimizations for Arm Neoverse V1 & N2 c5c8c064: 8279822: CI: Constant pool entries in error state are not supported 178b962e: 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty fd8a3dcc: 8280820: Clean up bug8033699 and bug8075609.java tests: regtesthelpers aren't used 7218d844: 8281567: Remove @throws IOException from X509CRLImpl::getExtension docs fa0a72c0: 8252496: C2: Useless code in MergeMemNode::Ideal c820d1ac: 8281379: Assign package declarations to all jtreg test cases under gc d442328b: 8281262: Windows builds in different directories are not fully reproducible 3ce1c5b6: 8280832: Update usage docs for NonblockingQueue 039313d6: 8054449: Incompatible type in example code in TreePath 83b6e4bc: 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors 58c2bd31: 8281536: JFR: Improve jdk.jfr.ContentType documentation 84868e39: 8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath separator in gc paths eee6a562: 8281522: Rename ADLC classes which have the same name as hotspot variants 65831eb2: 8281318: Improve jfr/event/allocation tests reliability a037b3c3: 8281460: Let ObjectMonitor have its own NMT category 8441d51e: 8281419: The source data for the color conversion can be discarded 3a13425b: 8072070: Improve interpreter stack banging 90939cb8: 8281626: NonblockingQueue should use nullptr 4d640760: 8047749: javadoc for getPathBounds() in TreeUI and BasicTreeUI is incorrect d254cf28: 8281638: jfr/event/allocation tests fail with release VMs after JDK-8281318 due to lack of -XX:+UnlockDiagnosticVMOptions 4ff5824f: 8281100: Spurious "variable might not have been initialized" with sealed class switch f399ae55: 8202836: [macosx] test java/awt/Graphics/TextAAHintsTest.java fails e73ee0ca: 8281259: MutableBigInteger subtraction could be simplified e75e8cd7: 8279997: check_for_dynamic_dump should not exit vm 88868397: 8281622: JFR: Improve documentation of jdk.jfr.Relational c5ff6e45: 8223077: module path support for dynamic CDS archive 0786ddb4: 8281535: Create a regression test for JDK-4670051 83ffbd2e: 8277175: Add a parallel multiply method to BigInteger 4032fe76: 8281238: TYPE_USE annotations not printed in correct position in toString output c3179a87: 8281462: Annotation toString output for enum not reusable for source input 6fdfe045: 8281674: tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java fails with AssertionError aa918a6e: 8281033: Improve ImageCheckboxTest to test all available LaF 58dae60d: 8274524: SSLSocket.close() hangs if it is called during the ssl handshake 67077a04: 8278423: ExtendedDTraceProbes should be deprecated 8acfbc2e: 8281675: VMDeprecatedOptions test fails after JDK-8278423 eff5dafb: 8274939: Incorrect size of the pixel storage is used by the robot on macOS adbe0661: 8239927: Product variable PrefetchFieldsAhead is unused and should be removed 483d4b97: 8281505: Add CompileCommand PrintIdealPhase 1ef45c5b: 8280799: ?2: assert(false) failed: cyclic dependency prevents range check elimination 46f52296: 8281539: IGV: schedule approximation computes immediate dominators wrongly 2632d40d: 8281637: Remove unused VerifyOption_G1UseNextMarking 25972062: 8280783: Parallel: Refactor PSCardTable::scavenge_contents_parallel c61d629a: 8281553: Ensure we only require liveness from mach-nodes with barriers 95f198b2: 8274980: Improve adhoc build version strings 534e5578: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers 2604a88f: 8281585: Remove unused imports under test/lib and jtreg/gc 9d0a4c3f: 8274238: Inconsistent type for young_list_target_length() f07b8165: 8280940: gtest os.release_multi_mappings_vm is racy 88fc3bfd: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant pool entries 16f649b9: 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails after JDK-8279997 1a7b70a8: 8269091: javax/sound/sampled/Clip/SetPositionHang.java failed with ArrayIndexOutOfBoundsException: Array index out of range: -4 d4cd8dfe: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters f33329eb: 8016524: [macosx] Bottom line is not visible for JTableHeader b1564624: 8281467: Allow larger OptoLoopAlignment and CodeEntryAlignment 11f943d1: 8280916: Simplify HotSpot Style Guide editorial changes 622970e4: 8281728: Redundant null check in LineNumberInputStream.read 8819f453: 8281722: Removal of PrintIdealLevel f82866bc: 8281555: [macos] Get rid of deprecated Style Masks constants 1c12b159: 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp 2112a9dc: 8246033: bin/print_config.js script uses nashorn jjs tool bc614840: 8280136: Serial: Remove unnecessary use of ExpandHeap_lock 2fe0bf66: 8281748: runtime/logging/RedefineClasses.java failed "assert(addr != __null) failed: invariant" 18704653: 8281744: x86: Use short jumps in TIG::set_vtos_entry_points 745f7e7d: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails 394ce5f9: 8280825: Modules that "provide" ToolProvider should document the name that can be used 1aff44b2: 8279949: JavaThread::_free_handle_block leaks native memory a24498b7: 8281771: Crash in java_lang_invoke_MethodType::print_signature 0af356bb: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts a86cab8d: 8236136: tests which use CompilationMode shouldn't be run w/ TieredStopAtLevel fef5d74d: 8281812: x86: Use short jumps in TemplateTable::condy_helper d5b46665: 8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467 7428b376: 8281948: JFR: Parser skips too many bytes for fractional types d8f44aa3: 8278067: Make HttpURLConnection default keep alive timeout configurable 395bc141: 8281732: add assert for non-NULL assumption for return of unique_ctrl_out 0f3d3ac3: 8061729: Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs 9b74c3f2: 8176706: Additional Date-Time Formats bb4dece2: 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 81645521: 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test 980d1878: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library 847a99b5: 8281822: Test failures on non-DTrace builds due to incomplete DTrace* flags handling 67763df4: 8281003: MethodHandles::lookup throws NPE if caller is null 48f6e930: 8282020: ProblemList sun/net/www/protocol/https/HttpsURLConnection/B6216082.java until JDK-8282017 is fixed 9ba0760c: 8275345: RasterFormatException when drawing a tiled image made of non-writable rasters 5ec7898d: 8281671: Class.getCanonicalName spec should explicitly cover array classes 0b00ce17: 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% 2be2a298: 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE 0f2113ce: 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022 b6e48e67: Merge cd234f5d: 8282007: Assorted enhancements to jpackage testing framework 1eec16b4: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE 1864481d: 8279969: NULL return from map_bitmap_region() needs to be checked c0275e18: 8203290: [AIX] Check functionality of JDK-8199712 (Flight Recorder) b4900b12: 8264743: Add forRemoval for deprecated classes and method in javax/swing/plaf/basic 9ca435b4: 8281305: Test com/sun/net/httpserver/simpleserver/MapToPathTest.java fails on Windows 11 3b7a3cfc: 8281971: Remove unimplemented InstanceRefKlass::do_next d0e11808: 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath 4c7f8b49: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException a6f8a386: 8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null cd9a3cf0: 8282017: sun/net/www/protocol/https/HttpsURLConnection/B6216082.java fails with "SocketException: Unexpected end of file from server" 12927765: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range 69fc273f: 8282075: ProblemList 3 compiler/whitebox tests on macosx-x64 f830cbec: 8188073: Add Capstone as backend for hsdis fdce35f3: 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732 a22f422b: 8037573: Typo in DefaultTreeModel docs: askAllowsChildren instead of asksAllowsChildren c9289583: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines 7bcca769: 8279068: IGV: Update to work with JDK 16 and 17 138a1719: 8281267: VM HeapDumper dumps array classes several times 834d55c5: 8277300: Issues with javadoc support for preview features e8224f7d: 8282089: [BACKOUT] Parallel: Refactor PSCardTable::scavenge_contents_parallel e3365041: 8280866: SuppressWarnings does not work properly in package-info and module-info f5120b76: 8282056: Clean up com.sun.tools.javac.util.GraphUtils cf6984dd: 8282086: Update jib profile to not set build to 0 413bef68: 8282049: AArch64: Use ZR for integer zero immediate volatile stores cfbfd9bf: 8282103: fix macosx-generic typo in ProblemList 7ce75afb: 8255266: Update Public Suffix List to 3c213aa 3943c89b: 8282044: [JVMCI] Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler. d3749de4: 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022 d7f31d0d: 8282077: PKCS11 provider C_sign() impl should handle CKR_BUFFER_TOO_SMALL error d28b048f: 8281815: x86: Use short jumps in TIG::generate_slow_signature_handler 8563d86f: 8282085: The REGISTER_DEFINITION macro is useless after JDK-8269122 4e0b81c5: 8281544: assert(VM_Version::supports_avx512bw()) failed for Tests jdk/incubator/vector/ 52a85d80: 8282158: ECParameters InvalidParameterSpecException messages missed ECKeySizeParameterSpec c5d9142a: 8282096: G1: Remove redundant checks in G1CardSet::free_mem_object 34aae32d: 8282166: JDK-8282158 changed ECParameters' package by accident 51f44207: 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers bdae1d87: 8282147: [TESTBUG] waitForIdle after creating frame in JSpinnerMouseAndKeyPressTest.java d7a706a5: 8253757: Add LLVM-based backend for hsdis cc7cf812: 8280861: Robot color picker broken on Linux with scaling above 100% e1c98bd1: 8281523: Accessibility: Conversion from string literal loses const qualifier e0b49629: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle f9539521: 8281745: Create a regression test for JDK-4514331 bc43320f: 8281543: Remove unused code/headerfile dtraceAttacher.hpp b95310b0: 8282220: contentType should not be a PKCS7's member ab6d8e64: 8260328: Drop redundant CSS properties from java.desktop HTML files 022d8070: 8271008: appcds/*/MethodHandlesAsCollectorTest.java tests time out because of excessive GC (CodeCache GC Threshold) in loom 41355e2d: 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java e44d0670: 8244593: Clean up GNM/NM after JEP 381 957dae02: 8280958: G1/Parallel: Unify marking code structure 3cb38678: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception 58e1882f: 8282042: [testbug] FileEncodingTest.java depends on default encoding 7feabee4: 8261407: ReflectionFactory.checkInitted() is not thread-safe 6445ee46: 5041655: (ch) FileLock: negative param and overflow issues 2557ef8a: 8282276: Problem list failing two Robot Screen Capture tests 6f882ded: 8280964: [Linux aarch64] : drawImage dithers TYPE_BYTE_INDEXED images incorrectly e1060bee: 8281615: Deadlock caused by jdwp agent 378fa507: 8281962: Avoid unnecessary native calls in InflaterInputStream ecd85e6f: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts registers 93320717: 8282194: C1: Missing side effects of dynamic constant linkage d017e988: 8255577: Possible issues with SR_initialize aaab2cb4: 8282225: GHA: Allow one concurrent run per PR only 5035bf5e: 8282208: Reduce MachNode size 340a35d8: 8282279: Interpret case-insensitive string locale independently 35076af1: 8281376: Consider polymorphic methods when looking for overrides 99b8ed9d: 8281217: Source file launch with security manager enabled fails a020b6ba: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() 7dc7184c: 8282309: Operation before upper case conversion e540e0a8: 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) f86f38a8: 8280901: MethodHandle::linkToNative stub is missing w/ -Xint 253cf785: 8282076: Merge some debug agent changes from the loom repo 43dc9ef6: 8281988: Create a regression test for JDK-4618767 a6610031: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr cd3e59ef: 8282299: Remove unused PartialArrayScanTask default constructor 379fd859: 8277369: Strange behavior of JMenuBar with RIGHT_TO_LEFT orientation, arrow keys behaves opposite traversing through keyboard 3cfffa4f: 8282188: Unused static field MathContext.DEFAULT_DIGITS f4486a19: 8262400: runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails in test_ame5_compiled_vtable_stub with wrapper 231e48fa: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 0796620b: 8281944: JavaDoc throws java.lang.IllegalStateException: ERRONEOUS abc0ce11: 8282316: Operation before String case conversion 6fab8a2d: 8277204: Implement PAC-RET branch protection on Linux/AArch64 0b6862e8: 8282348: Remove unused CardTable::dirty_card_iterate 20e78f7a: 8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor 23995f82: 8281525: Enable Zc:strictStrings flag in Visual Studio build b6843a16: 8005885: enhance PrintCodeCache to print more data bf19fc65: 8280357: user.home = "?" when running with systemd DynamicUser=true cd36be42: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use 3efd6aa4: 8282347: AARCH64: Untaken branch in has_negatives stub 9471f24c: 8280684: JfrRecorderService failes with guarantee(num_written > 0) when no space left on device. b96b7437: 8281015: Further simplify NMT backend 735e86b0: 8282345: handle latest VS2022 in abstract_vm_version e96c599e: 8271232: JFR: Scrub recording data 441e4850: 8281739: JFR: Use message with Objects.requireNonNull fb8bf818: 8279995: jpackage --add-launcher option should allow overriding description c5c6058f: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX cf6d2565: 8282153: JFR: Check for recording waste afd4bcbc: 8282398: EndingDotHostname.java test fails because SSL cert expired 630ad1ac: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java 86723d48: 8281507: Two javac tests have bad jtreg `@clean` tags efd3967b: 8267265: Use new IR Test Framework to create tests for C2 Ideal transformations 06cadb36: 8230382: Clean up ConvI2L, CastII and CastLL::Ideal methods c58f5c67: 8282360: Merge POSIX implementations of ThreadCritical 0ae3d1d5: 8282131: java.time.ZoneId should be a sealed abstract class 4e7fb41d: 8282172: CompileBroker::log_metaspace_failure is called from non-Java/compiler threads 59b3ecc5: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName c7cd1487: 8282240: Add _name field to Method for NOT_PRODUCT only d983d108: 8275731: CDS archived enums objects are recreated at runtime 9d9618a3: 8282462: Remove unnecessary use of @SuppressWarnings("preview") 1f89acd8: 8282464: Remove author tags from java.compiler 77432663: 8281210: Add manpage changes for PAC-RET protection on Linux/AArch64 c1a28aa0: 8282392: [zero] Build broken on AArch64 e4d9fc81: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale d3022f87: 8282467: add extra diagnostics for JDK-8268184 22b93a31: 8282094: [REDO] Parallel: Refactor PSCardTable::scavenge_contents_parallel d4d12ad1: 8282047: Enhance StringDecode/Encode microbenchmarks 369291b2: 8282444: Module finder incorrectly assumes default file system path-separator character eff396f3: 8280713: Related to comment inheritance jdk.javadoc cleanup and refactoring 44d599aa: 8227369: pd_disjoint_words_atomic() needs to be atomic a95edee6: 8281472: JVM options processing silently truncates large illegal options values fcce24c5: 8281811: assert(_base == Tuple) failed: Not a Tuple after JDK-8280799 341c8bd7: 8267834: Refactor G1CardSetAllocator and BufferNode::Allocator to use a common base class 2c5d266f: 8282045: When loop strip mining fails, safepoints are removed from loop anyway 31b61f98: 8282311: Fix a typo in javax.lang.model.type.NullType 76398c84: 8279573: compiler/codecache/CodeCacheFullCountTest.java fails with "RuntimeException: the value of full_count is wrong." b03d66c5: 8282452: Use of Preview API in preview methods should not trigger preview warning for the enclosing class 8fec7b87: 8281548: Add escape analysis tracing flag 941e97c4: 8281738: Create a regression test for checking the 'Space' key activation of focused Button b86a8c00: 8282150: Drop redundant
elements from tables in java.desktop HTML files eac80214: 8282320: Remove case conversion for debugging log in SSLCipher 732d891f: 8282411: Add useful predicates to ElementKind fc52a218: 8282143: Objects.requireNonNull should be ForceInline ed3496e6: 8282480: IGV: Use description instead of enum name for phases 12a822a2: 8282381: Parallel: Remove unnecessary PCReferenceProcessor f12200cd: 8267796: vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java fails with NoClassDefFoundError d80f6971: 8282523: Fix 'hierachy' typo fc918a73: 8281234: The -protected option is not always checked in keytool and jarsigner 234c17e8: 8274788: Support archived heap objects in ParallelGC ce18ff85: 8282551: Properly initialize L32X64MixRandom state b6c35ae4: 8209784: Include hsdis in the JDK 1485883c: 8281628: KeyAgreement : generateSecret intermittently not resetting 02aa7cef: 8282515: More clean up on NativeLibraries just for JNI library use d0eb6fa2: 8281569: Create tests for Frame.setMinimumSize() method 2da67779: 8281122: [IR Framework] Cleanup IR matching code in preparation for JDK-8280378 b1f935c1: 8277055: Assert "missing inlining msg" with -XX:+PrintIntrinsics d4d1fbc2: 8282484: G1: Predicted old time in log always zero 0402a288: 8037965: NullPointerException in TextLayout.getBaselineFromGraphic() for JTextComponents 832729b4: 6911375: mouseWheel has no effect without vertical scrollbar 7822cbce: 8276711: compiler/codecache/cli tests failing when SegmentedCodeCache used with -Xint 5c187e34: 8282593: JDK-8281472 breaks 32-bit builds and gtests 57020fd5: 8282582: Unused methods in Utils 080baffa: 8282483: Ensure that Utils.getAllInterfaces returns unique instances c777bb3d: 8282619: G1: Fix indentation in G1CollectedHeap::mark_evac_failure_object 268fa693: 8282511: Use fixed certificate validation date in SSLExampleCert template 1581e3fa: 8282402: Create a regression test for JDK-4666101 fb6b929e: 8277474: jarsigner does not check if algorithm parameters are disabled 8478173d: 8282583: Update BCEL md to include the copyright notice 7e1c67d4: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 b629782b: 8279886: C1: Turn off SelectivePhiFunctions in presence of irreducible loops b3837808: 8282343: Create a regression test for JDK-4518432 d5e8e52f: 8282532: Allow explicitly setting build platform alongside --openjdk-target a584c904: 8282573: ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y) 52471539: 8282615: G1: Fix some includes 603050bf: 8282661: [BACKOUT] ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y) f9f9c0a8: 8252769: Warn in configure if git config autocrlf has invalid value 733c7907: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F 9c817d38: 8015854: [macosx] JButton's HTML ImageView adding unwanted padding e07fd395: 8281181: Do not use CPU Shares to compute active processor count b0028a45: 8272853: improve `JavadocTester.runTests` bae0d5e7: 8236907: JTable added to nested panels does not paint last visible row c459f8f4: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1 52278b80: 8282694: ProblemList runtime/CommandLine/VMDeprecatedOptions.java bc42e7cb: 8282382: Report glibc malloc tunables in error reports 974ef554: 8282617: sun.net.www.protocol.https.HttpsClient#putInKeepAliveCache() doesn't use a lock while dealing with "inCache" field 415bf441: 8275715: D3D pipeline processes multiple PaintEvent at initial drawing 894ffb09: 8282713: Invalid copyright notice in new test added by JDK-8275715 6fc73f70: 8282620: G1/Parallel: Constify is_in_young() predicates 104e3cb2: 8282696: Add constructors taking a cause to InvalidObjectException and InvalidClassException e544e354: 8282621: G1: G1SegmentedArray remove unnecessary template parameter 8e70f4c3: 8282224: Correct TIG::bang_stack_shadow_pages comments f0995abe: 8280404: Unexpected exception thrown when CEN file entry comment length is not valid ef266d77: 8278296: Generalize long range check transformation 7194097b: 8252577: HotSpot Style Guide should link to One-True-Brace-Style description 1faa5c80: 8282686: Add constructors taking a cause to SocketException 5953b229: 8257589: HotSpot Style Guide should link to rfc7282 2e298b8b: 8272691: Fix HotSpot style guide terminology for "non-local variables" 3996782c: 8281093: Violating Attribute-Value Normalization in the XML specification 1.0 5d5bf16b: 8282567: Improve source-date handling in build system ccad3923: 8282657: Code cleanup: removing double semicolons at the end of lines 50eb915a: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss cde923dd: 8282690: runtime/CommandLine/VMDeprecatedOptions.java fails after JDK-8281181 3f0684d0: 8275775: Add jcmd VM.classes to print details of all classes 8b45dbda: 8282312: Minor corrections to evbroadcasti32x4 intrinsic on x86 e6072872: 8282728: Serial: Remove unused BlockOffsetArray::Action 65ca0a57: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed "assert(!contains(edge->reference())) failed: invariant" 5fab27e1: 8282144: RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes c6d743fb: 8282770: Set source date in jib profiles from buildId 0f88fc18: 8282769: BSD date cannot handle all ISO 8601 formats 0cbc4b85: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle hidden classes correctly 3e4dfc63: 8282295: SymbolPropertyEntry::set_method_type fails with assert 2549e550: 8275640: (win) java.net.NetworkInterface issues with IPv6-only environments 3fc009be: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. 6b34884b: 8282234: Create a regression test for JDK-4532513 288d1afc: 8282715: typo compileony in test Test8005033.java 72e987e3: 7192189: Support endpoint identification algorithm in RFC 6125 ea19114e: 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh 49245131: 8265263: AArch64: Combine vneg with right shift count 12693a6c: 8282432: Optimize masked "test" Vector API with predicate feature 31ad80a2: 8280902: ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame d07f7c76: 8282665: [REDO] ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y) 5df2a057: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() 6d8d156c: 8280494: (D)TLS signature schemes 70318e1d: 8282884: Provide OID aliases for MD2, MD5, and OAEP ff766204: 8282641: Make jdb "threadgroup" command with no args reset the current threadgroup back to the default 8aba4de9: 8249592: Robot.mouseMove moves cursor to incorrect location when display scale varies and Java runs in DPI Unaware mode 5b78a82e: 7017094: ParsedSynthStyle: parameter name "direction" should be changed to "tabIndex" 6a3a7b94: 6218162: DefaultTableColumnModel.getColumn() method should mention ArrayIndexOutOfBoundsException 83d77186: 8282893: Remove MacroAssembler::push/pop_callee_saved_registers 9c88c5bb: 8282948: JDK-8274980 missed correct handling of MACOSX_BUNDLE_BUILD_VERSION 7c8ea9f0: 8282509: [exploded image] ResolvedClassTest fails with similar output 26747990: 8282878: Removed _JavaThread from PhaseTraceTime 1668c02e: 8277922: Unable to click JCheckBox in JTable through Java Access Bridge e8a1ce00: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException fdce97df: 8267820: (fs) Files.copy should attempt to copy POSIX attributes when target file in custom file system 879b6445: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c 1f295239: 8282932: a space is needed for the unsupported protocol exception message in ProtocolVersion b13cacc5: 8254574: PrintWriter handling of InterruptedIOException should be removed 7b91bbba: 8282170: JVMTI SetBreakpoint metaspace allocation test f5217b47: 8282852: Debug agent asserts in classTrack_addPreparedClass() bb7ee5a0: 8282314: nsk/jvmti/SuspendThread/suspendthrd003 may leak memory a5a1a32d: 8282883: Use JVM_LEAF to avoid ThreadStateTransition for some simple JVM entries 88f0938c: 8272493: Suboptimal code generation around Preconditions.checkIndex intrinsic with AVX2 1a5a496a: 8282763: G1: G1CardSetContainer remove intrusive-list details. cab9def1: 8282700: Properly handle several --without options during configure f99193ae: 8282811: Typo in IAE details message of `RecordedObject.getValueDescriptor` 95ca9443: 8282354: Remove dependancy of TestHttpServer, HttpTransaction, HttpCallback from open/test/jdk/ tests 0fd09d38: 8282978: Wrong parameter passed to GetStringXXXChars in various places 374193b6: 8283041: [javadoc] Crashes using {@return} with @param 5c408c14: 8282874: Bad performance on gather/scatter API caused by different IntSpecies of indexMap 3cf83a67: 8282572: EnumSet should be a sealed class fde31498: 8281375: Accelerate bitCount operation for AVX2 and AVX512 target. c0e3d107: 8283008: KRegister documentation out of date 01570ca9: 8283017: GHA: Workflows break with update release versions 5f3d4032: 8272735: Add missing SubL node transformations ea9eeea8: 8281322: C2: always construct strip mined loop initially (even if strip mining is disabled) 08573cc3: 8282529: Fix API Note in javadoc for javax.net.ssl.SSLSocket 13cebffe: 8058924: FileReader(String) documentation is insufficient c96085ea: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value 7833667f: 8282881: Print exception message in VM crash with -XX:AbortVMOnException 70bd57ed: 8283049: Fix non-singleton LoggerFinder error message: s/on/one f66070b0: 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile 5bf6a7f7: 8282691: add jdb "-R" option for passing any argument to the launched debuggee process a244051a: 8283062: Uninitialized warnings in libgtest with GCC 11.2 5ba5e21f: 8282214: Upgrade JQuery to version 3.6.0 6013d09e: 8268866: Javascript when used in an iframe cannot display search results 34d4ffce: 8279317: compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable code 710653ce: 8254786: java/net/httpclient/CancelRequestTest.java failing intermittently 2cddf3f5: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows 4de72014: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail on Big Endian Systems f43ffe21: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled 671b6efd: 8283143: Use minimal-length literals to initialize PI and E constants 05a83e03: 8283124: Add constant for tau to Math and StrictMath 12dca36c: 8283189: Bad copyright header in UnsafeCopyMemory.java 32f8437d: 8283075: Bad IllegalArgumentException message for out of range rank from ClassDesc.arrayType(int) ac06bdb1: 8282507: Add a separate license file for hsdis 1465ea98: 8282355: compiler/arguments/TestCodeEntryAlignment.java failed "guarantee(sect->end() <= tend) failed: sanity" bacfaa3e: 8282414: x86: Enhance the assembler to generate more compact instructions 27fe3d7f: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled 4df24c5d: 8283230: Improve @jls usage in ElementType de4f04cb: 8253495: CDS generates non-deterministic output 08cadb47: 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available 9b8afce3: 8283260: gcc is not supported on mac 0cf291bc: 8283234: Improve @jls usage in java.base 3e393047: 8281631: HashMap copy constructor and putAll can over-allocate table 3da5204b: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails with release VMs a5ebcc0c: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr 096bca4a: 8282473: Refactor swing classes javadoc to use @throws instead of @exception 249d5536: 8282602: Refactor awt classes javadoc to use @throws instead of @exception beedae11: 8281146: Replace StringCoding.hasNegatives with countPositives bad658e8: 8282727: Parallel: Remove PSPromotionManager::_totally_drain 69e4e338: 8283056: show abstract machine code in hs-err for all VM crashes 0f1766df: 8283320: Error message for Windows libraries always points to --with-msvcr-dll no matter the actual file name 31df6a60: 8283188: Build time regression caused by JDK-8278917 5ef1990d: 8283274: Improve @jvms usage in java.base b004fb05: 8282773: Refactor parsing of integer VM options 002e3667: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive d83cee98: 8282407: Missing ')' in MacResources.properties cab4ff64: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) b96cb048: 8283353: compiler/c2/cr6865031/Test.java and compiler/runtime/Test6826736.java fails on x86_32 b47f6c00: Moving guards to switches. 2f02c93a: Moving guards to cases. 78a3fb24: Merge branch 'case-guard' into type-patterns-third e92ca08f: Updating null handling. 5e0f5587: Merge branch 'switch-null' into type-patterns-third From jlahoda at openjdk.java.net Tue Mar 22 09:32:17 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 22 Mar 2022 09:32:17 GMT Subject: git: openjdk/amber: created branch patterns-record-deconstruction3 based on the branch type-patterns-third containing 142 unique commits Message-ID: <395ac14d-a730-426e-adef-c7d6fee47a2f@openjdk.org> The following commits are unique to the patterns-record-deconstruction3 branch: ======================================================== 5227516d: Branching for pattern-runtime 12167265: Initial implementation of PatternHandle and friends 3d62c4e9: Automatic merge with default 110bb836: Updates to pattern match tests 447ad742: Temporary testing support for RecordTest e2287af8: 8216977: ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken b4c63048: 8230302: GenerateJLIClassesPlugin can generate invalid DirectMethodHandle methods d607548f: 8230338: Accurate error message about bad Unicode block name 1bc974d8: 8229210: [TESTBUG] Move gc stress tests from JFR directory tree to gc/stress b6fac7fe: 8229284: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage 470d32df: 8182119: jdk.hotspot.agent's META-INF/services/com.sun.jdi.connect.Connector no longer needed 6d4ef5aa: 8229999: Apply java.io.Serial annotations to security types in java.base 647e4d75: 8230037: Confused MetaData dumped by PrintOptoAssembly b6b6a37f: 8230109: G1DirtyCardQueueSet should use card counts rather than buffer counts 489f8027: 8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as Unknown 6d064a74: 8230332: G1DirtyCardQueueSet _notify_when_complete is always true 9d764ee4: 8229997: Apply java.io.Serial annotations in java.base 6a48a4e5: 8229797: [JVMCI] Clean up no longer used JVMCI::dependencies_invalid value c7f0ae07: 8230376: [TESTBUG] runtime/StackTrace/HiddenFrameTest.java fails with release VM 3149ed49: 8230203: Replace markWord enums with typed constants 647f4875: 8230004: jdk/internal/jimage/JImageOpenTest.java runs no test 05d4e7a2: 8230388: Problemlist additional compiler/rtm tests 277ef756: 8230307: ZGC: Make zGlobals and zArguments OS agnostic 1d71dd86: 8230105: -XDfind=diamond crashes 6fa4babb: 8230310: SocksSocketImpl should handle the IllegalArgumentException thrown by ProxySelector.select usage aa5d8f64: 8193596: java/net/DatagramPacket/ReuseBuf.java failed due to timeout 79c14f08: 8230390: Problemlist SA tests with AOT 1668370d: 8230327: Make G1DirtyCardQueueSet free-id init unconditional f14e2135: 8230337: Clarify intention of Elements.{getPackageOf, getModuleOf} 448e0030: 8227224: GenCollectedHeap: add subspace transitions for young gen for gc+heap=info log lines a72d25fc: 8230372: Remove G1GCPhaseTimes::MergeLBProcessedBuffers 2399a8d7: 8230373: Use java.io.Serial in generated exception types b7821ad3: 8224214: [AIX] Remove support for legacy xlc compiler 5110530d: 8230238: Add another regression test for JDK-8134739 77adc77c: 8229235: com.sun.net.httpserver.HttpExchange should implement AutoCloseable c25e2fd8: 8230425: Shenandoah forces +UseNUMAInterleaving even after explicitly disabled e77e5da7: 8229422: Taskqueue: Outdated selection of weak memory model platforms 8f9d63df: 8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant 4e434861: 8227411: TestTimeMultiple.java failed "assert(!lease()) failed: invariant" 5ded63ef: Merge 47e00558: 8230428: Cleanup dead CastIP node code in formssel.cpp 6b2e444a: 8223714: HTTPSetAuthenticatorTest could be made more resilient fd89fedc: 8230483: Shenandoah: consistently disable concurrent roots for Traversal mode 4dc79c2e: 8227236: assert(singleton != __null && singleton != declared_interface) failed 99c17fbf: 6313903: Thread.sleep(3) might wake up immediately on windows dfe4ba50: 8226221: Update PKCS11 tests to use NSS 3.46 libs 7cb28198: 8230485: add handling of aix tar in configure a41b9a71: 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 bb635584: 8230431: Move G1 trace code from gcTrace* to G1 directory f7d0ece0: 8209802: Garbage collectors should register JFR types themselves to avoid build errors b0e72712: 8230434: [C1, C2] Release barrier for volatile field stores in constructors implemented inconsistently ea436110: 8230401: ClassLoaderData::_keep_alive is read with wrong type in c2i entry barrier 0a92dc78: 8229450: C2 compilation fails with assert(found_sfpt) failed 662348c7: 8230159: Add test to verify that com.sun.net.httpserver.BasicAuthenticator constructors throw expected exceptions 7b49c40e: 8171405: java/net/URLConnection/ResendPostBody.java failed with "Error while cleaning up threads after test" f71db307: 8230435: Replace wildcard address with loopback or local host in tests - part 22 39465f49: 8230624: [TESTBUG] Problemlist JFR compiler/TestCodeSweeper.java 7004b3f3: 8230626: Make UnknownFooException strings more informative cc268aa7: Added tag jdk-14+13 for changeset fbbe6672ae15 655cf141: 8228967: Trust/Key store and SSL context utilities for tests d19e6eae: 8229189: Improve JFR leak profiler tracing to deal with discontiguous heaps f869706f: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() 4b65e2b3: 8230642: 8224815 broke Shenandoah build 5c4be9cc: 8230466: check malloc/calloc results in jdk.hotspot.agent 2fa3eddd: 8177068: incomplete classpath causes NPE in Flow a4b46ccc: 8229496: SIGFPE (division by zero) in C2 OSR compiled method 675eecaa: 8230646: Epsilon does not extend TLABs to max size 77b3801f: 8228854: Default ErrorListener reports warnings and errors to the console a1002d68: 8230632: [TESTBUG] appcds/NonExistClasspath.java and ClassPathAttr.java failed when running in hotspot_appcds_dynamic test group d2db14b8: 8229280: Test failures on several linux hosts after JDK-8181493 474d164d: Automatic merge with default 740b888a: Automatic merge with default dfc13e89: [pattern-runtime] manual merge to by-pass bad changeset 8f29150a: [pattern-runtime] manual merge with default 73aee53e: Automatic merge with default b26e7bfd: Automatic merge with default fc7be875: Automatic merge with default e204607a: Automatic merge with default 744a2376: Automatic merge with default 0682db0e: Adding pattern-runtime 223c356a: Rebasing the prototype of deconstruction patterns 16f70d1c: Adding deps files d073a938: Cleanup 5bcd6488: Fixing (again) pattern targets ecaaade6: Automatic merge with default 05b05c0a: Merging default branch into patterns-stage-2 44c837c2: Simplifications for the patterns-stage-2 branch 931c5e3b: Merging recent default branch changes into patterns-stage-2 92425861: Automatic merge with default e4964202: Cleanup - undoing unnecessary changes 74dd28d0: Automatic merge with default c9dc7587: Various improvements related to deconstruction patterns 41a83d00: Automatic merge with default 8142133e: Patterns stage 2: more cleanup c9c5c95d: Adding error when the are too little or too many deconstruction parameters 487a20b5: Fixing owners of synthetic pattern-related symbols c0fb53e7: Correcting deduplication related to deconstruction patterns 7eda6983: Reflecting review comments df80c11a: Cleanup desugaring comments, as suggested on the review ddb3dac2: Fixing out file 1b489ca9: Fixing handling of generic records 6c629ca8: Automatic merge with default 24d76483: Automatic merge with default 5b1da0a5: 8242624: Update .jcheck/conf for project Amber (patterns-stage-2) a3d67137: Automatic merge of master into patterns-stage-2 ae6aac36: Automatic merge of master into patterns-stage-2 febdf12e: Automatic merge of master into patterns-stage-2 79803158: Automatic merge of master into patterns-stage-2 21ad424e: Automatic merge of master into patterns-stage-2 ff3d0c61: Automatic merge of master into patterns-stage-2 a6e3357b: Automatic merge of master into patterns-stage-2 60a1cd85: Automatic merge of master into patterns-stage-2 3eeebaa5: manual merge 3fe12cd2: Merge pull request #29 from openjdk-bot/49 01977468: Automatic merge of master into patterns-stage-2 86d0fa54: manual merge 907c29ac: Merge pull request #34 from openjdk-bot/56 8ed30d4b: Automatic merge of master into patterns-stage-2 4cc4481a: Automatic merge of master into patterns-stage-2 08c1b8c8: Automatic merge of master into patterns-stage-2 11ccff3f: Automatic merge of master into patterns-stage-2 08d218ed: Automatic merge of master into patterns-stage-2 d3afb554: Automatic merge of master into patterns-stage-2 53dc30b2: Automatic merge of master into patterns-stage-2 8841dbe4: Automatic merge of master into patterns-stage-2 0ddfcd45: Automatic merge of master into patterns-stage-2 3a960eda: Automatic merge of master into patterns-stage-2 a83d117f: Automatic merge of master into patterns-stage-2 f8a68ca5: Automatic merge of master into patterns-stage-2 4620e676: Automatic merge of master into patterns-stage-2 4239ce43: Automatic merge of master into patterns-stage-2 33fb461b: Merging master into patterns-record-deconstruction 786057dd: First version of array patterns 2e1a6bbe: Merging master into patterns-record-deconstruction-array 6b7ca2bf: First attempt to include exhaustiveness for deconstruction patterns cd5e696b: Merge branch 'master' into patterns-record-deconstruction-array 8cfd8b8a: Merging master into patterns-record-deconstruction-array 6de23315: Removing array patterns. 3cae577d: Moving guards to cases. da542900: Cleanup. 6bdb98df: Improving handling of parameterized record deconstruction. 708b7c6a: Merging type-patterns-third into patterns-record-deconstruction3 From ice1000kotlin at foxmail.com Tue Mar 22 20:13:47 2022 From: ice1000kotlin at foxmail.com (=?utf-8?B?VGVzbGEgWmhhbmc=?=) Date: Tue, 22 Mar 2022 16:13:47 -0400 Subject: Empty exhaustive switches and the ability to refine type variables Message-ID: Greetings, I asked if empty switch (the switched expression has an uninhabitable type so no case clause is needed) would be possible because the second preview of switch expressions allows refuting patterns, and Brian told me it's 'unlikely', see https://mail.openjdk.java.net/pipermail/amber-dev/2021-November/007161.html. I still don't understand why it's unlikely, because for example sealed interface I References: Message-ID: I think I may have misunderstood your earlier question.? An uninhabitable switch is one over a sealed type for which none of the type patterns apply, such as: ??? sealed interface X { } ??? final class A implements X {} ??? final class B implements X {} ??? X x = ... ??? switch (x) { ??????? // none of the subtypes of X are applicable ??? } So this would fall out as a natural consequence of eliminating inapplicable choices. In any case, the issues surrounding GADTs are more than just exhaustiveness; you mention type refinement, and there are also other consequences for type checking.? These are going to take a while to work through.? Rest assured they're on our radar. On 3/22/2022 4:13 PM, Tesla Zhang wrote: > Greetings, > > I asked if empty switch (the switched expression has an uninhabitable type so no case clause is needed) would be possible because the second preview of switch expressions allows refuting patterns, and Brian told me it's 'unlikely', seehttps://mail.openjdk.java.net/pipermail/amber-dev/2021-November/007161.html. I still don't understand why it's unlikely, because for example > > > sealed interface I record R() implements I > > The switch should be well-typed without any case, which is a counterexample. > > > Apart from that, Brian also mentioned a 'probable bug' in https://mail.openjdk.java.net/pipermail/amber-dev/2021-November/007156.html related to casting refinable types, is that addressed now? I explored the mailing list archive but I didn't find relevant discussions. I think it would be very nice for javac to be able to refine a local type. > > > Best regards, > Tesla From ice1000kotlin at foxmail.com Tue Mar 22 21:05:35 2022 From: ice1000kotlin at foxmail.com (=?utf-8?B?VGVzbGEgWmhhbmc=?=) Date: Tue, 22 Mar 2022 17:05:35 -0400 Subject: Empty exhaustive switches and the ability to refine type variables Message-ID: Thanks!! That's great to hear. Regards, Tesla ---Original--- From: "Brian Goetz" Hi, There is a new draft JEP for preview 3 of Pattern Matching for switch here: https://bugs.openjdk.java.net/browse/JDK-8282272 The current ideas for improvements over the previous round are to remove guarded patterns and replace them with a "when" clause for the cases, and adjusting null handling more to the null handling in existing switches. Feedback is welcome! Thanks! ??? Jan From ice1000kotlin at foxmail.com Wed Mar 23 18:49:16 2022 From: ice1000kotlin at foxmail.com (=?utf-8?B?VGVzbGEgWmhhbmc=?=) Date: Wed, 23 Mar 2022 14:49:16 -0400 Subject: Pattern matching for switch (Third Preview) In-Reply-To: <2005744e-a331-6a99-0b42-f5371e102ec5@oracle.com> References: <2005744e-a331-6a99-0b42-f5371e102ec5@oracle.com> Message-ID: Hi, I have two confusions about the new JEP: 0. I noticed a `<>` operator, is that a typo? 1. What's the motivation of replacing `??` with a new soft keyword? What's bad about `??`? Best regards, Tesla ------------------ Original ------------------ From: "Jan Lahoda" References: <2005744e-a331-6a99-0b42-f5371e102ec5@oracle.com> Message-ID: <587324ab-31bc-4c41-1978-ff6bb4626af4@oracle.com> > 0. I noticed a `<>` operator, is that a typo? Likely a rendering artifact; the markdown renderer in the bug system is different from that of the OpenJDK website, which ultimately is the definitive view. > 1. What's the motivation of replacing `??` with a new soft keyword? What's bad about `??`? This was discussed on the amber-spec-experts list in January; see threads rooted at "reviewing feedback on patterns in switch".? The key part of this change is not the syntactic change from && to `when`, but moving the refinement from the pattern itself, to the switch.? The change in syntax follows naturally from this change in location. FWIW, adjoining guards to patterns has some nasty surprises lurking, which we knew about but convinced ourselves we could ignore at first.? For example, if we ever have switches over boolean (which we surely will, as pattern matching has been a forcing function for regularizing all aspects of switch, and this one will surely come), you can then get some bizarre combinations, which don't mean what you think they mean, like: ??? switch (aBoolean) { ? ?? ?? case false && false:? // will never be selected! ??????? ... ??? } In the design discussion for this feature, we went back and forth several times between refining patterns and refining switch cases, since there were pros and cons of each.? In the end, it felt like refinement fit more cleanly in the conditional construct (switch) than in the pattern machinery.? This is why we do previews; to give decisions a chance to settle. From ice1000kotlin at foxmail.com Wed Mar 23 19:14:03 2022 From: ice1000kotlin at foxmail.com (=?utf-8?B?VGVzbGEgWmhhbmc=?=) Date: Wed, 23 Mar 2022 15:14:03 -0400 Subject: Pattern matching for switch (Third Preview) In-Reply-To: <587324ab-31bc-4c41-1978-ff6bb4626af4@oracle.com> References: <2005744e-a331-6a99-0b42-f5371e102ec5@oracle.com> <587324ab-31bc-4c41-1978-ff6bb4626af4@oracle.com> Message-ID: Hi Brian, Thanks for the quick reply! Two more small things: 0. I also see the `<>` in https://openjdk.java.net/jeps/8282272 as well :/ 1. Is the 'allow null' thing aimed at adding `null` to all possible switches, so we cannot have empty switches (as `null` becomes an always-possible case candidate)? Best regards, Tesla ------------------ Original ------------------ From: "Brian Goetz" References: <2005744e-a331-6a99-0b42-f5371e102ec5@oracle.com> <587324ab-31bc-4c41-1978-ff6bb4626af4@oracle.com> Message-ID: <187e99fd-2369-6cb4-e3ae-f21d090ac574@oracle.com> > 1. Is the 'allow null' thing aimed at adding `null` to all possible switches, so we cannot have empty switches (as `null` becomes an always-possible case candidate)? No. Historically, switches are null-hostile.? This was a mostly sensible choice when the reference types that switch accepted were (a) very limited and (b) types for which null was almost certainly an error (e.g., Integer), but as switch gets more general, this restriction increasingly appears arbitrary.? We are constrained by compatibility to retain the legacy behavior, so the new treatment of null is effectively opting into null by saying "case null" somewhere in the switch.? An empty switch has no "case null".? And even if it were, null would fall into the "remainder" (just as novel subclasses of sealed types are, as well as some other weird shapes) and be rejected via remainder rejection. So the null treatment does not interact with exhaustiveness checking in any meaningful way. From ice1000kotlin at foxmail.com Wed Mar 23 19:52:51 2022 From: ice1000kotlin at foxmail.com (=?utf-8?B?VGVzbGEgWmhhbmc=?=) Date: Wed, 23 Mar 2022 15:52:51 -0400 Subject: Pattern matching for switch (Third Preview) In-Reply-To: <187e99fd-2369-6cb4-e3ae-f21d090ac574@oracle.com> References: <2005744e-a331-6a99-0b42-f5371e102ec5@oracle.com> <587324ab-31bc-4c41-1978-ff6bb4626af4@oracle.com> <187e99fd-2369-6cb4-e3ae-f21d090ac574@oracle.com> Message-ID: Hi Brian, Very nice!!! This is exactly the design that makes the most sense to me. Thank you people for the great work!! Btw, I think it would be nice to have less keywords, so what about reusing `if` instead of introducing the new contextual keyword `when`? This should probably help with parsing (and since `if` works only in statements, this is probably unambiguous both for the compiler and to a human). Best regards, Tesla ------------------ Original ------------------ From: "Brian Goetz" References: <2005744e-a331-6a99-0b42-f5371e102ec5@oracle.com> <587324ab-31bc-4c41-1978-ff6bb4626af4@oracle.com> <187e99fd-2369-6cb4-e3ae-f21d090ac574@oracle.com> Message-ID: <8731be23-b753-9bc4-bd77-b437ec169493@oracle.com> > Btw, I think it would be nice to have less keywords, so what about reusing `if` instead of introducing the new contextual keyword `when`? This should probably help with parsing (and since `if` works only in statements, this is probably unambiguous both for the compiler and to a human). This was discussed.? The primary argument in favor of this is "keyword reuse", but keyword reuse is often a false economy, and people are inclined to over-rotate on this. Some of the downsides were: > > ?- The generality of "if" reminded people of the Perl-style "statement > unless condition" postfix convention, and that people might see it as > an "inconsistency" that they could not then say > > ?? x = 3 if (condition); > > which is definitely somewhere we don't want to go. > > > ?- We're use to seeing "if" with a consequence, and a "naked" if might > have the effect of "lookahead pollution" in our mental parsers. > > > ?- Keeping `if` for statements allows us to keep the "body" of case > clauses visually distinct from the "envelope": > > ??? case Foo(var x) > ??? if (x > 3) : if (x > 10) { ... } > > would make people's eyes go buggy.? One could argue that "when" is not > fantastically better: > > ??? case Foo(var x) > ??? when (x > 3) : if (x > 10) { ... } > > but it doesn't take quite as long to de-bug oneself in that case. To which I'll add: `when` is more in line with what other languages with a similar construct do. From tanksherman27 at gmail.com Thu Mar 24 02:29:00 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 24 Mar 2022 10:29:00 +0800 Subject: Java Enhancement Proposal: Field Accessors Message-ID: Hi all, It would be appreciated if I could get feedback and refinements on the current Amber JEP draft. Thanks and have a great day! :) best regards, Julian Summary ------- Enhance Java with language level field accessors. Accessors provide an easy way to define logic for setting and retrieving field values in what would otherwise be a tedious process of writing multiple methods (with potential overloads) Goals ----- It is intended for this new feature to work with full compatibility with existing manually defined methods, as well as with inheritance and subclass overriding, and to provide a clean way to define accessors with different signatures. Motivation ---------- >From JEP-395: "It is a common complaint that "Java is too verbose" or has "too much ceremony"." Currently, if one wishes to have private fields with public methods to modify them, it is required to write at least one getter and setter. In the worst case, it is required to write multiple copies of the exact same method if there need to be multiple overloads. This eventually becomes overly tedious or error prone, and a common desire is that Java had cleaner syntax for such field access. It may be tempting to ask why direct field modification is not then used instead, but accessing a field through methods allows custom logic to be executed, which is particularly useful for state checking and possibly returning or setting a different value if the situation call for it. Other languages, such as Kotlin and C#, have dedicated syntax for such "getters and setters", but their approach only allows for one such set to be specified, and no extra parameters other than the built in ones are allowed. We should not abandon the flexibility overloads in Java provide for the sake of such a feature, so we'll need an approach that combines the compactness of other such languages with the more Java-esque method style for full flexibility and ease of use. Description ----------- The current proposal proposes the syntax for field accessors as follows: // Getters have the same name as the field // Setters have the name of set private long field = 0 { // Getter, leave semicolons after return to define a getter without running any custom logic, or a block if custom logic is required return; // Getter that executes custom logic // If no return is specified in the getter, it will implicitly return the field bound to it // after executing the body return { /*Code here*/ } // Getter that explicitly returns a value using a return statement in the body // Note that "this" refers to the field and not the containing class // To explicitly access the containing class, use KlassName.this return { return this; }; // Getter that returns another field instead of this one. Note that KlassName.this is // not required to access other fields in the class; It serves the same purpose as // regular usages of "this": To differentiate fields defined in the class itself and // local variables // Note that the other field MUST have the same type // as the one the accessor is bound to return { return KlassName.this.otherField } // Getter overloaded with custom signature // Note: No getter or setter can share the same signature return(Klass klass) {} // Return random literal return { return 42L; } // Accessors can call their own overloads too, if // required // If an accessor calls its own overload, the implicit // setting or getting is disabled. return { field(); } // Setter, leave as is to implicitly set field to value without any custom logic // Note that the type and name do not need to be set, the type is already inferred // and the name is not needed unless it has to be referred to in a body with custom // logic new; // Setter that executes body before assigning a value to the field // Like Getters, Setters execute the body first before setting the field, unless the order // is customized by setting "this" to another value explicitly new { /*Code*/ } // Setter that accepts parameters. Method signature when being called will be (valueToSet, ...) new(KlassName otherType) {} // Accessors can call their own overloads too, if // desired // If an accessor calls its own overload, the implicit // setting or getting is disabled. new { setField(5); } // Setter with access to the value being sent to set the field // Type is automatically inferred, but can be set if desired for whatever reason new(value) -> {} // Setter with both access to the new value and more parameters new(value) -> (KlassName otherType) {} // Setter that explicitly sets the field // Normally the field is set implicitly if nothing is assigned to "this" in the body new(value) -> { this = value; } // Setter with a return type. By default, setters are void // Both setters and getters can be marked as final in the same manner with the "final" // keyword char new { return 'c'; } } // To override the getter/setter in subclasses, if possible // Eg not marked as final // Type is immediately inferred, but can be explicitly specified before the identifier if // there are other fields with the same name but different type // This is only possible if those fields have getters or setters super field { // Syntax is the same as above } // Note that overriding getters or setters defined by // this new syntax can be done in the typical // way, if desired, and vice versa @Override public long field() { /*Logic*/ } @Override public void setField(long value) { /*Logic*/ } The above are all ultimately implemented as normal methods, making supporting them relatively easy and requiring little change to javac as a whole, and also means that any accessor can be overridden by subclasses with regular methods with the correct name and signature, as shown above (Unless marked final) Currently, there is no proposal for static fields. This can hopefully be worked on as discussion around this JEP progresses Alternatives ------------ The Lombok project has annotations that can be added to fields to automatically generate getters and setters, however this would require developers to install a third party library, when native language support would be much more efficient to work with. Additionally, Lombok's field annotations can only generate one set of methods and do not allow for overloads, making it much less flexible than the currently proposed syntax. Alternatively, we could continue to stick to Java's traditional way of directly writing methods, but developers often find such an approach rather tedious, and the amount of boilerplate required with this approach can make it ultimately more error prone. Risks and Assumptions --------------------- This JEP assumes that developers have prior knowledge of accessors, and will not have any issues making their code work with the new language feature. From brian.goetz at oracle.com Thu Mar 24 13:46:34 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 24 Mar 2022 09:46:34 -0400 Subject: Java Enhancement Proposal: Field Accessors In-Reply-To: References: Message-ID: The topic of "properties in Java" has a long and fraught history.? Many attempts have been made in the past to lick this third rail.? Such discussions usually have a predicable trajectory; initially there appears to be broad desire for such a feature, but then when the discussions get into the details, it turns out there isn't much support for *this* variant of the feature, or there are design wars over which design is better, because everyone knows that at most one will be selected.? The most bitter and nasty e-mails in "Project Coin" were those between proponents of competing properties proposals. This proposal remixes a number of existing ideas (e.g., borrows from C#'s property syntax), plus seizes on the precedent of records (where declarations in one place turn into synthetic methods and other members.) Such proposals historically have had to deal with a number of challenges: ?- It is extremely difficult to do this in a way that doesn't just feel like a "macro generator" nailed on the side of the language; ?- It has a high syntax-to-semantics ratio, meaning that such proposals usually die in a bikeshed fire; ?- Invariably there are an infinite stream of enhancement requests to "tune" the "macro expansion" -- accessibility modifiers, tuning the name generation, implicit adaptation (e.g., String field, Optional accessors), validation (most frequently null checks), related boilerplate features (builders, generation of Object methods), constructors and factories, derived properties (accessors not mapped to a specific field), etc; ?- Such proposals tend to have a lot of detail but relatively little "depth", offering a poor return on complexity; - It is "fighting the last war", in that the model of "every class should have getters and setters for their fields" is finally starting to fade; ?- The concept of accessors as ordinary methods is inherently lossy.? While the author understands that `getX` and `setX` are related somehow, the language, and reflection libraries, do not.? (It's what we have; the choice to separate field and method namespaces slammed the door pretty much forever on first-class properties.) Additionally, we confronted a lot of these issues when we did records.? We looked at all the popular "macro generator" and properties libraries (e.g., Lombok, Joda Beans, Immutables, etc), and asked ourselves which of the features from these libraries belonged in records.? We struggled with the concept of accessors, and whether the record treatment of accessors (as well as other features) could scale to arbitrary classes. We made a number of decisions during the design of records that may be informative here, including: ?- The language does not get in the business of naming conventions.? Records have public constructors and no factories largely because factories are not a language feature, they are merely a convention.? It would have have been acceptable for the language to bless an arbitrary name like "of" for factories.? If factories had been a language feature, records might have leaned on them; in fact, during the design of records, we explored a number of interpretations of "factories as a language feature", but in the end, decided to prune that branch of inquiry.? (Some might want to argue that even picking `x()` as the accessor name for field `x` was getting into the naming convention business, but this usually turns out to be arguing for its own sake.)? We also considered how, if we extended the read accessors from records to arbitrary classes, what the story might be for setters.? Your choice of `setX` falls afoul of this principle (as did many of the alternatives we explored.) ?- The stable number of "tuning knobs" is zero.? For every not-always-perfect decision we made with records, someone always wants to propose "just one" option for tuning it (e.g., "the factory name is `newFoo`", "exclude this component from the equals computation", etc).? The only stable number of such knobs is zero; once there is one, there will be many, and you will have turned the language into Lombok.? A language feature that requires many knobs (whether keywords, annotations, "convention over configuration", etc) is probably the wrong design; leave that for code generators. On 3/23/2022 10:29 PM, Julian Waters wrote: > Hi all, > > > It would be appreciated if I could get feedback and refinements > > on the current Amber JEP draft. > > > Thanks and have a great day! :) > > > best regards, > > Julian > > > Summary > ------- > > Enhance Java with language level field accessors. > > Accessors provide an easy way to define logic for setting > > and retrieving field values in what would otherwise be a > > tedious process of writing multiple methods (with potential > > overloads) > > Goals > ----- > > It is intended for this new feature to work with full > > compatibility with existing manually defined methods, > > as well as with inheritance and subclass overriding, > > and to provide a clean way to define accessors with > > different signatures. > > > Motivation > ---------- > > From JEP-395: "It is a common complaint that > > "Java is too verbose" or has "too much ceremony"." > > > Currently, if one wishes to have private fields with > > public methods to modify them, it is required to write > > at least one getter and setter. In the worst case, it > > is required to write multiple copies of the exact same method > > if there need to be multiple overloads. This eventually > > becomes overly tedious or error prone, and a common desire > > is that Java had cleaner syntax for such field access. It > > may be tempting to ask why direct field modification is not > > then used instead, but accessing a field through methods > > allows custom logic to be executed, which is particularly > > useful for state checking and possibly returning or setting > > a different value if the situation call for it. Other > > languages, such as Kotlin and C#, have dedicated syntax > > for such "getters and setters", but their approach only > > allows for one such set to be specified, and no extra > > parameters other than the built in ones are allowed. We > > should not abandon the flexibility overloads in Java > > provide for the sake of such a feature, so we'll need an > > approach that combines the compactness of other such > > languages with the more Java-esque method style for full > > flexibility and ease of use. > > > Description > ----------- > > > The current proposal proposes the syntax for field > > accessors as follows: > > > // Getters have the same name as the field > // Setters have the name of set > > private long field = 0 { > // Getter, leave semicolons after return to define a getter > without running any custom logic, or a block if custom logic is > required > return; > > // Getter that executes custom logic > // If no return is specified in the getter, it will implicitly > return the field bound to it > // after executing the body > return { /*Code here*/ } > > > // Getter that explicitly returns a value using a return statement > in the body > // Note that "this" refers to the field and not the containing class > // To explicitly access the containing class, use KlassName.this > return { return this; }; > > // Getter that returns another field instead of this one. Note > that KlassName.this is > // not required to access other fields in the class; It serves the > same purpose as > // regular usages of "this": To differentiate fields defined in > the class itself and > // local variables > > // Note that the other field MUST have the same type > > // as the one the accessor is bound to > return { return KlassName.this.otherField } > > // Getter overloaded with custom signature > // Note: No getter or setter can share the same signature > return(Klass klass) {} > > > // Return random literal > > return { return 42L; } > > > // Accessors can call their own overloads too, if > > // required > > // If an accessor calls its own overload, the implicit > > // setting or getting is disabled. > > return { field(); } > > // Setter, leave as is to implicitly set field to value without > any custom logic > // Note that the type and name do not need to be set, the type is > already inferred > // and the name is not needed unless it has to be referred to in a > body with custom > // logic > new; > > // Setter that executes body before assigning a value to the field > // Like Getters, Setters execute the body first before setting the > field, unless the order > // is customized by setting "this" to another value explicitly > new { /*Code*/ } > > > // Setter that accepts parameters. Method signature when being > called will be (valueToSet, ...) > new(KlassName otherType) {} > > > // Accessors can call their own overloads too, if > > // desired > > // If an accessor calls its own overload, the implicit > > // setting or getting is disabled. > > new { setField(5); } > > // Setter with access to the value being sent to set the field // Type is > automatically inferred, but can be set if desired for whatever reason > new(value) -> {} // Setter with both access to the new value and more > parameters new(value) -> (KlassName otherType) {} // Setter that explicitly > sets the field // Normally the field is set implicitly if nothing is > assigned to "this" in the body new(value) -> { this = value; } // Setter > with a return type. By default, setters are void // Both setters and > getters can be marked as final in the same manner with the "final" // > keyword char new { return 'c'; } } // To override the getter/setter in > subclasses, if possible > > // Eg not marked as final > > // Type is immediately inferred, but can be explicitly specified > before the identifier if > // there are other fields with the same name but different type > // This is only possible if those fields have getters or setters > super field { > // Syntax is the same as above > } > > // Note that overriding getters or setters defined by > > // this new syntax can be done in the typical > // way, if desired, and vice versa > @Override > public long field() { /*Logic*/ } > > > @Override > public void setField(long value) { /*Logic*/ } > > > The above are all ultimately implemented as normal methods, > > making supporting them relatively easy and requiring > > little change to javac as a whole, and also means that > > any accessor can be overridden by subclasses with regular > > methods with the correct name and signature, as shown above > > (Unless marked final) > > > Currently, there is no proposal for static fields. This can > > hopefully be worked on as discussion around this JEP progresses > > > Alternatives > ------------ > > The Lombok project has annotations that can be added > > to fields to automatically generate getters and setters, > > however this would require developers to install a third > > party library, when native language support would be much > > more efficient to work with. Additionally, Lombok's field > > annotations can only generate one set of methods and do not > > allow for overloads, making it much less flexible than the > > currently proposed syntax. Alternatively, we could continue > > to stick to Java's traditional way of directly writing > > methods, but developers often find such an approach rather > > tedious, and the amount of boilerplate required with this > > approach can make it ultimately more error prone. > > > Risks and Assumptions > --------------------- > > This JEP assumes that developers have prior knowledge of > > accessors, and will not have any issues making their code > > work with the new language feature. From tanksherman27 at gmail.com Fri Mar 25 03:30:30 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Fri, 25 Mar 2022 11:30:30 +0800 Subject: Java Enhancement Proposal: Field Accessors In-Reply-To: References: Message-ID: Hi Brian, thanks for the review, The current JEP was written with 395's records in mind and aimed to have naming matching as closely as possible to the synthetic methods generated for records. Since records simply reused the name of the field, I assumed that adding a "set" in front for write methods was acceptable. I also notice that a lot of the issues faced seem to be related to the syntax and boilerplate/tuning, as you mentioned. In that instance we could ditch the syntactically heavy declarations that turn into synthetic methods for a more concise way to write accessor methods for fields without having to repeat the typical method boilerplate over and over (and in turn avoiding the naming conundrum brought up previously), indeed the ultimate goal of this JEP is to reduce repeated boilerplate for accessors and does not mind the manner it achieves it in. I don't quite get why "The concept of accessors as ordinary methods is inherently lossy" though, could you elaborate slightly more on that? The current proposal does not really mean to introduce first class properties like those seen in other language like Kotlin and C# (although it is similar in a sense) since those have a whole set of limitations that come alongside such an approach, which I personally hope we can rectify in Java with the power of conventional method overloads Thanks for your reply, appreciate it and I apologize if this took up a lot of your time P.S. This was also written in relation to Amber's with expressions draft, which mentions accessors as a possible future language feature, which is why I decided to send this JEP here. On a side note, I personally think we can do away with the with (no pun intended) and just have braces directly after for that particular draft. best regards, Julian On Thu, Mar 24, 2022 at 9:46 PM Brian Goetz wrote: > The topic of "properties in Java" has a long and fraught history. Many > attempts have been made in the past to lick this third rail. Such > discussions usually have a predicable trajectory; initially there appears > to be broad desire for such a feature, but then when the discussions get > into the details, it turns out there isn't much support for *this* variant > of the feature, or there are design wars over which design is better, > because everyone knows that at most one will be selected. The most bitter > and nasty e-mails in "Project Coin" were those between proponents of > competing properties proposals. > > This proposal remixes a number of existing ideas (e.g., borrows from C#'s > property syntax), plus seizes on the precedent of records (where > declarations in one place turn into synthetic methods and other members.) > > Such proposals historically have had to deal with a number of challenges: > > - It is extremely difficult to do this in a way that doesn't just feel > like a "macro generator" nailed on the side of the language; > > - It has a high syntax-to-semantics ratio, meaning that such proposals > usually die in a bikeshed fire; > > - Invariably there are an infinite stream of enhancement requests to > "tune" the "macro expansion" -- accessibility modifiers, tuning the name > generation, implicit adaptation (e.g., String field, Optional > accessors), validation (most frequently null checks), related boilerplate > features (builders, generation of Object methods), constructors and > factories, derived properties (accessors not mapped to a specific field), > etc; > > - Such proposals tend to have a lot of detail but relatively little > "depth", offering a poor return on complexity; > > - It is "fighting the last war", in that the model of "every class > should have getters and setters for their fields" is finally starting to > fade; > > - The concept of accessors as ordinary methods is inherently lossy. > While the author understands that `getX` and `setX` are related somehow, > the language, and reflection libraries, do not. (It's what we have; the > choice to separate field and method namespaces slammed the door pretty much > forever on first-class properties.) > > > Additionally, we confronted a lot of these issues when we did records. We > looked at all the popular "macro generator" and properties libraries (e.g., > Lombok, Joda Beans, Immutables, etc), and asked ourselves which of the > features from these libraries belonged in records. We struggled with the > concept of accessors, and whether the record treatment of accessors (as > well as other features) could scale to arbitrary classes. > > We made a number of decisions during the design of records that may be > informative here, including: > > - The language does not get in the business of naming conventions. > Records have public constructors and no factories largely because factories > are not a language feature, they are merely a convention. It would have > have been acceptable for the language to bless an arbitrary name like "of" > for factories. If factories had been a language feature, records might > have leaned on them; in fact, during the design of records, we explored a > number of interpretations of "factories as a language feature", but in the > end, decided to prune that branch of inquiry. (Some might want to argue > that even picking `x()` as the accessor name for field `x` was getting into > the naming convention business, but this usually turns out to be arguing > for its own sake.) We also considered how, if we extended the read > accessors from records to arbitrary classes, what the story might be for > setters. Your choice of `setX` falls afoul of this principle (as did many > of the alternatives we explored.) > > - The stable number of "tuning knobs" is zero. For every > not-always-perfect decision we made with records, someone always wants to > propose "just one" option for tuning it (e.g., "the factory name is > `newFoo`", "exclude this component from the equals computation", etc). The > only stable number of such knobs is zero; once there is one, there will be > many, and you will have turned the language into Lombok. A language > feature that requires many knobs (whether keywords, annotations, > "convention over configuration", etc) is probably the wrong design; leave > that for code generators. > > > > > > > > On 3/23/2022 10:29 PM, Julian Waters wrote: > > Hi all, > > > It would be appreciated if I could get feedback and refinements > > on the current Amber JEP draft. > > > Thanks and have a great day! :) > > > best regards, > > Julian > > > Summary > ------- > > Enhance Java with language level field accessors. > > Accessors provide an easy way to define logic for setting > > and retrieving field values in what would otherwise be a > > tedious process of writing multiple methods (with potential > > overloads) > > Goals > ----- > > It is intended for this new feature to work with full > > compatibility with existing manually defined methods, > > as well as with inheritance and subclass overriding, > > and to provide a clean way to define accessors with > > different signatures. > > > Motivation > ---------- > > From JEP-395: "It is a common complaint that > > "Java is too verbose" or has "too much ceremony"." > > > Currently, if one wishes to have private fields with > > public methods to modify them, it is required to write > > at least one getter and setter. In the worst case, it > > is required to write multiple copies of the exact same method > > if there need to be multiple overloads. This eventually > > becomes overly tedious or error prone, and a common desire > > is that Java had cleaner syntax for such field access. It > > may be tempting to ask why direct field modification is not > > then used instead, but accessing a field through methods > > allows custom logic to be executed, which is particularly > > useful for state checking and possibly returning or setting > > a different value if the situation call for it. Other > > languages, such as Kotlin and C#, have dedicated syntax > > for such "getters and setters", but their approach only > > allows for one such set to be specified, and no extra > > parameters other than the built in ones are allowed. We > > should not abandon the flexibility overloads in Java > > provide for the sake of such a feature, so we'll need an > > approach that combines the compactness of other such > > languages with the more Java-esque method style for full > > flexibility and ease of use. > > > Description > ----------- > > > The current proposal proposes the syntax for field > > accessors as follows: > > > // Getters have the same name as the field > // Setters have the name of set > > private long field = 0 { > // Getter, leave semicolons after return to define a getter > without running any custom logic, or a block if custom logic is > required > return; > > // Getter that executes custom logic > // If no return is specified in the getter, it will implicitly > return the field bound to it > // after executing the body > return { /*Code here*/ } > > > // Getter that explicitly returns a value using a return statement > in the body > // Note that "this" refers to the field and not the containing class > // To explicitly access the containing class, use KlassName.this > return { return this; }; > > // Getter that returns another field instead of this one. Note > that KlassName.this is > // not required to access other fields in the class; It serves the > same purpose as > // regular usages of "this": To differentiate fields defined in > the class itself and > // local variables > > // Note that the other field MUST have the same type > > // as the one the accessor is bound to > return { return KlassName.this.otherField } > > // Getter overloaded with custom signature > // Note: No getter or setter can share the same signature > return(Klass klass) {} > > > // Return random literal > > return { return 42L; } > > > // Accessors can call their own overloads too, if > > // required > > // If an accessor calls its own overload, the implicit > > // setting or getting is disabled. > > return { field(); } > > // Setter, leave as is to implicitly set field to value without > any custom logic > // Note that the type and name do not need to be set, the type is > already inferred > // and the name is not needed unless it has to be referred to in a > body with custom > // logic > new; > > // Setter that executes body before assigning a value to the field > // Like Getters, Setters execute the body first before setting the > field, unless the order > // is customized by setting "this" to another value explicitly > new { /*Code*/ } > > > // Setter that accepts parameters. Method signature when being > called will be (valueToSet, ...) > new(KlassName otherType) {} > > > // Accessors can call their own overloads too, if > > // desired > > // If an accessor calls its own overload, the implicit > > // setting or getting is disabled. > > new { setField(5); } > > // Setter with access to the value being sent to set the field // Type is > automatically inferred, but can be set if desired for whatever reason > new(value) -> {} // Setter with both access to the new value and more > parameters new(value) -> (KlassName otherType) {} // Setter that explicitly > sets the field // Normally the field is set implicitly if nothing is > assigned to "this" in the body new(value) -> { this = value; } // Setter > with a return type. By default, setters are void // Both setters and > getters can be marked as final in the same manner with the "final" // > keyword char new { return 'c'; } } // To override the getter/setter in > subclasses, if possible > > // Eg not marked as final > > // Type is immediately inferred, but can be explicitly specified > before the identifier if > // there are other fields with the same name but different type > // This is only possible if those fields have getters or setters > super field { > // Syntax is the same as above > } > > // Note that overriding getters or setters defined by > > // this new syntax can be done in the typical > // way, if desired, and vice versa > @Override > public long field() { /*Logic*/ } > > > @Override > public void setField(long value) { /*Logic*/ } > > > The above are all ultimately implemented as normal methods, > > making supporting them relatively easy and requiring > > little change to javac as a whole, and also means that > > any accessor can be overridden by subclasses with regular > > methods with the correct name and signature, as shown above > > (Unless marked final) > > > Currently, there is no proposal for static fields. This can > > hopefully be worked on as discussion around this JEP progresses > > > Alternatives > ------------ > > The Lombok project has annotations that can be added > > to fields to automatically generate getters and setters, > > however this would require developers to install a third > > party library, when native language support would be much > > more efficient to work with. Additionally, Lombok's field > > annotations can only generate one set of methods and do not > > allow for overloads, making it much less flexible than the > > currently proposed syntax. Alternatively, we could continue > > to stick to Java's traditional way of directly writing > > methods, but developers often find such an approach rather > > tedious, and the amount of boilerplate required with this > > approach can make it ultimately more error prone. > > > Risks and Assumptions > --------------------- > > This JEP assumes that developers have prior knowledge of > > accessors, and will not have any issues making their code > > work with the new language feature. > > > From ice1000kotlin at foxmail.com Fri Mar 25 13:52:09 2022 From: ice1000kotlin at foxmail.com (=?utf-8?B?VGVzbGEgWmhhbmc=?=) Date: Fri, 25 Mar 2022 09:52:09 -0400 Subject: Pattern matching for switch (Third Preview) Message-ID: Here: "hello", as expected; but also case Integer i when i <> 0 dominates the label case 0. This leads to a simple, predictable, and readable ordering of case labels, where the constant Regards, Tesla ---Original--- From: "Gavin Bierman" JEP 420 has been delivered ------------- Commit messages: - Updated list of delivered JEPs Changes: https://git.openjdk.java.net/amber-docs/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=amber-docs&pr=13&range=00 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/amber-docs/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/amber-docs pull/13/head:pull/13 PR: https://git.openjdk.java.net/amber-docs/pull/13 From gbierman at openjdk.java.net Mon Mar 28 15:31:39 2022 From: gbierman at openjdk.java.net (Gavin Bierman) Date: Mon, 28 Mar 2022 15:31:39 GMT Subject: [amber-docs] RFR: Updated list of delivered JEPs [v2] In-Reply-To: References: Message-ID: > JEP 420 has been delivered Gavin Bierman has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. ------------- Changes: - all: https://git.openjdk.java.net/amber-docs/pull/13/files - new: https://git.openjdk.java.net/amber-docs/pull/13/files/eab5f421..83e606de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=amber-docs&pr=13&range=01 - incr: https://webrevs.openjdk.java.net/?repo=amber-docs&pr=13&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/amber-docs/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/amber-docs pull/13/head:pull/13 PR: https://git.openjdk.java.net/amber-docs/pull/13 From gbierman at openjdk.java.net Mon Mar 28 15:31:39 2022 From: gbierman at openjdk.java.net (Gavin Bierman) Date: Mon, 28 Mar 2022 15:31:39 GMT Subject: [amber-docs] Withdrawn: Updated list of delivered JEPs In-Reply-To: References: Message-ID: <7ArPaeb_zKguQ_LiNNUwDwtHj1q4R0UvuSXPI3WKhbI=.e2ba91ae-9319-48f1-b737-5455f00e0abf@github.com> On Mon, 28 Mar 2022 15:22:16 GMT, Gavin Bierman wrote: > JEP 420 has been delivered This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/amber-docs/pull/13 From gbierman at openjdk.java.net Mon Mar 28 15:37:18 2022 From: gbierman at openjdk.java.net (Gavin Bierman) Date: Mon, 28 Mar 2022 15:37:18 GMT Subject: [amber-docs] RFR: Updated list of delivered JEPs Message-ID: Updated list of delivered JEPs to reflect that JEP 420 has now been delivered ------------- Commit messages: - Updated list of delivered JEPs Changes: https://git.openjdk.java.net/amber-docs/pull/14/files Webrev: https://webrevs.openjdk.java.net/?repo=amber-docs&pr=14&range=00 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/amber-docs/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/amber-docs pull/14/head:pull/14 PR: https://git.openjdk.java.net/amber-docs/pull/14 From gbierman at openjdk.java.net Wed Mar 30 08:12:54 2022 From: gbierman at openjdk.java.net (Gavin Bierman) Date: Wed, 30 Mar 2022 08:12:54 GMT Subject: [amber-docs] Integrated: Updated list of delivered JEPs In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 15:31:48 GMT, Gavin Bierman wrote: > Updated list of delivered JEPs to reflect that JEP 420 has now been delivered This pull request has now been integrated. Changeset: 89a52fa5 Author: Gavin Bierman URL: https://git.openjdk.java.net/amber-docs/commit/89a52fa5c397bcd1c6eb42f07acb12400474113d Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Updated list of delivered JEPs ------------- PR: https://git.openjdk.java.net/amber-docs/pull/14 From brian.goetz at oracle.com Wed Mar 30 17:49:02 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 30 Mar 2022 13:49:02 -0400 Subject: Fwd: Pattern matching remainders In-Reply-To: References: Message-ID: <0041040c-3e11-24ba-6ce6-06cc3d156dd7@oracle.com> The following was received on amber-spec-comments. It's a cute idea, but it's not a precedent I want to set: ?- Catch clauses cannot specify interfaces, and this is a nontrivial change; ?- Going down this road for pattern matching would likely generate a significant stream of RFEs for new interfaces to be retrofitted to existing exceptions; ?- Having NPE acquire a pile of new supertypes is likely to be confusing to users who arrive at the Javadoc page; ?- The payoff is just not that big; ?- There are already well-established techniques for providing additional cause information for debugging -- exception text and wrapping. So overall, I don't see the benefits justifying the costs. -------- Forwarded Message -------- Subject: Pattern matching remainders Date: Wed, 30 Mar 2022 18:38:11 +0100 From: Izz Rainy To: amber-spec-comments at openjdk.java.net Instead of having compilers potentially wrap the "true cause" of a failed match in a MatchException, perhaps have MatchException be an interface implemented by (subtypes of) ICCE and NPE, which compilers/runtimes and future versions of the spec could add additional subtypes to later? That way, exceptions thrown by matching would be consistent ("a subtype of MatchException" rather than "an NPE or ICCE or ME"), and the spec would have more flexibility to specify another top-level matching exception in the future (and implementers could more easily specify their own diagnosis logic) without breaking existing error handling, which also wouldn't have to use an overly general catch block (catch all MEs and sometimes rethrow) or parse exception descriptions (like a helpful-NPEs analogue) to rely a more useful message to a developer or user. Specifically using an interface would avoid needing to make all NPEs and ICCEs into MatchExceptions (and potentially trigger false positive catches), only producing match-based subtypes of these. Admittedly, that relies on being able to specify a catch for an interface type with no relation to Throwable, which may be too big of a change for consideration. From tanksherman27 at gmail.com Thu Mar 31 01:51:07 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 31 Mar 2022 09:51:07 +0800 Subject: Java Enhancement Proposal: Field Accessors Message-ID: As a small post to revive the current thread, the idea was inspired by the following within the amber-docs repo: "There are other potential new goodies for records (e.g., keyword-based construction and deconstruction) and new goodie-democratization opportunities *(e.g., accessors for arbitrary classes)* that can come later." I'm unsure if there is already an ongoing draft for this however. best regards, Julian