On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz wrote:
> Test that when the jdk.incubator.vector module is present that libsvml.so is
> present, and test the opposite case.
The test logic should be changed.
If C2 is absent, libsvml.so would not be generated after JDK-8268643.
Thanks.
On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz wrote:
> Test that when the jdk.incubator.vector module is present that libsvml.so is
> present, and test the opposite case.
Looks good to me.
-
Marked as reviewed by sviswanathan (Reviewer).
PR:
On Tue, 15 Jun 2021 21:51:33 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 17 -> JDK 18
This pull request has now been integrated.
Changeset: e0f6f70d
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/e0f6f70d3f9e748d2bc53f371beca487e9343d4a
Stats: 1606
> Forwardport JDK 17 -> JDK 18
Jesper Wilhelmsson 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 25 additional commits
since the last revision:
-
Forwardport JDK 17 -> JDK 18
-
Commit messages:
- Merge jdk17
- 8268768: idea.sh has been updated in surprising and incompatible ways
- 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on
win-x64
- 8268723: Problem list SA core file tests on OSX when using
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 20:31:52 GMT, Erik Joelsson wrote:
> It got stuck in moderation. Tim has fixed the config now, so this message
> should hopefully appear.
Yep - I see emails now. Thanks this is really useful!
-
PR: https://git.openjdk.java.net/jdk17/pull/61
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 19:50:12 GMT, Erik Joelsson wrote:
> This comment should now end up in ide-support-dev as well.
Not really (at least for now) :-)
-
PR: https://git.openjdk.java.net/jdk17/pull/61
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote:
> The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like
> @apiNote. However, some of the discussion contained in AutoCloseable.close is
> more appropriate as an apiNote that normal text.
This pull request has now been
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote:
> The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like
> @apiNote. However, some of the discussion contained in AutoCloseable.close is
> more appropriate as an apiNote that normal text.
I'm confused: I thought that
On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote:
> The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like
> @apiNote. However, some of the discussion contained in AutoCloseable.close is
> more appropriate as an apiNote that normal text.
Marked as reviewed by naoto
On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote:
> The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like
> @apiNote. However, some of the discussion contained in AutoCloseable.close is
> more appropriate as an apiNote that normal text.
Marked as reviewed by bpb
On 15/06/2021 17:31, Erik Joelsson wrote:
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
As the title says (please also refer to the JBS issue which describes all the issues in
more details), the IDE support for IntelliJ has been updated with many enhancements as
part of a
The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like
@apiNote. However, some of the discussion contained in AutoCloseable.close is
more appropriate as an apiNote that normal text.
-
Commit messages:
- 8268736: Use apiNote in AutoCloseable.close javadoc
On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano wrote:
> Hi all,
>
> Could you please review the 8268457 bug fixes?
>
> The problem is that ToHTMLStream applies processing for non-surrogate pairs
> to the surrogate pair.
> This fix changes the processing for non-surrogate pairs to the else
On 6/15/21 10:15 AM, dfranken@gmail.com wrote:
Dear readers,
I think java.time.Duration is a pretty useful class and after having to
work a lot with it, I recognized there might be some enhancements we
could make (where 'enhancement' is a subjective term of course).
For instance:
On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
As the title says (please also refer to the JBS issue which describes all the
issues in more details), the IDE support for IntelliJ has been updated with
many enhancements as part of a seemingly innocuous "path handling" fix. The IDE
doesn't appear to be usable in the same way it was in the
On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 15:35:14 GMT, Maurizio Cimadamore
wrote:
> I can push to 17 if desired, but I'll need a new PR for that
pushing to 17 would be nice; the script is equally broken and unusable there.
-
PR: https://git.openjdk.java.net/jdk/pull/4492
On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore
wrote:
> As the title says (please also refer to the JBS issue which describes all the
> issues in more details), the IDE support for IntelliJ has been updated with
> many enhancements as part of a seemingly innocuous "path handling" fix.
On Tue, 15 Jun 2021 at 15:16, wrote:
> Comparison
> --
> boolean isGreaterThan(Duration duration) / isLongerThan(..)
> boolean isSmallerThan(Duration duration) / isShorterThan(..)
>
> English is not my primary language so I don't know which of these
> aliases would be better. Given
Dear readers,
I think java.time.Duration is a pretty useful class and after having to
work a lot with it, I recognized there might be some enhancements we
could make (where 'enhancement' is a subjective term of course).
For instance:
Comparison
--
boolean isGreaterThan(Duration
As the title says (please also refer to the JBS issue which describes all the
issues in more details), the IDE support for IntelliJ has been updated with
many enhancements as part of a seemingly innocuous "path handling" fix. The IDE
doesn't appear to be usable in the same way it was in the
Seems like another big change is that we try to create an IDE module per
imported JDK module.
Again, whether this is feasible or not is something which deserves more
discussion. At the moment it just doesn't work.
Maurizio
On 15/06/2021 14:26, Maurizio Cimadamore wrote:
This PR removes
This PR removes support for the Ant support file. Without that, many of
the IDE actions are no longer working. Jtreg plugin support seems broken
as well, as you can no longer select which build target has to be
executed before the tests are run.
I think I'm a bit concerned by these changes,
Hi Brian,
thanks a lot!
It may be difficult to reproduce. Maybe a slow file system helps (like NFS).
Just let us know if you have questions.
Best regards,
Martin
Von: Brian Stafford
Datum: Dienstag, 15. Juni 2021 um 01:20
An: jdk-updates-...@openjdk.java.net ,
core-libs-dev@openjdk.java.net
In some JDK classes there's still the following hashCode() implementation:
long objNum;
public int hashCode() {
return (int) objNum;
}
This outdated expression should be replaced with Long.hashCode(long) as it
- uses all bits of the original value, does not discard any information
On 15/06/2021 10:35, Rafael Winterhalter wrote:
Hi Peter,
thanks for the suggestion. Byte Buddy still baselines to Java 5,
unfortunately method handles are not an option at this point. I am
looking into writing a Byte Buddy build plugin that discovers calls to
PrivilegedAction.run and wraps
Hi Peter,
thanks for the suggestion. Byte Buddy still baselines to Java 5,
unfortunately method handles are not an option at this point. I am looking
into writing a Byte Buddy build plugin that discovers calls to
PrivilegedAction.run and wraps those in a reflection-based AccessController
Hi Rafael,
On 13/06/2021 22:28, Rafael Winterhalter wrote:
Furthermore, it is difficult to create a working facade for dispatching to
the security manager only if it is available. Methods like
AccessController.doPrivileged are caller sensitive and by adding a utility
to a library, this utility
38 matches
Mail list logo
