I think I didn't address one important thing, which is what I was
leading up to. For the phrase in Craig's suggested text:
"a resource loaded from a class loader that contains the byte codes
as generated by the javac compiler "
I would either qualify this to say that the enhancer tool itself (as an
application) can find its classes using the class loader _and_ that the
classes being enhanced are not used by the currently running VM (e.g.
the enhancer), or to eliminate this line for now ...
Richard
Richard Schilling wrote:
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
