What's more, the selection tool as I believe, should select and gather other necessary files, e.g property file, resource bundles, etc.
Hope the discussion can help you on the proposal ;) 2009/3/30 Mike <[email protected]> > 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. > > >> > > > > > > > > > > > > -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
