harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike <mikeandm...@gmail.com>
Subject Re: [GSoC] Questions about the Harmony class selector idea
Date Mon, 30 Mar 2009 07:33:31 GMT
oh, Yeah, your right, user configuration should also be a part of it.
Thanks, Regis.

Yours Mike

在 2009-03-30一的 13:43 +0800,Regis写道:
> 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.
> >>
> > 
> > 
> 
> 


Mime
View raw message