-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8304146: Refactor VisibleMemberTable (LocalMemberTable) #13044
Conversation
Sadly, changing the member key computation ripples through JavaFX-related code.
👋 Welcome back prappo! A progress list of the required criteria for merging this PR into |
@pavelrappo 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
|
return new SimpleElementVisitor14<String, Void>() { | ||
@Override | ||
public String visitExecutable(ExecutableElement e, Void aVoid) { | ||
return e.getSimpleName() + ":" + e.getParameters().size(); |
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.
That was bizarre.
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.
Somewhat, yes. That computation complicated code more than it improved (some aspects of) it.
List<Element> getMembers(Element e, Kind kind) { | ||
String key = getMemberKey(e); | ||
return getMembers(key, kind); | ||
List<Element> getMembers(Name simplename, Kind kind) { |
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.
Suggest: simpleName
<T extends Element> List<T> getMembers(String key, Kind kind, Class<T> clazz) { | ||
Map<String, List<Element>> map = memberMap.get(kind); | ||
return map.getOrDefault(key, List.of()) | ||
<T extends Element> List<T> getMembers(Name simplename, Kind kind, Class<T> clazz) { |
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.
suggest: simpleName
.stream() | ||
.map(clazz::cast) | ||
.toList(); | ||
} | ||
|
||
List<ExecutableElement> getPropertyMethods(String methodName, int argcount) { | ||
return getMembers(methodName + ":" + argcount, Kind.METHODS).stream() | ||
List<ExecutableElement> getPropertyMethods(Name simplename) { |
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.
suggest simpleName
getter = found.get(0); | ||
} | ||
if (getter == null) { | ||
// TODO: this code does not seem to be covered by tests well |
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.
Suggest: link to this TODO in recent new JBS entry.
} | ||
} | ||
} | ||
|
||
var setter = lmt.getPropertyMethods(utils.elementUtils.getName(pUtils.getSetName(propertyMethod))).stream() | ||
// TODO: number of parameters a setter take is not tested |
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.
Suggest: link to this TODO in recent new JBS entry.
- renames simplename to simpleName - links to the relevant JBS issue from TODOs
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.
Minor naming and other suggestions.
@pavelrappo 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 5 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
memberMap.computeIfPresent(kind, (k, v) -> Collections.unmodifiableMap(v)); | ||
memberMap.computeIfAbsent(kind, t -> Map.of()); | ||
orderedMembers.compute(kind, (k, v) -> v == null ? List.of() : Collections.unmodifiableList(v)); | ||
namedMembers.compute(kind, (k, v) -> v == null ? Map.of() : Collections.unmodifiableMap(v)); |
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 just use replaceAll
than using a for loop
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.
There's a cost of changing that to this:
// protect from unintended change
orderedMembers.replaceAll((k, l) -> Collections.unmodifiableList(l));
namedMembers.replaceAll((k, m) -> Collections.unmodifiableMap(m));
That cost is using default values for absent kinds:
List<Element> getOrderedMembers(Kind kind) {
return orderedMembers.getOrDefault(kind, List.of());
}
List<Element> getMembers(Name simpleName, Kind kind) {
return namedMembers.getOrDefault(kind, Map.of())
.getOrDefault(simpleName, List.of());
}
Or did you mean something else?
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 don't mind either way; @jonathan-gibbons do you have a preference?
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.
TANSTAAFL
I suggest to leave the code as-is.
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.
True, my previous suggestion is largely trivial.
In addition, I suggest to run replaceAll
to ensure the map elements of each value of namedMembers
is unmodifiable as well:
namedMembers.replaceAll((k, m) -> {
m.replaceAll((n, members) -> Collections.unmodifiableList(members));
return Collections.unmodifiableMap(m);
});
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 believe that shallow unmodifiability of namedMembers is a bug, which you spotted. We should either fix it by making it deeply unmodifiable, or remove this defensiveness altogether: those lists and maps (especially maps) are internal and should never escape. I suppose, it's better to fix it now and revisit later.
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.
Or just comment the existing code, indicating that this is just a shallow copy.
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 we should follow the original code intent, if that's not too complicated. Please have a look at the proposal in 7565f89, and if you are okay with it, and the tests pass, I'll integrate 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.
@liach there's no need for namedMembers or its value maps to be unmodifiable: it's the lists that are exposed. So let's protect just them.
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.
Sorry, pushed the change sloppily. Since it was done recently and there haven't been more pushes on top of that, I pushed forcefully. Please consider 963bff7 instead of 7565f89.
Uses better suited list/map processing.
@pavelrappo Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information. |
/integrate |
Going to push as commit 8eed7de.
Your commit was automatically rebased without conflicts. |
@pavelrappo Pushed as commit 8eed7de. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review a change to clean up and simplify LocalMemberTable; a container to cache, classify, and provide efficient lookup for the return value of
TypeElement.getEnclosedElements()
.While the change primarily targets internals of LocalMemberTable, it also affects its clients: in particular, code that handles JavaFX documentation. That code does not seem to be tested well (I filed a bug for that: JDK-8304170). To make sure I haven't broken anything, aside from usual testing, I also cloned OpenJFX and built its documentation with javadoc before and after the change. Documentation bundles were identical.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/13044/head:pull/13044
$ git checkout pull/13044
Update a local copy of the PR:
$ git checkout pull/13044
$ git pull https://git.openjdk.org/jdk pull/13044/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13044
View PR using the GUI difftool:
$ git pr show -t 13044
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13044.diff