Tag Archives: code

Singletons auf die faule Art

Wir hatten heute eine kurze Diskussion über Singletons und die Art und Weise ihrer Erzeugung, speziell wenn man sie faul (lazy) erzeugen möchte. Die Wikipedia hat dazu diesen schönen Eintrag – On Demand Holder Idiom:

In software engineering, the Initialization on Demand Holder idiom (design pattern) is a lazy-loaded singleton. The idiom can be implemented in both single-threaded/serial and concurrent environments, but care must be taken to correctly implement the idiom under concurrent conditions.

Ganz besondern wichtig ist die Erklärung, warum Lazy in diesem Fall so und nicht anders funktioniert:

The implementation relies on the well-specified initialization phase of execution within the Java Virtual Machine (JVM); see section 12.4 of Java Language Specification (JLS) for details.

When the class Something is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables to initialize, the initialization completes trivially. The static class definition LazyHolder within it is not initialized until the JVM determines that LazyHolder must be executed. The static class LazyHolder is only executed when the static method getInstance is invoked on the class Something, and the first time this happens the JVM will load and initialize the LazyHolder class.

Der Browser-Krieg und seine Nachwirkungen

Ich bin fest der Überzeugung, dass wir jährlich Millionen, wenn nicht Milliarden Euro sparen könnten, wenn die Webbrowser nur korrekten Code akzeptieren würden und nicht in einen Ratemodus verfallen, wenn irgendwas im HTML nicht stimmt. Dieses Erbe aus den Zeiten der Browser-Kriege kann einen total in den Wahnsinn treiben, vor allem weil viele Leute nicht wissen, wie man mit (X)HTML und CSS korrekt arbeitet.  Oft es aber damit begründen, dass der Browser es ja auch nicht korrekt macht… Henne und Ei sage ich nur!

Es ist unglaublich, was einem als Tester bzw. Performance Tester für Code vorgesetzt wird. Nicht nur, dass oft Tools und Browser unterschiedlicher Meinung sind, wenn es um die Interpretation von HTML geht, nein, auch der Code selbst ist grottenschlecht und stellt eine Wartungshölle dar.

Wenn man den Code zurückgehen lässt oder auf Fehlerbehebung drängt, dann kommt meist zurück: “Geht doch im Browser, was wollt Ihr denn?” Als Tester kann man da wahnsinnig werden. Erst recht, wenn man selbst weiss, wie man XHTML und CSS fehlerfrei schreiben kann und welchen Gewinn man dadurch erzielt.