clojure-lsp doesn't support it, but there is an open issue for that feature, it'd need changes on clj-kondo probably

This is solved https://github.com/clojure-emacs/enrich-classpath and a public alpha will be released as soon as Clojars solves an administrative issue

oh, I didn't know about that lib, does it plays well with clj-kondo?

Maybe. It helps tools (like deps.edn or Leiningen) to add items to the classpath. It's not a runtime library.

yeah, @U04V15CAJ that may help with that idea of supporting java source on clj-kondo/clojure-lsp ?

btw @U0178V2SLAY I read too quickly your question and didn't notice you mentioned resolve-java-sources-and-javadocs (which is the former name of enrich-classpath). Happy you're giving it use and seeing some success. I think you're mentioning a different use case ("local" java sources). I assume this refers to .java files located within your project? That seems a slightly different use case.

yeah, exactly

nice :) I think you can open an issue in https://github.com/clojure-emacs/cider-nrepl explaining the issue in detail (and mentioning that you already are using this plugin). Will be happy to give it a read. Not sure if it's something that should be solved by the plugin, or by cider

sure, I can try to write up what I was trying to achieve. As I'm quite new to both cider & lsp, I was mostly pondering if this is a functionality that's already provided by some component, but which I haven't configured properly.

Because this plugin is new and there practically wasn't a solution for this problem in the preceding years, I think this is not a very often explored area. People are used for Java integration to not work at all. So it wouldn't surprise me if you found a genuine edge case!

@UKFSJSM38 clj-kondo already supports linting arities for static methods on built-in Java classes. Guess how many times this has helped me in the last two years? 0 times :) So linting for Java interop doesn't add a lot of value imo, but being able to navigate to them, could surely be useful.

Agreed, I think navigation is the priority indeed, you are right

As for linting, Eastwood lints for arities (static and instance methods), deprecations, etc from arbitrary Java deps (without requiring the .java sources to be present). It helps from time to time As always, I'm perfectly fine with the two most prominent linters having different areas of focus. In the average project I'll run both clj-kondo and Eastwood (the former fail-fasting the second for a nicer feedback loop, in CI)

> (without requiring the .java sources to be present). yeah, I implemented the static arity info first using the javadoc stuff, but later on I realized that can just be done using reflection I have an issue to revisit that, but when the actual sources are available, then the javadoc approach might still have value as the mapping between source and Java class/methods can be made

I think clj-kondo could provide arity info + analysis info for navigation based on analyzing the source. I just wonder if there is a better analyzer than the javadoc stuff that is also compatible with graalvm native-image. I haven't tried running the javadoc stuff at runtime

@U45T93RA6 how does eastwood know what class is being called using an instance call, does it always know also in the presence of reflection? how?

> I just wonder if there is a better analyzer than the javadoc stuff that is also compatible with graalvm native-image. I haven't tried running the javadoc stuff at runtime Orchard has a variety of parsers and fallbacks. I think some of them work better in concert with https://github.com/clojure-emacs/enrich-classpath

can you be more specific?

> how does eastwood know what class is being called using an instance call, does it always know also in the presence of reflection? how? it doesn't know in face of reflection. In the codebases I generally work on reflection is a no-go and will have 0 reflection warnings. The https://github.com/jonase/eastwood#reflection linter emphasizes this ideal so hopefully it will be no-go for more people (increasing Eastwood accuracy as well for the instance call linting)

> can you be more specific? There's parser and legacy-parser https://github.com/clojure-emacs/orchard/tree/70e42b52962572602c6bbbcfe1c7f547f2ab8a9e/src/orchard/java

ah ok, it uses the same stuff clj-kondo uses: https://github.com/clojure-emacs/orchard/blob/70e42b52962572602c6bbbcfe1c7f547f2ab8a9e/src/orchard/java/parser.clj#L15

Perhaps that stuff works in GraalVM though, never tried

if it does, then when its given an "enriched" classpath, there might be some gains to be made, also with respect to instance methods

there's https://javaparser.org/ btw, seems simpler than parsing javadoc

cool

https://github.com/clj-kondo/clj-kondo/issues/1330

I attempted to document my original question under https://github.com/clojure-emacs/cider-nrepl/issues/700

@U0178V2SLAY Let me know if this works for you. https://github.com/clojure-emacs/cider-nrepl/issues/700#issuecomment-890479971

thanks, I'll check it out later 🙂