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.
