Re: RFR: 8259074: regex benchmarks and tests [v2]

[Martin Buchholz]

> 8259074: regex benchmarks and tests

Martin Buchholz has updated the pull request incrementally with one additional 
commit since the last revision:

  address comments from @amalloy; introduce technically correct use of "numeral"

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1940/files
  - new: https://git.openjdk.java.net/jdk/pull/1940/files/cf0922f4..abb6c672

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

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

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

Re: RFR: 8259074: regex benchmarks and tests

[Alan Malloy]

On Tue, 5 Jan 2021 03:15:56 GMT, Martin Buchholz  wrote:

> 8259074: regex benchmarks and tests

test/jdk/java/util/regex/TestCases.txt line 1248:

> 1246: false 1
> 1247: 
> 1248: // Unary power of two (8), reluctant quantifier

I think the comment here is meant as "Giving a power of 2 as input to the 
primarily tester", but coming right after a unary primality tester commented 
with "Unary prime", it sounds like you are labeling this as a power-of-2 
detector.

-

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

Re: RFR: 8259074: regex benchmarks and tests

[Martin Buchholz]

On Tue, 5 Jan 2021 03:15:56 GMT, Martin Buchholz  wrote:

> 8259074: regex benchmarks and tests

@amalloy - you are invited to comment on regex content
@cl4es @shipilev - you are invited to point out my jmh bad practices

-

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

RFR: 8259074: regex benchmarks and tests

[Martin Buchholz]

8259074: regex benchmarks and tests

-

Commit messages:
 - more benchmarks
 - JDK-8259074

Changes: https://git.openjdk.java.net/jdk/pull/1940/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1940=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259074
  Stats: 444 lines in 5 files changed: 442 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1940/head:pull/1940

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

Re: bug jpackage in JDK 15

[Michael Hall]

> On Jan 29, 2021, at 7:37 PM, Michael Hall  wrote:
> 
> 
> 
>> On Jan 26, 2021, at 7:16 PM, Michael Hall > > wrote:
>> 
>>> 
>>> 
>>> When I open the built dmg there is an application icon, a drag to 
>>> indicating arrow, but no application folder icon as the drag target.
>>> 
>>> Possibly related…
>>> 
>>> Running [osascript, 
>>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>>  Blastoff-dmg-setup.scpt]
>>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>>  Blastoff-dmg-setup.scpt:1112:1334: execution error: Finder got an error: 
>>> Can’t make class alias file. (-2710)
>>> java.io.IOException: Command [osascript, 
>>> /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/jdk.incubator.jpackage15947685185521368596/config/BlackJack
>>>  Blastoff-dmg-setup.scpt] exited with 1 code
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:75)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:167)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:135)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:393)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:91)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:535)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:680)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:549)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:98)
>>> at 
>>> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:52)
> 
> This doesn’t necessarily seem to be security related. So possibly not related 
> to my other problem.
> I was going to try and re-open a bug report but that doesn’t appear currently 
> possible for me.
> 
> It seems it could possibly be the path for the Applications folder. Say if 
> you want something nice to get a name without a forward slash.
> Based on DMGSetup.scpt…
> 
> tell application "Finder"
>   set DEPLOY_VOLUME_PATH to "/Volumes/TestImage/"
>   set DEPLOY_INSTALL_LOCATION to "Applications"
>   set DEPLOY_INSTALL_NAME to "Applications"
>   make new alias file at POSIX file DEPLOY_VOLUME_PATH to POSIX file 
> DEPLOY_INSTALL_LOCATION with properties {name:DEPLOY_INSTALL_LOCATION}
> end tell
> 
> tell application "Finder"
>   make new alias file at file "TestImage:" to file ":Applications" with 
> properties {name:"Applications"}
> Result:
> error "Finder got an error: Can’t make class alias file." number -2710 from 
> alias file to class
> 
> You get the same error. Note INSTALL_LOCATION is used for both destination 
> and name.
> 
> If you make that a correct path with forward slash but have a separate name 
> variable without forward slash for the name.
> 
> tell application "Finder"
>   make new alias file at file "TestImage:" to file "Macintosh 
> HD:Applications:" with properties {name:"Applications"}
> end tell
> Result:
> alias file "Applications" of disk "TestImage" of application “Finder”
> 
> It works. I’m not sure unless something changed why that would suddenly be 
> broke but it does seem to be for DMG’s. 

This was a hypothetical, hopefully plausible, possibility that reproduced the 
actual error. I don’t work on the JDK and don’t know how I would debug to get 
the values actually being passed. Possibly a ‘debug’ option where the script 
output is saved instead of being written to a temporary file and disappearing 
could be useful?

Re: Why does Set.of disallow duplicate elements?

[Remi Forax]

Set.of() is the closest way we've got to a literal Set without having 
introduced a special syntax for that in the language.

The idea is that if you conceptually want to write
  Set set = { "hello", "world" };
instead, you write
  Set set = Set.of("hello", "world");

In that context, it makes sense to reject Set constructed with the same element 
twice because this is usually a programming error.
So
  Set.of("hello", "hello")
throws an IAE.

If you want a Set from a collection of elements, you can use
  Set.copyOf(List.of("hello", "hello"))

