Cider: CIDER no muestra documentos para Java

Como puede ver, el símbolo también se resuelve por error para java.lang.Character / toUpperCase en lugar de lang.String.

¿No recibe un mensaje que le pregunta qué versión elegir?

@bbatsov Curiosamente, hoy es así (que es mucho mejor 😂):

Lo verifiqué y recibo el mensaje cuando uso la tecla de acceso rápido predeterminada (en Spacemacs es , h h en estado normal malvado), pero no cuando uso esta tecla de acceso rápido que he configurado:

(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"))))))

Esta tecla de acceso rápido de alguna manera omite el aviso y solo muestra los documentos para el personaje.

Por cierto, la sugerencia de eldoc también podría usar algo de trabajo, por ejemplo, una separación entre los argumentos de los diferentes métodos:

No pudimos encontrar una buena separación, por eso solo mezclamos las firmas de todas las versiones posibles. Es ideal, pero lamentablemente tampoco veo cómo se puede mejorar. Eldoc debe tener una estructura de cadena ver, de lo contrario el resaltado de los parámetros allí se rompería.

@bbatsov Acabo de reiniciar mi Emacs y los Javadocs volvieron a desaparecer. :(

Me pregunto si las cosas cambiarán para usted si prueba Java 8 en lugar de 9. No he tenido mucho tiempo para jugar con Java 9 y me pregunto si parte de la manipulación de classpath que hacemos no funciona correctamente allí o algo así. Además, asegúrese de que el búfer de código haya sido evaluado antes de probar eldoc / cider-doc).

@bbatsov Cambié a Java 8 y todavía no he tenido ningún problema (pero no he hecho mucho código desde entonces, quién sabe).
Y acabo de entender que eres la persona que da esa charla ^ __ ^ De alguna manera tu avatar se veía tan agresivo para mí y esto me sorprendió :)) Gracias por tu trabajo;) Estoy viendo tu Clojure Bad Parts hablar ahora 😊

¡Ja ja!

¡Y pensé que esta era mi cara feliz! 😄

Hola, (emacs / sidra principiante aquí)

¿Dónde en la sidra general / ROADMAP está posicionado este error?

Es mas

• nadie tiene tiempo para trabajar en esto
• se resolverá con / por huerto
• funciona según lo previsto
• ¿No se supone que funcione en este momento?

Cada vez que dedico algún tiempo a aprender clj / emacs, termino queriendo buscar algo de clase y me siento frustrado, lo cual depende completamente de mí, pero sigo preguntándome:

¿Mi configuración es incorrecta o está rota, o los desarrolladores de clojure "reales" nunca necesitan buscar un javadoc, lo cual sería bastante desconcertante para mí?

Mi caso de prueba es buscar a través de cider-doc java.util.concurrent.PriorityBlockingQueue que da como resultado https://imgur.com/a/TaQXfpS .

En resumen: ¿Esto está roto para mí o para todos y cómo se las arregla la gente sin él?

PPS: lo he intentado con java 8-11 con java-doc y java-src instalados

Salidas:

en una clase

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.

en un método

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

For additional documentation, see the Javadoc.

Definition location unavailable.

Progreso !

Creo que está sucediendo lo siguiente

Premisa: uso spacemacs, que usa sidra de MELPA, actualmente 0.20.0 + cider-nrepl 0.20.0

sidra-nrepl 0.20.0 utiliza huerto 0.3.1

Asunto:

orchard detecta fuentes java por medio de jdk-sources -> jdk-resource-url y críticamente -> 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)

En mi sistema (archlinux) y en el paquete ubuntus openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64 parece que los javas están distribuidos como carpetas en /usr/lib/jvm

es decir

# ~/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

o 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

en una demo emacs / cider repl java.home es, por ejemplo:

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

_No sé si algo de fuera pasa esto, o si es el hogar predeterminado de Java actual ._

si no me equivoco, eso significaría que en mi sistema jdk-root es

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

resultando en jdk-resource-url buscando cosas en la carpeta incorrecta (padre)

Conclusión:

jdk-roots "El directorio raíz de JDK (padre del directorio java.home JRE)" el ​​comentario / premisa parece estar equivocado (revisé rápidamente en línea y parece que no hay un "estándar" como lo que java. el hogar realmente está destinado a ser)

¿Eso ayuda a alguien?

¡Sí, ayuda! A través de Java 8, la propiedad del sistema java.home apunta a un JRE dentro de la raíz del JDK. Esto se espera según https://docs.oracle.com/javase/7/docs/technotes/tools/linux/jdkfiles.html. No puedo encontrar un enlace a javase / 8 pero observo empíricamente (en Debian):

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

Desde java 9 en adelante, el subdirectorio JRE desaparece y su contenido se fusiona un nivel en la raíz JDK, que java.home ahora apunta a:

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

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

Como un aparte para los usuarios de distribuciones derivadas de Debian, el paquete openjdk-11-source instala un enlace simbólico roto a src.zip (consulte https://bugs.launchpad.net/ubuntu/+source/openjdk-lts / + error / 1791219)
Después de instalarlo, tengo:

$ 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

Parece que orchard debería verificar en ambos lugares y probar si src.zip es legible. También sería bueno imprimir una advertencia silenciable a STDERR si no es así.
Estaría encantado de enviar un PR si esto suena razonable.

Mientras tanto, puede encontrar su copia de src.zip y agregarla a la ruta de clases manualmente, por ejemplo, usando una entrada :local/root deps.edn (si está en tools.deps https: / /clojure.org/reference/deps_and_cli#_dependencies).

hm, parece que la cadena de llamadas jdk-sources -> jdk-root solo se llama cuando está en boot-class-loader; de lo contrario, es (.getContextClassLoader (Thread/currentThread)) ,

Forcé el zip en el classpath por medio de project.clj

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

y comprobado a través de

> (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>

todavía no hay doc

Parece que esto no funcionará en Java 11 hasta que se solucione https://github.com/clojure-emacs/orchard/issues/20 .
Sin embargo, Java 8 debería funcionar. Necesitará src.zip y tools.jar en la ruta de clase, que debe agregarse automáticamente. Entonces puede intentar algo como lo siguiente (en sidra 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)

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. ¡Gracias por su contribución y comprensión!

@jeffvalk abordó recientemente el problema vinculado de Orchard, así que supongo que podemos cerrar este.

En Debian 10, todo lo que tuve que hacer fue instalar openjdk-11-source . Intenté el enlace simbólico src.zip y descubrí que ya se había creado.

En Ubuntu 18.04 con Emacs 26.3 CIDER 0.24.0 nREPL 0.6.0 Java 1.8.0_242 agregué un directorio que contiene un zip con fuentes Java como recurso para el perfil de Leiningen ( ~/.lein/profiles.clj ):

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