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
> 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: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
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: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 Thu, 12 Sep 2024 15:40:27 GMT, Brian Burkhalter wrote:
>> Moved to `NTLMAuthentication` static initializer. 853d349
>
> @dfuch Would you please check whether the change at line 71 in the updated
> version of `NTLMAuthentication` is the correct place for this load?
hmm... I don't see any iss
On Fri, 13 Sep 2024 16:05:37 GMT, Daniel Fuchs wrote:
>> @dfuch Would you please check whether the change at line 71 in the updated
>> version of `NTLMAuthentication` is the correct place for this load?
>
> hmm... I don't see any issue in adding the load call to `NTLMAuthentication`
> but I'm
On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs wrote:
>> hmm... I don't see any issue in adding the load call to
>> `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect
>> that libnet would have been loaded before we reach NTLMAuthentication.
>
> I wonder - do you see any f
On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter wrote:
>> I wonder - do you see any failure if you don't load libnet from there?
>
> Yes, there was an `UnsatisfiedLinkError` in the native method
> `isTrustedSiteAvailable()` in `NTLMAuthentication`.
> [...] I'd expect that libnet would have b
On Fri, 13 Sep 2024 16:12:28 GMT, Brian Burkhalter wrote:
>> Yes, there was an `UnsatisfiedLinkError` in the native method
>> `isTrustedSiteAvailable()` in `NTLMAuthentication`.
>
>> [...] I'd expect that libnet would have been loaded before we reach
>> NTLMAuthentication.
>
> In the (as of no
On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs wrote:
>>> [...] I'd expect that libnet would have been loaded before we reach
>>> NTLMAuthentication.
>>
>> In the (as of now) penultimate webrev 4f47d5a (Merge),
>> `WindowsNativeDispatcher` loaded it during boot phase 2. I think that
>> withou
On Fri, 13 Sep 2024 16:35:04 GMT, Brian Burkhalter wrote:
>> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded
>> by HttpURLConnection, which should have triggered the loading of libnet long
>> before it cares about NTLM.
>
> I would have to check. The failure I observe
On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs wrote:
>> I would have to check. The failure I observed occurred in both of these tests
>>
>> test/jdk/sun/net/www/protocol/http/NoNTLM.java
>> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
>>
>> and nowhere else.
>
> I see. The test
On Thu, 12 Sep 2024 02:10:00 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request in
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Clean up to address reviewer comments
>
> make/modules/java.base/lib/CoreLibraries.gmk line 68:
>
>
17 matches
Mail list logo
