-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8071693: Introspector ignores default interface methods #13544
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 archiecobbs! A progress list of the required criteria for merging this PR into |
@archiecobbs 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. |
Webrevs
|
import java.util.List; | ||
|
||
import com.sun.beans.TypeResolver; | ||
import com.sun.beans.finder.MethodFinder; | ||
|
||
final class MethodInfo { | ||
|
||
static final HashSet<Class<?>> IGNORABLE_INTERFACES = new HashSet<>(6); |
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.
static final HashSet<Class<?>> IGNORABLE_INTERFACES = new HashSet<>(6); | |
static final HashSet<Class<?>> IGNORABLE_INTERFACES = HashSet.newHashSet(6); |
Or even better, use Set.of instead.
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, much cleaner. Fixed in e37a146.
This one probably needs a CSR. /csr |
@archiecobbs has indicated that a compatibility and specification (CSR) request is needed for this pull request. @archiecobbs please create a CSR request for issue JDK-8071693 with the correct fix version. This pull request cannot be integrated until the CSR request is approved. |
|
||
import com.sun.beans.TypeResolver; | ||
import com.sun.beans.finder.MethodFinder; | ||
|
||
final class MethodInfo { | ||
|
||
static final Set<Class<?>> IGNORABLE_INTERFACES = Set.of( |
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.
Hm. Why only this specific interfaces?
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.
This a list of commonly implemented interfaces that don't need to be inspected because they are "known empty". This list is inspired by Spring's ClassUtils. Happy to add any others that deserve to be in there.
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.
given that serializable is commonly implemented, this may be a worthwhile optimisation.
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 think it should have some explanation comment, about why this interfaces are ignored and how they were chosen.
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 in ac90a10.
if (IGNORABLE_INTERFACES.contains(iface)) | ||
continue; | ||
for (Method method : iface.getMethods()) { | ||
if ((method.getModifiers() & Modifier.ABSTRACT) == 0) | ||
(list = createIfNeeded(list)).add(method); | ||
} |
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.
Please always use braces even if the body has only one statement.
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.
OK, I'll fix. I've seen examples of both styles in the JDK so am never really sure.
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 client libs, we tend to use the braces all the time.
By this comment, I meant adding braces to all the statements where you omitted them, including the test.
If you look through MethodInfo.java
class, you see that braces are used consistently even if the body has only one statement.
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 in ac90a10.
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 fix overall looks fine, but I'm not seeing why you think it needs a CSR.
It is just a bug fix. And if there were a CSR, it would be about the visible change, not the internals.
I'm not sure if it does or not. According to the CSR FAQ, Behavioral compatibility involves operational equivalence; with "the same" inputs, does a program behave "the same way" before and after a change. I've been dinged before for mere "bug fixes" without a CSR (see for example #10856 which made the compiler behave more closely to the spec and was eventually reverted because of it :) So, just being conservative I guess. I'd be happy to be wrong. @jddarcy, your opinion? |
Hmmm. I'm not an expert on Introspectors, but my impression is the behavior change is CSR-worthy. HTH |
By that criterion every change needs a CSR.
Maybe but regardless the CSR that has been written is very wrong, as I already commented there. All it needs to say is That's it, isn't it ? |
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.
Is it expected that the test file doesn't compile with simple javac DefaultMethodBeanPropertyTest.java
? It complains about BeanUtils
not found. When run with jtreg, the test compiles successfully.
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.
Is it expected that the test file doesn't compile with simple javac DefaultMethodBeanPropertyTest.java?
Definitely not. For example, many regression tests use classes that are not part of the standard JDK such as toolbox.ToolBox
.
Let's make this CSR question easy. I'll remove the CSR and see if anybody actually complains :) /csr unneeded |
@archiecobbs only Reviewers can determine that a CSR is not needed. |
Ugh, it looks like the bot won't let me do that. A reviewer will have to remove the CSR.... |
/csr unneeded |
import java.util.Arrays; | ||
import java.util.HashSet; | ||
|
||
public class DefaultMethodBeanPropertyTest { |
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 please add two additional tests to verify the "diamond" case:
- getFoo is in the top interfaceA, two empty subinterfaces B anc C , and one class D of B and C, will the D have one correct prop Foo?
- getFoo is in the top interfaceA, two non-empty subinterfaces B and C and each override getFoo by the different return types, and then one class D of B and C which override getFoo again by compatible type from B and C, will the D have one correct prop Foo?
We also can test the case if the D from the cases above is interface and implemented by the class E.
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.
Sure thing... see 6b43627.
findProperty(ClassB.class, "foo"); | ||
|
||
// Expected properties | ||
final HashSet<PropertyDescriptor> expected = new HashSet<>(); |
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.
please split the long lines to use 80 chars per line.
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 in e6a2ecb.
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.
/integrate |
@archiecobbs |
test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
Outdated
Show resolved
Hide resolved
test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
Outdated
Show resolved
Hide resolved
test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
Outdated
Show resolved
Hide resolved
/integrate |
@archiecobbs |
/sponsor |
Going to push as commit 1e4eafb.
Your commit was automatically rebased without conflicts. |
@mrserb @archiecobbs Pushed as commit 1e4eafb. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
As a retroactive post-integration comment, there is judgement required when gauging whether or not the behavioral changes associated with a PR merit a CSR, as discussed in the CSR FAQ: "Q: Under what conditions does a CSR need to be filed for a purely behavioral change? Given my general understanding of the nature of the change, based on nature of the change, my answer to the question of whether or not this should have a CSR would be "yes", but I'm happy to defer to @prrace 's subject matter expertise here that the answer should be "no." |
Maybe we should add a release note as a sort of consolation prize...? |
Hello, If I backported this to JDK17 LTS, would there be any chance of acceptance? Open Source work often goes unthanked, so I do wish to express my gratitude for fixing this. Unfortunately it does create headaches in JDK17 as an entire class of methods are getting missed. |
The
Introspector
class was never updated to includedefault
methods inherited from interfaces.This patch attempts to fix that omission.
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13544/head:pull/13544
$ git checkout pull/13544
Update a local copy of the PR:
$ git checkout pull/13544
$ git pull https://git.openjdk.org/jdk.git pull/13544/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13544
View PR using the GUI difftool:
$ git pr show -t 13544
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13544.diff
Webrev
Link to Webrev Comment