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 19:04:50 GMT
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
>>
>>
>>
>
>
>


Mime
View raw message