harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: [GSoC] Questions about the Harmony class selector idea
Date Mon, 30 Mar 2009 08:02:37 GMT
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 <mikeandmore@gmail.com>

> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message