Eigene Klassen einbinden

[javanewbie]

Ich habe früher in C++ programmiert und steige nun nach längere Pause auf Java um. Allerdings habe ich nun ein Problem. Wie werden Klassen bei anderen Klassen eingebunden? In C++ ging das über #include bruch.h
(meine ich mich zu erinnern). Aber wie geht das in Java.

Ich habe beispielsweise folgendes Problem: Ich möchte in mein bruchrechnen.java mit der Klasse Bruchrechnen die Klasse Bruch benutzen können, damit ich Brüche als Typ zu Verfügung habe. Wie geht das?

Und noch was: Was sollen "interface" sein? Sind die die Methoden einer Klasse mein "Interface" von dieser Klasse?

Danke, Javanewbie

[Kadir]

Hi,

Ich habe früher in C++ programmiert und steige nun nach längere Pause auf Java um. Allerdings habe ich nun ein Problem. Wie werden Klassen bei anderen Klassen eingebunden? In C++ ging das über #include bruch.h
(meine ich mich zu erinnern). Aber wie geht das in Java.

Ich habe beispielsweise folgendes Problem: Ich möchte in mein bruchrechnen.java mit der Klasse Bruchrechnen die Klasse Bruch benutzen können, damit ich Brüche als Typ zu Verfügung habe. Wie geht das?

Und noch was: Was sollen "interface" sein? Sind die die Methoden einer Klasse mein "Interface" von dieser Klasse?

Danke, Javanewbie

Naja ich hatte als erste Sprache VB, das war ja ein Schock.... Zum Problem: Du musst eine INSTANZ der Klasse Bruch erstellen. Falls die 2 Klassen im gleichen Package sind, kannst du folgenden Code verwenden:

private MySql clsSql = new MySql();
// clsSql ist die Instanz der Hauptklasse MySql
// mit clsSql arbeitest du dann...

Und was Interfaces sind, hab ich schon vergessen 8-)

mfg

[Slyh]

Hallo,

In C++ ging das über #include bruch.h (meine ich mich zu erinnern).
Aber wie geht das in Java.

Dieses Header-File-Geraffel ist in Java nicht notwendig. Es gibt nur
.class-Dateien. Der Compiler ist klug genug selbst zu wissen, welche
Schnittstellen eine Klasse definiert.

Du mußt einzig ein import im Klassenkopf angeben, wenn du eine andere
Klasse verwenden möchtest. Verwende hier den vollqualifizierten
Name (also inkl. Package) oder die Stern-Notation, wenn du alle
Klassen eines Package importieren willst.

Verwende eine anständige Entwicklungsumgebung, beispielweise Eclipse,
und schon kümmert sich die um die Importe.

Ich habe beispielsweise folgendes Problem: Ich möchte in mein bruchrechnen.java mit der Klasse Bruchrechnen die Klasse Bruch benutzen können, damit ich Brüche als Typ zu Verfügung habe. Wie geht das?

import mein.tolles.package.Bruch;

Das war's.

Und noch was: Was sollen "interface" sein? Sind die die Methoden einer Klasse mein "Interface" von dieser Klasse?

Nein. Zumindest nicht zwingend. Ein Interface definiert -- wie der
Name schon vermuten läßt -- einzig eine Schnittstelle. In C++ wird
dies üblicherweise durch eine Klasse nachgebaut, die einzig aus
abstrakten (rein-virtuellen) Methoden besteht.

Somit _muß_ die Klasse, die das Interface implementiert, jede der im
Interface definierten Methoden implementieren.
Damit kann man beispielsweise erreichen, daß zur Programmzeit nur die
Schnittstelle der verwendeten Klasse bekannt sind, die eigentliche
Implementierung aber unsichtbar und insbesondere auswechselbar ist.

Nach deinen Frage zu urteilen, solltest du dir dringend ein Java-Buch
besorgen. Davon gibt es mindestens 2 kostenlos, nämlich das Javabuch
und Java ist auch eine Insel. Außerdem sei dir der Java Almanac ans
Herz gelegt.

Gruß
Slyh

[javanewbie]

Du mußt einzig ein import im Klassenkopf angeben, ...

Das habe ich gesucht :-)

Eclipse,

Ich wollte eigentlich erstmal das Prinzip von Java verstehen, bevor ich Hilfmittel verwende, die alles für einen machen. Später werde ich dann schon wechseln.

import mein.tolles.package.Bruch;

Wie kann ich denn ein package erzeugen?

... Java-Buch besorgen.

Ich wusste gar nicht, dass es welche im Netz gibt. Danke für den Tipp.

javanewbie

[Cheatah]

Hi,

Ich wollte eigentlich erstmal das Prinzip von Java verstehen, bevor ich Hilfmittel verwende, die alles für einen machen. Später werde ich dann schon wechseln.

