harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Lee <littlee1...@gmail.com>
Subject Re: [GSOC] Proposals from me
Date Sun, 29 Mar 2009 06:24:23 GMT
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

Yours sincerely,
Charles Lee

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