Bereits seit Java 5 besteht die Möglichkeit mit der JVM Option -javaagent eigene Klasse in das Klassenladen der VM einzuklinken und so zu verändern bevor diese ausgeführt werden. AspectJ nutzt das z.B. um Aspekte auf Bytecode Ebene "einzuweben".
Ein schönes OpenSource Tool, welches sich diese Möglichkeit ebenfalls zu Nutze macht, ist: LimpidLog
Leider gibt’s das so gut wie gar nicht, das einzige was ich finden konnte ist der FastStone ImageViewer. Der hat allerdings so seine Macken beim Abspielen von ganzen Verzeichnissen und noch so ein paar Seltsamkeiten. Also was tun? Selber machen!
Auch für Java ist das Angebot gross, wenn man einen Bildbetrachter sucht, leider kann kein einziger seine Slideshow auch auf einem zweiten Monitor darstellen. Wenn man jedoch die APIs studiert, stellt man fest, dass Bilder laden und anzeigen eh nur ein Zweizeiler ist und auch das Umschalten in der FullScreen-Mode geht seit Java 1.4 ganz einfach …
Bislang gab es vor allem zwei Ansätze JSF und Spring einander näher zu bringen:
Erstere liefert über einen Custom Variable Resolver die Möglichkeit auf Spring-Beans aus JSF (mit Hilfe der ExpressionLanguage) zuzugreifen.
JSF-Spring fügt dann noch die Möglichkeit hinzu auch von Spring aus auf JSF zugreifen zu können.
Aber mit Spring 2.0 braucht man das eigentlich gar nicht mehr …
Beim Testen von Java Programmen die Nebenläufigkeiten und Synchronisation enthalten, bekommt man schnell Probleme. Zum einen stellt man fest, dass es recht schwierig ist Testfälle zu konstruieren, die alle relevanten Codeteile durchlaufen. Und selbst wenn das geschafft ist, kann man noch nicht sicher sein, dass das Programm sich unter realen Bedingung korrekt verhält.
Die zeitlichen Anläufe, der nicht vorhersagbare Wettbewerb vieler Threads lassen sich schlecht oder gar nicht simulieren. Selbst wenn man Tests entwirft, die mit mehreren Threads arbeiten, stellt man schnell fest, das die Testabläufe fast vollkommen deterministisch sind und das zufällige Zeitverhalten einer echten Anwendung in keiner Weise erreicht wird. Deshalb findet man mit solchen "fast" deterministischen Tests auch potentielle Deadlocks oder Race-Conditions meistens nicht. Diese Probleme tauchen dann erst im Betrieb auf …
Was hilft, ist den Test weniger vorhersagbar zu machen, das Zeitverhalten zu variieren. Das kann man erreichen, in dem man etwas "Zufall" in den Code einfügt.
Für Java Projekte gibt es ein schönes Plugin mit dem Dependencies eines Packages graphisch angezeigt werden können: Byecycle.
Es zeigt die insbesondere zyklische Abhängigkeiten in rot an und hilft so, diese zu vermeiden. Die Grafik richtet sich wie mit Gummibänden und Schwerkrafteffekt selbst aus, was auch “fürs Auge” schön anzusehen ist. 
Nachdem mir die erste Lösung schon sehr nützlich vorkam, hab ich noch einmal nachgelegt. Die 2. Version unterstützt nun einige Datentypen mehr, die als Property gesetzt werden können.
Neben den primitive Types, lassen sich Maps, Sets, Lists, Properties und einfache Arrays als Bean-Property "injecten". Als Wert werden sowohl für Keys in Maps, als auch für Collection-Items selbst wiederum alle diese Typen akzeptiert. Ausserdem können natürlich an allen Stellen auch Referenzen auf andere Beans gesetzt werden. Alles ist – wie schon die erste Version – als eine einfache Klasse implementiert.
Gestern in der Sneak gabs Crank mit Jason Statham. Absolute geil! Schnell, Adrenalin pur, witzig vor allem die Coolness des Hauptdarstellers. Empfehlenswert … Weiterlesen
Wenn man einmal die Vorteile einer BeanFactory ala Spring kennengelernt hat, will man deren Vorteile nicht mehr missen. Es ist einfach viel angenehmer – insbesondere auch im Hinblick auf die Testbarkeit – wenn man Klassen als POJOs entwirft, die Eigenschaften besitzen, die von aussen gesetzt werden (Dependency Injection). Nun will man aber nicht immer einen "Container" wie Spring bemühen, selbst wenn Spring modular aufgebaut ist und leicht die Verwendung nur von Teilen erlaubt. Konkret wollte ich Dependency Injection sogar gerne in einem Appet nutzen, wofür mir Spring zu gross erschien. Ergebnis war eine eigene kleine "BeanFactory" ala Spring … Weiterlesen
[:de]Neulich stellte sich mir die Frage, warum eigentlich nicht auch SWT Applikationen als Applet laufen können. Gut der erste Grund ist sicherlich, dass SWT nicht immer installiert ist, im Gegensatz zu Swing, was schon mit dem JRE dabei ist. Allerdings ist das so dramatisch auch wieder nicht in Zeiten schneller DSL-Leitungen, dann wird’s eben nachgeladen.
Was aber noch dazu kommt: SWT braucht native Libraries und native Libraries lassen sich nicht so einfach über den ClassLoader nachladen, wie irgendwelche Java-Klassen.
Ist das Applet allerdings signiert, dann ist auch das kein Problem und was dann mit relativ wenig Aufwand möglich ist …
Will man Spring zusammen mit Hibernate 3 verwenden, so muss man beachten, dass die DataAccessObjects (DAOs) nicht ohne weiteres mit Spring zusammenarbeiten. Eine gute Spring-Integration ist aber wünschenswert, weil man nur so in den Genuss der Spring-Features wie z.B. deklaratives Transaction-Management oder JTA-Transactions kommt.
Ausserdem begegnet man bei der Verwendung von Hibernate 3 mit Sicherheit auch dem Lazy Loading, das seit Hibernate 3 per Default aktiviert ist. Dieses Feature sorgt dafür, dass nicht sofort benötigte Datenbankinhalte beim "Load" gar nicht geladen werden, sondern erst dann wenn man sie tatsächlich braucht.
Das funktioniert aber nur, wenn zu einem späteren Zeitpunkt – wenn dann auf die Datenbank zugegriffen wird – die Hibernate-Session auch noch offen ist …
