Cider: CIDER n'affiche pas les documents pour Java

Créé le 17 avr. 2018  ·  17Commentaires  ·  Source: clojure-emacs/cider

Comportement prévisible

image

Comportement réel

image

Informations sur l'environnement et la version
Informations sur la version du CIDRE
;; Connecté au serveur nREPL - nrepl://localhost :59990
;; Instantané CIDER 0.17.0 (package : 20180413.51), nREPL 0.2.13
;; Clojure 1.8.0, Java 9.0.4
Version Lein/Botte
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.7.2

Version Emacs
27.0.50

Système opérateur
macOS

bug stale

Tous les 17 commentaires

Comme vous le voyez, le symbole est également résolu par erreur pour java.lang.Character/toUpperCase au lieu de lang.String.

Vous ne recevez pas une invite vous demandant quelle version choisir ?

@bbatsov Bizarrement, aujourd'hui c'est comme ça (ce qui est bien mieux 😂) :
image

J'ai vérifié et j'obtiens l'invite lorsque j'utilise le raccourci clavier par défaut (dans Spacemacs, il s'agit de , h h en état evil-normal-state), mais pas lorsque j'utilise ce raccourci clavier que j'ai configuré moi-même :

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

Ce raccourci clavier ignore en quelque sorte l'invite et affiche simplement la documentation du personnage.

BTW, l'astuce d'eldoc pourrait également nécessiter du travail, par exemple une séparation entre les arguments des différentes méthodes :
image

Nous n'avons pas pu trouver une bonne séparation, c'est pourquoi nous avons juste mélangé les signatures de toutes les versions possibles. C'est l'idéal, mais malheureusement je ne vois pas non plus comment l'améliorer. Eldoc doit avoir une structure de chaîne ver, sinon la surbrillance des paramètres serait interrompue.

@bbatsov Je viens de redémarrer mon Emacs et les Javadocs ont de nouveau disparu. :(
image

Je me demande si les choses changent pour vous si vous essayez Java 8 au lieu de 9. Je n'ai pas eu beaucoup de temps pour jouer avec Java 9 et je me demande si certaines des manipulations de classpath que nous faisons ne fonctionnent pas correctement là-bas ou quelque chose. Aussi - assurez-vous que le tampon de code a été évalué avant d'essayer eldoc/cider-doc).

@bbatsov Je suis passé à Java 8 et je n'ai toujours pas eu de problèmes (mais je n'ai pas fait beaucoup de codage depuis, alors qui sait).
Et je viens de comprendre que tu es la personne qui donne ce discours ^__^ D'une certaine manière ton avatar m'a semblé si agressif et ça m'a un peu surpris :)) Merci pour ton travail ;) Je regarde ton discours Clojure Bad Parts maintenant 😊

Haha !

Et je pensais que c'était mon visage heureux ! ??

Salut, (emacs/cider débutant ici)

Où dans le cidre général/FEUILLE DE ROUTE ce bug est-il positionné ?

Est-ce plus

  • personne n'a le temps de travailler dessus
  • il sera résolu avec/par verger
  • ça marche comme prévu
  • ce n'est pas censé fonctionner maintenant ?

Chaque fois que je passe du temps à apprendre clj/emacs, je finis par vouloir rechercher une classe et je suis frustré - ce qui est entièrement de ma responsabilité, mais je continue à me demander :

Est-ce que ma configuration est incorrecte ou cassée, ou est-ce que les "vrais" développeurs de clojure n'ont jamais besoin de rechercher un javadoc - ce qui serait assez déroutant pour moi.

Mon cas de test consiste à rechercher via cider-doc java.util.concurrent.PriorityBlockingQueue ce qui donne https://imgur.com/a/TaQXfpS .


En bref : est-ce que c'est juste cassé pour moi ou pour tout le monde et comment les gens s'en sortent-ils ?

PPS: j'ai essayé avec java 8 - 11 avec java-doc et java-src installés


Les sorties:

sur une classe

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.

sur une méthode

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

For additional documentation, see the Javadoc.

