> JDK-8289106: Add model of class file versions to core reflection
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains 20 additional commits since
On Tue, 16 Aug 2022 14:40:41 GMT, Roger Riggs wrote:
>> Joe Darcy has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains 18 additional commits
>> since
On Wed, 10 Aug 2022 01:54:56 GMT, Joe Darcy wrote:
>> JDK-8289106: Add model of class file versions to core reflection
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/
> JDK-8289106: Add model of class file versions to core reflection
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains 18 additional commits since
On Tue, 2 Aug 2022 21:21:51 GMT, Roger Riggs wrote:
> True, many ways to factor the code. Another possibility is add a field to the
> enum that holds a `java.util.Function>)` and initialize
> it each with a lambda of the code now in the locations(cffv) method that maps
> the cffv to the set of
On Mon, 1 Aug 2022 23:05:58 GMT, Joe Darcy wrote:
>> Probably by creating and using shared instances of `java.util.Function`
>> which would also allow deduplicating the code.
>
>> Is there another way to implement this that does not create 19 anonymous
>> classes with a single overloaded method
On Mon, 1 Aug 2022 17:37:36 GMT, ExE Boss wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 101:
>>
>>> 99: PUBLIC(Modifier.PUBLIC, true,
>>> 100:Set.of(Location.CLASS, Location.FIELD, Location.METHOD,
>>> 101: Location.INNER_CLASS)) {
On Mon, 1 Aug 2022 17:04:51 GMT, Roger Riggs wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Appease jcheck.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 101:
>
>> 99: PUBLIC(Modifier.PU
On Thu, 28 Jul 2022 20:43:31 GMT, Joe Darcy wrote:
>> JDK-8289106: Add model of class file versions to core reflection
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Appease jcheck.
src/java.base/share/classes/java/lang/refl
On Thu, 28 Jul 2022 20:37:30 GMT, Joe Darcy wrote:
>> JDK-8289106: Add model of class file versions to core reflection
>
> Joe Darcy has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Finish more precise versioned location support; udpate te
> JDK-8289106: Add model of class file versions to core reflection
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Appease jcheck.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9299/files
- new: https://git.openjdk
> JDK-8289106: Add model of class file versions to core reflection
Joe Darcy has updated the pull request incrementally with two additional
commits since the last revision:
- Finish more precise versioned location support; udpate tests.
- Partial implementation of version-depdendent locations(
> JDK-8289106: Add model of class file versions to core reflection
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains 12 additional commits since
On Mon, 11 Jul 2022 20:31:04 GMT, Mandy Chung wrote:
> This `ClassFileFormatVersion` API is a good proposal. It can also reference
> `java.class.version` system property to map to the latest class file format
> version.
Good idea Mandy; I'll add that reference and start working on the
impleme
On Wed, 29 Jun 2022 21:32:29 GMT, Joe Darcy wrote:
>> JDK-8289106: Add model of class file versions to core reflection
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/
On Wed, 29 Jun 2022 21:32:29 GMT, Joe Darcy wrote:
>> JDK-8289106: Add model of class file versions to core reflection
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/
On Wed, 29 Jun 2022 16:51:21 GMT, Roger Riggs wrote:
> I'm thinking of the case where I'm reading class file bytes and pull out the
> major classfile version and want to map it to the enum. If the semantic was
> the "earliest version" supporting the major version then it would be
> unambiguous
> JDK-8289106: Add model of class file versions to core reflection
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains 10 additional commits since
On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy wrote:
> JDK-8289106: Add model of class file versions to core reflection
I'm thinking of the case where I'm reading class file bytes and pull out the
major classfile version and want to map it to the enum. If the semantic was the
"earliest version"
On Wed, 29 Jun 2022 14:42:19 GMT, Roger Riggs wrote:
> A static method to map from classfile version (as in the JVMS) to
> ClassFileVersion enum will be useful too.
Just to confirm, you're asking for a method that would map 63 to RELEASE_19, 64
to RELEASE_20, etc.?
Seems reasonable, although
On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy wrote:
> JDK-8289106: Add model of class file versions to core reflection
A static method to map from classfile version (as in the JVMS) to
ClassFileVersion enum will be useful too.
-
PR: https://git.openjdk.org/jdk/pull/9299
On Mon, 27 Jun 2022 20:26:52 GMT, Joe Darcy wrote:
> JDK-8289106: Add model of class file versions to core reflection
Sending this enum to model class file format versions out for some review
comments before starting to write the tests and CSR, etc.
The class file format has a rich structure t
JDK-8289106: Add model of class file versions to core reflection
-
Commit messages:
- Update phrasing.
- Augment and correct docs.
- Correct major versions; RELEASE_0 and RELEASE_1 are both 45.
- Make major method public.
- Add AccessFlag.locations(ClassFileFormatVersion)
- Add
23 matches
Mail list logo
