Thanks for letting me know. I'll just close bug.
Leonid
> On Jan 12, 2020, at 11:39 PM, Nick Gasson wrote:
>
> Hi Leonid,
>
> On 11/01/2020 02:06, Leonid Mesnik wrote:
>> --- a/test/jdk/java/foreign/TestArrays.java Wed Jan 01 03:08:45 2020
>> +0100
>> +++ b/test/jdk/java/foreign/TestArray
Hi Leonid,
On 11/01/2020 02:06, Leonid Mesnik wrote:
--- a/test/jdk/java/foreign/TestArrays.java Wed Jan 01 03:08:45 2020 +0100
+++ b/test/jdk/java/foreign/TestArrays.java Fri Jan 10 09:51:51 2020 -0800
@@ -76,8 +76,8 @@
static VarHandle shortHandle = shorts.varHandle(short.class,
Hi Aleksey,
On 13/01/2020 03:33, Aleksey Shipilev wrote:
Looks fine.
The long/doubleHandle changes probably clash with JDK-8236939.
The test changes probably benefit from cleaner accessors like in JDK-8236920.
But whatever, having any fix in jdk14 that unbreaks 32-bit platforms before
RDP2 h
Hi,
I'm wondering whether we shouldn't just do "inodes = null;"? I guess this is
cheaper and accesses to the inodes map on a closed filesystem object should not
happen anyway (e.g. all is guarded by ensureOpen()). Other than that, the
change looks fine.
Cheers
Christoph
> -Original Messag
Jim, this was the information that somehow I was not able to wrap my mind
around:
"So it all comes down to the last line being blank or not blank. A blank
line becomes an empty line due to stripping of trailing blanks."
Any character inserted on the last line (ending with """) will actually
autom
Hi Naoto,
Thanks. I'll make those changes and push.
-Sundar
On 10/01/20 7:20 pm, naoto.s...@oracle.com wrote:
Hi Sundar,
You might want to add the bug id in the regression test, and change
the copyright year to 2020.
Otherwise, looks good.
Naoto
On 1/10/20 5:07 AM, sundararajan.athijegan
Chris,
String::stripIndent might not be the routine you are looking for. It is
provided to duplicate the actions performed by the compiler when processing a
Text Block. To use String::stripIndent as a method to strip indentation in the
way you might expect you might have to massage the input st
On Jan 11, 2020, at 3:59 AM, fo...@univ-mlv.fr wrote:
> In my opinion, it's better to introduce an annotation @TrueScottmanFinal
> instead of using @Stable in a way it was not designed to be used.
And even better than that is fixing “final” so it’s really final.
But @TrueScottmanFinal is surpris
On 1/9/20 1:01 PM, Maurizio Cimadamore wrote:
> On 09/01/2020 08:10, Nick Gasson wrote:
>> http://cr.openjdk.java.net/~ngasson/8236634/webrev.1/index.html
Looks fine.
The long/doubleHandle changes probably clash with JDK-8236939.
The test changes probably benefit from cleaner accessors like in JD
Bug:
https://bugs.openjdk.java.net/browse/JDK-8236920
Fix:
https://cr.openjdk.java.net/~shade/8236920/webrev.01/
This breaks x86_32 test builds. I would like to have this fix in 14.
Testing: Linux {x86_64, x86_32} builds; java/foreign (still passes on x86_64;
still fails on x86_32,
seems un
On 1/10/20 10:24 AM, Alan Bateman wrote:
> On 10/01/2020 09:11, Aleksey Shipilev wrote:
>> :
>> No other takers? I would then push this trivial patch for Alex under my
>> single review.
>>
> I think it's okay but would be nice if one of the jpackager maintainers
> jumped in.
Thanks!
It had been
11 matches
Mail list logo
