What is the minimal analysis you need for Java classes?

Probably we could start with a new bucker for java with it's locations, or even add to var-definition with a class flag or something, this way we could have find-definition and if we have the var-usages the references as well

ok. I'm looking at the javaparser project now. it's lgpl, but I think it's safe to include such a project?

I always thought since it's LGPL it's safe, but not sure if it works fine for all kind of licenses like MIT / EPL

The other option is to use jdk.javadoc.doclet.Doclet which requires java 9+

we could make that functionality optional, when the class is there, use it, else don't provide java analysis

and for graalvm it shouldn't matter, as there 11 is already used

Exactly!

I see no problems with that approach

I've already been using that class for java methods (which are stored as functions to get arity errors, which was something from the initial versions of clj-kondo)

for built-in classes

the funny thing is, I've never really encountered an example where clj-kondo helped me with this

Hmm, this only seems to work for "documented" classes

not sure if that is a reasonable restriction

so classes that actually have javadoc stuff in it

I think that's not ideal unfortunately 😔

then I think we should go with javaparser

but the lgpl is something that could be tricky

besides license, is it hard to use javaparser?

yeah, I tried to write some "proxy" code which didn't work

so I think it might be better to write an API in Java

and then use that from Clojure

let me push what I got so far

maybe a separate project as a anti corruption layer/API in clojure

hmm yeah perhaps. we could make a project in the clj-kondo org for this

but how would this help us?

oh, I misread, you meant an API in java

yeah, write the javaparser interop in Java

well, it could be a clojure API, it'd just be more convenient, but both should work

and then expose a few functions for Clojure

basically to hide the messy interop

seems good

I just want the AST as data, not as some classes

same old

yeah, makes sense

that's why maybe an clojrue API makes more sense as we do care more about data not classes

ok, let's backup

what I mean is: you have to write a ton of interop to deal with this library

and this interop is messy to do in Clojure

so that part has to be written in Java

I see now

and then expose a couple of methods that you can then use to get a Clojure API

makes sense!

so I'm already running into this problem: https://stackoverflow.com/a/6054258/6264

maybe ask if Alex got his answer? 😂

haha lol @U064X3EF3

ok, pushed to the branch.

lein run -m clj_kondo.impl.JavaParser

I didn't get it to work by writing Clojure, I think just making a facade in Java is the way to go for this nasty lib

javaparser branch?

yes

we might want to split this into a separate project so we can package the compiled java into a separate artifact

and then it seems fairly easy to extract whatever from whatever source files

just tested, the javaparser seems quite good for java, a abstraction in java seems a good idea indeed to get data

ok, I'll make javaparser-clj or so in clj-kondo

perhaps we can use tools.build with this compilation hook

but then again, maybe not

lein is easy

hahah, there is americano which I use on clojure-lsp

is really easy and you can have deps.edn

yeah, but I also want to deploy

and everything needed is already in lein

indeed

we could do it both ways

I use a github action for clojure-lsp clojars deploy, there is even no alias for deploy locally

yeah, we could do it the same way as your lein clj-kondo project

so I think the interface we need is: throw Java source file in, get out a map with information

and clj-kondo can store this somewhere for linting

and we can expose it in the analysis

seems good, the return map should contain localtion, documentation arity etc right?

yeah maybe :classes [{:name ... :file :...} or so. let's start with the least info possible

yes, seems reasonable

inside :methods [...] with some other maps

> If you use a library that is LGPL, and you statically link with that library, your software must be released with a compatible license.

😢

We should ask some advice in the broader #clojure community. If you could do some research to get more clarity, that would be nice

I think a native image is similar to an uberjar

yeah me too

we could also consider antlr4 which is bsd

and it has a java grammar, possible also a javascript one

it seems generic for multiple languagues right? we would need to check if the java parser is good enough

I think we could borrow some of this stuff from there too: https://github.com/carocad/parcera/blob/master/src/clojure/parcera/antlr/java.clj

I'll also whip up a POC with this

ghaha parcera is also lgpl, what's up with this

hmm, the antlr grammar is unoptimized they say and the optimized one only supports 8

javaparser is probably better

Thank you very much! I will share that with vim users when they find issues to configure clojure-lsp :)

Feel free to link on http://clojure-lsp.io/clients as well

Can I open a PR?

Sure!

https://github.com/clojure-lsp/clojure-lsp/pull/542/files