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 t
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
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 parti
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 "f
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'
para
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 wro
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
>
>
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)
Maurizio Cucchiara
On 22 November 2013 13:37, Matt Benson wrote:
> Hmm, I would have expected [1] (with terminating argument true) to have
> work
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)
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 se
