Unser neuer PodcastUnter
http://se-radio.net/ gibt es den neuen SE-Radio Podcast, an dem auch ich beteiligt bin. Die Idee ist, regelmäßig interessante Themen aus dem Bereich der Software-Entwicklung durch dieses neue Medium zu vermitteln. Die Ausrichtung ist dabei eher auf Technologien. In einer Folge sprechen Markus Völter und ich über Dependencies, die anderen beiden jetzt schon verfügbaren Folgen sind ein Beitrag über Patterns und ein Interview mit Doug Schmidt.
Kommunikation ist endlich wieder ein Abenteuer!Ja, die Welt war so schön: Internet breitbandig und zuverlässig zu Hause. Telefonieren ohne Probleme und dann auch noch mobil, wenn man will. Anscheinend war es zu schön und der "technische Fortschritt" steht auch nie still.
Nehmen wir Skype: Zugegebenermaßen ein "It just works". Meistens. Wenn es nicht so wäre, dass dann überraschend irgendwo Rauschen auftaucht. Oder die Verbindung kurz weg ist. Letzteres ist ja wg. IP-Kommunikation noch erklärlich, aber der Grund für das Rauschen wird sich wohl nicht lokalisieren lassen.
Oder Internet per UMTS. Es ist wie in den guten, alten Tagen: Man schaut auf den Modem Monitor, um zu sehen, ob die Verbindung noch steht, und auf den Netzwerk Monitor, um zu sehen, ob noch Daten durchgehen. Und dann greift man zu Maßnahmen wie einem dauerhaft laufenden Ping, was zumindest subjektiv die Zuverlässigkeit erhöht.
Besonders spaßig ist es, Web Seiten auf dem Mobiltelefon anzuschauen: Der kleine Bildschirm ist ja schon ein Problem, aber lustige Fehlermeldungen wie "Die Seite ist zu groß" oder "Irgendwas stimmt mit der Seit nicht" garniert mit Abstürzen, bei denen man den Akku aus dem Handy rausnehmen muss, damit wieder was funktioniert, erinnern an die dunklen Netscape Zeiten, als man jedes neue Update in der Hoffnung installierte, dass es nun stabiler wird.
Ganz klar: Die neuen Technologien haben ihre Vorteile, aber vielleicht sollte man mal einen Moment innehalten und sich vergegegenwärtigen, was wir schon alles schönes haben. So, und jetzt gehe ich Skypen.
Und? Wie einfach ist Java EE 5?Eine interessante Frage bezüglich Java EE 5 ist natürlich, wieviel die Vereinfachung bringt. Mein Kollege Christian Heinemann, hat sich dazu die
Portierung des
Adventure Builders von J2EE 1.4 auf Java EE 5. Dies ist eine Demo Anwendung, die zeigen soll, wie man Java EE Anwendungen baut.
Die Ergebnisse:
- Die Anzahl der Interface ist um mehr als die Hälfte gesunken.
- Die Anzahl der Code Zeilen aber nur um 9%.
- In sehr vielen Fällen werden Java EE Ressourcen wie der Entity Manager aus JNDI ausgelesen, statt Dependency Injection (DI) zu verwenden.
Aus meiner Sicht bedeutet dies, dass DI in Java EE eben nicht sinnvoll umgesetzt ist, da es auf Java EE Elemente beschränkt ist und dadurch Utility Klassen usw. so nicht verwaltet werden können. Bei Spring ist dieses Problem nicht vorhanden, da eben beliebige Objekte per Dependency Injection veraltet werden können.
In Bezug auf den Code selbst finde ich die Abnahme der Interface-Anzahl nicht überraschend, denn die alte Version hat EJB Interfaces ausprogrammiert, so dass sich hier eine massive Reduktion ergeben muss. Aber das dies nur zu 9% weniger Code führt, ist nicht sonderlich beeindruckend.
Vor allem bei DI habe ich das Gefühl, dass Java EE auf halben Wege stehen bleibt. Interessanterweise ist das jetzt schon klar und es führt jetzt schon zu Themen wie im Adventure Builder. Vielleicht droht ein zweites
Pet Store.
Spring Tag auf der JAXDas Programm für die JAX Konferenz findet sich
hier. Ein besonderes Highlight (aus meiner Sicht) ist der Spring Tag, den ich auch mit organisiert habe. Das Programm bietet nach meiner Meinung einen guten Überblick über verschiedene weitergehende Themen wie Spring IDE, Spring Web Flow, das Acegi Sicherheits Framework, die Spring-JSF Integration sowie modell-getrieben Entwicklung und Spring. Ein Highlight ist sicher auch, dass mit Jürgen Höller einer der wichtigsten Entwickler des Spring-Frameworks uns aus erster Hand einen Überblick über die neuen Features in Spring 2.0 geben wird. Außerdem gibt es einige Case Studies, die zeigen werden, wo überall Spring heute schon verwendet wird und welche Erfahrungen dabei entstanden sind.
MobilitätskonzepteIch stelle zunehmend eine Änderung fest, wie ich meine mobile Arbeit organisiere:
- Statt einem Replizieren meiner Daten auf meinen stationären Rechner, arbeite ich liebte weiter mit dem Laptop und einem externen Monitor und Tastatur.
- Mobiles Internet immer und überall wird durch UMTS / GPRS möglich. Dadurch kann man mehr online halten und Web-Dienste wie backpackit werden noch attraktiver.
- Zugriff auf meinen GMail Account ist mit dem Mobiltelefon überall mit einigen wenigen Tastendrücken möglich.
Dadurch wird langsam aber sicher tatsächlich die Vision von "always online" und volliger Mobilität realistisch. Theoretisch war das schon länger denkbar, aber mittlerweile ist es eben Realität. Das hat aus meiner Sicht vor allem den Vorteil, dass man immer und überall arbeiten kann. Das ändert auch die Bedeutung von der Kooperation durch die Möglichkeiten der Vernetzung - gerade für Berater ein wichtiges Thema. Schauen wir mal, was die Zukunft da noch an weiteren Dingen bringt.
Intel Macs?Steve hat uns also Intel Macs gegeben. In diesem Zug ist die etablierte Marke PowerBook dann auch gleich gegen den Namen Mac Book ausgetauscht worden. Dabei hat PowerBook nichts mit PowerPC Prozessoren zu tun, denn schon die 680x0 Notebooks hießen so. Sei's drum, Steve wird nicht böse sein, dass ein Name, der nicht in seiner Zeit etabliert wurde, jetzt eliminiert wird.
Ich werde mir kurzfristig zumindest nicht kein Mac Book kaufen (und schon gar kein stationäres Gerät). Der Grund? Die Maschinen sind "nur" schneller und Geschwindigkeit habe ich ausreichend. Erinnert ein wenig an die Leistungsangabe bei einem Rolls Royce, die angeblich auch "ausreichend" ist. Zudem gibt es kein 12" Gerät und ein solches will ich. Und außerdem fehlt schlicht Software. Heise nach zu urteilen, kommt Firefox im März mit einer Intel Version. Das bedeutet, dass noch einige Zeit in's Land gehen wird, bevor die Software, die ich so typischerweise nutze, portiert ist. Ich habe sogar noch eine Mac OS 9 Anwendung (Outlook), die ich nicht so einfach ersetzen kann, denn Eudora kommt mit dem fraglischen Exchange-Server nicht klar. Da ist natürlich die Frage, ob Mac OS 9 Anwendung auf Intel überhaupt laufen.
Ein wesentliches Argument wäre natürlich eine Lösung, die einem den Betrieb von Windows oder Linux ohne signifikanten Performance Nachteil erlaubt. Dazu wäre aber VMWare oder Virtual PC für Mac/Intel notwendig.
Das Ende vom Lied ist, dass für mich eine vierfache Performance einfach kein ausreichendes Argument ist. Abgesehen davon, dass nun auf einmal die Intel Prozessoren viel schneller sind, obwohl Microsoft gerade bei der XBox 360 Richtung PowerPC geht. Na ja, vielleicht werfe ich doch noch einen Blick in einen Apple Laden, wenn die Rechner lieferbar sind...
Spring und TestenEs gibt zwar auch gerade (wie hier schon geschrieben) eine Diskussion zum Thema Testen und Dependency Injection, aber ich muss dennoch noch einmal etwas zu dem Thema sagen. Ich habe langsam den Eindruck, dass man das Thema Testen in seiner Wichtigkeit gar nicht überschätzen kann. Es ist eine triviale Weisheit: Ohne Testen kann man die Qualität einer Software nicht gewährleisten. Trotzdem gibt es in diesem Bereich immer noch deutliche Innovation. JUnit war die erste, die Testing plötzlich in den Vordergrund gerückt hat. Der nächste Schritt für mich war Easymock. Man hat sich dann gefragt, wie man vorher überhaupt Tests geschrieben hat. Die letzte größere Innovation scheint Fit zu sein, mit dem auch Akzeptanz-Tests mit einem einfachen, eleganten und effektiven Tool besetzt werden.
Das interessante ist nun, dass Dependency Injection (DI) sich tatsächlich in diese Reihe von Test-Tools in gewisser Weise einreiht. (Ja, ich bin voreingenommen und dies ist vereinfacht). Dennoch stellt sich bei der Auswahl von Möglichkeiten, die Spring bietet, die Frage, welcher Teil denn nun der wichtigste ist. Erstaunlich oft ist die Antwort DI. Es geht ja eigentlich "nur" darum, die Abhängigkeiten in einer Anwendung anders zu organisieren. Nachdem meistens sowieso eine oder mehrere Factories eingesetzt werden, ist die Einführung von DI in einem existieren Projekt eigentlich recht aufwändig. Und der nutzen ist recht gering: Man bekommt die Referenzen halt zugewiesen, statt sie selber zu suchen. Erst wenn man die isolierte Testbarkeit in die Gleichung einfügt, wird klar, dass der Aufwand gerechtfertigt ist. Auch die Abstraktion von der Ausführungsschicht (Java EE oder Java SE) bringt vor allem Vorteile beim Testen. Es ist also möglicherweise nicht die Vereinfachung von Java EE, die das entscheidende Argument darstellt, sondern die leichtere Testbarkeit. Insofern ist Spring vielleicht wirklich ein Testtool....
Artikel im Java MagazinIm aktuellen Java Magazin sind zwei Artikel von mir: Zum einen über das Acegi Security Framework, das aus dem Spring-Umfeld kommt und meiner Ansicht nach eine interessante Alternative in diesem Bereich darstellt. Zum anderen gibt es den Salon, in dem Jan Leßner, Oliver Ihns, Andreas Holubek und ich jeweils unsere Meinung zum Thema Dependency Injection, Testing und EJBs niedergelegt haben.
Tournee DatenIch gebe im Januar einige Vorträge:
- Am 18.1. auf der OOP zum Thema "Java EE ganz einfach". Mehr Infos hier und Eintrittskarten gibt es hier.
- Am 20.1. in Stuttgart zum Thema Spring beim ObjektForum Stuttgart, Alte Scheuer Degerloch ab 18:30. Eintritt ist kostenlos.
- Am 30.1. abends in Dresden. Näher Infos und Anmeldungen bitte bei mir persönlich, EMail findet sich im Profil.
Vielleicht sieht man sich ja...
UMTS: Die stille RevolutionDieses Posting ist eine Premiere, denn es ist das erste, das ich über eine Mobilfunk-Verbindung erstellt. Seit dieser Woche bin ich Besitzer des SonyEricsson
K600i UMTS Mobil-Telefons und der dazu passenden
EPlus Daten Flatrate. Das ganze ist mit 30-40 kB/s bei Download nicht so schnell wie DSL (was auch niemand erwartet hat) und insbesondere die Latenz ist hoch (ping auf www.web.de ist ca. 300ms). Dadurch ist die Benutzung eines Microsoft Terminal-Servers nur bedingt spaßig. Aber ansonsten läuft es recht gut.
Interessant war die Beauftragung: Man kann die Tarif-Option nicht gleich zu dem Vertrag dazubuchen, sondern man muss bei der Hotline anrufen. Auch online buchen geht nicht. Freundlicherweise hat der EPlus Shop für mich den Anruf getätigt. Als dann online nicht zu sehen war, habe ich selbst nachgehagt. Aussage war dann, dass man in "Mein EPlus" im Internet sieht, wenn die Sache aktiv ist und das es beantragt ist. Ein Tag später war da immer noch nichts zu sehen. Lustigerweise war es aber schon so, dass meine GPRS Verbindungen (UMTS taucht anscheinend explizit gar nicht auf) nicht mehr berechnet wurde. Die nächste Aussage von der Hotline war dann, das es aktiv ist...
Was lehrt uns das? Auch bei EPlus gibt es mindestens zwei unterschiedliche Systeme, nämlich für die Hotline und für Internet und beide sind anscheindend nicht gleich mächtig. Das aber nur als amüsante Bemerkung am Rande.
Ansonsten wie gesagt eine schöne Sache, aber weit davon entfernt, die große Revolution zu sein, die 2000 mit UMTS erwartet wurde. Es ist halt nur ein mobiles DSL und preislich auch nicht so teuer, dass es viel Profit verspricht. Vor allem ist EPlus dadurch ein Internet Service Provider und prinzipiell austauschbar. Aber was soll's, für den Kunden ist es auf jeden Fall toll.
BTW: Erwähnte ich, dass man auch offiziell Skype über diesen Service machen kann? Damit kann man dann im Prinzip mobil kostenlos telefonieren. VoIP ist allerdings nicht erlaubt, Chats gehen aber anscheinend. Fehlt noch ein Skype UMTS Mobiltelefon.
Noch ein Spring 2.0 Feature: SimpleJdbcTemplateNachdem das Java Magazin
hier einen Link auf meinen Blog hatte (danke!), hier noch ein neues Feature aus Spring 2.0: Das SimpleJdbcTemplate.
Die JdbcTemplates aus Spring sind ein wichtiges Feature von Spring, da die Fehlerquellen in Bezug auf das Schließen der verschiedenen JDBC-Ressourcen damit eliminiert werden und die API auch wesentlich einfacher ist als die pure JDBC API. Sie sind ohne den Rest von Spring nutzbar, so dass man sie auf jeden Fall verwenden sollte, wenn man JDBC Code schreiben will. Das SimpleJdbcTemplate verwendet nun JDK 1.5 Features, um das Leben noch einfacher zu machen. Hier ein Code-Beispiel:
getSimpleJdbcTemplate().update(
"INSERT INTO KUNDE(VORNAME,NAME,KONTOSTAND) "+
" VALUES(?,?,?)",
kunde.getVorname(), kunde.getName(),
kunde.getKontostand());
Dabei muss die Klasse von SimpleJdbcDaoSupport erben, damit man mit getSimpleJdbcTemplate() auch ein SimpleJdbcTemplate bekommt (alternativ kann man selber eines unter Angaben einer DataSource oder eines JdbcTemplates erzeugen).
Was hier nun auffällt ist, dass man bei Kontostand nicht mehr double in Double umwandeln muss (Autoboxing) und man kann die Parameter einfach so übergeben, da JDK 1.5 Methoden mit einer variablen Anzahl Parameter erlaubt. Beim JdbcTemplate musste man noch ein Object-Array verwenden. Im Prinzip ist der Umgang recht natürlich: Man gibt eben die SQL-Anfrage an und die Parameter - das war's.
Für Queries kann man nach wie vor queryForInt oder queryForLong verwenden, falls man einen primitiven Typ als Rückgabe erwartet. Neu ist, dass bei dem generischen queryForObject aus dem übergebenen erwarteten Typ vom Compiler Typ-Informationen abgeleitet werden, so dass der Typ-Cast entfällt:
Date d=
simpleJdbcTemplate.queryForObject(
"SELECT date from DBLOG where id=?", Date.class, id);
Hier ist keine Umwandlung in ein Date mehr nötig.
Wenn man nun ein fachliches Objekt erzeugen will, kann man die Daten aus dem SQL-Statement auch mit einem RowMapper in ein solches Objekt umwandeln. Auch hier sorgt das bessere Typ-System von JDK 1.5 dafür, dass einiges eleganter wird:
public class KundeDAO extends SimpleJdbcDaoSupport {
private static final class KundeResultSetRowMapper implements
ParameterizedRowMapper {
public Kunde mapRow(ResultSet rs, int rowNum) throws SQLException {
Kunde kunde = new Kunde(rs.getString(1), rs.getString(2), rs
.getDouble(4));
kunde.setId(rs.getInt(3));
return kunde;
}
}
public List getAll() {
return getSimpleJdbcTemplate().query(
"SELECT VORNAME, NAME, ID, KONTOSTAND FROM KUNDE",
new KundeResultSetRowMapper());
}
public Kunde getByID(int id) {
return getSimpleJdbcTemplate()
.queryForObject(
"SELECT K.VORNAME, K.NAME, K.ID, K.KONTOSTAND FROM KUNDE K WHERE K.ID=?",
new KundeResultSetRowMapper(), id);
}
}
Wie man sieht, gibt es nun den ParameterizedRowMapper. Dadurch wird es hier möglich, anzugeben, dass dieser als Ergebnis einen Kunden zurück gibt. Dadurch kann dann die getAll()-Methode ohne weiter Typ-Umwandlungen als Ergebnis ein List
zurückgeben. Und bei getById() wird der Rückgabetyp Kunde ebenfalls automatisch abgeleitet.
Ingesamt empfinde ich diese Möglichkeiten als extrem elegant. Sie zeigen auch sehr deutlich die praktische Relevanz der JDK 1.5 Features. Von daher ist dies auf jeden Fall ein guter Tipp für Leute, die JDBC direkt nutzen wollen.
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
