[code-reflection] RFR: Cleanup JavaType factories [v2]
Maurizio Cimadamore
mcimadamore at openjdk.org
Fri May 3 09:32:30 UTC 2024
> This PR is a biggie cleanup of the various `JavaType` classes.
>
> Perhaps the biggest contribution of this PR is to cleanup the factories in `JavaType`. The new factories are as follows:
> * a factory to create a type from a `ClassDesc`
> * a factory to create a type from a `j.l.r.Type`
> * a couple of factories for creating parameterized types, which work on `JavaType` instances
> * a couple of factories for array types
> * a couple of factories for wildcard types
> * a factory for type variables
>
> This resolves the non-orthogonality found in the current set of factories, where one can take a `JavaType` and can, simultaneously, parameterize it, and turn it into an array type. Now the factories for these two operations are distinct.
>
> The new factories also clarify the relationship between `JavaType`, `ClassDesc` and `j.l.Type` - that is:
>
> * a type can be built from a nominal descriptor, using `type(ClassDesc)`
> * a type can turned into a nominal descriptor, using `toNominalDescriptor()`
> * a type can be built from a reflective type mirror, using `type(Type)`
> * a type can turned into a nominal descriptor, using `resolve(Lookup)`
>
> These operations are symmetric - that is, you can start from a reflective type mirror, build a `JavaType` form it, then resolve that into a `Type` and check that you get back where you started. I've enhanced `JavaTypeTest` to check round trip for both `ClassDesc` and `Type`.
>
> Note that the `JavaType` can be associated with complex reflective mirrors, e.g. beyond just `Class<?>`. For this reason, existing uses of `JavaType::resolve` in `BytecodeGenerator` and `Interpreter` which were expecting to obtain a `Class` from a `resolve` call have been rewritten to use the idiom `type.erasure().resolve(...)`.
>
> As part of this PR I've also added javadoc for all the methods/fields under the `JavaType` hierarchy that did not have one, and expanded existing docs.
>
> I've added several tests to make sure that all the conversions work as expected, and I have verified the examples (by opening their files in the IDE and make sure there's no error, I did not build).
Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
- Update src/java.base/share/classes/java/lang/reflect/code/type/impl/MethodRefImpl.java
Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
- Update src/java.base/share/classes/java/lang/reflect/code/type/impl/FieldRefImpl.java
Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
-------------
Changes:
- all: https://git.openjdk.org/babylon/pull/71/files
- new: https://git.openjdk.org/babylon/pull/71/files/767f0d6d..42bed94a
Webrevs:
- full: https://webrevs.openjdk.org/?repo=babylon&pr=71&range=01
- incr: https://webrevs.openjdk.org/?repo=babylon&pr=71&range=00-01
Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/babylon/pull/71.diff
Fetch: git fetch https://git.openjdk.org/babylon.git pull/71/head:pull/71
PR: https://git.openjdk.org/babylon/pull/71
More information about the babylon-dev
mailing list