On Thu, 22 Oct 2020 12:14:42 GMT, Jan Lahoda wrote:
>> This is the current proposed patch for the upcoming JEP 394, for pattern
>> matching for instanceof.
>>
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current
I did not reproduce issue with license is not shown as per SQE report. It work
as expected. However, jpackage fails due to unflatten/flatten being removed
from hdiutil on macOS 11. I am not sure why it was needed, probably some legacy
code. Without unflatten/flatten everything works as expected
On Fri, 23 Oct 2020 21:38:16 GMT, Jorn Vernee wrote:
>> This approach does not work for reference types, since they are erased to
>> `Object`, and then exact checking will be performed on the erased reference
>> types.
>>
>> For example try this:
>>
>> import java.lang.invoke.MethodHandles;
> Hi,
>
> This patch adds an asExact() combinator to VarHandle, that will return a new
> VarHandle that performs exact type checks, similar to
> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
> which can lead to performance degradation.
>
> This is implemented
On Fri, 23 Oct 2020 20:41:31 GMT, Paul Sandoz wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make internalName helper method static
>
> This approach does not work for reference types, since they are erased to
>
On Fri, 23 Oct 2020 18:06:51 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This patch adds an asExact() combinator to VarHandle, that will return a new
>> VarHandle that performs exact type checks, similar to
>> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
>> which can
On Fri, 23 Oct 2020 19:54:40 GMT, Igor Ignatyev wrote:
>> Hi Igor,
>> I think it depends on whether the tests will be permanently or temporarily
>> excluded from running with containers. I thought this mechanism would be to
>> permanently exclude the tests. That's why I used @requires.
>>
> On Oct 23, 2020, at 3:57 PM, Igor Ignatyev wrote:
>
> On Fri, 23 Oct 2020 19:25:27 GMT, Harold Seigel wrote:
>
>> I think it depends on whether the tests will be permanently or temporarily
>> excluded from running with containers. I thought this mechanism would be to
>> permanently
On Fri, 23 Oct 2020 19:25:27 GMT, Harold Seigel wrote:
> I think it depends on whether the tests will be permanently or temporarily
> excluded from running with containers. I thought this mechanism would be to
> permanently exclude the tests. That's why I used `@requires`.
I see, if this is
On Fri, 23 Oct 2020 19:17:40 GMT, Igor Ignatyev wrote:
>> Please review this change to add an @requires mechanism called
>> "jdk.containerized" to help mark tests that are incompatible with
>> containers. Users would add "@requires jdk.containerized != true" to the
>> incompatible tests and
Hi Bob,
Thanks for looking at this. I'll look into basing the option on an
environment variable.
Thanks, Harold
On 10/23/2020 3:12 PM, Bob Vandette wrote:
I wonder if it makes sense to add this option to
open/test/jtreg-ext/requires/VMProps.java and have it
automatically enable this
On Fri, 23 Oct 2020 18:44:54 GMT, Harold Seigel wrote:
> Please review this change to add an @requires mechanism called
> "jdk.containerized" to help mark tests that are incompatible with containers.
> Users would add "@requires jdk.containerized != true" to the incompatible
> tests and then
I wonder if it makes sense to add this option to
open/test/jtreg-ext/requires/VMProps.java and have it
automatically enable this option based on an environment variable so we don’t
have to remember the
cryptic command line sequence.
It’s too bad we can’t automatically detect that we are running
Please review this change to add an @requires mechanism called
"jdk.containerized" to help mark tests that are incompatible with containers.
Users would add "@requires jdk.containerized != true" to the incompatible tests
and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash
On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda wrote:
>> This is an update to javac and javadoc, to introduce support for Preview
>> APIs, and generally improve javac and javadoc behavior to more closely
>> adhere to JEP 12.
>>
>> The notable changes are:
>>
>> * adding support for Preview
On Wed, 21 Oct 2020 17:03:33 GMT, Alexey Semenyuk wrote:
> Don't run ldd and build list of dependency packages in case jpackage builds
> DEB package on non Debian Linux and RPM on Debian Linux. In this cases
> attempts to detect what packages provide libs will fail anyways, so don't
> waste
On Fri, 23 Oct 2020 09:14:48 GMT, Daniel Fuchs wrote:
>> The changes in src/java.desktop looks fine.
>
> Changes to `java.logging` and `java.net.http` also look good to me.
Hi Sergey,
I'll give it some testing and sponsor it next week unless someone else steps up.
best regards,
-- daniel
On Fri, 23 Oct 2020 18:02:11 GMT, Rémi Forax
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make internalName helper method static
>
>
On Fri, 23 Oct 2020 18:04:11 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This patch adds an asExact() combinator to VarHandle, that will return a new
>> VarHandle that performs exact type checks, similar to
>> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
>> which can
> Hi,
>
> This patch adds an asExact() combinator to VarHandle, that will return a new
> VarHandle that performs exact type checks, similar to
> MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
> which can lead to performance degradation.
>
> This is implemented
Hi,
This patch adds an asExact() combinator to VarHandle, that will return a new
VarHandle that performs exact type checks, similar to
MethodHandle::invokeExact, to help developers catch inexact VarHandle usage,
which can lead to performance degradation.
This is implemented using a boolean
On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this small exception message fix.
>
> Naoto
Looks good.
-
Marked as reviewed by bchristi (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/841
Hi,
Please review this small exception message fix.
Naoto
-
Commit messages:
- 8255242: Bidi.requiresBidi has misleading exception message
Changes: https://git.openjdk.java.net/jdk/pull/841/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=841=00
Issue:
On Wed, 21 Oct 2020 12:43:51 GMT, Hannes Wallnöfer wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 35 commits:
>>
>> - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into
>> JDK-8250768
>>
On Wed, 21 Oct 2020 17:03:33 GMT, Alexey Semenyuk wrote:
> Don't run ldd and build list of dependency packages in case jpackage builds
> DEB package on non Debian Linux and RPM on Debian Linux. In this cases
> attempts to detect what packages provide libs will fail anyways, so don't
> waste
On Fri, 23 Oct 2020 15:31:46 GMT, Aleksey Shipilev wrote:
>> It currently fails on x86_32 with `java.lang.IllegalStateException:
>> Misaligned access at address: 12`. I checked that once JDK-8254162
>> integrates, that issue is gone. Until then, having clean x86_32 testing is
>> beneficial
On Fri, 23 Oct 2020 16:39:57 GMT, Maurizio Cimadamore
wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix it instead of problem-listing
>
> Looks good
> > /approve
>
> "Files Changed" on top -> "Review
On Fri, 23 Oct 2020 16:21:29 GMT, Marcono1234
wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comment updates to class javadoc
>
> Do you want to refactor some of the classes where `HexFormat` would be a
>
On Fri, 23 Oct 2020 15:39:41 GMT, Maurizio Cimadamore
wrote:
>>> Yes - another thing worth considering though is: if 32bit alignment is the
>>> best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a
>>> double[] it seems, from what you are getting), then I think an even
On Wed, 21 Oct 2020 15:25:59 GMT, Hannes Wallnöfer wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 35 commits:
>>
>> - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into
>> JDK-8250768
>>
On Thu, 22 Oct 2020 15:55:30 GMT, Roger Riggs wrote:
>> java.util.HexFormat utility:
>>
>> - Format and parse hexadecimal strings, with parameters for delimiter,
>> prefix, suffix and upper/lowercase
>> - Static factories and builder methods to create HexFormat copies with
>> modified
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc behavior to more closely adhere
> to JEP 12.
>
> The notable changes are:
>
> * adding support for Preview APIs (javac until now supported primarily only
> preview
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc behavior to more closely adhere
> to JEP 12.
>
> The notable changes are:
>
> * adding support for Preview APIs (javac until now supported primarily only
> preview
> Test only change. With
> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
> been added on the hotspot side, but nothing for the Java Metrics code. Same
> for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
>
> When JDK-8217766 got fixed cgroup
On Fri, 23 Oct 2020 15:37:03 GMT, Aleksey Shipilev wrote:
>>> I can fix the whole thing thus, without problem listing the test then.
>>> Agree?
>>
>> Yes - another thing worth considering though is: if 32bit alignment is the
>> best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit
On Fri, 23 Oct 2020 15:25:47 GMT, Maurizio Cimadamore
wrote:
> Yes - another thing worth considering though is: if 32bit alignment is the
> best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a
> double[] it seems, from what you are getting), then I think an even better
>
> It currently fails on x86_32 with `java.lang.IllegalStateException:
> Misaligned access at address: 12`. I checked that once JDK-8254162
> integrates, that issue is gone. Until then, having clean x86_32 testing is
> beneficial for other work.
>
> Testing:
> - [x] Affected test on Linux
On Fri, 23 Oct 2020 15:03:55 GMT, Aleksey Shipilev wrote:
> I can fix the whole thing thus, without problem listing the test then. Agree?
Yes - another thing worth considering though is: if 32bit alignment is the best
we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a
On Fri, 23 Oct 2020 14:57:06 GMT, Maurizio Cimadamore
wrote:
>> Thing is, I don't think there is a way to problem list the _TestNG_
>> testcase, is it? There is only a way to problem list the entire jtreg test
>> or its separate `@run` with ID. Which is what the patch does. I would think
>>
On Fri, 23 Oct 2020 15:01:48 GMT, Aleksey Shipilev wrote:
>> Can you see if this helps?
>>
>> diff --git
>> a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
>>
>>
On Fri, 23 Oct 2020 14:45:22 GMT, Aleksey Shipilev wrote:
>> Ok - I understand at least why JDK-8254162 fixed it - JDK-8254162 uses a new
>> API to access memory (MemoryAccess) which disables alignment checks, so
>> that's why the issue doesn't happen. But that means that there could be a
>>
On Fri, 23 Oct 2020 14:33:11 GMT, Maurizio Cimadamore
wrote:
>> I'm not sure I get as to why the test fails on 32 bits - in the sense that
>> it does not seem to rely on platform specific assumptions (at least on a
>> quick look). On top of my head I'm not aware of what might have caused this
On Fri, 23 Oct 2020 14:26:07 GMT, Maurizio Cimadamore
wrote:
>> It currently fails on x86_32 with `java.lang.IllegalStateException:
>> Misaligned access at address: 12`. I checked that once JDK-8254162
>> integrates, that issue is gone. Until then, having clean x86_32 testing is
>>
On Fri, 23 Oct 2020 12:37:10 GMT, Aleksey Shipilev wrote:
> It currently fails on x86_32 with `java.lang.IllegalStateException:
> Misaligned access at address: 12`. I checked that once JDK-8254162
> integrates, that issue is gone. Until then, having clean x86_32 testing is
> beneficial for
It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned
access at address: 12`. I checked that once JDK-8254162 integrates, that issue
is gone. Until then, having clean x86_32 testing is beneficial for other work.
Testing:
- [x] Affected test on Linux x86_64 (still
On Fri, 23 Oct 2020 11:02:11 GMT, Magnus Ihse Bursie wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix whitespaces
>
> Changes requested by ihse (Reviewer).
@magicus the files you commented on are not
> Test only change. With
> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
> been added on the hotspot side, but nothing for the Java Metrics code. Same
> for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). This
> patch alleviates that.
>
>
I would like to have clean x86_32 test runs until JDK-8254162 arrives.
Testing:
- [x] Affected test on Linux x86_64 (still passes)
- [x] Affected test on Linux x86_32 (now ignored)
-
Commit messages:
- 8255331: Problemlist java/foreign/TestMismatch.java on 32-bit platforms
On Wed, 21 Oct 2020 20:05:31 GMT, Andy Herrick wrote:
>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains five commits:
>
> - Merge branch master into
On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore
wrote:
>> 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
On Thu, 22 Oct 2020 17:07:55 GMT, Mandy Chung wrote:
>> Thanks for the update. Lots of challenges finding the right API as there are
>> security and usability issues, not to mention performance and making it look
>> like the support for default methods has always been there.
>>
>> I've
On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the integration of tzdata2020c to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-October/60.html
> Bug:
On Fri, 23 Oct 2020 09:12:15 GMT, Daniel Fuchs wrote:
>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
>> reason to explicitly instantiate any instance of `Atomic*` class with its
>> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>>
On Thu, 22 Oct 2020 15:55:30 GMT, Roger Riggs wrote:
>> java.util.HexFormat utility:
>>
>> - Format and parse hexadecimal strings, with parameters for delimiter,
>> prefix, suffix and upper/lowercase
>> - Static factories and builder methods to create HexFormat copies with
>> modified
On Fri, 23 Oct 2020 08:15:00 GMT, Sergey Bylokhov wrote:
>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
>> reason to explicitly instantiate any instance of `Atomic*` class with its
>> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>>
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>
On Thu, 22 Oct 2020 20:56:44 GMT, Brian Burkhalter wrote:
> Please review this proposed fix. The review was initially in this thread
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061914.html
>
> under the old Hg SCM. The changes proposed here are derived from the final
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>
As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason
to explicitly instantiate any instance of `Atomic*` class with its default
value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()`
which is faster:
@State(Scope.Thread)
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
>
This looks like a legitimate bug to me (the zip file system implementation
is sensitive to the order of extra parameters and may throw an unexpected
error
on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no
permissions - but I think it'd be worth adding one?
Dawid
On Wed,
62 matches
Mail list logo
