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
