• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Java: Verwendung von package

Cyrics

Neuer Berner Rosenapfel
Registriert
01.04.05
Beiträge
1.973
Ich wollte ein Programm schreiben wo ich eine abstrakte Klasse bilde, die eine Klasse abgeleitet. Die Abstrakte Klasse heisst Strassenfahrzeug und die abgeleitete Klasse Auto.
Die Quelltexte sind fehlerfrei. Ich will diesen Klassenverbund noch etwas stärker erweitern und das Ganze als package fahrzeug zusammen fassen um dieses package dann nur noch der Ausführbaren importiert.

Dabei hab ich bei meiner abstrakten Klasse geschrieben:
Code:
package fahrzeug;
genau das Gleiche bei meiner abgeleiteten Klasse.

Bei meiner Ausführbaren AutoTest hab ich dann geschrieben
Code:
import fahrzeug.*;

Auto basiert nun auf den Prototypen und Variablen, die in Strassenfahrzeug definiert sind. Strassenfahrzeug wird ohne Probleme kompiliert und Auto bricht dann mit Fehlermeldungen ab, weil es die Methoden und Variablen nicht kennt, die in Strassenfahrzeug deklariert sind, obwohl explizit ja per extends Strassenfahrzeug verwiesen wird. Beide liegen im gleichen Verzeichnis.
Nehm ich nun die Package-Verweise überall heraus und kompiliere neu, gibt es keine Fehler.
Also wo liegt der Fehler bzw. der fehlerhafte Gedanke wie mit Package umgegangen werden sollte?!
Ich würde das eben gerne alles explizit zu einem Package zusammen fassen wollen.

Danke schonmal für die Hilfestellung
 

quarx

Brauner Matapfel
Registriert
17.04.05
Beiträge
8.444
Ist der zusätzliche import-Befehl nicht überflüssig, innerhalb eines Packages?

Edit: Oder ist das Testprogramm ausserhalb des Packages? Ansonsten würde ich (wie Low Peack) mal die Verzeichnisstruktur prüfen.
 

Low Peack

Gast
Es wäre hilfreich die Fehlermeldung zu kennen die ausgegeben wird, so kann man nur Vermutungen anstellen.

Meine Vermutung ist das die Dateien nicht in den richtigen Verzeichnissen sind.
Wenn dich eine Klasse in dem Package "fahrzeug" befindet muss sie auch in einem Unterordner namens "fahrzeug" liegen.

Gruß
 

Cyrics

Neuer Berner Rosenapfel
Registriert
01.04.05
Beiträge
1.973
also das Testprogramm soll natürlich außerhalb dieses Packages. Ich will das Package nur mit der kompletten Verwaltungsumgebung und das Testprogramm soll dann nur noch das Package importieren und anwenden.

Ich hab den Ordner auch "fahrzeug", also wie das Package, genannt.
Alle drei Dateien liegen im selben Verzeichnis. Vielleicht ist das ja der Fehler...

Wie gesagt bei Strassenfahrzeug gibt es keine Probleme...
wenn ich Auto kompiliere und dabei die "package fahrzeug;"-Anweisung drin lasse kommt folgende Fehlermeldung:
Auto.java:11: cannot find symbol
symbol: class StrassenFzg
public class Auto extends StrassenFzg
^
Auto.java:23: cannot find symbol
symbol : variable bez
location: class fahrzeug.Auto
bez = eingabe.readLine();
^
Auto.java:27: cannot find symbol
symbol : variable geschw
location: class fahrzeug.Auto
geschw = Short.parseShort(eingabe.readLine());
^
Auto.java:37: cannot find symbol
symbol : variable bez
location: class fahrzeug.Auto
System.out.println("\nDas Auto ist ein "+bez);
^
Auto.java:39: cannot find symbol
symbol : variable geschw
location: class fahrzeug.Auto
System.out.println("Der Top-Speed: "+geschw);
^
Auto.java:40: cannot find symbol
symbol : variable verliehen
location: class fahrzeug.Auto
if (verliehen)
^
6 errors

Die Quelltexte dazu:

// StrassenFzg.java
//
//
// Created by Torsten on 17.06.06.
// Copyright 2006. All rights reserved.
package fahrzeug;

abstract class StrassenFzg
{
protected String bez;
protected short geschw;
protected boolean verliehen;
abstract boolean anzeigen();
abstract boolean eingeben();

public boolean verleihen()
{
if(verliehen)
return false;
else {
verliehen = true;
return true;
}
}
}

Auto.java
// Auto.java
//
//
// Created by Torsten on 17.06.06.
// Copyright 2006. All rights reserved.
//
package fahrzeug;
import java.io.*;