kein schlechter Gedanke. Meiner Erfahrung nach ist der _Einstieg_ in Java aber mit Abstand das Schlimmste (und Grausamste) an dieser Sprache. Ich empfehle Dir, Dich dabei von allem unterstützen zu lassen, was Du findest.

import mein.tolles.package.Bruch;
Wie kann ich denn ein package erzeugen?

package mein.tolles.package;

Oder Rechtsklick > New > Package ;-)

... Java-Buch besorgen.
Ich wusste gar nicht, dass es welche im Netz gibt. Danke für den Tipp.

Das Problem ist nicht, im Netz etwas über Java zu finden. Das Problem ist, aus der überquillenden Masse an Informationen, Codes, Dokus, Projekten, Fragen, Postings, FAQs, Tutorials und was immer man noch so erfinden kann das _richtige_ zu finden. Ich habe noch nie eine Sprache oder Technik gesehen, in der es so schwer ist, einfach nur eine bestimmte Dokumentation zu finden. Mittlerweile bevorzuge ich das Vorhandensein der Quellen sowie den regen Gebrauch der F3-Taste.

Cheatah

[Kadir]

Das Problem ist nicht, im Netz etwas über Java zu finden. Das Problem ist, aus der überquillenden Masse an Informationen, Codes, Dokus, Projekten, Fragen, Postings, FAQs, Tutorials und was immer man noch so erfinden kann das _richtige_ zu finden. Ich habe noch nie eine Sprache oder Technik gesehen, in der es so schwer ist, einfach nur eine bestimmte Dokumentation zu finden. Mittlerweile bevorzuge ich das Vorhandensein der Quellen sowie den regen Gebrauch der F3-Taste.

Ich habe in der Schule Borland JBuilder verwendet. Mittlerweile heisst die freie Edition "Community Edition" oder sowas. Die Umgebung ist 70 MB, weitere 70 MB fallen für die akzeptable Dokumentation an. Eine freie Registrierung ist noch erforderlich.

mfg

[Slyh]

Hallo,

kein schlechter Gedanke. Meiner Erfahrung nach ist der _Einstieg_ in Java aber mit Abstand das Schlimmste (und Grausamste) an dieser Sprache.

Nur wenn man seine Gehirn vorhin mit einer grauenvollen Sprache[tm]
wie C++ oder Perl gequält hat. Nach kurzer Zeit wird einem nämlich
klar, daß ziemlich alles viel besser ist. Spätestens seitdem ich
in C++ einen Corba-Server in einem größeren Projekt (*g*) implementiert
habe, ist mir wieder klar geworden, wie gut Java im Vergleich zu C++
oder Perl oder PHP oder dem meisten anderen ist. Und eigentlich wollte
ich mich dabei mit C++ anfreunden...

Damit kämen wir dann auch gleich zu den Make-Files, von denen ich noch
eine schlechtere Meinung habe... Aber lassen wir das... ;-)

Ich empfehle Dir, Dich dabei von allem unterstützen zu lassen, was Du findest.

ACK. Wobei das nicht heißt, daß man es nicht zu verstehen braucht
oder ignorieren sollte. Nein. Lieber von einem Tool machen lassen,
anschauen und _dann_ verstehen, was da eigentlich abgeht. (Aber darum
wird man ohnehin nie kommen.)

Das Problem ist nicht, im Netz etwas über Java zu finden. Das Problem ist, aus der überquillenden Masse an Informationen, Codes, Dokus, Projekten, Fragen, Postings, FAQs, Tutorials und was immer man noch so erfinden kann das _richtige_ zu finden. Ich habe noch nie eine Sprache oder Technik gesehen, in der es so schwer ist, einfach nur eine bestimmte Dokumentation zu finden. Mittlerweile bevorzuge ich das Vorhandensein der Quellen sowie den regen Gebrauch der F3-Taste.

Eines der größten Mankos der aktuellen Java-Entwicklungsumgebung
ist die fehlende Fähigkeit die Dokumentation der Klassen und Methoden
auch ohne den Quellcode der verwendeten (Fremd-)Software akkurat
anzeigen zu können. In Visual Studio ist das sehr viel schöner
gelöst. Dort reicht ein Druck auf F1, und schon ist man bei der Doku.
Zumindest sofern man diese korrekt einbindet. MSDN ist aber immer da.
(Bei Pascal und Delphi war/ist das auch schon immer so.)

Es sollte einen Zurückübersetzer geben, der aus dem Javadoc-HTML ein
(gerne auch binäres) Format erzeugt, das vollständig integriert in
der IDE verwendet werden kann.
Vielleicht gibt es sowas (oder etwas ähnliches) aber auch, nur ich
weiß nichts davon.

