8245584: [lworld] LW3 core reflection update #53
This patch updates the core reflection for the new language model for inline classes.
If this class has no val type or ref type,
I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
The text was updated successfully, but these errors were encountered:
@mlchung This change now passes all automated pre-integration checks, type
There are currently no new commits on the
It's up to the source compiler to issue or not issue a V.ref class file. Perhaps the user has manually created one, or perhaps it is automatically generated, or perhaps the inline type is a HC and therefore cannot have been sealed to a companion type.
The JVM has to take what's there and surface it; if it's not there the JVM has to carry on. Since the core reflection APIs are mostly about what's in the classfile, they don't try to reconstruct what the source language was, but rather report any and all classfiles present.
But we do want to reflect the relation between V.ref and V.val, if both exist and are properly marked. We need a clearly stated rule for what "properly marked" means, and those rules are not nailed down yet, since we are hammering out a story where V.ref might be either an interface or an abstract class.
I suggest that the final form of the reflection code for V.ref/V.val should be written in Java, and clearly and simply implement whatever agreement we make in the end. Java code should manage the refType and valType fields, if possible. Bootstrapping issues may force them to be managed by the JVM, as in this patch, but even in that case the code should be set apart (probably as a subroutine or two) and documented clearly as relating to the above-mentioned agreement.
One comment, really for the future, regarding the shape of the Java API here: It uses Optional and omits the "get" prefix on accessors. This is the New Style, as opposed to the Classic Style using null (for "empty" results) and a "get" prefix ("getComponentType") to get a related type. We may choose to to use the New Style for new reflection API points, and if so let's not choose N different New Styles, but one New Style. Personally I like removing "get"; I accept Optional instead of null; and I also suggest that arrays (if any) be replaced by (immutable) Lists in the New Style.
[CC to Brian and amber-dev] because this is relevant to the API around record too.
----- Mail original -----
Please no, no New Style if the Old Style is good enough,
I think NetworkInterface  is the perfect example of how to evolve an API,
1/ you have Enumeration used instead of Iterator because it's coherent with the java.net package that was created for Java 1, even if NetworkInterface was introduced in Java 4.
I see two rules, one is when you grow an API follow the style of the API and if you have a good reason to introduce an API points with a new style, then provide both variants the old way and the new way.
@mlchung this pull request can not be integrated into
git checkout lw3-reflection git fetch https://git.openjdk.java.net/valhalla lworld git merge FETCH_HEAD # resolve conflicts and follow the instructions given by git merge git commit -m "Merge lworld" git push
On 5/25/20 12:40 PM, Remi Forax wrote:
IMO, adding both old way and the new way bloats the API unnecessarily.
Note that the java.lang.Class API implements TypeDescriptor.ofField