public class Auto extends StrassenFzg
{
public short plaetze;
public boolean eingeben()
{
InputStreamReader daten;
daten = new InputStreamReader(System.in);
BufferedReader eingabe;
eingabe = new BufferedReader(daten);
try
{
System.out.print("Bezeichnung: ");
bez = eingabe.readLine();
System.out.print("Sitzplaetze: ");
plaetze = Short.parseShort(eingabe.readLine());
System.out.print("Geschwindigkeit: ");
geschw = Short.parseShort(eingabe.readLine());
return true;
}
catch (Exception e)
{
return false;
}
}
public boolean anzeigen()
{
System.out.println("\nDas Auto ist ein "+bez);
System.out.println("Es hat "+plaetze+" Sitze.");
System.out.println("Der Top-Speed: "+geschw);
if (verliehen)
System.out.println("Es ist verliehen.");
else
System.out.println("Es ist nicht verliehen.");
return true;
}
}

Der Quelltext macht eben keine Probleme solange die Package-Anweisung auskommentiert ist. Aber wenn sie drin steht, kennt Auto plötzlich nicht mehr seine Oberklasse Strassenfahrzeug.
 

quarx

Brauner Matapfel
Registriert
17.04.05
Beiträge
8.444
Macht es etwas, dass die Klasse StrassenFzg und ihre Methoden nicht als public deklariert sind? o_O
 

Cyrics

Neuer Berner Rosenapfel
Registriert
01.04.05
Beiträge
1.973
nee, ich hatte auch erst aus Unsicherheit erst wieder alles public gesetzt, aber brauch man auch überhaupt nicht.
abstract bildet ja die Oberklasse. Alles ihr unterteiltes kann also auf die Methoden zugreifen. Genauso wie protected eigentlich das Gleiche für Variablen bedeutet.
Also ich hab anstelle von public das Ganze soweit eingeschränkt, dass es eben nicht mehr public zur Verfügung steht, sondern nur von den Klassen, die auch zum Klassenverbund und (hoffentlich irgendwann) zum package fahrzeug gehören.
 

quarx

Brauner Matapfel
Registriert
17.04.05
Beiträge
8.444
Cyrics schrieb:
nee, ich hatte auch erst aus Unsicherheit erst wieder alles public gesetzt, aber brauch man auch überhaupt nicht.
abstract bildet ja die Oberklasse. Alles ihr unterteiltes kann also auf die Methoden zugreifen. Genauso wie protected eigentlich das Gleiche für Variablen bedeutet.
Also ich hab anstelle von public das Ganze soweit eingeschränkt, dass es eben nicht mehr public zur Verfügung steht, sondern nur von den Klassen, die auch zum Klassenverbund und (hoffentlich irgendwann) zum package fahrzeug gehören.
Diese Vorgehensweise wirkt auf mich irgendwie etwas unsauber, ich kann mir nicht helfen. Die "public"-Deklaration wegzulassen führt ja normalerweise dazu, dass die Methoden privat sind. Das willst Du aber nicht. Funktioniert das Beispiel mit public?
 

Demo

Süssreinette (Aargauer Herrenapfel)
Registriert
02.04.04
Beiträge
411
Kompiliert ohne Probleme durch. Mit was kompilierst Du denn ? Von Hand mit javac ?
 

Cyrics

Neuer Berner Rosenapfel
Registriert
01.04.05
Beiträge
1.973
ja, wollte das nur mit Konsole hinkriegen.
Bei eclipse funktioniert das auch wunderbar... aber eclipse...kann ich mich nicht mit anfreunden.
Hast du irgendwas an der Ordner-Struktur geändert, oder auch beides in den selben Ordner?
Welche Java-Version hast du denn sonst?
 

Demo

Süssreinette (Aargauer Herrenapfel)
Registriert
02.04.04
Beiträge
411
Die Ordner Struktur ist folgende:

fahrzeug/
- Auto.java
- StrassenFzg.java

Java:

Code:
$> java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-83)
Java HotSpot(TM) Client VM (build 1.5.0_05-48, mixed mode, sharing)

Compiliert:

Code:
$-apfeltalk_java: > javac fahrzeug/Auto.java
 
  • Like
Reaktionen: Cyrics

quarx

Brauner Matapfel
Registriert
17.04.05
Beiträge
8.444
Bei mir geht's auch einwandfrei. Alles im Ordner "fahrzeug", mit
Code:
~/test/cyrics$ java -version
java version "1.4.2-03"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-03)
Java HotSpot(TM) Client VM (build Blackdown-1.4.2-03, mixed mode)
Allerdings unter Linux... :innocent:
 

Cyrics

Neuer Berner Rosenapfel
Registriert
01.04.05
Beiträge
1.973
das versteh ich nun überhaupt nicht... wenn ich im Ordner fahrzeug drin bin und per javac kompiliere, dann kommen die Fehler.
Wechsel ich in den übergeordneten Ordner und rufe javac mit dem Unterordner und der darin enthaltenen Auto.java auf wie es Demo tat, dann krieg ich keinen Fehler...