Ihr beschäftigt euch doch gerade exzessiv mit dem Java-Thema. Habt
ihr zu dem Problem, daß die Dokumentation üblicherweise händisch
im externen Browser gesucht werden muß, solange kein Source-Code
zur Verfügung steht, eine adäquat Lösung gefunden?

Ansonsten finde ich zu meinen Java-Problemen, die ohnehin nicht so
häufig sind, meist ziemlich schnell und problemlos über Google eine
passende Lösung. Ich könnte nicht behaupten, daß ich aufgrund der
überquellenden Informationsfülle nichts finden würde.
Gut, sowas wie javabuch.de oder den Almanac muß man halt kennen, weil
man sonst gar nicht weiß, daß es existiert. Aber sonst... nö...

Gruß
Slyh

[Cheatah]

Hi,

kein schlechter Gedanke. Meiner Erfahrung nach ist der _Einstieg_ in Java aber mit Abstand das Schlimmste (und Grausamste) an dieser Sprache.
Nur wenn man seine Gehirn vorhin mit einer grauenvollen Sprache[tm]
wie C++ oder Perl gequält hat.

NACK. C++ kann ich nicht, Perl habe ich schon lange nicht mehr angefasst. Die Vorgängersprache war Python.

Nach kurzer Zeit wird einem nämlich
klar, daß ziemlich alles viel besser ist.

Weder ziemlich alles, noch viel; aber eine Menge um einiges. Nur ist bis zu diesem Moment der Initialaufwand einfach extrem hoch. Danach geht es - aber ich rede hier eben nur vom Einstieg.

Damit kämen wir dann auch gleich zu den Make-Files, von denen ich noch
eine schlechtere Meinung habe... Aber lassen wir das... ;-)

*g*

Ich empfehle Dir, Dich dabei von allem unterstützen zu lassen, was Du findest.
ACK. Wobei das nicht heißt, daß man es nicht zu verstehen braucht
oder ignorieren sollte.

Ja, natürlich.

Eines der größten Mankos der aktuellen Java-Entwicklungsumgebung
ist die fehlende Fähigkeit die Dokumentation der Klassen und Methoden
auch ohne den Quellcode der verwendeten (Fremd-)Software akkurat
anzeigen zu können.

Zustimmung. Wobei natürlich die Frage gestellt werden darf, woher die IDE denn die Doku kennen soll. Die meisten werden aus dem Quellcode erzeugt ... :-)

In Visual Studio ist das sehr viel schöner gelöst.

Das kann ich nicht beurteilen.

Dort reicht ein Druck auf F1, und schon ist man bei der Doku.

Auch von Dingen, die bei der Auslieferung von VS noch nicht bekannt waren?

Es sollte einen Zurückübersetzer geben, der aus dem Javadoc-HTML ein
(gerne auch binäres) Format erzeugt, das vollständig integriert in
der IDE verwendet werden kann.

Auch dazu muss die Doku zunächst einmal bekannt sein. Nur woher? Die Einbindung irgend einen JAR-Files mit diversen CLASS-Dateien lässt noch lange nicht darauf schließen, wo die Verwendung dokumentiert ist - bzw. ob überhaupt.

Ihr beschäftigt euch doch gerade exzessiv mit dem Java-Thema. Habt
ihr zu dem Problem, daß die Dokumentation üblicherweise händisch
im externen Browser gesucht werden muß, solange kein Source-Code
zur Verfügung steht, eine adäquat Lösung gefunden?

Ja: Quellcode suchen! ;-) Bei uns klappt das (meistens), weil wir gewöhnlich nur Projekte verwenden, deren Quellcode uns zur Verfügung steht; sei es nun wegen Open Source oder durch Einkauf. Trotzdem habe ich schon oft genug überlegt, ob ich jetzt wirklich wieder ein externes Projekt auschecken möchte oder es mir doch antue, die Doku im Netz zu suchen. Schön ist es nicht.

Ansonsten finde ich zu meinen Java-Problemen, die ohnehin nicht so
häufig sind, meist ziemlich schnell und problemlos über Google eine
passende Lösung. Ich könnte nicht behaupten, daß ich aufgrund der
überquellenden Informationsfülle nichts finden würde.

Ich hoffe, dass es nicht daran liegt, dass unsere Projekte komplizierter sind, sondern daran, dass Du einfach besser bist - dann besteht nämlich die Chance, dass es mir irgendwann wie Dir geht ;-)

Cheatah

[Slyh]

Hallo,

Nur wenn man seine Gehirn vorhin mit einer grauenvollen Sprache[tm]
wie C++ oder Perl gequält hat.

NACK. C++ kann ich nicht, Perl habe ich schon lange nicht mehr angefasst. Die Vorgängersprache war Python.

OK, Python ist meiner Meinung nach etwas weniger grauenvoll als die
anderen genannten. So richtig kann ich das mangels wirklicher
Erfahrung aber nicht beurteilen.

