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
