Looks good to me Mark.
-Chris.
On 12 Mar 2014, at 17:39, Mark Sheppard mark.shepp...@oracle.com wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8035870/webrev/
which address the issues raised in
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 kumar.x.sriniva...@oracle.com
wrote:
Hello,
Appreciate if
On Mar 12, 2014, at 10:23 PM, John Rose john.r.r...@oracle.com 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.
On Feb 28, 2014, at 11:29 PM, Martin Buchholz marti...@google.com 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
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:
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 the
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
+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
+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
On Mar 13, 2014, at 1:19 PM, Andrew Haley a...@redhat.com 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
On 03/13/2014 12:49 PM, Paul Sandoz wrote:
On Mar 13, 2014, at 1:19 PM, Andrew Haley a...@redhat.com 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
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
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
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
On Mar 13, 2014, at 1:57 PM, Andrew Haley a...@redhat.com wrote:
On 03/13/2014 12:49 PM, Paul Sandoz wrote:
On Mar 13, 2014, at 1:19 PM, Andrew Haley a...@redhat.com 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
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
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
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 ivan.gerasi...@oracle.com wrote:
Hello!
Would you please review a simple fix of the javadoc for
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
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 = ...;
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
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)
On 03/13/2014 02:19 PM, Paul Sandoz wrote:
On Mar 13, 2014, at 1:57 PM, Andrew Haley a...@redhat.com wrote:
On 03/13/2014 12:49 PM, Paul Sandoz wrote:
On Mar 13, 2014, at 1:19 PM, Andrew Haley a...@redhat.com wrote:
On 03/13/2014 11:57 AM, Paul Sandoz wrote:
Now i am in two minds to
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 types (plus
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.ArrayListInteger {
public static void main(String[] args) throws Throwable {
Test list = new Test();
On Mar 13, 2014, at 5:26 PM, Andrew Haley a...@redhat.com 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
On 03/13/2014 05:02 PM, Paul Sandoz wrote:
On Mar 13, 2014, at 5:26 PM, Andrew Haley a...@redhat.com 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 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
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
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 Mar 13, 2014, at 4:21 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Mar 12, 2014, at 10:23 PM, John Rose john.r.r...@oracle.com 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
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 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
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:
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
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)
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
37 matches
Mail list logo
