Hi David,
thank you for such a prompt review!
-- Igor
> On Apr 11, 2017, at 7:47 PM, David Holmes wrote:
>
> Hi Igor,
>
> On 12/04/2017 12:29 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
>>> 59 lines changed: 0 ins; 59 del; 0 mod;
>>
>> Hi all,
>>
>> c
Hi Igor,
On 12/04/2017 12:29 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
59 lines changed: 0 ins; 59 del; 0 mod;
Hi all,
could you please review this small clean up of testlibaries?
the only platform specific vm arguments which we had were -d64/32. they
http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
> 59 lines changed: 0 ins; 59 del; 0 mod;
Hi all,
could you please review this small clean up of testlibaries?
the only platform specific vm arguments which we had were -d64/32. they were
deprecated in jdk9 by 8168010 and will be removed i
Updated patch with the changed parameter validation, updated javadoc and added
test coverage.
# HG changeset patch
# User chris_dennis
# Date 1491945909 14400
# Tue Apr 11 17:25:09 2017 -0400
# Node ID c87cb7f14db71cff2bb4f0a7490b77cfe7ac07b6
# Parent fbedc2de689fd9fe693115630225e2008827c4e
Color me confused… what would the javadoc on the parameter say? It could I
guess have an @implNote documenting the meanings of the parameters… but then
what use is it? The proposed API simply limits the precision with which a
DoubleSummaryStatistic can be copied to be the same as the precision w
On 2017-04-11 22:15, Paul Sandoz wrote
Would you mind making the comment a little more descriptive? e.g.
// Obtain the invoker MethodType outside of the following try block.
// This ensures that an IllegalArgumentException is directly thrown if the
// type would have 256 or more parameters
Sur
Hi David,
thanks for review.
-- Igor
> On Apr 11, 2017, at 12:04 AM, David Holmes wrote:
>
> Hi Igor,
>
> This looks fine to me.
>
> I was a little concerned any tests with a try/catch around these calls would
> fail to compile due to exception checking, but class Exception is exempt from
On an API design note, I would prefer to DoubleSummaryStatistics took a
double... argument to pass in the state of the summation. This
flexibility is necessary to more fully preserve the computed sum. Also,
the we want flexibility to change the amount of internal state
DoubleSummaryStats keeps
Tricky!
Would you mind making the comment a little more descriptive? e.g.
// Obtain the invoker MethodType outside of the following try block.
// This ensures that an IllegalArgumentException is directly thrown if the
// type would have 256 or more parameters
(IAE can be confused with Access or
On 11/04/2017 19:09, Roger Riggs wrote:
Hi Alan, Brian,
Updated in place with copyrights and corrections to @linkplain in
java.lang.Process.
Thanks, Roger
http://cr.openjdk.java.net/~rriggs/webrev-pid-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-jaxp-8178347
http://cr.openjdk.java.
Hi Chris,
Thanks for looking at this.
There is some rudimentary testing using streams in
CollectAndSummaryStatisticsTest.java.
I think we should enforce constraints where we reliably can:
1) count >= 0
2) count = 0, then min/max/sum are ignored and it’s as if the default
constructor was call
Hi,
JDK-8178387 subtly and inadvertently changed what exception was being
thrown by LambdaForm.compileToBytecode in
certain cases - this patch reverts this simplification and adds a
comment to warn against future attempts to
simplify too much..
Bug: https://bugs.openjdk.java.net/browse/JDK-81
Yes, I've seen some of these dirty hacks in the ASM code, as they show
up here and there in
my startup graphs when I add some lambdas to the mix[1]... ;-)
I hadn't considered the 64K bytecode per method limitation, which means
you couldn't even
generate a fraction of that number of elements in
Hi Roger,
OK by me.
Brian
On Apr 11, 2017, at 11:09 AM, Roger Riggs wrote:
> Updated in place with copyrights and corrections to @linkplain in
> java.lang.Process.
Yes, please hide -Xmodule,
currently people get confused by -Xmodule vs --patch-module, i had several
questions related to that at DevoxxFR.
Rémi
- Mail original -
> De: "Jan Lahoda"
> À: "compiler-dev" , "Java Core Libs"
> ,
> hotspot-...@openjdk.java.net
> Envoyé: Mardi 11 Avril 2017
Hi Claes,
yes !
We use something equivalent to "FOO".toCharArray() at several place in ASM
because there is no constant pool constant arrays [1].
Terence Parr also mentions that issue at the JVM Summit 2009 [2].
Rémi
[1]
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/645c0d3e3977/src/java.base/
Hi Alan, Brian,
Updated in place with copyrights and corrections to @linkplain in
java.lang.Process.
Thanks, Roger
http://cr.openjdk.java.net/~rriggs/webrev-pid-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-jaxp-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-jdk-8178347
http://
Hi,
javac used to have an option, -Xmodule:, that allowed to compile given
sources as if they were part of the specified module.
This functionality has been merged into the --patch-module option, but
the -Xmodule: option couldn't be fully removed at that time, as some
tests and tools (e.g. j
On 11/04/2017 16:55, Roger Riggs wrote:
Please review this change to the name of the ProcessHandle.getPid and
Process.getPid methods
as observed and recommended in email: [1]
I looked through the jdk repo and the changes look fine. In passing then
I assume the links in Process of the form {@
Hi Roger,
Looks fine to me, modulo the usual copyright date.
Thanks,
Brian
On Apr 11, 2017, at 8:55 AM, Roger Riggs wrote:
> Please review this change to the name of the ProcessHandle.getPid and
> Process.getPid methods
> as observed and recommended in email: [1]
>
> The methods are new in
Please review this change to the name of the ProcessHandle.getPid and
Process.getPid methods
as observed and recommended in email: [1]
The methods are new in JDK 9 and the renaming corrects the method name
style to be
consistent within each class.
The change sets propagate the name change to
Thanks! Pushed.
/Claes
On 04/11/2017 11:16 AM, Vladimir Ivanov wrote:
Reviewed.
Best regards,
Vladimir Ivanov
Reviewed.
Best regards,
Vladimir Ivanov
On 4/11/17 12:06 PM, Claes Redestad wrote:
On 04/10/2017 05:20 PM, Claes Redestad wrote:
On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
Looks good.
Thanks for reviewing!
One small suggestion [1]
Sure, updated in-place.
Taking a second look a
On 04/10/2017 05:20 PM, Claes Redestad wrote:
On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
Looks good.
Thanks for reviewing!
One small suggestion [1]
Sure, updated in-place.
Taking a second look at these constants, it turned out that a few of
them were unused, but since they
weren
Sounds like you want https://bugs.openjdk.java.net/browse/JDK-8061402 -
which was originally filed back in 2002 but was closed since it got
filed on the wrong component or something... ¯\_(ツ)_/¯
There's still a number of char[] foo = "FOO".toCharArray() in the JDK
since this allows for a more
Hi Igor,
This looks fine to me.
I was a little concerned any tests with a try/catch around these calls
would fail to compile due to exception checking, but class Exception is
exempt from that checking.
Thanks,
David
On 11/04/2017 8:42 AM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~ii
26 matches
Mail list logo
