+1 As far as I know the Dacapo dependency is not such critical to spend a time for replacing one generator with another (instead of write own simple parser / lexer targeted for Generic Signature).
+1 for Alexey note about the existing Signature Parser code may be simpler rewritten then re-factored to work with different engine. AFAIK there are set of related JIRAs: HARMONY-1906<https://issues.apache.org/jira/browse/HARMONY-1906>, HARMONY-2130 <https://issues.apache.org/jira/browse/HARMONY-2130> ... Still it looks like nobody complains they are not fixed. So I would let them life a bit more. Also there is HARMONY-4987<https://issues.apache.org/jira/browse/HARMONY-4987>from Mark (pretty fresh one), still it can be fixed w/o removing antlr dependency. Thanks -- Vladimir Beliaev Intel Middleware Products Division 2007/11/6, Gregory Shimansky <[EMAIL PROTECTED]>: > > 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 >
