> Created two files for testing XPath Axes: XPathAncestors.java tests the
> ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the
> preceding and preceding-sibling axes.
Rahul Prabhu has updated the pull request incrementally with one additional
commit since the last revis
On Tue, 13 Sep 2022 05:23:20 GMT, Joe Wang wrote:
>> Rahul Prabhu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8289508: fixed whitespace
>
> It would be nice to cover some of the assertions made in the spec, e.g.:
> 2.2 Axes
> .
> Created two files for testing XPath Axes: XPathAncestors.java tests the
> ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the
> preceding and preceding-sibling axes.
Rahul Prabhu has updated the pull request incrementally with one additional
commit since the last revis
> Created two files for testing XPath Axes: XPathAncestors.java tests the
> ancestor and ancestor-or-self axes, while XPathPrecedingTest.java tests the
> preceding and preceding-sibling axes.
Rahul Prabhu has refreshed the contents of this pull request, and previous
commits have been removed. T
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
I've opened https://bugs.openjdk.org/browse/JDK-82938
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
Interesting, I remember changes like this causing fai
On Mon, 18 Jul 2022 22:33:15 GMT, Alex Kasko wrote:
> It is proposed to introduce support for `--win-codepage` argument, and
> substitute the `Codepage` attribute with `--win-codepage` specified value in
> primary l10n file when it is being copied to the config dir.
>
> Instead of copying all
On Wed, 17 Aug 2022 17:59:34 GMT, Brian Burkhalter wrote:
>> On Windows, suppress failure if the total space indicated by `df` is less
>> than `FileStore::getTotalSpace` and the free space indicated by `df` equals
>> `FileStore::getUnallocatedSpace`.
>
> Brian Burkhalter has updated the pull re
On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf wrote:
> Similar issue to the hotspot change discussed in
> https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation
> may get the resource limits wrong if there are additional cgroup fs mounts.
> Apparently that's more comm
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote:
>> I found out that reading from `DataInputStream` wrapping
>> `ByteArrayInputStream` (as well as `BufferedInputStream` or any
>> `InputStream` relying on `byte[]`) can be significantly improved by
>> accessing volatile `in` field only on
On Wed, 14 Sep 2022 07:33:32 GMT, Сергей Цыпанов wrote:
> > Does that mean there is no explicit test for DataInputStream endianess
>
> @ecki I think this is not strictly necessary as order of bytes is explicitly
> specified in JavaDoc of `DataInput` implemented by `DataInputStream`
Hm, maybe I
On Fri, 9 Sep 2022 08:30:55 GMT, KIRIYAMA Takuya wrote:
> Could you please review the JDK-8293579 bug fixes?
>
> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give
> the launcher the character which is encoded by Windows API
> WideCharToMultiByte()
> from UNICODE "é
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
Names are retrieved through aliases, so I think there
On Thu, 1 Sep 2022 21:17:30 GMT, Vladimir Kozlov wrote:
>> Yes; I removed support for --release 7 in JDK 20 early today.
>>
>>
>> On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote:
>>
>>> Likely requires a merge with master.
>>>
>>> —
>>> Reply to this email directly, view it on Gi
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote:
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
Reviewer request: @seanjmullan @egahlin
-
PR: https://git.openjdk.org/jdk/pull/9657
Add a JFR Event for `java.security.Provider.getService(String type, String
algorithm)` calls.
-
Commit messages:
- Track successful getInstance calls only
- Merge branch 'master' into 8254711-jfr-jca
- Refactor and use of static Event on
- Merge branch 'master' into 8254711-jfr-j
On Wed, 14 Sep 2022 11:57:17 GMT, Alan Bateman wrote:
> One other comment on the snippet is that the type of "jar" may not be obvious
> to readers. I think you'll need Path jar = ... in which case changing it
> Files.newInputStream(jar) might be simpler.
Updated per your suggestion
> I wonder
> Hi,
>
> Please review this update to the ZipInputStream class description to clarify
> that ZipInputStream walks sequentially through each Zip Entry contained
> within the Zip File. As a result, the CEN header for the Zip file entries
> are not read resulting in ZipInputStream not having acc
On Wed, 14 Sep 2022 12:53:12 GMT, Alan Bateman wrote:
> I think you can insert a comma after "when it is the first entry in the
> stream"? I think that would make it a bit clearer that there are two cases.
Done
>
> Also I'm wondering if the paragraph should be split into two, meaning "When
>
On Wed, 14 Sep 2022 15:53:41 GMT, Weijun Wang wrote:
> I have no more comment.
Thank you Max for your time and input
-
PR: https://git.openjdk.org/jdk/pull/10045
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update, we are finally documenting
> behavior that dates back to w
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
That is something we've patched locally e.g.
https:/
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
Should this not have included an update to the resour
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Wed, 14 Sep 2022 14:35:05 GMT, Alan Bateman wrote:
> > The changes to the `core-libs` look fine to me. There are some test
> > security policy files (for example `IsKeepingAlive.policy`) and the
> > `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no
> > longer exists. S
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Wed, 14 Sep 2022 14:21:09 GMT, Jaikiran Pai wrote:
> The changes to the `core-libs` look fine to me. There are some test security
> policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy`
> which use the `stopThread` `RuntimePermission` which no longer exists. Should
> th
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Tue, 13 Sep 2022 23:51:03 GMT, Mandy Chung wrote:
> The change looks good. There are other tests that reference `ThreadDeath` for
> example `test/lib/jdk/test/lib/process/ProcessTools.java`,
> `test/jdk/java/util/Timer/KillThread.java` ,
> `test/jdk/java/net/httpclient/reactivestreams-tck/o
On Tue, 13 Sep 2022 14:03:52 GMT, Roger Riggs wrote:
> fold with previous line.
Done.
-
PR: https://git.openjdk.org/jdk/pull/10230
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998)
> with a link to a supplementary page that explains
On Wed, 14 Sep 2022 10:51:21 GMT, Jie Fu wrote:
> I could reproduce the issue with `Files.createDirectories` on a macos with a
> trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/F
On Wed, 14 Sep 2022 10:31:41 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Tue, 13 Sep 2022 21:13:15 GMT, Lance Andersen wrote:
>> Hi,
>>
>> Please review this update to the ZipInputStream class description to clarify
>> that ZipInputStream walks sequentially through each Zip Entry contained
>> within the Zip File. As a result, the CEN header for the Zip file ent
Similar issue to the hotspot change discussed in
https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation
may get the resource limits wrong if there are additional cgroup fs mounts.
Apparently that's more common than one might think. I've reproduced this with
these existing
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand of a
> compound assignment is not assignment compatibl
On Wed, 14 Sep 2022 11:10:15 GMT, Adam Sotona wrote:
>> Please review this patch adding new lint option, **lossy-conversions**, to
>> javac to warn about type casts in compound assignments with possible lossy
>> conversions.
>>
>> The new lint warning is shown if the type of the right-hand ope
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand of a
> compound assignment is not assignment compatibl
On Wed, 14 Sep 2022 10:47:18 GMT, Jaikiran Pai wrote:
> I could reproduce the issue with `Files.createDirectories` on a macos with a
> trivial program. It appears to be because of the use of `NOFOLLOW_LINKS` here
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/
On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu wrote:
> Hi all,
>
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is
> a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw
> `FileAlreadyExistsException` if `parent` is a symbolic dir
On Wed, 14 Sep 2022 02:22:17 GMT, Weijun Wang wrote:
> Only tiny comments for the last paragraph.
Thank you Max, I addressed the above
>
> That said, I have some questions on the other parts of this file:
>
> 1. In `getNextEntry`, the method spec says "If verification has been
> enabled,
> Please review this PR which updates the JarInputStream class description to
> clarify when the Manifest is accessible via JarInputStream::getManifest and
> JarInputStream::get[Jar]Entry.
>
> It is worth noting that with this update, we are finally documenting
> behavior that dates back to w
On Wed, 14 Sep 2022 09:42:37 GMT, Jie Fu wrote:
> Hi all,
>
> runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is
> a symbolic link directory.
> The root cause is that `JarUtils.createJarFile` [1] will throw
> `FileAlreadyExistsException` if `parent` is a symbolic dir
Hi all,
runtime/Dictionary/ProtectionDomainCacheTest.java fails on Linux if `/tmp` is a
symbolic link directory.
The root cause is that `JarUtils.createJarFile` [1] will throw
`FileAlreadyExistsException` if `parent` is a symbolic directory.
So it seems better to test the existance of `parent` b
On Wed, 14 Sep 2022 01:05:35 GMT, Jaikiran Pai wrote:
> Hello Aleksey, could you also please create a release note for this? You may
> already know how to do that, if not, the steps are noted here
> https://openjdk.org/guide/#release-notes
Yes, but later, once CSR and this PR integrates in its
On Tue, 13 Sep 2022 20:04:08 GMT, Bernd wrote:
> Does that mean there is no explicit test for DataInputStream endianess
@ecki I think this is not strictly necessary as order of bytes is explicitly
specified in JavaDoc of `DataInput` implemented by `DataInputStream`
-
PR: https://g
51 matches
Mail list logo
