harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike <mikeandm...@gmail.com>
Subject Re: [GSOC] Proposals from me
Date Sun, 29 Mar 2009 06:30:34 GMT
hi Charles.
Thanks for your reply.

well, do unit testing is good, but i don't think forcing other
developers are nice enough ^_^. 

what if developer just want to be slick and quick without caring about
code robust? i guess we have to leave them a choice.

Yours
Mike

在 2009-03-29日的 14:24 +0800,Charles Lee写道:
> Hi Mike,
> 
> Thanks for your consideration. Here is a quick reply from my mind.
> 
> On Sun, Mar 29, 2009 at 1:56 PM, Mike <mikeandmore@gmail.com> wrote:
> 
> > Hi all,
> >
> > i'm a undergraduate student from ZheJiang University and had just
> > submitted my proposal some of the harmony GSOC's project. I've been
> > focusing on harmony from last year when firepure@gmail.com gave a speech
> > on Apache Harmony at ZheJiang University ZJG campus.
> >
> > i'm familiar with java's mechanism, how a java program runs. Know the
> > principle of java virtual machine. i'm also a active opensource
> > programmer, and currently maintain a java project called MNADemo (at
> > http://code.google.com/p/mnademo/ )
> >
> > I have submitted 3 projects on the GSOC's website.
> >
> >      * harmony-class-selector
> >        In the Harmony's wiki page it saids.
> >
> >                For many java desktop application, sometimes they will
> >                offer a JRE in the installation package, which may be
> >                big. And the project may also customize the jre to be
> >                smallest for the application, which cost much effort. We
> >                are looking for an automatic tool to find out all
> >                classes for the application and build up a smallest JRE
> >                for the customer. For many our developers, we have
> >                EasyMock to cheat coverage tools, such as Emma. The
> >                smallest jre can help us to find these cheats, make code
> >                more robust.
> >
> >
> >        This is a rather strange idea. Because, it will make application
> >        code more robust, but will not make harmony-class-selector
> >        robust. Which means, harmony-class-selector will force user to
> >        do nearly 100% testing. This is not always good. So on my own
> >
> 
> harmony-class-selector will not force user to do nearly 100% testing, but
> force developer to do the testing. Actually now every project will use unit
> testing and code coverage to ensure their code robust, but as human beings,
> we find lots of trick ways to cheat the result. Using harmony selector,
> developer will be forced to test every code he write. Is it good or not?
> 
> 
> >        perspective, we need to provide 2 strategies.
> >
> >             1. collect the class dependency according to test generated
> >                class file.
> >             2. collect the class dependency according to application
> >                jar.
> >
> >        One is for user to recheck the their code coverage, another is
> >        for productivity use. But if we implement the second strategy,
> >        the information collection algorithm will be base on .class file
> >        parsing. There's no way for hacking a classloader when the jar
> 
> 
> if the unit test do a really full tests on the application code, we can know
> every class it use. So again, harmony-class-selector force developer to do
> real full tests.
> 
> 
> >
> >        file is not fully running. So there should be an alternative.
> >        ^_^
> >
> >      * Harmony misc tools (harmony-tools-1 on the wiki page)
> >
> >        Tools that be involved are jar, javaws, jconsole.
> >
> >        For jar, it's not that hard. jar spec can be found at
> >        http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
> >
> >        For javaws, it seems that it involves the JNLP stuff, and it
> >        shouldn't be too complicated. ^_^
> >
> >        But for jconsole, sun's jconsole is just too rich featured T_T.
> >        I guess we can separate the jconsole into many other small
> >        tools, such as heap_mon, thread_mon, vm_info. And also, we may
> >        cast away the GUI interface, since harmony's swing/awt
> >        implementation is not mature. CLI interface for a monitor is
> >        convenient enough for a administrator.
> >
> >      * i18n tool harmony/others
> >        The wiki page gave us a clear guideline of how to implement it
> >        clear enough ^_^.
> >        ( http://wiki.apache.org/harmony/Harmony_i18n_tool )
> >
> >        So i only got some ideas on implementation:
> >        1 i think the translation notation should be written in the
> >        code. Programmers should know that their strings in the code
> >        will be translated. Java5's annotation support can help us with
> >        this. Using a annotation within a class is better than a xml
> >        file to configure the extractor.
> >        2 injector. how about do a hack on the classpath? when analyzer
> >        detect that the class will be translate, use javac to compile
> >        different a copy with different languages. then pack to
> >        different jar files. When project code is runnning, the injector
> >        will place the localized jar prior in the classpath.
> >
> > well, this is the first idea that comes into my mind, it might be
> > impossible to complete, but i'm expecting your feedbacks. ^_^
> >
> > Thanks all, yours
> > Mike
> >
> >
> >
> >
> 
> 


Mime
View raw message