fmeschbe's blog

After subscribing to the OSGi Planet feed I felt like starting to read some old blog posts and stumbled upon a series of posts by BJ Hargave around the issues of the Eclipse ContextFinder caused by the Class.forName methods. For the full story please go and read Class.forName caches defined class in the initiating class loader (and folow the links !). So, these posts caused me to try and look how we behave in Apache Sling ... and of course hoped we would be clean. Well, hmm, turns out we are not ... I found nine classes using Class.forName . So we probably have to clean this up. Maybe or maybe not, these uses may be the cause for some strange failures we had over time. I cannot really tell. But I cannot exclude this possibility either. BTW, this is what I did to find the classes: $ find . -name "*.java" -exec fgrep -l Class.forName {} \;

Recently I discovered two very nice features of the java.util.LinkedHashMap : accessOrder and removeEldestEntry(Entry) . These features combined let you implement simple LRU caches in under two minutes. accessOrder The accessOrder flag is set when creating the LinkedHashMap instance using the LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) constructor. This boolean flag specifies how the entries in the map are ordered: accessOrder=true The elements are ordered according to their access: When iterating over the map the most recently accessed entry is returned first and the least recently accessed element is returned last. Only the get , put , and putAll methods influence this ordering. accessOrder=false The elements are ordered according to their insertion. This is the default if any of the other LinkedHashMap constructors is used. In this ordering read access to the map has no influence on element ordering. removeEdlestEntry(Entry) The second feature of ...