> 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
On 26/09/17 08:25, Peter Lawrey wrote:
> I am looking forward to intrinsic support for 128 bit math using ?Long2?
> and XMM (or even YMM, ZMM) instructions.
> This is the best way forward, I hope.
>
> Personally I would like to see a long long type, or even uint128, uint256,
> uint512 style notati
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 26/09/17 11:20, Peter Lawrey wrote:
> We have arrays already but we don't have primitive types of more than
> 64-bit. If we had uint128 for example we wouldn't need this method.
Perhaps not, but why is needing this method a problem?
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd.
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
On 26/09/17 15:53, Peter Lawrey wrote:
> None, except you end up jumping through hoops to implement 128 bit
> arithmetic efficiently or cleanly. At some point language support for such
> a basic operation is the simplest and clearest solution.
There's nothing inefficient about this approach. I do
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
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 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
>
