On Wed, 25 May 2022 09:30:46 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which addresses
>> https://bugs.openjdk.java.net/browse/JDK-8287104?
>>
>> The change in this commit now uses an `InnocuousThread` to create a thread
>> with `null` context classloader. The `Runna
On Mon, 23 May 2022 12:27:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which addresses
>> https://bugs.openjdk.java.net/browse/JDK-8287104?
>>
>> The change in this commit now uses an `InnocuousThread` to create a thread
>> with `null` context classloader. The `Runna
On Fri, 6 May 2022 09:18:33 GMT, Michael Felt wrote:
>> Michael Felt has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changes per review
>
> - Thx all for your assistance and patience.
> - (Hoping you will consider this for backport as we
On Sun, 22 May 2022 08:20:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8287104?
>
> The change in this commit now uses an `InnocuousThread` to create a thread
> with `null` context classloader. The `Runnable`
On Fri, 6 May 2022 09:18:33 GMT, Michael Felt wrote:
>> Michael Felt has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changes per review
>
> - Thx all for your assistance and patience.
> - (Hoping you will consider this for backport as we
On Thu, 5 May 2022 12:55:57 GMT, Michael Felt wrote:
>> with IP "0.0.0.0"
>>
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psue
On Sat, 30 Apr 2022 09:55:16 GMT, Michael Felt wrote:
>> with IP "0.0.0.0"
>>
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psu
On Fri, 29 Apr 2022 12:16:36 GMT, Michael Felt wrote:
>> with IP "0.0.0.0"
>>
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psu
On Mon, 28 Mar 2022 21:44:36 GMT, Aleksei Efimov wrote:
> The following fix seals `sun.net.dns.ResolverConfiguration` abstract class.
> `sun.net.dns.ResolverConfigurationImpl` is the only permitted subclass which
> has two O/S specific implementations: for `Windows` and `Unix` arch
The following fix seals `sun.net.dns.ResolverConfiguration` abstract class.
`sun.net.dns.ResolverConfigurationImpl` is the only permitted subclass which
has two O/S specific implementations: for `Windows` and `Unix` architectures.
Both of them are marked as `final`.
Testing: `jdk-tier1`, `jdk-ti
On Wed, 16 Mar 2022 13:26:36 GMT, Aleksei Efimov wrote:
> Hi,
>
> This cleanup change removes `InetAddressImplFactory` class from
> `InetAddress`. The list of changes:
> - Remove `InetAddressImplFactory` from `InetAddress`
> - Since `isIPv6Supported` native code is identic
moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
>
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change
Aleksei Efimov has updated the pull request with a new target base due to a
merge or a reba
On Fri, 11 Mar 2022 16:47:46 GMT, Aleksei Efimov wrote:
> The following fix seals the `java.net.InetAddress` class and permits only two
> implementations - `java.net.Inet4Address` and `java.net.Inet6Address`.
>
> No issues have been detected by regression and JCK tests.
>
On Wed, 16 Mar 2022 14:34:49 GMT, Daniel Fuchs wrote:
>> I agree that it could be simplified to match
>> `Java_java_net_InetAddress_isIPv4Available`. Changed in
>> 49fdd576cade2e97639f827f9db6d0f1e31101e2
>
> Thanks for noticing that Jaikiran!
>
> Both `ipv4_available()` and `ipv6_available()`
moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
>
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change
Aleksei Efimov has updated the pull request incrementally with one additional
commit
moved to the libnet's `InetAddress.c`.
> - `InetAddressImplFactory.c` Windows and Unix implementations were removed
>
> Testing: jdk-tier1 to jdk-tier3 tests show no failures related to the change
Aleksei Efimov has updated the pull request incrementally with one additional
commit since t
On Wed, 16 Mar 2022 13:49:39 GMT, Jaikiran Pai wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/native/libnet/InetAddress
Hi,
This cleanup change removes `InetAddressImplFactory` class from `InetAddress`.
The list of changes:
- Remove `InetAddressImplFactory` from `InetAddress`
- Since `isIPv6Supported` native code is identical for Windows and Unix
implementations it was moved to the libnet's `InetAddress.c`.
- `In
K-8282536)
> [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)
Aleksei Efimov 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 contains four additional
c
On Fri, 11 Mar 2022 16:47:46 GMT, Aleksei Efimov wrote:
> The following fix seals the `java.net.InetAddress` class and permits only two
> implementations - `java.net.Inet4Address` and `java.net.Inet6Address`.
>
> No issues have been detected by regression and JCK tests.
>
K-8282536)
> [CSR](https://bugs.openjdk.java.net/browse/JDK-8282880)
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Cleanup unnessecary class loader checks, remove readObjectNoData
-
Changes:
- all: https://git.open
The following fix seals the `java.net.InetAddress` class and permits only two
implementations - `java.net.Inet4Address` and `java.net.Inet6Address`.
No issues have been detected by regression and JCK tests.
Links: [JBS](https://bugs.openjdk.java.net/browse/JDK-8282536)
[CSR](https://bugs.openj
On Wed, 2 Feb 2022 08:31:08 GMT, Masanori Yano wrote:
> I added socket connection check same as IPv6_supported().
> Before this fix, when IPv4 is uninstalled (called `netsh interface ipv4
> uninstall`), and set property `-Djava.net.preferIPv4Stack=true`,
> java.net.InetAddress.PLATFORM_LOOKUP_P
The following fix clarifies spec for
`InetAddressResolverProvider.get(Configuration)` method to state that an error
or exception thrown by this method will be propagated to to the caller of the
method that triggered the lookup operation.
The `InetAddressResolverProvider#system-wide-resolver`
On Tue, 5 Oct 2021 12:00:15 GMT, Aleksei Efimov wrote:
> This change implements a new service provider interface for host name and
> address resolution, so that java.net.InetAddress API can make use of
> resolvers other than the platform's built-in resolver.
>
> The follo
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request wi
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request wi
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request with
On Wed, 27 Oct 2021 16:23:29 GMT, Michael McMahon wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add @ throws NPE to hosts file resolver javadoc
>
> src/java.base/share/classes/
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request increme
On Tue, 26 Oct 2021 15:04:54 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov 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 cont
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request inc
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request with
On Sat, 23 Oct 2021 06:19:46 GMT, Alan Bateman wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More javadoc updates to API classes
>
> src/java.base/share/classes/java/net/InetAd
On Tue, 26 Oct 2021 12:49:30 GMT, Aleksei Efimov wrote:
>> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java
>> line 45:
>>
>>> 43: * system-wide resolver instance, which is used by
>>> 44: * >> href="{@docRoot}/java.base
On Sat, 23 Oct 2021 06:33:52 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java
>> line 52:
>>
>>> 50: /**
>>> 51: * Initialise and return the {@link InetAddressResolver} provided by
>>> 52: * this provider. This method is called
On Wed, 20 Oct 2021 15:41:35 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change InetAddressResolver method names
>
> Marked as reviewed by dfuchs (R
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request incr
On Wed, 20 Oct 2021 18:47:32 GMT, Alan Bateman wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change InetAddressResolver method names
>
> src/java.base/share/classes/java
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request increm
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request increm
On Sun, 17 Oct 2021 21:03:56 GMT, Mark Sheppard wrote:
> getByName requires a hostname lookup and getByAdress requires (eventually - I
> know the docs says there’s no reverse lookup) an address reverse lookup.
> Thus, a logical mapping is getByName —> lookupHostname, and getByAddr —>
> lookupA
On Sun, 17 Oct 2021 21:39:06 GMT, Mark Sheppard wrote:
> I think that a hostname is constant while a host is up, but it can be
> changed, and when changed a host restart is required. I don't think it is
> quite as dynamic as has been suggested, but I open to correction.
It is possible to chang
On Fri, 15 Oct 2021 17:19:26 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add @since tags to new API classes
>> - Add checks and test for empty stream res
On Fri, 15 Oct 2021 17:09:46 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add @since tags to new API classes
>> - Add checks and test for empty stream reso
On Fri, 15 Oct 2021 14:25:02 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add @since tags to new API classes
>> - Add checks and test for empty stream reso
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull reque
On Sat, 16 Oct 2021 10:48:32 GMT, Mark Sheppard wrote:
> What’s in a name? I find the method names of the InetAddressResolver
> interface a bit ambiguous. Typically in this DNS problem space one speaks of
> lookup to resolve a hostname to its associated addresses and reverse lookup
> to resolv
On Sat, 16 Oct 2021 12:30:44 GMT, Mark Sheppard wrote:
> So Suggestion is refector remove Configuration to simplify the interface and
> provide the BULITIN_RESOLVER and hostname as parameters to the
> InetAddressResolverProvider::get method
During work on this JEP we've examined the approach s
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request incre
solver.LookupPolicy` - a class whose instances describe the
> characteristics of one forward lookup operation.
>
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>
> Testing: new and existing `tier1:tier3` tests
Aleksei Efimov has updated the pull request with
This change implements a new service provider interface for host name and
address resolution, so that java.net.InetAddress API can make use of resolvers
other than the platform's built-in resolver.
The following API classes are added to `java.net.spi` package to facilitate
this:
- `InetAddressR
On Wed, 29 Sep 2021 15:41:06 GMT, Aleksei Efimov wrote:
> The following fix proposes to remove usages of `"impl.prefix"` JDK system
> property from the `java.net.InetAddress` class.
> This system property is used to locate concrete implementations of the
The following fix proposes to remove usages of `"impl.prefix"` JDK system
property from the `java.net.InetAddress` class.
This system property is used to locate concrete implementations of the package
private "java.net.InetAddressImpl" interface.
The list of changes:
- `impl.prefix` usages ar
On Wed, 1 Sep 2021 16:53:50 GMT, Aleksei Efimov wrote:
> Hi,
>
> The fix changes indentations in the following `java.net.InetAddress` methods:
> - getAddressesFromNameService
> - getHostFromNameService
>
> It helps to improve code readability. Can
> Hi,
>
> The fix changes indentations in the following `java.net.InetAddress` methods:
> - getAddressesFromNameService
> - getHostFromNameService
>
> It helps to improve code readability. Can't say the same about
> `getHostFromNameService` diffs shown in this PR
On Wed, 1 Sep 2021 17:08:24 GMT, Brian Burkhalter wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8273243: looks -> looks like
>
> src/java.base/share/classes/java/net/Ine
Hi,
The fix changes indentations in the following `java.net.InetAddress` methods:
- getAddressesFromNameService
- getHostFromNameService
It helps to improve code readability. Can't say the same about
`getHostFromNameService` diffs shown in this PR.
-
Commit messages:
- 8273243: Fi
Hi,
For some time now we've been considering adding a standard service
provider interface for InetAddress APIs that will allow deployment of
alternative implementations of the underlying host name and address
resolution mechanisms.
After some prototyping work we have a draft JEP written:
On Mon, 12 Apr 2021 15:21:05 GMT, Conor Cleary wrote:
> ### Description
> `Inet6Address/B6206527.java` test creates two instances of ServerSocket, both
> of which are explicity bound to a Link-Local address. Neither of the
> ServerSocket instances are explicitly closed meaning there is no guara
On Tue, 30 Mar 2021 11:30:48 GMT, Aleksei Efimov wrote:
> Current fix tries to tackle an issue with URL connection referencing
> non-existing Jar file entries:
> If an entry that doesn't exist is specified in an URL connection the
> underlying Jar file is still cached even i
:
> - New regression tests
> - ``:jdk_core:`` tests
> - `api/java_util`,`api/java_net` JCK tests
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8264048: Remove old version of RemoveJar test
---
On Wed, 31 Mar 2021 11:24:02 GMT, Daniel Fuchs wrote:
>> Current fix tries to tackle an issue with URL connection referencing
>> non-existing Jar file entries:
>> If an entry that doesn't exist is specified in an URL connection the
>> underlying Jar file is still cached even if an exception is
Current fix tries to tackle an issue with URL connection referencing
non-existing Jar file entries:
If an entry that doesn't exist is specified in an URL connection the underlying
Jar file is still cached even if an exception is thrown after that. Such
behavior prevents the caller, for instance,
On Thu, 25 Feb 2021 15:38:02 GMT, Conor Cleary wrote:
>> A number of net tests use a
>> **[HostsFileNameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L955)**
>> to verify either the functionality of th
On Wed, 24 Feb 2021 10:24:06 GMT, Conor Cleary wrote:
> A number of net tests use a
> **[HostsFileNameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L955)**
> to verify either the functionality of this
On Tue, 12 Jan 2021 16:05:01 GMT, Aleksei Efimov wrote:
> Hi,
>
> The proposed change adds back [1] `instanceof` pattern match use to
> `HttpClientImpl` class. It was previously removed by
> [JDK-8258696](https://bugs.openjdk.java.net/browse/JDK-8258696) due to docs
Hi,
The proposed change adds back [1] `instanceof` pattern match use to
`HttpClientImpl` class. It was previously removed by
[JDK-8258696](https://bugs.openjdk.java.net/browse/JDK-8258696) due to docs
build failure.
Aleksei
[1] `git rollback be41468c --no-commit`
-
Commit messag
On Mon, 11 Jan 2021 23:29:53 GMT, Aleksei Efimov wrote:
>> @AlekseiEfimov `HttpClientImpl` is not in `java.base` module. So I think
>> it's better to not touch it under this PR.
>
> To double check that docs build will be stable after integration the
> following a
On Mon, 11 Jan 2021 17:12:24 GMT, Andrey Turbanov
wrote:
>> Hi @turbanoff,
>> This PR is ready for integration - `JDK-8258657` has been resolved.
>> You can proceed with issuing `integrate` bot command. Then I will `sponsor`
>> it.
>> But before that, I would like to ask if you would like to ta
On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov
wrote:
> 8258422: Cleanup unnecessary null comparison before instanceof check in
> java.base
Hi @turbanoff,
This PR is ready for integration - `JDK-8258657` has been resolved.
You can proceed with issuing `integrate` bot command. Then I will `sp
On Sat, 19 Dec 2020 10:29:23 GMT, Chris Hegarty wrote:
>> Thank you for checking `HttpURLConnection` and `Socket`.
>> The latest version looks good to me.
>
> This issue is blocked by [8258657][1]. It should not be integrated until
> after 8258657 has been resolved. The JIRA issues have been lin
On Fri, 18 Dec 2020 16:54:59 GMT, Chris Hegarty wrote:
> Temporarily revert use of pattern match instanceof construct until
> docs-reference is fixed, see JDK-8258657.
>
> ...
> Generating REFERENCE_API javadoc for 21 modules
>
> if (delegate instanceof ExecutorService service)
On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov
wrote:
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8258422: Cleanup unnecess
On Wed, 16 Dec 2020 09:44:37 GMT, Chris Hegarty wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>> use instanceof pattern m
On Wed, 2 Dec 2020 20:15:02 GMT, Andrey Turbanov
wrote:
>> This seems like a reasonable change, which improves readability.
>>
>> My preference is to wait a little longer (hopefully no more than a couple of
>> weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern
>> Matching f
On Fri, 4 Dec 2020 17:41:47 GMT, Daniel Fuchs wrote:
> The timeout tests extending AbstractConnectTimeout have been relaxed to
> accept a
> ConnectException wrapping NoRouteToHostException.
> These test have been observed failing intermittently with ConnectException
> wrapping
> java.nio.channe
77 matches
Mail list logo
