No problem with them being both on the Wiki and the JIRA, I think.
On 02 Nov 2006 17:57:29 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote: > Alexey Varlamov wrote: > > 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > >> Put them in as JIRAs > > Done: HARMONY-2051, 2052, 2053. > > Thanks - that just makes it easy for people to grab them and get going... maybe, put the list of JIRAs on wiki? > > > >> Alexey Varlamov wrote: > >> > 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\internal\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? > >> > > >> > > > -- Egor Pasko, Intel Managed Runtime Division
