Hi Ivan,
I think we need to apply the brakes here and back up a bit :)
First of all these aren't typo fixes they are spec changes and they will
need to go through CCC for approval.
Second point is that the condition "fromIndex >= size()" is already
captured by the condition "if {@code fromIn
On Mar 12, 2014, at 1:45 AM, Peter Levart wrote:
> What would the following cost?
>
>
>private transient String stringCache;
>
>public String toString() {
> […]
This version did not show any significant difference in the benchmark results
(updated)
http://cr.openjdk.java.net/~
On Mar 12, 2014, at 2:08 AM, Peter Levart wrote:
> Huh! This is a ThreadLocalRandom anti-pattern. Thou should not use a
> ThreadLocalRandom instance in a thread that did not obtain it via a call to
> ThreadLocalRandom.current()…
Good point.
> You could create a new BigInteger(512, rnd) in the
Thanks David for the update!
Joe
On 3/13/2014 4:07 PM, David Li wrote:
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webre
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/
New test case was added for code change in RangeToken.intersectRanges.
On 03/13/2014 12:34 PM, Martin Buchholz wrote:
I notice there are zero jtreg tests for removeRange. That should be fixed.
I notice there is a removeRange in CopyOnWriteArrayList, but it is
package-private instead of "protected", which seems like an oversight. Can Doug
remember any history on t
Sorry, I forgot to incorporate changes to AbstractList.removeRange()
documentation, which you Martin had suggested.
Here's the webrev with those included:
http://cr.openjdk.java.net/~igerasim/8014066/2/webrev/
Sincerely yours,
Ivan
On 13.03.2014 23:03, Ivan Gerasimov wrote:
Would you please
On Mar 13, 2014, at 4:21 AM, Paul Sandoz wrote:
> On Mar 12, 2014, at 10:23 PM, John Rose wrote:
>> P.S. FTR, I wish we could also remove the per-object monitor from its
>> privileged position, so not all objects are burdened by it, and other forms
>> of lock can be switched into the existing
Would you please take a look at the updated webrev:
http://cr.openjdk.java.net/~igerasim/8014066/1/webrev/
In addition to the javadoc correction, it includes a regression test and
a check for (fromIndex > toIndex).
The last check turns out to be sufficient for removeRange() method to
agree with
On 13.03.2014 22:16, Ivan Gerasimov wrote:
On 13.03.2014 20:37, Martin Buchholz wrote:
The corner case for removeRange(SIZE, SIZE) does seem rather tricky,
and it's easy for an implementation to get it wrong. All the more
reason to add tests!
It was a good idea to add a test for removeRan
On 13.03.2014 20:37, Martin Buchholz wrote:
The corner case for removeRange(SIZE, SIZE) does seem rather tricky,
and it's easy for an implementation to get it wrong. All the more
reason to add tests!
It was a good idea to add a test for removeRange().
I just discovered that IOOB isn't throw
Hi
Could we have someone review this change. This is just a backport from JDK8,
but there were some small changes so we want to get a proper review here.
We have several other backports waiting for this change (fixes using the new
test libraries), so it would be good to get this going.
Kind Re
On 03/13/2014 05:02 PM, Paul Sandoz wrote:
> On Mar 13, 2014, at 5:26 PM, Andrew Haley wrote:
>>
> A quick solution is to leverage Unsafe within a
> ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be
> used (as Aleksey says in [1]) for put/get as well, which i presume
On Mar 13, 2014, at 5:26 PM, Andrew Haley wrote:
>
A quick solution is to leverage Unsafe within a
ByteBuffer.compareUnsigned method. In fact i believe Unsafe could be
used (as Aleksey says in [1]) for put/get as well, which i presume
is likely to be much easier/quicker to imp
Thank you Martin for your feedback!
I'll add the test with the next webrev.
Here's the test I used to check that the exception isn't thrown:
class Test extends java.util.ArrayList {
public static void main(String[] args) throws Throwable {
Test list = new Test();
list.add(1);
On 03/13/2014 02:26 PM, David M. Lloyd wrote:
> On 03/13/2014 07:19 AM, Andrew Haley wrote:
>> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
>>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
>>> Arrays.compareUnsigned.
>>>
>>> An explosion of methods on Arrays for all type
On 03/13/2014 02:19 PM, Paul Sandoz wrote:
>
> On Mar 13, 2014, at 1:57 PM, Andrew Haley wrote:
>
>> On 03/13/2014 12:49 PM, Paul Sandoz wrote:
>>> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
> Now i am in two minds to whether to add Byte
Thank you Chris!
It is System.arraycopy() method, where checking is performed and the
exception is thrown.
Here's this code:
if ( (((unsigned int) length + (unsigned int) src_pos) > (unsigned
int) s->length())
|| (((unsigned int) length + (unsigned int) dst_pos) > (unsigned
int) d->len
You could definitely safely do a check to see if elementData ==
EMPTY_ELEMENTDATA (irrespective of size), and if so, return
EMPTY_ELEMENTDATA instead of copying.
I don't think however that that method, as is, is actually unsafe. I
can't think of a code path where, say, a sudden concurrent cha
Hi Joe,
Thanks for the reply and hinting me the right direction!
I had seen these methods but was missing the down-cast to
AnnotatedParameterizedType which gives access to
getAnnotatedActualTypeArguments(). In case it's helpful to others, that's
what I ended up with:
Field myField = ...;
Mike,
The constructor modification looks good. The only other alternative I can
think would be to use 'c.toArray(EMPTY_ELEMENTDATA)' to avoid creating an extra
array. I'm guessing that version would not perform as well as your current
version.
The modification for toArray violates the List
Ivan,
This does look a little odd, but since fromIndex is inclusive I would think
that it should throw if passed a value of size() ??
-Chris.
On 13 Mar 2014, at 15:29, Ivan Gerasimov wrote:
> Hello!
>
> Would you please review a simple fix of the javadoc for
> ArrayList#removeRange() method
Hello!
Would you please review a simple fix of the javadoc for
ArrayList#removeRange() method?
The doc says that IndexOutOfBoundsException is thrown if fromIndex or
toIndex is out of range (fromIndex < 0 || fromIndex >= size() || toIndex
> size() || toIndex < fromIndex).
The condition 'fro
Hello,
See the methods in java.lang.reflect named "getAnnotedFoo" which return
java.lang.reflect.AnnotedType or a subinterface.
-Joe
On 3/13/2014 6:24 AM, Gunnar Morling wrote:
Hi,
Is it possible to retrieve type annotations (as defined by JSR 308) using
reflection at runtime? E.g. I would
On Mar 13, 2014, at 1:57 PM, Andrew Haley wrote:
> On 03/13/2014 12:49 PM, Paul Sandoz wrote:
>> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
>>> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
Arrays.compareUns
On 03/13/2014 07:19 AM, Andrew Haley wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
Arrays.compareUnsigned.
An explosion of methods on Arrays for all types (plus to/from versions) would
be annoying.
Surely it's a n
Thanks Paul, for the review!.
Hi,
Eye-balled the changes, nothing obvious popped out. Looks good.
It's very minor, and should not block the code going back, but "occured" is a common
misspelling of "occurred".
fyi, these are *all* changes made upstream, by the ASM team, the only
file we
Hi,
Is it possible to retrieve type annotations (as defined by JSR 308) using
reflection at runtime? E.g. I would like to retrieve the @NotNull
annotation from a member declared like this:
private List<@NotNull String> names;
I assumed that this would be possible using reflection, but I coul
On 03/13/2014 12:49 PM, Paul Sandoz wrote:
> On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
>> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
>>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
>>> Arrays.compareUnsigned.
>>>
>>> An explosion of methods on Arrays for all t
On Mar 13, 2014, at 1:19 PM, Andrew Haley wrote:
> On 03/13/2014 11:57 AM, Paul Sandoz wrote:
>> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
>> Arrays.compareUnsigned.
>>
>> An explosion of methods on Arrays for all types (plus to/from versions)
>> would be annoyin
+1
Masayoshi
On 3/13/2014 9:19 PM, Seán Coffey wrote:
Looks good Aleksej. A future rule change doesn't necessarily mean a
new GMT offset change. Original test logic seemed buggy.
regards,
Sean.
On 12/03/2014 15:06, Aleksej Efimov wrote:
Hello,
Can I have a review for a 'test/sun/util/calen
+1
Masayoshi
On 3/13/2014 9:18 PM, Seán Coffey wrote:
Looks good to me.
regards,
Sean.
On 12/03/2014 15:05, Aleksej Efimov wrote:
Hello,
Can I have a review for a tzdata2014a [1] integration to JDK9:
http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00
The following test sets were exec
Looks good Aleksej. A future rule change doesn't necessarily mean a new
GMT offset change. Original test logic seemed buggy.
regards,
Sean.
On 12/03/2014 15:06, Aleksej Efimov wrote:
Hello,
Can I have a review for a 'test/sun/util/calendar/zi/Zoneinfo.java'
test bug failure [1] related to th
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
> Now i am in two minds to whether to add ByteBuffer.compareUnsigned or add
> Arrays.compareUnsigned.
>
> An explosion of methods on Arrays for all types (plus to/from versions) would
> be annoying.
Surely it's a no brainer? All we have to do is add t
Looks good to me.
regards,
Sean.
On 12/03/2014 15:05, Aleksej Efimov wrote:
Hello,
Can I have a review for a tzdata2014a [1] integration to JDK9:
http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00
The following test sets were executed on the build with latest tzdata:
test/sun/util/calen
On Feb 28, 2014, at 11:29 PM, Martin Buchholz wrote:
> Are word-size reads in ByteBuffer actually intrinsified? I could find no
> evidence for that. Perhaps this is an important missing optimization for
> hotspot to make?
>
> I see DirectByteBuffer, but not garden-variety ByteBuffer, using
On Mar 12, 2014, at 10:23 PM, John Rose wrote:
> P.S. FTR, I wish we could also remove the per-object monitor from its
> privileged position, so not all objects are burdened by it, and other forms
> of lock can be switched into the existing notation on a type-by-type basis.
> This is obviously
Hi,
Eye-balled the changes, nothing obvious popped out. Looks good.
It's very minor, and should not block the code going back, but "occured" is a
common misspelling of "occurred".
Paul.
On Mar 12, 2014, at 10:24 PM, Kumar Srinivasan
wrote:
> Hello,
>
> Appreciate if someone cane review thi
Looks good to me Mark.
-Chris.
On 12 Mar 2014, at 17:39, Mark Sheppard wrote:
>
> Hi
> please oblige and review the following changes
> http://cr.openjdk.java.net/~msheppar/8035870/webrev/
>
> which address the issues raised in
> https://bugs.openjdk.java.net/browse/JDK-8035870
>
> summary
39 matches
Mail list logo
