harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Beliaev" <vladimir.k.beli...@gmail.com>
Subject Re: [DRLVM][kernel] Recreate the parser in JavaCC? (Re: [jira] Commented: (HARMONY-2052) [drlvm][kernel] Improve/re-implement a parser of generic signatures)
Date Tue, 06 Nov 2007 10:30:03 GMT
+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 <gshimansky@apache.org>:
>
> 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) <jira@apache.org>:
> >>
> >>     [
> >>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message