On Tue, 17 Nov 2020 05:02:07 GMT, Christoph Langer wrote:
>> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on
>> AIX.
>>
>> It tests that when a DNS server is unreachable it fails quickly with a
>> PortUnreachableException due to ICMP Destination Unreachable
Hi Vincente,
On 16/11/2020 11:36 pm, Vicente Romero wrote:
Please review the code for the second iteration of sealed classes. In this
iteration we are:
- Enhancing narrowing reference conversion to allow for stricter checking of
cast conversions with respect to sealed type hierarchies.
-
On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson wrote:
> I ran this test on a machine with 224 logical CPUs and it fails with:
>
> ITERATION 3
> test TestHandshake.testHandshake("SegmentMismatchAccessor",
> TestHandshake$$Lambda$57/0x0001000e7968@37c4b344): failure
>
On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes for upgrading the CLDR data to version 38. The vast
> majority of the changes are simply the changes in CLDR upstream, and others
> are mainly test changes due to the locale data change.
Looks like the
On Tue, 17 Nov 2020 22:21:18 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> Jim Laskey has
> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
> objects
> be shared between a hidden class and other classes. A hidden class can load
> these live objects as dynamically-computed constants via this API.
>
> Specdiff
>
On Tue, 17 Nov 2020 21:21:47 GMT, Roger Riggs wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding test coverage. Tweaking wording in docs.
>
> test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java
> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
> objects
> be shared between a hidden class and other classes. A hidden class can load
> these live objects as dynamically-computed constants via this API.
>
> Specdiff
>
> Added a cast in the right place, thanks to @jonathan-gibbons.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
cast to double instead of Object
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1274/files
-
Hi,
Please review the changes for upgrading the CLDR data to version 38. The vast
majority of the changes are simply the changes in CLDR upstream, and others are
mainly test changes due to the locale data change.
-
Commit messages:
- Updated the version in `cldr.md` files
-
An honest question,
why do we need so many interfaces for the different categories of
RandomGenerator ?
My fear is that we are encoding the state of our knowledge of the different
kinds of random generators now so it will not be pretty in the future when new
categories of random generator are
On Tue, 17 Nov 2020 22:12:19 GMT, Jim Laskey wrote:
>> @kevinrushforth What is the recommended approach to remove the doc
>> edit/commit?
>
> javadoc can be found at
> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
Presuming your master branch
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
Jim Laskey has updated the pull request with a new target base due to a
On Tue, 17 Nov 2020 21:59:04 GMT, Jim Laskey wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> @kevinrushforth What is the recommended approach to remove the doc
> edit/commit?
javadoc can be found at
- Mail original -
> De: "Brian Goetz"
> À: "Michael Kuhlmann" , "core-libs-dev"
>
> Envoyé: Mardi 17 Novembre 2020 20:44:17
> Objet: Re: 'Find' method for Iterable
> On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
>> But after thinking about it, I'm now convinced that it would be a bad
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
@kevinrushforth What is the recommended approach to remove
On Tue, 17 Nov 2020 19:58:29 GMT, Ian Graves wrote:
>> The `java.util.Formatter` format specifies support for field widths,
>> argument indexes, or precision lengths of a field that relate to the
>> variadic arguments supplied to the formatter. These numbers are specified by
>> integers,
On Tue, 17 Nov 2020 21:33:13 GMT, Magnus Ihse Bursie wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> This PR looks seriously messed up:
>
> JimLaskey added 30 commits on Oct 9
> @JimLaskey
> 8248862: Implement Enhanced
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
This PR looks seriously messed up:
JimLaskey added 30
On Tue, 17 Nov 2020 20:56:52 GMT, Jim Laskey wrote:
> my local branch seems to have the right sources for doc
Maybe, but your branch on GitHub does not.
-
PR: https://git.openjdk.java.net/jdk/pull/1273
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
Jim Laskey has updated the pull request incrementally with one additional
On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> It looks like
On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> It looks like
On Tue, 17 Nov 2020 20:01:37 GMT, Stuart Marks wrote:
> Added a cast in the right place, thanks to @jonathan-gibbons.
test/jdk/java/util/stream/boottest/java.base/java/util/stream/DoubleNodeTest.java
line 69:
> 67: assertEquals(list.size(), array.length);
> 68: for (int i = 0;
On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote:
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
It looks like you have
On Tue, 10 Nov 2020 09:34:56 GMT, Peter Levart wrote:
>> I can see that having a separate IMM_LIST_NULLS type might be necessary to
>> preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf
>> methods...
>>
>> NOTE ALSO that ListN.equals(o) and ListN.hashCode() are
Added a cast in the right place, thanks to @jonathan-gibbons.
-
Commit messages:
- 8256152: tests fail because of ambiguous method resolution
Changes: https://git.openjdk.java.net/jdk/pull/1274/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1274=00
Issue:
This PR is to introduce a new random number API for the JDK. The primary API is
found in RandomGenerator and RandomGeneratorFactory. Further description can be
found in the JEP https://openjdk.java.net/jeps/356 .
-
Commit messages:
- 8248862: Implement Enhanced Pseudo-Random
> The `java.util.Formatter` format specifies support for field widths, argument
> indexes, or precision lengths of a field that relate to the variadic
> arguments supplied to the formatter. These numbers are specified by integers,
> sometimes negative. For argument index, it's specified in the
On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
But after thinking about it, I'm now convinced that it would be a bad
idea. Because it extends the scope of this small, tiny Iterable
interface to something bigger which it shouldn't be.
This response captures the essence of the problem. You
On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee wrote:
> This PR sharpens the testing done by
> test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after
> @mcimadamore reported that the test was not catching an issue with memory
> access var handles; namely that the implementation of
I think that the discussion is still at the level of if it's an acceptable
addition and not yet at where to implement it. I gave my reasoning in
response to Stuart's points as to what I think is acceptable and what
isn't. Whether the java.lang package has special status is a bit ahead of
where we
This PR sharpens the testing done by
test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after @mcimadamore
reported that the test was not catching an issue with memory access var
handles; namely that the implementation of withInvokeBehavior was incorrect.
After some debugging it
On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore
wrote:
> The current memory segment implementation defines a hierarchy with 3 concrete
> classes: one for heap segments, one for native segments and one for mapped
> segments.
>
> Since there can be many kinds of heap segments (e.g.
On Mon, 16 Nov 2020 17:29:20 GMT, Roman Kennke wrote:
> A follow-up to JDK-8256106, this is adding two asserts to check that the API
> is used as it should be, i.e. only on inactive FinalReferences. Also, in
> Finalizer, where getInactive() is used, there is a null-check. The GC must
> never
The current memory segment implementation defines a hierarchy with 3 concrete
classes: one for heap segments, one for native segments and one for mapped
segments.
Since there can be many kinds of heap segments (e.g. created from a byte[] or
from a float[]) the current implementation is prone
On Tue, 17 Nov 2020 02:01:32 GMT, Alexey Semenyuk wrote:
>> In scenario 1, the installer would be Bar-1.0.{exe, msi, pkg ...}
>> The change in test above tests this.
>> Scenario 2 would be an error currently, since all jpackage commands require
>> a "--name" argument, however, it would be
On Mon, 16 Nov 2020 15:15:02 GMT, Andy Herrick wrote:
> … fix linux DTI
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/1229
On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson wrote:
> I ran this test on a machine with 224 logical CPUs and it fails with:
>
> ITERATION 3
> test TestHandshake.testHandshake("SegmentMismatchAccessor",
> TestHandshake$$Lambda$57/0x0001000e7968@37c4b344): failure
>
> This patch contains the changes associated with the first incubation round of
> the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
> access support (see JEP 393 [2] and associated pull request [3]).
>
> The main goal of this
On Sat, 24 Oct 2020 21:44:22 GMT, Rafael Winterhalter
wrote:
> A method's or constructor's owner type might carry annotations on its
> potential type parameters but is never represented as parameterized type what
> makes these parameters inaccessible at runtime, despite the presence of
>
On Mon, 16 Nov 2020 18:44:55 GMT, Rajan Halade wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix aarch64 test failure
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 387:
>
Allow `XMLStreamException` to be thrown to the application when a filtered
`XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped
`XMLStreamReader`.
Note, this PR includes a method signature change (constructor of
On Mon, 2 Nov 2020 10:47:18 GMT, Roland Westrelin wrote:
> This change add 3 new methods in Objects:
>
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long
On Tue, 17 Nov 2020 08:33:20 GMT, Roland Westrelin wrote:
>> This change add 3 new methods in Objects:
>>
>> public static long checkIndex(long index, long length)
>> public static long checkFromToIndex(long fromIndex, long toIndex, long
>> length)
>> public static long checkFromIndexSize(long
On Mon, 16 Nov 2020 11:51:32 GMT, Rafael Winterhalter
wrote:
>> I think it would be good to rebase on top of a recent jdk upstream before
>> merging.
>
> Rebased on HEAD/master.
Tier 1-3 looks good, go ahead and / integrate and I'll sponsor
-
PR:
On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson wrote:
> I ran this test on a machine with 224 logical CPUs and it fails with:
>
> ITERATION 3
> test TestHandshake.testHandshake("SegmentMismatchAccessor",
> TestHandshake$$Lambda$57/0x0001000e7968@37c4b344): failure
>
I ran this test on a machine with 224 logical CPUs and it fails with:
ITERATION 3
test TestHandshake.testHandshake("SegmentMismatchAccessor",
TestHandshake$$Lambda$57/0x0001000e7968@37c4b344): failure
java.lang.OutOfMemoryError: Cannot reserve 100 bytes of direct buffer
memory
On Tue, 17 Nov 2020 08:33:20 GMT, Roland Westrelin wrote:
>> This change add 3 new methods in Objects:
>>
>> public static long checkIndex(long index, long length)
>> public static long checkFromToIndex(long fromIndex, long toIndex, long
>> length)
>> public static long checkFromIndexSize(long
> This change add 3 new methods in Objects:
>
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
>
> This mirrors the int utility
50 matches
Mail list logo
