QIU, Yin wrote:
Hi,
On Mon, Mar 30, 2009 at 1:06 PM, Mike <[email protected]> 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.
I'm sorry but I was expressing my thoughts incorrectly. I intended to
say static analysis could not deal with reflection (not RTTI).
Reflection involves hard-coded cases (e.g., Class.forName("xxx.Clazz")
) and those cases that make use of configuration files (as Regis
suggested).
3 So i don't think two method are exclusive. These two mechanism can
both exist in our harmony-class-selector.
Actually I never meant they were exclusive. That's why I suggested a
hybrid approach.
I don't know why nobody responds to Stefan's post about ProGuard.
Maybe your clean-room policy prevented you from accessing its site
(though I don't think it is a violation :-) ). ProGuard is GPLed,
conflicting with Apache License v2, so we are not going to use it. But
Actually we can't use code of ProGuard, but can use its binary as a
tool, just like gcc we used to compile our vm.
the author also gives several JRE shrinker alternatives [1], three of
which are under Apache License (v2 or v1). Apache Ant ClassFileSet
attribute and Codehaus mojo minijar Eclipse plugin are notably
outstanding. I guess they all use the static approach. For Ant
Sound great, have you used it to generate a minimize JRE? Could it
correctly deal with dynamic loaded classes?
ClassFileSet, one specifies a set of root classes and Ant will find
all those classes that depend on these root classes. IIRC, minijar
also collects depended resource files in the Eclipse build path into
the final jar, which meets Jing's requirements.
So my point is we don't need to re-invent the wheel, especially when
we have multiple wheel candidates. I don't believe there is enough
work for a whole summer (as GSoC requires) if we base this project on
these existing projects. That said, if you think this idea still fits
into the GSoC scope, I'd be glad to submit my proposal.
Yes, I agree with you that we need to re-consider the value of this idea.
Regards.
[1] JRE shrinker alternatives.
http://proguard.sourceforge.net/alternatives.html.
--
Best Regards,
Regis.
