Als Rubyist juckt es da in den Fingern, das muss doch schneller gehen.

require 'test/unit/assertions'
extend MiniTest::Assertions

class String

  BRACKETS = {
    "(" => ")",
    "[" => "]",
    "{" => "}",
  }

  def balanced?
    stack = []
    each_char do |char|
      if BRACKETS.keys.include? char
        stack.push char
      elsif BRACKETS.values.include? char
        return false if BRACKETS[stack.pop] != char
      end
    end
    stack.empty?
  end

end

assert "".balanced?
assert "([Hell{} T(h(e[r]e))]boom)".balanced?
assert not("(a[b{c)d]e}".balanced?)
assert not("([{".balanced?)
assert not("}])".balanced?)

sudo update-alternatives --config java

Das ganze stellt dann alle Alternativen zur Wahl:

Es gibt 2 Auswahlmöglichkeiten für die Alternative java (welche /usr/bin/java bereitstellen).

  Auswahl      Pfad                                            Priorität Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      Auto-Modus
  1            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      manueller Modus
  2            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein: 

Hier im Beispiel die 1 eingeben, mit Enter bestätigen und Java 6 ist wieder der Standard.

• PropertyModels, in denen Objektattribute als Strings notiert werden:

  new PropertyModel<String>(person, "name");

• Wicket-ID-Referenzen, die Komponenten mit ihrem Template verbinden:

  <span wicket:id="myLabel"></span> <-> new Label("myLabel")

• Propertynamen, die vor allem für Übersetzungen benötigt werden:

  new StringResourceModel("page.welcome", this, null);

Bindgen für Wicket

Für das Model-Problem gibt es mit Bindgen Wicket eine verhältnismäßig prominente Lösung. Hier wurde bereits angefragt, ob das Tool nicht offizieller Teil von Wicket 7 werden könnte.

Bindgen ist ein Annotation Processing Tool. Es erzeugt Meta-Klassen, welche die vom Nutzer geschriebenen Klassen und deren Eigenschaften beschreiben. Property-Models können somit compilersicher beschrieben werden:

// ohne Bindgen:
PropertyModel<String>(person, "name");

// mit Bindgen:
BindingModel.of(person, new PersonBinding().name());

// auch über Objektgrenzen hinweg:
BindingModel.of(person, new PersonBinding().address().street());

Kein wackliger String, sondern sichere, generierte Bindingklassen, welche die Attribute der Basisklasse beschreiben.

Annotationprocessing ist mittlerweile fester Bestandteil moderner IDEs, so dass Bindgen nach der einmaligen Einrichtung in etwa Eclipse keiner weiteren Interaktion bedarf. Die Bindings werden stets automatisch aktualisiert.

• Bindgen-Wicket auf Google Code

Wicket-ID-Bindings-Generator für Property-Dateien und HTML-Templates

Von Bindgen inspiriert, hat Ole Langbehn eine analoge Lösung für Property-Dateien und HTML-Templates geschaffen.

// WelcomePage.html
<h1 wicket:id="heading"></h1>

// WelcomePage_de.properties.xml:
<entry key="greetings">Willkommen</entry>

