Greetings everyone. Hope you all had a great Christmas and new years.
I've taken a look at instrumentation ...
After today's JDO phone call, and from Craig I understand that one of
the intentions of providing API access to the enhancer is to enhance
classes on the fly (just-in-time enhancement ?), and that the
instrumentation mechanism could be used for this. I have some vague
memory about using an enhancer API as a way to integrate the JDO toolkit
into an IDE. This would not require the "just-in-time" enhancing that
is suggested by the passing of a resource (or passing a java.lang.Class
object) to the enhancer API. As the specs stand now, enhancement would
ideally be supported in the build stage. The entire JDO spec seems to
be bent in this direction so far...
Most importantly, there's a fundamental difference between enhancement
and instrumentation that we should take into account. Instrumentation
seems to be directed primarily at _reading_ state of the virtual machine
and program state after class files are loaded. JDO is directed at both
reading and writing object state to some storage mechanism ... JDO
enhancement modifies classes at the API level and changes an
application's functionality significantly. Mixing the two concepts
arbitrarily might cause some mental consternation among developers...
but ...
I can see why someone would be inspired to take advantage of the
instrumentation facility to support class enhancement. Instrumentation
gives us the capability to modify classes on a "just-in-time" basis,
which can be extremely handy (and tempting!). But, as Craig suspects, I
don't see any support for in instrumentation for the modification of
class members. And, the specification of an agent is required, along
with the definition of a premain method (which is not presently covered
in the JDO specification).
So, how do we take advantage of the concept of instrumentation and
incorporate it into JDO? I would suggest that creating a new
specification to support on-demand class enhancement at the VM level.
The instrumentation concept has certainly paved the way for this, and I
would love to see it happen. Restricting API calls to accept only File
objects, or in some other way enforcing enhancement to be done during
the build process is, IMHO, ideal under the current JDO specification.
Okay - resources and class names don't HAVE to eliminated from the API,
but the fact that enhancement is a build level process should be
reinforced...
But, lets please DO talk about run-time enhancement features..... :-)
Perhaps not calling it an instrumentation facility. How about an
enhancement facility?
Richard
Ilan Kirsh wrote:
private void loadTypeFromUrl(URL url) throws IOException
{
// Handle a class file:
String protocol = url.getProtocol();
if ("file".equals(protocol))
{
File file = new File(
URLDecoder.decode(url.getFile(), "UTF8"));
if (!file.isDirectory())
loadTypeFromFile(file);
}
// Handle a JAR file:
else if ("jar".equals(protocol))
{
JarURLConnection con =
(JarURLConnection)url.openConnection();
loadTypeFromZipEntry(con.getJarFile(),
con.getJarEntry());
}
}
Just to clarify, as I have not used these particular APIs:
Does this allow the enhancer to get a read/write File handle for a URL
that's in the classpath?
Yes, if there is no permission restriction.
And if it's a jar file, does it allow the enhancer to replace files
within it?
Craig
As far as I know you cannot replace an entry in a jar file using the
standard Java API. You can however, override the file with a new
complete jar file.
Ilan
