It is a non-goal to replicate all of the JCK test coverage in the
regression test suite.
-Joe
On 10/25/2021 7:17 PM, Sergey Bylokhov wrote:
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote:
It looks like we cannot use `Long.hashCode(long)` for
`java.rmi.server.ObjID.hashCode()` due
On Mon, 25 Oct 2021 22:39:47 GMT, intrigus wrote:
> Question: Can someone confirm that `Method.invoke` will still work with 255
> parameters after this PR gets merged?
Thanks for the test case. For the case when method handles cannot be created
due to the arity limit, it can fall back to the
> This reimplements core reflection with method handles.
>
> For `Constructor::newInstance` and `Method::invoke`, the new implementation
> uses `MethodHandle`. For `Field` accessor, the new implementation uses
> `VarHandle`.For the first few invocations of one of these reflective
>
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: * >>
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/InetAddress.java line 169:
>
>> 167:
On Tue, 26 Oct 2021 12:52:58 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 following API
On Tue, 26 Oct 2021 06:30:39 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
On Tue, 26 Oct 2021 16:24:48 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 following API
> 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:
>
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 contains 14 additional
>>
On Tue, 26 Oct 2021 12:52:58 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 following API
On Tue, 26 Oct 2021 12:59:11 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/io/Console.java line 590:
>>
>>> 588: if (cs == null) {
>>> 589: cs = Charset.forName(StaticProperty.nativeEncoding(),
>>> 590: Charset.defaultCharset());
>>
>> I
On Mon, 18 Oct 2021 16:10:21 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For
On Thu, 14 Oct 2021 14:44:34 GMT, Julia Boes wrote:
> sun.reflect.ReflectionFactory provides MethodHandles for the various
> serialization methods, it is a critical internal API in the jdk.unsupported
> module (see JEP 260 [1]) that may be used by 3rd party serialization
> libraries.
>
>
On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato wrote:
> Trivial clean-up.
This pull request has now been integrated.
Changeset: 63e0f344
Author:Naoto Sato
URL:
https://git.openjdk.java.net/jdk/commit/63e0f344e9a2da135c76caff11e437dfc40408a6
Stats: 2 lines in 2 files changed: 0
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 Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote:
>> During the review of JEP 400, a proposal to provide an overloaded method to
>> `Charset.forName()` was suggested
>> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This
>> PR is to implement the proposal. A CSR is
On Tue, 26 Oct 2021 06:30:39 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
> 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:
>
On Tue, 26 Oct 2021 10:42:49 GMT, Daniel Fuchs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflecting review comments
>
> src/java.base/share/classes/java/io/Console.java line 590:
>
>> 588: if (cs ==
On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote:
>> During the review of JEP 400, a proposal to provide an overloaded method to
>> `Charset.forName()` was suggested
>> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This
>> PR is to implement the proposal. A CSR is
On Tue, 26 Oct 2021 19:48:47 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka 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 two additional
On Tue, 26 Oct 2021 19:48:47 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka 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 two additional
Please consider this proposed change to ignore comparing the total size of
`/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
-
Commit messages:
- 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976
Changes: https://git.openjdk.java.net/jdk/pull/6122/files
On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote:
> Please consider this proposed change to ignore comparing the total size of
> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
Alternative approaches would be to compare `File.getTotalSpace()` with
`FileStore.getTotalSpace()` and
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote:
> Enhance ASCII-compatible `DoubleByte` encodings to make use of the
> `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
> `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
> encoders - and
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote:
> Enhance ASCII-compatible `DoubleByte` encodings to make use of the
> `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
> `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
> encoders - and
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote:
> Enhance ASCII-compatible `DoubleByte` encodings to make use of the
> `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
> `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
> encoders - and
> cc @ctornqvi
Ivan Šipka 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 two additional commits since the
last revision:
- fixed OS identifier
-
Hello,
PR [1] and the accompanying article [2] have been subject to some
positive reactions in the last couple of weeks. A fresh set of about 20
thousand additional hard test cases kindly provided by Paul Zimmermann
of INRIA and other tests proposed by Guy Steele have been added to the code.
On Tue, 26 Oct 2021 19:00:44 GMT, Brian Burkhalter wrote:
> Please consider this proposed change to ignore comparing the total size of
> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
test/jdk/java/io/File/GetXSpace.java line 210:
> 208: if (Platform.isOSX() &&
On Tue, 26 Oct 2021 20:24:28 GMT, Naoto Sato wrote:
>> Please consider this proposed change to ignore comparing the total size of
>> `/dev` as returned by `DF(1)` and `STAT(2)` on macOS.
>
> test/jdk/java/io/File/GetXSpace.java line 210:
>
>> 208: if (Platform.isOSX() &&
On Tue, 26 Oct 2021 20:59:45 GMT, Igor Ignatyev wrote:
>> Ivan Šipka has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - fixed OS identifier
>> - 8274122: added to problem list
>
> And now you use an incorrect
On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote:
> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
> libraries are no longer present on the filesystem.
> `NativeLibraries::loadLibrary` checks for the file existence before calling
> `JVM_LoadLibrary`. Such
On Wed, 27 Oct 2021 03:31:00 GMT, Jaikiran Pai wrote:
>> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
>> libraries are no longer present on the filesystem.
>> `NativeLibraries::loadLibrary` checks for the file existence before calling
>> `JVM_LoadLibrary`.
On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
libraries are no longer present on the filesystem.
`NativeLibraries::loadLibrary` checks for the file existence before calling
`JVM_LoadLibrary`. Such check no longer applies on Big Sur. This proposes
that on
On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote:
> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
> libraries are no longer present on the filesystem.
> `NativeLibraries::loadLibrary` checks for the file existence before calling
> `JVM_LoadLibrary`. Such
On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote:
> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
> libraries are no longer present on the filesystem.
> `NativeLibraries::loadLibrary` checks for the file existence before calling
> `JVM_LoadLibrary`. Such
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the
On Tue, 26 Oct 2021 06:30:39 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>>
40 matches
Mail list logo
