camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <>
Subject Re: About 4 method signatures by the ClassResolver API
Date Mon, 11 Feb 2013 10:47:59 GMT

Any Camel commiter out there willing to express his opinion about this?


Babak Vahdat wrote
> Hi
> Looking at the public ClassResolver API (among others) it provides 4
> methods taking over the concrete to be loaded Class type:
> 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:
> 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. 
> Thoughts?
> Babak

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

View raw message