Re: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image

[Jie Fu]

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.

-

Changes requested by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/47

Re: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image

[Sandhya Viswanathan]

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: https://git.openjdk.java.net/jdk17/pull/47

Integrated: Merge jdk17

[Jesper Wilhelmsson]

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 lines in 62 files changed: 1180 ins; 181 del; 245 mod

Merge

-

PR: https://git.openjdk.java.net/jdk/pull/4499

Re: RFR: Merge jdk17 [v2]

[Jesper Wilhelmsson]

> 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:

 - Merge jdk17
 - 8268620: InfiniteLoopException test may fail on x86 platforms
   
   Reviewed-by: prr, trebari, azvegint
 - 8268125: ZGC: Clone oop array gets wrong acopy stub
   
   Reviewed-by: kvn, vlivanov
 - 8238649: Call new Win32 API SetThreadDescription in 
os::set_native_thread_name
   
   Co-authored-by: Markus GaisBauer 
   Reviewed-by: stuefe, luhenry
 - 8268626: Remove native pre-jdk9 support for jtreg failure handler
   
   Reviewed-by: erikj
 - 8268699: Shenandoah: Add test for JDK-8268127
   
   Reviewed-by: rkennke
 - Merge
   
   Reviewed-by: dcubed
 - 8262731: [macOS] Exception from "Printable.print" is swallowed during 
"PrinterJob.print"
   
   Reviewed-by: prr
 - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: 
avoid underflow
   
   Reviewed-by: dcubed, stefank, kbarrett
 - 8266791: Annotation property which is compiled as an array property but 
changed to a single element throws NullPointerException
   
   Reviewed-by: darcy, jfranck
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/6da37cd0...e748b877

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4499/files
  - new: https://git.openjdk.java.net/jdk/pull/4499/files/e748b877..e748b877

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4499=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4499=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4499.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499

PR: https://git.openjdk.java.net/jdk/pull/4499

RFR: Merge jdk17

[Jesper Wilhelmsson]

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 ZGC
 - 8268736: Use apiNote in AutoCloseable.close javadoc
 - 8263321: Regression 8% in javadoc-steady in 17-b11
 - 8268125: ZGC: Clone oop array gets wrong acopy stub
 - 8268663: Crash when guards contain boolean expression
 - 8268347: C2: nested locks optimization may create unbalanced monitor 
enter/exit code
 - 8268643: SVML lib shouldn't be generated when C2 is absent
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/0b09129f...e748b877

The webrevs contain the adjustments done while merging with regards to each 
parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk=4499=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk=4499=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4499/files
  Stats: 1606 lines in 62 files changed: 1180 ins; 181 del; 245 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4499.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499

PR: https://git.openjdk.java.net/jdk/pull/4499

[jdk17] Integrated: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any targeted fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

This pull request has now been integrated.

Changeset: 788b3095
Author:Maurizio Cimadamore 
URL:   
https://git.openjdk.java.net/jdk17/commit/788b309563610b690306211790af17954f7556cb
Stats: 690 lines in 12 files changed: 492 ins; 63 del; 135 mod

8268768: idea.sh has been updated in surprising and incompatible ways

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk17/pull/61

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Erik Joelsson]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any targeted fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

It got stuck in moderation. Tim has fixed the config now, so this message 
should hopefully appear.

-

PR: https://git.openjdk.java.net/jdk17/pull/61

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Erik Joelsson]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any targeted fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

This comment should now end up in ide-support-dev as well.

-

PR: https://git.openjdk.java.net/jdk17/pull/61

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Erik Joelsson]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any targeted fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

Making the change here https://github.com/openjdk/skara/pull/1189

-

PR: https://git.openjdk.java.net/jdk17/pull/61

[jdk17] Integrated: 8268736: Use apiNote in AutoCloseable.close javadoc

[Joe Darcy]

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 integrated.

Changeset: 31a055e6
Author:Joe Darcy 
URL:   
https://git.openjdk.java.net/jdk17/commit/31a055e67a9a579a6b6ab26519271202da53a295
Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8268736: Use apiNote in AutoCloseable.close javadoc

Reviewed-by: bpb, naoto

-

PR: https://git.openjdk.java.net/jdk17/pull/63

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Erik Joelsson]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any targeted fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

Exactly, I need to add the label and the mailing list config.

-

PR: https://git.openjdk.java.net/jdk17/pull/61

