Or you can smuggle it out through JavaUtilJarAccess with SharedSecrets.
> On Aug 31, 2018, at 10:32 AM, Weijun Wang wrote:
>
> if we want to show the .SF name also, we will need a public API because
> SignatureFileVerifier.java is inside sun.security.util. Something like
>
Some more comments:
Attributes.java
- No need to "import java.security.Security".
- In the updated read() method, I think there is no need to use an "int offset"
parameter. "int lineNumber" is enough and you can modify it and return it
without a new local variable.
- I feel like calling
Okay.
Thanks,
Xuelei
On 8/30/2018 6:46 PM, sha.ji...@oracle.com wrote:
On 2018/8/31 09:22, Xuelei Fan wrote:
On 8/30/2018 6:16 PM, sha.ji...@oracle.com wrote:
Hi Xuelei,
It still be possible that two test runs fail.
Yes. I was wondering the possibility of the failure may go down.
I
On 2018/8/31 09:22, Xuelei Fan wrote:
On 8/30/2018 6:16 PM, sha.ji...@oracle.com wrote:
Hi Xuelei,
It still be possible that two test runs fail.
Yes. I was wondering the possibility of the failure may go down.
I searched this test in JBS, and didn't find many failures on this test.
So, it
Sorry - I meant for the subject of my prior email to be "How does one
securely obtain and verify openjdk repositories as a non-contributor?"
Hi,
I am asking this because I am not able to find information on if
openjdk uses signed tags/commits & because those of us without commit
access cannot use ssh to clone the openjdk mercurial repositories
hosted on http://hg.openjdk.java.net/ . Also, hg.openjdk.java.net is
not available over
On 8/30/2018 6:16 PM, sha.ji...@oracle.com wrote:
Hi Xuelei,
It still be possible that two test runs fail.
Yes. I was wondering the possibility of the failure may go down.
Thanks,
Xuelei
Best regards,
John Jiang
On 2018/8/30 22:02, Xuelei Fan wrote:
Maybe, run the test twice and pass if
Hi Xuelei,
It still be possible that two test runs fail.
Best regards,
John Jiang
On 2018/8/30 22:02, Xuelei Fan wrote:
Maybe, run the test twice and pass if one passed?
Xuelei
On 8/29/2018 7:34 PM, sha.ji...@oracle.com wrote:
Hi,
In test sun/security/ssl/SSLSocketImpl/ReuseAddr.java,
the
Webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8171279
Please review the following change to add support for X25519 and X448
(XDH) to TLS 1.3. This change includes some refactoring to remove code
that was duplicated for DH and
Hi Max, probably we should add the info about the MANIFEST.MF , for
example :
change getErrorPosition to
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/share/classes/java/util/jar/Attributes.java.udiff.html
static String getErrorPosition(String filename,
> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias
> wrote:
>
>> - What will the output look like? Is it "/tmp/x.jar:100"?
>>
>
> Yes it look like this :
>
> line too long (/testdata/jars/file_with_long_line_1.jar:2)
Is this a little misleading? I think you mean
Hi Max,
I changed the following in the new webrev :
- added the copyright+license header to the new file
- called trim on each token
- adjusted the comment java.security like you suggested
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/
>
> - What will the output look like? Is it
12 matches
Mail list logo
