On 24/11/2011 4:21 AM, Darryl Mocek wrote:
I've gone back to the try-with-resources implementation in the test
(which will close resources), but specifically closing the
ObjectOutputStream to ensure flushing of the data. I've also kept the
three equals tests and fixed the wording in the Exception
On 24/11/2011 10:15 AM, Stuart Marks wrote:
I don't want to nickel-and-dime you here but there are a few small
things I wanted to mention.
- The test is really about String.CaseInsensitiveComparator.readResolve,
not String.readResolve. The comments at the top of the test should be
updated.
- Ex
On 24/11/2011 6:04 AM, Brandon Passanisi wrote:
I'm currently looking at a bug report:
http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an
issue where a simple program was run with the option -esa to enable
system assertions. The bug author describes that, in the provided sample
Hi Joe,
On 24/11/2011 2:33 AM, Joe Darcy wrote:
On 11/22/2011 9:57 PM, David Holmes wrote:
On 22/11/2011 9:51 PM, Neil Richards wrote:
I've also converted the testcase's use of ZipFile, ZipOutputStream&
FileOutputStream to use ARM (for greater clarity).
I think proper use of ARM requires tha
FYI this bug is visible in the open at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5066854
s'marks
On 11/23/11 12:04 PM, Brandon Passanisi wrote:
I'm currently looking at a bug report:
http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an issue
where a simple program was
Hi Darryl,
I don't want to nickel-and-dime you here but there are a few small things I
wanted to mention.
- The test is really about String.CaseInsensitiveComparator.readResolve, not
String.readResolve. The comments at the top of the test should be updated.
- Extra semicolon at line 50.
On 23/11/2011 20:04, Brandon Passanisi wrote:
I'm currently looking at a bug report:
http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an
issue where a simple program was run with the option -esa to enable
system assertions. The bug author describes that, in the provided
sampl
Looking into the issue more, I had incorrectly assumed that the
assertion was a pre-condition of the MissingFormatArgumentException
because of the differing behavior when -esa is used. After stepping
through the code, it is actually unrelated and... is still a bug.
On 11/23/2011 1:22 PM, Eamo
Isn't an AssertionError *always* a bug?
Éamonn
On 23 November 2011 12:04, Brandon Passanisi
wrote:
>
> I'm currently looking at a bug report:
> http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an issue
> where a simple program was run with the option -esa to enable system
>
I'm currently looking at a bug report:
http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an
issue where a simple program was run with the option -esa to enable
system assertions. The bug author describes that, in the provided
sample code, an AssertionError occurs when the spec
Thanks Alan.
The webrev has been updated accordingly.
http://cr.openjdk.java.net/~sherman/7109837/webrev/
-Sherman
On 11/23/2011 02:58 AM, Alan Bateman wrote:
On 22/11/2011 23:26, Xueming Shen wrote:
Hi,
java.util.zip.Adler32/CRC32 do not have update method that accepts
ByteBuffer.
As of J
I've gone back to the try-with-resources implementation in the test
(which will close resources), but specifically closing the
ObjectOutputStream to ensure flushing of the data. I've also kept the
three equals tests and fixed the wording in the Exceptions.
Please review: http://cr.openjdk.jav
Hello,
On 11/22/2011 9:57 PM, David Holmes wrote:
Hi Neil,
On 22/11/2011 9:51 PM, Neil Richards wrote:
I've created a webrev [1] to address the problem reported in bug
7094995, where the ClearStaleZipFileInputStreams testcase leaves a
lingering GC inducing thread running after the test ends (w
It's been a long time ago.
Had someone had the time to think about this:
Am 29.10.2011 13:17, schrieb Sebastian Sickelmann:
Sorry i linked the wrong webrev for Solution 3.
Am 27.10.2011 16:50, schrieb Sebastian Sickelmann:
Some time ago (see below) i ask what would be the right solution to
ref
Changeset: d27f0b2f1476
Author:coffeys
Date: 2011-11-23 14:55 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d27f0b2f1476
7102369: remove java.rmi.server.codebase property parsing from registyimpl
7094468: rmiregistry clean up
Reviewed-by: smarks
! src/share/classes/sun/rmi/
On 23/11/2011 13:29, Neil Richards wrote:
:
Thanks for all your guidance on this.
I've uploaded another webrev [1], incorporating David's suggested ARM
correction (thanks) and Chris' suggested handling of
InterruptedException (together a System.out.println(), for clarity).
Looks fine to me too.
On 11/23/11 01:29 PM, Neil Richards wrote:
On Tue, 2011-11-22 at 19:09 +, Chris Hegarty wrote:
On 11/22/11 06:56 PM, Alan Bateman wrote:
On 22/11/2011 17:22, Neil Richards wrote:
:
Can you tell me, when jtreg decides to fire an interrupt at a test, has
it already concluded that the test
On Tue, 2011-11-22 at 19:09 +, Chris Hegarty wrote:
> On 11/22/11 06:56 PM, Alan Bateman wrote:
> > On 22/11/2011 17:22, Neil Richards wrote:
> >> :
> >>
> >> Can you tell me, when jtreg decides to fire an interrupt at a test, has
> >> it already concluded that the test has "failed" (or, at lea
Changeset: 7eb0debca9b3
Author:chegar
Date: 2011-11-23 12:30 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7eb0debca9b3
6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is
not destroyed ,fastdebug LINUX
Reviewed-by: chegar, dholmes
Contributed-by:
Changeset: 82151e860a64
Author:xuelei
Date: 2011-11-23 03:40 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82151e860a64
7113275: compatibility issue with MD2 trust anchor and old X509TrustManager
Summary: also reviewed by dennis...@oracle.com
Reviewed-by: mullan
! src/share
On 22/11/2011 23:26, Xueming Shen wrote:
Hi,
java.util.zip.Adler32/CRC32 do not have update method that accepts
ByteBuffer.
As of JDK7, you have to copy the content of the ByteBuffer into a
byte[], then
invoke Adler32/CRC32.update() method, which might have significant
performance
impact for
On 23/11/2011 06:27, David Holmes wrote:
Thumbs up from me.
David
Looks okay to me too although 120s seems way too high, I'd be interested
to know how long the termination actually takes on one of these slow
machines when it is heavily loaded.
-Alan.
On 22/11/2011 19:09, Chris Hegarty wrote:
Right, and I was proposing that any threads created by the test be
interruptible and be able to terminate in a timely manner.
I don't think in this case throwing from the catch block of IE is
necessary, just that the thread terminate quickly. It is n
23 matches
Mail list logo
