Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v5]

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`

Re: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v4]

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

Re: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v4]

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. > >

Re: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v3]

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. > >

Re: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v3]

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. > >

Re: RFR: 8265591: Remove vestiages of intermediate JSR 175 annotation format

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

Re: RFR: 8265174: Update Class.getDeclaredMethods to discuss synthetic and bridge methods [v2]

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

Re: RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices [v3]

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

Re: RFR: 8169629: Annotations with lambda expressions cause AnnotationFormatError

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

Re: RFR: 8263333: Improve links from core reflection to JLS and JVMS

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

Re: [jdk16] RFR: 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes [v2]

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

[jdk16] Integrated: 8256693: getAnnotatedReceiverType parameterizes types too eagerly

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

Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2]

n't the 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 incr

Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2]

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

Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly

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 >>

[jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly

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

Re: RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly

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. >

Withdrawn: 8256693: getAnnotatedReceiverType parameterizes types too eagerly

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

Re: RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2]

n't the 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 unrel

Re: RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly

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

RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly

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

Re: RFR: 8202471: (ann) Cannot read type annotations on generic receiver type's type variables [v7]

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:

Re: RFR: 8202471: (ann) Cannot read type annotations on generic receiver type's type variables [v7]

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

Re: RFR: 8202471: (ann) Cannot read type annotations on generic receiver type's type variables [v7]

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 >>

Re: RFR: 8202471: (ann) Cannot read type annotations on generic receiver type's type variables [v6]

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 >>

Re: RFR: 8202471: Make type annotations on owner type parameters available [v4]

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 >>

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod…

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

Re: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation [v2]

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

Re: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation

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 @

Re: RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation

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:

Re: 8202469 / 8202473: Correct type annotation resolution for class type variables

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 < > joel.borggren.fra...@gmail.com>: > >> Many thanks to Vicente for sponsorin

Re: 8202469 / 8202473: Correct type annotation resolution for class type variables

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 < joel.borggren.fra...@gmail.com> wrote: > Looks good to me! > > I'll see if I can find a sponsor for this. > > chee

Re: 8202469 / 8202473: Correct type annotation resolution for class type variables

a.net/~winterhalter/8202469/webrev.01/ > > Thanks, Rafael > > Am So., 16. Feb. 2020 um 10:51 Uhr schrieb Joel Borggrén-Franck < > joel.borggren.fra...@gmail.com>: > >> Hi Rafael, >> >> Thanks for reaching out and reminding me of this! >> >> I manage

Re: 8202469 / 8202473: Correct type annotation resolution for class type variables

hing there. >> Best regards, Rafael >> >> Am Fr., 2. Aug. 2019 um 11:59 Uhr schrieb Daniel Fuchs < >> daniel.fu...@oracle.com>: >> >>> Hi Rafael, >>> >>> On 02/08/2019 09:00, Joel Borggrén-Franck wrote: >>> > I can host we

Re: 8202469 / 8202473: Correct type annotation resolution for class type variables

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

Re: JDK 13 RFR of JDK-8224012: AnnotatedType implementations of hashCode() lead to StackOverflowError

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

Re: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly

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

Re: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly

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

Re: JDK 12 RFR of JDK-8212081: AnnotatedType.toString implementation don't print annotations on embedded types

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/ > >

Re: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode()

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

Re: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode()

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

Re: RFR: 8029019: (ann) Optimize annotation handling in core reflection

This looks fine to me. None of the gotchas I could remember that may or may not apply to Peters bigger change applies to this one. You should get a second opinon from Joe or Peter though. cheers /Joel On Tue, 10 Oct 2017 at 20:02 Christoph Dreis wrote: > Hi Claes,

Re: Guaranteed order of annotations?

Iirc there are no guatantees but we try as best as we can to maintain source code order. It has been a couple of years now but I think there are a few corner cases with repeating annotations. Cheers /Joel On Fri, 13 Jan 2017 at 18:14, Gunnar Morling wrote: > Hi, > > > >

Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

lassReceiverTypeBug > constructor=LocalClassReceiverTypeBug$1StaticLocal() receivertype=null > constructor=LocalClassReceiverTypeBug$1InstanceLocal(LocalClassReceiverTypeBug) > receivertype=null > constructor=LocalClassReceiverTypeBug$Inner(LocalClassReceiverTypeBug) > receivertype=sun.refl

Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

iver type=%s%n", > constructors[0].getAnnotatedReceiverType()); > } > } > > > > On Wed, Aug 13, 2014 at 1:54 AM, Joel Borggren-Franck < > joel.fra...@oracle.com> wrote: > >> Hi Paul, >> >> On 2014-06-24, Paul Sandoz

Re: JDK 9 RFR of JDK-8152174: Type annotations with a missing type throw NullPointerException

Looks good Joe. Cheers /Joel On Jul 7, 2016 07:49, "joe darcy" wrote: > Hello, > > Please review the changes to address > > JDK-8152174: Type annotations with a missing type throw > NullPointerException > http://cr.openjdk.java.net/~darcy/8152174.0/ > > In brief,

Re: JDK 9 RFR of JDK-5041778: (ann) AnnotationFormatError if "default" Class type not found

Looks good. I think I would have avoided the nested ifs and just tested for instanceof TypeNotPresentExceptionProxy directly but no big deal. cheers /Joel On Sat, Jun 11, 2016 at 11:30 PM, joe darcy wrote: > Hello, > > Please review these changes to address > >

Re: JDK 9 RFR of JDK-5040830: (ann) please improve toString() for annotations containing exception proxies

Ping! If the slightly irregular format wasn't intentional I think it is worth taking a second pass over this before the toString gets set in stone. On Wed, Jun 1, 2016 at 8:33 PM, Joel Borggrén-Franck <joel.borggren.fra...@gmail.com> wrote: > Hi Joe, > > I noticed you chose

Re: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior.

Hi, I think this was caught by the verifier before 8 since you couldn't have concrete or private methods in an interface. Now you can (though not in Java for private ones). My spider sense tells me there might be something lurking here (though it was a while since this was in my L1 cache). It is

Re: JDK 9 RFR of JDK-5040830: (ann) please improve toString() for annotations containing exception proxies

Hi Joe, I noticed you chose the old format for a type mismatch ("class java ...") and print the type name in the middle of the comment instead of before, why? Other than that, looks good! cheers /Joel On Tue, May 31, 2016 at 9:43 PM, joe darcy wrote: > Hello, > > Some

Re: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported

Hi Chris, FWIW changes looks good to me. cheers /Joel On Wed, 13 Apr 2016 at 17:43 Chris Hegarty wrote: > This review is for the second significant part of the changes for JEP > 260 [1]. When created, the jdk.unsupported module [2] initially > contained the sun.misc

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

Hi Liam, Sorry for the delay, On Sat, 30 Jan 2016 at 04:45 Liam Miller-Cushon <cus...@google.com> wrote: > On Thu, Jan 28, 2016 at 11:50 AM, Joel Borggrén-Franck < > joel.borggren.fra...@gmail.com> wrote: > > But, the reason we didn't fix this the last two times we lo

Re: [PATCH] 8140633: Method.getAnnotatedReturnType() returns empty annotations if return type is an array

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

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

hes the right people. cheers /Joel On Thu, Jan 7, 2016 at 7:59 PM, Liam Miller-Cushon <cus...@google.com> wrote: > Hi Joel - > > On Tue, Jan 5, 2016 at 1:16 PM, Joel Borggrén-Franck > <joel.borggren.fra...@gmail.com> wrote: >> >> I think you need to do skipMembe

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

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,

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

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

Re: General question: sun package -> jdk package?

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 <chris.hega...@oracle.com> wrote: > On 15/12/15 18:56, Joel Borggrén-Franck wrote: >&

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Thanks, change has been pushed. cheers /Joel On Wed, 16 Dec 2015 at 18:53 joe darcy <joe.da...@oracle.com> wrote: > Hi Joel, > > FYI, ccc request now approved; thanks, > > -Joe > > > On 12/16/2015 1:15 AM, Joel Borggrén-Franck wrote: > > Sounds good. &

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

ion of the spec; should be > 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: > &g

Re: General question: sun package -> jdk package?

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

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Hi Joe, Thanks for the comments, On Thu, 10 Dec 2015 at 22:18 joe darcy <joe.da...@oracle.com> 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? >

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

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

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

his.locations, 0, res, 0, depth); > 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, >> >> W

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

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

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

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

RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

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

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

of 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 peter.lev...@gmail.com wrote: On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

Mandy, Paul, what do you think? cheers /Joel On 28 Mar 2015, at 11:24, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi, On 27 Feb 2015, at 11:06, Peter Levart peter.lev...@gmail.com wrote: On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote: On 26 feb 2015, at 22:35, Peter Levart

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

On 28 Mar 2015, at 13:42, Peter Levart peter.lev...@gmail.com wrote: On 03/28/2015 11:24 AM, Joel Borggrén-Franck wrote: Hi, On 27 Feb 2015, at 11:06, Peter Levart peter.lev...@gmail.com wrote: On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote: On 26 feb 2015, at 22:35, Peter

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

Hi, On 27 Feb 2015, at 11:06, Peter Levart peter.lev...@gmail.com wrote: On 02/27/2015 10:27 AM, Joel Borggrén-Franck wrote: On 26 feb 2015, at 22:35, Peter Levart peter.lev...@gmail.com wrote: On 02/26/2015 10:27 PM, Peter Levart wrote: The m.setAccessible(true) for the methods

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

On 26 feb 2015, at 22:35, Peter Levart peter.lev...@gmail.com 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

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

Hi, On 27 feb 2015, at 01:04, Mandy Chung mandy.ch...@oracle.com 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

Re: RFR 8014678: Spurious AccessControlException thrown in java.lang.Class.getEnclosingMethod()

Hi, On 25 feb 2015, at 16:32, Peter Levart peter.lev...@gmail.com wrote: On 02/25/2015 04:10 PM, Joel Borggrén-Franck wrote: Hi Peter, On 25 feb 2015, at 15:48, Peter Levart peter.lev...@gmail.com wrote: On 02/25/2015 03:26 PM, Peter Levart wrote: Ah, never mind. I missed

Re: RFR 8014678: Spurious AccessControlException thrown in java.lang.Class.getEnclosingMethod()

Hi Mandy, Paul, Thanks for the reviews! cheers /Joel On 24 feb 2015, at 12:26, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi, Here is a fix for an old issue with Class.getEnclosingMethod() and Class.getEnclosingConstructor(). The problem is that we throw a spurious

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

Hi Mandy, On 25 feb 2015, at 23:19, Mandy Chung mandy.ch...@oracle.com 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.java.net/~jfranck/8073056

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

to wrap the call to m.setAccessible in a doPriv block instead? Paul. On Feb 24, 2015, at 11:49 AM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: 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

Re: RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

Hi, On 25 feb 2015, at 13:16, Paul Sandoz paul.san...@oracle.com wrote: On Feb 25, 2015, at 12:59 PM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi Paul, Yes that would indeed be possible, but after some internal discussions we though it safer to reuse the Proxy invocation

Re: RFR 8014678: Spurious AccessControlException thrown in java.lang.Class.getEnclosingMethod()

Hi Peter, On 25 feb 2015, at 15:48, Peter Levart peter.lev...@gmail.com 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

RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager

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

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

+1 cheers /Joel On 16 Feb 2015, at 15:25, Staffan Larsen staffan.lar...@oracle.com 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 fo...@univ-mlv.fr wrote: Hi Staffan, ASM MethodVisitor API

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

Hi, On 03 Feb 2015, at 10:15, Staffan Larsen staffan.lar...@oracle.com 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

Re: JDK 9 RFR of JDK-8071959: java.lang.Object uses implicit default constructor

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

Re: RFR: 8068736: Avoid synchronization on Executable/Field.declaredAnnotations

Looks good. cheers /Joel On 15 jan 2015, at 13:32, Claes Redestad claes.redes...@oracle.com 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:

Re: JDK 9 RFR of 8060077: Class.toGenericString specification doesn't mention array types

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

Re: RFR: 8065172: More core reflection final and volatile annotations

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

Re: RFR: 8062771: Core reflection should use final fields whenever possible

, Joel Borggrén-Franck wrote: That would be great cheers /Joel On 2014-11-09, Ivan Gerasimov wrote: Hi! I think I can handle the backport to jdk7, if you still need a volunteer. Sincerely yours, Ivan On 08.11.2014 1:48, Martin Buchholz wrote: Hi Joel, Thanks

Re: RFR: 8065172: More core reflection final and volatile annotations

Hi, On 20 Nov 2014, at 16:33, Peter Levart peter.lev...@gmail.com 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,

Re: RFR: 8065172: More core reflection final and volatile annotations

On 24 Nov 2014, at 16:36, Peter Levart peter.lev...@gmail.com 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() { // check that upper bounds

Re: RFR: 8064846: Lazy-init thread safety problems in core reflection

Hi, On 14 Nov 2014, at 22:48, Martin Buchholz marti...@google.com wrote: On Fri, Nov 14, 2014 at 9:32 AM, Peter Levart peter.lev...@gmail.com 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

Re: RFR: 8062771: Core reflection should use final fields whenever possible

and me as reviewer. cheers /Joel On 2014-11-07, Martin Buchholz wrote: Hi Joel, 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

Re: RFR: 8062771: Core reflection should use final fields whenever possible

arrays which are published unsafely. Would this need a separate issue. For example: Core reflection should use volatile fields whenever necessary ? Regards, Peter On Fri, Nov 7, 2014 at 1:36 PM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi Martin, Thanks

Re: RFR: 8062771: Core reflection should use final fields whenever possible

://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 joel.fra...@oracle.com wrote: Hi Martin, Thanks for the clarification. On 6 nov 2014, at 20:51, Martin Buchholz marti...@google.com wrote

Re: Review request for 8055063: Parameter#toString() fails w/ AIOOBE for ctr of inner class w/ generic type

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 fairly few will be examined for parameters and the vast majority

Re: Review request for 8055063: Parameter#toString() fails w/ AIOOBE for ctr of inner class w/ generic type

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 Executable.java and Parameter.java looks good

Re: RFR: 8062771: Core reflection should use final fields whenever possible

Hi Martin, Thanks for the clarification. On 6 nov 2014, at 20:51, Martin Buchholz marti...@google.com wrote: Hi Joel, On Thu, Nov 6, 2014 at 2:48 AM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi, I’m having a hard time following this thread, which webrev has been updated

Re: RFR: 8062771: Core reflection should use final fields whenever possible

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

Re: Review request for 8055063: Parameter#toString() fails w/ AIOOBE for ctr of inner class w/ generic type

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

Re: Loading classes with many methods is very expensive

() algorithm stops searching for and consolidating any methods in (super)interfaces. Do you agree that this is a bug? Regards, Peter On 10/27/2014 02:45 PM, Joel Borggrén-Franck wrote: Hi Peter, As always, thanks for doing this! It has been on my todolist for a while but never quite

Re: inconsistency between Class.getMethod and Class.getMethods Was: Loading classes with many methods is very expensive

Hi Peter, On 29 Oct 2014, at 18:16, Peter Levart peter.lev...@gmail.com 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 and return what you find

Re: Request for review/advice from langtools teamwas Re: Covariant overrides on the Buffer Hierarchy redux

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

  1   2   >