Cider: CIDER zeigt keine Dokumente für Java an

Erstellt am 17. Apr. 2018  ·  17Kommentare  ·  Quelle: clojure-emacs/cider

Erwartetes Verhalten

image

Tatsächliches Verhalten

image

Umgebungs- und Versionsinformationen
CIDER-Versionsinformationen
;; Verbunden mit nREPL-Server - nrepl://localhost :59990
;; CIDER 0.17.0Snapshot (Paket: 20180413.51), nREPL 0.2.13
;; Clojure 1.8.0, Java 9.0.4
Lein/Boot-Version
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.8.0
BOOT_VERSION=2.7.2

Emacs-Version
27.0.50

Betriebssystem
Mac OS

bug stale

Alle 17 Kommentare

Wie Sie sehen, wird das Symbol auch fälschlicherweise für java.lang.Character/toUpperCase anstelle von lang.String aufgelöst.

Sie werden nicht gefragt, welche Version Sie wählen sollen?

@bbatsov Seltsamerweise ist es heute so (was viel besser ist 😂):
image

Ich habe es überprüft und erhalte die Eingabeaufforderung, wenn ich den Standard-Hotkey verwende (in Spacemacs ist es , h h im bösen-normalen-Zustand), aber nicht, wenn ich diesen Hotkey verwende, den ich selbst konfiguriert habe:

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

Dieser Hotkey überspringt irgendwie die Eingabeaufforderung und zeigt nur die Dokumente für das Zeichen an.

Übrigens, der Hinweis von eldoc könnte auch etwas Arbeit gebrauchen, z. B. eine Trennung zwischen den Argumenten der verschiedenen Methoden:
image

Wir konnten keine gute Trennung herausfinden, deshalb haben wir einfach die Signaturen aller möglichen Versionen gemischt. Es ist ideal, aber leider kann ich auch nicht sehen, wie das verbessert werden kann. Eldoc muss eine ver-String-Struktur haben, sonst würde die Hervorhebung von Parametern dort brechen.

@bbatsov Ich habe gerade meinen Emacs neu gestartet und die Javadocs sind wieder verschwunden. :(
image

Ich frage mich, ob sich die Dinge für Sie ändern, wenn Sie Java 8 anstelle von 9 ausprobieren. Ich hatte nicht viel Zeit, um mit Java 9 zu spielen, und ich frage mich, ob einige der Klassenpfad-Manipulationen, die wir durchführen, dort nicht richtig funktionieren oder so. Stellen Sie außerdem sicher, dass der Codepuffer ausgewertet wurde, bevor Sie eldoc/cider-doc ausprobieren).

@bbatsov Ich bin auf Java 8
Und ich habe gerade verstanden, dass du die Person bist, die diesen Vortrag hält ^__^ Irgendwie sah dein Avatar auf mich so aggressiv aus und das hat mich irgendwie überrascht :)) Danke für deine Arbeit ;)

Haha!

Und ich dachte, das wäre mein glückliches Gesicht! 😄

Hallo, (Emacs/Cider Anfänger hier)

Wo in der allgemeinen Cider/ROADMAP ist dieser Fehler positioniert?

Ist es mehr

  • Niemand hat Zeit, daran zu arbeiten
  • es wird mit/durch Obstgarten gelöst
  • es funktioniert wie gewünscht
  • das soll jetzt nicht gehen?

Jedes Mal, wenn ich etwas Zeit damit verbringe, clj/emacs zu lernen, möchte ich am Ende nach einer Klasse suchen und bin frustriert - was ganz bei mir liegt, aber ich frage mich immer wieder:

Ist mein Setup falsch oder kaputt, oder müssen "echte" Clojure-Entwickler nie ein Javadoc nachschlagen - was für mich ziemlich verblüffend wäre.

Mein Testfall soll über cider-doc java.util.concurrent.PriorityBlockingQueue suchen, was zu https://imgur.com/a/TaQXfpS führt .


Kurzum: Ist das nur für mich oder für alle kaputt und wie kommen die Leute ohne zurecht?

PPS: Ich habe es mit Java 8 - 11 versucht, wobei java-doc und java-src installiert sind


Ausgänge:

in einer klasse

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.

auf eine Methode

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

For additional documentation, see the Javadoc.

Definition location unavailable.

Fortschritt !

Ich denke folgendes passiert


Prämisse: Ich verwende spacemacs, das Cider von MELPA verwendet, derzeit 0.20.0 + Cider-nrepl 0.20.0

