AOP und dynamische Typisierung
Aspekt-orientierte Programmierung ist schon seit geraumer Zeit eigentlich ein Thema. Meiner Ansicht nach wird aber gerade durch die zunehmende Popularität dynamisch typisierter Sprachen die Sache interessanter. Einer der wesentlichen Vorteile ist eben, dass man auf Methoden-Aufrufe anders reagieren kann und dadurch einfacher generische Programme schreiben kann. Wenn man etwas ähnliches mit statischer Typisierung machen will, bleibt eigentlich nur AOP als Mittel der Wahl. Dazu gibt es
hier einen recht interessanten Artikel, der zeigt, wie man ein DAO generisch bauen kann und dann bei bestimmten Methoden mit Hilfe einer Namenskonvention eine Hibernate-Query ausführen kann. Das entspricht in etwa dem, was Ruby on Rails mit dem Scaffolding auch anbietet.
Umso verwunderlicher oder dramatischer ist es, dass anscheinend bei vielen Entwicklern die Meinung vorherrscht, dass AOP irgendwie kompliziert und unhandhabbar ist. Das merkt man vor allem daran, dass es Spring-Projekte gibt, die in die Richtung gehen, dass sie zwar Spring verwenden wollen, aber nich AOP oder keine eigenen Aspekte schreiben wollen. Meiner Ansicht nach ist das Schreiben von Aspekten gerade mit Spring recht einfach und löst viele Probleme, die man sonst nicht vernünftig lösen könnte. Gerade bei Java EE Projekten entsteht sonst leicht eine Flut an Code, die kaum etwas sinnvolles tut. Beispiele sind oft Exception Handling, Security oder auch Transaktionen.
Daher ist es wichtig, dass AOP mit Spring recht einfach handhabbar ist und mit Spring 2.0 auch eine einfache Migration in Richtung AspectJ möglich ist. Komischerweise scheint aber dennoch die Hürde höher zu sein als jene für das Erlernen einer neuen Sprache. Vielleicht spielt es auch eine Rolle, dass AOP noch das Siegel eines "offiziellen" Standards fehlt. Aber gerade bei Programmiermodellen sind solche Standards nicht immer förderlich und mit Spring oder Struts gibt es auch gute Beispiele für Programmiermodelle, die sich etabliert haben, ohne dass sie Standards sind. Und am Ende kann Code, der mit AspectJ compiliert wurde, auf jeder JVM laufen, weil es eben ganz normaler Bytecode ist - in so fern hält sich AspectJ also auch an die Standards.
Schauen wir mal, wie es da weiter geht. Interface21 ist mit
Adrian Colyer als AspectJ Lead und
Ramnivas Laddad im Bereich AOP ganz gut aufgestellt.
Computer Sammlung
Hier ein Bild von meiner Computer Sammlung.
Von links nach rechts auf dem Tisch:
- Sun 3/60 (68020, 20 MHz, 24 MB RAM)
- Auf dem Monitor: Eine Airport Extreme Base Station
- Mac Classic II mit Apple Natural Keyboard
- NeXT Mega Pixel 21 Zoll Bildschirm, NeXT Tastatur, NeXT Maus und NeXT Soundbox
- Apple II gs mit 1 MB, 2 3.5 Zoll Disk-Laufwerk, einem 5.25 Zoll Disk-Laufwerk und intern einem 64MB Compact Flash als Festplatte
- NeXTstation mono turbo (68040 @ 33 MHz)
Unter dem Tisch:
- BeBox turbo (2*PPC 603 @ 133 MHz)
- SCSI Gehäuse
- Sun externes Festplatten-Gehäuse
- NeXTcube turbo (68040 @ 33 MHz) mit NeXT dimension Farbgrafik-Karte (Intel i860, 48 MB)
Übrigens benutze ich immer noch den NeXT Laserdrucker. Und ich habe noch einen Apple IIc, der aber nicht auf dem Tisch ist.
Pressespiegel....
Ziemlich viel Rauschen im Blätterwald im Frühling. Im aktuellen JavaSpektrum findet sich ein
Interview mit Rod Johnson, dem CEO von Interface21, und Martin Percival, Senior Technology Evangelist bei BEA. Dort geht es um den EJB 3 Container und das damit assoziierte Open Source Projekt
Pitchfork, das Interface21 als freie Implementierung großer Teile der EJB 3 API auf Basis von Spring anbietet. Das bedeutet natürlich nicht, dass EJB 3 jetzt die bevorzugte API für Spring ist, siehe dazu auch die
Pitchfork FAQ.
Im
Java Magazin gibt es einen Titel zum Thema Spring 2.0, in dem es um die neuen Features geht und zum anderen noch einmal um die Konzepte von Spring. Außerdem habe ich einen
Konferenz-Bericht von der Spring One veröffentlicht, der allerdings für die Leser dieses Blogs nicht interessant sein dürfte, weil es hier viel detailierte Informationen über die Konferenz gab.
Fazit: Die Blätter rascheln nicht nur im Herbst, sondern auch im Frühling.
Spring hat schon wieder gewonnen!
Aber keinen richtigen Preis. Dafür ist es nach Expertenmeinung possibly the best structured code-base in the world! Und das ist doch auch eine schöne Auszeichnung. Mehr Infos gibt es
hier,
hier und
hier. Außerdem wird jetzt seit einiger Zeit auch SonarJ von
Hello2Morrow verwendet, um den Code zu analysieren - übrigens eine deutsche Firma...
PowerBook und UMTS revisited
Mittlerweile arbeite ich jetzt schon seit einem halben Jahr mit meinem SonyEricsson K600i UMTS Mobiltelefon und meinem PowerBook. Ohne würde ich auch nicht mehr zurecht kommen.
Dennoch habe sich mittlerweile Schwächen gezeigt. Ingesammt bin ich sehr zufrieden. Mit UMTS kann man auch Skypen, wobei ich die Erfahrung gemacht habe, dass das eingebaute Mikrofon und Kopfhörer die beste Idee sein. Ich habe auch ein Bluetooth Headset ausprobiert, aber die Ergebnisse waren weniger gut.
Ein anderes Problem ist, dass UMTS eben nicht überall zur Verfügung steht und die Kommunikation mit GPRS, die als Fallback dient, kann teilweise echt nerven. Da gibt es dann nicht nur langsame, sondern auch unzuverlässige Verbindungen. Das nervt dann schon sehr. Zum Teil gibt es dann Problem, vom ICE aus zu surfen, aber das wäre wohl auch etwas viel verlangt.
Ansonsten ist die Kombination aus Notebook und Mobiltelefon nicht wirklich zu empfehlen: Das Mobiltelefon steht nur einige Stunden durch, bis der Akku leer ist. Dabei wird das Telefon auch recht warm. Das lässt sich dann noch optimieren, indem man das Telefon an das Ladegerät hängt, dann wird es nämlich wirklich warm. Und an Tagen wie diesen, kommt es dann dazu (vielleicht wegen der Wärme), dass sich das Telefon einfach abschaltet, was recht unschön ist. Heute zumindest durfte ich dann in der Folge den Rechner neu starten, weil er nicht dazu bereit war, wieder mit dem Telefon zu kommunizieren.
Aufgrund von besserer Stromversorgung und dem Verzicht auf Bluetooth würde ich also daher eher eine UMTS Karte vorziehen, wenn denn das PowerBook einen Slot hätte. Für den neuen Slot im MacBook Pro scheint es noch keine UMTS-Karten zu geben, was auch eher suboptimal ist. Aber schauen wir mal. Übrigens gibt es bei Base dann die Möglichkeit, für die UMTS Karte eine eigene SIM Karte zu bekommen, ohne mehr dafür zu zahlen...
Die Zukunft von Enterprise Java
Hier berichtet InfoQ über eine Diskussion über die Zukunft von Enterprise Java. Die Zusammenfassung stellt einige spannende Sache klar und ingesamt ist die Diskussion offensichtlich sehr konstruktiv, was eine gute Sache ist....
Java Starter Equinox Artikel zum Download...
Mein Artikel aus dem Java Starter Magazin zum Thema Equinox kann man
hier online anschauen. Equinox ist eine Art Projekt-Kick-Starter, mit dem man schon mal ein Skelett für eine Anwendung bekommt. Vordefiniert sind Hibernate, Spring usw., aber auch eine Integration von anderen Persistenztechnologien wie z.B. iBATIS und anderen Web Frontends wie zum Beispiel JSF ist denkbar. Auch andere wichtige Dinge wie automatische Builds mit CruiseControl sind einigermaßen einfach realiserbar. Ingesamt eine praxisnahe und spannende Sache. Der Artikel beschäftigt sich damit, wie man in Equinox weitere fachliche Objekte integrieren kann.
Java Forum Stuttgart
Gestern habe ich also als Aussteller zum ersten Mal am Java Forum Stuttgart teilgenommen. Ingesamt eine recht interessante Veranstaltung und es gab auch ein recht großes Interesse an Interface21 und Spring. Von daher sicher eine gelungene Sache. Es ist immer ein gutes Zeichen, wenn am Stand keine Langeweile aufkommt. Interessanterweise gab es auch ein recht großes Interesse an Spring Rich Client, was meiner Ansicht nach auch eine recht gute Technologie ist, aber im Moment immer noch in Version 0.1 ist. Aber gerade das Design und die Architektur sind sicher interessant. Schauen wir mal, wie es damit weitergeht...
Über das Gängige...
Wenn man wirklich Anwendungen und IT-Infrastrukturen bauen will, die lange Zeit funktionieren, dann ist es sinnvoll, darauf zu achten, dass man gängige Produkte nutzt. Das sind solche Produkte, die im fraglichen Kontext von vielen anderen ebenfalls eingesetzt werden. Warum ist das wichtig? Weil in 10 Jahren nur für diese Produkte noch ernsthafter Support existieren wird, Skills am Markt vorhanden sind usw. Das bedeutet, dass als Investitionssschutz dieses Thema ein wichtiger Punkt bei der Produktauswahl sein sollte. Eine Evaluierung ist eben mehr, als nur eine rein technische Geschichte.
Vom Pattern zum Anti-Pattern?
Wenn man das GoF-Buch heute liest, sind einige der dort beschriebenen Patterns inzwischen fast zu Anti-Patterns geworden. Ein Beispiel ist Singleton. Während die ursprüngliche Idee, ein Objekt nur einmal zu instanziieren, nicht schlecht ist, ergibt sich gleichzeitig ein Problem: Das Singleton ist überall im Code bekannt und kann verwendet werden, ohne dass man dies von außen erkennen kann. Dadurch wird Testing und isolierte Wiederverwendbarkeit schwierig.
Noch entscheidender ist meiner Ansicht nach die Factory. Das Pattern hat früher die Erstellung eines konkreten Produkte vor dem aufrufenden Objekt versteckt. Grundsätzlich keine schlechte Idee, aber inzwischen weiß ich nicht mehr genau, wieviele Factories ich schon gebaut habe und wenn man dann testen will, muss man die Factories so bauen, dass man auch andere Produkte erzeugen lassen kann (Mocks).
Durch Dependency Injection lassen sich diese Themen natürlich lösen, was aber hier nicht Thema sein soll. Viel interessanter ist die Frage, ob das GoF Buch heute immer noch so geschrieben werden würde. Und ob nicht eben Patterns wie Factory oder Singleton inzwischen sogar Anti-Patterns sind.
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
