public interface IndaFaeis {
public static final int KONSTANTE_1=12340;
public static final int KONSTANTE_2=12341;
//Methodenköpfe
public void doSomething(Object o[]);
}
JPKI hat gesagt.:Nein, in Interfaces können nur statische Variablen (ich glaub "final" ist nicht unbedingt nötig) definiert werden.
Sicher können die auch prviat sein... Nur Atrribute halt nicht (also Objektvariablen).
Beispiel:
Code:public interface IndaFaeis { public static final int KONSTANTE_1=12340; public static final int KONSTANTE_2=12341; //Methodenköpfe public void doSomething(Object o[]); }
Dies schafft bzw. erzwingt etwas mehr Ordnung im Code. Dateien kriegen die gleichen Namen wie die darinernst hat gesagt.:Ok.
Kannst du mir den _Sinn_ sagen, warum eine public Klasse in einer eigenen Datei stehen muss?
(Irgendwas müssen die Java-Entwickler dabei gedacht bzw. beabsichtigt haben).
mfg
Ernst
Wie meinst du das?Anonymous hat gesagt.:(die ganze Reflection-API basiert darauf bzw. setzt dies voraus)
Hier ein typisches BeispielMurray hat gesagt.:Wie meinst du das?Anonymous hat gesagt.:(die ganze Reflection-API basiert darauf bzw. setzt dies voraus)
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")
Man kann davon ausgehen, dass irgendeine Jar-Datei oder URI im Classpath diese Klasse enthält.
Ferner ist auch bekannt, dass die Klasse in einem Unterverzeichnis "sun/jdbc/odbc" zu finden
ist und auch tatsächlich den Namen "JdbcOdbcDriver" hat.
All dies ist nur deswegen möglich, da Packages und Klassennamen den oben genannten Konventionen
entsprechen. Wäre dies nicht der Fall, müsste jede Jar-Datei etc. eine Zusammenfassung der darin
enthaltenen Klassen enthalten (ein Mapping von Dateien und Klassen) oder es müsste jede einzelne
Datei untersucht werden, ob sie eine solche Klasse enthält.
Es geht mir nur um den Sinn der ganzen Geschichte. Die Classloaderhierarchie und das eigentliche Laden von KlassenHoaX hat gesagt.:Man kann davon ausgehen, dass irgendeine Jar-Datei oder URI im Classpath diese Klasse enthält.
Ferner ist auch bekannt, dass die Klasse in einem Unterverzeichnis "sun/jdbc/odbc" zu finden
ist und auch tatsächlich den Namen "JdbcOdbcDriver" hat.
du kannst davon ausgehen dass einer der classloader diese klasse laden kann. ob das jetzt ein jarclassloader ist, der seine classen in verzeichnissen ordnet oder ein selbstgeschriebener, der die klassen anhand vom packagenamen von der entsprechenden domain im internet läd ist nicht gesagt. der packagename ist nur eine innere ordnung, wie die klassen geladen werden und wie sie in der quelle stukturiert sind hat damit nichts zu tun.
All dies ist nur deswegen möglich, da Packages und Klassennamen den oben genannten Konventionen
entsprechen. Wäre dies nicht der Fall, müsste jede Jar-Datei etc. eine Zusammenfassung der darin
enthaltenen Klassen enthalten (ein Mapping von Dateien und Klassen) oder es müsste jede einzelne
Datei untersucht werden, ob sie eine solche Klasse enthält.
letzteres ist der fall, der JarClassLoader ist nur dazu da, klassen auf jardateien zu laden. für andere quellen gibts wiederum andere classloader.
JPKI hat gesagt.:Nein, in Interfaces können nur statische Variablen (ich glaub "final" ist nicht unbedingt nötig) definiert werden.
Sicher können die auch prviat sein... Nur Atrribute halt nicht (also Objektvariablen).
Ich gebe auf, hat keinen Sinn. Ich habe hier manchmal den Eindruck, dass ich Deutsch schreibe undHoaX hat gesagt.:gast, nur weil es der am häufigsten verwendete classloader, jarclassloader, so macht ist das noch lange kein standard. und die reflectionapi hat damit auch überhauptnix zu tun.
package a.b.c;
public class Hallo
{
public static void main(String args[])
{
System.out.println("Hallo");
}
}
Du kannst auch einen Classloader schreiben, der zunächst eine Email nach Japan schickt, die dort vonWildcard hat gesagt.:@Gast
Java Klassen aus Datenbanken zu laden ist so ungewöhnlich nicht.
Deswegen ist Java sooooooooooo langsam... wegen des speziellen Classloaders... :wink:Anonymous hat gesagt.:Du kannst auch einen Classloader schreiben, der zunächst eine Email nach Japan schickt, die dort von
irgendeinem Server verarbeitet wird und dem Classloader via ICQ die Adresse eines Servers in Papua
Neu Guinea zuschickt, der ein Katalog von Klassen und der dazugehörigen Server führt, auf denen die
gesuchten Klassen gehostet sind. Jeder dieser Server speichert die Klassen in einem speziellen, Kontinent-
abhängigen Format, für den du einen Decoder von einem Server auf Grönland brauchst...
All diese Klassen wurden auch mit einem speziellen Compiler compiliert, der nicht darauf besteht, dass die
Sourcecodedateien den Klassennamen entsprechen...