jnew-runtime-class fails with constructor exception

[lazy-macro-macaroni]

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]

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

[easye]

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]

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]

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

[easye]

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]

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]

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]

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.

[crmsnbleyd]

Can reproduce with

CL-USER(1): (lisp-implementation-version)
"1.9.2"
"OpenJDK_64-Bit_Server_VM-Homebrew-23.0.1"
"x86_64-Mac_OS_X-15.1.1"

Running it twice makes it work