Aber meine Polemik von oben ist sowieso nicht kommentierungswürdig,
eigentlich. *g*

Weder ziemlich alles, noch viel; aber eine Menge um einiges.

Das hast du schön gesagt. :)

Nur ist bis zu diesem Moment der Initialaufwand einfach extrem hoch. Danach geht es - aber ich rede hier eben nur vom Einstieg.

Auch hier erstmal ein ACK.

Ich habe mich schon öfter gefragt, wie ich Java empfunden hätte, wäre
ich damals nicht so auf C++ fixiert gewesen, obwohl ich es selbst
kaum konnte. Ich fand an Java alles schlimm, weil ich vorher Pascal
und Assembler gewohnt war, und daher dann auch das Pointer-Konzept
und das eigene Aufräumen im Destruktor von C++ etc. ganz toll fand.
Sowas selbst machen zu müssen, erinnert mich jetzt, rückblickend an
Selbstgeißelung. :-)

Einige meiner Kommilitonen haben C++ und Java zur gleichen Zeit
gelernt, und waren von Java begeistert, während sie C++ gehasst
haben. Bei mir war es umgekehrt. Erst viel später wurden mir die
Vorteile von Java klar.

Daher meine Aussage von oben, daß man Java am Anfang nur dann als
komplex empfindet, wenn man vorher eine andere Sprache verwendet hat,
bei der man evtl. mehr selbst machen mußte. (Im Falle von Python
mußte man hingegen vermutlich weniger machen. Das Resultat ist
dasselbe.)
Ich könnte mit meiner Einschätzung völlig falsch liegen...

Zustimmung. Wobei natürlich die Frage gestellt werden darf, woher die IDE denn die Doku kennen soll. Die meisten werden aus dem Quellcode erzeugt ... :-)

Ja, genau. Da für viele Quellen aber bereits Javadoc existiert, wäre
es wünschenswert, wenn aus diesem wieder eine für die IDE lesbare
Dokumentation im eigenen Format generiert werden könnte.
Später, wenn sich das Format etabliert hätte, wäre es natürlich
wünschenswert, wenn es gleich zusammen mit der (Closed-Source-)Software
ausgeliefert werden würde.

In Visual Studio ist das sehr viel schöner gelöst.
Dort reicht ein Druck auf F1, und schon ist man bei der Doku.

Auch von Dingen, die bei der Auslieferung von VS noch nicht bekannt waren?

Soweit ich weiß, ja. Leg mich aber nicht drauf fest. Hier gibt es
sicherlich Teilnehmer, die mit VS mehr (und aktuellere) Erfahrungen
haben.
Ich weiß, daß man aus Quellen irgendwelche Dateien generieren kann,
die sich dann in VS einbinden lassen. Ich bilde mir ein, daß dort
(auch?) die Doku enthalten ist.
Aber, wie gesagt, ich bin mir diesbezüglich nicht sehr sicher.

Es sollte einen Zurückübersetzer geben, der aus dem Javadoc-HTML ein
(gerne auch binäres) Format erzeugt, das vollständig integriert in
der IDE verwendet werden kann.

Auch dazu muss die Doku zunächst einmal bekannt sein. Nur woher? Die Einbindung irgend einen JAR-Files mit diversen CLASS-Dateien lässt noch lange nicht darauf schließen, wo die Verwendung dokumentiert ist - bzw. ob überhaupt.

Dafür muß eine Konvention existieren, klar. Aber wofür gibt es denn
die Manifest-Datei? Dort ließe sich doch eine Dokumentations-Datei
im JAR referenzieren.
Für einzelne Class-Dateien muß dann eben die IDE die Zuordnung
ermöglichen. So handhabt Eclipse dies ja auch heute schon, wenn man
die Sourcen an eine JAR-Datei "bindet".

Soweit zumindest meine Idee.
Vielleicht sollte ich dafür ein Eclipse-Plugin entwickeln... ;)

[Doku im externen Browser vermeiden]

Ja: Quellcode suchen! ;-)

Ich wußte, daß du das sagen würdest! ;-)

Bei uns klappt das (meistens), weil wir gewöhnlich nur Projekte verwenden, deren Quellcode uns zur Verfügung steht; sei es nun wegen Open Source oder durch Einkauf. Trotzdem habe ich schon oft genug überlegt, ob ich jetzt wirklich wieder ein externes Projekt auschecken möchte oder es mir doch antue, die Doku im Netz zu suchen. Schön ist es nicht.

Du meinst, weil das dann bei einem Full (Re)build wieder alles
mitkompiliert werden muß? Ja, das ist wirklich ein Nachteil. (Ich wüßte
jetzt spontan nicht mal, ob man einzelne Projekte aus dem Build-
Vorgang ausschließen kann, und trotzdem noch die Quellen zur
Dokumentation verwenden kann.)
Oder dauert es dir einfach zu lange, das Projekt auszuchecken, wenn
du nur schnell was nachschauen magst?

