Kap jvm: needs exception handling similar to Dyalog JNI #36

kapitaali commented 2025年11月09日 11:17:24 +01:00

Current jvm: functions (at least that I'm aware of) do not allow one to handle exceptions on the JVM side. Dyalog has exception handling and you can do something like

:If ⎕SE.Dyalog.JNI.ExceptionCheck env
 ⎕SE.Dyalog.JNI.ExceptionClear env
 'Skipping: ', className
 →nextIteration
:EndIf

I wrote a JAR loader, and it works for small JAR files:

loadJar "../classes/helloworld.jar"
┌Map: 1───────────────────────┐
│"HelloWorld" class HelloWorld│
└─────────────────────────────┘

But bigger JAR files give various errors that relate to the internal dependency structure:

loadJar "../classes/cobaltstrike.jar"
Error at: 40:21: callMethod: JVM Exception: superclass access check failed: class de.javasoft.plaf.synthetica.SyntheticaDefaultLookup (in unnamed module @0x3e8691d7) cannot access class sun.swing.DefaultLookup (in module java.desktop) because module java.desktop does not export sun.swing to unnamed module @0x3e8691d7
loadJar "../classes/shadow-cljs.jar"
Error at: 40:21: callMethod: JVM Exception: class org.apache.commons.io.comparator.ReverseComparator cannot access its abstract superclass org.apache.commons.io.comparator.AbstractFileComparator (org.apache.commons.io.comparator.ReverseComparator is in unnamed module of loader java.net.URLClassLoader @4ed05b28; org.apache.commons.io.comparator.AbstractFileComparator is in unnamed module of loader 'app')

The point is just to be able to skip loading those classes that cause exceptions.

Current jvm: functions (at least that I'm aware of) do not allow one to handle exceptions on the JVM side. Dyalog has exception handling and you can do something like ``` :If ⎕SE.Dyalog.JNI.ExceptionCheck env ⎕SE.Dyalog.JNI.ExceptionClear env 'Skipping: ', className →nextIteration :EndIf ``` I wrote a JAR loader, and it works for small JAR files: ``` loadJar "../classes/helloworld.jar" ┌Map: 1───────────────────────┐ │"HelloWorld" class HelloWorld│ └─────────────────────────────┘ ``` But bigger JAR files give various errors that relate to the internal dependency structure: ``` loadJar "../classes/cobaltstrike.jar" Error at: 40:21: callMethod: JVM Exception: superclass access check failed: class de.javasoft.plaf.synthetica.SyntheticaDefaultLookup (in unnamed module @0x3e8691d7) cannot access class sun.swing.DefaultLookup (in module java.desktop) because module java.desktop does not export sun.swing to unnamed module @0x3e8691d7 loadJar "../classes/shadow-cljs.jar" Error at: 40:21: callMethod: JVM Exception: class org.apache.commons.io.comparator.ReverseComparator cannot access its abstract superclass org.apache.commons.io.comparator.AbstractFileComparator (org.apache.commons.io.comparator.ReverseComparator is in unnamed module of loader java.net.URLClassLoader @4ed05b28; org.apache.commons.io.comparator.AbstractFileComparator is in unnamed module of loader 'app') ``` The point is just to be able to skip loading those classes that cause exceptions.

kapitaali commented 2025年11月09日 13:14:50 +01:00

Here's the code if you want to try it out:

∇ loadJar (jarName) {
 ⍝ jarName ← "../classes/myJar.jar" relative dir + jarfile name
 fullpath ← { ~("/" ∊ ̄1↑⍵) → ⍵←⍵, "/" } jarName
 fileClass ← jvm:findClass "java.io.File"
 stringClass ← jvm:findClass "java.lang.String"
 fileConstructor ← jvm:findConstructor⟦fileClass; stringClass⟧
 filePathObj ← jvm:createInstance⟦fileConstructor; fullpath⟧
 toURI ← jvm:findMethod⟦fileClass; "toURI"⟧
 uri ← jvm:callMethod⟦toURI; filePathObj⟧
 toURL ← jvm:findMethod⟦fileClass; "toURL"⟧
 url ← jvm:callMethod⟦toURL; filePathObj⟧
 urlArray ← jvm:createArrayInstance⟦jvm:findClass "java.net.URL"; 1⟧
 jvm:arraySetElement (urlArray; 0; url)
 classloaderClass ← jvm:findClass "java.net.URLClassLoader" 
 getClassMethod ← jvm:findMethod⟦jvm:findClass "java.lang.Object"; "getClass"⟧
 classloaderConstructor ← jvm:findConstructor⟦classloaderClass; jvm:callMethod⟦getClassMethod; jvm:createArrayInstance⟦jvm:findClass "java.net.URL"; 0⟧⟧⟧
 classloaderObj ← jvm:createInstance⟦classloaderConstructor; urlArray⟧
 jarloaderClass ← jvm:findClass "java.util.jar.JarFile" 
 jarloaderConstructor ← jvm:findConstructor⟦jarloaderClass; stringClass⟧
 jarloaderObj ← jvm:createInstance⟦jarloaderConstructor; jarName⟧
 entriesMethod ← jvm:findMethod⟦jarloaderClass; "entries"⟧
 entriesObj ← jvm:callMethod⟦entriesMethod; jarloaderObj⟧
 classMap ← map ⍬
 classNames ← ⍬
 enumClass ← jvm:findClass "java.util.Enumeration"
 hasmoreMethod ← jvm:findMethod⟦enumClass; "hasMoreElements"⟧
 nextMethod ← jvm:findMethod⟦enumClass; "nextElement"⟧
 entryClass ← jvm:findClass "java.util.jar.JarEntry"
 getnameMethod ← jvm:findMethod⟦entryClass; "getRealName"⟧
 while ("true"≡jvm:fromJvm jvm:callMethod⟦jvm:findMethod⟦jvm:findClass "java.lang.Boolean"; "toString"⟧; jvm:callMethod⟦hasmoreMethod; entriesObj⟧⟧) {
 entryObj ← jvm:callMethod⟦nextMethod; entriesObj⟧
 entryName ← jvm:callMethod⟦getnameMethod; entryObj⟧
 n←jvm:fromJvm entryName
 if ((".class"≡ ̄6↑n)∧("META-"≢5↑n)) {
 className ← ̄6↓n
 className ← "/" regex:replace (className; ".")
 classNames ← classNames, ⊂className
 classNameJ ← jvm:toJvmString className
 loadclassMethod ← jvm:findMethod⟦classloaderClass; "loadClass"; stringClass⟧
 { 
 loadedClass ← jvm:callMethod⟦loadclassMethod; classloaderObj; classNameJ⟧ 
 classMap ← classMap mapPut className loadedClass
 } catch 'jvm:jvmMethodCallException λ{ ⍬ }
 }
 }
 classMap
}

Here's the code if you want to try it out: ``` ∇ loadJar (jarName) { ⍝ jarName ← "../classes/myJar.jar" relative dir + jarfile name fullpath ← { ~("/" ∊ ̄1↑⍵) → ⍵←⍵, "/" } jarName fileClass ← jvm:findClass "java.io.File" stringClass ← jvm:findClass "java.lang.String" fileConstructor ← jvm:findConstructor⟦fileClass; stringClass⟧ filePathObj ← jvm:createInstance⟦fileConstructor; fullpath⟧ toURI ← jvm:findMethod⟦fileClass; "toURI"⟧ uri ← jvm:callMethod⟦toURI; filePathObj⟧ toURL ← jvm:findMethod⟦fileClass; "toURL"⟧ url ← jvm:callMethod⟦toURL; filePathObj⟧ urlArray ← jvm:createArrayInstance⟦jvm:findClass "java.net.URL"; 1⟧ jvm:arraySetElement (urlArray; 0; url) classloaderClass ← jvm:findClass "java.net.URLClassLoader" getClassMethod ← jvm:findMethod⟦jvm:findClass "java.lang.Object"; "getClass"⟧ classloaderConstructor ← jvm:findConstructor⟦classloaderClass; jvm:callMethod⟦getClassMethod; jvm:createArrayInstance⟦jvm:findClass "java.net.URL"; 0⟧⟧⟧ classloaderObj ← jvm:createInstance⟦classloaderConstructor; urlArray⟧ jarloaderClass ← jvm:findClass "java.util.jar.JarFile" jarloaderConstructor ← jvm:findConstructor⟦jarloaderClass; stringClass⟧ jarloaderObj ← jvm:createInstance⟦jarloaderConstructor; jarName⟧ entriesMethod ← jvm:findMethod⟦jarloaderClass; "entries"⟧ entriesObj ← jvm:callMethod⟦entriesMethod; jarloaderObj⟧ classMap ← map ⍬ classNames ← ⍬ enumClass ← jvm:findClass "java.util.Enumeration" hasmoreMethod ← jvm:findMethod⟦enumClass; "hasMoreElements"⟧ nextMethod ← jvm:findMethod⟦enumClass; "nextElement"⟧ entryClass ← jvm:findClass "java.util.jar.JarEntry" getnameMethod ← jvm:findMethod⟦entryClass; "getRealName"⟧ while ("true"≡jvm:fromJvm jvm:callMethod⟦jvm:findMethod⟦jvm:findClass "java.lang.Boolean"; "toString"⟧; jvm:callMethod⟦hasmoreMethod; entriesObj⟧⟧) { entryObj ← jvm:callMethod⟦nextMethod; entriesObj⟧ entryName ← jvm:callMethod⟦getnameMethod; entryObj⟧ n←jvm:fromJvm entryName if ((".class"≡ ̄6↑n)∧("META-"≢5↑n)) { className ← ̄6↓n className ← "/" regex:replace (className; ".") classNames ← classNames, ⊂className classNameJ ← jvm:toJvmString className loadclassMethod ← jvm:findMethod⟦classloaderClass; "loadClass"; stringClass⟧ { loadedClass ← jvm:callMethod⟦loadclassMethod; classloaderObj; classNameJ⟧ classMap ← classMap mapPut className loadedClass } catch 'jvm:jvmMethodCallException λ{ ⍬ } } } classMap } ```

loke commented 2025年11月09日 15:21:44 +01:00

Did you try catching jvmMethodCallException? You can find an example here:

https://codeberg.org/loke/array/src/branch/master/array/standard-lib/xml.kap#L73

Note that as of the most recent commit, this symbol was moved from the kap to the jvm namespace.

Did you try catching `jvmMethodCallException`? You can find an example here: https://codeberg.org/loke/array/src/branch/master/array/standard-lib/xml.kap#L73 Note that as of the most recent commit, this symbol was moved from the `kap` to the `jvm` namespace.

kapitaali commented 2025年11月09日 15:32:41 +01:00

Thanks, I added catching to the code above. It still fails. It seems a bit similar to the thing where JVM method returns an instance of java.lang.Boolean, but then when you do jvm:fromJvm, it says fromJvm: Unexpected JVM type: kotlin.Boolean.

Thanks, I added catching to the code above. It still fails. It seems a bit similar to the thing where JVM method returns an instance of java.lang.Boolean, but then when you do jvm:fromJvm, it says `fromJvm: Unexpected JVM type: kotlin.Boolean`.

loke commented 2025年11月09日 16:35:34 +01:00

As best as I can tell, catching that exception should work. Can you show the code you used?

As best as I can tell, catching that exception should work. Can you show the code you used?

kapitaali commented 2025年11月09日 16:41:52 +01:00

code #36 (comment)

code https://codeberg.org/loke/array/issues/36#issuecomment-8191205

kapitaali commented 2025年11月09日 17:03:16 +01:00

For example loading Kap's own internal JARs work, eg.

loadJar "../contrib/httpserver-mod/build/libs/httpserver-mod-jvm.jar"

but if try with this one https://repo.clojars.org/thheller/shadow-cljs/3.0.4/shadow-cljs-3.0.4.jar it will say

loadJar "../classes/shadow-cljs-3.0.4.jar"
Error at: 41:23: callMethod: JVM Exception: io/methvin/watchservice/MacOSXListeningWatchService$Config

For example loading Kap's own internal JARs work, eg. ``` loadJar "../contrib/httpserver-mod/build/libs/httpserver-mod-jvm.jar" ``` but if try with this one https://repo.clojars.org/thheller/shadow-cljs/3.0.4/shadow-cljs-3.0.4.jar it will say ``` loadJar "../classes/shadow-cljs-3.0.4.jar" Error at: 41:23: callMethod: JVM Exception: io/methvin/watchservice/MacOSXListeningWatchService$Config ```

kapitaali commented 2025年11月09日 22:57:20 +01:00

I just realized that this error might be due to me trying to open JAR files that themselves are executable, and that they error if I try to java -jar them from terminal (both cobaltsrike and shadow-cljs are executable).

However, catching those exceptions still would be nice. Then it would not error on Kap's end. Opening the JAR would just not do much anything (I guess) and I could print an error message of my own.

I just realized that this error might be due to me trying to open JAR files that themselves are executable, and that they error if I try to `java -jar ` them from terminal (both cobaltsrike and shadow-cljs are executable). However, catching those exceptions still would be nice. Then it would not error on Kap's end. Opening the JAR would just not do much anything (I guess) and I could print an error message of my own.

loke commented 2025年11月10日 16:49:13 +01:00

The catching really should be working. When you tried, did you check out the latest version of the code first, since the name of the tag that you should catch had changed.

The catching really should be working. When you tried, did you check out the latest version of the code first, since the name of the tag that you should catch had changed.

kapitaali commented 2025年11月10日 18:38:00 +01:00

Yes, I have checked out master. I can see the exception type being used in xml.kap.

Here is a minimal test example, it should return custom error message:

{
 mathClass ← jvm:findClass "java.lang.Math"
 intClass ← jvm:findPrimitiveTypeClass 'jvm:int
 divideMethod ← jvm:findMethod⟦mathClass; "divideExact"; intClass; intClass⟧
 test ← jvm:callMethod⟦divideMethod; null; jvm:toJvmInt 1; jvm:toJvmInt 0⟧
} catch 'jvm:jvmMethodCallException λ{ "testing catching exceptions, tried to divide by zero" }

Running this gives me

Error at: 5:9: callMethod: JVM Exception: / by zero

so the exception is not caught.

Yes, I have checked out master. I can see the exception type being used in xml.kap. Here is a minimal test example, it should return custom error message: ``` { mathClass ← jvm:findClass "java.lang.Math" intClass ← jvm:findPrimitiveTypeClass 'jvm:int divideMethod ← jvm:findMethod⟦mathClass; "divideExact"; intClass; intClass⟧ test ← jvm:callMethod⟦divideMethod; null; jvm:toJvmInt 1; jvm:toJvmInt 0⟧ } catch 'jvm:jvmMethodCallException λ{ "testing catching exceptions, tried to divide by zero" } ``` Running this gives me ``` Error at: 5:9: callMethod: JVM Exception: / by zero ``` so the exception is not caught.

loke commented 2025年11月11日 13:32:54 +01:00

I tested your code, and I get the message: "testing catching...", so it works for me. The only explanation I have is that for some reason you're using the old version. Can you look in jvm-module.kt and check what the JvmFunctionCallException constructor looks like.

It should contain this:

 tag = ThrowableTag(APLSymbol(module.jvmMethodCallExceptionSymbol), JvmInstanceValue(originException))

I tested your code, and I get the message: "testing catching...", so it works for me. The only explanation I have is that for some reason you're using the old version. Can you look in `jvm-module.kt` and check what the `JvmFunctionCallException` constructor looks like. It should contain this: ``` tag = ThrowableTag(APLSymbol(module.jvmMethodCallExceptionSymbol), JvmInstanceValue(originException)) ```

kapitaali commented 2025年11月11日 13:58:33 +01:00

Thanks. Looks like trying with another system works.

I have two laptops here, tested with both of them. The other one is older Lenovo. That test code does work on the older Lenovo, custom error message is returned and exception is caught.

I'm closing this now since with my older laptop the above code does in fact load shadow-cljs.jar without any kind of errors.

Thanks. Looks like trying with another system works. I have two laptops here, tested with both of them. The other one is older Lenovo. That test code does work on the older Lenovo, custom error message is returned and exception is caught. I'm closing this now since with my older laptop the above code does in fact load shadow-cljs.jar without any kind of errors.