Definition location unavailable.

Le progrès !

Je pense que ce qui suit se passe


Prémisse : j'utilise spacemacs, qui utilise le cidre de MELPA , actuellement 0.20.0 + cider-nrepl 0.20.0

cider-nrepl 0.20.0 utilise verger 0.3.1


Problème:

orchard détecte les sources Java au moyen de jdk-sources -> jdk-resource-url et de manière critique -> 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)

Sur mon système (archlinux) et dans le package ubuntus openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64 , il semble que les javas soient mis en forme sous forme de dossiers sous /usr/lib/jvm

c'est à dire

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

ou 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

dans une démo emacs/cider repl java.home est c'est-à-dire :

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

_Je ne sais pas si quelque chose de l'extérieur le transmet à , ou s'il s'agit de l'accueil par défaut de Java actuel._

si je ne me trompe pas, cela signifierait que sur mon système jdk-root est

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

résultant en jdk-resource-url rechercher des éléments dans le mauvais dossier (parent)


Conclusion:

jdk-roots "Le répertoire racine JDK (parent du répertoire java.home JRE)" semble erroné (j'ai rapidement vérifié en ligne et il ne semble pas y avoir de "standard" comme quoi java. la maison est vraiment censée être)

Est-ce que ça aide quelqu'un ?

Oui, ça aide ! Grâce à Java 8, la propriété système java.home pointe vers un JRE dans la racine JDK. Ceci est attendu par https://docs.oracle.com/javase/7/docs/technotes/tools/linux/jdkfiles.html. Je ne trouve pas de lien vers javase/8 mais observe empiriquement (sur Debian):

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

À partir de Java 9, le sous-répertoire JRE a disparu et son contenu est fusionné d'un niveau dans la racine JDK, vers laquelle java.home pointe maintenant :

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

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

En passant pour les utilisateurs de distributions dérivées de Debian, le paquet openjdk-11-source installe un lien symbolique brisé vers src.zip (voir https://bugs.launchpad.net/ubuntu/+source/openjdk-lts /+bug/1791219)
Après l'avoir installé, j'ai :

$ 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

Il semble qu'orchard devrait vérifier aux deux endroits et tester si src.zip est lisible. Il serait également bien d'imprimer un avertissement squelchable à STDERR si ce n'est pas le cas.
Je serais heureux de soumettre un PR si cela semble raisonnable.

En attendant, vous pouvez trouver votre copie de src.zip et l'ajouter manuellement au chemin :local/root classe, par exemple en utilisant une entrée

hm, il semble que la chaîne d'appel jdk-sources -> jdk-root ne soit appelée que dans le boot-class-loader sinon c'est (.getContextClassLoader (Thread/currentThread)) ,

J'ai forcé le zip sur le classpath au moyen de project.clj

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

et vérifié 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>

toujours pas de doc

Il semble que cela sera interrompu sur Java 11 jusqu'à ce que https://github.com/clojure-emacs/orchard/issues/20 soit corrigé.
Java 8 devrait fonctionner cependant. Vous aurez besoin à la fois de src.zip et de tools.jar sur le chemin de classe qui devrait être ajouté automatiquement. Ensuite, vous pouvez essayer quelque chose comme ce qui suit (sur le cidre 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)

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Merci pour votre contribution et votre compréhension !

@jeffvalk a récemment abordé le problème lié d'Orchard, donc je suppose que nous pouvons fermer celui-ci.

Sur Debian 10, tout ce que j'avais à faire était d'installer openjdk-11-source . Je suis allé essayer de créer src.zip lien symbolique

Sur Ubuntu 18.04 avec Emacs 26.3 CIDER 0.24.0 nREPL 0.6.0 Java 1.8.0_242 j'ai ajouté un répertoire contenant un zip avec des sources Java comme ressource au profil Leiningen ( ~/.lein/profiles.clj ):

{:user {:resource-paths ["/usr/lib/jvm/openjdk-8"]}}
Cette page vous a été utile?
1 / 5 - 1 notes