Ich hoffe, dass es nicht daran liegt, dass unsere Projekte komplizierter sind, sondern daran, dass Du einfach besser bist

Natürlich liegt es einzig und alleine daran! ;-)

Gruß
Slyh

[Cheatah]

Hi,

OK, Python ist meiner Meinung nach etwas weniger grauenvoll als die
anderen genannten. So richtig kann ich das mangels wirklicher
Erfahrung aber nicht beurteilen.

ich finde Python mehr als ordentlich. Eine Sprache, anhand der man wunderbar lernen kann, wie man _richtig_ programmiert.

Aber meine Polemik von oben ist sowieso nicht kommentierungswürdig,
eigentlich. *g*

*g* :-)

Ich habe mich schon öfter gefragt, wie ich Java empfunden hätte, wäre
ich damals nicht so auf C++ fixiert gewesen, obwohl ich es selbst
kaum konnte. Ich fand an Java alles schlimm, weil ich vorher Pascal
und Assembler gewohnt war, und daher dann auch das Pointer-Konzept
und das eigene Aufräumen im Destruktor von C++ etc. ganz toll fand.

Ich behaupte, dass es egal ist, womit man vorher bereits Erfahrung hatte. Für Java braucht man erst mal eine Unmenge Energie, um _überhaupt_ etwas erreichen zu können. Nun ja, andererseits reduziert das die Menge der "'sch mach des so und's funzt"-DAUs.

Sowas selbst machen zu müssen, erinnert mich jetzt, rückblickend an
Selbstgeißelung. :-)

Ja ... :-)

Einige meiner Kommilitonen haben C++ und Java zur gleichen Zeit
gelernt, und waren von Java begeistert, während sie C++ gehasst
haben. Bei mir war es umgekehrt. Erst viel später wurden mir die
Vorteile von Java klar.

Ich finde - in hinreichender Unkenntnis - C++ etwas zu kryptisch, gerade was die Symbolik angeht. Bei Java sind die Sprachkonstrukte sehr viel klarer.

Ich könnte mit meiner Einschätzung völlig falsch liegen...

Nicht, wenn Du sie als subjektiv bezeichnest. Immerhin reden wir von hochkomplexen Dingen, die zwangsläufig unterschiedliche Einstiege seitens der Einsteiger bedingen.

Zustimmung. Wobei natürlich die Frage gestellt werden darf, woher die IDE denn die Doku kennen soll. Die meisten werden aus dem Quellcode erzeugt ... :-)
Ja, genau. Da für viele Quellen aber bereits Javadoc existiert, wäre
es wünschenswert, wenn aus diesem wieder eine für die IDE lesbare
Dokumentation im eigenen Format generiert werden könnte.

Ich bin mir fast sicher, dass das irgend wer schon mal gemacht haben mag. Meiner Ansicht nach ist das aber ein Umweg, den man eher vermeiden sollte - wobei ich nicht glaube, dass Du das anders siehst :-)

Später, wenn sich das Format etabliert hätte, wäre es natürlich
wünschenswert, wenn es gleich zusammen mit der (Closed-Source-)Software
ausgeliefert werden würde.

Das müsste strukturell standardisiert werden, was erfahrungsgemäß nur mit einer gewissen Abhängigkeit geht, welche de facto nicht existiert: Bisher geht's ja wunderbar ohne. Ich hege also Zweifel, dass sich derartiges etablieren lässt. Eher könnte man die Entwickler dazu bringen, die Klassenstrukturen in Form von leeren Rümpfen auszuliefern (was sich ja beispielsweise per UML wunderbar generieren lässt), welche neben den (eh bekannten) Signaturen nur ihre Dokumentation besitzen.

In Visual Studio ist das sehr viel schöner gelöst.
Dort reicht ein Druck auf F1, und schon ist man bei der Doku.
Auch von Dingen, die bei der Auslieferung von VS noch nicht bekannt waren?
Soweit ich weiß, ja. Leg mich aber nicht drauf fest.

Okay, hätte mich auch eher am Rande interessiert (bzw. etwas mehr, wie es denn dann gelöst wäre).

Aber wofür gibt es denn die Manifest-Datei?

Für rein ignorative Zwecke. Nach meiner Beobachtung :-)

Vielleicht sollte ich dafür ein Eclipse-Plugin entwickeln... ;)

Halt mich bitte auf dem Laufenden! :-)

[Doku im externen Browser vermeiden]
Ja: Quellcode suchen! ;-)
Ich wußte, daß du das sagen würdest! ;-)

Es gibt die Theorie, nach der man nur dann Fragen stellen soll, wenn man die Antwort bereits kennt. Insofern also: Herzlichen Glückwunsch :-)

