This is a drive-by fix to the JDWP agent to fix 50+ warnings that have
been annoying me, see:
https://bugs.openjdk.java.net/browse/JDK-8033758
The bulk of the warnings stem from using a switch statement to switch on
JVMTI and JDWP internal "agent" errors. The agent errors are arranged
(i
Hi Alan,
On 6/02/2014 8:04 PM, Alan Bateman wrote:
This is a drive-by fix to the JDWP agent to fix 50+ warnings that have
been annoying me, see:
https://bugs.openjdk.java.net/browse/JDK-8033758
The bulk of the warnings stem from using a switch statement to switch on
JVMTI and JDWP interna
Looks good!
Thanks,
/Staffan
On 6 feb 2014, at 11:04, Alan Bateman wrote:
>
> This is a drive-by fix to the JDWP agent to fix 50+ warnings that have been
> annoying me, see:
>https://bugs.openjdk.java.net/browse/JDK-8033758
>
> The bulk of the warnings stem from using a switch statement
Looks good.
Thanks, Alan!
Serguei
On 2/6/14 2:04 AM, Alan Bateman wrote:
This is a drive-by fix to the JDWP agent to fix 50+ warnings that have
been annoying me, see:
https://bugs.openjdk.java.net/browse/JDK-8033758
The bulk of the warnings stem from using a switch statement to switch
On 06/02/2014 10:22, David Holmes wrote:
Ok - not the nicest but this isn't worth any additional effort.
Right, it's not worth it.
Thanks for the quick review (Staffan too). I've just run the JDI tests
on all platforms (as that exercises JDWP) and the tests are passing so I
think we are good
On 2/5/14 9:28 PM, David Holmes wrote:
Hi Dan,
Looks good to me.
Thanks for the review!
(I never run the install targets :( )
Neither do I and apparently neither does JPRT... That's how this
slipped through the cracks...
Dan
Thanks,
David
On 6/02/2014 9:20 AM, Daniel D. Daugherty wr
Looks good to me. Nice to see you back in Serviceability code...:-)
Dan
On 2/6/14 3:04 AM, Alan Bateman wrote:
This is a drive-by fix to the JDWP agent to fix 50+ warnings that have
been annoying me, see:
https://bugs.openjdk.java.net/browse/JDK-8033758
The bulk of the warnings stem fr
Looks good to me too. Thanks for fixing this.
tom
On Feb 6, 2014, at 6:07 AM, Daniel D. Daugherty
wrote:
> On 2/5/14 9:28 PM, David Holmes wrote:
>> Hi Dan,
>>
>> Looks good to me.
>
> Thanks for the review!
>
>
>> (I never run the install targets :( )
>
> Neither do I and apparently nei
On 2/6/14 9:29 AM, Doug Simon wrote:
Not sure if I’m being asked for a review, but if so, looks good.
Yes, I was looking for a review. In particular because I tweaked your
original fix...
Thanks for the review!
Dan
On Feb 6, 2014, at 5:07 PM, Tom Rodriguez wrote:
Looks good to me too.
Not sure if I’m being asked for a review, but if so, looks good.
On Feb 6, 2014, at 5:07 PM, Tom Rodriguez wrote:
> Looks good to me too. Thanks for fixing this.
>
> tom
>
> On Feb 6, 2014, at 6:07 AM, Daniel D. Daugherty
> wrote:
>
>> On 2/5/14 9:28 PM, David Holmes wrote:
>>> Hi Dan,
>>>
On 02/ 6/14 08:32 AM, Daniel D. Daugherty wrote:
Looks good to me, Dan
Tim
On 6/02/2014 9:20 AM, Daniel D. Daugherty wrote:
This code review request is going to three different aliases.
Don't use Thunderbird's "reply to list" option since it will
pick just _one_ of the _three_ lists.
Greeti
Thanks for the review!
Dan
On 2/6/14 9:53 AM, Tim Bell wrote:
On 02/ 6/14 08:32 AM, Daniel D. Daugherty wrote:
Looks good to me, Dan
Tim
On 6/02/2014 9:20 AM, Daniel D. Daugherty wrote:
This code review request is going to three different aliases.
Don't use Thunderbird's "reply to list" o
Changeset: 7534523b4174
Author:henryjen
Date: 2014-02-06 10:30 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7534523b4174
8033590: java.util.Comparator::thenComparing has unnecessary type restriction
Reviewed-by: psandoz
! src/share/classes/java/util/Comparator.java
! test/
Runtime team,
This fix was reviewed by Vladimir K. and me.
Just wanted to make sure if you would like to review it as well.
If not, then I will push it.
Thanks,
Serguei
On 2/3/14 2:17 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8
Hi, I clicked on this a couple times. It seems okay but isn't there a
safer way to identify code blobs that are vtable stubs, without looking
at the name (which can change in while creating it). A comment at least
when you create "vtable chunks" would be good. It seems that someone
might
My understanding was that a buffer blob was just that - a buffer. Could
potentially contain code fragments of different kinds.
Thus, is_buffer_blob() was the closest type available. Agree that a dependency
on its name is not reliable, though testing
will reveal if the condition turns false for "
Okay, thanks for adding a comment.
Coleen
On 2/6/14 6:52 PM, Oleg Mazurov wrote:
My understanding was that a buffer blob was just that - a buffer.
Could potentially contain code fragments of different kinds.
Thus, is_buffer_blob() was the closest type available. Agree that a
dependency on its
17 matches
Mail list logo
