Category: Java

Sanselan und Vendor Notes

Metadaten in Bildern sind in Java scheinbar echt gar nicht so einfach.  In einem früheren Artikel habe ich kurz aufgelistet, welche Metadata-Libraries ich immerhin schon mal ausgemacht habe. – Sanselan sah da ja schon gar nicht schlecht aus.

Bei einem ersten Test bin ich dann aber darauf gestoßen, dass scheinbar die Vendor Notes echte Probleme bereiten können. Ich wollte eigentlich nur die Exif-Daten auslesen und in eine andere Datei kopieren. Die eigentlichen Exif-Daten waren alle super. Die Vendor-Notes meiner Sony Alpha 350 sahen auch ganz gut aus (keine genauen Vergleiche) – ein Bild einer Canon Powershot A570 IS war schon anspruchsvoller. Ca. die Hälfte der Vendor-Notes waren verändert bis unbrauchbar 🙁

Brav wie ich bin, erst mal auf der Mailingliste nachgefragt… keine Antwort – hm. Also mal brav einen Bug eröffnet. Und danach gesehen, dass das Verhalten in der Doku quasi schon angekündigt ist:

Note that this uses the “Lossless” approach – in order to preserve data embedded in the EXIF segment that it can’t parse (such as Maker Notes), this algorithm avoids overwriting any part of the original segment that it couldn’t parse. This can cause the EXIF segment to grow with each update, which is a serious issue, since all EXIF data must fit in a single APP1 segment of the Jpeg image.
http://commons.apache.org/sanselan/api-release/org/apache/sanselan/formats/jpeg/exifRewrite/ExifRewriter.html

Tjo. Blöd. Klar Blöd auch von den Kameraherstellern, dass diese Einträge proprietär sind – aber noch dümmer, dass es unter Windows gefühlte 10.000 Programme gibt, die die Exif-Daten einfach ändern können und sich das mit Java langsam echt zu einem ernsthaften Problem auswächst.

Als nächstes versuche ich jetzt Imagero, der ist zwar nicht frei, aber vielleicht geht’s da wenigstens.

JXMapKit: Karten schneller und gleichzeitig laden

Verschiebt man die Karte eines JXMapKit, müssen ja logischerweise Kartenteile (Kacheln) nachgeladen werden.
Per Default werden immer nur 4 Kacheln gleichzeitg geladen. Bei entsprechend schneller Verbindung macht es durchaus Sinn, diese Zahl zu erhöhen:

((AbstractTileFactory) jXMapKit.getMainMap().getTileFactory()).setThreadPoolSize(10);

Und schon wird spürbar schneller nachgeladen. Allerdings muss der Aufruf durchgeführt werden, bevor die erste Kachel geladen wird, wie die Javadoc aussagt:

/**
* Set the number of threads to use for loading the tiles. This controls the number of threads
* used by the ExecutorService returned from getService(). Note, this method should
* be called before loading the first tile. Calls after the first tile are loaded will
* have no effect by default.
* @param size
*/

Siehe auch: “Erste Schritte mit JavaX JXMapKit“

How to use TableModels and ListModel with NetBeans GUI Builder

A default JTable or JList comes with it’s own pre initalized model. Okay – but: how can we modify this model? Which type of model is usually pre initialized?
In the following I’ll just list some of the may possible ways to work with tables and lists and the NetBeans Gui Builder:
Continue reading How to use TableModels and ListModel with NetBeans GUI Builder

java.sql.SQLException: No suitable driver found for ‘jdbc:derby:…

Kleine Gemeinheit im “Using dblook” guide (Übersichtslink):

dblook -verbose -d ‘jdbc:derby:pathToDBDBName’

— Zeitmarke: 2010-01-04 12:27:34.578
— Quellendatenbank: pathToDBDBName
— Verbindungs-URL: ‘jdbc:derby:pathToDBDBName
— appendLogs: false

