On Fri, 20 Sep 2024 08:14:04 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
On Tue, 17 Sep 2024 14:25:42 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 13:37:19 GMT, Chen Liang wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update javadoc
>> - Rename utility class
>
> I think a better approach to this problem might be converting these static
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 12:33:34 GMT, Alan Bateman wrote:
> I think your proposal looks generally okay, not sure about naming it
> "MethodHandlesInternal" with "internal" in the package name as it's more like
> a class of utility methods.
Perhaps `MethodHandlesSupport`, like `jdk.internal.util.Arr
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 07:24:29 GMT, Per Minborg wrote:
> If you wish to add public methods anyhow, I think we should consider this
> under a separate issue.
I think it's a request for 10+ find methods to sit along the existing methods
so it might be confusing too.
I think your proposal looks g
On Tue, 17 Sep 2024 12:17:06 GMT, Chen Liang wrote:
> I think the original poster means to find a VH in the lookup class.
I actually meant what Per is hinting at. Defining static MethodHandle/VarHandle
in a class at class initialization time, without the ceremony of handling
ReflectiveOperatio
On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Mon, 16 Sep 2024 10:19:26 GMT, Kasper Nielsen wrote:
> This would actually be super useful in a public API. I use the same "trick"
> in some of my projects. Not because I care too much about the classfile size.
> But it is just a lot easier on the eye.
While I understand it would be conveni
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Fri, 13 Sep 2024 12:40:33 GMT, Chen Liang wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename and reformat
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java
> line 50:
>
>> 48:
On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Thu, 12 Sep 2024 19:30:45 GMT, Chen Liang wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename and reformat
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java
> line 1:
>
>> 1: /*
On Fri, 13 Sep 2024 07:39:40 GMT, Per Minborg wrote:
> If we could access `MethodHandles.Lookup.IMPL_LOOKUP `, we could use this as
> a lookup and elide the lookup arg. Any ideas to do this in a "polite" way?
Lookup.IMPL_LOOKUP should be guarded closely, I don't think we should remove
the need
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
On Thu, 12 Sep 2024 19:29:47 GMT, Chen Liang wrote:
> I think we can elide the `Lookup` argument to perform a
> always-full-permission lookup operation to simplify call sequence; or, to
> elide the `recv` receiver argument as it is almost always
> `lookup.lookupClass()` (except for a few lazy
On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg wrote:
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`Metho
On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg wrote:
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`Metho
This PR suggests introducing an internal class in `java.base` to simplify the
use of some `MethodHandles.Lookup` operations.
While the utility of the methods might appear to be limited in classes with
many static `VarHandle`/`MethodHandle` variables, it should be noted that the
class files beco
26 matches
Mail list logo
