Well, the SecurityManager consideration applies for a lot of what goes on in oacl3.reflect. ;)
Matt On Fri, Nov 22, 2013 at 11:37 AM, Maurizio Cucchiara <mcucchi...@apache.org>wrote: > NP, > > I can file a jira and (I can submit a patch or the code into the trunk). > (I had already the code, nothing special or particularly complex, but > at least work in production). > > For what concerns the use of the existing method, the "forceAccess" > parameter could be misleading, since the magic of "force", in this > case, could not be enough (SecurityManager enabled or primitive type). > Maurizio Cucchiara > > > On 22 November 2013 17:15, Matt Benson <gudnabr...@gmail.com> wrote: > > Sorry, I was thinking about the idea of extending final classes that can > be > > done by manipulating bytecode even though the compiler restricts it. Can > > you open a JIRA issue for this? I would say we could stuff this into the > > existing method as part of the behavior specified by the 'forceAccess' > > parameter; does anyone else prefer a specific method or parameter for > this? > > > > Matt > > > > > > On Fri, Nov 22, 2013 at 11:06 AM, Maurizio Cucchiara > > <mcucchi...@apache.org>wrote: > > > >> Hi Jorg, > >> actually I have already done: it doesn't work (but I could be wrong). > >> > >> So to recap, writing a private field works, a final one don't. > >> > >> IMHO adding a method that allows to write a static final field makes > >> sense to me, WDYT? > >> > >> Maurizio Cucchiara > >> > >> > >> On 22 November 2013 16:01, Jörg Schaible <joerg.schai...@scalaris.com> > >> wrote: > >> > Hi Maurizio, > >> > > >> > Maurizio Cucchiara wrote: > >> > > >> >> So do I, but looking at the throws list it seems that final is not > >> >> supported (although write a private one is) by design (which can be a > >> >> valid point) > >> > > >> > Try it. The documentation might be a simple relict from Java 1.4 > >> > functionality. > >> > > >> > Cheers, > >> > Jörg > >> > > >> >> > >> >> Maurizio Cucchiara > >> >> > >> >> > >> >> On 22 November 2013 13:37, Matt Benson <gudnabr...@gmail.com> wrote: > >> >>> Hmm, I would have expected [1] (with terminating argument true) to > have > >> >>> worked for your purposes. > >> >>> > >> >>> Matt > >> >>> [1] > >> >>> > >> > http://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/reflect/FieldUtils.html#writeStaticField(java.lang.Class > >> , > >> >>> java.lang.String, java.lang.Object, boolean) > >> >>> On Nov 22, 2013 3:49 AM, "Maurizio Cucchiara" < > mcucchi...@apache.org> > >> >>> wrote: > >> >>> > >> >>>> Hi all, > >> >>>> > >> >>>> yesterday I was trying to write a static final field in order to > mock > >> >>>> it and I realised that there is no way to do that using the Common > >> >>>> way. > >> >>>> > >> >>>> I expected to find something similar on FieldUtils class [1]. > >> >>>> > >> >>>> I know that is not a very good practice and in case of primitive > field > >> >>>> or enabled security manager it is unlikely that works. > >> >>>> > >> >>>> But it seems a common pattern, so why do not include in Lang? > >> >>>> > >> >>>> Maurizio Cucchiara > >> >>>> > >> >>>> [1] > >> >>>> > >> > http://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/reflect/FieldUtils.html > >> >>>> > >> >>>> > --------------------------------------------------------------------- > >> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >>>> > >> >>>> > >> > > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> >
