On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28
On Fri, 2 Apr 2021 18:00:57 GMT, Daniel Fuchs wrote:
>> This RFE proposes to extend the MXBean framework to define a mapping to
>> records.
>>
>> The MXBean framework already defines a mapping of `CompositeType` to plain
>> java objects. Records are a natural representation of CompositeTypes.
On Thu, 25 Mar 2021 17:30:52 GMT, Daniel Fuchs wrote:
> This RFE proposes to extend the MXBean framework to define a mapping to
> records.
>
> The MXBean framework already defines a mapping of `CompositeType` to plain
> java objects. Records are a natural representation of CompositeTypes. A
>
On 22 Dec 2015, at 17:25, olivier.lagn...@oracle.com wrote:
> Hi Jaroslav,
>
> Looks good. Not a reviewer however.
+1
-Chris.
> Olivier.
>
> On 22/12/2015 17:50, Jaroslav Bachorik wrote:
>> Please, review this trivial test change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-814598
Looks fine to me.
-Chris.
On 9 Jan 2014, at 14:05, Jaroslav Bachorik wrote:
> Please, review this small test change.
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8031420
> Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00
>
> The test needs to check for the supported pla
On 10/03/2013 04:37 PM, Jaroslav Bachorik wrote:
On 3.10.2013 17:29, Chris Hegarty wrote:
On 10/03/2013 04:02 PM, Jaroslav Bachorik wrote:
...
But it might hardly matter - it seems that the main culprit for this
test to fail on this particular configuration was the fact that
127.0.0.1
On 10/03/2013 04:02 PM, Jaroslav Bachorik wrote:
...
But it might hardly matter - it seems that the main culprit for this
test to fail on this particular configuration was the fact that
127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and
I have not looked at the specif
On 09/12/2013 04:45 AM, David Holmes wrote:
Hi Jaroslav,
You need a copyright notice in the new file.
As written this test can only run on a full JDK - so please add it to
the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
from the test-jdk? And use the VMOPTS passed to the te
On 09/03/2013 09:02 AM, Jaroslav Bachorik wrote:
Please, review the following patch:
http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
It addresses the problem of the test not properly cleaning up the
created threads at exit. It does
On 24/07/2013 12:21, David Holmes wrote:
On 24/07/2013 7:31 PM, Mandy Chung wrote:
On 7/24/2013 4:50 PM, shanliang wrote:
So we have 2 kinds of issues here:
1) the test related, like Thread state checking, we can fix them in
the test
2) MBean.getThreadCount() issue, we can create a bug to trac
On 24/07/2013 15:08, Jaroslav Bachorik wrote:
On 07/24/2013 03:17 PM, Chris Hegarty wrote:
On 24/07/2013 13:49, Jaroslav Bachorik wrote:
On 07/24/2013 02:32 PM, Chris Hegarty wrote:
On 24/07/2013 12:21, David Holmes wrote:
On 24/07/2013 7:31 PM, Mandy Chung wrote:
On 7/24/2013 4:50 PM
On 24/07/2013 13:49, Jaroslav Bachorik wrote:
On 07/24/2013 02:32 PM, Chris Hegarty wrote:
On 24/07/2013 12:21, David Holmes wrote:
On 24/07/2013 7:31 PM, Mandy Chung wrote:
On 7/24/2013 4:50 PM, shanliang wrote:
So we have 2 kinds of issues here:
1) the test related, like Thread state
On 07/25/2013 01:28 PM, Jaroslav Bachorik wrote:
..
I have filed a separate issue for hotspot/svc (JDK-8021335)
Yes, this is probably a separate, and more involved, issue.
For the time being I propose modifying the test to be less race-prone in
java and adding a timeout of 500ms after t
13 matches
Mail list logo
