Java, Rich Clients, Frameworks und OSGi

Windows Console und Encoding

2011-04-13T16:16:00.003+02:00

Nachdem ich gerade unter Windows 7 eine neue Version des Subversion Kommandozeilen-Clients in meine Entwicklungsinfrastruktur übernommen habe, stelle ich fest, dass dieser scheinbar Encoding Probleme hatte. Bei einer kleinen Google-Suche bin ich über diesen Blogpost hier gestolpert: I18N: Unicode at the Windows command prompt

Scheinbar verwendet der SVN Client unter Windows die Standard-Codepage 1252, Windows hingegen in der Konsole UTF-16. Das in dem Blogpost beschriebene Ändern der Schriftart (ich habe Lucida Console in Größe 13 gewählt) und anschließende Ausführen von "chcp 1252" hat geholfen.

Tante Edit sagt: Mit dem Befehl "chcp" ohne Parameter lässt sich herausfinden welche Codepage gerade verwendet wird. Standard unter Windows 7 ist die 850. Mit "chcp 850" kommt man also zum Ausgangszustand wieder zurück.

Zwei Updates pro Jahr

2010-10-11T20:20:00.001+02:00

Seitdem ich den Blog habe habe ich es tatsächlich geschafft im Schnitt zwei Updates pro Jahr zu posten. Jetzt habe ich mal das Design etwas überarbeitet und mal wieder den Entschluss gefasst meine Erkentnisse (haha) hier festzuhalten.

So, erstes Update für dieses Jahr wäre geschafft. Eins muss ich also noch. ;)

Subversion 1.6 in JDeveloper 11g

2009-09-11T09:03:00.006+02:00

Im Moment bin ich etwas fachfremd als 4GL Entwickler mit Oracle ADF unterwegs. Das Mittel der Wahl für die Entwicklung ist natürlich der JDeveloper 11g. Dieser unterstützt von Hause aus leider nur Subversion 1.5, was sich mit dem bei mir auf dem System installierten TortoiseSVN beißt. Nun hatte ich vier Möglichkeiten:

TortoiseSVN für das aktuelle Projekt downgraden und nicht auf meine anderen Projekte zugreifen können, dafür aber sowohl mit JDeveloper als auch mit Tortoise auf der Working-Copy arbeiten können.
Nur TortoiseSVN benutzen und auf die Toolunterstützung im JDeveloper verzichten. Das würde allerdings sehr beim Umbenennen, Verschieben und Löschen von Dateien stören, da man die Subversion Änderungen alle von Hand nachziehen müsste.
Nur mit der Unterstützung vom JDeveloper arbeiten. Das führt allerdings dazu, dass man zum einen sehr aufpassen muss, dass man nicht aus Versehen im Explorer Tortoise SVN verwendet. Außerdem sieht man im JDeveloper nicht unbedingt immer alle Dateien oder Ordner - Tortoise ist da flexibler. Außerdem habe ich den Verdacht, dass TortoiseMerge etwas cleverer ist.
Den JDeveloper überreden auf einer 1.6er Working-Copy arbeiten zu können. Davon handelt dieser Post.

Im Prinzip ist es ganz einfach. JDeveloper arbeitet mit SvnKit, allerdings mit einer älteren Version theoretisch muss man also nur dieses aktualisieren und schon kann man das Beste aus beiden Welten verwenden. Hier also eine Anleitung:

JDeveloper schließen (falls geöffnet)
In das Verzeichnis [Jdev-Install]\jdev\extensions\oracle.jdeveloper.subversion wechseln
Die Dateien svnjavahl.jar und svnkit.jar vorsichtshalber zur Sicherung umbenennen (z.B. ein .bak anhängen)
SvnKit 1.3.0 Standalone herunterladen (http://svnkit.com/download.php)
Die Dateien svnkit.jar und svnkit-javahl.jar in das oben genannte Verzeichnis entpacken
Die svnkit-javahl.jar in svnjavahl.jar umbennen
JDeveloper starten und überprüfen, dass er das aktualisierte SVNKit verwendet (Tools -> Preferences -> Versioning -> Subversion)

Herausgefunden habe ich das übrigens nicht selber. Eine ähnliche Anleitung habe ich für Subversion 1.5 und JDeveloper 10g gefunden. Zwischen den Versionen hat sich aber scheinbar nicht viel geändert.

Es wird keine Garantie für einen verhunzten JDeveloper oder eine gefraggte Working-Copy übernommen! :o)

Fensterrahmen und -titel vom Look and Feel

2009-07-03T10:51:00.004+02:00

Gestern habe ich gelernt, dass man Swing dazu anleiten kann die Fensterleiste und den Rahmen durch das aktuelle Look&Feel darzustellen. Normalerweise wird dieser Bereich vom Betriebssystem bereitgestellt, so dass auch das Aussehen zu dem Betriebssystem passt. Wenn man nun aber ein eigenes Look&Feel verwenden möchte passt das manchmal nicht zusammen. Um das einzuschalten braucht man lediglich folgende Zeilen Aufrufen, bevor man die erste JFrame oder JDialog Instanz erstellt hat:


      JFrame.setDefaultLookAndFeelDecorated(true);
      JDialog.setDefaultLookAndFeelDecorated(true);
      System.setProperty("sun.awt.noerasebackground", "true");

Die letzte Property ist um ein Flackern beim Resizing zu unterbinden, die allerdings nur unter Windows funktioniert.

Darauf gestoßen bin ich, als ich mit dem Substance Look&Feel herumgespielt habe und mich wunderte, warum die Fenster auf den Screenshots alle dem Look&Feel angepasst waren. Über die FAQ (Question 16) habe ich dann erfahren wie das geht.

Wieder was gelernt... :)

Build Path Fehler in Eclipse

2008-06-05T10:04:00.002+02:00

Aktuell habe ich in Eclipse das Problem, dass das organisieren der Imports nicht richtig funktioniert. Und zwar wird der Pfad zu dem source folder, in dem dann eigentlich erst das Package liegt mit als Package erkannt. Das Ganze sieht ungefähr so aus:

...
import src.main.java.de.opitzconsulting.test.client.MyInterface;
...

Das kann natürlich nicht funktionieren. Schuld daran ist die Einstellung des Build Paths, da das Root Verzeichnis vom Projekt ebenfalls als Source Folder konfiguriert ist. Scheinbar ignoriert Eclipse allerdings beim organisieren der Importe (und auch im (STRG+SHIFT+T) "Open Type" Dialog) die Tatsache, dass dort alle Java Dateien rekursiv ausgenommen sind.
Ein Workaround dafür ist manuell in der .classpath die Reihenfolge der Einträge zu ändern und den Eintrag für den Project Root ans Ende zu setzen. Da ich aber maven und das eclipse:eclipse goal verwende würde ich gerne eine allgemeingültige Lösung finden.
Eigentlich würde es reichen, wenn man das maven-eclipse-plugin dazu überredet bekommt die Einträge in einer bestimmten Reihenfolge vorzunehmen. Bisher habe ich leider noch nicht rausfinden können wie das geht. Insgesamt denke ich trotzdem, dass es sich um einen Eclipse Bug handelt, der behoben werden sollte.

Falls jemand diesen Blog liest und eine Idee hat wie sich das Problem beseitigen lässt wäre ich ihm/ihr sehr verbunden, wenn er/sie es mir mitteilt. ;)

Neuer Blog

2008-05-14T11:33:00.000+02:00

Kaum zu glauben, aber ich habe mich tatsächlich dazu durchgerungen auch ein Blog zu erstellen. Jetzt fehlen nur noch Inhalte. ;-)