( 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? 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. > > -- Paulex Yang China Software Development Lab IBM
