Hi Alan,
On 1/26/19 8:38 PM, Alan Snyder wrote:
My usage of GetStringUTFChars was to pass a String as a parameter to a system
call that takes a NUL-terminated UTF-8 string (a file path). Obviously, the
system call does not accept strings containing NUL. I suspect this is a common
case.
This one keeps bubbling to the very top of my todo stack, only to be
pre-empted a minute later by some other task.
On Tue, Jan 29, 2019 at 2:00 AM Michal Vala wrote:
> Hi Martin,
>
> I'd like to finish this review. Are you still willing to sponsor this?
>
> Thanks!
>
> On 1/9/19 11:39 AM,
Hi Roger,
I really hope you can still sponsor this.
Could you help me, please?
Thanks again.
Best regards,
Jie
On 2019/1/31 上午10:59, David Holmes wrote:
On 31/01/2019 12:44 pm, Jie Fu wrote:
Hi David,
I prefer the original patch[1].
Could you please sponsor this issue or help me find a
Hi, Andrey.
On 27/01/2019 14:35, Andrey Turbanov wrote:
I checked only java.base module and fixed problems there. Does it
makes sense to create patches to other modules too?
You are welcome to make the similar changes in java.desktop module,
please use these email alias
On 31/01/2019 12:44 pm, Jie Fu wrote:
Hi David,
I prefer the original patch[1].
Could you please sponsor this issue or help me find a sponsor.
I really appreciate it. Thank you very much.
Hopefully Roger will still sponsor this.
Thanks,
David
Also thanks Roger. We had a pleasant
Hi David,
I prefer the original patch[1].
Could you please sponsor this issue or help me find a sponsor.
I really appreciate it. Thank you very much.
Also thanks Roger. We had a pleasant discussion offlist.
Best regards,
Jie
[1]
Hi Jie, Roger,
I think this has now consumed far too many cycles for everyone, dealing
with a test that is checking for a leak that can't even exist any more.
Alan was fine with the original proposed patch, as was I, so I think we
can should proceed with that. Obviously there is more than one
Hi,
Please review the javadoc fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8217892
The CSR and the proposed changeset are located at:
https://bugs.openjdk.java.net/browse/JDK-8217939
http://cr.openjdk.java.net/~naoto/8217892/webrev.00/
This is a (effective) forward
Hi,
Please review the javadoc fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8216546
The CSR and the proposed changeset are located at:
https://bugs.openjdk.java.net/browse/JDK-8217938
http://cr.openjdk.java.net/~naoto/8216546/webrev.00/
This is a forward poring of the
On 1/30/2019 5:22 PM, Mandy Chung wrote:
On 1/30/19 5:27 AM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217793 fixes the use of modular jars
[1]
On 1/30/2019 6:46 PM, Mandy Chung wrote:
On 1/30/19 2:05 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217792 : Investigate what modules are included
For modules
On 1/30/19 2:05 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217792 : Investigate what modules are included
For modules included in the runtime of a non-modular
yes - I will put the else back - no impact on functionality (both can't
be true), but it reads better with the else, conforms to the coding
style, and could be minutely faster.
/Andy
On 1/30/2019 5:40 PM, Alexander Matveev wrote:
Hi Andy,
Looks good.
-- Kevin
On 1/30/2019 2:05 PM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217792 : Investigate what modules are included
For modules included in the
Hi Andy,
http://cr.openjdk.java.net/~herrick/8217792/webrev.03/src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkBundlerHelper.java.frames.html
Line 272: Did you mean "if" here? I think it should be changed back to
"else if".
Otherwise looks fine.
Thanks,
Alexander
On 1/30/2019 2:05
Looks good to me, too.
-- Kevin
On 1/30/2019 2:16 PM, Alexander Matveev wrote:
Hi Andy,
Looks fine.
Thanks,
Alexander
On 1/30/2019 5:27 AM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
On 1/30/19 5:27 AM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217793 fixes the use of modular jars
[1] https://bugs.openjdk.java.net/browse/JDK-8217793
[2]
On 1/24/19 8:14 AM, Daniel Fuchs wrote:
Hi,
Please find below another test fix for:
8195716: BootstrapLoggerTest : Executor still alive
https://bugs.openjdk.java.net/browse/JDK-8195716
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.00/
Looks okay. This gets quite
Hi Andy,
Looks fine.
Thanks,
Alexander
On 1/30/2019 5:27 AM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217793 fixes the use of modular jars
[1]
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217792 : Investigate what modules are included
For modules included in the runtime of a non-modular application, we now
computes all modules
Recommendations:
- open source the moribund jni spec, perhaps as part of openjdk, so that
people can improve it
- Add Scare doc to anything that deals with Modified UTF-8
- Add a Charset so that Java code can explicitly encode to Modified UTF-8,
despite being a bug magnet.
- AFAIK the "jnu"
Hi Adam,
On 1/30/19 7:52 AM, Adam Farley8 wrote:
Hi Mandy,
CSR has been raised: https://bugs.openjdk.java.net/browse/JDK-8218061
Thanks for doing it. A couple comments:
I think the compatibility risk should be low rather than minimal.
Even the code shouldn't be doing that, unreflectSetter
Arguably, it could have been exposed as a default method on Collector
(Collector::andThen) -- but we avoided this approach out of concern that
a generic methods in receiver position can interact with type inference
in ways that confuse people.
On 1/30/2019 3:22 AM, Peter Levart wrote:
On
Hi Mandy,
CSR has been raised: https://bugs.openjdk.java.net/browse/JDK-8218061
The webrev I used includes John's comments, your additions, the
one-line-IF,
and I also took the liberty of moving the unreflectField method underneath
the unreflectSetter method, because it seemed strange that
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
JDK-8217793 fixes the use of modular jars
[1] https://bugs.openjdk.java.net/browse/JDK-8217793
[2]
On 1/29/19 9:52 PM, Brian Goetz wrote:
How is this different from Collectors.collectingAndThen?
Hi Brian,
It is exactly the same!
I'm sorry, I haven discovered that method when I needed it. Perhaps I
was looking for another name?
Regards, Peter
On 1/29/2019 3:30 PM, Peter Levart
26 matches
Mail list logo
