Sorry, all paragraphs were in disorder ; looks like my mail app is not wysiwyg
at all.
I hope this time content doesn't get messed up, else I'll just give up.
- Message transféré
De : Jeff Hain jeffh...@rocketmail.com
À : core-libs-dev@openjdk.java.net
Envoyé le : Mer 13 juillet 2011,
This message is forwarded from Apache Commons, where a question was
raised as to whether the change in behaviour of year formatting in JDK
7 was deliberate:
Stephen
-- Forwarded message --
From: Jörg Schaible joerg.schai...@gmx.de
Date: 12 July 2011 18:56
Subject: Re: [lang] RC4
Changeset: db419c454f92
Author:dl
Date: 2011-07-13 12:24 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db419c454f92
7057320: test/java/util/concurrent/Executors/AutoShutdown.java failing
intermittently
Summary: Add retry/timeout for checking activeCount
Reviewed-by: chegar
Jeff Hain wrote:
Hello.
I have some remarks about the methods named in the subject (JDK 6u26, JDK
7b147).
1) AbstractCollection.removeAll(Collection)
This method could return immediately if the specified collection is
empty,
not to iterate uselessly over all this, or if this is
It doesn't work because the complexity of size() can be O(n).
In my opinion, only the checks for emptyness are Ok.
Rémi
On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
Jeff Hain wrote:
Hello.
I have some remarks about the methods named in the subject (JDK 6u26, JDK
7b147).
1)
It doesn't work because the complexity of size() can be O(n).
In my opinion, only the checks for emptyness are Ok.
The calls to size() are already there in current implementation,
and I think with the idea that in most cases they are O(1).
If they are O(n), it's of course pointless to
It looks to me that AbstractCollection could benefit from a c.isEmpty() check
but that's the only optimization I currently see. It's necessary to iterate the
target collection because values can be repeated for some collection types.
I agree that AbstractSet.removeAll appears to make a poor
Mike,
The history is in the evaluation of
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6394757
I don't think that even adding a empty check can be considered an optimization
when dealing with two abstract things. The iterator creation here is 'good
garbage' and worst case
On Jul 13 2011, at 15:19 , Jason Mehrens wrote:
worst case AbstractCollection.isEmpty could be O(N).
JDKs 5 and 6 shipped with two collections (CHM views) that had O(N) isEmpty
methods.
This is very interesting. The common wisdom has been that size() should be
avoided because of O(1)
Hello.
Please code review my JDK 8 changes for
7007535: (reflect) Please generalize Constructor and Method
http://cr.openjdk.java.net/~darcy/7007535.3
To summarize the changes, a new superclass is defined to capture the
common functionality of java.lang.reflect.Method and
10 matches
Mail list logo
