Methodenübersicht einer Klasse einsehen

Mahoni84

Mitglied
Hallo zusammen,

hat jemand einen guten Tipp, wo man sich die Methoden einer importierten Klasse anschauen kann und wie diese implementiert werden?
Ich finde die Java Api extrem unübersichtlich und würde gerne auf etwas anderes ausweichen.
Hintergrund:
Ich habe in meiner letzten Hausaufgabe fast den Fehler gemacht und File.getPath() benutzt statt File.getAbsolutePath()...

Viele Grüße
 
Hi erstmal danke für deine Antwort,

Ich verwende Eclipse, der shortcut STRG + Leertaste ist mir bekannt (für die automatische Vervollständigung)...

gibt es eventuell noch etwas anderes?
 
Es ist ja auch die Beschreibung wichtig. Daher würde ich bei der API immer auf die JavaDoc verweisen. (Einige Entwicklungsumgebungen blenden das auch ein, aber das ist halt immer etwas beschränkt). Eclipse nutze ich nicht, daher kann ich dazu nichts sagen.

Im Browser ist die Java Dokumentation aber sehr gut abrufbar, z.B. zu Java 17: Overview (Java SE 17 & JDK 17) (oracle.com)

Evtl. ist es dann hilfreich, in einem Browser-Tab die Dokumentation zu öffnen (wenn es innerhalb der IDE sein soll) oder evtl. gibt es diesbezüglich auch Plugins, die da den schnellen Aufruf z.B,. für eine Klasse erlauben.
 
Die Dokumentation direkt im Webbrowser. Wenn die Klassen des Frameworks noch nicht bekannt sind, dann hilft zuerst eine Suche per Google.

Wichtig ist halt, dass man sich sowas richtig erarbeitet. Man mag ein Codeschnipsel finden (Google, ChatGPT, …), der das eigentliche Problem löst, aber an der Stelle sollte es nicht enden.

Es ist wichtig, sich das dann zu erarbeiten: was machen die Klassen genau? Gibt es evtl. Alternativen? Man sollte da also mehr Zeit investieren um zu lernen.

Foren sind da übrigens auch eine gute Übung: was für Fragen haben andere? Kannst du die Frage beantworten? Da kann man also das auch alles machen. Und dann kannst du schauen, was Andere so vorschlagen. Da lernt man dann auch sehr gut neue Klassen kennen.

Wichtig ist dabei aber immer die Praxis: wenn du eine neue Klasse kennen lernen willst, dann nutze diese. Spiele wirklich damit herum!
 
In Eclipse kann man für jede Bibliothek angeben unter welcher URL, Pfad oder Archiv die JavaDoc's zu finden sind. Deutlich komfortabler wird es, wenn man mit Maven arbeitet, dann werden die Quellen und JavaDoc automatisch eingebunden und wenn nötig heruntergeladen. Aktualisieren ist auch möglich, falls mal irgendwas unvollständig oder beschädigt heruntergeladen wurde. Die Anzeige kann dann innerhalb von Eclipse oder im Browser erfolgen, JavaDoc ist auch per Tooltip und in einer separaten View verfügbar.
 
Maven ist einfach ein Build Tool. In dem Build Tool wird das Projekt mit einer XML Datei beschrieben.
Ein paar wichtige Punkte dabei sind:
  • Alle üblichen Entwicklungsumgebungen unterstützen Maven. Damit kann jeder Entwickler mit der Umgebung arbeiten, die er möchte.
  • Abhängigkeiten müssen nicht auf dem System parat gestellt werden. Abhängigkeiten werden automatisch aus sogenannten Repositories herunter geladen.
  • In den Repositories sind üblicherweise nicht nur die reinen Java Abhängigkeiten sondern auch die Sourcen und die JavaDoc Dokumentation. Dadurch kann eine Entwicklungsumgebung auch auf diese zugreifen, was z.B. beim Debuggen sehr hilfreich sein kann.
 
Vielen Dank ihr beiden,

ich werde erstmal mehr zum maven mit Eclipse recherchieren...

