harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [GSoC] Questions about the Harmony class selector idea
Date Mon, 30 Mar 2009 05:43:36 GMT
Mike wrote:
> Hi Qiu:
> Here are some of my explanation towards my idea.
> 1 statically parsing classfile will cover RTTI, the inheritance will be
> determined on the compile time. From the research i've been done, it
> seems that classfile will record the its imports for us. ^_^
> 
> 2 statically parsing will miss one thing, java's reflection. But will
> the dynamically trace method will got this information if developer
> create a testcase for his/her class.

We usually use class name to load class at runtime, so if we know the 
name, we can find the dependencies. Some ones are hard coded in code, 
parse class file may get them; Others are in configuration files, it's 
hard to be collected automatically, maybe let user to provide them is a 
easy way.

> 
> 3 So i don't think two method are exclusive. These two mechanism can
> both exist in our harmony-class-selector.
> 
> Thanks again for considering my idea ^_^
> 
> Yours, Mike
> 
> 在 2009-03-30一的 12:04 +0800,QIU, Yin写道:
>> Hi Harmony folks,
>>
>> I am interested in the idea of creating a minimal JRE for a Java
>> application, but I have some questions about it.
>>
>> Having browsed the mail archive, I found I had similar thoughts to
>> Mike's. The key to this idea is to determine the class dependencies.
>> Parsing bytecode (class files or jars) would be sufficient in most
>> cases, except for RTTI. It's not easy (or even impossible) for this
>> static approach to find classes dependencies that emerge with
>> reflection. The description of the idea, as well as the previous
>> discussion on this, implies a dynamic method, which may be based on
>> the instrumentation mechanism, that is, to find dependencies by
>> running tests. Of course, this puts obligations on the developers to
>> write tests with 100% code coverage. But it seems to be a bit
>> contradictory. As harmony class selector is an *automatic* way to
>> build a JRE of minimal size, the correctness of it relies strongly on
>> the hypothesis that human beings make no faults.
>>
>> So my question is: What is the most important objective of Harmony
>> class selector? Better code coverage or a minimal JRE? If it is the
>> latter case, I would like to suggest a hybrid approach. We first parse
>> the bytecode, get a preliminary class dependency graph, write specific
>> programs to test RTTI-related code, and finally use instrumentation to
>> find if we missed some dependencies.
>>
>> I hope I made myself clear. Any comment is greatly appreciated.
>>
>>
>> Regards.
>>
> 
> 


-- 
Best Regards,
Regis.

Mime
View raw message