Hi Alan,
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Wednesday, March 11, 2020 3:03 PM
> To: Yangfei (Felix) ; core-libs-dev@openjdk.java.net
> Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible
> between builds
>
> On 11/03/2020 0
On 12/03/2020 07:32, Yangfei (Felix) wrote:
:
I looked into the JLinkReproducibleTest.
There are only two modules contained in lib/modules of the image: main and
java.base.
I changed the test specifying --keep-packaged-modules:
diff -r 8c5697ed51b2 test/jdk/tools/jlink/JLinkReproducibleTest.java
On 11/03/2020 21:43, Mandy Chung wrote:
:
I discussed further with Alan. Other class and names are no better
than BootLoader::loadLibrary. We agree to keep that helper method as
BootLoader::loadLibrary. The changes due to the renaming is reverted.
Updated patch:
http://cr.openjdk.java.n
Hi,
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Thursday, March 12, 2020 4:47 PM
> To: Yangfei (Felix) ; core-libs-dev@openjdk.java.net
> Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible
> between builds
>
> The `jmod` and `jar`
On 12/03/2020 09:30, Yangfei (Felix) wrote:
:
According to [1], if A requires B and C, then I suppose the hashes will be
included in B and C instead of A when we do 'jmod hash --module-path jmods
--hash-modules .*'.
So for the hashed to be stored in A, we may need relations like: B requires A,
Hi Roger,
Looks good to me. If it were my own test I would add a little
Thread.sleep() after System.gc() to actually give time to the
gc to do something.
I have to note however that:
83 final long ERROR_PERCENT = 10;
84 final long ERROR_THRESHOLD = // 10% increase over min to
Hi,
> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Thursday, March 12, 2020 5:40 PM
> To: Yangfei (Felix) ; core-libs-dev@openjdk.java.net
> Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible
> between builds
>
> On 12/03/2020 09:30,
The change for 8232622: Technical debt in BadAttributeValueExpException
failed to document the behavior of the readObject method to ensure
compatibility.
Please review the javadoc for the readObject method.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-readobject-doc-8240957/
Thanks, Ro
Hi Roger,
Looks fine.
Brian
> On Mar 12, 2020, at 7:36 AM, Roger Riggs wrote:
>
> The change for 8232622: Technical debt in BadAttributeValueExpException
> failed to document the behavior of the readObject method to ensure
> compatibility.
> Please review the javadoc for the readObject method
Ping. Any takers?
Naoto
On 3/5/20 8:58 AM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8216332
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8216332/webrev.00/
Before this fix, the rul
Hi Daniel,
Good point about the sleep and the percent computation.
Fixed both, its a bad idea to leave buggy code around to mislead or be
copied.
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704-1/
Thanks, Roger
On 3/12/20 7:13 AM, Daniel Fuchs wrote:
Hi Roge
Hi Naoto,
The fix looks fine and the set of test cases looks good too.
Roger
On 3/5/20 11:58 AM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8216332
The proposed changeset is located at:
https://cr.openjdk.java.
Looks good Roger!
best regards,
-- daniel
On 12/03/2020 15:11, Roger Riggs wrote:
Hi Daniel,
Good point about the sleep and the percent computation.
Fixed both, its a bad idea to leave buggy code around to mislead or be
copied.
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-hand
This change looks okay.
Mandy
On 3/12/20 1:50 PM, Jonathan Gibbons wrote:
Please review a simple fix regarding the non-standard use of some CSS
in some doc comments.
From the JBS Description:
Recently, for the display of javadoc block tags, javadoc changed from
using an inconsistent set of
Please review a simple fix regarding the non-standard use of some CSS in
some doc comments.
From the JBS Description:
Recently, for the display of javadoc block tags, javadoc changed from
using an inconsistent set of CSS class names on the generated 'dt'
elements to using a single new name ("
+1
--alex
On 03/12/2020 13:53, Mandy Chung wrote:
This change looks okay.
Mandy
On 3/12/20 1:50 PM, Jonathan Gibbons wrote:
Please review a simple fix regarding the non-standard use of some CSS
in some doc comments.
From the JBS Description:
Recently, for the display of javadoc block tags
16 matches
Mail list logo
