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. create
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 w
> 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
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. create
On Wed, 18 Nov 2020 10:08:20 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. c
On 11/17/20 9:08 PM, Stuart Marks wrote:
@plevart wrote:
Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both
apps run on JDK16+, there will be no exception.
Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility across
JDK releases.
I would say i
* Peter Levart:
> But I see that the new IMM_LIST_NULLS type is needed for one other
> thing - the immutable list implementation of that type has different
> behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when
> null is passed to those methods) so this behavior has to be pre
- Mail original -
> De: "Florian Weimer"
> À: "Peter Levart"
> Cc: "Stuart Marks" , "core-libs-dev"
>
> Envoyé: Mercredi 18 Novembre 2020 12:55:02
> Objet: Re: RFR: 8180352: Add Stream.toList() method [v2]
> * Peter Levart:
>
>> But I see that the new IMM_LIST_NULLS type is needed fo
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 .
This pull request has b
On Wed, 18 Nov 2020 00:51:43 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Gene
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 fine from a
On Wed, 18 Nov 2020 13:18:30 GMT, Jim Laskey wrote:
>> I am unsure if the intent is also to support external libraries providing
>> `RandomGenerator` implementations. Currently there is an implicit contract
>> for properties (reflectively invoking a method returning a map with a set of
>> entr
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 .
javadoc can be found at
http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base
On Wed, 21 Oct 2020 00:11:42 GMT, John Lin
wrote:
>> Hi Jon,
>>
>> Can you explain what this change is about: e.g. something like:
>>
>>> Updates the documentation of `Map::compute` to match its default
>>> implementation:
>>> The documentation of the default implementation of `Map::compute`
On Tue, 17 Nov 2020 23:34:23 GMT, Stuart Marks wrote:
>> 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
Marked as reviewed by
On Wed, 18 Nov 2020 00:50:22 GMT, Mandy Chung wrote:
>> 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.
>>
>
ObjectInputStream has nearly identical but separate implementations to read
values from the stream.
Both implementations read primitive and object values from the stream and
return an object holding the values.
OIS.readFields() uses the internal class GetFieldImpl while
OIS.defaultReadObject and
On Wed, 18 Nov 2020 16:51:47 GMT, Paul Sandoz wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the name passed to condy calling classData
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3
On Wed, 18 Nov 2020 17:26:02 GMT, Paul Sandoz wrote:
> IIUC classData can be used for an original lookup that is not produced by the
> result of defineHiddenClassWithClassData, but in such cases the class data
> will always be null.
Yes that's the case. I see some clarification would help.
On Wed, 18 Nov 2020 17:26:02 GMT, Paul Sandoz wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the name passed to condy calling classData
>
> IIUC `classData` can be used for an original lookup that is not produc
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 w
> 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 d
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.
Changes seem fine
On Wed, 18 Nov 2020 14:16:03 GMT, Pavel Rappo wrote:
>> @dfuch May I ask how can I create a CSR? I checked
>> https://wiki.openjdk.java.net/display/csr/CSR+FAQs and it says:
>>
>>> Q: How do I create a CSR ?
>>> A: Do not directly create a CSR from the Create Menu. JIRA will let you do
>>> thi
On Tue, 17 Nov 2020 20:04:58 GMT, Stuart Marks wrote:
>>> @plevart wrote:
>>>
>>> > But the question is how does having a separate CollSer.IMM_LIST_NULLS
>>> > type prevent that from happening?
>>>
>>> When a serialized list with IMM_LIST_NULLS is deserialized on an older JDK,
>>> it'll throw
On Wed, 18 Nov 2020 07:46:33 GMT, Matthias Baesken wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains one commit:
>>
>> Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work
>> on AIX
Fix test failures. They didn't fail in Mach5 test runs as WiX was not available
on test machines and these tests were not executed.
-
Commit messages:
- 8227400: Adjust jib profiles to make 3rd party tools for creating installers
available on Mach5 test machines
Changes: https://g
On Mon, 16 Nov 2020 22:28:08 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 packets rece
Small change to retrieve the raw bytes of manifest during verifying signed JAR.
-
Commit messages:
- 8253299: Manifest bytes are read twice when verifying a signed JAR
Changes: https://git.openjdk.java.net/jdk/pull/1299/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=12
On Tue, 17 Nov 2020 20:01:37 GMT, Stuart Marks wrote:
> Added a cast in the right place, thanks to @jonathan-gibbons.
This pull request has now been integrated.
Changeset: 646c2002
Author:Stuart Marks
URL: https://git.openjdk.java.net/jdk/commit/646c2002
Stats: 1 line in 1 file c
> 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 d
> This change introduces a new terminal operation on Stream. This looks like a
> convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> method directly on Stream enables it to do what can't easily by done by a
…n name.
-
Commit messages:
- JDK-8256475: Fix Behavior when Installer name differs from application name.
Changes: https://git.openjdk.java.net/jdk/pull/1300/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK
On Wed, 18 Nov 2020 22:09:21 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, somet
On Wed, 18 Nov 2020 22:30:21 GMT, Roger Riggs wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exception message tweak
>
> src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java
> line 66:
>
> 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 d
On Wed, 18 Nov 2020 22:57:19 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, somet
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote:
> Small change to retrieve the raw bytes of manifest during verifying signed
> JAR.
This seems like a good optimization.
I think comparing the manifest name case insensitively might be preferable -
e.g. using String.equalsIgnoreCase - but
Hi, Roger.
The change looks good. I just noticed a couple small things:
2324 for (int i = 0; i < slots.length-1; i++) {
2325 new FieldValues(slots[i].desc, true);
The slots[i].hasData check is no longer performed here.
2561 primValues = new byte[desc.ge
Before this change, the setting of the
`jdk.internal.lambda.disableEagerInitialization` property was not captured
during dumping of lambda proxy classes. There's a workaround in
`LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above
property is set.
This change adds handl
On Wed, 18 Nov 2020 22:57:19 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, somet
On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote:
> Before this change, the setting of the
> `jdk.internal.lambda.disableEagerInitialization` property was not captured
> during dumping of lambda proxy classes. There's a workaround in
> `LambdaProxyClassArchive.find`, it won't call `findFr
> 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 d
On Thu, 19 Nov 2020 00:38:49 GMT, Stuart Marks wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 'unrepresentable' to 'not representable'
>
> test/jdk/java/util/IllegalFormatException/TestFormatSpecifierBounds.java lin
Refactor the vector conversions tests to improve performance and reduce
explicit test methods (using data providers).
-
Commit messages:
- 8256581: Refactor vector conversion tests
Changes: https://git.openjdk.java.net/jdk/pull/1302/files
Webrev: https://webrevs.openjdk.java.net/?
On Wed, 18 Nov 2020 21:57:13 GMT, Alexey Semenyuk wrote:
> Fix test failures. They didn't fail in Mach5 test runs as WiX was not
> available on test machines and these tests were not executed.
Marked as reviewed by almatvee (Committer).
-
PR: https://git.openjdk.java.net/jdk/pull/
On Wed, 18 Nov 2020 22:17:07 GMT, Andy Herrick wrote:
> …n name.
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line
312:
> 310: Path appDir;
> 311: if (appName == null) {
> 312: // this can only happen when no name is given and using
> f
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote:
> Small change to retrieve the raw bytes of manifest during verifying signed
> JAR.
The changes looks good. I am assuming that we do not need an additional test
for this and if so, please add a noreg label such as noreg-trivial to the bug
Hi,
Please review this simple change that catches UncheckedIOException that can
occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the
system, or if there is an interrupt while these are being read.
Testing: Tier1, Tier2 and Tier3.
Thanks,
Poonam
-
Commit mes
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 good to me.
On Thu, 19 Nov 2020 00:50:52 GMT, Claes Redestad wrote:
>> Before this change, the setting of the
>> `jdk.internal.lambda.disableEagerInitialization` property was not captured
>> during dumping of lambda proxy classes. There's a workaround in
>> `LambdaProxyClassArchive.find`, it won't call `f
8231547: Serializable class doc should link to serialization specification
Rewrite a couple confusing sentences in the Serializable class doc. This does
affect normative text, but the edits are primarily to focus and clarify the
text, not to make any semantic changes. Thus, a CSR request shouldn
Remove partially implemented in-place conversion vector operators from Vector
API:
ofNarrowing, ofWidening, INPLACE_XXX
-
Commit messages:
- 8256585: Remove in-place conversion vector operators from Vector API
Changes: https://git.openjdk.java.net/jdk/pull/1305/files
Webrev: ht
53 matches
Mail list logo