[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Patch submission advice: use webrev, jtreg tests where, cmd line test?
From:       Mandy.Chung () Sun ! COM (Mandy Chung)
Date:       2008-02-14 22:51:17
Message-ID: 47B4C5E5.1010309 () Sun ! com
[Download RAW message or body]

Hi Lars,

Thanks for getting a fix for 6523160.  You can use 
serviceability-dev at openjdk.java.net alias for submitting the patch and I 
believe the change in the hotspot code is local to serviceability.

My comment is inlined....

Lars Westergren wrote:
> Hello,
> 
> I have a fix ready for bug 6523160 - "RuntimeMXBean.getUptime() returns
> negative values". Mandy Chung long ago suggested I use this mailing list
> rather than the management mailinglist for this bug since the fix
> involves changes in Hotspot code.
> 
> 
> Before I submit, I wanted to clarify three things -
> 
> 1. Should I include diff files as attachments as is recommended here:
>  http://openjdk.java.net/contribute/
> or do you now prefer that I use Webrev for OpenJDK as Jean-Christophe
> Collet describes, so I include a link to my webrev pages in the mail
> instead?
> http://blogs.sun.com/jcc/

It would be great if you can use webrev. It's a very useful code-review 
generating tool and I'm sure you will like it.

You can either include a link to your webrev (public accessible) or 
include the tarball of the webrev pages which is also fine with me.

> 2. My jtreg tests, would you prefer them included as standalone files
> attachments to the mail so you yourselves can decide where to put them,
> or should I place them in the correct package in jdk/test so they become
> a part of the webrev?

You can just include the jtreg tests in the 
jdk/test/java/lang/management/RuntimeMXBean directory since the test 
will be specific for testing that API.  I'll be able to get a copy of 
the test from the webrev generated.

FYI.  The source and test location for the serviceability project are 
listed at:
   http://openjdk.java.net/groups/serviceability/svcjdk.html

> 3. Provoking the bug involves setting back the OS clock. Is it ok if I
> use the command line "date" command (making the test platform dependent)
> to set back the clock in the test? Or should I prefer user interaction
> as is done in some other tests I've seen - i.e. popping up a window that
> says "Set back the OS clock an hour now, click 'ok' when done to continue"?

The jtreg tests have to be fully automated and can be run on machines 
that may be used by others for various purposes.  In addition, changing 
the clock on a shared machine might cause unexpected problems to other 
applications/testing running on the same machine.

The Java SE Quality team has several functional tests that fail due to 
this bug. I can help run those tests to verify your fix.  We can work 
together.

Mandy
P.S. I'll be on vacation next week and return on 1/25.

> 
> Thanks in advance,
> Lars


[prev in list] [next in list] [prev in thread] [next in thread]