Class.forName ? Probably not ...

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 {} \;

Kommentare

Thomas Mueller hat gesagt…
How should a OSGi-aware library load user defined classes? For example, an embedded database that allows users to register user defined triggers using Statement.execute("create trigger xyz before insert on test call \"com.acme.MyTrigger\""). The embedded database then needs to load the class com.acme.MyTrigger somehow - but how? The current implementation tries Class.forName(className), and if that fails, it calls Class.forName(className, true, Thread.currentThread().getContextClassLoader()). If that's wrong, what is the correct way? The embedded database is supposed to work in both OSGi and non-OSGi environments.

If there is no 'easy' solution for OSGi that always works, what about supporting rules that define how to load the class (optionally with parameters) as in: Statement.execute("create trigger ... call \"com.acme.MyTrigger?bundle=abc&version=1.1\"") (OSGi) or "create trigger ... call \"com.acme.MyTrigger?service=def\"" (OSGi) or \"com.acme.MyTrigger?loader=context\"" (only use the context class loader) or \"com.acme.MyTrigger?loader=forName\"" (only use Class.forName).

Please forgive me my current non-knowledge about OSGi.
10. Dezember 2010 um 09:06
fmeschbe hat gesagt…
This post is about not using the Class.forName() method. It is not about don't ever try to load classes. Thus the library should do getClass().getClassLoader().loadClass(theClazz) or Thread.currentThread().getContextClassLoader().loadClass(theClazz). There is nothing wrong in using the ClassLoader.loadClass method; just don't use Class.forName().

As for the "loader hint": I think this completely defeats the whole idea of OSGi and loose coupling. Thus it creates even more harm.
10. Dezember 2010 um 09:46
Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Ready to serve requests ...

In the Apache Sling project we have an interesting problem : Knowing when the application has finished its startup. Coming from a background of a traditional application, you know when the system has finished its startup. For example, a servlet container knows it has finished the startup, when all web applications have been started. In Apache Sling, the situation is a bit different: Apache Sling is an extensible system, where extensions may simply be added by adding more bundles. "Easy", you say, "just wait for all bundles to have been started and you know when the application is ready". True, but there is a catch. To extend Apache Sling, you register services with the OSGi registry. "Still easy", you might say. Right, if the services are all started by bundle activators, we still can depend on having all bundles started for the system to be ready. Again, this is only part of the story: Some services depend on other services. So the dependent services may
Mehr anzeigen

LinkedHashMap's hidden (?) features

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
Mehr anzeigen

OSGi Bundles require Classes from the Environment

Imagine your great application running inside an OSGi framework such as Apache Felix or Eclipse Equinox and requiring a class, which you know is provided by the Java Platform but not provided inside the framework. For example, you provide functionality for the general user on the Internet to submit comments or register themselves but you want to protect this functionality from robots. To do this, you include a Captcha and decided to use the simple java captcha library from SourceForge. This library requires classes from the com.sun.image.codec.jpeg package. This package is generally not made visible inside the framework. So, what can you do ? Of course you could configure your OSGi framework to just make the package visible by configuring either the org.osgi.framework.system.packages or the org.osgi.framework.bootdelegation property accordingly. But what if you can't do that ? Here come the so-called Extension Bundles. Extension Bundles are actually Fragment Bundles, which a
Mehr anzeigen