regards,
Rémi

- Mail original -
> De: "dfranken jdk" 
> À: "core-libs-dev" 
> Envoyé: Samedi 30 Janvier 2021 19:30:06
> Objet: Why does Set.of disallow duplicate elements?

> Dear users,
> 
> While looking at the implementation of Set.of(...) I noticed that
> duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an
> IllegalArgumentException. Why has it been decided to do this?
> 
> My expectation was that duplicates would simply be removed.
> 
> If I do for instance new HashSet<>()
> it works and duplicates are removed. To me, it looks a bit inconsistent
> to have duplicates removed for a collection passed in the constructor,
> but not for a collection (even though it is a vararg array) passed to a
> static factory method.
> 
> Kind regards,
> 
> Dave Franken

Re: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation [v3]

[Claes Redestad]

> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is 
> only used from ZipFile.initCEN right after the checkEncoding today, so 
> verifying this is equivalent is straightforward.
> - Factor out the logic to calculate hash, check encoding etc into the 
> addEntry method to allow JITs to chew off larger chunks of the logic early on
> 
> Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the 
> time required to open the jar file and thus exercising the optimized code.
> 
> Testing: tier1-4

Claes Redestad has updated the pull request incrementally with one additional 
commit since the last revision:

  Clarify comments, put normal path branch first in UTF8 checkedHash

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2306/files
  - new: https://git.openjdk.java.net/jdk/pull/2306/files/713e03b4..bb1659e3

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

  Stats: 12 lines in 1 file changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2306/head:pull/2306

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

Why does Set.of disallow duplicate elements?

[dfranken . jdk]

Dear users,

While looking at the implementation of Set.of(...) I noticed that
duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an
IllegalArgumentException. Why has it been decided to do this?

My expectation was that duplicates would simply be removed.

If I do for instance new HashSet<>()
it works and duplicates are removed. To me, it looks a bit inconsistent
to have duplicates removed for a collection passed in the constructor,
but not for a collection (even though it is a vararg array) passed to a
static factory method.

Kind regards,

Dave Franken

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3]

[Weijun Wang]

On Sat, 30 Jan 2021 00:06:51 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   phil comment
>
> Marked as reviewed by prr (Reviewer).

Added a test. Unfortunately it has to be `manual` because updating the dynamic 
store needs `sudo` privilege.

-

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

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v5]

[Weijun Wang]

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from 
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from 
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

Weijun Wang has updated the pull request incrementally with one additional 
commit since the last revision:

  a test
  
  only in patch2:
  unchanged:

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1845/files
  - new: https://git.openjdk.java.net/jdk/pull/1845/files/a0cad8fd..38616b32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1845=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1845=03-04

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

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

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v4]

[Weijun Wang]

> This fix covers both
> 
> - [[macOS]: Remove JNF dependency from 
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from 
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)

Weijun Wang has updated the pull request incrementally with one additional 
commit since the last revision:

  end values should be vectors

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1845/files
  - new: https://git.openjdk.java.net/jdk/pull/1845/files/ba3d1a1f..a0cad8fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1845=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1845=02-03

  Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1845/head:pull/1845

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

RFR: 8260401: StackOverflowError on open WindowsPreferences

[Jaikiran Pai]

Can I please get a review for this change which proposes to fix the issue 
reported in https://bugs.openjdk.java.net/browse/JDK-8260401?

As noted in that issue, when the constructor of 
`java.util.prefs.WindowsPreferences` runs into an error while dealing with the 
Windows registry, it logs a warning message. The message construction calls 
`rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being 
constructed) which then ultimately ends up calling the constructor of 
`WindowsPreferences` which then again runs into the Windows registry error and 
attempts to log a message and this whole cycle repeats indefinitely leading to 
that `StackOverFlowError`. 

Based on my limited knowledge of the code in that constructor and analyzing 
that code a bit, it's my understanding (and also the input provided by the 
reporter of the bug) that the log message should actually be using the 
`rootNativeHandle` parameter that is passed to this constructor instead of 
invoking the `rootNativeHandle()` method. The commit in this PR does this 
change to use the passed `rootNativeHandle` in the log message.

Furthermore, there's another constructor in this class which does a similar 
thing and potentially can run into the same error as this one. I've changed 
that constructor too, to avoid the call to `rootNativeHandle()` method in that 
log message. Reading the log message that's being generated there, it's my 
understanding that this change shouldn't cause any inaccuracy in what's being 
logged and in fact, I think it's now more precise about which handle returned 
the error code.

Finally, this log message creation, in both the constructors, also calls 
`windowsAbsolutePath()` and `byteArrayToString()` methods. The 
`byteArrayToString()` is a static method and a call to it doesn't lead back to 
the constructor again. The `windowsAbsolutePath()` is a instance method and 
although it does use a instance variable `absolutePath`, that instance variable 
is already initialized appropriately by the time this `windowsAbsolutePath()` 
gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't 
lead back to the constructor of the `WindowsPreferences` so it doesn't pose the 
same issue as a call to `rootNativeHandle()`.

Given the nature of this issue, I haven't added any jtreg test for this change.

-

Commit messages:
 - 8260401: StackOverflowError on open WindowsPreferences

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

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