muss ich das verstehen? Muss ich jetzt immer in den übergeordneten Ordner wechseln um sicher zu gehen?! :eek:
 

quarx

Brauner Matapfel
Registriert
17.04.05
Beiträge
8.444
Cyrics schrieb:
muss ich das verstehen? Muss ich jetzt immer in den übergeordneten Ordner wechseln um sicher zu gehen?! :eek:
Geht das überhaupt anders? Ich mach das auch immer so, vom Ober-Ordner aus... :oops:
 

Cyrics

Neuer Berner Rosenapfel
Registriert
01.04.05
Beiträge
1.973
ich hab bisher immer aus dem gleichen Verzeichnis heraus kompiliert und es gab noch nie Probleme... bis ich auf package gestoßen bin... unglaublich! Und ich dachte ich hätte Java verstanden! :oops:
 

Demo

Süssreinette (Aargauer Herrenapfel)
Registriert
02.04.04
Beiträge
411
Ganz grob formuliert wuerde ich behaupten, das der Compiler der Verzeichnisstruktur nach arbeit. Soll also eine Klasse K in einem Package p compiliert werden, so beginnt der Compiler nach der Verzeichnisstruktur zu arbeiten, so wie es beim package Prinzip notwendig ist. Wenn man dann allerdings schon im Verzeichnis p ist, findet er es nicht. Sicherlich absolut bescheuert formuliert glaube ich. ;)
 

Cyrics

Neuer Berner Rosenapfel
Registriert
01.04.05
Beiträge
1.973
also ich danke dann einfach mal recht herzlich für die schnelle Hilfe! Nun bin ich immer hin ein ganzes Stück klüger und weiß dann auch beim nächsten mal bescheid :)
 

JMR

Granny Smith
Registriert
17.04.07
Beiträge
12
Demo hat recht. In Java werden Packages immer mit den Dateiordnern gleich gesetzt. Dass man das Package auch weglassen kann, ist eine kleine Hilfestellung, die in der Praxis aber eigentlich nie verwendet wird. In diesem Fall wird alles in ein nicht sichtbares Default Package einsortiert. Aber alleine schon, um die Klassen eindeutig zu machen, sollte man immer Packages verwenden.

Wenn Du ein Package angibst, dann sucht der Compile in einem Ordner mit diesem Namen, ausgehend von dem Ordner, der als Source Verzeichnis angegeben ist (wenn Du keinen angibst nimmt er wahrscheinlich den Ordner, in dem Du den Compiler startest).

Solltest Du häufiger Java programmieren, kann ich Dir nur dringend eine gute Entwicklungsumgebung wie Eclipse oder IntelliJ ans Herz legen, damit ist man um ein Mehrfaches produktiver, als mit dem Texteditor und dem Compiler auf der Commandozeile
 

ulukaii

Idared
Registriert
22.02.07
Beiträge
28
Die "public"-Deklaration wegzulassen führt ja normalerweise dazu, dass die Methoden privat sind.

Errg. No.

In Java gibt's 4 verschiedene "Sichtbarkeitsstufen":

Code:
//nur innerhalb der selben Klasse
private

//innerhalb des selben Packages 
<default>

//innerhalb von abgeleiteten Klassen
protected

//offen für alles und jeden
public

Aber schaut doch selbst: http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html

@quarx: Sorry, aber dass konnte ich nicht so stehen lassen ;)
 
  • Like
Reaktionen: quarx

quarx

Brauner Matapfel
Registriert
17.04.05
Beiträge
8.444
Hmm, stimmt. Ich schrob
meinereiner schrieb:
Die "public"-Deklaration wegzulassen führt ja normalerweise dazu, dass die Methoden privat sind.
Das gilt zwar, aber nur für die Methoden-Modifier. Du hast völlig Recht, i.A. wirken die Modifier etwas diffiziler. Danke für die Klarstellung. ;)

Edit: Aber mit Modifiern find ich's trotzdem sauberer als ohne.
 

ulukaii

Idared
Registriert
22.02.07
Beiträge
28
Solltest Du häufiger Java programmieren, kann ich Dir nur dringend eine gute Entwicklungsumgebung wie Eclipse oder IntelliJ ans Herz legen, damit ist man um ein Mehrfaches produktiver, als mit dem Texteditor und dem Compiler auf der Commandozeile

Right. Xcode ist allerdings auch nicht zu vernachlässigen. Hab auch zunächst mit Eclipse angefangen, weil's halt auf allen Platformen verfügbar ist. Hat man sich erstmal in Xcode eingearbeitet, so will man (zumindest ich) nie wieder eine andere IDE anfassen :-D

(mag sein, dass ich gerade etwas übertreibe)

Zudem beschäftige ich mich gerade intensiv mit Ant. Darüber lässt sich so gut wie alles automatisieren.