I agree. And Harmony-class-selector is optional. When they release a milestone, harmony-class-selector is recommended. Any way, the main usage of the harmony-class-selector is for a small runtime environment.
On Sun, Mar 29, 2009 at 2:30 PM, Mike <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > -- Yours sincerely, Charles Lee
