One of my first tasks as a River developer was to rewrite ClassDep,
previously it was based on a jvm tools library, now it uses ASM.
What became painfully obvious at the time: IT IS NOT POSSIBLE to
determine all runtime dependencies at compile time.
However this could be sufficient for most developers, even if it's not
preferred, a class found during runtime may be not be available at the
client and could still be loaded from the proxy jar, it just means the
parent class loader will be tried first.
So the preferred list automatically generated would not necessarily be
comprehensive, but in most cases adequate, this seems less confusing
than writing a new class loader with different behaviour.
Can anyone see any issues with this?
Peter.
Peter Firmstone wrote:
Well spotted, I spoke to Peter Kriens over the phone about this in
2010 (very smart guy btw), ClassDep doesn't detect Class.forName
dependencies.
A string might not be defined until runtime, so it's not something
that can be easily determined. This could become even more difficult
if dynamic languages like Groovy are used in the proxy.
Another alternative might be to prefer everything resolvable by the
proxy codebase string annotation at runtime. It would be up to the
developer to ensure that proxy classses are packaged correctly,
annotations could go some way to automating this for the developer.
The developer could include any library jars required in their
codebase string.
Perhaps a classloader called ProxyPreferredClassLoader might be
created for such a purpose.
@ServiceAPI - dependency tree excluded from proxy codebase.
@SmartProxy - root class for dependency search, to determine classes
to be included in proxy jar file.
Consideration has to be given to felixibility for developers using
Maven, OSGi and dynamic languages.
Peter.
Could work for anything other than cases where someone makes liberal
use of
dynamic class loading via Class.forName and similar. So let's say I
have a
smart proxy that has some dynamically assembled bits, the references
will
be in String form making bytecode analysis difficult.
I wouldn't say this is likely a common case, more something that
would have
to be noted as a limitation of the tool so developers are not caught
out.
