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. > >> > > > > > >
