k.java.net/browse/JDK-8202473 and
> was closed as a duplicate. With this cleaner solution, the duplication does
> however no longer apply.
>
> Am Mo., 6. Apr. 2020 um 14:01 Uhr schrieb Joel Borggrén-Franck <
> [email protected]>:
>
>> Many thanks to Vicent
On Mon, 14 Sep 2020 19:49:08 GMT, Rafael Winterhalter
wrote:
> This patch assures that an annotation on a type bound is placed on the
> correct bound index.
Pre-git review thread here:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html
-
PR: https://git.
On Tue, 15 Sep 2020 08:10:00 GMT, Joel Borggrén-Franck
wrote:
>> This patch assures that an annotation on a type bound is placed on the
>> correct bound index.
>
> Pre-git review thread here:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067049.html
@
On Tue, 15 Sep 2020 15:18:20 GMT, Rafael Winterhalter
wrote:
>> This patch assures that an annotation on a type bound is placed on the
>> correct bound index.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and
> previous commits have been removed. The
> incremental vi
On Fri, 6 Nov 2020 00:24:14 GMT, Hui Shi wrote:
>> If we are changing NativeMethodAccessorImpl.invoke then we should probably
>> do NativeConstructorAccessorImpl.newInstance at the same time. Also
>> wondering if we should, while in the area, add "return acc.invoke(obj,
>> args)" after setting
On Sat, 31 Oct 2020 21:11:15 GMT, Rafael Winterhalter
wrote:
>> A method's or constructor's owner type might carry annotations on its
>> potential type parameters but is never represented as parameterized type
>> what makes these parameters inaccessible at runtime, despite the presence of
>>
On Sun, 15 Nov 2020 23:25:22 GMT, Rafael Winterhalter
wrote:
>> A method's or constructor's owner type might carry annotations on its
>> potential type parameters but is never represented as parameterized type
>> what makes these parameters inaccessible at runtime, despite the presence of
>>
On Mon, 16 Nov 2020 11:10:19 GMT, Rafael Winterhalter
wrote:
>> A method's or constructor's owner type might carry annotations on its
>> potential type parameters but is never represented as parameterized type
>> what makes these parameters inaccessible at runtime, despite the presence of
>>
On Mon, 16 Nov 2020 11:23:47 GMT, Joel Borggrén-Franck
wrote:
>> Rafael Winterhalter has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR
On Mon, 16 Nov 2020 11:51:32 GMT, Rafael Winterhalter
wrote:
>> I think it would be good to rebase on top of a recent jdk upstream before
>> merging.
>
> Rebased on HEAD/master.
Tier 1-3 looks good, go ahead and / integrate and I'll sponsor
-
PR: https://git.openjdk.java.net/jdk/
Hi Rafael
Thanks for looking into this. Can you separate the two fixes into two
different patches? The tests should be moved to
java/lang/annotation/typeAnnotations/... . Nit, copyright year is wrong.
I can host webrevs for you on cr to make it easier for other reviewers, if
you also send me the
y) and upload everything there.
>> Best regards, Rafael
>>
>> Am Fr., 2. Aug. 2019 um 11:59 Uhr schrieb Daniel Fuchs <
>> [email protected]>:
>>
>>> Hi Rafael,
>>>
>>> On 02/08/2019 09:00, Joel Borggrén-Franck wrote:
>>>
k.java.net/~winterhalter/8202469/webrev.01/
>
> Thanks, Rafael
>
> Am So., 16. Feb. 2020 um 10:51 Uhr schrieb Joel Borggrén-Franck <
> [email protected]>:
>
>> Hi Rafael,
>>
>> Thanks for reaching out and reminding me of this!
>>
>> I m
Many thanks to Vicente for sponsoring this. I'll start to look at the
second part shortly.
cheers
/Joel
On Mon, Mar 16, 2020 at 9:44 PM Joel Borggrén-Franck <
[email protected]> wrote:
> Looks good to me!
>
> I'll see if I can find a sponsor for this.
>
On Tue, 24 Nov 2020 15:54:47 GMT, Joel Borggrén-Franck
wrote:
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> when this type or any of its transitive owner types has type p
The fix for JDK-8256693 too often produces a ParameterizedType as the result of
getAnnotatedReceiverType().getType() . A ParameterizedType is necessary when
this type or any of its transitive owner types has type parameters, but should
be avoided if this isn't the case.
This implementation recu
e case.
>
> This implementation recursively creates a chain of ParameterizedTypes
> starting from the outermost type that has type parameters.
Joel Borggrén-Franck has updated the pull request with a new target base due to
a merge or a rebase. The incremental webrev excludes the unrelated
On Tue, 24 Nov 2020 15:54:47 GMT, Joel Borggrén-Franck
wrote:
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> when this type or any of its transitive owner types has type p
On Fri, 27 Nov 2020 22:37:18 GMT, Rafael Winterhalter
wrote:
>> @raphw can you take a look at this?
>
> I just ran it a bit and this seems right to me. I just had an error reported
> in relation to this and I think this is fixed by your changes, too.
> (https://github.com/raphw/byte-buddy/issu
The fix for JDK-8256693 too often produces a ParameterizedType as the result of
getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only
when this type or any of its transitive owner types has type parameters, but
should be avoided if this isn't the case.
This implementation
On Wed, 16 Dec 2020 16:26:37 GMT, Vicente Romero wrote:
>> The fix for JDK-8256693 too often produces a ParameterizedType as the result
>> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
>> only when this type or any of its transitive owner types has type
>> paramete
On Wed, 16 Dec 2020 21:21:19 GMT, Vicente Romero wrote:
>> Yes, not great, but at least it isn't brittle when running the test, only
>> when changing it. I'd like to take a separate pass over the tests for 17 if
>> possible.
>
>> Yes, not great, but at least it isn't brittle when running the te
e case.
>
> This implementation recursively creates a chain of ParameterizedTypes
> starting from the outermost type that has type parameters.
>
> See here for the now closed JDK 17 pr:
> https://github.com/openjdk/jdk/pull/1414
Joel Borggrén-Franck has updated the pull request
On Wed, 16 Dec 2020 09:41:47 GMT, Joel Borggrén-Franck
wrote:
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> only when this type or any of its transitive owner types
On Tue, 5 Jan 2021 12:51:17 GMT, Rafael Winterhalter
wrote:
>> This change avoid that owner types of static nested classes are returned as
>> parameterized types.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and
> previous commits have been removed. The incremental
On Wed, 10 Mar 2021 06:19:27 GMT, Joe Darcy wrote:
> The javadoc of various methods in core reflection would be improved by links
> into the JLS.
Marked as reviewed by jfranck (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2906
On Wed, 31 Mar 2021 21:32:35 GMT, Joe Darcy wrote:
> The stricter checks added by
> 8035781: Improve equality for annotations
> in creating the proxy objects used to implement annotations has an unintended
> by-catch of rejecting annotation's whose type has, say, a field initialized
> with
On Sat, 10 Apr 2021 20:22:56 GMT, Rafael Winterhalter
wrote:
>> 8263763: The constructor of an enumeration prefixes with two synthetic
>> arguments for constant name and ordinal index. For this reason, the
>> constructor annotations need to be shifted two indices to the right, such
>> that th
On Wed, 14 Apr 2021 02:56:11 GMT, Joe Darcy wrote:
>> The results from Class.getDeclaredMethods can include bridge and other
>> synthetic methods, which can be unexpected by users (JDK-6815786,
>> JDK-8142904) and appear to be inherited methods. The javadoc for
>> Class.getDeclaredMethods shou
On Tue, 20 Apr 2021 23:37:15 GMT, Joe Darcy wrote:
> During the recent review of JDK-8228988, I noticed again the comments in the
> annotation parser about support for the pre-GA annotation format used before
> JDK 5.0 shipped. During the development of annotations, there was a late
> change t
On Sat, 8 May 2021 09:51:46 GMT, Rafael Winterhalter
wrote:
>> This improves the messages that are provided by
>> `AnnotationTypeMismatchException`s. The message provided by
>> AnnotationTypeMismatchExceptions is deliberately undefined such that this
>> should not break any contract.
>
> Rafa
On Sat, 8 May 2021 09:51:46 GMT, Rafael Winterhalter
wrote:
>> This improves the messages that are provided by
>> `AnnotationTypeMismatchException`s. The message provided by
>> AnnotationTypeMismatchExceptions is deliberately undefined such that this
>> should not break any contract.
>
> Rafa
On Wed, 9 Jun 2021 10:02:35 GMT, Rafael Winterhalter
wrote:
>> This improves the messages that are provided by
>> `AnnotationTypeMismatchException`s. The message provided by
>> AnnotationTypeMismatchExceptions is deliberately undefined such that this
>> should not break any contract.
>
> Rafa
On Thu, 10 Jun 2021 08:29:46 GMT, Rafael Winterhalter
wrote:
>> If a type is changed from a type that can be a member of an annotation which
>> is used in an array, changing it to a type that cannot be an array member
>> will be treated as if the type is an annotation type. As a result, no
>>
On Thu, 10 Jun 2021 08:36:42 GMT, Rafael Winterhalter
wrote:
>> During annotation parsing, the parser assumes that a declared property is of
>> an array type if the parsed annotation property is defined as an array. In
>> this case, the component type is `null`, and a `NullPointerException` is
On 10/15/2012 12:34 AM, David Holmes wrote:
> Remi,
>
> This ship has sailed you can't recall it. CloneNotSupportedException
> is a checked exception and needs to remain so for source and binary
> compatibility.
>
I see how this is source incompatible and also behaviorally incompatible
in a fe
t; AnnotationSuport.java:
>
>208 }catch (Throwable t) { // from
> InvocationHandler::invoke
>
> Thanks,
>
> -Joe
>
> On 3/28/2015 3:24 AM, Joel Borggrén-Franck wrote:
>> Hi,
>>
>>> On 27 Feb 2015, at 11:06, Peter Levart wrote:
>
Hi,
When reflecting over annotated types, there is currently no way to get
the potentially annotated owner of a type. For example, given you have
an instance of '@A Outer . @B Inner' you can't traverse it to get '@A
Outer' .
This API addition fixes this. Because both parameterized and
non-generic
Looks good to me.
In an unmodularized world I would think twice before adding the
hotspot specific tags.
(I'm not a HotSpot Reviewer).
cheers
/Joel
On Mon, Nov 16, 2015 at 11:41 PM, Christian Thalinger
wrote:
> [CC'ing core-libs-dev]
>
>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
>> wro
return new LocationInfo(depth, res);
> }
> return l;
> }
>
> Not a reviewer, easy to ignore. :-)
>
> /Claes
>
>
> On 2015-11-17 20:15, Joel Borggrén-Franck wrote:
>>
>> Hi,
>>
>> When reflecting over annotated types, th
Hi Paul,
See inline,
On Mon, 7 Dec 2015 at 21:39 Paul Benedict wrote:
> Joel, some comments on AnnotatedType#getAnnotatedOwnerType():
>
> * Is it convention to use tags to describe the complexity of the
> return value vs. just explaining it all in the @return tag?
>
> It is for the Core Reflec
Hi Joe,
Inline,
On Thu, 10 Dec 2015 at 02:09 Joseph D. Darcy wrote:
> Hi Joel,
>
> For the specification, it should seem reasonable to me to have the
> default implementation of AnnotatedType.getAnnotatedOwnerType() to
> return null rather than throwing an UnsupportedOperationException.
>
I di
Hi Joe,
Thanks for the comments,
On Thu, 10 Dec 2015 at 22:18 joe darcy wrote:
> Hi Joel,
>
> On 12/10/2015 12:27 PM, Joel Borggrén-Franck wrote:
>
> Question, is it better to remove the throws clauses for the cases that
> return null?
>
>
> I think so; they aren
Hi Chris,
I'm somewhat surprised to see ReflectionFactory on that list. Can you share
more details around its external use?
cheers
/Joel
On Tue, 15 Dec 2015 at 16:15 Chris Hegarty wrote:
> Paul,
>
> I cannot address your general question, but I guess it might be motivated
> by some of my recen
gt; approved in a day or two.
>
> Once that is approved, I think the current version can be pushed, enabling
> the refactorings you've alluded to to occur later.
>
> Thanks,
>
> -Joe
>
>
> On 12/13/2015 12:26 PM, Joel Borggrén-Franck wrote:
>
> Hi Joe,
>
&g
Thanks, change has been pushed.
cheers
/Joel
On Wed, 16 Dec 2015 at 18:53 joe darcy wrote:
> Hi Joel,
>
> FYI, ccc request now approved; thanks,
>
> -Joe
>
>
> On 12/16/2015 1:15 AM, Joel Borggrén-Franck wrote:
>
> Sounds good.
>
> I'll ping someone i
Hi Claes,
src/java.base/share/classes/java/lang/reflect/Parameter.java
src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java
src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
looks fine to me.
src/java.base/share/classes/java/lang/Class.java
is f
Do you know if it is only newConstructorForSerialization? Is it worth
keeping a minimal ReflectionFactory in sun.reflect that only exposes
that?
On Wed, Dec 16, 2015 at 1:22 PM, Chris Hegarty wrote:
> On 15/12/15 18:56, Joel Borggrén-Franck wrote:
>>
>> Hi Chris,
>>
>>
Hi Liam,
I think you need to do skipMemberValue the correct number of times so
that the cursor in buf is correct, or?
I modified your test slightly to provoke an
AnnotationTypeMismatchException that I think shouldn't be there:
@AnnotationAnnotation({@ClassArrayAnnotation({Missing.class, String.c
Hi,
Thanks for the patch, but this isn't a bug.
If you look in the Java Virtual Machine Specification 4.7.20.2. The
type_path structure [1] you can see that you haven't annotated the
array but the component type String. You can expand your test slightly
to see this:
public class AnnotationTest {
ke sure
it reaches the right people.
cheers
/Joel
On Thu, Jan 7, 2016 at 7:59 PM, Liam Miller-Cushon wrote:
> Hi Joel -
>
> On Tue, Jan 5, 2016 at 1:16 PM, Joel Borggrén-Franck
> wrote:
>>
>> I think you need to do skipMemberValue the correct number of times so
>> tha
Hi Liam,
Sorry for the delay,
On Sat, 30 Jan 2016 at 04:45 Liam Miller-Cushon wrote:
> On Thu, Jan 28, 2016 at 11:50 AM, Joel Borggrén-Franck <
> [email protected]> wrote:
>
> But, the reason we didn't fix this the last two times we looked at it
>>
Hi Andrej,
Can you resend the latest patch attached to a mail to this list?
cheers
/Joel
On 2014-08-29, Andrej Golovnin wrote:
> Hi Joel,
>
> >> I have changed the test TestMethodReflectValueOf as you suggested and I
> >> have changed the summary of both tests too. You will find the changes in
Hi,
I pushed this two days ago. Thank you Andrej for the contribution!
cheers
/Joel
On 9 sep 2014, at 11:21, Joel Borggrén-Franck wrote:
> Hi Andrej,
>
> Can you resend the latest patch attached to a mail to this list?
>
> cheers
> /Joel
>
> On 2014-08-29, Andrej Go
Hi,
Can I get a review for this anti-patch for JDK-8054984 (which is a backport
of JDK-8044629 "(reflect) Constructor.getAnnotatedReceiverType() returns wrong
value” to 8u).
The fix shouldn’t have been back ported, so this change reverts it in 8u only.
Webrev: http://cr.openjdk.java.net/~jfr
Thanks for the review Staffan!
cheers
/Joel
On 2014-09-18, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 18 sep 2014, at 11:00, Joel Borggrén-Franck wrote:
>
> > Hi,
> >
> > Can I get a review for this anti-patch for JDK-8054984 (w
Hi Martin,
On 23 okt 2014, at 00:53, Martin Buchholz wrote:
> Here at Google we have both kinds of scalability problems - loading classes
> from a classpath with 10,000 jars, and loading a single class file packed
> with the maximal number of methods. This message is about the latter.
>
> If y
On 23 Oct 2014, at 17:44, Peter Levart wrote:
>
> Is there a test that validates correctness of getMethods() or at least a set
> of interfaces and/or classes to exercise the algorithm and compare it to a
> different implementation?
>
There is :)
http://hg.openjdk.java.net/jdk9/dev/jdk/file/
Hi Peter,
As always, thanks for doing this! It has been on my todolist for a while but
never quite bubbling up to the top.
I don’t have time to look att his right now, but I expect to have some free
time next week, but i have two short comments
First, I have been thinking about moving MethodA
Hi Paul,
Sorry for the delay.
So if I understand this correctly, we get 4 warnings (and because of -Werror a
build failure) in langtools when compiling vs Jdk 9, but need the casts because
we bootstrap with Jdk 8.
Looks good to me but I would prefer if you filed a bug on me for Jdk 10 for
rem
void I.m()
>
> B.class.getMethods(): [public default void J.m()]
> B.class.getMethod("m"): public abstract void I.m()
>
> B.class.getMethods() reports default method J.m() (which I think is correct),
> but B.class.getMethod("m") reports the abstract I.m() inhe
Hi Peter,
On 29 Oct 2014, at 18:16, Peter Levart wrote:
> On 10/29/2014 02:08 PM, Joel Borggrén-Franck wrote:
>> Hi Peter,
>>
>> I’m not entirely convinced this is a bug.
>>
>> The lookup order for getMethod has for a long time been walk up superclasses
Hi Eric,
I think caching the real parameter type array on Executable is the wrong thing
to do considering we can have a lot of instances of Executable but fairly few
will be examined for parameters and the vast majority of those will never have
this issue.
Also, the tests are a bit minimal, I
Hi,
I’m having a hard time following this thread, which webrev has been updated,
for which release, fixing which issue?
Martin, as far as I can see you are the only one of us who has replied to this
thread who is a jdk7u committer (or reviewer).
I think the assumption is that generic repositor
Hi Martin,
Thanks for the clarification.
On 6 nov 2014, at 20:51, Martin Buchholz wrote:
> Hi Joel,
>
> On Thu, Nov 6, 2014 at 2:48 AM, Joel Borggrén-Franck
> wrote:
>> Hi,
>>
>> I’m having a hard time following this thread, which webrev has been updated,
>
;Thanks for volunteering. I foisted all I have in
> >
> >https://bugs.openjdk.java.net/browse/JDK-8064391
> >
> >I volunteer to be your reviewer for the backports.
> >
> >On Fri, Nov 7, 2014 at 1:36 PM, Joel Borggrén-Franck
> > wrote:
> >>Hi Martin,
&g
plied your fixes and re-upped the webrev.
>
> On 11/05/14 10:10, Joel Borggrén-Franck wrote:
> > Hi Eric,
> >
> > I think caching the real parameter type array on Executable is the wrong
> > thing to do considering we can have a lot of instances of Executable but
> &
Approved
thanks Eric,
cheers
/Joel
On 2014-11-10, Eric McCorkle wrote:
> Ok, the test has been revised as you suggested.
>
> A new version is posted (webrev.03).
>
> On 11/10/14 06:45, Joel Borggrén-Franck wrote:
> > Hi Eric,
> >
> > The changes to Executa
Hi Peter,
As always, thanks for taking a look at this,
This is quite big so in order to make this more approachable perhaps you can
split the patch up into a series? If you start with creating the MethodTable
interface, adding tests for how the interface should behave and refactored the
curren
, 2014 at 1:36 PM, Joel Borggrén-Franck
> wrote:
> > Hi Martin,
> >
> > Thanks for the clarification.
> >
> > On 6 nov 2014, at 20:51, Martin Buchholz wrote:
> >
> >> Hi Joel,
> >>
> >> On Thu, Nov 6, 2014 at 2:48 AM, Joel Borg
tionRaces/webrev.01/
>
> Mainly the fact that lazy initialization uses arrays which are published
> unsafely.
>
> Would this need a separate issue. For example: "Core reflection should use
> volatile fields whenever necessary" ?
>
>
> Regards, Peter
>
On 2014-11-13, Martin Buchholz wrote:
> Hi Joel, Joe, Paul,
>
> I'd like you to do a code review.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-volatile/
> https://bugs.openjdk.java.net/browse/JDK-8064846
Looks good. I think Aleksey's version removing 'sis' is a bit nea
Hi,
> On 14 Nov 2014, at 22:48, Martin Buchholz wrote:
>
> On Fri, Nov 14, 2014 at 9:32 AM, Peter Levart wrote:
>> Hi Martin,
>>
>> I dont know if you saw https://bugs.openjdk.java.net/browse/JDK-8064517 (a
>> followup to your fix for final fields). It would be best to merge those
>> fixes, wh
Hi,
> On 20 Nov 2014, at 16:33, Peter Levart wrote:
>
> Hi Martin,
>
> On 11/19/2014 01:42 AM, Martin Buchholz wrote:
>> Hi Joe, Peter, Paul
>>
>> This is the followup on thread safety I promised Peter.
>
> Looks good.
+1
>
> I made the WildcardTypeImpl.[upperBoundASTs, lowerBoundASTs] an
> On 24 Nov 2014, at 16:36, Peter Levart wrote:
>
> On 11/24/2014 04:04 PM, Joel Borggrén-Franck wrote:
>>
>> Btw, has anyone seen the assert for upper/lower bounds == null fail in the
>> wild?
>>
>> private FieldTypeSignature[] getUpperBoundASTs() {
ct/generics/scope/AbstractScope.java
>> src/share/classes/sun/reflect/generics/tree/ClassSignature.java
>>
>> Sincerely yours,
>> Ivan
>>
>>
>>
>> On 10.11.2014 12:00, Joel Borggrén-Franck wrote:
>>>
>>> That would be great
>
Hi Martin,
Looks good. I also think the code is easier to read now.
Thanks for switching back to a version with racy but correct initialization. As
Peter wrote, there are many cases where we don’t guarantee == on Type
instances. I can see why that would be desirable, but that is a separate
dis
Looks good.
cheers
/Joel
> On 15 jan 2015, at 13:32, Claes Redestad wrote:
>
> Hi,
>
> please review this patch to use double-checked locking to avoid
> synchronization overhead on repeated access to the
> declaredAnnotations field in Executable and Field.
>
> webrev: http://cr.openjdk.java.n
Hi Joe,
Nits,
152 * "void". If this {@code Class} object presents an array type,
153 * this method returns "class " followed by {@code getName}.
line 152, presents or represents?
Personally I would add a test for a 2-dim array of a generic type.
cheers
/Joel
> On 15 jan 2015, at 0
Hi
Good question, but javac should be fine. I had to look it up, but there is
logic to omit super() when generating the default ctor for Object
(TypeEnter::DefaultConstructor), and also logic for omitting super() if we are
compiling an explicit ctor for Object (Attr::visitMethodDef).
Looks goo
Hi,
> On 03 Feb 2015, at 10:15, Staffan Larsen wrote:
>
> Hi,
>
> Please review this patch for hiding the lambda proxy frame in stack traces:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8025636
> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/
>
> This is a straightforward ad
+1
cheers
/Joel
> On 16 Feb 2015, at 15:25, Staffan Larsen wrote:
>
> Good point!
>
> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/
>
> Thanks,
> /Staffan
>
>> On 16 feb 2015, at 12:40, Remi Forax wrote:
>>
>> Hi Staffan,
>> ASM MethodVisitor API requires to call visitAnno
Hi,
Here is a fix for an issue with repeating annotations when a security manager
is set.
Fix is to use the Proxy invocation handler to unwrap the array containing the
repeating annotations. In theory it might be possible to have instances of
Annotations that are not implemented using Proxies,
o wrap the call
> to m.setAccessible in a doPriv block instead?
>
> Paul.
>
> On Feb 24, 2015, at 11:49 AM, Joel Borggrén-Franck
> wrote:
>
>> Hi,
>>
>> Here is a fix for an issue with repeating annotations when a security
>> manager is set.
>>
Hi,
> On 25 feb 2015, at 13:16, Paul Sandoz wrote:
> On Feb 25, 2015, at 12:59 PM, Joel Borggrén-Franck
> wrote:
>
>> Hi Paul,
>>
>> Yes that would indeed be possible, but after some internal discussions we
>> though it safer to reuse the Proxy i
Hi Peter,
> On 25 feb 2015, at 15:48, Peter Levart wrote:
>
>
> On 02/25/2015 03:26 PM, Peter Levart wrote:
>> Ah, never mind. I missed the explicit access check that getEnclosingMethod()
>> already performs on it's own before calling getDeclaredMethods(). But the
>> check is for the same per
Hi Mandy,
> On 25 feb 2015, at 23:19, Mandy Chung wrote:
>
>
> On 2/25/2015 5:19 AM, Joel Borggrén-Franck wrote:
>> InvocationHandler::invoke unfortunately throws Throwable, but I restructured
>> it a bit so it is easier to follow.
>>
>> http://cr.openjdk
Hi,
> On 25 feb 2015, at 16:32, Peter Levart wrote:
> On 02/25/2015 04:10 PM, Joel Borggrén-Franck wrote:
>> Hi Peter,
>>
>>
>>> On 25 feb 2015, at 15:48, Peter Levart
>>> wrote:
>>>
>>>
>>> On 02/25/2015 03:26 PM, Peter
Hi Mandy, Paul,
Thanks for the reviews!
cheers
/Joel
> On 24 feb 2015, at 12:26, Joel Borggrén-Franck wrote:
>
> Hi,
>
> Here is a fix for an old issue with Class.getEnclosingMethod() and
> Class.getEnclosingConstructor(). The problem is that we throw a spurious
> Acce
> On 26 feb 2015, at 22:35, Peter Levart wrote:
> On 02/26/2015 10:27 PM, Peter Levart wrote:
>> The m.setAccessible(true) for the methods is needed to access methods of
>> non-public annotations, right? This call could be moved to AnnotationType
>> constructor as there it will be performed onl
Hi,
> On 27 feb 2015, at 01:04, Mandy Chung wrote:
>
> On 2/26/15 1:27 PM, Peter Levart wrote:
>>
>> On 02/26/2015 05:34 PM, Mandy Chung wrote:
The problem is with the default method
AnnotatedElement::getDeclaredAnnotationsByType. If someone has an external
implementation of An
Hi,
> On 27 Feb 2015, at 11:06, Peter Levart wrote:
> On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote:
>>> On 26 feb 2015, at 22:35, Peter Levart
>>> wrote:
>>> On 02/26/2015 10:27 PM, Peter Levart wrote:
>>>
>>>> The m.setAccessibl
> On 28 Mar 2015, at 13:42, Peter Levart wrote:
> On 03/28/2015 11:24 AM, Joel Borggrén-Franck wrote:
>> Hi,
>>
>>
>>> On 27 Feb 2015, at 11:06, Peter Levart
>>> wrote:
>>> On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote
Mandy, Paul, what do you think?
cheers
/Joel
> On 28 Mar 2015, at 11:24, Joel Borggrén-Franck wrote:
>
> Hi,
>
>> On 27 Feb 2015, at 11:06, Peter Levart wrote:
>> On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote:
>>>> On 26 feb 2015, at 22:35, Peter Le
Hi Joe,
Good to see this happening. In general looks good to me, a few nits below.
AnnotatedTypeBaseImpl contains comments indicating from which
superclass or interface the overridden methods comes. I'd either add
// Object at line 207 or delete line 145 and 177 for consistency.
Even though this
ts below.
>
>
> On 10/9/2018 11:00 AM, Joel Borggrén-Franck wrote:
> > Hi Joe,
> >
> > Good to see this happening. In general looks good to me, a few nits
> below.
> >
> > AnnotatedTypeBaseImpl contains comments indicating from which
> > superclass or
Hi Joe,
I suspect you pasted the wrong link, link to updated impl ends in 8212081.2
right? Anyhow, the .2 version looks good. Ship it!
Cheers
/Joel
/Joel
On Fri, 26 Oct 2018 at 04:03, joe darcy wrote:
> PS Re-refined implementation at
>
> http://cr.openjdk.java.net/~darcy/8212081.1/
>
> T
Hi Liam,
This makes sense to me. Since nestingForType is used to navigate
scoping/nesting in more cases than owner type and javac seem to be
inconsistent with regards to locations (see [1] for example), will
this break or fix something else?
[1] https://bugs.openjdk.java.net/browse/JDK-8148504
c
Hi Liam,
I read the spec bugs, we had a similar discussion a few years ago
about the scoping. Given how all implementations of javac have behaved
for the last 4 years or so, I agree this is the right fix. Thanks for
the extra test.
Ship it!
cheers
/Joel
On Wed, Dec 19, 2018 at 8:19 PM Liam Mill
Hi Joe!
Looks good to me. Looking at the summary by the end of your mail I guess
this is the only subtype that needs fixing?
Cheers
/Joel
On Wed, 29 May 2019 at 07:52, Joe Darcy wrote:
> Hello,
>
> Please review the changes to address:
>
> JDK-8224012: AnnotatedType implementations of has
1 - 100 of 209 matches
Mail list logo
