Hi All
I've create a new bug to include the javadoc of the non-Java SE JarSigner API
into security doc:
https://bugs.openjdk.java.net/browse/JDK-8171135
If you think this is OK, I'll move the bug to doc.
Thanks
Max
Hi Amanda
Can you also test the new JarSigner API?
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd
line 2.72 has an example on it.
> On Dec 13, 2016, at 9:22 AM, Artem Smotrakov
> wrote:
>
> You can use
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/securit
Hi Adam
The only behavior change is with the debug output, right?
Is this a new pattern that internal optional fields should be defined as an
Optional?
And, when there is no provider the string form "from: " looks strange, I would
rather make it "from nowhere". I would also move the space befo
You can use
http://hg.openjdk.java.net/jdk9/dev/jdk/file/d4d7f1f0d688/test/lib/security/SecurityTools.java
which would simplify the code. This lib was added to be used in such tests.
Note that SecurityTools addresses a couple of known issues with running
security tools on machines with differe
Hi,
+1 (I am not really an expert on jar signing but the basic test looks fine).
Some minor comments below, no need for another review.
Paul.
113 Stream.of(sourceFiles).map(Object::toString).forEach(x ->
launcher.addToolArg(x));
119 Stream.of(args).forEach(x -> launcher.addTo
Hi All,
Please help to review following changeset, which tests that jarsigner
tool works with multi-release JAR files.
Webrev: http://cr.openjdk.java.net/~amjiang/8075618/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8075618
Thanks,
Amanda
Okay. I changed getProvider() to return this.provider.orElse(null),
which will allow this method to return null. For consistency, I allow
all other providers (in Instance and Service) to be null using
Optional.ofNullable(). Hopefully, I found and fixed all the whitespace
issues, too. Here is th
On 12/8/16 11:17 AM, Adam Petcher wrote:
Subclasses of Signature may have a null provider. In this case, the
debug logging code will throw a NPE when attempting to call getName() on
it. Since this member may be null, I would like to change its type to
Optional to ensure that code checks whether
Looks fine to me.
Thanks,
Xuelei
On 12/12/2016 2:29 AM, John Jiang wrote:
Hi Xuelei,
Thanks for your comments.
Please review this new webrev:
http://cr.openjdk.java.net/~jjiang/8171043/webrev.01/
Best regards,
John Jiang
On 2016/12/12 13:07, Xuelei Fan wrote:
Hi John,
It's a good catch of
> On Dec 12, 2016, at 6:03 PM, Daniel Fuchs wrote:
>
> Hi Max,
>
> Don't count me as reviewer - but I see a mismatched comment
> in the file:
>
> 209 /**
> 210 * Creates FilePermission objects with special internals.
> 211 * See {@link FilePermCompat#newPermPlusAltPath(Permission
Hi Xuelei,
Thanks for your comments.
Please review this new webrev:
http://cr.openjdk.java.net/~jjiang/8171043/webrev.01/
Best regards,
John Jiang
On 2016/12/12 13:07, Xuelei Fan wrote:
Hi John,
It's a good catch of the problem. Looks like the server side should
read the HTTP request at f
Hi Max,
Don't count me as reviewer - but I see a mismatched comment
in the file:
209 /**
210 * Creates FilePermission objects with special internals.
211 * See {@link FilePermCompat#newPermPlusAltPath(Permission)} and
212 * {@link FilePermCompat#newPermUsingAltPath(Permiss
Please take a review at
http://cr.openjdk.java.net/~weijun/8168979/webrev.00/
This further clarifies what an invalid FilePermission behaves. A major behavior
change is that <> now implies an invalid permission, I hope this is
good to minimize incompatibility.
Thanks
Max
13 matches
Mail list logo