Frage Debuggen:
Ich bin bei der Prüfung mit den Exceptions und dem Debuggen mit einer eins durchgekommen, muss aber ehrlich gestehen, dass ich nicht
wirklich ein Fan davon bin, denn selbst wenn die Möglichkeit besteht, zwischen dem schrittweisen und überspringenden Debuggen wählen zu können, läuft man sehr schnell Gefahr sich in Schleifen von übergeordneten Superklassen zu verlieren und versuche daher immer möglichst nach den ausgelösten Fehlermeldungen, meinen Quellcode zu korrigieren.
Ist es für euch undenkbar, bei der täglichen Arbeit mit Java auf das Debuggen zu verzichten?
 
Debugger sind bei der Fehlersuche unverzichtbar. Man muss natürlich nicht alles debuggen, dass ist meistens etwas zeitraubend. Mit der Zeit bekommt man einfach die Erfahrung und kann auch oft in Gedanken verfolgen, was das Programm gerade tut. Meist nutze ich den Debugger, wenn ich nach konkreten Problemen suche. Dann ist es hilfreich, wenn man die bedingten Haltepunkte verwendet, also das Programm stoppt z.B.: nach 1000 Schleifendurchläufen, wenn eine Variable einen bestimmten Wert angenommen hat, wenn eine bestimmte Variable den Wert null hat oder wenn eine bestimmte Exception auftritt.
 
Also Debugging hat in meinen Augen massiv an Wert verloren über die letzten Jahre / Jahrzehnte. Damals war es mit das Tool zur Fehlersuche als Entwickler, Aber mit den Unit Tests ist dies immer weiter in den Hintergrund getreten. Den Debugger nutze ich sehr selten. Es ist einfach ein zu zeitaufwändiges Tool. Man geht dann gewisse Stellen Schritt für Schritt durch und schaut sich die konkreten Werte in diversen Variablen an - das kostet enorm Zeit. Und meist ist das Resultat nur, dass bei Unit Tests schlicht geschlampt wurde und ein Case nicht beachtet wurde. Seltener, dass die generelle Logik / Spezifikation falsch verstanden wurde, Das ist zumindest meine Erfahrung, weshalb der Debugger überbewertet ist.

Und wenn es dazu kommt, dass der Debugger genutzt werden muss: Dann mache ich dies auch nur zusammen mit Tests. Das bedeutet ich starte nicht die Anwendung, um dann zu dem Punkt zu navigieren, wo ich dann debuggen möchte. Statt dessen schaffe ich mir die Daten einmalig in Code und nutze dann den Aufruf. Das ist dann natürlich kein Unit Test mehr, da keine Unit mehr getestet wird sondern ein ganzes Modul. Das vereinfacht das Starten des Debuggers deutlich. Und hat den Vorteil, dass eine Fehlersituation einmal nachgestellt wurde. Den Test lasse ich dann auch drin, denn nichts in peinlicher, als wenn ein Problem (evtl. in anderer Ausprägung) erneut auftritt. Das ist Kunden kaum zu vermitteln.

Das nur als kleiner Hinweis. Ehe man zu viel Zeit mit dem Debugger zubringt macht es evtl. mehr Sinn, mehr Zeit in das Schreiben von Tests zu investieren.
 
Debugging wird dann wichtig, wenn man wirklich Strange Dinge, die man nicht erklären kann und die man auch mit Tests nicht nachgestellt bekommt - bzw. nachgestellt bekommt, aber nicht versteht warum es schiefgeht.

In der Regel debugge ich fremden Code, Bibliotheken oder ähnliches. Also Code, der nicht unter meiner Kontrolle steht. Bei meinem eigenen Code kann ich zum einen mit Tests mehr sicherstellen und auch den Code so bauen, dass er isoliert testbar ist

Meine letzte Debugging Session war wie bei jax-rs Resteasys in einem wildfly 27 Container den Objectmapper für die Serialisierung/Deserialisierung eines Json sucht, wenn man Jax-Rs als Client verwendet. (Fragt nicht warum ....)
 

Zurück
Oben