armedbear / abcl

Armed Bear Common Lisp <git+https://github.com/armedbear/abcl/> <--> <svn+https://abcl.org/svn> Bridge
https://abcl.org#rdfs:seeAlso<https://gitlab.common-lisp.net/abcl/abcl>
Other
292 stars 30 forks source link

jnew-runtime-class fails with constructor exception #685

Open lazy-macro-macaroni opened 2 weeks ago

lazy-macro-macaroni commented 2 weeks ago

If I try to run just the smallest version of jnew-runtime-class, it doesn't work:

CL-USER(1): (jnew-runtime-class "haha")
#<THREAD "interpreter" native {7A6E8E2D}>: Debugger invoked on condition of type JAVA-EXCEPTION
  Java exception: #<java.lang.NoSuchMethodException java.lang.NoSuchMethodException:.... {3A2F243B}>.
Restarts:
  0: TOP-LEVEL Return to top level.
[1] CL-USER(2):

What's going on?

lazy-macro-macaroni commented 2 weeks ago

Tried oracle java 21, and adoptium 17, same result.

easye commented 2 weeks ago

Hmmm, it seems to work for me

CL-USER(1): (jnew-runtime-class "haha")
#<java class haha>
CL-USER(2): (describe *)
#<java.lang.Class class haha {5C13EBA2}> is an object of type JAVA-OBJECT.
The wrapped Java object is an instance of java.lang.Class:
  "class haha"
CL-USER(3): (lisp-implementation-version)
"1.9.2"
"OpenJDK_64-Bit_Server_VM-MacPorts-21.0.5+11"
"aarch64-Mac_OS_X-14.7.1"

I also tried this under openjdk17.

The method which cannot be found is being elided by the default printing length of Java Strings.

Can you try setting **java-object-to-string-length** to something like

(setf *java-object-to-string-length* 1024)

and report the results?

lazy-macro-macaroni commented 2 weeks ago
CL-USER(1): (setf *java-object-to-string-length* 1024)
1024
CL-USER(2): (jnew-runtime-class "haha")
#<THREAD "interpreter" native {4E3AAD4F}>: Debugger invoked on condition of type JAVA-EXCEPTION
  Java exception: #<java.lang.NoSuchMethodException java.lang.NoSuchMethodException: MemoryClassLoader(jdk.internal.loader.ClassLoaders$AppClassLoader) {2EAF6014}>.
Restarts:
  0: TOP-LEVEL Return to top level.
[1] CL-USER(3):

Thanks for answer. But unfortunately is the same. Tried abcl 1.9.2 and 1.6.1, same result.

CL-USER(1): (lisp-implementation-version)
"1.9.2"
"OpenJDK_64-Bit_Server_VM-Eclipse_Adoptium-17.0.13+11"
"amd64-Windows_11-10.0"
CL-USER(2):

Is windows as you can see.

lazy-macro-macaroni commented 2 weeks ago

Oh I guess you wanted to see the whole error that's why

easye commented 2 weeks ago

I managed to replicate your problem: it seems to be a bug in ABCL in bootstrapping its dependencies in a way that I don't quite understand.

As a workaround, issue a

(require :abcl-contrib)

to initialize the dependencies before attempting to use java:jnew-runtime-class.

Lemme know if this works for ya, please…

lazy-macro-macaroni commented 2 weeks ago

Yep it works now. Thanks a lot. 👍

Btw it seems to work without including abcl-contrib.jar. Am I supposed to include this jar in classpath?

easye commented 2 weeks ago

Am I supposed to include this jar in classpath?

ABCL has a strategy to locate and load abcl-contrib.jar as long as it exists in the same directory as abcl.jar which works most of the time. If you get error messages about not being to find this, go ahead and include it.

The error you encountered probably has do something with ABCL internal autoloader dependencies not being declared correctly. I haven't explicitly found the problem. I just guessed that the require clause might help things.

lazy-macro-macaroni commented 2 weeks ago

Alright gotcha. Thanks for the help. Feel free to close issue, although it looks like you want to use it for tracking the underlying issue.