On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov wrote:
> Updated man pages from markdown sources.
Ok, I just hacked a patch file.
-
PR: https://git.openjdk.org/jdk19/pull/103
> Updated man pages from markdown sources.
Igor Veresov has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contains one new commit
since the last revisi
On Sat, 2 Jul 2022 02:45:43 GMT, Igor Veresov wrote:
> There is also a question of which version is actually correct. Yeah, may be I
> should manually craft a patch just for the Xcomp part.
@veresov please see the closed issue
https://bugs.openjdk.org/browse/JDK-8287821
@vnkozlov when I did
On Sat, 2 Jul 2022 02:12:43 GMT, Vladimir Kozlov wrote:
> I am not sure some words changes are correct?
>
> May be we should cleanup and update all these man pages as separate issue.
> And apply only `-Xcomp` changes.
>
Then I'd have to manually craft a patch instead of actually generating th
On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov wrote:
> Updated man pages from markdown sources.
There is also a question of which version is actually correct. Yeah, may be I
should manually craft a patch just for the Xcomp part.
-
PR: https://git.openjdk.org/jdk19/pull/103
Several instances of function pointers in jdk.crypto.cryptoki are marked with
the dllimport attribute, which should only be applied to symbol declarations,
of which a typedef'd function pointer is not. This would only be useful if a
function pointer defined in the linked dll is desired to be imp
On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov wrote:
> Updated man pages from markdown sources.
I am not sure some words changes are correct?
May be we should cleanup and update all these man pages as separate issue. And
apply only `-Xcomp` changes.
@iklam
you recently pushed changes https:/
On Tue, 28 Jun 2022 07:12:07 GMT, Julian Waters wrote:
> Several instances of function pointers in jdk.crypto.cryptoki are marked with
> the dllimport attribute, which should only be applied to symbol declarations,
> of which a typedef'd function pointer is not. This would only be useful if a
Updated man pages from markdown sources.
-
Commit messages:
- Update man pages
Changes: https://git.openjdk.org/jdk19/pull/103/files
Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8245268
Stats: 495 lines in 8 files ch
> https://bugs.openjdk.org/browse/JDK-8284851
Mark Powers has updated the pull request incrementally with one additional
commit since the last revision:
Max comments continued
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9282/files
- new: https://git.openjdk.org/jdk/pul
On Tue, 28 Jun 2022 20:58:17 GMT, Weijun Wang wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Valerie fix
>
> src/java.base/share/classes/java/security/Policy.java line 505:
>
>> 503: * A new {@code Policy} o
On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver wrote:
> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
> bytes, though the spec does not require random bytes
Just a comment, I believe both approaches are ok. The ISO 10126 spec says:
> When padding with octets...the f
On Fri, 1 Jul 2022 21:47:37 GMT, Kevin Driver wrote:
> Fix build break from JDK-8170762
This pull request has now been integrated.
Changeset: 44e8c462
Author:Kevin Driver
Committer: Weijun Wang
URL:
https://git.openjdk.org/jdk/commit/44e8c462b459a7db530dbc23c5ba923439c419b4
Stats:
On Fri, 1 Jul 2022 21:47:37 GMT, Kevin Driver wrote:
> Fix build break from JDK-8170762
LGTM.
-
Marked as reviewed by weijun (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9352
Fix build break from JDK-8170762
-
Commit messages:
- change copyright dates
Changes: https://git.openjdk.org/jdk/pull/9352/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9352&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8289603
Stats: 1 line in 1 file changed: 0
On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver wrote:
> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
> bytes, though the spec does not require random bytes
This pull request has now been integrated.
Changeset: 2dd00f58
Author:Kevin Driver
Committer: Weijun Wang
On Fri, 1 Jul 2022 14:45:44 GMT, Alan Bateman wrote:
> Does this address JDK-8288286 and allow ReflectionCallerCacheTest.java to be
> removed from ProblemList-Xcomp.txt?
I think JDK-8288286 should be addressed, but I would like to have it further
evaluated via more Mach5 testing before remove
On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver wrote:
> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
> bytes, though the spec does not require random bytes
Filed: https://bugs.openjdk.org/browse/JDK-8289602
> Approved. File another docs bug to update the doc.
-
On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver wrote:
> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
> bytes, though the spec does not require random bytes
Approved. File another docs bug to update the doc.
-
Marked as reviewed by weijun (Reviewer).
PR
On Fri, 1 Jul 2022 20:15:57 GMT, Weijun Wang wrote:
>> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
>> bytes, though the spec does not require random bytes
>
> Also, the bug title does not match code change. Randomness is not removed,
> it's documented.
@wangweij -
On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver wrote:
> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
> bytes, though the spec does not require random bytes
Also, the bug title does not match code change. Randomness is not removed, it's
documented.
-
PR
On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver wrote:
> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
> bytes, though the spec does not require random bytes
Bug reporter says "document it in the SunJCE documentation". I am not sure what
"SunJCE documentation" is, but
On Tue, 28 Jun 2022 20:19:29 GMT, Weijun Wang wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Valerie fix
>
> src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java
> line 249:
>
>> 247: *
JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random
bytes, though the spec does not require random bytes
-
Commit messages:
- update javadoc according to JDK-8170762
Changes: https://git.openjdk.org/jdk/pull/9350/files
Webrev: https://webrevs.openjdk.org/?rep
On Fri, 1 Jul 2022 15:28:36 GMT, Roger Riggs wrote:
> > Could someone in Oracle help me run Mach 5 testing?
>
> The CI Passed for Tiers 1-3.
Thanks a lot!
-
PR: https://git.openjdk.org/jdk/pull/8979
On Fri, 1 Jul 2022 08:31:28 GMT, Xue-Lei Andrew Fan wrote:
> Could someone in Oracle help me run Mach 5 testing?
The CI Passed for Tiers 1-3.
-
PR: https://git.openjdk.org/jdk/pull/8979
On Fri, 1 Jul 2022 14:26:24 GMT, Roger Riggs wrote:
>> Thanks @XueleiFan, that's fine by me!
>
> When using Reference/ReferenceQueue there is no Cleaner, only normal
> reference processing (via GC).
I have tests that use Reference/ReferenceQueue to check that an object that
uses a Cleaner has
On Fri, 1 Jul 2022 08:35:37 GMT, Xue-Lei Andrew Fan wrote:
>> This is a follow up update per comments in [JDK-8287384
>> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
>> open part looks good to me. Please help to run Mach5 just case the closed
>> test cases are i
On Fri, 1 Jul 2022 08:40:06 GMT, Daniel Fuchs wrote:
>> @dfuch Taking a reference as parameter could simplify the use of ForceGC.
>> I though about this idea as well, when I had to check lambada expressions in
>> each call. I would like to do it in the future so that this PR could focus
>>
On Fri, 1 Jul 2022 09:13:52 GMT, Daniel Fuchs wrote:
>> In case we read all bytes from an `InputStream` we don't need wrapping with
>> `BufferedInputStream` as the bytes are not written into internal buffer.
>> With removal of redundant buffer we save 8 kB of allocated memory.
>
>> In case we r
On Fri, 1 Jul 2022 08:06:10 GMT, Сергей Цыпанов wrote:
> In case we read all bytes from an InputStream we don't need wrapping with
> BufferedInputStream as the bytes are not written into internal buffer. With
> removal of redundant buffer we save 8 kB of allocated memory.
I believe that in tha
On Fri, 1 Jul 2022 08:26:30 GMT, Xue-Lei Andrew Fan wrote:
>> Maybe not for this PR - but it could be useful to have a version of ForceGC
>> that takes as parameter a `ReferenceQueue` and a `Reference`. That
>> would be more efficient than creating a new object and waiting for a
>> different c
On Thu, 30 Jun 2022 18:44:30 GMT, Xue-Lei Andrew Fan wrote:
>> This is a follow up update per comments in [JDK-8287384
>> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
>> open part looks good to me. Please help to run Mach5 just case the closed
>> test cases are
> This is a follow up update per comments in [JDK-8287384
> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
> open part looks good to me. Please help to run Mach5 just case the closed
> test cases are impacted.
Xue-Lei Andrew Fan has updated the pull request with a
On Fri, 1 Jul 2022 08:12:59 GMT, Daniel Fuchs wrote:
>> True, knowing when GC is 'done' is not deterministic except for a specify
>> Reference to a specific object.
>> System.gc is just a request, the checking for an object can more quickly
>> exit the loop.
>> The code is as is, and already co
On Thu, 30 Jun 2022 20:36:35 GMT, Roger Riggs wrote:
>> I'm not sure if all unused object will be collected in one GC call always.
>> The gc() specification says "When control returns from the method call, the
>> Java Virtual Machine has made a best effort to reclaim space from all unused
>>
In case we read all bytes from an `InputStream` we don't need wrapping with
`BufferedInputStream` as the bytes are not written into internal buffer. With
removal of redundant buffer we save 8 kB of allocated memory.
-
Commit messages:
- 8289572: InputStream wrapping with BufferedIn
37 matches
Mail list logo