Re: [jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc

[Pavel Rappo]

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 both https://openjdk.java.net/jeps/8068562 and the 
actual usages of `@apiNote` in `java.base` accumulated since then are advisory 
to the API users rather than to API implementors.

-

PR: https://git.openjdk.java.net/jdk17/pull/63

Re: [jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc

[Naoto Sato]

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 (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/63

Re: [jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc

[Brian Burkhalter]

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 (Reviewer).

-

PR: https://git.openjdk.java.net/jdk17/pull/63

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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 seemingly innocuous "path handling" fix. The IDE doesn't appear to be 
usable in the same way it was in the past and many functionalities have been broken as a 
result (including support for jtreg test execution using the plugin).

For the above reasons, I'm reverting the plugin and idea.sh code to last known 
working version. Any targeted fix can be re-applied after the revert. Larger 
enhancements need to be discussed in the proper venue:

https://openjdk.java.net/groups/ide-support/

I think reverting this is fine. In the original review, I tried to point out 
that it needed to be looked at by people who actually use this functionality, 
but that never happened.

I wasn't aware of the ide-support mailing list. Would you like me to add 
automatic filtering in Skara so that changes touching these files are 
automatically labelled and mailed to that list?


That would be welcome, yes! Unfortunately cc'ing ide-support using the 
PR command doesn't work either, so some changes is needed on the Skara side.


Thanks
Maurizio



-

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/61

[jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc

[Joe Darcy]

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

Changes: https://git.openjdk.java.net/jdk17/pull/63/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=63=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268736
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/63/head:pull/63

PR: https://git.openjdk.java.net/jdk17/pull/63

Re: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML

[Joe Wang]

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 condition.

The fix looks good to me.

For ToHTMLStream, please update the copyright year to 2021 (s/2019/2021) and 
s/@LastModified: Aug 2019/ @LastModified: June 2021.

For the test, please move it to test/jaxp/javax/xml/jaxp/unittest/transform and 
make it a testng test (add @run testng transform.SurrogateTest, and @Test to 
each test case). 
For the test itself, you may replace the try-finally block with a 
try-with-resources statement. For comparing with the gold files, please take a 
look at the existing test library, specifically 
test/jaxp/javax/xml/jaxp/libs/jaxp/library/JAXPTestUtilities.java, and do it 
the testng way, e.g. Assert.assertTrue(compareWithGold(goldFile, outputFile));

-

PR: https://git.openjdk.java.net/jdk/pull/4474

Re: Some possible enhancements for java.time.Duration?

[Robert Marcano]

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:

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 that classes such as Instant and
OffsetDateTime also have comparison methods (isAfter, isBefore), I
think it would be useful if Duration had easy comparison methods. Of
course we have compareTo(..) but I always get confused what it actually
means when I get a positive or negative number. :)


A small tip when using compareTo, don´t think about the numbers but the 
operation. Always compare to 0


  object1.compareTo(object2) > 0

==>

  object1 > object2


You only change the comparison operator, and it always means object1 
 object2




More comparison
---
   static Duration max(Duration d1, Duration d2)
   static Duration min(Duration d1, Duration d2)

Returns the longest resp. shortest of the two durations, where negative
durations are shorter than positive durations.

Side note: I have not found an easy method to obtain the max resp. min
values of elements which implement Comparable, I could only come up
with something like:

   Stream.of(Duration.ZERO, Duration.ofSeconds(1L))
 .max/min(Comparator.naturalOrder())
 .orElse(null);

It could be worthwile to add generic methods such as
   public static > T max(T... elements)
   public static > T min(T... elements)
in the Comparator class.

Disallowing negative value
--
Okay, this one is a bit more farfetched, but a method which would be
useful for my use case is to have an alternative of between() which is
never negative and just truncates to zero if it happens to be negative.

I'm measuring a duration between timestamps which come from different
systems which should be in sync with their NTP servers (and each
other), but there may still be some time dilation which could lead to
weird results making it look like the effect happened before the cause.

So I could see some use for a method like:

   Duration positiveOrZero()


Kind regards,

Dave Franken

Re: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Erik Joelsson]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any targeted fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

I think reverting this is fine. In the original review, I tried to point out 
that it needed to be looked at by people who actually use this functionality, 
but that never happened.

I wasn't aware of the ide-support mailing list. Would you like me to add 
automatic filtering in Skara so that changes touching these files are 
automatically labelled and mailed to that list?

-

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/61

[jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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 past and many 
functionalities have been broken as a result (including support for jtreg test 
execution using the plugin).

For the above reasons, I'm reverting the plugin and idea.sh code to last known 
working version. Any targeted fix can be re-applied after the revert. Larger 
enhancements need to be discussed in the proper venue:

https://openjdk.java.net/groups/ide-support/

-

Commit messages:
 - Add missing files
 - Initial push

Changes: https://git.openjdk.java.net/jdk17/pull/61/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=61=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268768
  Stats: 690 lines in 12 files changed: 492 ins; 63 del; 135 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/61.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/61/head:pull/61

PR: https://git.openjdk.java.net/jdk17/pull/61

Re: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any _targeted_ fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

closing - and recreating against 17

-

PR: https://git.openjdk.java.net/jdk/pull/4492

Withdrawn: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any _targeted_ fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/4492

Re: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Jonathan Gibbons]

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

Re: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any _targeted_ fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

I can push to 17 if desired, but I'll need a new PR for that

-

PR: https://git.openjdk.java.net/jdk/pull/4492

Re: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Jonathan Gibbons]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any _targeted_ fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

Does this need backported to 17 (or pushed to 17 and "back"ported into 18)?

-

PR: https://git.openjdk.java.net/jdk/pull/4492

Re: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Paul Sandoz]

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. The 
> IDE doesn't appear to be usable in the same way it was in the past and many 
> functionalities have been broken as a result (including support for jtreg 
> test execution using the plugin).
> 
> For the above reasons, I'm reverting the plugin and idea.sh code to last 
> known working version. Any _targeted_ fix can be re-applied after the revert. 
> Larger enhancements need to be discussed in the proper venue:
> 
> https://openjdk.java.net/groups/ide-support/

Agreed, let's back up and reevaluate.

-

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4492

Re: Some possible enhancements for java.time.Duration?

[Stephen Colebourne]

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 that classes such as Instant and
> OffsetDateTime also have comparison methods (isAfter, isBefore), I
> think it would be useful if Duration had easy comparison methods. Of
> course we have compareTo(..) but I always get confused what it actually
> means when I get a positive or negative number. :)

