Dass Eclipse vieles zum komfortablen Entwickeln bietet, dürfte jedem Entwickler klar sein. Sicherlich kennen viele die Möglichkeit, Getter und Setter generieren zu lassen, so dass einem eine Menge stupider Schreibarbeit erspart bleibt. Ebenfalls unter dem Menü
Ein Blick lohnt sich auf jeden Fall!
Das PDF-Format ist eine einfache Art Dokumente auszutauschen, die wohl jedem Computernutzer bekannt ist. Jemand verfasst ein Dokument und erzeugt z.B. mittels der OpenOffice Suite ein PDF daraus, welches von jemand anderem mit einem entsprechendem Viewer wiedergegeben werden kann. Bei diesen Schritten gibt es im Normalfall keine Probleme, was das Arbeiten mit PDF-Dateien auszeichnet.
Die sehr umfangreiche PDF-Spezifikation ([SPEC]) lässt allerdings vermuten, dass das nicht immer der Fall ist, wenn man in den professionellen Bereich vordringt.
Folgendes Problem beschäftigte uns:
Um PDFs mit unserer Software weiterverarbeiten und letztendlich drucken zu können, ist es notwendig, dass sie das DIN A4 Format haben – hierbei wird die MediaBox der Seite geprüft. Es lag ein Dokument vor, welches die A4-Maße deutlich überschritt und somit zurückgewiesen wurde. Eine Analyse zeigte, dass die MediaBox, wie vermutet, von den gültigen Maßen abwich – entgegen allen Erwartungen besagte die Anzeige der Eigenschaften in einem PDF-Viewer, dass es sich trotzdem um ein A4 Dokument handelt. Die PDF-Spezifikation musste Klarheit verschaffen.
Neben der MediaBox gibt es weitere “Box”en – z.B. TrimBox, CropBox – die Einfluss auf die “PageBoundaries” eines Dokuments haben (s. [WIKI]). Die MediaBox beschreibt lediglich die physikalischen Ausmaße des Zielmediums – in unserem Fall A4. Das Dokument, welches wir bekommen hatten, wurde für einen Druckprozess erzeugt. Damit enthielt es neben dem eigentlichen Inhalt noch Meta-Informationen, wie z.B. Druckmarken, Falzmarken, die für den Druckprozess relevant sind. Diese Markierungen dürfen natürlich nicht auf den Inhalt gedruckt werden. So ist es nachvollziehbar, dass die Meta-Informationen auf einem eigenen Bereichen erscheinen müssen, um den das physische Medium (die MediaBox) vergrößert wird. Die Lösung des Problems war letztendlich, dass die PDFs nicht für den Druck erzeugt werden und somit die MediaBox wieder der Größe des Inhalts entspricht.
Positiver Nebeneffekt war, dass auch weitere nicht benötigte Informationen (Farbprofile, etc.) nicht mehr im PDF vorhanden waren und die Dateigröße deutlich gesenkt werden konnte – von ca. 2MB auf 600kb.
Quellen:
[SPEC] PDF Spezifikation Version 1.7
[WIKI] PDF in Wikipedia
Für sprachabhängige Vergleiche von Zeichenketten bietet Java die Klasse Collator. Meist ist das Ergebnis eines Collator-Vergleichs intuitiv und sofort nachvollziehbar. Es gibt aber Fälle, wo man schon mal ins Grübeln kommt.
Das Ergebnis eines Vergleichs zweier Zeichenketten a und b kann -1. 0, 1 sein und bedeutet, dass a kleiner als, gleich, größer als b ist. Völlig klar sind folgende Beispiele:
Collator collator = Collator.getInstance(); coll.compare("abc", "xyz"); //= 1 coll.compare("bcd", "bdd"); //= 1 coll.compare("123", "xyz"); //= -1, da Buchstaben > Zahlen |
Einiges Grübeln verursachten die folgenden Vergleiche:
Collator collator = Collator.getInstance(); coll.compare("5_", "-9")); // (1) coll.compare("5_", "-0")); // (2) |
Anzunehmen ist, dass beide dasselbe zurückliefern – dies ist aber nicht der Fall. Der Vergleich (1) resultiert in -1 und (2) in 1.
Bei einem Blick hinter die Kulissen zeigte sich, dass der java.text.RuleBasedCollator zum Einsatz kommt. Dieser arbeitet, wie der Name andeutet, mit regelbasierten Vergleichen.
Die deutschen und z.B. auch englischen Regeln betrachten das Zeichen ‘-’ als ein ignorierbares Zeichen. Daraus folgt, dass letztendlich nur noch 5 mit 9 bzw. 0 verglichen wird.
Wenn also ein Vergleich ein unerwartetes Ergebnis zu Tage fördert, liegt es vielleicht an einer nicht so intuitiv nachvollziehbaren Regel.
Genauere Informationen gibt es in den Javadocs des RuleBasedCollators
Andreas Siepert
Das Code-Review Tool PMD [1] kann als starker Partner an der Seite eines Programmierers eingesetzt werden. Natürlich versucht der Entwickler immer konzentriert alles richtig zu machen und keine Fehler einzubauen – leider gelingt es aber nicht immer, fehlerfreien Code zu schreiben. Hier kommen kleine Helfer wie PMD zum Einsatz, die den Entwickler unterstützen, indem sie nach typischen Fehlermustern suchen.
PMD durchsucht anders als andere Tools den Source-Code (nicht die compilierten Klassen) nach potenziellen Gefahrenquellen. Ein Beispiel ist das Muster des “MissingBreakInSwitch” – Es wird darauf hingewiesen, dass in einem case Zweig einer Switch-Anweisung kein break zu finden ist.
Die Regeln unterstützen neben dem Auffinden von Bugs, auch das Einhalten von OO-Prinzipien. Als Beispiel sei “LooseCoupling” genannt: es wird gefordert, mit Interfaces (wie List) und nicht mit Implementation (wie ArrayList) zu arbeiten.
Ein weiterer Punkt, in dem PMD dem Entwickler unter die Arme greift, ist die Lesbarkeit des Codes:
“ConfusingTernary” – in einem If-Audruck sollte der Testausdruck nicht negiert sein, da dies die Lesbarkeit mindert, wenn noch ein else folgt, z.B.:
if (!list.isEmpty()) { this.doSomething(); } else { this.doSomethingElse(); } |
läßt sich nicht so fließend lesen wie
if (list.isEmpty()) { this.doSomethingElse(); } else { this.doSomething(); } |
PMD kann individuell verschieden genutzt werden – einerseits als Tool, was immer mal wieder während der Implementation ausgeführt wird, andererseits kann es auch fest in einen Buildprozess integriert werden (z.B. Ant, Maven), um Fehlerquellen zu reporten oder sogar um den Build scheitern zu lassen.
Letzteres kann durch das Anpassen der Fehlerpriorität erreicht werden, so dass das Nicht-Einhalten einer Regel quasi zu einem Compilerfehler führt.
Ebenfalls lässt sich PMD in der Auswahl der zu prüfenden Regeln an die eigenen Bedürfnisse anpassen – so ist es z.B. nicht notwendig gegen J2EE Regeln prüfen zu lassen, wenn diese nicht relevant bzw. sogar störend für das aktuelle Projekt sind.
Für eine manuelle Prüfung des Codes bietet sich das Eclipse-Plugin [2] an. Hiermit können selbstgewählte “Pakete” durchsucht werden – ganze Projekte bis hin zu einzelnen Klassen.
Nach der Installation des Eclipse-Plugins [2] kann es wie gewohnt über Window ->Preferences -> PMD für den gelegentlichen Einsatz konfiguriert werden.
Wie oben schon erwähnt, lassen sich die anzuwendenden Regeln einzeln auswählen und die Prioritäten auf die verschiedenen Bedürfnisse anpassen.
Sehr hilfreich für eine firmenweite Verteilung ist die Ex- und Import-Funktion. Hierüber können beispielsweise die von PMD bereitgestellten RuleSets geladen und dann als eigener Satz exportiert werden.
Zum Einsatz bringen kann man PMD über das Context-Menü der verschiedenen Resourcen – Projekt, Package, Klasse – durch die Auswahl von PMD -> Check Code With PMD. Eine Auswertung findet dann in einem Extra Tab statt, in dem die gefundenen potentiellen Fehler z.B. nach Priorität und Klasse aufgelistet werden. Zu den Regelverstößen ist auch eine Beschreibung verfügbar, die teilweise Hinweise gibt, wie das “Problem” zu lösen ist.
Für PMD können auch neue Regeln erstellt bzw. die existierenden modifiziert werden – es sei auf [1] verwiesen.
Neben PMD gibt es diverse weitere Code-Review Tools (z.B. FindBugs), die einem die “Käfer” vom Leib halten helfen.
[1] http://pmd.sourceforge.net/
[2] http://pmd.sf.net/eclipse
Als Partner im pro4j Netzwerk werden Sie regelmäßig über unsere verfügbaren Java-Projekte informiert.
Sie können über pro4j zusätzliche Vorteile wahrnehmen, die Sie bei Ihrer täglichen Arbeit unterstützen.
pro4j ist ein Service von Bader&Jene