Bei uns klappt das (meistens), weil wir gewöhnlich nur Projekte verwenden, deren Quellcode uns zur Verfügung steht; sei es nun wegen Open Source oder durch Einkauf. Trotzdem habe ich schon oft genug überlegt, ob ich jetzt wirklich wieder ein externes Projekt auschecken möchte oder es mir doch antue, die Doku im Netz zu suchen. Schön ist es nicht.
Du meinst, weil das dann bei einem Full (Re)build wieder alles
mitkompiliert werden muß?

Auch, aber öfter deshalb, weil man eben nicht für _alle_ externen Pakete mehr als nur das JAR-File eingerichtet hat. Oft packt man nur in die project.xml die Abhängigkeit rein, lässt Maven rödeln und gut is' (quasi). Es ist schließlich nicht so, dass es nur zwei, drei Dutzend Pakete gäbe ...

(Ich wüßte
jetzt spontan nicht mal, ob man einzelne Projekte aus dem Build-
Vorgang ausschließen kann, und trotzdem noch die Quellen zur
Dokumentation verwenden kann.)

Das kommt auf den Build-Vorgang an. Bei uns gibt es da nicht mal den Ansatz eines Konfliktes.

Oder dauert es dir einfach zu lange, das Projekt auszuchecken, wenn
du nur schnell was nachschauen magst?

Es muss erst mal gesucht werden.

Ich hoffe, dass es nicht daran liegt, dass unsere Projekte komplizierter sind, sondern daran, dass Du einfach besser bist
Natürlich liegt es einzig und alleine daran! ;-)

*g* ;-)

Cheatah

[Daniel N.]

Hallo,

Es sollte einen Zurückübersetzer geben, der aus dem Javadoc-HTML ein
(gerne auch binäres) Format erzeugt, das vollständig integriert in
der IDE verwendet werden kann.

Ein "Zurückübersetzer" ist absolut unnötig. Die Javadoc-HTML-Dokumentation liegt in einer wohl definierten Struktur vor! Die Struktur ist so angelegt, dass sich der Link zur entsprechenden HTML-Seite bis auf Methoden-Ebene ableiten lässt.
Z.B.:
Die Klasse "de.test.hello.HelloWorld" mit der Methode "sayHello()"
landet in der HTML-Datei im Verzeichnis "de/test/hello/HelloWorld.html#sayHello().

Im Javadoc-Kommentar in der Klasse kann man die Methode wie folgt verlinken:
/**
{@link de.test.hello.HelloWolrd#sayHello()}
*/
javadoc generiert den entsprechenden Link.

Auch wen ich selber Eclipse nutze und die IDE gut finde... Eine gute IDE kann selbsverständlich auch die Api-Dok verwenden!
D. h. die Informationen, die man in Eclipse als gelben "Notizhilfe-Popup" bekommt, sollten auch aus einer javadoc kommen können! Das kann eclipse leider nicht, hier ist ein "Source-Code-Attachment" erforderlich.
Das ist bei anderen IDEs nicht nötig, z. B. JBuilder.

Auch dazu muss die Doku zunächst einmal bekannt sein. Nur woher? Die Einbindung irgend einen JAR-Files mit diversen CLASS-Dateien lässt noch lange nicht darauf schließen, wo die Verwendung dokumentiert ist - bzw. ob überhaupt.

Man benötigt natürlich den Ort, wo die API-Doc abgelet ist.

Dafür muß eine Konvention existieren, klar. Aber wofür gibt es denn
die Manifest-Datei? Dort ließe sich doch eine Dokumentations-Datei
im JAR referenzieren.

Die Manifest-Datei hat andere "Aufgaben" und ist für diesen Zweck nicht geeignet/gedacht.

Für einzelne Class-Dateien muß dann eben die IDE die Zuordnung
ermöglichen. So handhabt Eclipse dies ja auch heute schon, wenn man
die Sourcen an eine JAR-Datei "bindet".

S.o. Das sollte auch ohne Source-Attachment gehen!

[Doku im externen Browser vermeiden]
Ja: Quellcode suchen! ;-)

Bei vielen kommerziellen Produkten bekommt man nicht nur keinen Quelltext, sondert dort sind die Sourcen meistens auch durch einen Obfuscator unlesbar gemacht worden, so dass man keinen Decompiler mehr nutzen kann!

Bei uns klappt das (meistens), weil wir gewöhnlich nur Projekte verwenden, deren Quellcode uns zur Verfügung steht; sei es nun wegen Open Source oder durch Einkauf. Trotzdem habe ich schon oft genug überlegt, ob ich jetzt wirklich wieder ein externes Projekt auschecken möchte oder es mir doch antue, die Doku im Netz zu suchen. Schön ist es nicht.

