Hi Peter,
The concerns you raise below are some of the trade-offs I was thinking
of as I was working on the current implementation :-)
From a specification perspective, I'd like the @implSpec for this
method to allow different combinations of calling
getDeclaredAnnotation(Class) and getDecla
Xueming Shen wrote on 10/25/13 15:19:
> On 10/25/13 2:19 PM, Bill Shannon wrote:
>> If I understand this correctly, this proposes to remove the "lenient"
>> option we've been discussing and just make it always lenient. Is that
>> correct?
>
> Yes. Only for the mime type though.
That's fine.
>>
On 10/25/13 2:19 PM, Bill Shannon wrote:
If I understand this correctly, this proposes to remove the "lenient"
option we've been discussing and just make it always lenient. Is that
correct?
Yes. Only for the mime type though.
Unfortunately, from what you say below, it's still not lenient en
Changeset: 8ea272253285
Author:smarks
Date: 2013-10-25 14:53 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ea272253285
5063500: Formatter spec says "char" is not an integral type
7126305: Wrong Unicode value specified for format conversion character 'd'
8027287: incorrect e
Ha! Some quick and easy reviews for a Friday afternoon! OK, I'll pop this one
in. Thanks.
s'marks
On 10/25/13 2:02 PM, Lance Andersen - Oracle wrote:
+1
On Oct 25, 2013, at 4:50 PM, Stuart Marks wrote:
Hi all,
Please review a few minor javadoc fixes in java.util.Formatter. Links to bugs
ar
Looks fine to me.
The example "%1$tm %1$te,%1$tY" is used elsewhere in the class
description, but I think your change is probably best ( rather than
trying to make them consistent ).
-Chris.
On 10/25/2013 09:50 PM, Stuart Marks wrote:
Hi all,
Please review a few minor javadoc fixes in java
If I understand this correctly, this proposes to remove the "lenient"
option we've been discussing and just make it always lenient. Is that
correct?
Unfortunately, from what you say below, it's still not lenient enough.
I'd really like a version that never, ever, for any reason, throws an
excepti
+1
On Oct 25, 2013, at 4:50 PM, Stuart Marks wrote:
> Hi all,
>
> Please review a few minor javadoc fixes in java.util.Formatter. Links to bugs
> are:
>
> https://bugs.openjdk.java.net/browse/JDK-5063500
> https://bugs.openjdk.java.net/browse/JDK-7126305
> https://bugs.openjdk.java.net/browse/J
Looks good!
-Joe
On 10/25/2013 01:50 PM, Stuart Marks wrote:
Hi all,
Please review a few minor javadoc fixes in java.util.Formatter. Links
to bugs are:
https://bugs.openjdk.java.net/browse/JDK-5063500
https://bugs.openjdk.java.net/browse/JDK-7126305
https://bugs.openjdk.java.net/browse/JDK-
Three for the price of one. Looks fine. (Not a Reviewer)
Roger
On 10/25/2013 4:50 PM, Stuart Marks wrote:
Hi all,
Please review a few minor javadoc fixes in java.util.Formatter. Links
to bugs are:
https://bugs.openjdk.java.net/browse/JDK-5063500
https://bugs.openjdk.java.net/browse/JDK-71
Hi all,
Please review a few minor javadoc fixes in java.util.Formatter. Links to bugs
are:
https://bugs.openjdk.java.net/browse/JDK-5063500
https://bugs.openjdk.java.net/browse/JDK-7126305
https://bugs.openjdk.java.net/browse/JDK-8027287
The fixes are all one-liners so I've just appended the p
Thanks a lot, Martin!
I created the Jira issue for your proposal:
https://bugs.openjdk.java.net/browse/JDK-8027348.
Sincerely yours,
Ivan
On 25.10.2013 20:06, Martin Buchholz wrote:
I propose the test for this be in test/java/lang/ProcessBuilder/
instead of test/java/lang/Runtime/exec and
Hi Peter,
On 10/25/2013 05:28 AM, Peter Levart wrote:
On 10/25/2013 12:29 PM, Peter Levart wrote:
Hi Joe,
So, the order must be respected, right.
There's a bug. I think you wanted to call:
((Class) this).getSuperclass()
Instead of:
thisClass.getSuperclass()
...which would always return O
On 10/25/2013 03:29 AM, Peter Levart wrote:
Hi Joe,
So, the order must be respected, right.
There's a bug. I think you wanted to call:
((Class) this).getSuperclass()
Instead of:
thisClass.getSuperclass()
...which would always return Object.class...
Right; thanks catching that.
Time to
Hi Joe,
The code below is more optimal only in AnnotatedElement implementations
that don't override getDeclaredAnnotation(Class) with more optimal
implementation based on a HashMap lookup. Your implementation avoids
calling getDeclaredAnnotations() in common cases (where only directly
present
Hi Joe,
I propose some "premature" optimization for
AnnotatedElement.getDeclaredAnnotationsByType(). This implementation
calls either getDeclaredAnnotatios() once or
getDeclaredAnnotation(Class) once, depending on whether the annotation
type is repeatable or not respectively (this check also
On 10/25/2013 12:29 PM, Peter Levart wrote:
Hi Joe,
So, the order must be respected, right.
There's a bug. I think you wanted to call:
((Class) this).getSuperclass()
Instead of:
thisClass.getSuperclass()
...which would always return Object.class...
Well, this is not the only change need
Changeset: 1153022c0a45
Author:jbachorik
Date: 2013-10-25 13:01 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1153022c0a45
8004926: sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times
out
Summary: Improve reliability by converting the test to Java
Reviewe
Hi Joe,
So, the order must be respected, right.
There's a bug. I think you wanted to call:
((Class) this).getSuperclass()
Instead of:
thisClass.getSuperclass()
...which would always return Object.class...
Regards, Peter
On Oct 25, 2013 10:40 AM, "Joe Darcy" wrote:
> Hi Joel and Peter,
>
>
Changeset: d126301ad372
Author:ewang
Date: 2013-10-25 11:01 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d126301ad372
7079145: Remove java/net/ipv6tests/UdpTest.java from the ProblemList.txt
Reviewed-by: alanb, chegar
! test/ProblemList.txt
Hi Joel and Peter,
On 10/24/2013 07:10 AM, Peter Levart wrote:
Hi Joe,
I see two problems with the implementation in
*AnnotatedElementSupport*. The first is the treatment of declared-only
annotations where the code returns either directly present or
in-directly present repeatable annotations
21 matches
Mail list logo
