On Sat, 30 Nov 2024 01:09:50 GMT, Chen Liang wrote:
> Can you try raise this problem in this mailing list
> https://mail.openjdk.org/mailman/listinfo/classfile-api-dev?
Thanks for [mentioning it on the
list](https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html)
and i
On Fri, 29 Nov 2024 22:20:50 GMT, Luca Kellermann wrote:
>> Don't think so. This imo is fixable in the future if we do have many new
>> cp/annotation tags (see example of Thread::threadId), though I don't think
>> that is likely
>
> Wait, I referenced the wrong thing. I was speaking about this
On Fri, 29 Nov 2024 18:59:41 GMT, Chen Liang wrote:
>>> Yet I think we can consider promoting Constant Pool tag from byte or char,
>>> short, or int to represent a u1 in case it goes over 127.
>>
>> Is there any chance a change like this could make it into JDK 24? I'd
>> imagine it would be to
On Fri, 29 Nov 2024 17:53:43 GMT, Luca Kellermann wrote:
>>> Your example is an exact antipattern from our data-oriented model: we would
>>> want users to check the object type with `instanceof` (should be `is` in
>>> kotlin) instead of checking these constants.
>>
>> I'm aware, this was just
On Mon, 7 Oct 2024 17:37:40 GMT, Luca Kellermann wrote:
> Yet I think we can consider promoting Constant Pool tag from byte or char,
> short, or int to represent a u1 in case it goes over 127.
Is there any chance a change like this could make it into JDK 24? I'd imagine
it would be too late af
On Mon, 7 Oct 2024 17:07:47 GMT, Chen Liang wrote:
> Your example is an exact antipattern from our data-oriented model: we would
> want users to check the object type with `instanceof` (should be `is` in
> kotlin) instead of checking these constants.
I'm aware, this was just the first example
On Mon, 7 Oct 2024 16:45:28 GMT, Luca Kellermann wrote:
>> First, some bit of history. These API methods are added before those
>> constants, and this patch did not change the type of these methods or
>> constants.
>>
>> I believe the methods have restricted return types to be informative:
>>
On Wed, 2 Oct 2024 20:24:41 GMT, Chen Liang wrote:
> First, some bit of history. These API methods are added before those
> constants, and this patch did not change the type of these methods or
> constants.
Sure, makes sense to separate this patch from a potential type change of the
methods/c
On Wed, 2 Oct 2024 19:16:08 GMT, Luca Kellermann wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> AbstractPoolEntry is broken too
>
> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 482:
>
>
On Tue, 24 Sep 2024 17:23:41 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
On Tue, 24 Sep 2024 17:23:41 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
On Tue, 24 Sep 2024 17:23:41 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
On Mon, 23 Sep 2024 21:42:11 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
On Mon, 23 Sep 2024 21:42:11 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
On Mon, 23 Sep 2024 15:15:15 GMT, Adam Sotona wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 14 commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/jdk into
>> fix/constant-moving
>> - omi
On Tue, 10 Sep 2024 21:18:19 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
On Wed, 11 Sep 2024 03:20:54 GMT, ExE Boss wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 14 commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/jdk into
>> fix/constant-moving
>> - omissi
On Tue, 10 Sep 2024 21:18:19 GMT, Chen Liang wrote:
>> Many constants are cluttered in `ClassFile`. However, only a few of them are
>> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
>> constants. All other constants are specific and should live in more local
>> loca
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
Many constants are cluttered in `ClassFile`. However, only a few of them are
ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
constants. All other constants are specific and should live in more local
locations, such as getters that return these constants.
This simplifi
27 matches
Mail list logo
