A key benefit of this, is that I don't have to worry about ensuring the sources are up-to-date. It's someone else's problem 🙂

I've done a PR for this (https://github.com/clojure-lsp/clojure-lsp/pull/882). Happy to change based upon feedback.

@dharrigan that feature is pretty new, so I didn't have time to improve docs that much, but it should be already possible to point to existing java docs

I named URI exactly because of that

It should work under the existing setting, if not, we should fix and not create a new setting for that

WDYT?

sure, although one would have to remember to prefix it with file:/// etc...

for uri to work.

I'll rename from :jdk-souce-download-uri to jdk-source-uri

Sound agood to me

:perfecto

We can check if it's a path and concert to URI as well

:thumbsup:

There is a shared/filename->uri function

awesome, even simpler 🙂

Shall I close down the PR?

Feel free to change it to use same URI but checking if it's a filename and renaming it to :jdk-source-uri

will do

have to take pooch for a walk first, then when I come back I'll have a look see

on it

So question 'tho, what to do with download-jdk-source If false, or true

if false, but uri is still file:/// do analyse? if false and uri is http:// do nothing?

yes, I think we should analyze still

kk, and if false and uri == http do nothing, like it is atm.

check if URI is file:// or a path, otherwise check download-jdk-source

kk

I'd not suggest check for http, since there is https and variations

kk

I'll work on automatically finding the source on user's java home if available as mentioned https://clojurians.slack.com/archives/C17JYSA3H/p1648473913261469?thread_ts=1648384269.951629&cid=C17JYSA3H

and fallback to check the URI if not found or not set

Which editor are you using?

Emacs

you should configure the lsp-mode project root properly to point to code directory

try lsp-workspace-folders-remove , choose the git root, and then lsp again

choose the code dir when lsp-mode prompts

indeed, what greg says

Thanks! (You guys are both amazing.)

Me and @U04V15CAJ have been adding support for Java interop on clj-kondo and clojure-lsp, for now the only java interop we have so far is the find java classes definition from java class usages. With current nightly build from #clojure-lsp-builds , we support : • Find a java class if the source (`.java`) is available on classpath • Find and decompile a java class if no source is available, only .class, decompiling it to .lsp/.cache/java • Find a JDK class (e.g. java.util.UUID), this one was just added recently, and it has some waterfall decisions ◦ First clojure-lsp tries to find a existing JDK src.zip , this is pretty common on JRE installations, it checks java.home property, JAVA_HOME env var, and java command on PATH ◦ If above is not found, it uses the one specified on :java :jdk-source-uri (Falbacking to clojure-lsp/jdk-source https://github.com/clojure-lsp/jdk-source if not set manually) only if :java :download-jdk-source? is enabled (disabled by default) We are still improving, and we need to make some minor fixes on clj-kondo, with all of this set and working, all java classes should be found when trying to find a definition 🎉 We should keep this on master a little bit before next release, for those who want to test it, it's possible downloading a nightly build from #clojure-lsp-builds

Wow, nice work!!

Probably, I already saw people saying that one of the reasons they stick to cursive is because clojure-lsp doesn't java interop

not for so long :)

Yeah, if you've ever used java.time, for instance, having completion is night and day difference to keeping 15 browser tabs open to each class.

having java jdk sources is a big boon indeed!

I for one welcome our new interop overlords 🙂

Yes, we would like to add support for docs/go-to method definition and eventually completion, baby steps :)

we already have the mechanism on clj-kondo (ASM), we just need to improve it to have those features available on clojure-lsp

btw one thing that I think escaped the various threads we had on the topic was practicalli's aliases https://github.com/practicalli/clojure-deps-edn/blob/fc9f90c51113985938a5a7478d77554f477540f5/deps.edn#L462-L478 It's not drastically different from the various ideas that have been thrown around, but this one seems simple for users to understand and test out At scale it doesn't quite cut it since users will likely forget, misconfigure, etc or even after a correct configuration, switching JDKs would invalidate these aliases, possibly leaving very confusing errors.

And also deps.edn is one big map i.e. no sequential semantics. For all "sources" stuff, if you don't place this stuff at the tail of the classpath, you can and will suffer :)

(baby steps) 😉

Is this with java navigation?

Yes. I can goto definition on a java class and have it decompiled etc...

niiice :)

Not quite 100% there, for exmaple, if I goto definition on a stringbuffer constructor, it plops me at the top of the decompiled file, rather than at the constructor.

But I'm sure it'll all be good in the end.

it's no biggie, I can always go to the method by a simple grep. Having the ability just to go to source is fantastic no-matter what!

Those are the little things that are going to be improved over the next couple of months

yup 🙂 All wonderful stuff.

thank you! and Eric 🙂

@UKFSJSM38 considering this example though: perhaps clj-kondo could add :constructor true :arg-count 0 or so and then maybe clojure-lsp could figure out where to go, into the decompiled file?

I think that would require running a library like java-parser over the decompiled file

and then go to the correct constructor

I'm not sure if people would be too unhappy if clj-kondo did this work and thus had an dependency on java-parser

it already has a dependency on ASM

then you could call clj-kondo with the decompiled Java file and get on the fly analysis

anyway, these are the things that we need to figure out :)

:thumbsup:

Yes, ATM clojure-lsp has no logic on how to parse clojure or java, it relies on analysis location, so I think having the location come from kondo would make things easy to implement on clojure-lsp side

If we parse at clj-kondo, we would probably be able to add to analysis args, methods info and more

yeah, and completions etc

If ASM support get row/col location, then we may not need java-parser, but I couldn't find that info

it doesn't

I mean, this info isn't available in the .class files I think, it's compiled away

but perhaps other people will also happily use the java parsing info if clj-kondo has that dep

javaparser I mean

and we can make deps optional too

btw there's also java doclet stuff we could try to use. I think CIDER uses this and I've also used this but at build time, not in clj-kondo itself

Got it, that's bad

Yeah, I know it would be one more lib, but it would be great for downstreams I think if kondo know more about java

what does doclet does? It brings doc about java?

If we intend to add java-parser in the future, would be needed that doclet?

it can generate javadoc stuff but as it does that, it extracts info about constructors, methods etc. it's built into java

See e.g. https://github.com/clj-kondo/clj-kondo/blob/master/extract/clj_kondo/impl/ExtractJava.clj

I don't know if (ToolProvider/getSystemDocumentationTool) works properly in graalvm and also not if it provides good locations

I see, sounds good explore that

feel free to try this out a bit

I'm pretty sure javadoc doesn't generate any line numbers

Maybe we have to split clj-kondo into modules too.

and clojure-lsp can use all modules, but other users can choose to only use the core dependency for only clojure

but that can happen in the future too when people start asking for it

yes, I like that

I noticed javaparser has two deps: javassist and guava

we only started split clojure-lsp into modules after people asked

clojure-lsp cli module unfortunately already has guava because of lsp4j