Added some evaluation. Copied here:
The URL in the testcase has an invalid encoding. Its Unicode characters
must be encoded in UTF-8. For example,
\u3070 -> \e3\81\b0 -> %5Ce3%5C81%5Cb0
-Weijun
On 03/01/2012 03:39 PM, Sean Chou wrote:
Hi all,
I just encountered this bug:
http://bugs.
Changeset: 6eed7049d389
Author:ptisnovs
Date: 2012-03-01 14:02 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6eed7049d389
7149785: Minor corrections to ScriptEngineManager javadoc
Summary: JavaDoc correction
Reviewed-by: alanb
Contributed-by: Pavel Tisnovsky
! src/share/cl
Hi Stuart,
Please find an updated webrev here:
http://cr.openjdk.java.net/~khazra/7146763/webrev.05/
Thanks,
Kurchi
On 2/28/2012 4:32 PM, Stuart Marks wrote:
Right, I remember this issue. In the email you referenced [1] Max said
"I remember we agreed on several rules" which were basically to
Changeset: 971a86421f51
Author:mduigou
Date: 2012-03-01 09:40 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/971a86421f51
7149320: Move sun.misc.VM.booted() to the end of System.initializeSystemClass()
Summary: Ensure that sun.misc.VM.booted() is the last action in
System.in
Hello all;
Currently Collections.sort() refuses to sort the lists which result from
calling Collections.singletonList(). This makes some sense because the
singleton lists are immutable but they are also alway sorted.
This patch allows Collections.sort() to be used with empty and singleton lists
Hello all;
Currently Collections.sort() refuses to sort the lists which result from
calling Collections.singletonList(). This makes some sense because the
singleton lists are immutable but they are also alway sorted.
This patch allows Collections.sort() to be used with empty and singleton lists
Looks good to me.
A superfluous comment in the test:
47 // 7065380
David
On 2/03/2012 5:50 AM, Mike Duigou wrote:
Hello all;
Currently Collections.sort() refuses to sort the lists which result from
calling Collections.singletonList(). This makes some sense because the
singleton lis
On 03/01/2012 08:50 PM, Mike Duigou wrote:
Hello all;
Currently Collections.sort() refuses to sort the lists which result from
calling Collections.singletonList(). This makes some sense because the
singleton lists are immutable but they are also alway sorted.
This patch allows Collections.sor
I thought so too initially but that's optimizing for empty or singleton
collections which probably are an edge case? Adding a branch, polymorphic
method call, and increasing bytecode size may not be worth it.
Sent from my phone
On Mar 1, 2012 3:25 PM, "Rémi Forax" wrote:
> On 03/01/2012 08:50 PM
Also some collections may not have an O(1) size().
Sent from my phone
On Mar 1, 2012 3:52 PM, "Vitaly Davidovich" wrote:
> I thought so too initially but that's optimizing for empty or singleton
> collections which probably are an edge case? Adding a branch, polymorphic
> method call, and increa
I thought about that but the usual issue of non-O(1) size() methods lead me to
avoid having a size() in addition to the toArray(). Not perfect. :(
Mike
On Mar 1 2012, at 12:26 , Rémi Forax wrote:
> On 03/01/2012 08:50 PM, Mike Duigou wrote:
>> Hello all;
>>
>> Currently Collections.sort() refu
On 03/01/2012 09:52 PM, Vitaly Davidovich wrote:
I thought so too initially but that's optimizing for empty or
singleton collections which probably are an edge case? Adding a
branch, polymorphic method call, and increasing bytecode size may not
be worth it.
toArray is also polymorphic, so
On 03/01/2012 09:58 PM, Mike Duigou wrote:
I thought about that but the usual issue of non-O(1) size() methods lead me to
avoid having a size() in addition to the toArray(). Not perfect. :(
not perfect but you're right, it's better than calling size().
Mike
Rémi
Doesn't this break the contract of the method? It specifies that it throws
UnsupportedOperationException if the specified list's list-iterator does
not support the set operation. Its Javadoc body also states that the list
must be modifiable. (Though sort() already succeeds for an emptyList()
despit
What about exception cases where the single element is not comparable?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5045147
Consider the following:
=
Object[] a = new Object[]{new Object()};
Arrays.sort(a);
List l = Arrays.asList(a); //Evil raw type
Collections.sort(l);
I always read @throws declarations as "if thrown then description was the
cause" rather than "will be thrown if description". A minor difference in
interpretation that can sometimes be useful.
For this particular case the restriction on sort() seems to serve only to blunt
the usefulness of Coll
+1. A no-op sort() on an emptyList or singletonList() behaves in an
intuitive manner, IMHO. If the concern is that sort() will hide user bugs,
well my answer would be that sort()'s job is just that: sort the collection
-- it's not a defense mechanism for catching unrelated user bugs.
On Thu, Ma
I fail to come up with a (common) use case where this will be enabling
- I did read the example in the bug description but wasn't quite
convinced.
Having said that, a generalisation whereby Arrays.sort(a) or an
internal version of it returns a boolean indicating whether any
elements has been swapp
Hi Mike,
The main body of the javadoc of method does state
176 * The specified list must be modifiable, but need not be
resizable.
so I agree that a small javadoc update is needed to support this
reasonable expansion of behavior.
A further expansion would be "The list must be modifia
On Thu, Mar 1, 2012 at 2:02 PM, Mike Duigou wrote:
I always read @throws declarations as "if thrown then description was the
> cause" rather than "will be thrown if description".
FWIW, I have never read them this way, and I think there are plenty of
examples in the JDK that illustrate that it d
On 2/03/2012 10:22 AM, Joe Darcy wrote:
Hi Mike,
The main body of the javadoc of method does state
176 * The specified list must be modifiable, but need not be resizable.
so I agree that a small javadoc update is needed to support this
reasonable expansion of behavior.
Sorry I didn't check t
On 2/03/2012 10:39 AM, Kevin Bourrillion wrote:
The status quo is that the user who actually experiences this problem can,
at worst, replace
Collections.sort(list);
with
if (list.size()> 1)
Collections.sort(list);
... that doesn't seem so bad to me.
It is horrendous if you us
Looks good! Thanks for making the updates.
Interestingly, sun/rmi/server/LoaderHandler.java has a couple methods that use
Class[] as a parameter (loadProxyClass, loadProxyInterfaces), but which don't
generate rawtypes warnings. I may investigate this at some point.
Anyway, I think this has go
But UrlUtil.decode(DN, "UTF8") and URLDecoder.decode(DN, "UTF8") are
returning
different strings, if DN has invalid encoding, why URLDecoder.decode(DN,
"UTF8") can
decode it ?
On Thu, Mar 1, 2012 at 4:21 PM, Weijun Wang wrote:
> Added some evaluation. Copied here:
>
> The URL in the testca
Hi,
Currently jdk/src/solaris/bin/java_md.c includes with
"#ifdef __linux__", but BSD, MAC OS, AIX all needs to include pthread.h.
To avoid the situation that the ifdef clause becomes longer and longer
like "#if defined(__linux__) || defined(_ALLBSD_SOURCE) || defined(AIX)
|| defined(OTHER_P
On 2/03/2012 5:05 PM, Shi Jun Zhang wrote:
Currently jdk/src/solaris/bin/java_md.c includes with
"#ifdef __linux__", but BSD, MAC OS, AIX all needs to include pthread.h.
To avoid the situation that the ifdef clause becomes longer and longer
like "#if defined(__linux__) || defined(_ALLBSD_SOURCE)
26 matches
Mail list logo
