Noch ein paar interessante issues zum classloading:
Classloaders kann man sich als so eine Art java.util.HashMap vorstellen.
Ein bischen wie List in LotusScript.
Also jede Klasse hat einen key, unter der sie referenziert werden kann (und dann geladen). Der key ist der Name. Also z.B. java.util.Map ist key und value ist die ganze Klasse mit diesem Namen.
Die Klassen werden nicht direkt geladen, sondern wenn sie benötigt werden.
Sobald du sowas machst wie
StringBuffer buf = new StringBuffer();
beginnt die VM die HashMaps der Classloader zu durchforsten, ob sie die Klasse StringBuffer irgendwo finden kann.
Sie fängt mit dem untersten Classloader an. (s.o. 1. Bootstrap ClassLoader).
Sie findet java.lang.StringBuffer im untersten Classloader (java.lang.* steht implizit in jedem Import) und läd die Klasse.
Eine Klasse de.img.util.PropertiesFile wird vielleicht erst im 4. oder 5. Classloader gefunden.
Wird eine Klasse gar nicht in den ClassLoadern gefunden, wird eine ClassNotFound Exception geworfen.
Anfänger denken manchmal, dass die Anwendung schneller wird, wenn man die import statements so definiert:
statt:
import java.util.Map;
import java.util.HashMap;
import java.util.Set;
import java.util.HashSet;
Das ist nicht schneller. Die Klasse wird tatsächlich erst geladen, wenn sowas wie
StringBuffer buf = new StringBuffer();
da steht.
Jede Klasse spezifisch zu importieren ist sogar deutlicher. Ausserdem bieten moderne IDEs auto-completion features an, so dass kein Mensch mehr import statements schreibt, sondern z.B. bei Eclipse auf die gelbe Glühbirne klickt.
Es gibt ein teuflisches gotcha im Kontext von hot-deployment auf J2EE Servern, aber das sag ich jetzt nicht.
Axel
Hi,
Ich sehe James nicht als dickes Zusatztool, sondern als Mailserver-Implementierung gegen die sich zumindest openSource nichts anderes durchsetzt.
Das sind auch nicht so LEI/DWF mässige Zusatztools sondern Dinge die funktionieren.
Programmierpraxis in Java ist aber zumindest für mich in weiten Teilen eine Mischung aus Toolnutzung, Systemadministration und Programmierung.
"Dicke Zusatztools" benutzen Leute, die sich auf ihrer dollen Websphere Entity EJB Lösung darüber freuen, dass sie die Responsivität einer bestimmten Seitenabfrage von 45 auf 32 Sekunden gedrückt haben und schliesslich ist das alles kein Problem. Nein. Nein. Schliesslich ist der 4 Gig Testserver nicht in einem Cluster. Die finde ich auch bedenklich und ich glaub es gibt sie. James ist eine ganz andere Geschichte.
Als Lernprojekt ist das imho fast ein bischen aufwendig und es existiert Frustrationsgefahr, weil wie gesagt Java auf Domino noch seine Tücken hat.
Als reines programmieren im Sinne von Algorythmen coden gibt es ja auch nicht so wahnsinnig viel her gegenüber LotusScript.
Ob du jetzt:
if (int i==0) {
// oder
if i = 0 then
schreibst, ist ja auch nicht so spannend.
Spannend sind imho gerade diese Zusatztools, Frameworks, OO-Konzepte, Projektsteuerungsmethoden, Testmethoden, OR-Mapper, uvam..
Ist für dich Eclipse auch ein fettes Zusatztool ???
Dazu würde ich im jeden Fall auch Umsteigertestern raten, da es auch das Lernen einfacher macht und viele wirklich triviale Arbeiten wie z.B. import statements schreiben, Methoden umbenennen, kompilieren, uvam schlicht und ergreifend automatisiert.
Java ist ohne Eclipse und Zusatzzeugs eine eher geschwätzige Sprache. Das überzeugende sind aber diese Zusatztools, da sie in Sachen Transparenz, Ernstnehmen des Users und Stabilität so Dingen wie LEI und DWF imho turmhoch überlegen sind.
Ich bin ganz sicher kein brillianter Hacker. Aber genau deshalb mache ich Java und nicht C.
Gruß Axel