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
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 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 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 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`/`
> 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 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
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`/`
> 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: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
Please review this PR which removes occurrences of 'applet' within the corelibs
specification. Applet has been deprecated since JDK9, and may be a confusing
term for new Java developers, so it should be removed from the documentation.
Primarily, usages where 'applet' is used interchangeably with
On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote:
> Please review this PR which removes occurrences of 'applet' within the
> corelibs specification. Applet has been deprecated since JDK9, and may be a
> confusing term for new Java developers, so it should be removed from the
> documentation.
On Tue, 17 Sep 2024 23:36:16 GMT, Naoto Sato wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentat
On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote:
> Please review this PR which removes occurrences of 'applet' within the
> corelibs specification. Applet has been deprecated since JDK9, and may be a
> confusing term for new Java developers, so it should be removed from the
> documentation.
On Wed, 18 Sep 2024 06:25:57 GMT, Sean Coffey wrote:
>> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html
>> line 74:
>>
>>> 72: volatile (or access to the variable must be
>>> 73: synchronized).
>>> 74: For example, suppose your application contains the following
16 matches
Mail list logo