Apfelwein-nrepl 0.20.0 verwendet Obstgarten 0.3.1


Problem:

orchard erkennt Java-Quellen mittels jdk-sources -> jdk-resource-url und kritisch -> 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)

Auf meinem System (archlinux) und im Ubuntus openjdk-11-jre-headless_11.0.1+13-2ubuntu1_amd64 Paket scheint es, dass die Javas als Ordner unter /usr/lib/jvm

dh

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

oder 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 einer Demo ist emacs/cider repl java.home zB:

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

_Ich weiß nicht, ob etwas von außen dies durchgibt oder ob es das Standard-Home des aktuellen Javas ist._

Wenn ich mich nicht irre, würde das bedeuten, dass auf meinem System jdk-root ist

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

was dazu führt, dass jdk-resource-url Dinge im falschen (übergeordneten) Ordner nachschlägt


Abschluss:

jdk-roots "Das JDK-Stammverzeichnis (übergeordnet des java.home JRE-Verzeichnisses)" Kommentar / Prämisse scheint falsch zu sein (ich habe schnell online nachgesehen und es scheint keinen "Standard" zu geben, was java. Zuhause soll es wirklich sein)

Hilft das jemandem?

Ja, es hilft! Durch Java 8 zeigt die Systemeigenschaft java.home auf eine JRE im JDK-Root. Dies wird gemäß https://docs.oracle.com/javase/7/docs/technotes/tools/linux/jdkfiles.html erwartet

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

Ab Java 9 ist das JRE-Unterverzeichnis weg und sein Inhalt wird eine Ebene höher im JDK-Root zusammengeführt, auf das java.home jetzt zeigt:

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

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

Als Nebenbemerkung für Benutzer von Debian-abgeleiteten Distributionen installiert das openjdk-11-source Paket einen defekten Symlink zu src.zip (siehe https://bugs.launchpad.net/ubuntu/+source/openjdk-lts /+Fehler/1791219)
Nach der Installation habe ich:

$ 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

Es scheint, als ob orchard an beiden Stellen überprüfen sollte, ob src.zip lesbar ist. Es wäre auch schön, wenn nicht eine Squelchable-Warnung an STDERR auszugeben.
Ich würde gerne eine PR einreichen, wenn das vernünftig klingt.

In der Zwischenzeit können Sie Ihre Kopie von finden src.zip und fügen Sie den Classpath manuell, zB mit einem :local/root deps.edn Eintrag (wenn Sie auf tools.deps https geschehen sein: / /clojure.org/reference/deps_and_cli#_dependencies).

hm, es scheint, dass die Aufrufkette jdk-sources -> jdk-root nur im Boot-Class-Loader aufgerufen wird, ansonsten ist es (.getContextClassLoader (Thread/currentThread)) ,

Ich habe die ZIP-Datei im Klassenpfad mithilfe von project.clj . erzwungen

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

und überprüft über

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

immer noch kein doc

Es sieht so aus, als ob dies unter Java 11 kaputt geht, bis https://github.com/clojure-emacs/orchard/issues/20 behoben ist.
Java 8 sollte aber funktionieren. Sie benötigen sowohl src.zip als auch tools.jar im Klassenpfad, der automatisch hinzugefügt werden soll. Dann könnten Sie etwas wie Folgendes versuchen (auf 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)

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihren Beitrag und Ihr Verständnis!

@jeffvalk hat kürzlich das verlinkte Orchard-Problem angesprochen, also denke ich, dass wir dieses schließen können.

Unter Debian 10 musste ich nur openjdk-11-source installieren. Ich versuchte, src.zip zu symbolisieren und stellte fest, dass es bereits erstellt wurde.

Unter Ubuntu 18.04 mit Emacs 26.3 CIDER 0.24.0 nREPL 0.6.0 Java 1.8.0_242 habe ich ein Verzeichnis mit einer ZIP-Datei mit Java-Quellen als Ressource zum Leiningen-Profil hinzugefügt ( ~/.lein/profiles.clj ):

{:user {:resource-paths ["/usr/lib/jvm/openjdk-8"]}}
War diese Seite hilfreich?
1 / 5 - 1 Bewertungen

Verwandte Themen

dpsutton picture dpsutton  ·  32Kommentare

drguildo picture drguildo  ·  26Kommentare

bbatsov picture bbatsov  ·  18Kommentare

jaccarmac picture jaccarmac  ·  21Kommentare

expez picture expez  ·  28Kommentare