On 28/07/2016 16:59, Andrew Dinn wrote:
:
The part I am dubious about here is the URI, in particular the need to
provide a scheme (supplied as the String "byteman"). I passed that
because I get an error if I simply pass null for the scheme (it
complains that this is not an absolute URI). I can see that the module
should have a name but why does it need to be absolute? Indeed, why is
it needed at all? The various javadocs eventually lead to a suggestion
that the URI may be used by a security manager. If this is really what
it is for then do I need to worry about having invented scheme 'byteman'
out of thin air? WIl the security code ever try to convert it to a URL?
The IllegalArgumentException "URI is not absolute" is a bug, it arises
when converting the URI to a URL, we'll get that fixed.
But to your question then the module location is used as the CodeSource:
* <p> This URI, when present, is used as the {@linkplain
* java.security.CodeSource#getLocation location} value of a {@link
* java.security.CodeSource CodeSource} so that a module's classes
can be
* granted specific permissions when loaded by a {@link
* java.security.SecureClassLoader SecureClassLoader}.
and so interesting when running with a security manager and granting the
module permissions.
I am required to implement find as it has no default. I also need to
implement read so I can redirect to the agent to provide the class
format byte[]. However, it appears that find is only needed so it can be
called from the default method open and that open is only there to be
called from the default method read. Is there any possibility that
something else might call find?
The main user of ModuleReader is class loaders that load
classes/resources from the modules. ClassLoaders need to implement
methods such as findResource and findResources will attempt to return a
URL to resources in modules defined to the ClassLoader. You should see
your find method invoked for these cases.
-Alan
