-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8174222: LambdaMetafactory: validate inputs and improve documentation #4346
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
Conversation
👋 Welcome back dlsmith! A progress list of the required criteria for merging this PR into |
@dansmithcode The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
CSR was completed months ago: JDK-8221255. Just never got around to pushing the changes. Since then, InnerClassLambdaMetafactory was changed significantly, but the the public API is unchanged. |
In testing, I discovered one issue leading to an internal error: JDK-8268192. I commented out my test case and will follow up on that issue separately. |
Webrevs
|
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.
Looks fine to me. The CSR was approved for 13 and its fixVersion should be updated to 17.
@@ -0,0 +1,306 @@ | |||
/* | |||
* Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. |
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.
copyright year needs update.
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.
Fixed. And I bumped it on the other files, too.
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.
Code looks good, nice test.
@dansmithcode This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 49 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Mailing list message from Joe Darcy on core-libs-dev: Yes, the CSR should be re-reviewed before the change goes in. I've changed the CSR status to indicate it needs another review. -Joe On 6/3/2021 4:07 PM, Mandy Chung wrote: |
1 similar comment
Mailing list message from Joe Darcy on core-libs-dev: Yes, the CSR should be re-reviewed before the change goes in. I've changed the CSR status to indicate it needs another review. -Joe On 6/3/2021 4:07 PM, Mandy Chung wrote: |
* are violated, or the lookup context | ||
* does not have private access privileges. | ||
* instances of the interface named by {@code factoryType} | ||
* @throws LambdaConversionException If {@code caller} does not have private |
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.
One additional comment:
The lookup access has been extended since 14 to include MODULE
and ORIGINAL
access.
Lookup::hasFullPrivilegeAccess
returns true if the lookup has PRIVATE
and MODULE
which means that this lookup is not teleported from another module via Lookup::in
and MethodHandles::privateLookupIn
.
What privilege do you expect the caller
lookup should have? I believe full privilege access is the appropriate privilege. The ORIGINAL
access is stricter as the lookup must be created from the original lookup class.
[1] shows what access a Lookup
has when being produced via different APIs.
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.
Thanks, yes I think hasFullPrivilegeAccess
is what we want. I updated the javadoc, along with the actual check. Thanks for catching!
if (!type.isInstance(result)) { | ||
throw new IllegalArgumentException("argument has wrong type"); | ||
} | ||
return type.cast(result); |
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.
Can we just use a return (T) result
as there will always be a checked cast on the caller's end, and this call seems redundant? The only shortcoming is that the call will raise an unchecked warning that needs to be suppressed. Or is this negligible after hotspot optimization?
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.
Eh, the scale here is quite small (never more than, say, 20 items), and an instanceof + a cast is a routine coding style that I'd expect to be optimized away. Doesn't seem worth the maintenance noise of a @SuppressWarnings
.
final Class<?>[] markerInterfaces; // Additional marker interfaces to be implemented | ||
final MethodType[] additionalBridges; // Signatures of additional methods to bridge | ||
final Class<?>[] interfaces; // Additional interfaces to be implemented | ||
final MethodType[] bridges; // Signatures of additional methods to bridge |
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.
If you are removing ACC_BRIDGE from additional generated methods, then perhaps this parameter name could also be changed? altMethods
(as alternative methods perhaps?)
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.
Yes, it was sort of a half-done move. You're right, we should rename these (and, more importantly, in the public LambdaMetafactory API). Done. Also renamed interfaces
--> altInterfaces
.
@@ -309,8 +309,8 @@ private LambdaMetafactory() {} | |||
* {@code interfaceMethodType}. | |||
* @return a CallSite whose target can be used to perform capture, generating | |||
* instances of the interface named by {@code factoryType} | |||
* @throws LambdaConversionException If {@code caller} does not have private | |||
* access privileges, or if {@code interfaceMethodName} is not a valid JVM | |||
* @throws LambdaConversionException If {@code caller} does not have full privilege |
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.
* @throws LambdaConversionException If {@code caller} does not have full privilege | |
* @throws LambdaConversionException If {@code caller} does not have {@linkplain Lookup#hasFullPrivilegeAccess full privilege} |
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.
It's hard to see in the diff, but this link just appeared in the javadoc a few lines above. Stylistically, doesn't seem like it should be linked again.
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.
I didn't realize it's already linked, thanks. So what you have is fine then.
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.
Can you also rename the parameter names in java.lang.invoke.LambdaProxyClassArchive
methods to match the new ones?
Hmm, that expands the reach of the patch a bit—into native HotSpot code—but I've given it a try. Let me know if it looks like I've broken something. :-) |
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.
Thanks for going beyond the java code. Looks good.
/integrate |
@dansmithcode Since your change was applied there have been 85 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit fc08af5. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac.
Does some renaming of core parameters/fields to better reflect their purpose.
In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method).
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4346/head:pull/4346
$ git checkout pull/4346
Update a local copy of the PR:
$ git checkout pull/4346
$ git pull https://git.openjdk.java.net/jdk pull/4346/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4346
View PR using the GUI difftool:
$ git pr show -t 4346
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4346.diff