Would it be possible for Babashka to expose a list of the classes/interfaces it supports somehow? Basically the equivalent of (concat (keys babashka.impl.classes/base-custom-map) babashka.impl.classes/java-net-http-classes (:all babashka.impl.classes/classes)) or something along those lines. Or does it already?

you mean programmatically?

Yes.

clojure supports (ns-imports *ns*) which bb does too, but this doesn't give you everything. so I think we'd have to invent something custom for it, right?

I think so, yeah. With Clojure, I use java.lang.module.ModuleFinder to list all Java base classes/interfaces etc. So I’m looking for something similar here.

babashka.classes/all-classes or so?

Yes, something like that.

we could also expose the reflection config json which is already part of the resources

which would be the most accurate way since it reflects what is available in bb

Indeed. :thumbsup:

this is pretty easy to do, just add the resource as a built-in similar to how it's done in clj-kondo

clj-kondo has several built-in transit files

Cool. :thumbsup: This wouldn’t affect binary size, either, since reflection.json is already baked in, but how about memory use? I’m guessing not?

I guess you’re referring to this: https://github.com/clj-kondo/clj-kondo/blob/cb55e73bb8ce668e437eafb14901bdd8b73a133e/src/clj_kondo/impl/cache.clj#L13-L33

yes, and also the accompanying graal settings

> reflection config json which is already part of the resources So can I already access that JSON file somehow in the current Babashka version?

no, you need to expose the json file as part of the binary, like in clj-kondo

not everything in the classpath is automatically included in the binary

@flowthing https://github.com/clj-kondo/clj-kondo/blob/ded50286d3e7f192b714ac07980c85bd9a3f19f5/resources/META-INF/native-image/clj-kondo/clj-kondo/native-image.properties#L4

and probably we have to tweak the io/resource implementation also a bit to fall back on the clojure version of io/resource

I see. :thumbsup:

I can give that a shot locally.

See if that’ll give me everything I need.

Simply exposing babashka.impl.classes/all-methods would actually give me all I need, I think. Of course, I don’t know whether that makes for a sensible API. Could also add a wrapper that just does (map (fn [{:keys [class name]}] (symbol (.getName class) name)) (babashka.classes/all-methods)) to get a list of fully-qualified symbols.

So it’s all there already, would just need to figure out an API that makes sense and expose it.

do you mean all-classes?

No, all-methods. That way I could offer auto-completion for those (and only those) methods Babashka actually supports.

I’ll take the “fully-qualified symbol” suggestion above back, though — that only makes sense for static methods.

Hmm, except that I would also need a way to distinguish between static and instance methods…

Well, that should be doable, too.

I’ll look into it some more.

all-methods doesn't make sense to me

if I give you all classes, you can derive all methods from that

I think for now you could just make a one-one snapsnot of all classes in bb and keep that around in your tool?

> if I give you all classes, you can derive all methods from that Right, that’s true. :thumbsup:

> I think for now you could just make a one-one snapsnot of all classes in bb and keep that around in your tool? Yes, that’s the plan.

> if I give you all classes, you can derive all methods from that > Except that that will also return methods Babashka doesn’t actually support, right? (Not that this is necessarily a problem — I’m not sure yet which I’d prefer, to be honest.)