Hi Qiu Yin, Thank you for your suggestion.
The important objective of Harmony class Selector is to provide a minimal JRE. Follows are some good points: 1. Fast responding by dowloading the minimal size jre 2. Save resources by limiting the bandwidth 3. Enforce a good quality by requiring a sufficient tests On Mon, Mar 30, 2009 at 12:04 PM, QIU, Yin <[email protected]> wrote: > 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. > > -- > Yin Qiu > Nanjing University, China > -- Yours sincerely, Charles Lee
