Hello Roger,
On 28/08/21 12:16 am, Roger Riggs wrote:
Hi,
I'm finding the idea of removing the hardcoded timestamp and adding a
property to restore compatibility
strangely attractive. I don't think we've yet found a case where the
timestamp was needed (but need to keep looking).
(Adding a
On Fri, 22 Oct 2021 10:17:13 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - drop final
>> - no need to check for null values
>
> src/java
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with two a
Hello Ioi,
On 21/10/21 9:59 pm, Ioi Lam wrote:
On 10/21/21 5:25 AM, Alan Bateman wrote:
On 21/10/2021 10:49, Jaikiran Pai wrote:
:
Digging into it, it appears that since the ModuleDescriptor#equals()
calls equals() on enum types (in this specific case
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one addi
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote:
> The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a
> timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The
> timeout seems to have happened even after the tests had already
Can I please get a review for this change which fixes the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8275509?
The `ModuleDescriptor.hashCode()` method uses the hash code of its various
components to compute the final hash code. While doing so it ends up calling
hashCode() on
Hello Ioi,
On 22/10/21 12:29 pm, Ioi Lam wrote:
On 10/21/21 9:09 PM, Jaikiran Pai wrote:
Hello Ioi,
This is my initial analysis of the problem.
>>> Can anyone think of similar problems that may happen elsewhere?
The static constructors of enum classes are executed at both
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote:
> The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a
> timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The
> timeout seems to have happened even after the tests had already
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one addi
On Mon, 25 Oct 2021 08:04:43 GMT, Magnus Ihse Bursie wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> drop another final to make it consistent with rest of the code
>
On Mon, 6 Dec 2021 16:59:41 GMT, Roger Riggs wrote:
>> The effects of invalid values of `jdk.serialFilter` and
>> `jdk.serialFilterFactory` properties are
>> incompletely specified. The behavior for invalid values of the properties is
>> different and
>> use an unconventional exception type,
open https://github.com/openjdk/jdk/pull/6477.
-Jaikiran
On 19/11/21 5:10 pm, Jaikiran Pai wrote:
I have been experimenting with
https://bugs.openjdk.java.net/browse/JDK-8224794 and have reached a
stage with my changes where I would like some inputs before I move
ahead or raise a PR for review
On Sun, 21 Nov 2021 12:39:17 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to add more
> diagnostics when a failure occurs in the jlink tool during the jpackage tests?
>
> As noted in https://bugs.openjdk.java.net/browse/JDK-8277507, so far 3
On Mon, 22 Nov 2021 08:14:20 GMT, Alan Bateman wrote:
> It might be that jlink is throwing IAE for cases where another exception is
> more appropriate, but it does suggests something intermittent in the jpackage
> tests to trigger it.
Issue https://bugs.openjdk.java.net/browse/JDK-8277058
On Mon, 22 Nov 2021 19:57:25 GMT, Roger Riggs wrote:
> The effects of an invalid `jdk.serialFilter` property are not completely
> documented. If the value of the system property jdk.serialFilter is invalid,
> deserialization should not be possible and it should be clear in the
>
Can I please get a review of this change which proposes to add more diagnostics
when a failure occurs in the jlink tool during the jpackage tests?
As noted in https://bugs.openjdk.java.net/browse/JDK-8277507, so far 3 failures
have been reported in jpackage tests (across different test cases)
On Sun, 21 Nov 2021 12:39:17 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to add more
> diagnostics when a failure occurs in the jlink tool during the jpackage tests?
>
> As noted in https://bugs.openjdk.java.net/browse/JDK-8277507, so far 3
On Tue, 23 Nov 2021 04:57:57 GMT, Alexander Matveev
wrote:
>> Can I please get a review of this change which proposes to add more
>> diagnostics when a failure occurs in the jlink tool during the jpackage
>> tests?
>>
>> As noted in https://bugs.openjdk.java.net/browse/JDK-8277507, so far 3
On Sat, 20 Nov 2021 19:13:43 GMT, Mandy Chung wrote:
> java.lang.reflect.Field::set on static field with invalid argument type
> should throw IAE. But this regression is introduced by JEP 416 throwing NPE
> instead.
>
> `ensureObj` is called as the first check of the `Field::set` method to
On Tue, 23 Nov 2021 15:08:43 GMT, Daniel D. Daugherty
wrote:
> This reverts commit 12f08ba4d47cb70a0629b17bc3639ce170309f21.
>
> The fix for JDK-8277507 is causing 38 failures per Tier2 job set.
Sorry, I should really have had run that original PR through `tier2` from
someone before merging
On Fri, 19 Nov 2021 00:14:34 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/lang/ref/Finalizer.java line 195:
>>
>>> 193:
>>> 194: static {
>>> 195: if (Holder.ENABLED) {
>>
>> Hello Stuart,
>> My understanding of the the lazy `Holder` is that it's there to delay the
I have been experimenting with
https://bugs.openjdk.java.net/browse/JDK-8224794 and have reached a
stage with my changes where I would like some inputs before I move ahead
or raise a PR for review.
As noted in that JBS issue, the idea is to open the underlying file
using FILE_SHARE_DELETE
On Tue, 9 Nov 2021 15:48:22 GMT, Roger Riggs wrote:
> When set on the command line `jdk.serialFilter` to an invalid value, the
> invalid value is logged but the application is allowed to start without
> setting the filter.
> This leaves the application without the protections of the serial
On Mon, 15 Nov 2021 22:43:37 GMT, Naoto Sato wrote:
> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
> PrintStream to its charset. This issue was raised during the conversations in
> https://github.com/openjdk/jdk/pull/5771
> A corresponding CSR has also been
On Sat, 13 Nov 2021 23:16:22 GMT, Sergey Bylokhov wrote:
> The ZipOutputStream class may create bogus zip data which cannot be opened by
> the ZipFile. The root cause is how the comment field is stored by the
> ZipOutputStream. According to the zip specification, the comment field should
>
On Mon, 15 Nov 2021 12:58:45 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8227020?
>
> The linked issue talks about non-normalized paths contributing to the leak.
> Ho
On Wed, 24 Nov 2021 14:06:29 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to k
Can I please get a review of this change which adds `jlink.debug=true` system
property while launching `jpackage` tests?
The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't
take into account the part where the `jpackage` tool gets launched as a
`ToolProvider` from some
Hello Andy,
On 24/11/21 7:23 pm, Andy Herrick wrote:
never mind my previous email, addArgument("--java-option ...") ,
would be for argument to the java launching the app.
you are right to use -J-Djlink.debug=true . It must be interpreted in
the standard launcher used for jpackage, because
require a bigger change and also a discussion on what kind of
> extending of module-info.class content will require a change to the
> lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 13
require a bigger change and also a discussion on what kind of
> extending of module-info.class content will require a change to the
> lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request incrementally with three additional
commits since the last revision:
- revie
On Sat, 20 Nov 2021 10:08:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8003417?
>
> The issue notes that this is applicable for `WeakHashMap` which have `null`
>
On Wed, 24 Nov 2021 17:06:41 GMT, Mandy Chung wrote:
>> jdeps intends to report an error if there are multiple versions of the same
>> class being parsed. module-info.class should be excluded from such
>> detection.
>>
>> This patch also fixes a data race in `VersionHelper::set` and also
On Mon, 13 Sep 2021 05:35:23 GMT, Jaikiran Pai wrote:
> The commit here is a potential fix for the issue noted in
> https://bugs.openjdk.java.net/browse/JDK-8258117.
>
> The change here repurposes an existing internal interface `ModuleInfoEntry`
> to keep track of the last mod
On Wed, 24 Nov 2021 15:04:35 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to k
require a bigger change and also a discussion on what kind of
> extending of module-info.class content will require a change to the
> lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request incrementally with four additional
commits since the last revision:
- rev
On Mon, 22 Nov 2021 08:25:38 GMT, Alan Bateman wrote:
>> Jaikiran Pai 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 contain
On Mon, 22 Nov 2021 09:09:37 GMT, Jaikiran Pai wrote:
>> test/jdk/tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java
>> line 60:
>>
>>> 58: private static final String UPDATED_MODULE_VERSION = "1.2.4";
>>> 59: private stat
On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to k
require a bigger change and also a discussion on what kind of
> extending of module-info.class content will require a change to the
> lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excl
require a bigger change and also a discussion on what kind of
> extending of module-info.class content will require a change to the
> lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
use proper Fi
Can I please get a review for this change which proposes to fix the issue
reported in https://bugs.openjdk.java.net/browse/JDK-8003417?
The issue notes that this is applicable for `WeakHashMap` which have `null`
keys. However, the issue is even applicable for `WeakHashMap` instances which
On Wed, 10 Nov 2021 20:51:20 GMT, Lance Andersen wrote:
> Hi all,
>
> This patch addresses a regression introduced in JDK 15 via JDK-8242959 where
> you can no longer access a file entry contained within a Zip file when there
> is also a directory entry with the same name via
On Mon, 15 Nov 2021 13:56:18 GMT, Alan Bateman wrote:
> I can't quite tell if you have something that runs into the issue or whether
> you just spotted the open issue
Hello Alan,
I just happened to notice this issue in JBS and thought of checking if there's
any interest in this fix. From the
On Mon, 15 Nov 2021 13:25:01 GMT, Daniel Fuchs wrote:
> Hi Jaikiran, is this still an issue now that Jar Index is disabled by
> default? (see https://git.openjdk.java.net/jdk/pull/5524)
Hello Daniel,
The issue is still reproducible (only) if the jar indexing is enabled by
setting the
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote:
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so
On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to k
On Thu, 11 Nov 2021 11:51:31 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1642:
>>
>>> 1640: && entry.startsWith(name) &&
>>> 1641: entry.charAt(entryLen - 1) == '/') {
>>> 1642:
On 26/11/21 7:32 am, Mandy Chung wrote:
On Thu, 25 Nov 2021 02:22:20 GMT, Jaikiran Pai wrote:
Mandy Chung has updated the pull request incrementally with one additional
commit since the last revision:
minor fix to avoid casting
Hello Mandy, one small issue - `ClassFileReader
Hello Alan,
On 01/11/21 9:22 pm, Alan Bateman wrote:
On Mon, 1 Nov 2021 03:10:45 GMT, Jaikiran Pai wrote:
Can I please get a review for this change which fixes the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8275509?
The `ModuleDescriptor.hashCode()` method uses the hash
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one additi
On 02/11/21 10:29 am, Jaikiran Pai wrote:
Hello Alan,
On 01/11/21 9:22 pm, Alan Bateman wrote:
On Mon, 1 Nov 2021 03:10:45 GMT, Jaikiran Pai wrote:
Can I please get a review for this change which fixes the issue
reported in https://bugs.openjdk.java.net/browse/JDK-8275509
Hello Alan,
On 02/11/21 5:30 pm, Alan Bateman wrote:
On 02/11/2021 06:38, Jaikiran Pai wrote:
:
Perhaps run 1 writing the hash code of each of the boot modules'
descriptor into a file and then run 2 reading that same file to
compare the hash codes would be one way to do it. But I think
On 03/11/21 8:50 am, Jaikiran Pai wrote:
Hello Alan,
On 02/11/21 5:30 pm, Alan Bateman wrote:
On 02/11/2021 06:38, Jaikiran Pai wrote:
:
Perhaps run 1 writing the hash code of each of the boot modules'
descriptor into a file and then run 2 reading that same file to
compare the hash codes
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one a
On Fri, 22 Oct 2021 10:33:42 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2559:
>>
>>> 2557: continue;
>>> 2558: }
>>> 2559: h += e.ordinal();
>>
>&
Hello Ioi (and others),
On 22/10/21 1:39 pm, Jaikiran Pai wrote:
Hello Ioi,
On 22/10/21 12:29 pm, Ioi Lam wrote:
On 10/21/21 9:09 PM, Jaikiran Pai wrote:
Hello Ioi,
This is my initial analysis of the problem.
>>> Can anyone think of similar problems that may happen
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote:
> The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a
> timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The
> timeout seems to have happened even after the tests had already
On Tue, 19 Oct 2021 13:00:01 GMT, Jaikiran Pai wrote:
> The `GlobalFilterTest` has to 2 `@test` tags. One of them has failed with a
> timeout as noted in https://bugs.openjdk.java.net/browse/JDK-8268595. The
> timeout seems to have happened even after the tests had already
On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote:
> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
> libraries are no longer present on the filesystem.
> `NativeLibraries::loadLibrary` checks for the file existence before calling
> `JVM_LoadLibrary`. Such
On Wed, 27 Oct 2021 03:31:00 GMT, Jaikiran Pai wrote:
>> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
>> libraries are no longer present on the filesystem.
>> `NativeLibraries::loadLibrary` checks for the file existence before calling
&
On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote:
> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
> libraries are no longer present on the filesystem.
> `NativeLibraries::loadLibrary` checks for the file existence before calling
> `JVM_LoadLibrary`. Such
On Mon, 8 Nov 2021 15:53:54 GMT, Jaikiran Pai wrote:
>>> printStackTrace interacts with locking of the streams to avoid garbled
>>> output when many threads are printing to standard output output/error at
>>> the same time. If we change dumpStack to use StackWalker t
On Mon, 8 Nov 2021 15:46:22 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 1396:
>>
>>> 1394: // at this point in time. So we fallback to creating a
>>> Exception instance
>>> 1395: // and printi
ould need to run some performance benchmarks to evaluate any
> performance changes. The current `Thread.dumpStack` method clearly states
> that it is meant for debugging purposes so I haven't run any kind of
> performance benchmarks on this change.
Jaikiran Pai has updated the pull reque
On Mon, 8 Nov 2021 10:45:02 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which seeks to implement the
> enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8153133?
>
> The commit in this PR uses the `StackWalker` API to dump the stacktrace of
On Mon, 8 Nov 2021 19:49:06 GMT, Alan Bateman wrote:
> I'm uncomfortable with this change, does the change have any benefit?
To me, the initial appeal of this change was to use a more natural API instead
of creating an `Exception` instance and printing the stacktrace from it.
Performance
On Mon, 8 Nov 2021 19:59:27 GMT, Mandy Chung wrote:
> I think we should close this RFE as will not fix.
Will do.
Thank you Alan and Mandy for your time on reviewing this.
-
PR: https://git.openjdk.java.net/jdk/pull/6292
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files
> (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
> ZipOutputStream's.
> It fixes the following keys issues relating to
On Fri, 22 Oct 2021 09:33:35 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> compon
On Thu, 4 Nov 2021 14:08:50 GMT, Alan Bateman wrote:
> One final thought on this is whether we should remove the
> tools/jlink/JLinkReproducibleXXX tests from the exclude list.
Yes, I'm working on it in a separate PR.
-
PR: https://git.openjdk.java.net/jdk/pull/6078
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
require a bigger change and also a discussion on what kind of
> extending of module-info.class content will require a change to the
> lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request incrementally with two additional
commits since the last revision:
- use testng as
require a bigger change and also a discussion on what kind of
> extending of module-info.class content will require a change to the
> lastmodifiedtime of that entry.
Jaikiran Pai has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev exc
Can I please get a review for this change which removes the
`JLinkReproducibleTest` and `JLinkReproducible3Test` tests from the
`ProblemList.txt`?
With the fix for https://bugs.openjdk.java.net/browse/JDK-8275509 now merged, I
expect these tests to stop failing intermittently. I have run these
On Fri, 5 Nov 2021 09:03:59 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which removes the
> `JLinkReproducibleTest` and `JLinkReproducible3Test` tests from the
> `ProblemList.txt`?
>
> With the fix for https://bugs.openjdk.java.net/browse/JDK-8275509 n
On Fri, 5 Nov 2021 09:03:59 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which removes the
> `JLinkReproducibleTest` and `JLinkReproducible3Test` tests from the
> `ProblemList.txt`?
>
> With the fix for https://bugs.openjdk.java.net/browse/JDK-8275509 n
Hello Alan,
On 04/11/21 1:21 am, Alan Bateman wrote:
On Wed, 3 Nov 2021 03:22:40 GMT, Jaikiran Pai wrote:
So I decided to stick with using the ordinal modifiers in the hashCode()
computation. However, I'm not an expert on the performance aspects of the
Collections and how much using
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one additi
On Thu, 4 Nov 2021 03:18:40 GMT, Jaikiran Pai wrote:
> > So I decided to stick with using the ordinal modifiers in the hashCode()
> > computation. However, I'm not an expert on the performance aspects of the
> > Collections and how much using the modifiers for hashC
Hello Ioi,
On 02/11/21 12:13 am, Ioi Lam wrote:
Hi Jaikiran,
Thanks for writing the test case to explore the problems in this area.
Please see my comments below:
...
Generally speaking, CDS has two levels of archiving:
[1] archiving class metadata -- classes in the
$JAVA_HOME/lib/classlist
Can I please get a review of this change which seeks to implement the
enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8153133?
The commit in this PR uses the `StackWalker` API to dump the stacktrace of the
thread. A few things to note about this change:
- Previously, the dumped
ould need to run some performance benchmarks to evaluate any
> performance changes. The current `Thread.dumpStack` method clearly states
> that it is meant for debugging purposes so I haven't run any kind of
> performance benchmarks on this change.
Jaikiran Pai has updated the pull req
On Mon, 8 Nov 2021 11:12:25 GMT, Alan Bateman wrote:
> printStackTrace interacts with locking of the streams to avoid garbled output
> when many threads are printing to standard output output/error at the same
> time. If we change dumpStack to use StackWalker then it will need to do the
>
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one add
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one addi
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with four additi
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one addit
Hello Alan,
On 01/11/21 1:03 am, Alan Bateman wrote:
On Fri, 29 Oct 2021 04:19:21 GMT, Jaikiran Pai wrote:
Do you mean the jtreg `driver` style this test is using? I used it because it
was necessary to compare output (the hashCode value) between multiple JVM runs.
I use the `driver` along
On 01/11/21 7:26 am, Jaikiran Pai wrote:
Hello Alan,
On 01/11/21 1:03 am, Alan Bateman wrote:
On Fri, 29 Oct 2021 04:19:21 GMT, Jaikiran Pai wrote:
Do you mean the jtreg `driver` style this test is using? I used it
because it was necessary to compare output (the hashCode value)
between
On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to k
ementation, either directly or indirectly end up as calls on
> `java.lang.String.hashCode()` and as such aren't expected to cause
> non-deterministic values.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one add
On Mon, 25 Oct 2021 09:21:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
On Wed, 24 Nov 2021 08:54:08 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which adds `jlink.debug=true` system
> property while launching `jpackage` tests?
>
> The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't
> take into a
On Thu, 2 Dec 2021 19:04:11 GMT, Roger Riggs wrote:
> fyi, with this change the JCK did not flag a failure.
Thank you Roger for running those tests.
-
PR: https://git.openjdk.java.net/jdk/pull/6488
Can I please get a review for this change which fixes a typo in the javadoc of
`java.util.zip.ZipEntry.setTime()` method?
-
Commit messages:
- 8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
Changes: https://git.openjdk.java.net/jdk/pull/6615/files
Webrev:
On Wed, 24 Nov 2021 08:54:08 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which adds `jlink.debug=true` system
> property while launching `jpackage` tests?
>
> The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't
> take into a
On Wed, 1 Dec 2021 12:21:00 GMT, Athijegannathan Sundararajan
wrote:
>> Can I please get a review of this change which adds `jlink.debug=true`
>> system property while launching `jpackage` tests?
>>
>> The previous fix for this in https://github.com/openjdk/jdk/pull/6491 didn't
>> take into
On Mon, 6 Dec 2021 04:25:37 GMT, Jaikiran Pai wrote:
>> The effects of invalid values of `jdk.serialFilter` and
>> `jdk.serialFilterFactory` properties are
>> incompletely specified. The behavior for invalid values of the properties is
>> different and
>> use an
301 - 400 of 584 matches
Mail list logo
