Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux
On Wed, 1 Sep 2021 12:51:15 GMT, Florian Weimer wrote: >> Hi, >> Please help me review the change to enhance getting time zone ID from >> /etc/localtime on linux. >> >> We use `realpath` instead of `readlink` to obtain the link name of >> /etc/localtime, because `readlink` can only read the value of a symbolic of >> link, not the canonicalized absolute pathname. >> >> For example, the value of /etc/localtime is >> "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by >> `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of >> `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which >> consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you >> can get “/usr/share/zoneinfo/Asia/Shanghai“ directly from “/etc/localtime“. >> >> Thanks, >> wuyan > > src/java.base/unix/native/libjava/TimeZone_md.c line 292: > >> 290: /* canonicalize the path */ >> 291: char resolvedpath[PATH_MAX + 1]; >> 292: char *path = realpath(DEFAULT_ZONEINFO_FILE, resolvedpath); > > You really should use `realpath` with `NULL` as the second argument, to avoid > any risk of buffer overflow. Future C library headers may warn about non-null > arguments here. Ok, Thanks. I will refer to the implementation of `os::Posix::realpath` to fix it if we still use `realpath`. https://github.com/openjdk/jdk/blob/5245c1cf0260a78ca5f8ab4e7d13107f21faf071/src/hotspot/os/posix/os_posix.cpp#L805 - PR: https://git.openjdk.java.net/jdk/pull/5327
Re: RFR: 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux
On Wed, 1 Sep 2021 12:38:38 GMT, Alan Bateman wrote: > I haven't come across this configuration like but changing it to use realpath > seem reasonable. Thanks, this scenario comes from our customers. > Using `realpath` instead of `readlink` will change results on systems which > use symbolic links instead of hard links to de-duplicate the timezone files. > For example, on Debian, if `UTC` is configured (`/etc/localtime` points to > `/usr/share/zoneinfo/UTC`), I think the result will be `Etc/UTC` instead of > `UTC` after this change. But I have not actually tested this. We tested it on ubuntu, it does have this kind of problem, thank you for your reminder. `realpath` doesn't seem to be suitable here, maybe we could directly process the previous `linkbuf` to remove the extra'.' and'/'. > The change looks reasonable. Please test your fix with macOS as well. Thanks, the test on macOS is passed. - PR: https://git.openjdk.java.net/jdk/pull/5327
RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296). - Commit messages: - 8273259: Character.getName doesn't follow Unicode spec for ideographs Changes: https://git.openjdk.java.net/jdk/pull/5354/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5354&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273259 Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5354/head:pull/5354 PR: https://git.openjdk.java.net/jdk/pull/5354
Re: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted > (https://bugs.openjdk.java.net/browse/JDK-8273296). Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5354
Re: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted > (https://bugs.openjdk.java.net/browse/JDK-8273296). Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5354
Re: RFR: 8273259: Character.getName doesn't follow Unicode spec for ideographs
On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote: > Simple spec clarification. A CSR has also been drafted > (https://bugs.openjdk.java.net/browse/JDK-8273296). Associated CSR also "Reviewed". - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5354
Re: RFR: 8271603: Unnecessary Vector usage in java.desktop [v6]
On Wed, 1 Sep 2021 19:46:51 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to >> use `ArrayList` if a thread-safe implementation is not needed. In >> post-BiasedLocking times, this is gets worse, as every access is >> synchronized. >> I checked only places where `Vector` was used as local variable. > > Andrey Turbanov has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains eight commits: > > - Merge remote-tracking branch 'origin/master' into > avoid-unnecessary-vector-usage-in-java.desktop > ># Conflicts: ># src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java > - 8271603: Unnecessary Vector usage in java.desktop >use toArray with zero sized array in places where Vector.copyInto was used > - 8271603: Unnecessary Vector usage in java.desktop >migrate even more usages > - 8271603: Unnecessary Vector usage in java.desktop >migrate more usages. Not sure how I missed them > - 8271603: Unnecessary Vector usage in java.desktop >revert back to use cycle to copy into array > - 8271603: Unnecessary Vector usage in java.desktop >revert back to Enumeration >bring back default values > - [PATCH] Unnecessary Vector usage in java.desktop >use zero-length array > - [PATCH] Unnecessary Vector usage in java.desktop src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1578: > 1576: } > 1577: String[] retValue = new String[temp.size()]; > 1578: temp.toArray(retValue); Why not `return temp.toArray(new String[0]);` like in other places in the last commit? - PR: https://git.openjdk.java.net/jdk/pull/4680