Mir ist eine vernünftige Schnittstelle mit einer guten Dokumentation wesentlich lieber als in den Quellcode gucken zu müssen!
Eine schlechte und dazu schlecht dokumentierte Schnittstelle lässt ein Produkt in einem sehr schlechtem Licht erscheinen!

Du meinst, weil das dann bei einem Full (Re)build wieder alles
mitkompiliert werden muß? Ja, das ist wirklich ein Nachteil. (Ich wüßte
jetzt spontan nicht mal, ob man einzelne Projekte aus dem Build-
Vorgang ausschließen kann, und trotzdem noch die Quellen zur
Dokumentation verwenden kann.)
Oder dauert es dir einfach zu lange, das Projekt auszuchecken, wenn

"Fremde" Bibliotheken sollten auf gar keinen Fall kompiliert werden, auch wenn es open source ist und man die Sourcen hat!
Das macht keinen Sinn, da es unnötig ist! Bei Java gibt es diese Abhängigkeiten nicht (wie es z. B. bei c++ der Fall ist).

Viele Grüße
Daniel

[Biesterfeld]

Hej,

Eines der größten Mankos der aktuellen Java-Entwicklungsumgebung
ist die fehlende Fähigkeit die Dokumentation der Klassen und Methoden
auch ohne den Quellcode der verwendeten (Fremd-)Software akkurat
anzeigen zu können.

Bin mir nicht ganz sicher ob das gemeint ist, aber weil eben Eclipse in diesem Thread nun öfer genannt wurde, kann ich gesagtes nicht ganz nachvollziehen. In den Projekt Eigenschaften kann ich doch für jede eingebunden Bibliothek eine Javadoc Location angeben. Die *.class-Dateien sind dazu nicht von nöten.

Komfortabler gehts dann m.E. nicht mir, wenn ich beim Schreiben nicht nur alle verfügbaren Methoden und Klassen angezeigt bekomme, sondern auch direkt die Javadoc parrallel angezeigt wird.

Beste Grüße
Biesterfeld

[Slyh]

Hallo,

Bin mir nicht ganz sicher ob das gemeint ist, aber weil eben Eclipse in diesem Thread nun öfer genannt wurde, kann ich gesagtes nicht ganz nachvollziehen. In den Projekt Eigenschaften kann ich doch für jede eingebunden Bibliothek eine Javadoc Location angeben. Die *.class-Dateien sind dazu nicht von nöten.

Du meinst die .java-Dateien.

Ja, man kann dort zwar eine Javadoc-Location angeben, trotzdem wird die
Dokumentation dann aber noch nicht so schön schick als Tooltip angezeigt.
Außerdem wird immer noch ein externer Browser geöffnet, der zudem
nicht das übliche Frameset verwendet, sondern die Dokumentationsdateien
zu der jeweiligen Klasse einzeln anzeigt. Eine Navigation in den
Packages ist damit so direkt nicht möglich. (Außer man klickt im
Kopf wieder auf "Frames", was aber den Nachteil hat, daß die aktuelle
Seite verloren geht.)
Mit Eclipse 3.1M6 ist ja der Help-View dazugekommen. Somit läßt sich
sogar (theoretisch) leicht die Hilfe direkt in Eclipse anzeigen, also
ohne einen externen Browser. Funktioniert nur leider (noch) nicht so
toll.
Aber auch wenn, fehlt noch immer der Tooltip und das Frameset.

Ich hätte gerne, daß sowohl die Dokumentation als Tooltip angezeigt
wird, wie auch die Dokumentation inkl. dem üblichen Frameset im
Browser (ob nun intern oder extern) geöffnet werden kann.

Visual Age für Java konnte das übrigens. Zumindest das mit dem
Frameset. (Tooltips gab's dort keine, glaube ich.) Aber die hatten
auch ihren eigenen Hilfe-Server, der immer zusammen mit Visual Age im
Hintergrund gestartet wurde. Vermutlich war der sogar um die Dokumentation
von Fremdbibliotheken erweiterbar...

Komfortabler gehts dann m.E. nicht mir, wenn ich beim Schreiben nicht nur alle verfügbaren Methoden und Klassen angezeigt bekomme, sondern auch direkt die Javadoc parrallel angezeigt wird.

Doch. Wenn du neben dem Methoden gleich noch die Dokumentation
angezeigt bekommst. :-)

Gruß
Slyh

[Slyh]

Hallo ich, ;-)

Außer man klickt im Kopf wieder auf "Frames", was aber den
Nachteil hat, daß die aktuelle Seite verloren geht.

Wie ich gerade feststelle, gilt die Aussage für die Doku des JDK 1.5
nicht mehr. Dort ist in der Frameset-Datei ein JavaScript, das
zumindest die zuletzt angezeigte Seite wieder lädt. (Die letzte
Position innerhalb der Seite geht aber nachwievor verloren.)