java.sql.SQLException: No suitable driver found for ‘jdbc:derby:pathToDBDBName
at java.sql.DriverManager.getConnection(DriverManager.java:602)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
at org.apache.derby.tools.dblook.go(Unknown Source)
at org.apache.derby.tools.dblook.(Unknown Source)
at org.apache.derby.tools.dblook.main(Unknown Source)
— **–> DEBUG: No suitable driver found for ‘jdbc:derby:pathToDBDBName

(Fast) Derselbe Aufruf geht via ij und NetBeans …

Lösung: dblook -d jdbc:derby:pathToDBDBName
Unterschied: einfach ohne die ‘Hochkommata‘, auch wenn es im Guide immer wieder mal mit Gänsefüßchen steht.

Escape analysis, Lock Coarsening und Biased locking

Die Ausgabe 179 des “The Java Specialists’ Newsletter” stellt ein paar interessante – wenn auch noch experimentelle – Features der Server-VM vor:

Escape analysis: Damit kann die JVM prüfen, ob ein Objekt einen bestimmten Scope nicht verlässt (z.B. nur in einer Methode verwendet wird) und dieses Objekt dann direkt auf dem Stack anlegen.

Lock Coarsening: Fordert ein Thread aufeinanderfolgend mehrere Locks auf ein Objekt an und gibt sie dann wieder frei (wie z.B. bei der Verwendung von Vector), kann die JVM diese wiederholten, teuren Anfragen zu einem lock/release zusammenfassen,

Biased locking: Wird ein Objekt von nur einem Thread ge’lock’ed, kann auf die Sperre ebenso verzichtet werden.

Im The Java Specialists’ Newsletter werden einige eindrucksvolle MicroBenchmarks gezeigt, die einiges an Performance bringen können. Aber: es sind nur MicroBenchmarks, die den Effekt sehr gut zeigen. In komplexen Applikationen kann der Benefit natürlich deutlich schlechter ausfallen. Soweit ich das aus anderen Seiten gelesen habe, sind die Optionen derzeit noch als experimentell zu betrachten – aber sie sind schon ein schöner Vorgeschmack.

Ein sehr schönes Statement im Zusammenhang mit Performance Tuning, das den Nagel auf den Kopf trifft: “Assumption is the mother of all f* ups”. Der Spruch drückt sehr schön das aus, was ich bei Performance-Optimierungen immer wieder sage: Erst Messen, dann Tunen. Und niemals Tunen ohne zu Messen. Andernfalls kann man schnell mal Stunden damit zubringen, ein Programmstück auf 5% Ausführungszeit zu drücken … das aber in der Gesamtausführung nahezu keine Zeit verbraucht – womit die Verbesserung quasi nicht existent ist. Oder schlimmer: man denkt, ein Programmteil wäre langsam, optimiert aber erfolglos an der Ursache vorbei.

Relevante Links:

http://profiler.netbeans.org/

How to load images in Java

Every once in a while there is a question on the NetBeans mailinglist about how to load an image (or other ressource, like a text file) relative to the executing JAR.

The Java Tutorial gives the answer in the chapter “How to use Icons“:

java.net.URL imgURL = getClass().getResource("inSamePackage.png");
java.net.URL imgURL = getClass().getResource("/de/foo/otherPackage.png");

Continue reading How to load images in Java

How to pack multiple JARs into one using ANT (and NetBeans)

Eines der Features, die ich bei NetBeans eine ganze Zeit lang nicht realisiert hatte war die Tatsache, dass NetBeans beim Compilieren automatisch ein ausführbares JAR erstellt, und JAR nebst Libraries in das “dist”-Verzeichnis im Projektordner kopiert. Das heißt das sieht dann so aus:

Coole Sache eigentlich. Nur – um die Applikation einfach so online zu stellen oder jemandem aufs Auge zu drücken (oder in den Java Store hochzuladen), wäre es doch fein, wenn man nur noch ein einziges JAR hätte und nicht noch zusätzlich die ganzen Libs aus “/dist/libs/” mitschicken muss (und das können schon einige sein – in meinem Mini-Projekt zB schon 19).

