camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <>
Subject About 4 method signatures by the ClassResolver API
Date Fri, 08 Feb 2013 10:42:18 GMT

Looking at the public ClassResolver API (among others) it provides 4 methods
taking over the concrete to be loaded Class type:,%20java.lang.Class%29,%20java.lang.Class,%20java.lang.ClassLoader%29,%20java.lang.Class%29,%20java.lang.Class,%20java.lang.ClassLoader%29

However referencing the to be loaded Class type in this way would make the
given Class object to be already loaded statically through the JVM itself
:-) so that as soon as the actual parameters are put on the call stack for
these methods the concrete Class object is already loaded even *before*
these methods return!

I think originally the idea behind these methods was to avoid a need to
(explicitly) type cast for the caller, e.g. like the following method we've
got by the Exchange interface:,%20java.lang.Class%29

However in case of the ClassResolver API the same doesn't make much sense
(correct me if I'm wrong) so IMHO we should better @deprecate these methods
and remove them in 3.0 because the idea behind the ClassResolver API is to
*dynamically* load the classes, however using these methods make the given
classes already being *statically* loaded. 



View this message in context:
Sent from the Camel Development mailing list archive at

View raw message