Gruß
Slyh

[Biesterfeld]

Hej Slyh,

In den Projekt Eigenschaften kann ich doch für jede eingebunden Bibliothek eine Javadoc Location angeben. Die *.class-Dateien sind dazu nicht von nöten.

Du meinst die .java-Dateien.

Genau ;)

Ja, man kann dort zwar eine Javadoc-Location angeben, trotzdem wird die
Dokumentation dann aber noch nicht so schön schick als Tooltip angezeigt.

Ich wollts ja nicht glauben, aber du hast recht! Dabei war ich mir eigentlich ziemlich sicher. Allerdings frage ich mich wozu ich dann überhaupt eine Javadoc angeben kann.

Komfortabler gehts dann m.E. nicht mir, wenn ich beim Schreiben nicht nur alle verfügbaren Methoden und Klassen angezeigt bekomme, sondern auch direkt die Javadoc parrallel angezeigt wird.

Doch. Wenn du neben dem Methoden gleich noch die Dokumentation
angezeigt bekommst. :-)

Ähm ... steht das nicht da ;)

Beste Grüße
Biester - der so langsam müde wird - feld

[Daniel N.]

Hi,

Ja, man kann dort zwar eine Javadoc-Location angeben, trotzdem wird die
Dokumentation dann aber noch nicht so schön schick als Tooltip angezeigt.

Man kann zwar eine javadoc-Location angeben, die wird aber nur dazu genutzt, um (z. B. per shift-f2 glaub ich) die Dokumenation im Broser anzuzeigen. Dazu kann der interne Browser oder der Betriebssystem-Browser genutzt werden.

Leider wird bei Code-Completation z. B. nicht die Javadoc-Doku angezeigt. Man bekommt leider z. B. auch nicht die Namen der Parameter einer Methode angezeigt sonder nur z. B. "(String arg0, String arg1)".

Das ist ein echtes Manko von Eclipse. Andere IDEs können das.
Bei Eclipse ist dazu ein Source-Code-Attachment nötig.

Viele Grüße
Daniel

[Daniel Thoma]

Hallo javanewbie,

Ich wollte eigentlich erstmal das Prinzip von Java verstehen, bevor ich Hilfmittel verwende, die alles für einen machen. Später werde ich dann schon wechseln.

Ja, ich denke, das ist empfehlenswert. Wenn man schon einiges an Programmiererfahrung hat, kann man aber auch gleich mit einer IDE loslegen.

Wie kann ich denn ein package erzeugen?

Pakete sind einfach Ordner. Jede java-Datei hat am Anfang ein package-Statement mit dem man angibt, in welchem Pakte die Klasse liegt.

Beispiel:
Name: bla/blub/Klasse.java
Inhalt:
package bla.blub;

public class Klasse {
  ...
}

Ich wusste gar nicht, dass es welche im Netz gibt. Danke für den Tipp.

Von Sun selbst gibt es auch noch ein sehr umfangreiches Tutorial, das auch recht gut ist.
Außerdem gibt es natürlich die API-Specification und falls Du manches ganz genau wissen willst, die Java Language und Java VM Spezification.

Grüße

Daniel

[MudGuard]

Hi,

Du mußt einzig ein import im Klassenkopf angeben, wenn du eine andere
Klasse verwenden möchtest.

Nein, import ist für die Verwendung der Klasse nicht notwendig.
import sorgt nur dafür, daß die Klasse unter Umständen (*) ohne den package-Namen angesprochen werden kann.

Das wirklich notwendige ist, daß die zu verwendende Klasse über den classpath auffindbar ist.

(*) Voraussetzung ist, daß der Klassenname ohne package eindeutig ist.

cu,
Andreas

[Slyh]

Hallo,

Nein, import ist für die Verwendung der Klasse nicht notwendig.
import sorgt nur dafür, daß die Klasse unter Umständen (*) ohne den package-Namen angesprochen werden kann.

Das wirklich notwendige ist, daß die zu verwendende Klasse über den classpath auffindbar ist.

Du hast natürlich vollkommen recht. Sorry.

Gruß
Slyh

[Cheatah]

Hi,

Aber wie geht das in Java.

verwende Eclipse als Entwicklungsumgebung. Dann stellt sich diese Frage sehr viel seltener.

Ich habe beispielsweise folgendes Problem: Ich möchte in mein bruchrechnen.java mit der Klasse Bruchrechnen die Klasse Bruch benutzen können, damit ich Brüche als Typ zu Verfügung habe. Wie geht das?

1.) Bruch meinbruch = new Bruch();
2.) Shift+Strg+O
3.) Fertig. Schritt 2 ist vermutlich nicht mal nötig. Wenn doch, siehst Du das an der roten Unterkringelung.

Cheatah