Yang Paulex wrote:
( I am looking at the jiras holding in my hand, and blush for myself that
there are several opening for more than 1 year! So I think it's time to
look at them now.)
The idea of HARMONY-2052 is to refactor the implementation of generic
signature reflection, so that:
1. We got a clearer API, and
2. Remove the dependency to ANTLR runtime jar, which prevents Dacapo ANTLR
benchmark running on Harmony, and potentially may prevent applications based
on ANTLR.
I did parts for first purpose, and thanks Alexey Varlamov and Vladimir
Beliaev for polishing and committing that, now I'm thinking for the second
purpose. Seems no one in nowadays has interest to write a parser manually
without strong reason (I'm talking about myself, of course, do correct me if
anyone does have interest ;-) ), so that I'm wondering if anyone objects we
recreate the parser for same grammar via JavaCC to remove runtime
dependency.
Comments? other ideas?
I didn't have experience with JavaCC, so I don't know how the generated
code works. If generated code depends on some javacc API, wouldn't it
create a similar dependency as code that depends on antlr.jar?
2007/6/9, Alexey Varlamov (JIRA) <[EMAIL PROTECTED]>:
[
https://issues.apache.org/jira/browse/HARMONY-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503077]
Alexey Varlamov commented on HARMONY-2052:
------------------------------------------
Applied at revision: 545750, thanks!
[drlvm][kernel] Improve/re-implement a parser of generic signatures
-------------------------------------------------------------------
Key: HARMONY-2052
URL: https://issues.apache.org/jira/browse/HARMONY-2052
Project: Harmony
Issue Type: Task
Components: Classlib, DRLVM
Reporter: Alexey Varlamov
Assignee: Paulex Yang
Priority: Minor
Attachments: antlr-2.7.5.jar, HARMONY-2052-1.diff,
HARMONY-2052-1.diff, HARMONY-2052-1.diff
Improve/re-implement a parser of generic signatures in DRLVM kernel
classes [1], 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 [2];
unfortunately this is not the case with the impl in question. OTOH
minimizing number of dependencies for VM is always good.
[1]
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**
[2]
http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdfPara
4.4.4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--
Gregory
