harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@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 07:08:49 GMT
2007/11/6, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
>
> 2007/11/5, Yang Paulex <paulex.yang@gmail.com>:
> > ( 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.
>
> Sounds reasonable. Minor notice, it's a bit unclear which grammar do
> you mean - the one documented in JVMS? I wonder if antlr-expressed
> "grammar", which currently resides in our SVN, is suitable for any
> reuse ;)


no idea...I'm newbie to JavaCC myself, will have a try soon...

BTW, I recall there was a suggestion to clean API even further and
> make it VM-agnostic, so as to be able to share the parser between VMs.
> Would be nice to keep this in mind when reimplementing the parser,
> what do you think?


Sure, that's also my target,  forgot to mention yesterday.

--
> Alexey
>
> >
> > Comments? other ideas?
> >
> > 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.
> > >
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
>



-- 
Paulex Yang
China Software Development Lab
IBM

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