Nach dem großen Erfolg der JVM-Memory-Indicator-Komponente und dem sensationellen Layout-Manager nun eine weitere unverzichtbare Komponente in jeder grafischen Oberfläche, die aus unverständlichen Gründen nicht schon standardmäßig in Swing ausgeliefert wird: die Anzeige eines klassischen Hexdumps. In der ebenso klassischen 8 + 16 + 16-Darstellung: 8-stellige Adresse, danach 16 Bytes in Hex-Darstellung, danach 16 ASCII-Zeichen als direkte Übersetzung der Bytes. Mit möglichst simpler API: hier ist das Byte-Array, mach’ mir die HexDump-View als Swing-Komponente dazu, die ich zur Nutzung nur noch in eine JScrollPane reinsetzen muss. Natürlich superschnell und superspeichersparend.
Testkandidat war eine 800KiB-Datei (ein adf-Floppyimage, aber das tut nichts zur Sache, hat aber mit dem Ursprung des Wunsches nach dieser Komponente zu tun – ich hoffe, da kann ich demnächst Vollzug melden, dann voraussichtlich nebenan im RISC OS-Blog), resultierend in einem rund 50000 (genau 51200) Zeilen umfassenden Hexdump.
Wie ist es implementiert? Da gab es natürlich eine Menge Varianten, die mir spontan in den Sinn kamen und die wie immer mit unterschiedlichen Kompromissen behaftet sind, die ich kurz anreißen will.
Variante 1: Erzeugen einer String-Repräsentation der Binärdaten und Nutzung einer “normalen” JTextArea oder JEditorPane. Geht schnell, ist unproblematisch in der Realisierung, alle typischen Dinge einer Textkomponente sind direkt verfügbar (auch wenn in diesem Falle das Copy&Paste vermutlich nicht ganz das ist, was der Anwender erwartet). Aber speicher- und laufzeittechnisch sicher suboptimal – die Konvertierung in eine lange Zeichenkette, obwohl man diese ja bei größeren Datensätzen niemals gleichzeitig auf dem Schirm sieht, ist doch verhältnismäßig teuer, und die Wahrscheinlichkeit, dass sowohl das Quell-Byte-Array als auch die Zeichenkette im Speicher verbleiben müssen, ist ja doch recht groß (vermutlich will der Verwender seine Quelldaten ja nicht wegwerfen, sondern noch weiter verarbeiten), und pro Byte kostet die String-Repräsentation ja zusätzlich etwa 14 Bytes (73 Zeichen pro 16 Bytes.
Variante 1a: Erzeugen einer String-Repräsentation der Binärdaten und wrappen in ein java.swing.text.Document als Unterfütterung einer JTextArea/JEditorPane. Spontan würde ich denken, dass so ein reines ReadOnly-Document etwas besser bei Speicher- und Laufzeitverhalten ist als ein Wald- und Wiesen-Document aus dem Swing-Bauchladen.
Variante 2: Erzeugen einer String-Repräsentation der Binärdaten und direkter Redraw in paintComponent. Habe ich getestet, für mäßig große Binärdaten funktioniert das erschreckenderweise recht gut (in meinem Falle waren das rund 50000 Zeilen des Hexdumps), was glaube ich eher zeigt, wie schnell die Maschinen heutzutage sind, und nicht, wie man ein solches Problem angehen sollte. Speichertechnisch ist das etwas günstiger als eine JTextArea oder JEditorPane weil man die ganze unnütze Funktionalität weglässt, aber das Hauptproblem der Erzeugung der großen Zeichenkette bleibt.
Variante 2a: wie 2, aber mit optimiertem Redraw (paintComponent) – nur die Zeilen zeichnen, die laut Clipping Rectangle tatsächlich gezeichnet werden. Das ist geschwindigkeitstechnisch schon erheblich besser als Variante 2, weil eben nur sagen wir 100 Zeilen gezeichnet werden statt 50000, und deshalb aus der vollständigen String-Repräsentation auch nur 100 Substring-Operationen anstatt 50000 durchgeführt werden müssen. Ich habe allerdings nicht analysiert, ob denn den Substring-Operationen im Vergleich zum dann weggeclippten drawString wirklich die teurere Operation ist – einigen wir uns auf “hilft beides nicht”.
Variante 3: kein Erzeugen der vollständigen String-Repräsentation, sondern Erzeugung der zu malenden Textzeile “on demand” aus den Quelldaten, dem Byte-Array. Dabei Inspektion des Clipping Rectangles, um nur die notwendigen Operationen durchzuführen.
Nachfolgend beispielhaft die Implementierungsvariante 3 (die anderen sind zu trivial :-)), als ganz nacktes Java – keine externen Abhängigkeiten, und vermutlich würde der Code so schon unter Java 1.1 mit Swing 1.1 funktionieren. Es gibt hier natürlich Lücken (es sind nur rund 200 Zeilen Code, für eine vollständige JComponent, inklusive JavaDoc!), die selbstverständlich nur als Aufforderung zur Übung an den Leser zu verstehen sind. Encoding-Unterstützung für den Textbereich, Implementierung eines Carets und einer Selektionsmöglichkeit, Unterstützung für nicht-Monospaced-Schriften, on-demand-loading der Binärdaten aus einer Datei größer als MaxHeap während der Benutzer scrollt, suchen nach Text und Bytes und Adressen, Darstellung in Byte- und Word-Form, hinzufügen der Zeilennummer…
Auch eine Variante 4 – ein Document das allein durch die Quelldaten unterfüttert ist und on-the-fly den Text für die JTextComponent generiert, wäre eine interessante Forschungsaufgabe.
/*
* (c) hubersn Software
* www.hubersn.com
*
* Use wherever you like, change whatever you want. It's free!
*/
package com.hubersn.playground.swing;
import java.awt.Dimension;
import java.awt.Font;
import java.awt.FontMetrics;
import java.awt.Graphics;
import java.awt.Insets;
import java.awt.Rectangle;
import javax.swing.JComponent;
/**
* Component showing a hexdump.
*/
public class HexDumpView extends JComponent {
/** Number of characters in one line of a hexdump: 8 characters address, 16 2-character-bytes, 16 characters, spaces. */
private static final int LINE_LENGTH = 8 + 1 + 3 * 16 + 16;
private byte[] data;
private int lineCount = -1;
private FontMetrics fm = null;
private int lineHeight = 0;
private int lineAscent = 0;
private int characterWidth;
private int calculatedWidth;
private int calculatedHeight;
/**
* Creates a hexdump view based on the given data with a monospaced 12pt font.
*
* @param data hexdump data.
*/
public HexDumpView(final byte[] data) {
setFont(new Font("Monospaced", Font.PLAIN, 12));
setData(data);
}
/**
* Sets the data to be visualized by this hexdump view.
*
* @param data hexdump data.
*/
public void setData(final byte[] data) {
this.data = data;
refresh();
}
/**
* Sets the font to be used for the hexdump - note that only a monospaced font will yield sensible results.
*/
@Override
public void setFont(final Font font) {
super.setFont(font);
this.fm = null;
refresh();
}
private void refresh() {
if (this.data == null) {
return;
}
calculateSizes();
revalidate();
}
private int calculateLineCount() {
if (this.data == null) {
return 0;
}
int lc = this.data.length / 16;
if (this.data.length % 16 > 0) {
lc++;
}
return lc;
}
private void calculateSizes() {
if (this.fm == null) {
this.fm = getFontMetrics(getFont());
this.lineHeight = this.fm.getHeight();
this.lineAscent = this.fm.getAscent();
this.characterWidth = this.fm.stringWidth("M");
}
this.lineCount = calculateLineCount();
this.calculatedWidth = getInsets().left + getInsets().right;
this.calculatedWidth += LINE_LENGTH * this.characterWidth;
this.calculatedHeight = getInsets().top + getInsets().bottom;
this.calculatedHeight += this.lineCount * this.lineHeight + this.lineAscent;
}
@Override
public Dimension getPreferredSize() {
return new Dimension(this.calculatedWidth, this.calculatedHeight);
}
@Override
protected void paintComponent(Graphics g) {
super.paintComponent(g);
if (this.data == null) {
return;
}
Rectangle clipBounds = g.getClipBounds();
Insets insets = getInsets();
int y = insets.top + this.lineAscent;
for (int i = 0; i < this.lineCount; i++) {
// optimized redraw - check if clipping bounds contains line
if (shouldDraw(clipBounds, y)) {
String str = getHexDumpLine(this.data, 0, i * 16);
g.drawString(str, insets.left, y);
}
y += this.lineHeight;
}
}
private boolean shouldDraw(Rectangle r, int y) {
return !(y + this.lineHeight < r.y || y - this.lineHeight > r.y + r.height);
}
//
// -- utility methods for hex(dump) representation
//
/**
* Converts a value between 0 and 15 into the corresponding hex character - throws an
* IllegalArgumentException on illegal input values.
*
* @param value value to convert.
* @param useUpperCase use upper case letters A-F?
* @return hex character representing value.
*/
private static char valueToHexChar(final long value) {
if (value < 0 || value > 15) {
throw new IllegalArgumentException("Value " + value + " out of range - must be 0-15");
}
if (value < 10) return (char) ('0' + value);
return (char) ('A' + (value - 10));
}
/**
* Converts the given value to a number of hex characters specified in nibble count value.
*
* @param value
* @param nibbleCount amount of nibbles (characters) to return.
* @param useUpperCase use upper case hex characters.
* @return hex representation of value.
*/
private static String valueToHexChars(final long value, final int nibbleCount) {
char[] hexChars = new char[nibbleCount];
for (int i = 0; i < nibbleCount; i++) {
hexChars[i] = valueToHexChar(0b1111 & (value >> (4 * (nibbleCount - 1 - i))));
}
return new String(hexChars);
}
/**
* Returns a line (not terminated) for a hexdump output - either 16 bytes starting from offset or less if data has less than 16 bytes available.
*
* @param data data for dump.
* @param startAddress start address of data.
* @param offset offset into data.
* @return hexdump line.
*/
private static String getHexDumpLine(final byte[] data, final long startAddress, final int offset) {
StringBuilder sb = new StringBuilder(LINE_LENGTH);
sb.append(valueToHexChars(startAddress + offset, 8));
sb.append(' ');
for (int lineOffset = 0; lineOffset < 16; lineOffset++) {
if (offset + lineOffset < data.length) {
sb.append(valueToHexChars(getUnsigned(data[offset + lineOffset]), 2));
sb.append(' ');
} else {
sb.append(" ");
}
}
for (int lineOffset = 0; lineOffset < 16; lineOffset++) {
if (offset + lineOffset < data.length) {
sb.append(getPrintableCharacter(getUnsigned(data[offset + lineOffset])));
}
}
return sb.toString();
}
private static int getUnsigned(final byte b) {
if (b < 0) {
return ((int) b + 256);
}
return b;
}
private static char getPrintableCharacter(final int byteValue) {
if (byteValue < 32 || byteValue > 255 || (byteValue > 128 && byteValue < 160)) {
return '.';
}
return (char) byteValue;
}
}