Cider: CIDER doesn't show docs for Java

As you see, the symbol is also mistakenly resolved for java.lang.Character/toUpperCase instead of lang.String.

Don't you get a prompt asking you which version to choose?

@bbatsov Strangely, today it is like this (which is much better 😂):

I checked, and I do get the prompt when I use the default hotkey (In Spacemacs it is , h h in evil-normal-state), but not when I use this hotkey I have configured myself:

(key-chord-define-global "fd" '(lambda () (interactive "")
                                   (cond
                                    ((or (eq evil-state 'normal) (eq evil-state 'visual)) (execute-kbd-macro (kbd "<escape> , h h")))
                                    ((eq evil-state 'insert) (execute-kbd-macro(kbd "<escape> l , h h i"))))))

This hotkey somehow skips the prompt and just shows the docs for character.

BTW, eldoc's hint could also use some work, e.g., a separation between the args of the different methods:

We could not figure out a good separation, that's why we just mixed the signatures of all possible versions. It's ideal, but unfortunately I can't see how this can be improved either. Eldoc must have a ver string structure, otherwise the highlighting of params there would break.

@bbatsov I just restarted my Emacs, and the Javadocs went missing again. :(

I wonder if things change for you if you try Java 8 instead of 9. I haven't had much time to play with Java 9 and I wonder if some of the classpath manipulation that we do is not working properly there or something. Also - make sure the code buffer has been evaluated before trying eldoc/cider-doc).

@bbatsov I switched to Java 8, and still haven't had any issues (but I haven't done much coding since so who knows).
And I just understood that you're the person giving that talk ^__^ Somehow your avatar looked so aggressive to me and this kind of surprised me :)) Thank you for your work ;) I am watching your Clojure Bad Parts talk now 😊

Haha!

And I thought this was my happy face! 😄

Hi, (emacs/cider beginner here)

Where in the general cider/ROADMAP is this bug positioned ?

Is it more

• noone has time to work on this
• it will be resolved with/by orchard
• it works as intended
• it's not supposed to work right now ?

Everytime I spend some time learning clj/emacs I end up wanting to lookup some Class and get frustrated - which is entirely on me, but I keep asking myself:

Is my setup wrong or broken, or do "real" clojure devs never need to lookup a javadoc - which would be quite baffling to me.

My testcase is to lookup via cider-doc java.util.concurrent.PriorityBlockingQueue which results in https://imgur.com/a/TaQXfpS .

In short: Is this just broken for me or for everybody and how do people cope without ?

PPS: i have tried with java 8 - 11 with java-doc and java-src installed

Outputs:

on a class

java.util.concurrent.PriorityBlockingQueue
   Extends: java.util.AbstractQueue
Implements: java.util.concurrent.BlockingQueue
            java.io.Serializable

Not documented.

For additional documentation, see the Javadoc.

Definition location unavailable.

on a method

java.util.concurrent.PriorityBlockingQueue/add
 [this java.lang.Object]
Not documented.

For additional documentation, see the Javadoc.

Definition location unavailable.

Progress !

I think the following is happening

Premise: I use spacemacs, which uses cider from MELPA , currently 0.20.0 + cider-nrepl 0.20.0

cider-nrepl 0.20.0 uses orchard 0.3.1

Issue:

orchard detects java sources by means of jdk-sources -> jdk-resource-url and critically -> jdk-root

(def jdk-root
  "The JDK root directory (parent of the `java.home` JRE directory)"
  (-> (io/file (System/getProperty "java.home"))
      (.getParentFile)))

(https://github.com/clojure-emacs/orchard/blob/v0.3.1/src/orchard/java.clj#L47)

On my system (archlinux) and in ubuntus openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64 package it seems that the javas are layout as folders under /usr/lib/jvm

i.e.

# ~/Downloads/openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64/data $ tree usr/lib/jvm/ -L 2
usr/lib/jvm/
├── java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
└── java-11-openjdk-amd64

or archlinux

# ~ $ tree /usr/lib/jvm/ -L 2
/usr/lib/jvm/
├── default -> java-11-openjdk
├── default-runtime -> java-11-openjdk
├── java-11-openjdk
├── java-8-openjdk
└── java-default-runtime -> default

in an demo emacs/cider repl java.home is i.e.:

(System/getProperty "java.home") 
; =>  /usr/lib/jvm/java-11-openjdk

_I do not know if something from outside passes this in , or if its the current java's default home._

if I'm not mistaken that would mean on my system jdk-root is

(-> (io/file (System/getProperty "java.home"))
      (.getParentFile))) 
; => /usr/lib/jvm/

resulting in jdk-resource-url looking things up in the wrong (parent) folder

Conclusion:

jdk-roots "The JDK root directory (parent of the java.home JRE directory)" comment/premise seems to be wrong (I quickly checked online and there seems to be no "standard" as what java.home really is meant to be)

Does that help anyone ?

Yes, it helps! Through java 8, the java.home system property points to a JRE within the JDK root. This is expected per https://docs.oracle.com/javase/7/docs/technotes/tools/linux/jdkfiles.html. I can't find a link to javase/8 but empirically observe (on Debian):

user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-8-openjdk-amd64/jre"

From java 9 onwards, the JRE subdirectory is gone and its contents are merged up one level into the JDK root, which java.home now points to:

user=> (System/getProperty "java.home")
"/usr/lib/jvm/java-11-openjdk-amd64"

(see https://docs.oracle.com/en/java/javase/11/install/installed-directory-structure-jdk.html)

As an aside for users of Debian-derived distros, the openjdk-11-source package installs a broken symlink to src.zip (see https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1791219)
After installing it, I have:

$ pwd
/usr/lib/jvm
$ ls -l java-11-openjdk-amd64/src.zip
lrwxrwxrwx 1 root root 21 Nov 20 04:13 java-11-openjdk-amd64/src.zip -> ../openjdk-11/src.zip
$ find openjdk-11 -type f
openjdk-11/lib/src.zip

It seems like orchard should check in both places and test whether src.zip is readable. It would also be nice to print a squelchable warning to STDERR if not.
I'd be happy to submit a PR if this sounds reasonable.

In the meantime, you can find your copy of src.zip and add it to the classpath manually, e.g. using a :local/root deps.edn entry (if you happen to be on tools.deps https://clojure.org/reference/deps_and_cli#_dependencies).

hm, it seems that the call chain jdk-sources -> jdk-root is only called when in boot-class-loader otherwise it's (.getContextClassLoader (Thread/currentThread)),

I forced the zip on the classpath by means of project.clj

:profiles {:repl {:resource-paths ["/usr/lib/jvm/default/lib/src.zip"]}}

and checked via

> (System/getProperty "java.class.path") ; in repl buffer
; "/home/_/Projekte/repos/temp/test/test:/_/patrik/Projekte/repos/temp/test/src:
   /usr/lib/jvm/default/lib/src.zip:  <snip>

still no doc

It looks like this'll be broken on Java 11 until https://github.com/clojure-emacs/orchard/issues/20 is fixed.
Java 8 should work though. You'll need both src.zip and tools.jar on the classpath which should be added automatically. Then you might try something like the following (on cider v0.21.1):

(clojure.java.io/resource "java/util/AbstractQueue.java")
;; => #object[java.net.URL 0x2e00bc76 "jar:file:/usr/lib/jvm/java-8-openjdk-amd64/src.zip!/java/util/AbstractQueue.java"]

(require '[mranderson049.orchard.v0v4v0.orchard.java.parser :as ojp])

(keys (ojp/source-info 'java.util.AbstractQueue))
;; => (:class :doc :line :column :members :file :path)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

@jeffvalk recently addressed the linked Orchard issue, so I guess we can close this one.

On Debian 10, all I had to do was install openjdk-11-source. I went to try to symlink src.zip and found that it had already been created.

On Ubuntu 18.04 with Emacs 26.3 CIDER 0.24.0 nREPL 0.6.0 Java 1.8.0_242 I added a dir containing a zip with Java sources as a resource to Leiningen profile (~/.lein/profiles.clj):

{:user {:resource-paths ["/usr/lib/jvm/openjdk-8"]}}