Autoformatierung unter Eclipse

Wenn man unter Eclipse in Java entwickelt, so möchte man natürlich das dieser Code formatiert wird. Dafür gibt es je nach System die Kombination Strg + Shift + F oder unter Mac OS X die Kombination Command + Shift + F. Damit wird der aktuell geöffnete Quelltext formatiert.

Die Save Actions in den Eclipse Einstellungen

Die Save Actions in den Eclipse Einstellungen

Alternativ kann Eclipse so eingestellt werden, das der Quelltext beim Speichern neu formatiert wird, was auf Dauer natürlich praktischer ist. Dazu müssen die Einstellungen unter Window -> Preferences -> Java -> Editor-> SaveActions aufgerufen werden. Dort kann die automatische Formatierung der Quellcodes beim Speichern aktiviert werden.

Javadoc-Kommentarblock unter Eclipse erzeugen

Wenn man unter C# einen Kommentarblock zur Dokumentation über einer Methode oder einer Klasse erzeugen möchte so tippt man drei Slashes nebeneinander (///). Anschließend wird ein entsprechender Block zur Kommentierung erzeugt. Unter Eclipse ist dies für Java in abgewandelter Form ebenfalls möglich, in dem ein Javadoc-Kommentarblock automatisch erzeugt wird.

Ein Javadoc-Block zur Beschreibung eines Klasse

Ein Javadoc-Block zur Beschreibung eines Klasse

Dazu gibt man über der Klasse oder Methode welche man kommentieren möchte die Zeichenfolge:

/**

ein und bestätigt das ganze mit der Enter-Taste. Anschließend wird der Javadoc-Block erzeugt und kann vom Entwickler gefüllt werden.

Java und vorzeichenlose Typen

Zur Entwicklung von Anwendungen nutze ich im Normalfall die Programmiersprache C#. In dieser gibt es sogenannte Signed und Unsigned-Datentypen. Im Deutschen würde man dazu vorzeichenbehaftete und vorzeichenlose Typen sagen. Bei einem vorzeichenbehafteten Typ wird die Hälfte des Wertebereiches für die Darstellung negativer Zahlen und die andere Hälfte für die Darstellung positiver Zahlen genutzt. Dies führt allerdings dazu das man die Hälfte des positiven Wertebereiches einbüßt. So gibt es für den UInt32 und den Int32 unter C# bzw. der CLR folgende Wertebereiche:

UInt32    0 bis 4.294.967.295
Int32    −2.147.483.648 bis 2.147.483.647

An dieser Stelle spielen vorzeichenlose Datentypen ihre Stärke aus, da sie über einen größeren Wertebereich für positive Zahlen verfügen – bei gleichem Speicherverbrauch. So ist die Nutzung vorzeichenloser Datentypen immer dann interessant, wenn man größere positive Zahlen speichern möchte. Wenn man sich nun die Datentypen bei Java anschaut, so wird man feststellen, das es unter Java keine vorzeichenlosen Typen (mit der Ausnahme des 16 Bit großen Typs char) gibt. Möchte man nun z.B. die Werte von 0 bis 255 speichern, was bei der Verarbeitung von Daten aus bestimmten Dateiformaten vorkommt, müsste man in Java hierfür einen short (16 Bit) anstatt eines byte (8 Bit) nutzen, da selbst das byte unter Java vorzeichenbehaftet ist und nur den Bereich von -128 bis 127 abbilden kann. Möchte man diesen zusätzlichen Speicherplatz nicht hergeben, so gibt es auch unter Java eine Möglichkeit größere Werte in einem byte zu speichern:

byte unsigned = (byte)200;
int value = (int)unsigned^-256;

In der ersten Zeile wird die Zahl 200 gecastet und der Variable unsigned zugewiesen. Das Bitmuster in der Variable entspricht dann der Zahl 200. Da der Typ allerdings als vorzeichenbehaftet interpretiert wird, würde ein:

System.out.println(unsigned);

zur Ausgabe der Zahl -56 führen. Möchten wir den Wert der Variable vorzeichenlos ermitteln, muss eine XOR-Operation mit -256 ausgeführt werden, welche schließlich zum Ergebnis 200 führt.

Java und die Speicherung von Unicode

Der Datentyp char ist unter Java 16 Bit, also zwei Byte groß. Laut dem Buch Java ist auch eine Insel, werden die Daten in 16-Bit-Unicode gespeichert. Doch was genau bedeutet das und ist das eine korrekte Aussage? Die grundlegende Aussage, dass ein char unter Java ein 16-Bit-Unicode Zeichen ist, stimmt. Wobei mittlerweile wird das ganze so betrachtet, dass ein char unter Java eine Unicode code unit repräsentiert. Echte Unicode-Zeichen benötigen mittlerweile bis zu 21 Bit und werden üblicherweise als 32 Bit gespeichert, was einer UCS-4 Kodierung entspricht.

Mit Unicode können nicht nur lateinische Buchstaben abgebildet werden

Mit Unicode können nicht nur lateinische Buchstaben abgebildet werden

Das bedeutet, dass in einem char nur Unicode-Zeichen gespeichert werden können, die in 16 Bit abgebildet werden können. Bei einem Array vom Typ char, einem StringBuffer und einem String sieht die Sache anders aus. Hier sind die Unicode-Zeichen in UTF-16 kodiert, damit können alle Zeichen des Unicode-Satzes kodiert werden. Das führt aber auch zu Problemen, so gibt die Methode length() einer String-Instanz die Anzahl der Unicode code units zurück, was gleichbedeutend ist mit der Anzahl Byte multipliziert mit zwei ergibt. Es bedeutet das die Methode nicht zwingend die Anzahl der Buchstaben zurück gibt, da manche Buchstaben mit zwei Unicode code units kodiert werden.

SourceTree

Normalerweise nutze ich als grafische Git-Oberfläche für Mac OS X, die freie Software GitX. Allerdings scheint die Entwicklung des Clients (wieder mal) eingeschlafen zu sein, so das ich mich nach Alternativen umgeschaut habe.

SourceTree unter Windows

SourceTree unter Windows

Fündig geworden bin ich dann bei SourceTree vom Hersteller Atlassian, welcher vor allem durch seine Projekmanagmentlösungen bekannt geworden ist. Der Client verfügt über eine Menge Funktionalität, welche der normale Anwender sicherlich nicht auf Anhieb benötigen wird, ist aber ansonsten sehr solide aufgebaut. Neben Git unterstützt der Client auch das Versionsverwaltungssystem Mercurial. Der Client selbst ist dabei neben Mac OS X auch für Windows verfügbar.