Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8263233: Update java.net and java.nio to use instanceof pattern variable #2890
8263233: Update java.net and java.nio to use instanceof pattern variable #2890
Changes from all commits
b204a44
eca9095
27a5892
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the context of this type of change the negative logic is a little obtuse or disjoint in the new style variable declaration, and its subsequent use. I'd find it a more natural flow and easier to read with the instanceof pattern prefacing a block in which the variable is used
if (addr instanceof InetSocketAddress epoint) {
// a block which is using the epoint variable
if (epoint.isUnresolved)
throw new SocketException("Unresolved address");
InetAddress iaddr = epoint.getAddress;
etc, etc ...
} else {
throw new IllegalArgumentException("Unsupported address type!");
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The disadvantage is that it would add another level of braces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe ... I find it would provide an easier flow to code ... an "easy on the eye" call flow linkage - the variable is declared and then used .... instead of the disconnect of throwing an exception or non immediate use of the variable.
but sure, isn't code somewhat idiosyncratic!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first few times I looked at this pattern, I did stumble over it somewhat. But since then, I find it natural enough and easy to follow. Maybe the concern is transient in nature, until the instanceof pattern matching feature is more widely used.