> 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 with a new target base due to a
merge or a rebase.
> 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 with a new target base due to a
merge or a rebase.
> 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 with a new target base due to a
merge or a rebase.
> 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 with a new target base due to a
merge or a rebase.
On Thu, 5 Dec 2024 18:44:06 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
On Thu, 5 Dec 2024 18:44:06 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
On Thu, 9 Jan 2025 13:06:55 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which clarifies the purpose
> of the HTTP server that's provided in the JDK's `jdk.httpserver` module? This
> should help avoid any confusion on the purpose of the server.
src/jdk.httpserve
> 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 with a new target base due to a
merge or a rebase.
> 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 with a new target base due to a
merge or a rebase.
On Tue, 19 Nov 2024 16:33:49 GMT, Sean Mullan wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 836: Address reviewer comments
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/
On Fri, 13 Sep 2024 20:41:27 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
> 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 with a new target base due to a
merge or a rebase.
On Tue, 19 Nov 2024 01:17:55 GMT, Brian Burkhalter wrote:
> Expunge the use of the `SecurityManager`, `AccessController`, and the like
> from the `jdk.sctp` module.
This pull request has now been integrated.
Changeset: f6f73ce7
Author: Brian Burkhalter
URL:
https://git.openj
> Expunge the use of the `SecurityManager`, `AccessController`, and the like
> from the `jdk.sctp` module.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
836: Address more reviewer comments
-
Changes:
> Expunge the use of the `SecurityManager`, `AccessController`, and the like
> from the `jdk.sctp` module.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
836: Address reviewer comments
-
Changes:
On Tue, 19 Nov 2024 13:57:01 GMT, Sean Mullan wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 836: Address reviewer comments
>
> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/
On Tue, 19 Nov 2024 07:30:01 GMT, Alan Bateman wrote:
> [...] so in theory there may be code that modifies the set [...]
That is precisely why I did not use `Set.of(saa)`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/5#discussion_r1848645515
On Tue, 19 Nov 2024 01:17:55 GMT, Brian Burkhalter wrote:
> Expunge the use of the `SecurityManager`, `AccessController`, and the like
> from the `jdk.sctp` module.
On a Linux system with SCTP, the results for the `com/sun/nio/sctp` tests are
the same with this patch applied as w
Expunge the use of the `SecurityManager`, `AccessController`, and the like from
the `jdk.sctp` module.
-
Commit messages:
- 836: Remove security manager dependency from module jdk.sctp
Changes: https://git.openjdk.org/jdk/pull/5/files
Webrev: https://webrevs.openjdk.org/?
On Fri, 13 Sep 2024 20:41:27 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
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu wrote:
> Please review this PR which fixes incorrect usage of `jthrowable
> ExceptionOccurred(JNIEnv *env)` within _java.base_.
>
> This corrects instances where the return value is being treated as a boolean.
> Such occurrences are replaced with `jbo
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
> 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
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 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: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 e
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 Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote:
> Can you hold off integrating, I plan to go over the changes soon.
I don't plan to integrate until you have reviewed it. I set the minimum
reviewer count to 3 to avoid doing so accidentally.
-
PR Comment: https://git.openjdk.o
On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter wrote:
>> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps
>> unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move
>> the load to a more appropriate location in t
On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeliński wrote:
> Thanks for making the changes. LGTM, assuming that tests still pass.
The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any
case, I will run another round of tests before integrating.
> src/java.base/unix/native/
On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeliński wrote:
>> Yes, it still needs to be called in a few places, e.g., for classes whose
>> native component needs the `fdval()` and `handleval()` functions.
>
> that's a good point. The comment might need to be updated to reflect that.
Comments adde
On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter wrote:
>> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line
>> 1097:
>>
>>> 1095:
>>> 1096: static {
>>> 1097: jdk.internal.loader.BootLoader.loadLibrary("
On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter wrote:
>> Just to be absolutely clear: All my other comments about removing unneeded
>> libraries were about libnio, not libjava. I realize I made the comment in
>> the PR next to libjava, but my intention was to ask if the
On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/Lib.gmk line 81:
>>
>>> 79: libjava/nio/ch \
>>> 80: libnio/ch \
>>> 81: libnio/fs \
>>
>> libnio/fs is gone on all platforms other than aix; is this still necessary?
>
> We can't add e
On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
> 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
On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie wrote:
>> Apparently I did remove it from libjava and not libnio. It will be fixed in
>> the next commit. Thanks for being persistent.
>
> Just to be absolutely clear: All my other comments about removing unneeded
> libraries were about libni
On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeliński wrote:
>> From a clean build in the CI with `mswsock.lib` removed:
>>
>>
>> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol
>> TransmitFile referenced in function
>> Java_sun_nio_ch_FileDispatch
On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeliński wrote:
>> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol TransmitFile`?
>
> Right. This PR moves FileDispatcherImpl.c to libjava, so
> FileDispatcherImpl.obj is no longer there. I'm guessi
On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
> 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 with a new target base due to a
merge or a rebase.
On Fri, 9 Aug 2024 17:59:12 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
On Mon, 12 Aug 2024 15:46:13 GMT, Alan Bateman wrote:
> please do not integrate this change until I get time
Sure, of course I will not.
Thanks to @magicus and @dfuch for helping to make it better.
-
PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2284529067
On Fri, 26 Jul 2024 21:34:07 GMT, Brian Burkhalter wrote:
> > Also think to work through some naming on IOUtil vs. NIOUtil as it won't be
> > obvious to maintainers which class to use.
>
> Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only
&
On Thu, 8 Aug 2024 14:33:15 GMT, Brian Burkhalter wrote:
>> src/java.base/windows/native/libjava/IOUtil.c line 37:
>>
>>> 35: #include "nio.h"
>>> 36: #include "nio_util.h"
>>> 37: /* #include "net_util.h" */
>>
On Fri, 9 Aug 2024 15:58:50 GMT, Brian Burkhalter wrote:
>> I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes
>> implementing InetAddressImpl. Both will make native calls to the "net"
>> library - so both require the library to be loaded.
>>
> 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
On Fri, 9 Aug 2024 15:47:07 GMT, Daniel Fuchs wrote:
>> Loading "net" was removed from IOUtil so I am thinking that IOUtil must have
>> been initialized somewhere before constructing Inet6AddressImpl, but I've
>> not identified where just yet.
>
> I see. Inet6AddressImpl and Inet4AddressImpl ar
On Fri, 9 Aug 2024 09:05:49 GMT, Daniel Fuchs wrote:
>> Without loading libnet in Inet6AddressImpl, the test
>> java/net/InetAddress/NullCharInHostnameDriver.java fails with
>> UnsatisfiedLinkError:
>>
>> java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[]
>> java.net.Inet6AddressImpl.loo
On Fri, 9 Aug 2024 09:40:59 GMT, Magnus Ihse Bursie wrote:
>> `pthread` is still needed:
>>
>> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error:
>> undefined reference to 'pthread_kill'
>
> Ok then. Thank you for your thorough checking!
Thank you for suggesting it!
-
On Thu, 8 Aug 2024 16:48:24 GMT, Brian Burkhalter wrote:
>> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you
>> might be able to see the issue in the same test that you observed failing
>> without your change.
>>
>> InetAddress has a s
On Thu, 8 Aug 2024 16:39:33 GMT, Daniel Fuchs wrote:
>> I'll have to investigate.
>
> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you
> might be able to see the issue in the same test that you observed failing
> without your change.
>
> InetAddress has a static blo
On Thu, 8 Aug 2024 14:31:09 GMT, Brian Burkhalter wrote:
>> And pthread?
>
> I will check.
`pthread` is still needed:
open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error:
undefined reference to 'pthread_kill'
-
PR Review Comment: https
On Thu, 8 Aug 2024 16:18:28 GMT, Daniel Fuchs wrote:
>> How would you suggest testing this?
>
> I don't know - you added that code to Inet6AddressImpl - so presumably a test
> was failing without that code?
> Which test was that? It wasn't obvious to me that adding code to load the
> "net" libr
On Thu, 8 Aug 2024 15:16:14 GMT, Daniel Fuchs wrote:
>> I have not seen any failures in CI testing. Is there a specific test that
>> would reveal whether this is a problem?
>
> It may be because we have no IPv4 only machine in the CI? It seems strange
> that IPv6 is treated differently than IPv
On Thu, 8 Aug 2024 09:11:31 GMT, Daniel Fuchs wrote:
>> Brian Burkhalter 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 contai
On Thu, 8 Aug 2024 12:18:04 GMT, Magnus Ihse Bursie wrote:
>> The Windows libs are also still required for `TransmitFile` and
>> `WSAGetLastError`:
>>
>> - ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved
>> external symbol TransmitFile```
>> - ```ws2_32.lib: FileDispatcherIm
On Wed, 7 Aug 2024 16:03:33 GMT, Brian Burkhalter wrote:
>> I will check. Thanks for noticing it.
>
> `CoreServices` is still necessary ([Uniform Type
> Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).
The Windows libs are also still required fo
On Wed, 7 Aug 2024 16:00:26 GMT, Brian Burkhalter wrote:
>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>>
>>> 69: -framework Foundation \
>>> 70: -framework SystemConfiguration, \
>>> 71: LIBS_windows := advapi3
On Wed, 7 Aug 2024 15:56:06 GMT, Magnus Ihse Bursie wrote:
>> Brian Burkhalter 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 contai
On Mon, 5 Aug 2024 15:37:46 GMT, Brian Burkhalter wrote:
>> make/modules/java.base/lib/CoreLibraries.gmk line 57:
>>
>>> 55: OPTIMIZATION := HIGH, \
>>> 56: EXTRA_HEADER_DIRS := \
>>> 57: libnio/ch, \
>>
>> This will introduce
> 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 with a new target base due to a
merge or a rebase. The in
On Fri, 26 Jul 2024 19:40:24 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
> 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
On Mon, 5 Aug 2024 15:19:33 GMT, Magnus Ihse Bursie wrote:
> This will introduce a source code dependency from libjava to libnio. It might
> be the correct thing to do, but I just want to highlight this.
I'll look into improving it.
> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>
>>
On Thu, 25 Jul 2024 10:05:03 GMT, Alan Bateman wrote:
> Also think to work through some naming on IOUtil vs. NIOUtil as it won't be
> obvious to maintainers which class to use.
Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only by
classes involved in networking?
> 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
On Wed, 24 Jul 2024 19:11:42 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.
Perhaps `/native/libjava/nio/ch` and
On Wed, 24 Jul 2024 19:11:42 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.
Yes, I was wondering about changing the org
On Wed, 24 Jul 2024 19:11:42 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.
This change passes CI tiers 1-5 jobs on all
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.
-
Commit messages:
- 8337143: (fc, fs) Move filesystem-related native objects from libnio to
libjava
Cha
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally with
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally with
On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
76 matches
Mail list logo