Maybe. Classes like OffsetDateTime have such methods because equals()
and compareTo() have different definitions. My gut feeling is that
this should not be done until Valhalla project has decided what if
anything it will do with the need for operator overloading on value
types.


> More comparison
> ---
>   static Duration max(Duration d1, Duration d2)
>   static Duration min(Duration d1, Duration d2)

I don't see the point of this. If such methods are to be added, they
should be generic, taking any Comparable


> Disallowing negative value
> --
> Okay, this one is a bit more farfetched, but a method which would be
> useful for my use case is to have an alternative of between() which is
> never negative and just truncates to zero if it happens to be negative.
>
> I'm measuring a duration between timestamps which come from different
> systems which should be in sync with their NTP servers (and each
> other), but there may still be some time dilation which could lead to
> weird results making it look like the effect happened before the cause.

I understand the use case, but it is too marginal for Duration IMO.

thanks
Stephen

Some possible enhancements for java.time.Duration?

[dfranken . jdk]

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 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 that classes such as Instant and
OffsetDateTime also have comparison methods (isAfter, isBefore), I
think it would be useful if Duration had easy comparison methods. Of
course we have compareTo(..) but I always get confused what it actually
means when I get a positive or negative number. :)

More comparison
---
  static Duration max(Duration d1, Duration d2)
  static Duration min(Duration d1, Duration d2)

Returns the longest resp. shortest of the two durations, where negative
durations are shorter than positive durations.

Side note: I have not found an easy method to obtain the max resp. min
values of elements which implement Comparable, I could only come up
with something like:

  Stream.of(Duration.ZERO, Duration.ofSeconds(1L))
.max/min(Comparator.naturalOrder())
.orElse(null);

It could be worthwile to add generic methods such as
  public static > T max(T... elements)
  public static > T min(T... elements)
in the Comparator class.

Disallowing negative value
--
Okay, this one is a bit more farfetched, but a method which would be
useful for my use case is to have an alternative of between() which is
never negative and just truncates to zero if it happens to be negative.

I'm measuring a duration between timestamps which come from different
systems which should be in sync with their NTP servers (and each
other), but there may still be some time dilation which could lead to
weird results making it look like the effect happened before the cause.

So I could see some use for a method like:

  Duration positiveOrZero()


Kind regards,

Dave Franken

RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

[Maurizio Cimadamore]

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 past and many 
functionalities have been broken as a result (including support for jtreg test 
execution using the plugin).

For the above reasons, I'm reverting the plugin and idea.sh code to last known 
working version. Any _targeted_ fix can be re-applied after the revert. Larger 
enhancements need to be discussed in the proper venue:

https://openjdk.java.net/groups/ide-support/

-

Commit messages:
 - Revert idea.sh
 - Revert idea support changes

