Hi Philipp
The change is now at http://hg.openjdk.java.net/jdk10/master/rev/f60a42d4b8cd.
I only moved the test to its new directory. Everything else unchanged.
Thanks again for your contribution, looking forward for more!
--Max
> On Sep 27, 2017, at 1:49 PM, Philipp Kunz wrote:
>
> Hi Max
>
Hi Max
Thank you for your update and its associated effort.
I suggest that at least a comment should be added about why and how
non-existing files can be added and the test still serves it's purpose.
In fact I was quite a bit surprised when I found out that
JarUtils.createJar adds the file na
Hi Philipp
The problem is that when launching by jtreg javac has difficulties writing the
class file with the é char into the file system on several OSes.
I've updated the test a little. Now they are not written to files. Fortunately
JarUtils can add non-existing entries. The test now passes on
It might be a jtreg issue, but I'll have to get it resolved before pushing your
changeset.
--Max
> On Sep 26, 2017, at 7:30 PM, Weijun Wang wrote:
>
> Oops, the new test fails on Linux and Solaris.
>
> /scratch/test/jdk/sun/security/tools/jarsigner/LineBrokenMultiByteCharacter.java:54:
> err
Oops, the new test fails on Linux and Solaris.
/scratch/test/jdk/sun/security/tools/jarsigner/LineBrokenMultiByteCharacter.java:54:
error: error while writing A1234567890B1234567890C123456789D1?xyz: bad
filename
RelativeFile[LineBrokenMultiByteCharacter$A1234567890B1234567890C123456789D1?xyz.cl
> On Sep 26, 2017, at 1:37 PM, Philipp Kunz wrote:
>
> Hi Max
>
> This time I got it with readAllBytes. Thank you for the hint.
>
> Apparently, UTF characters are allowed in source code, particularly in
> identifiers here, which also has caused the bug. Even if only for sending
> patches aro
Hi Max
This time I got it with readAllBytes. Thank you for the hint.
Apparently, UTF characters are allowed in source code, particularly in
identifiers here, which also has caused the bug. Even if only for
sending patches around I changed it and was surprised to see escaping
working not only
> On Sep 26, 2017, at 1:11 AM, Philipp Kunz wrote:
>
> Hi Max
>
> Thank you for the detailed assistance and I really hope it doesn't annoy you
> too much with so many beginner's mistakes. Every little point of yours seems
> to be absolutely justified in my point of view.
I'm flattered.
>
>
Some more suggestions on the test:
1. You can use readAllBytes() to ... err ... read all bytes.
2. I normally don’t remove intermediate files. Jtreg will do an automatic
cleanup, and it can be configured to retain those files when the test fails.
They will be very helpful in debugging.
Thank
Great.
Some suggestions, just my own habit, you are free to decide yourself:
1. In ManifestDigester.java, I'd rather define nameBuf inside the if
(isNameAttr(bytes, start)) block.
2. I normally don't use "import static" unless I can save a lot of keystrokes
and still do not confuse anyone. Bot
Hi Max and Vincent
Thank you for your suggestions. It sure looks better now. I hope this
time I got the patch added in the right format.
diff -r ddc25f646c2e
src/java.base/share/classes/sun/security/util/ManifestDigester.java
---
a/src/java.base/share/classes/sun/security/util/ManifestDigest
Hi Philipp
The change mostly looks fine. You might want to put everything into a patch
file so Vincent can recreate a webrev and post it to cr.openjdk.java.net.
One thing I would suggest for the test is that instead of using jarsigner
-verify and check the text in output you can open it as a Ja
12 matches
Mail list logo
