Alexey, Do you think you can post these on Wiki? We actually have several pages there that can help arrange and store such development items: Starting point, choose your subpage http://wiki.apache.org/harmony/TODO_List_for_DRLVM Sample http://wiki.apache.org/harmony/JIT_Development_Tasks Wiki seems easier to find and use than an email thread on the list. What do you say? Do you need my help with this?
Thank you, Nadya Morozova -----Original Message----- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 9:24 AM To: harmony-dev Subject: [drlvm] more self-dependent VM tasks, newbies welcome Below is a list of isolated development tasks which do not require advanced knowledge of VM and could be a nice start for newbies to get acquainted with the code. All items are targeted for better code sharing. 1) Eliminate duplicate implementation of j.l.Runtime.Process in kernel classes of DRLVM [1]. The classlib provides neat portlib-based reference implementation [2], which should be reused. These 2 impls are roughly identical, so one needs to made more scrupulous comparison and squeeze some features/fixes of [1] which may be missing in [2], then employ [2] in j.l.Runtime of DRLVM and drop [1]. 2) Improve/re-implement a parser of generic signatures in DRLVM kernel classes [3], and move this functionality to classlib (luni ?), so other VMs could reuse it for 1.5 support. The current impl is somewhat messy and half-baked, one need to invent more shaped and modular API to the parser. One more possible issue is parser's dependency on antlr, which may be considered overkill for this duty. I think antlr has its pros, like more illustrative code with clear correlation to formal grammar [4]; unfortunately this is not the case with the impl in question. OTOH minimizing number of dependencies for VM is always good. 3) Classlib's j.u.TimeZone expects "user.timezone" property value initialized during VM startup (BTW I did not find explicit statement in VMI docs for that, only indirect reference in kernel stub for j.l.System). I believe this action should be done by hyluni natives during JNI_OnLoad, no reason to burden VM with it. Therefore I suggest to move "port_user_timezone()" function [5] from DRLVM to classlib (luni/port), and fix DRLVM & hyluni accordingly. [1] working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java + working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp [2] working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\inte rnal\process\* + working_classlib\modules\luni\src\main\native\luni\shared\process.c [3] working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\ reflect\** [4] http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5. pdf Para 4.4.4 [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c Comments? Should I put this somewhere on the Wiki?