Changes: https://git.openjdk.java.net/jdk/pull/4492/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4492=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268768
  Stats: 690 lines in 12 files changed: 492 ins; 63 del; 135 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4492.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4492/head:pull/4492

PR: https://git.openjdk.java.net/jdk/pull/4492

Re: Integrated: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac

[Maurizio Cimadamore]

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 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, in the sense that they 
tweak quite a lot of the functionality of the IDE project, in ways 
which makes them no longer working, and, more generally, this PR does 
a lot more than just replacing realpath, it seems.


I think we should back this out, and have a wider discussion (possibly 
using ide-support mailing list) as to whether some of the features in 
this PR are worth pursuing.


As things stand, I can no longer use the IDE in a way which works.

Maurizio

On 08/06/2021 15:39, Nikita Gubarkov wrote:
On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov 
 wrote:


I got rid of `realpath` usage as discussed in 
https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` 
macro instead, however there were quite a few problems with this 
macro, here's the example:


$(call RelativePath,/foo/bar,/foo/bar/baz) -> " ..//foo/bar"
$(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT
$(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> " ./baz/banan"
$(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> " ../baz"

As you can see, 1st case is just plain wrong, 2nd crashes make 
because of infinite loop, 3rd can be simplified and all of them have 
leading whitespaces
First commit in this PR fixes all these issues and adds 
corresponding test cases and second commit replaces usage of 
`realpath` in idea.sh with `RelativePath` macro in idea.gmk and 
fixes problems, when paths are incorrectly treated by IDEA

This pull request has now been integrated.

Changeset: 159cb6fa
Author:    Nikita Gubarkov 
Committer: Alexey Ushakov 
URL: 
https://git.openjdk.java.net/jdk/commit/159cb6facc668acc30552665e46b18edf58c3a91

Stats: 219 lines in 11 files changed: 107 ins; 47 del; 65 mod

8268083: JDK-8267706 breaks bin/idea.sh on a Mac

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/4369

Re: Integrated: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac

[Maurizio Cimadamore]

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, in the sense that they 
tweak quite a lot of the functionality of the IDE project, in ways which 
makes them no longer working, and, more generally, this PR does a lot 
more than just replacing realpath, it seems.


I think we should back this out, and have a wider discussion (possibly 
using ide-support mailing list) as to whether some of the features in 
this PR are worth pursuing.


As things stand, I can no longer use the IDE in a way which works.

Maurizio

On 08/06/2021 15:39, Nikita Gubarkov wrote:

On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov 
 wrote:


I got rid of `realpath` usage as discussed in 
https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro instead, 
however there were quite a few problems with this macro, here's the example:

$(call RelativePath,/foo/bar,/foo/bar/baz) -> "..//foo/bar"
$(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT
$(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> "./baz/banan"
$(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> "../baz"

As you can see, 1st case is just plain wrong, 2nd crashes make because of 
infinite loop, 3rd can be simplified and all of them have leading whitespaces
First commit in this PR fixes all these issues and adds corresponding test 
cases and second commit replaces usage of `realpath` in idea.sh with 
`RelativePath` macro in idea.gmk and fixes problems, when paths are incorrectly 
treated by IDEA

This pull request has now been integrated.

Changeset: 159cb6fa
Author:Nikita Gubarkov 
Committer: Alexey Ushakov 
URL:   
https://git.openjdk.java.net/jdk/commit/159cb6facc668acc30552665e46b18edf58c3a91
Stats: 219 lines in 11 files changed: 107 ins; 47 del; 65 mod

8268083: JDK-8267706 breaks bin/idea.sh on a Mac

Reviewed-by: erikj

-

PR: https://git.openjdk.java.net/jdk/pull/4369

AW: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64

[Doerr, Martin]

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 , Doerr, Martin 

Cc: Reka Kovacs , Aditya Mandaleeka 
, Monica Beckwith 
Betreff: RE: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes 
on Windows x64
Hi Martin,

We haven’t encountered this yet, to my knowledge, but we’ll see if we can 
reproduce it during our next sprint.

Thanks,
Brian Stafford



From: Doerr, Martin mailto:martin.do...@sap.com>>
Sent: Monday, June 14, 2021 3:17 AM
To: jdk-updates-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net; Reka 
Kovacs mailto:rekakov...@microsoft.com>>; Aditya 
Mandaleeka mailto:adit...@microsoft.com>>; Monica 
Beckwith mailto:monica.beckw...@microsoft.com>>
Subject: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on 
Windows x64

Hi,

we observe crashes in jdk 11.0.12 on Windows:
https://bugs.openjdk.java.net/browse/JDK-8267440

I haven’t found any backport which looks like obviously causing it.

We had different theories which include:

  *   Antivirus tool which keeps the test file open.
  *   Error in handling of OVERLAPPED structures.

I was hoping that 
JDK-8184157
 would fix it, but it doesn’t. Maybe it is incomplete?

Did anybody else notice such crashes?
Any idea?

Best regards,
Martin

RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable

[Сергей Цыпанов]

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 
upfront. For example, depending on how you are generating the IDs, the upper 
bits could change more frequently (or the opposite).

- does not introduce any bias towards values with more ones (zeros), as it 
would be the case if the two halves were combined with an OR (AND) operation.

See https://stackoverflow.com/a/4045083

This is related to https://github.com/openjdk/jdk/pull/4309

-

Commit messages:
 - 8268764: Use Long.hashCode() instead of int-cast where applicable

Changes: https://git.openjdk.java.net/jdk/pull/4491/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4491=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268764
  Stats: 15 lines in 9 files changed: 6 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491

PR: https://git.openjdk.java.net/jdk/pull/4491

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Levart]

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 those in a reflection-based 
AccessController invocation. This does however not cover all corner 
cases. I have tabled the problem for now and will see how and if other 
libraries adapt.

Best regards, Rafael



Maybe the problem would be clearer if you described what Byte Buddy 
normally does with code that uses AccessController.doPrivileged. Does 
Byte Buddy also use AccessController.doPrivileged internally? What I 
mean is AccessControllerWrapper could be an independent library, 
compiled for at least JDK 7 target. Apps or libraries that want to be 
deployable across JDK 7 ... JDK X (where X is the release which removes 
AccessController API) could use this library instead of directly 
invoking AccessController API to achieve that. Apps that still want to 
run on JDK 5 or 6 probably are not also targeting JDK X at the same time 
right? Such apps can keep using AccessController API. Now how does 
ByteBuddy come into this picture? What does it do with code that either 
uses AccessController API and what would it have to do with code that 
uses AccessControllerWrapper instead?


Regards, Peter




Am Di., 15. Juni 2021 um 09:20 Uhr schrieb Peter Levart 
mailto:peter.lev...@gmail.com>>:


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 would leak to any potential user. It
would
> therefore require package-private dispatchers for any relevant
package,
> which would lead to a lot of copy-paste to retain backwards
compatibility
> (given that a library cannot assume to be run as a module).


Here's my attempt / idea for such a utility which uses
MethodHandles.Lookup as an additional argument in order to
dispatch to a
caller-sensitive AccessControler.doPrivileged:

https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98



I don't know whether this helps much in your situation because apps
currently using AccessControler.doPrivileged would have to 1st
migrate
to using such utility wrapper so you would have to provide an
independent module containing it. But it is a possible solution in
the
long run when AccessControler API is removed from JDK.


Regards, Peter

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Rafael Winterhalter]

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
invocation. This does however not cover all corner cases. I have tabled the
problem for now and will see how and if other libraries adapt.
Best regards, Rafael

Am Di., 15. Juni 2021 um 09:20 Uhr schrieb Peter Levart <
peter.lev...@gmail.com>:

> 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 would leak to any potential user. It would
> > therefore require package-private dispatchers for any relevant package,
> > which would lead to a lot of copy-paste to retain backwards compatibility
> > (given that a library cannot assume to be run as a module).
>
>
> Here's my attempt / idea for such a utility which uses
> MethodHandles.Lookup as an additional argument in order to dispatch to a
> caller-sensitive AccessControler.doPrivileged:
>
> https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98
>
>
> I don't know whether this helps much in your situation because apps
> currently using AccessControler.doPrivileged would have to 1st migrate
> to using such utility wrapper so you would have to provide an
> independent module containing it. But it is a possible solution in the
> long run when AccessControler API is removed from JDK.
>
>
> Regards, Peter
>
>

Re: JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Levart]

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 would leak to any potential user. It would
therefore require package-private dispatchers for any relevant package,
which would lead to a lot of copy-paste to retain backwards compatibility
(given that a library cannot assume to be run as a module).



Here's my attempt / idea for such a utility which uses 
MethodHandles.Lookup as an additional argument in order to dispatch to a 
caller-sensitive AccessControler.doPrivileged:


https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98


I don't know whether this helps much in your situation because apps 
currently using AccessControler.doPrivileged would have to 1st migrate 
to using such utility wrapper so you would have to provide an 
independent module containing it. But it is a possible solution in the 
long run when AccessControler API is removed from JDK.



Regards, Peter