-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Handle jdk.internal classes mentioned in vector superclass or interfaces during extraction #12329
Handle jdk.internal classes mentioned in vector superclass or interfaces during extraction #12329
Conversation
…action. This fixes problem on branch_9x where the private superclasses are not available in Java 11. On Java 17 it just worked so we didn't figure.
I think that your proposed change is fine. Alternatively we could determine accessibility / visibility of the super class / interface by reading it from the jrt. But this is probably overkill for this one particular case. And of course, we'd need to consult the module-info to determine if that package is unconditionally exported - way way too much for this. ;-) |
Thanks for review, i added a logging statement to show all classes which were not referenced but not included. This would solve problems like this in future. Will merge when CI is happy. |
Looks like this:
|
I'm clearly doing something wrong, but I cherrypicked this into the 9x_panama_vector branch locally, and it still fails. I dunno why, it should work. Checking that my env is correct and that I've not missed something. I still see |
Did you generate everything? |
Ahhhhh, the signature because it is generic.... |
Here you see it, must be the signature as it shows generics:
Uwe |
Here's what I'm doing:
Debugging the extractor Cleaner, I can see that superName is replaced with java/lang/Object.
|
The problem is the signature, I verified it. Let me think how to do that. |
This can't be repaired, as the generic signature refers to the other class which has generics, too. By replacing it with If I just null out the generic signature, javac reports:
So the only route here is my original idea to include the internal classes intothe JAR -- unfortunately. |
Keep the backport open, I will try to fix it later this afternoon, I first have to do something else. |
For now, I just updated the glob in the 9x Panama vector branch to include VectorSupport, see 7c353f0 --- a/gradle/generation/extract-jdk-apis/ExtractJdkApis.java
+++ b/gradle/generation/extract-jdk-apis/ExtractJdkApis.java
@@ -50,7 +50,7 @@ public final class ExtractJdkApis {
private static final FileTime FIXED_FILEDATE = FileTime.from(Instant.parse("2022-01-01T00:00:00Z"));
static final Map<String,String> CLASSFILE_MATCHERS = Map.of(
- "java.base", "glob:java/{lang/foreign/*,nio/channels/FileChannel,util/Objects}.class",
+ "java.base", "glob:{java/lang/foreign/*,java/nio/channels/FileChannel,java/util/Objects,jdk/internal/vm/vector/VectorSupport*}.class",
"jdk.incubator.vector", "glob:jdk/incubator/vector/*.class"
); |
…ted as "hidden" and we remove all their members
Argh! inner classes!!! We still need the enclosing class (which we currently don't have). the jdk20api.jar contains:
|
I have seen this, too, but does this break in the Java 11 compiler? |
yeah, it breaks - in the same way - "class file for jdk.internal.vm.vector.VectorSupport not found" |
I have no idea way they had did this crazy class layout. There's also the special javadoc tag "@hidden" which looks like a crazy workaround. It looks like we have to include also the superclasss. There are also interfaces which on the other hand are not referenced downstream, so the current code to hide them is fine. |
Have a look at the whole class: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java |
Here is this mess with the As you see we are in the areas of heavy hacks with visibility. So we can't solve this in a general way. I tend to hardcode the exact classes needed into the extractor as patterns. I will also change the patterns a bit by having a list of filename patterns without module per Java version. |
++ while not perfect, it is understandable and maintainable. The extra logging is also very welcome, which will help future potential changes in this area. |
- have a list of filematcher patterns per java version - collect all files using a combined matcher
OK, I committed my final fix. Rewrote the modules / java version static settings at top of file:
The internal classes are explicitely specifid until no more were left over in the warning at end (including the superclass). |
@ChrisHegarty: do you want to crosscheck the 9.x branch? (don't forget to re-add the |
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 changes look good. And maintainable.
I can confirm that it works on the 9x Panama_vector branch. 👍
Thanks, as always a fun to work together! |
Absolutely. And thanks for fixing this so quickly. So how to proceed? I can merge in this PR commit (to he 9x_panama_branch), or we can coordinate and you can backport very quickly afterwards? |
I would merge this to the 9x_panama_branch. I don't want the huge binary file go into the main repo's Git state (I am afraid of Dawid and Robert about binaries in checkouts). |
The Java 21 branch was also updated. |
…ces during extraction (apache#12329)
By the way in Java 19 you see the |
This fixes problem on branch_9x backport (#12327) where the private superclasses are not available in Java 11.
On Java 17 it just worked so we didn't figure. :-(