db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Schilling <rschill...@cognitiongroup.biz>
Subject Re: Enhancer specification text for discussion
Date Fri, 09 Jan 2009 18:57:12 GMT
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 

But, lets please DO talk about run-time enhancement features..... :-)

Perhaps not calling it an instrumentation facility.  How about an 
enhancement facility?


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

View raw message