Stuart Marks wrote:
Hi all,
The following webrev changes a variety of files in java.lang, math,
and util, and their corresponding tests, to use the new Java 7
try-with-resources construct. I think most of the changes should be
straightforward. In a few cases (e.g., Currency.java and
Changeset: dbdafe65af60
Author:alanb
Date: 2011-02-21 13:54 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbdafe65af60
7020517: (fs) FileStore.equals returns true if both volumes have the same
serial number
Reviewed-by: chegar
!
Too many balls in the air, looks like I created the change-set for
7020888 while have another patch in my working copy. This means the
change included changes to several java.io classes that should have been
there. Nothing wrong with the change, they fix long standing issues that
were
Changeset: bac152c6491a
Author:alanb
Date: 2011-02-22 14:28 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bac152c6491a
7021327: Changes for 7020888 included changes to other files in error
Reviewed-by: chegar
! src/share/classes/java/io/BufferedReader.java
!
Changeset: b853414b8eef
Author:michaelm
Date: 2011-02-22 14:44 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b853414b8eef
6702400: ChunkedInputStream expecting -1 from int read, but int-char
comparision is wrong
Reviewed-by: chegar
!
On 2/20/2011 9:39 AM, Dr Andrew John Hughes wrote:
On 15 February 2011 20:23, Phil Racephilip.r...@oracle.com wrote:
On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote:
Yes, IcedTea uses system libraries for everything bar LCMS, where
local changes in OpenJDK mean we are still forced to use
Hello, community!
Is java.awt.Graphics not a candidate for AutoCloseable?
In most cases, a Graphics object has to be dispose()'d at the end.
Couldn't it be extended with close() which would be a delegate to dispose()?
Best regards,
Ivan G Shevchenko
Aside from the fact that its weird, if not downright wrong
to think of a Graphics instance as closeable,
Graphics instances are not used in the same way as all
the stream type resources for which AutoCloseable is intended.
In most cases they are provided to you in a call to paint()
Releasing a
Right, I was dealing with sources, where accidentally all Graphics objects were
manually created from BufferedImage objects ;)
So I wasn't thinking about the more common case of paint().
22.02.2011, 21:19, Phil Race philip.r...@oracle.com:
Aside from the fact that its weird, if not downright
Looks good to me.
Naoto
(2/21/11 6:05 PM), Stuart Marks wrote:
Hi all,
The following webrev changes a variety of files in java.lang, math, and
util, and their corresponding tests, to use the new Java 7
try-with-resources construct. I think most of the changes should be
straightforward. In a
Changeset: 75216854fb53
Author:valeriep
Date: 2011-02-22 12:01 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75216854fb53
6604496: Support for CKM_AES_CTR (counter mode)
Summary: Enhanced SunPKCS11 provider to support AES/CTR/NoPadding
transformation.
Reviewed-by: vinnie
On 2/22/11 12:44 AM, Alan Bateman wrote:
Minor comment on test/java/util/Formatter/FailingConstructors.java is that an
alternative to using try-with-resources is to just replace it with
Files.write(file.toPath(), FILE_CONTENTS.getBytes()). Same thing in
Changeset: 84e339f1033b
Author:smarks
Date: 2011-02-22 15:34 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/84e339f1033b
7021209: convert lang, math, util to use try-with-resources
Reviewed-by: alanb, darcy, naoto
! src/share/classes/java/lang/Package.java
!
On 22 February 2011 17:26, Phil Race philip.r...@oracle.com wrote:
On 2/20/2011 9:39 AM, Dr Andrew John Hughes wrote:
On 15 February 2011 20:23, Phil Racephilip.r...@oracle.com wrote:
On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote:
Yes, IcedTea uses system libraries for everything bar
On 2/22/2011 3:51 PM, Dr Andrew John Hughes wrote:
On 22 February 2011 17:26, Phil Racephilip.r...@oracle.com wrote:
We believe LCMS 2.0 should pass JCK, but I don't know if a full JCK run
has been performed against a fully open 7 build since it went in.
A 6-open backport would find any
Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor
and hashCode() methods. I've prepared a webrev with the suggested changes:
http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/
I've tested the change against the standard UUID tests and did a microbenchmark
Hi Vitaly,
Vitaly Davidovich said the following on 02/23/11 11:46:
Unless i missed something, seems like the race can be fixed via same
mechanics as String.hashcode; ie since all of the cached values are based on
least and most significant bits which are final and the long members are
volatile,
I think you have a potential visibility problem here. You use -1 as the
initial value, but observing threads might see instead the default value
if the initializing write is not visible, and mistakenly think that the
zero default value represents a computed value. (This is different from
the
18 matches
Mail list logo
