On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in
> java.1) are handled separately.
>
> This initial generation also picks up the unpublished
On Wed, 29 May 2024 06:25:44 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which marks 2 constructors on
>> `java.net.Socket` as deprecated for removal?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
>> constructors, which allow for
On Wed, 29 May 2024 05:48:44 GMT, Jaikiran Pai wrote:
> Hello Alan, I've updated the PR to include a note on
> `SocketImpl.create(...)`. Does the wording look correct? I'll update the CSR
> too once we finalize on the text.
SocketImpl is for implementors (it's not a user facing API) so
On Wed, 29 May 2024 00:59:10 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which marks 2 constructors on
> `java.net.Socket` as deprecated for removal?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
> constructors, which allow for
On Sun, 26 May 2024 08:22:44 GMT, Lei Zhu wrote:
> Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and
> MulticastSocket.send(DatagramPacket, byte)
These methods are proposed to be deprecated for removal in JDK 23, it will be
JDK 25, maybe later, before they can be
On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote:
> Further, I confirm that if I pass that option to jlink or jpackage when
> creating a custom runtime, there is no warning.
Great! What about jpackage without a custom runtime, wondering if
--java-options can be tested.
-
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end
On Mon, 20 May 2024 18:39:31 GMT, Phil Race wrote:
>> make/conf/module-loader-map.conf line 105:
>>
>>> 103: java.smartcardio \
>>> 104: jdk.accessibility \
>>> 105: jdk.attach \
>>
>> The list of allowed modules has been rewritten from scratch, by looking at
>> the set of modules
On Fri, 17 May 2024 11:33:14 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the
On Mon, 20 May 2024 06:02:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in that issue these methods have
On Fri, 17 May 2024 11:50:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in that issue these methods have
On Fri, 17 May 2024 10:42:44 GMT, Alan Bateman wrote:
>> Sergey Chernyshev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update src/java.base/share/classes/java/net/Inet4Address.java
>>
>> Co
On Fri, 17 May 2024 08:46:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the
On Thu, 16 May 2024 09:12:20 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Fri, 17 May 2024 05:44:29 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Wed, 15 May 2024 10:40:34 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Wed, 15 May 2024 05:06:02 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which clarifies the value
> type for the `java.net.SocketOptions.SO_LINGER` option?
src/java.base/share/classes/java/net/SocketOptions.java line 197:
> 195: * {@link #setOption(int,
On Wed, 15 May 2024 10:34:01 GMT, Maurizio Cimadamore
wrote:
> I don't fully agree that this option is not module related (which is why I
> gave it that name). The very definition of illegal native access is related
> to native access occurring from a module that is outside a specific set. So
On Wed, 15 May 2024 00:54:43 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/arguments.cpp line 2271:
>>
>>> 2269: } else if (match_option(option, "--illegal-native-access=",
>>> )) {
>>> 2270: if (!create_module_property("jdk.module.illegal.native.access",
>>> tail,
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Fri, 10 May 2024 03:53:12 GMT, Nizar Benalla wrote:
>> Please review this simple change, aiming to fix current uses of `@since` in
>> the source code
>> -The constructor
>> BasicAuthenticator(java.lang.String,java.nio.charset.Charset) needs an
>> `@since 14` instead of 9.
>>
On Tue, 9 Apr 2024 07:54:19 GMT, Daniel Fuchs wrote:
> @jaikiran the only reservation I have is that the new wording makes it look
> like the default implementation of `ServerSocket` methods is going to call
> `SocketImpl::getOption(SocketOption<>)` while in fact it still calls
>
On Sun, 7 Apr 2024 08:16:56 GMT, Jaikiran Pai wrote:
> > So I think we need a follow-up to the change here to say that the value is
> > Boolean.FALSE to disable (or disabled), otherwise an Integer with the
> > linger timeout.
>
> I've opened https://bugs.openjdk.org/browse/JDK-8329825 to
On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket
>> and java.net.Socket classes?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
>> currently refer to the legacy
On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clean up
>> the documentation of `java.net.SocketOptions` interface?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing
>> documentation in this
On 07/04/2024 00:37, robert engels wrote:
Hi Daniel,
Here is a PR which fixes it.
I don't think anyone will be able to look at this PR until the "oca"
label is removed. Look for the comment that the bot added about signing
the OCA for instructions.
-Alan
On Fri, 5 Apr 2024 13:03:13 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket
>> and java.net.Socket classes?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
>> currently refer to the legacy
On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clean up
>> the documentation of `java.net.SocketOptions` interface?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing
>> documentation in this
On Sat, 6 Apr 2024 08:41:23 GMT, Jaikiran Pai wrote:
> Alan, in context of another old issue
> https://bugs.openjdk.org/browse/JDK-6431396 would you want anything more to
> be added/updated for the `SO_BINDADDR` field's javadoc as part of this PR?
> The current update in PR already takes into
On Fri, 5 Apr 2024 12:06:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket
>> and java.net.Socket classes?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
>> currently refer to the legacy
On Fri, 5 Apr 2024 07:31:47 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only changes to java.net.ServerSocket
> and java.net.Socket classes?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
> currently refer to the legacy `java.net.SocketOptions`
On Fri, 5 Apr 2024 06:56:06 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which proposes to clean up
> the documentation of `java.net.SocketOptions` interface?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing
> documentation in this
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
On Wed, 6 Mar 2024 15:45:16 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
On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken wrote:
> We could maybe also use the existing
> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h
> - what do you think ?
jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't
think we
On Wed, 6 Mar 2024 09:26:25 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 !
src/java.base/share/native/libjava/jni_util.h line 243:
> 241: }
On Sun, 25 Feb 2024 14:20:54 GMT, Korov wrote:
> Make sun.net.www.MessageHeader final, and replace C-style array type
> declaration with Java-style array declaration.
The motivation for JDK-8325361 is to remove `@SuppressWarnings("this-escape")`
from the constructor.
-
PR
On Thu, 1 Feb 2024 12:55:39 GMT, Daniel Jeliński wrote:
> Please review this documentation change that:
> - removes networkcache.cache.*.ttl properties from the [System properties
> page](https://docs.oracle.com/en/java/javase/21/docs/api/system-properties.html)
> - Adds a link to the Security
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
On Sat, 13 Jan 2024 08:46:50 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes unused code from
>> `sun.net.www.protocol.jar.URLJarFile` and removes
>> `sun.net.www.protocol.jar.URLJarFileCallBack`?
>>
>> As noted in the linked issue
On 22/01/2024 08:43, Robert Engels wrote:
See github.com/robaho/httpserver for a more capable fork of the JDK code.
Would love to create a PR to move the core changes back into the JDK but the
net-dev folks don’t seem to be interested
As I recall, it wasn't really possible to do any
On 21/01/2024 20:18, Ethan McCue wrote:
Hi all,
Elliot[1] and I have been digging into the HTTP(S) server
implementation provided by the jdk.httpserver module.
It hasn't taken long to notice that the provided implementation
is...lacking. Both in performance, as it places extremely low and
On Sat, 13 Jan 2024 08:46:50 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes unused code from
>> `sun.net.www.protocol.jar.URLJarFile` and removes
>> `sun.net.www.protocol.jar.URLJarFileCallBack`?
>>
>> As noted in the linked issue
On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken wrote:
> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
> cleanup has been proposed before (and was done in the change). But there are
> a number of other places in the codebase where the import is done and still
>
On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote:
> Updated the version to 23-ea and year to 2024.
>
> This initial generation also picks up the unpublished changes from:
>
> - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool &
> jarsigner)
> -
On Tue, 28 Nov 2023 20:06:15 GMT, Mark Sheppard wrote:
> Hmm! sound like a bit of a fudge, and doesn't really make sense, as
> DatagramSocket and DatagramChannel essentially delegate to the same
> underlying implementation, which in turn delgates to the same underlying
> native implementation
On Tue, 28 Nov 2023 18:49:53 GMT, Mark Sheppard wrote:
> Returns: the local address to which the socket is bound, null if the socket
> is closed, or an InetAddress representing
>
On Tue, 28 Nov 2023 13:35:33 GMT, Mark Sheppard wrote:
> Also, the return for the case of an unbound DatagramSocket or DatagramChannel
> is not specified.
DatagramChannel::getLocalAddress is specified to return null when channel's
socket is not bound. DatagramSocket::getLocalSocketAddress
On Mon, 13 Nov 2023 17:28:29 GMT, Michael McMahon wrote:
> Hi,
>
> This is a small doc change for DatagramChannel.getLocalAddress() and the
> equivalent methods on DatagramSocket which documents some existing (but not
> currently documented) behavior.
>
> Thanks,
> Michael
Marked as
On Mon, 27 Nov 2023 14:24:32 GMT, Darragh Clarke wrote:
>> Currently the descriptions of `URLEncoder.encode` and `URLDecoder.decode`
>> don't specify their use of replacement bytes or replacement character when
>> they cannot handle a character or sequence of bytes. This is longstanding
>>
On Thu, 23 Nov 2023 11:18:17 GMT, Darragh Clarke wrote:
>> Currently the descriptions of `URLEncoder.encode` and `URLDecoder.decode`
>> don't specify their use of replacement bytes or replacement character when
>> they cannot handle a character or sequence of bytes. This is longstanding
>>
On Mon, 20 Nov 2023 16:08:10 GMT, Alan Bateman wrote:
> This is a Windows specific issue where a virtual thread attempting to
> establish a connection appears to hang, and the test eventually times out. It
> initially looked like an issue on older releases of Windows but it
On Mon, 20 Nov 2023 16:08:10 GMT, Alan Bateman wrote:
> This is a Windows specific issue where a virtual thread attempting to
> establish a connection appears to hang, and the test eventually times out. It
> initially looked like an issue on older releases of Windows but it
This is a Windows specific issue where a virtual thread attempting to establish
a connection appears to hang, and the test eventually times out. It initially
looked like an issue on older releases of Windows but it turns out to be an
issue that arises when a SOCKET handle is recycled quickly.
On Mon, 20 Nov 2023 12:44:12 GMT, Daniel Fuchs wrote:
> That's a good point. I see that there's another `decode(String, String)`
> method above in this file that has the same old `@implNote` but not
> `@throws`. Maybe the implNote should be removed there too and the `@throws`
> added. Not
On Mon, 20 Nov 2023 08:23:51 GMT, Matthias Baesken wrote:
>> There are a few places in the JDK C coding where the setsocktopt return
>> value is not handled but better should be handled.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Fri, 17 Nov 2023 16:15:46 GMT, Darragh Clarke wrote:
> Currently the descriptions of `URLEncoder.encode` and `URLDecoder.decode`
> don't specify their use of replacement bytes or replacement character when
> they cannot handle a character or sequence of bytes. This is longstanding
>
On Thu, 16 Nov 2023 13:22:10 GMT, Matthias Baesken wrote:
>> src/java.base/windows/native/libnio/ch/Net.c line 160:
>>
>>> 158:
>>> 159: /* IPV6_V6ONLY is true by default */
>>> 160: /* attempt to disable IPV6_V6ONLY to ensure dual-socket
>>> support; ignore errors */
>>
>>
On Thu, 16 Nov 2023 15:52:02 GMT, Matthias Baesken wrote:
>> There are a few places in the JDK C coding where the setsocktopt return
>> value is not handled but better should be handled.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Fri, 17 Nov 2023 08:07:02 GMT, Matthias Baesken wrote:
> Hi Alan, do you want an additional change to
> src/java.base/windows/native/libnio/ch/WindowsAsynchronousServerSocketChannelImpl.c
> ? Was not really sure about this after your comment about this chunk .
I think it's okay. The only
On Thu, 16 Nov 2023 13:14:16 GMT, Matthias Baesken wrote:
> Hi Alan, do you mean "drop this chunk from the change" or "drop the coding
> that is trying to copy the socket options" ?
Yes, I think drop SdpSupport.c from the PR. We probably should have removed the
SDP support a long time ago.
On Thu, 16 Nov 2023 08:39:32 GMT, Matthias Baesken wrote:
> There are a few places in the JDK C coding where the setsocktopt return value
> is not handled but better should be handled.
src/java.base/unix/native/libnet/SdpSupport.c line 100:
> 98: if (getsockopt(fd, SOL_SOCKET,
On Thu, 16 Nov 2023 08:39:32 GMT, Matthias Baesken wrote:
> There are a few places in the JDK C coding where the setsocktopt return value
> is not handled but better should be handled.
src/java.base/windows/native/libnio/ch/Net.c line 160:
> 158:
> 159: /* IPV6_V6ONLY is true by
On 16/11/2023 08:40, Baesken, Matthias wrote:
Hi Alan, thanks for the comment.
I created https://bugs.openjdk.org/browse/JDK-8320168 .
Okay, but please note that putting checks into some of these places will
require testing across a very wide range of systems. There are at least
some
On 14/11/2023 15:16, Baesken, Matthias wrote:
Hi, while looking at some net/nio coding, I noticed that at a lot of
places the return value of setsockopt is checked :
https://github.com/search?q=repo%3Aopenjdk%2Fjdk+%22setsockopt%22=code
On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich wrote:
>> The various Zip/Jar-file related Java APIs have some long-standing
>> differences or peculiarities with respect to the ZIP-file specification or
>> compared to other implementations which should be documented in the API-doc.
>>
On Mon, 13 Nov 2023 16:00:05 GMT, Yakov Shafranovich wrote:
> That would probably also involve taking existing documentation such as the
> note about not opening entries with "."/"..", and the POSIX permissions
> mappings? Would it make sense to split the rest of the changes in this PR
> from
On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich wrote:
>> The various Zip/Jar-file related Java APIs have some long-standing
>> differences or peculiarities with respect to the ZIP-file specification or
>> compared to other implementations which should be documented in the API-doc.
>>
On 10/11/2023 07:26, Shruthi Shruthi1 wrote:
Hi Alan.,
Please let us know if you have any suggestions/inputs for the earlier
update.
Sorry, I can't help you. The SAP and IBM engineers maintain the AIX port
and may be able to help diagnose this issue, it sounds like dup2 is
problematic.
On Wed, 20 Apr 2022 14:30:21 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Could I get the following PR review please? It adds a new JDK specific
>> extended socket option
>> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4
>> and IPv6
>> UDP sockets (NIO
On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote:
> The various Zip/Jar-file related Java APIs have some long-standing
> differences or peculiarities with respect to the ZIP-file specification or
> compared to other implementations which should be documented in the API-doc.
> This
On Thu, 2 Nov 2023 22:20:02 GMT, Martin Balao wrote:
>> src/java.base/share/classes/java/security/Security.java line 243:
>>
>>> 241: if (connection instanceof FileURLConnection
>>> fileConnection) {
>>> 242: // A local file URL can be interpreted as a Path
>>> 243:
On Thu, 2 Nov 2023 19:07:48 GMT, Francisco Ferrari Bihurriet
wrote:
> The implementation of this proposal is based on the requirements,
> specification and design choices described in the [JDK-8319332] ticket and
> its respective CSR [JDK-8319333]. What follows are implementation notes
>
On Fri, 20 Oct 2023 08:03:01 GMT, Daniel Jeliński wrote:
> ProxySelector.getDefault may return null if someone explicitly calls
> ProxySelector.setDefault(null); otherwise it's initialized to an instance of
> DefaultProxySelector
Right, I guess part of my puzzlement is to understand why
On Thu, 19 Oct 2023 12:10:02 GMT, Daniel Jeliński wrote:
> This patch fixes the encoding of IPv6 addresses in the URI provided to
> ProxySelector.
>
> The original code percent-encoded the square brackets added around the IPv6
> addresses, producing URIs that could not be parsed correctly.
>
On 18/10/2023 15:55, Nandagiri, Ramadasu (NSDi) wrote:
Hi,
Please see the discussion in the following mails. One of the TCK test
cases, api/java_net/MulticastSocket/ClassLevel.html is failing on
NonStop platform as NonStop doesn't support IP_MULTICAST_ALL option.
We would like this test
On Mon, 9 Oct 2023 07:00:08 GMT, Jaikiran Pai wrote:
> The new APIs are proposing to throw an `IllegalArgumentException` if the
> passed literal is not an IP address literal. That seems logical. However, the
> existing `getByAddress(byte[] ...)` API which accepts a byte form of the raw
> IP
On Sat, 7 Oct 2023 13:27:45 GMT, Mark Sheppard wrote:
> The sentence should have read "The functionality can be fully provided by
> adding an overloaded (static) getByAddress in the base InetAddress class,
> only."
>
> I wasn't suggesting that the current API was providing the requested
>
On Sat, 7 Oct 2023 11:32:43 GMT, Mark Sheppard wrote:
> The functionality can be fully provided by the overloaded (static)
> getByAddress in the base InetAddress class
I don't think I agree with this. The existing 2-arg getByAddress method takes a
string that is a host name or string
On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov wrote:
> ### Summary
>
> The changes in this PR add new API to `java.net.InetAddress`,
> `java.net.Inet4Address`, and
> `java.net.Inet6Address` classes to parse IP address literals:
> ```
> method public static java.net.InetAddress
>
On Thu, 12 Oct 2023 13:14:31 GMT, Matthias Baesken wrote:
> [JDK-8253119](https://bugs.openjdk.org/browse/JDK-8253119) removed the old
> socket implementation code but it did leave some unused code behind, it would
> be good to remove these unused functions.
Looks okay, I wonder if the list
On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin wrote:
> Hi,
>
> The events for socket read and socket write retrieves the remote address even
> in cases where the event didn't exceed the threshold. By moving the
> shouldCommit check earlier, it can be avoided.
>
> Testing: jdk/jdk/jfr
>
>
On Wed, 11 Oct 2023 07:58:21 GMT, Matthias Baesken wrote:
> When doing [JDK-8317603](https://bugs.openjdk.org/browse/JDK-8317603), it
> became clear that NET_SocketAvailable should be replaced.
Marked as reviewed by alanb (Reviewer).
-
PR Review:
On Mon, 9 Oct 2023 07:00:08 GMT, Jaikiran Pai wrote:
> The new APIs are proposing to throw an `IllegalArgumentException` if the
> passed literal is not an IP address literal. That seems logical. However, the
> existing `getByAddress(byte[] ...)` API which accepts a byte form of the raw
> IP
On Sat, 7 Oct 2023 13:27:45 GMT, Mark Sheppard wrote:
> The sentence should have read "The functionality can be fully provided by
> adding an overloaded (static) getByAddress in the base InetAddress class,
> only."
>
> I wasn't suggesting that the current API was providing the requested
>
On Sat, 7 Oct 2023 11:32:43 GMT, Mark Sheppard wrote:
> The functionality can be fully provided by the overloaded (static)
> getByAddress in the base InetAddress class
I don't think I agree with this. The existing 2-arg getByAddress method takes a
string that is a host name or string
On Thu, 21 Sep 2023 09:29:37 GMT, Claes Redestad wrote:
> There are mysterious interactions with `-Dfile.encoding=COMPAT` and
> `native.encoding` that I don't fully understand, but it does seem odd that
> `URLDecoder/-Encoder` rely directly on the `StaticProperty.fileEncoding()`
> string.
On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin wrote:
> Hi,
>
> The events for socket read and socket write retrieves the remote address even
> in cases where the event didn't exceed the threshold. By moving the
> shouldCommit check earlier, it can be avoided.
>
> Testing: jdk/jdk/jfr
>
>
On Fri, 22 Sep 2023 08:09:50 GMT, Claes Redestad wrote:
> I'd be happy to spell it out in the documentation, just pointing out that
> it's been long-standing behavior.
Right, I wasn't suggesting there is behavior change, instead I was pointing out
to Daniel that the spec is incomplete and we
On Thu, 21 Sep 2023 22:48:56 GMT, Claes Redestad wrote:
>> `URLEncoder` currently appends chars that needs encoding into a
>> `java.io.CharArrayWriter`, converts that to a `String`, uses
>> `String::getBytes` to get the encoded bytes and then appends these bytes in
>> a escaped manner to the
On Wed, 20 Sep 2023 11:21:51 GMT, Daniel Fuchs wrote:
> Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests?
I don't think so as these tests are just used to check that changes haven't
broken anything.
-
PR Comment:
On Wed, 20 Sep 2023 07:13:17 GMT, Deepa Kumari wrote:
>> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of
>> whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as
>> its's delegate. So, This can cause problems with operations like joinGroup.
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
>>> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
>>> https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event
>>> generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking,
>>> event
On Mon, 18 Sep 2023 23:17:22 GMT, Glavo wrote:
> I ran the tier1 test with no failures.
It's very important to run the tier2 tests as that is where the jdk_net test
group runs.
-
PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1724921264
On Mon, 18 Sep 2023 17:30:25 GMT, Daniel Jeliński wrote:
> WinHTTP functions are only used when an application:
> - uses DefaultProxySelector to resolve proxies, and
> - is run with -Djava.net.useSystemProxies=true
>
> In all other cases, loading winhttp.dll is a waste of resources.
>
>
1 - 100 of 327 matches
Mail list logo
