Just to follow up on this with a little more info, I've put together a small example that demonstrates the issue I'm seeing.

Consider this class "Outer", which includes an inner class "Inner":

public class Outer { public static Inner getAnInner(){ return new Inner(); } static class Inner{ public Inner(){ } public void innerm(){ System.out.println("called innerm"); } } }

In Java, I can instantiate Inner and call its public methods, as in the following:

public class TestMain { public static void main(String[] args){ Outer.Inner myinner = new Outer.Inner(); myinner.innerm(); } }

However, in ABCL 1.0.1:

CL-USER(1): (jnew "Outer$Inner") #<THREAD "interpreter" {7FB5438D}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.IllegalAccessException: Class org.armedbear.lisp.Java$pf_jnew can not access a member of class Outer$Inner with modifiers "public"'.

I can still get an instance to play with:

CL-USER(3): (jstatic "getAnInner" "Outer") #<Outer$Inner Outer$Inner@67df02c9 {62300F65}>

… but I can't call its public methods:

CL-USER(6): (jcall "innerm" (jstatic "getAnInner" "Outer")) #<THREAD "interpreter" {7FB5438D}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.IllegalAccessException: Class org.armedbear.lisp.Java can not access a member of class Outer$Inner with modifiers "public"'.

… unless I use JSS and with-constant-signature

CL-USER(7): (require :abcl-contrib) CL-USER(8): (require :jss) CL-USER(9): (jss::ensure-compatibility) CL-USER(10): (with-constant-signature ((innerm "innerm")) (innerm (jstatic "getAnInner" "Outer")) ) called innerm NIL

Any help getting to the bottom of this would be greatly appreciated.

Regards, Jonathan

On Tue, Jul 31, 2012 at 10:06 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:

Hey guys,

Have any of you had a chance to look into this? This is a showstopper for me using the latest ABCL as I have basic infrastructure code that is failing.

Would much appreciate someone having a look.

Thanks, Alan

On Thu, Jul 19, 2012 at 3:54 PM, Jonathan P. Bona jonathanbona@gmail.com wrote:

...

Hello,

We found this issue while working with LSW. It seems to be a bug in how public methods are found for inner classes. The last line of code below results in an exception rather than finding and running the size() method:

;;;---------------- (require :abcl-contrib) (require :jss) (jss::ensure-compatibility) (setq headers (#"getHeaderFields" (#"openConnection" (jss::new 'java.net.url "http://google.com"))))

; a java.util.Collections$UnmodifiableRandomAccessList (setq ural (#"get" headers (second (jss::set-to-list (#"keySet" headers)))))

;finds: #<method public int java.util.Collections$UnmodifiableCollection.size()> (find "size" (#"getMethods" (#"getClass" ural) ) :test 'string-equal :key #"getName")

; Java exception 'java.lang.NoSuchMethodException: No applicable method named size found in java.lang.Object or java.util.Collections$UnmodifiableRandomAccessList'. (#"size" ural) ;;;----------------

I chased this into org.armedbear.lisp.Java, where findMethod is returning null.

• Jonathan Bona

---

armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

On 8/1/12 7:03 AM, Alan Ruttenberg wrote:

Well, that's cute. with constant signature expands into a call to jss:invoke-find-method called with the arguments to the first function call, saves that, and subsequently always uses jcall to call that specific method. The lookup calls jresolve method then setAccessible on the result. Perhaps it is the setAccessible that is doing the magic?

You should svn update - I've committed some changes elsewhere. I'm dealing with an annoyance - I updated abcl to trunk and am trying java 1.7. I get a startup (fatal) error unless I first delete the slime/swank compiled files. No clue what that's about. If you want you can see if you can reproduce and then file a report. Otherwise I'll get to it.

The java 1.7 I get from the Oracle site.

Work on the CLOS/AMOP has created weird errors that require removing fasls over the past several months, but it seems to have stablized somewhat across revisions. So, please, if something stops working in mysterious ways across svn revs, please do a full rebuild (and get take a break) while you recursively remove "~/.slime" and "~/.cache" before you tear too much hair out.

I've been able to reproduce on oracle-jdk-1.7.0_05 running on x86_64-osx-10.8 so have filed this as [ticket #229][#229].

[#229]: http://trac.common-lisp.net/armedbear/ticket/229

@Alan: I'd appreciate you checking my logic on JSS:WITH-CONSTANT-SIGNATURE, as you can see from [r13937] when I fixed [#205], my previous understanding of what that macro should do was completely (and dangerously wrong).

I will try to get some cycles later today to at this bug.

[r13937]: http://trac.common-lisp.net/armedbear/changeset/13937 [#205]: http://trac.common-lisp.net/armedbear/ticket/205

On Mon, Aug 6, 2012 at 7:33 AM, Alessio Stalla alessiostalla@gmail.comwrote:

Please see http://ale20.wordpress.com/2010/01/13/java-reflection-non-public-inner-class...

I believe it's an instance of that. At that time, I introduced "intended class" + jcoerce to work around that, but I'm not sure about it anymore; setAccessible(true) is a better strategy, imho. It is perhaps trickier to implement correctly (when exactly to call setAccessible(true)?

Always. (unless hashing is cheaper than the call, in which case once per method and cache the methods that have been set)

What about security exceptions ?)

You get the exception and deal with it. If you really want to call the method you modify the security policy for your machine.

but more predictable by the user.

Certainly this user ;-)

-Alan

Alessio

On Wed, Aug 1, 2012 at 7:56 AM, Mark Evenson evenson@panix.com wrote:

...

On 8/1/12 7:03 AM, Alan Ruttenberg wrote:

...

Well, that's cute. with constant signature expands into a call to jss:invoke-find-method called with the arguments to the first function call, saves that, and subsequently always uses jcall to call that specific method. The lookup calls jresolve method then setAccessible on the result. Perhaps it is the setAccessible that is doing the magic?

You should svn update - I've committed some changes elsewhere. I'm dealing with an annoyance - I updated abcl to trunk and am trying java 1.7. I get a startup (fatal) error unless I first delete the slime/swank compiled files. No clue what that's about. If you want you can see if you can reproduce and then file a report. Otherwise I'll get to it.

The java 1.7 I get from the Oracle site.

Work on the CLOS/AMOP has created weird errors that require removing

fasls

...

over the past several months, but it seems to have stablized somewhat

across

...

revisions. So, please, if something stops working in mysterious ways

across

...

svn revs, please do a full rebuild (and get take a break) while you recursively remove "~/.slime" and "~/.cache" before you tear too much

hair

...

out.

I've been able to reproduce on oracle-jdk-1.7.0_05 running on x86_64-osx-10.8 so have filed this as [ticket #229][#229].

@Alan: I'd appreciate you checking my logic on

JSS:WITH-CONSTANT-SIGNATURE,

...

as you can see from [r13937] when I fixed [#205], my previous

understanding

...

of what that macro should do was completely (and dangerously wrong).

I will try to get some cycles later today to at this bug.

--

"A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

---

armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

-- Some gratuitous spam:

http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework

---

armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel