On 31/01/2012 11:12 AM, Joe Darcy wrote:
On 01/30/2012 04:50 PM, David Holmes wrote:
On 31/01/2012 1:08 AM, Alan Bateman wrote:
The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
to remove the JAX-WS dependency on apt and the com.sun.mirror API:
http://cr.openjdk.java.ne
On 01/30/2012 04:50 PM, David Holmes wrote:
On 31/01/2012 1:08 AM, Alan Bateman wrote:
The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
to remove the JAX-WS dependency on apt and the com.sun.mirror API:
http://cr.openjdk.java.net/~alanb/7140918/webrev/
This is needed b
On 31/01/2012 1:08 AM, Alan Bateman wrote:
The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
to remove the JAX-WS dependency on apt and the com.sun.mirror API:
http://cr.openjdk.java.net/~alanb/7140918/webrev/
This is needed before Joe Darcy can wield his machete.
Pleas
I agree that performance of clone vs copy ctor should be irrelevant in the
grand scheme of things -- I think this question is purely academic at this
point. I think most call sites that call clone() will have just one (maybe
two) receiver types, so the guard should predict every time in most cases
On 01/30/2012 10:17 PM, Vitaly Davidovich wrote:
I would also expect clone to run a bit faster than copy constructor, if for
nothing else than clone not executing any constructor; this perf diff would
probably be more noticeable in interpreter as compiler may inline
constructor. In addition, I'd
I would also expect clone to run a bit faster than copy constructor, if for
nothing else than clone not executing any constructor; this perf diff would
probably be more noticeable in interpreter as compiler may inline
constructor. In addition, I'd also think that clone can basically be
equivalent
Am 30.01.2012 14:28, schrieb Tom Hawtin:
On 30/01/2012 13:16, Ulf Zibis wrote:
Isn't cloning faster than normal instantiation?
I can imagine, that behind the scenes cloning mainly only needs to
duplicate the binary footprint of an object.
I don't see a good reason why it should be (equally, I'
On 01/30/2012 04:19 AM, Tom Hawtin wrote:
On 30/01/2012 03:58, Joe Darcy wrote:
Object clone()
method inherited from java.lang.Object with a covariant override such as
MyType clone()
This is, of course, going to break any existing overrides (that aren't
making use of covariant return types
On 01/29/2012 10:52 PM, Rémi Forax wrote:
On 01/30/2012 04:58 AM, Joe Darcy wrote:
Hello,
As an indirect outgrowth of warnings cleanup day, various categories
of warnings can be eliminated by in the use of Cloneable types by
overriding the
Object clone()
method inherited from java.lang
On 01/27/2012 02:41 PM, Tim Buktu wrote:
On 01/11/2012 11:59 AM, Joe Darcy wrote:
Thanks Tim. I'll add this to my review queue after Alan Eliasen's work
(finally) gets in.
Is there a timeframe for this yet?
The timeframe is on the order of weeks to months.
Cheers,
-Joe
On 01/30/2012 07:08 AM, Alan Bateman wrote:
The following webrev is a patch from Miran Kos and Martin Grebac
(cc'ed) to remove the JAX-WS dependency on apt and the com.sun.mirror
API:
http://cr.openjdk.java.net/~alanb/7140918/webrev/
This is needed before Joe Darcy can wield his machete.
P
The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
to remove the JAX-WS dependency on apt and the com.sun.mirror API:
http://cr.openjdk.java.net/~alanb/7140918/webrev/
This is needed before Joe Darcy can wield his machete.
Please cc'ed Miran and Martin on my review comm
Changeset: f9fb8c4b4550
Author:dl
Date: 2012-01-30 11:44 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9fb8c4b4550
7132378: Race in FutureTask if used with explicit set ( not Runnable )
Reviewed-by: chegar, dholmes
! src/share/classes/java/util/concurrent/FutureTask.java
+
On 01/30/2012 01:19 PM, Tom Hawtin wrote:
On 30/01/2012 03:58, Joe Darcy wrote:
Object clone()
method inherited from java.lang.Object with a covariant override such as
MyType clone()
This is, of course, going to break any existing overrides (that aren't
making use of covariant return types
On 30/01/2012 13:16, Ulf Zibis wrote:
Isn't cloning faster than normal instantiation?
I can imagine, that behind the scenes cloning mainly only needs to
duplicate the binary footprint of an object.
I don't see a good reason why it should be (equally, I've not tried
benchmarking).
For the imm
Am 30.01.2012 13:19, schrieb Tom Hawtin:
A better solution to the unchecked casts from clone, is not to clone. Using a constructor gets rid
of the problem, and ensures you aren't using some funky (potentially malicious) subclass.
-return (Hashtable)_env.clone();
+return
On 30/01/2012 03:58, Joe Darcy wrote:
Object clone()
method inherited from java.lang.Object with a covariant override such as
MyType clone()
This is, of course, going to break any existing overrides (that aren't
making use of covariant return types). This will be why the changes
weren't ma
17 matches
Mail list logo
