harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "QIU, Yin" <allenc...@gmail.com>
Subject Re: [GSoC] Questions about the Harmony class selector idea
Date Tue, 31 Mar 2009 05:08:58 GMT

On Mon, Mar 30, 2009 at 1:06 PM, Mike <mikeandmore@gmail.com> 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

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


[1] JRE shrinker alternatives.

Yin Qiu
Nanjing University, China

View raw message