// ohne Wicket-ID-Bindings-Generator
add(new Label("heading", 
    new StringResourceModel("greetings", this, null));

// mit Wicket-ID-Bindings-Generator
add(new Label(WelcomePageWID.heading,
    new StringResourceModel(WelcomePageI18n.greetings, this, null));

Das offizielle Repository auf Github ist momentan nicht mit Wicket > 1.4 kompatibel. Eine Variante für neuere Versionen habe ich in meinem Fork bereitgestellt:

• SebastianG86 / wicket-id-bindings-generator

Ole hat angedeutet die Änderungen zu übernehmen, so dass die Updates auch bald im offiziellen Repo zu finden sein sollten.

Die Autovervollständigung nimmt nun noch mehr Arbeit ab und eine potentielle Fehlerquelle ist eliminiert. Bleibt nur noch zu hoffen, dass Wicket diese oder ähnliche Lösungen zukünftig schon von Haus aus mitbringt.

Ein Beispiel: Venkat Subramaniam zeigt Scala und Groovy, Rekursionsprobleme, wie diese teilweise vom Compiler selbst eliminiert werden und wie man ihnen dabei helfen kann:

[youtube clip_id=“4tEi86h8-TM“]

IllegalArgumentException

Passt immer, wenn die Argumente, die an Konstruktor oder Methode übergeben wurden, nicht den Erwartungen entsprechen.

NullPointerException

Keine Spezialisierung der IllegalArgumentException, dennoch ein naher Verwandter: Teilt mit, dass ein Argument null ist, obwohl dies so nicht vorgesehen ist.

IllegalStateException

Wird immer dann benötigt, wenn Methoden nur in einer speziellen Reihenfolge verwendet werden dürfen und ein Abweichen zu einem ungültigen Zustand führen kann. Besser ist es natürlich, solche unsichtbaren Reihenfolgezwänge zu vermeiden. Möglich ist dies jedoch nicht immer.

IndexOutOfBoundsException

Der Klassiker für alles, was einen potentiell ungültigen Index haben kann.

StringIndexOutOfBoundsException

Eine spezielle Variante für die Manipulation von Strings.

UnsupportedOperationException

Nicht immer sind Interfaces so sauber und feingranular aufgebaut, dass man wirklich jede vorgegebene Methode implementieren kann. Diese Exception macht dies unmissverständlich deutlich. Dennoch eine Notlösung, denn die Erkenntnis zur Laufzeit ist eigentlich etwas spät.

Checked Exceptions sind tot

Die klassischen, gecheckten Java-Exceptions wirken heute wie ein Relikt aus früheren Zeiten. Die Java-Macher scheinen dem zuzustimmen und bieten eine Auswahl an ungecheckten Runtime-Exceptions, die fast alle Problemfälle abdeckt.

Das Pflegen unzähliger, hochspezialisierter Exceptions in einem Software-Projekt wirkt heute nicht zeitgemäß: Ausnahmen sollen keine Kontrollstrukturen ersetzen; in den meisten Fällen sind es schlicht fehlerhafte Zustände, die vor dem Programmabbruch geloggt werden müssen. Ein falsch eingegebenes Passwort ist keine Ausnahme, sondern eher die Regel; etwas das andauernd passiert: Wird eine Exception regelmäßig geworfen, wird das Exception-Konzept missbraucht und sollte durch Bedingungen ersetzt werden.

Wichtig sind präzise und ausführliche Meldungen, die das Problem und mögliche Ursachen beschreiben. Fehler lassen sich somit effizient beseitigen und vermeiden dank ihrer Fokussierung auf die Laufzeit das oft übliche Fangen-Kapseln-und-Weiterwerfen, wie es bei gecheckten Exceptions üblich ist.

public static void main(String[] args) {

  get(new Route("/hello") {
     @Override
     public Object handle(Request req, Response res) {
         return "Hello World!";
     }
  });

}

Das ganze Ding unterstützt nur wesentliche Sachen wie Routing und Request-Response-Verarbeitung. Alles andere kann man sich entsprechend eigener Vorlieben zusammensuchen oder einfach weglassen – je nach Einsatzzweck.

Das Ergebnis läuft dann  mit Hilfe von Jetty selbstständig als Webserver (was die Entwicklung vereinfacht), lässt sich aber natürlich auch in einem Tomcat unterbringen.

final File file = 
    new File( MyClass.class.getResource( "myfile" ).getPath() );

Textdatei in String lesen

Will man eine solche Datei lesen und in einen String schreiben, helfen Apaches FileUtils:

public String getFileContent( final String fileName ) {
    final File file = new File( MyClass.class.getResource( fileName ).getPath() );
    try {
        return FileUtils.readFileToString( file );
    } catch ( final IOException e ) {
        throw new RuntimeException( "Cannot find file: " + file.getAbsolutePath(), e );
    }
}

Beispiel Binding-Möglichkeiten

Implementierung an Interface binden

Üblicherweise bindet man ein Interface an seine Implementierung:

bind(Map.class).to(ArrayMap.class);

Implementierung an sich selbst

Was aber tun, wenn man gar kein Interface hat? Blauäugig dachte ich, dass das doch genauso gehen müsste:

// Fehlerhafter Beispielcode
bind(MyClass.class).to(MyClass.class);

Aber dem ist nicht so. Stattdessen bricht Guice den Startvorgang ohne verwertbare Fehlermeldung ab. Die Lösung ist stattdessen viel einfacher:

bind(MyClass.class);

Typ an Provider binden

Ein weitere interessante Möglichkeit ist die Bindung eines Typs an einen Provider, welcher Instanzen des Typs bei Nachfrage erzeugt und zurückgibt.

bind(MyClass.class).toProvider(MyClassProvider.class);

Generics und mehr

Solche und weitere Möglichkeiten, wie das leider etwas unschöne Binden generischer Klassen, lässt sich in den Javadocs nachlesen. Diese sind auch online verfügbar.

ObjectUtils.defaultIfNull

System.out.println((String) null);
// "null"
System.out.println(ObjectUtils.defaultIfNull(null, ""));
// ""
System.out.println(ObjectUtils.defaultIfNull("a", ""));
// "a"

In der mir noch stets unterkommenden Variante 2.4 ist recht nervig, dass die Funktion schlicht Object zurückgibt und man seine Ergebnisse stets umständlich casten musste. In 3.1 ist der Rückgabetyp endlich generisch und kann direkt weiterverwendet werden.

ObjectUtils.firstNonNull

In eine ähnliche Kerbe schlägt die Funktion firstNonNull aus dem selben Paket. Sie liefert aus einer Liste optionaler Werte den ersten, der nicht null ist.

System.out.println(ObjectUtils.firstNonNull(null, null, "a", null, "b"));
// "a"

Nach der vollständigen Syntaxanalyse, die man von Eclipse schon heute gewohnt ist, ist dies ein weiterer Schritt mit großem Effizienzsteigerungspotential. Und für Testmuffel werden Unittests um einiges interessanter…