Yep, that's true for SM, but although modification of final field is a well known practice, the result is pretty much unpredictable, writings in fact may fail silently (changes to an ex-final field may not be observed [1]).
My idea is to add a method called /removeFinalModifier/ and then give to the user the choice to use in combination with /writeField/: removeFinalModifier(field); writeField(field); WDYT? Maurizio Cucchiara On 22 November 2013 19:08, Matt Benson <gudnabr...@gmail.com> wrote: > 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 >> >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
