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 <[email protected]> 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 [email protected] 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 > > > > > > > > > >
