JavaBlog

Caching spielt bei der Entwicklung von Webapplikation eine entscheidende Rolle. Nicht jedes Element auf einer Seite soll bei einem Request komplett neu generiert werden. Beispiel dafür sind RSS-Feeds, die in Form einer Newsliste auf einer Homepage dargestellt werden. Hier soll nicht bei jedem Request der RSS-Feed vom anderen Server abgeholt und neu geparst werden, da jedes Einlesen mit erheblichen Zeitaufwand verbunden ist.

Eine typische Lösung ist, den RSS-Feed nach dem ersten eintreffenden Request für eine Zeitspanne (z.B. für eine Stunde) im RAM zu halten. Jeder weitere Request innerhalb dieser Zeitspanne verwendet das gecachte Objekt. Nach Ablauf dieser Zeitspanne verfällt der Cacheeintrag und der nächste Request sorgt dafür, dass der RSS-Feed neu generiert wird und wieder in den Cache abgelegt wird.

Man kann sich so einen Cachingmechanismus mit Hilfe einer HashMap und einem Object-Wrapper selber bauen. Oder man spart sich die Arbeit und nutzt ein vorhandenes Caching-Framework wie OSCache von OpenSymphony.

OSCache bietet generische Caching-Klassen mit unterschiedlichen Cache-Algorithmen wie Least Recently Used oder FIFO. Die Cache-Einträge können zudem persistiert werden, damit sie einen Webserver Neustart überleben und nicht neu generiert werden müssen.

Mehr zum Einsatz dieser Cache-Bibliothek gibts im zweiten Teil.

Manchmal darf man als Java-Entwickler auch JavaScript programmieren. Dabei stört mich der fehlende Compiler, der den Code auf Tippfehler oder versehentlich definierte globale Variablen überprüft. Abhilfe schafft JSLint, ein JavaScript Programm, das JavaScript validiert. Neben Fehlern werden auch Coderichtlinien wie Klammersetzung oder Variablennamen berücksichtigt.

Abschliessend noch ein Zitat von Douglas Crockford (Entwickler von JSLint):

JSLint will hurt your feelings

Mit dem Web 2.0 Hype kam eine Vielzahl von Javascript Frameworks. Neben der obligatorischen Unterstützung für asynchrone Requests bieten diese Frameworks auch zusätzliche Features wie Animation oder eigene UI-Controls. Diese Woche habe ich mir die Yahoo! User Interface Library (YUI) genauer angeschaut und bin bis jetzt begeistert.

Typischerweise zeichnen sich die bisherigen JavaScript Frameworks wie Dojo oder Rico durch eine eher dürftige Dokumentation aus. Dagegen ist die YUI Library von Yahoo vorbildlich dokumentiert. Besonders gefällt mir die hohe Anzahl an Code-Beispielen und die “Cheat Sheets”, die eine sehr schnelle Einarbeitung in die Library ermöglichen.

Beispiele:
Cheat Sheet für das “Animation” Modul
Dokumentation für das “Autocomplete” Modul

Ach ja: Die Library ist Open Source (unter der BSD Lizenz).

Webapplikationen können über die HttpSession keine Daten austauschen, da eine HttpSession immer an einen ServletContext gebunden ist. Wenn eine Webapplikation eine andere Webapplikation über den RequestDispatcher inkludiert, wird zwar eine Session mit der gleichen(!) SessionID erzeugt, es sind aber effektiv zwei HttpSession Objekte vorhanden.
Vergleiche Servlet Specification 2.4. (Kapitel 15.1.7)

Session information is scoped only to the current web application
(ServletContext), so information stored in one context will not be directly visible
in another.

Auch für JSR 168-konforme Portlets gelten diese Restriktionen. So konnen Portlets nur innerhalb der gleichen PortletApplication gemeinsame Daten austauschen. (Eine PortletApplication wird mit Hilfe einer Webapplikation realisiert). Diese Restriktion soll mit JSR 286 aufgehoben werden. Im Early Draft Review werden sogenannte “Shared Session Attribute” vorgestellt. Hier definiert der Portlet-Entwickler die gemeinsamen Session Attribute in der portlet.xml. Das JAXB Framework (Java Architecture for XML Binding) wird verwendet, um den Typ des Session Attributes zu beschreiben. Konkret bedeutet dass, das die Klasse für das Shared Attribut mit JAXB Annotations versehen wird. So kann das Attribut auch in anderen VMs ausgelesen werden, da die Klasse mit Hilfe von JAXB wieder zusammengebaut wird (Stichwort “marshalling”).