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] Proposals from me
Date Mon, 30 Mar 2009 07:47:10 GMT
Hi Mike,

     Welcome and sorry for late reply. :)

2009/3/29 Mike <mikeandmore@gmail.com>

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

:) Nice to hear that.


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

Yep, that's a good idea. The projects welcome all ideas from students.


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

I will leave Oliver and Mark to discuss with you ;)


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

Yes if the programmers does have sense to make their projects localizable
(like Apache Harmony) that'll be good, the only work left for the tool is to
translate and fulfill the property file, however many of them does not. The
project will help them to do that.
Yep, that's an alternative implementation, however this requires the
re-compilation thus is not flexible, and may have problems on deployment(jar
replacement is costly!). If we use a property/resource Bundle mechanism, no
compilation nor source code modification is need if we want to add one or
more languages.


>
> well, this is the first idea that comes into my mind, it might be
> impossible to complete, but i'm expecting your feedbacks. ^_^
>

Your ideas are cool, Mike. Please enrich your proposals to the GSoC, it is
very key to the GSoC review and final decision on choosing the students.
Please tell me if you have more questoins.

Good Luck ;)


>
> Thanks all, yours
> Mike
>
>
>
>


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

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