Viele Leute ziehen ein Jar zB einfach auf den Desktop um es direkt dort per Doppelklick zu starten. Das geht in dem Fall nicht mehr, da ja der libs-Ordner auch auf dem Desktop liegen müsste. Klar, eine Möglichkeit wäre, die Applikation woanders hin kopieren und eine Verknüpfung auf den Desktop legen – aber wir wollen dem User ja entgegenkommen.

Also:  ein einziges JAR muss her. Im Sun Developer Network (SDN) findet sich dazu auch die passende Anleitung im Artikel: “Use NetBeans IDE 6.7 to Combine JAR Files Into a Single JAR File“. Dort wird schön erklärt, wie man die build.xml ändern muss um genau das zu erreichen.

In diesem Sinne: Viel Erfolg beim ausprobieren.

Geotag-Bug in Sanselan (gefixed!)

War ich noch so begeistert davon ein Projekt gefunden zu haben, das Exif– und IPTC-Daten in Photos lesen und schreiben kann (siehe hier), habe ich beim Experimentieren auch gleich einen (seit 27 .März 2009  bekannten) Bug gefunden: “Fetching GPS Latitude Ref gets Interoperability Index instead of Reference”

Das heißt, ich kann aus meinen Bildern (die ich mit locr mit Geotags versehe) die Position nicht extrahieren – sehr schade. Immerhin ist der Bug bekannt und nun um ein Vote reicher. Vielleicht wird der Bug ja bald behoben. Je nachdem wie dringend ich die Funktionalität bald brauche, sehe ich mich doch schon fast bald dieselben Tests mit Imagero durchführen.

Update 26.11.2009: Nachdem ich mir heute vorgenommen hatte, mir den Sanselan Code einmal selbst anzusehen um den Bug vielleicht zu finden, war ich doch sehr überrascht, als ich eine Mail vom Apache-Bugtracker bekomme in der Bill Evans schreibt, er habe den Fehler und eine Lösung gefunden.

Sanslean Sourcen entpackt, Patch durchgeführt, getestet JUHU! Funktioniert.

Und dank der Testdateien von Seb (siehe Kommentar) auch noch gleich neue GPS-Tags entdeckt:
GPS Img Direction Ref: ‘M’
GPS Img Direction: 2133/10 (213,3)
Also die Richtung in die fotografiert wurde.

Und solange der Bugfix noch nicht ins offizielle Sanselan-Release eingeflossen ist, kann man die gebugfixte Version hier downloaden.

Update 9.12.2010: Der Bug ist immer noch nicht gefixed obwohl ein Patch existiert. Sanselan ist auch immernoch ein Incubator-Projekt ohne voll in Apache integriert zu sein.

Update 28.11.2011: Der Bug ist als fixed markiert!

etching GPS Latitude Ref gets Interoperability Index instead of Reference

Derby 10.5 mit Fetch/Offset

Gerade gesehen, dass es in Derby 10.5 auch ein Limit-Äquivalent geben soll (mehr dazu hier).

Im Beispiel:

ij> SELECT NAME, SCORE FROM RESULTS ORDER BY SCORE DESC
> FETCH FIRST 3 ROWS ONLY;
NAME      |SCORE
----------------------
John      |33
Anne      |28
Sue       |21

Ein “richtiges” Limit wird es nicht geben, da es (noch?) nicht Teil des SQL-Standards ist.

Siehe auch SQL:2008.

improved ButtonUI

In the JavaGraphics Blog there are some very nice examples of how Java Buttons can be made nicely. The code is also available. So it’ a nice starting point for learning how to make own UIs! Features include:

  • cross-platform.
  • pure Java
  • Resizable
  • Vertical segments
  • Java 1.4 compatible

See the BlogPost here.