Nach einer Idee von Andrej und mir gibt’s jetzt den Palindrom-Wettbewerb. Der Wettbewerb besteht aus zwei Disziplinen, bei denen sinnvolle (!) Palindrome durch ein Programm generiert werden müssen.
    »more…

an unseren Komilitonen Yury, der vor kurzem seine Diplomprüfung bestanden hat.

Während ich in ein paar Onlineforen rumblätterte, fiel mir das Problem eines Java-Newbies auf. Er wollte Wörter darauf testen, ob es sich um Palindrome handelt, also ob sie vorwärts wie rückwärts gelesen das gleiche bedeuten. Auf die schnelle habe ich eine Methode geschrieben, welche Wörter oder Sätze auf die Palindromeigenschaft prüft.

public static boolean isPalindrome(String sentence) {
  // remove all whitespace characters and casing
  String sentenceWithoutSpaces = sentence.replaceAll("\\s+", "")
    .toLowerCase();
  // find the middle
  int middle = (int) (sentenceWithoutSpaces.length() / 2);
  boolean isPalindrome = true;
  for (int i = 0; i < middle; i++) {
    if (sentenceWithoutSpaces.charAt(i) != sentenceWithoutSpaces
      .charAt(sentenceWithoutSpaces.length() - (i + 1))) {
      isPalindrome = false;
      break;
    }
  }
  return isPalindrome;
}

Und schon wieder ein Stückchen schlauer geworden: Auf jsresources.org findet man den Quellcode, um mit wenigen Zeilen einen CDDA Ripper in Java zu implementieren. Das ganze geht über die Sound API von Java. Was man nicht so alles für Java findet.

Was kann man machen, um seinen Source zu verbessern? Bücher studieren, Erfahrung sammeln, Refactoren, Reverse Engineeren, Informatik studieren, Tao of Programming auswendig lernen?

Eine weit aus einfachere Möglichkeit ist das Trinken von Vittel Mineralwasser.

Bis vor kurzem wusste ich es nicht, bin aber beim Durchstöbern von Java ist auch eine Insel darauf gestoßen:
Schon seit JDK 1.4 unterstützt Java Antialiasing für (zumindest) Swingkomponenten. Aktiviert werden kann das Antialiasing über folgende Codezeile in einer JComponent:

public void paintComponent(Graphics g){
    ((Graphics2D) g).setRenderingHint(
        RenderingHints.KEY_ANTIALIASING, 
        RenderingHints.VALUE_ANTIALIAS_ON);
    super.paintComponent(g);
}

Weitere Konfigurationsmöglichkeiten können in der Javadoc unter Graphics2D sowie RenderingHints gefunden werden.

Beim Herumstöbern im Netz nach aktuellen Opensource Java Projekten bin ich auf eine interessante API gestoßen, die RMI ähnlich, aber simpler, funktioniert. Dabei können Java Objekte zwischen verschiedenen JVMs, auch über das Netzwerk hinweg, miteinander arbeiten. Ein besonderer Artikel mit dem Namen “Inside the World Wide Virtual Machine” öffnete mir dabei die Augen bezüglich der Möglichkeiten: Ein weltweites Netz von JVMs. Genial! Aber auch im kleineren Rahmen kann ich mir vorstellen, dass man einen Verbund aus Rechnern erstellt, welche sich gegenseitig sichern und miteinander Arbeiten.

Wer kennt das nicht: da hat man nun eine Binärdatei vorliegen, und möchte gerne wissen, was sich dahinter verbirgt. Meist genügt ein Blick auf den Header der Datei mit Notepad, doch bei defizileren Unterschieden, wie z. B. dem ELF Header für 32 oder 64 Bit Prozessoren, versagt diese Methode: Ein Hexeditor muss her. Es gibt viele davon, jedoch hat einer meine Aufmerksamkeit besonders angezogen, da er nicht nur Freeware ist, sondern auch ganz ohne Installation auskommt. Funktionell bietet er dabei jedoch nur das Nötigste.

�brigens sieht der Unterschied zwischen ELF32 und ELF64 im Header wie folgt aus:

ELF 32: 7F 45 4C 46 01 02 01 00 00
ELF 64: 7F 45 4C 46 02 02 01 00 00

Das ganze entdeckte ich, als ich über JNI eine Library unter SPARC einladen wollte und die folgende Exception vorfand. Der Rechner war wohl nur 32 Bit und die Library 64 Bit…

Exception in thread "main" java.lang.UnsatisfiedLinkError:
/home/lib/libXXX.so: ld.so.1:
/home/java/usr/bin/../java/bin/../bin/sparc/native_threads/java: fatal:
/home/lib/libXXX.so: wrong ELF class: ELFCLASS64
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1419)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1343)
        at java.lang.Runtime.loadLibrary0(Runtime.java:749)
        at java.lang.System.loadLibrary(System.java:820)
        at myPackage.JNIXXX.<clinit>(JNIXXX.java:12)
        at myPackage.XXX.<init>(XXX.java:117)
        at myPackage.XXX.<init>(XXX.java:92)

Download XVI32