<br><br><div class="gmail_quote">On Mon, Aug 6, 2012 at 7:33 AM, Alessio Stalla <span dir="ltr"><<a href="mailto:alessiostalla@gmail.com" target="_blank">alessiostalla@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please see <a href="http://ale20.wordpress.com/2010/01/13/java-reflection-non-public-inner-class-bug/" target="_blank">http://ale20.wordpress.com/2010/01/13/java-reflection-non-public-inner-class-bug/</a><br>
<br>
I believe it's an instance of that. At that time, I introduced<br>
"intended class" + jcoerce to work around that, but I'm not sure about<br>
it anymore; setAccessible(true) is a better strategy, imho. It is<br>
perhaps trickier to implement correctly (when exactly to call<br>
setAccessible(true)? </blockquote><div><br></div><div>Always. (unless hashing is cheaper than the call, in which case once per method and cache the methods that have been set)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What about security exceptions ?)</blockquote><div><br></div><div>You get the exception and deal with it. If you really want to call the method you modify the security policy for your machine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but more predictable by the user.<br></blockquote><div><br></div><div> Certainly this user ;-)</div><div><br></div><div>-Alan</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Alessio<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Aug 1, 2012 at 7:56 AM, Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:<br>
> On 8/1/12 7:03 AM, Alan Ruttenberg wrote:<br>
>><br>
>> Well, that's cute.<br>
>> with constant signature expands into a call to jss:invoke-find-method<br>
>> called with the arguments to the first function call, saves that, and<br>
>> subsequently always uses jcall to call that specific method. The lookup<br>
>> calls jresolve method then setAccessible on the result. Perhaps it is<br>
>> the setAccessible that is doing the magic?<br>
>><br>
>> You should svn update - I've committed some changes elsewhere. I'm<br>
>> dealing with an annoyance - I updated abcl to trunk and am trying java<br>
>> 1.7. I get a startup (fatal) error unless I first delete the slime/swank<br>
>> compiled files. No clue what that's about. If you want you can see if<br>
>> you can reproduce and then file a report. Otherwise I'll get to it.<br>
>><br>
>> The java 1.7 I get from the Oracle site.<br>
><br>
><br>
> Work on the CLOS/AMOP has created weird errors that require removing fasls<br>
> over the past several months, but it seems to have stablized somewhat across<br>
> revisions. So, please, if something stops working in mysterious ways across<br>
> svn revs, please do a full rebuild (and get take a break) while you<br>
> recursively remove "~/.slime" and "~/.cache" before you tear too much hair<br>
> out.<br>
><br>
> I've been able to reproduce on oracle-jdk-1.7.0_05 running on<br>
> x86_64-osx-10.8 so have filed this as [ticket #229][#229].<br>
><br>
> [#229]: <a href="http://trac.common-lisp.net/armedbear/ticket/229" target="_blank">http://trac.common-lisp.net/armedbear/ticket/229</a><br>
><br>
> @Alan: I'd appreciate you checking my logic on JSS:WITH-CONSTANT-SIGNATURE,<br>
> as you can see from [r13937] when I fixed [#205], my previous understanding<br>
> of what that macro should do was completely (and dangerously wrong).<br>
><br>
> I will try to get some cycles later today to at this bug.<br>
><br>
> [r13937]: <a href="http://trac.common-lisp.net/armedbear/changeset/13937" target="_blank">http://trac.common-lisp.net/armedbear/changeset/13937</a><br>
> [#205]: <a href="http://trac.common-lisp.net/armedbear/ticket/205" target="_blank">http://trac.common-lisp.net/armedbear/ticket/205</a><br>
><br>
> --<br>
><br>
> "A screaming comes across the sky. It has happened before, but there is<br>
> nothing to compare it to now."<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> armedbear-devel mailing list<br>
> <a href="mailto:armedbear-devel@common-lisp.net">armedbear-devel@common-lisp.net</a><br>
> <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Some gratuitous spam:<br>
<br>
<a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
<a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
<a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
<a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
<a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
model-driven Java web application framework<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
armedbear-devel mailing list<br>
<a href="mailto:armedbear-devel@common-lisp.net">armedbear-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
</div></div></blockquote></div><br>