parsing of java interfaces

parsing of java interfaces

[Christian Nautze]

Hi,

first i would like to say thanks to everbody who contributed to
SN. Really great work! 

Second i wanted to ask if it is a bug or feature :)
when using SN with java that the "implements" clause
isn't parsed like "extends". So under "Hierarchy"
i only see super and sub classes but no interfaces which
where implemented. I think "implements" should be treated
similarly as "extends" in java. Any comments?

Christian Nautze

PS: execuse my bad english

Re: parsing of java interfaces

[Mo DeJong]

On Wed, 26 Jul 2000, Christian Nautze wrote:

> Hi,
> 
> first i would like to say thanks to everbody who contributed to
> SN. Really great work! 

We are hoping that the best contributions have yet to be made.
Folks on the list are already talking about adding Python,
Perl, and improved Tcl support. We are really excited about
the possibilities that opens up for cross language tools.

> Second i wanted to ask if it is a bug or feature :)
> when using SN with java that the "implements" clause
> isn't parsed like "extends". So under "Hierarchy"
> i only see super and sub classes but no interfaces which
> where implemented. I think "implements" should be treated
> similarly as "extends" in java. Any comments?

Sounds like a bug. Java's interface types are kind of like
multiple inheritance in C++, so we should use that same
sort of metaphor. Why don't you take a shot at fixing
it? You will have to much around with the Java parser
to see if that is where the problem is. Post a patch
to the list when you get it working.

Mo DeJong
Red Hat Inc

Re: parsing of java interfaces

[Christian Nautze]

Mo DeJong wrote:
> 
> On Wed, 26 Jul 2000, Christian Nautze wrote:
> 
> > Hi,
> >
> > first i would like to say thanks to everbody who contributed to
> > SN. Really great work!
> 
> We are hoping that the best contributions have yet to be made.
> Folks on the list are already talking about adding Python,
> Perl, and improved Tcl support. We are really excited about
> the possibilities that opens up for cross language tools.
> 
> > Second i wanted to ask if it is a bug or feature :)
> > when using SN with java that the "implements" clause
> > isn't parsed like "extends". So under "Hierarchy"
> > i only see super and sub classes but no interfaces which
> > where implemented. I think "implements" should be treated
> > similarly as "extends" in java. Any comments?
> 
> Sounds like a bug. Java's interface types are kind of like
> multiple inheritance in C++, so we should use that same
> sort of metaphor. Why don't you take a shot at fixing
> it? You will have to much around with the Java parser
> to see if that is where the problem is. Post a patch
> to the list when you get it working.
> 

having looked at the java parser i only can see that the .c and .h
files where generated with tools from a commercial company in germany:
(script files *.ast *.puma etc)

http://www.cocolab.de/

There are also old versions of the compiler generator tools available
from
1992 (although i do not know if they work with the config files). 
Do you have contact to this company and can the tools be used 
(on there site is only a demo version available for win*)
without paying fees for GNU projects or would be a better solution to
rewrite
the java parser with GNU tools like flex and bison ? 
(i haven't done something like this before but it seems to be a lot of
work :)

kind regards

Christian Nautze

Re: parsing of java interfaces

[Syd Polk]

>having looked at the java parser i only can see that the .c and .h
>files where generated with tools from a commercial company in germany:
>(script files *.ast *.puma etc)
>
> http://www.cocolab.de/
>
>There are also old versions of the compiler generator tools available
>from
>1992 (although i do not know if they work with the config files).
>Do you have contact to this company and can the tools be used
>(on there site is only a demo version available for win*)
>without paying fees for GNU projects or would be a better solution to
>rewrite
>the java parser with GNU tools like flex and bison ?
>(i haven't done something like this before but it seems to be a lot of
>work :)

Cygnus was unwilling to pay for this tool. It is not open source.

There are two alternatives:

- We can use gcj. gcj has already been modified to generate SN information 
once for the Code Fusion effort. While this has not been maintained, it is 
free, and the infrastructure is their for it.

- We can write a new parser from scratch using flex and bison.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: parsing of java interfaces

[Alexandre Petit-Bianco]

Ben Elliston writes:

> It would be a better solution to rewrite the Java parser.  Since
> it's LALR(1), it should be relatively straightforward.  I understand
> there was some work underway to reuse the parser from the GNU Java
> compiler, gcj.  Alex?

Yes, and this went into the Code Fusion boxed product. The xref stuff
is still sanitized out, but with the release of SN, it should make it
to egcs, I think.

Of course, I would have to verify that it works and then I would let
people hack on it since I don't really have the time to maintain it.

./A

Re: parsing of java interfaces

[Gilles J. Seguin]

Syd Polk wrote:
> 
> Cygnus was unwilling to pay for this tool. It is not open source.
> 
> There are two alternatives:
> 
> - We can use gcj. gcj has already been modified to generate SN information
> once for the Code Fusion effort. While this has not been maintained, it is
> free, and the infrastructure is their for it.

This is an interesting comment.  The name "Source"-Navigator was
nearly saying what we try to do.

Have we some kind of interest in using other methods, like
using the information provided by the compiler stabs information.
Basically using the information provided to or used by the
debugger(gdb).

> - We can write a new parser from scratch using flex and bison.

What is the position or the openness for a tool like antlr
< http://www.antlr.org > for the java parser,  The C parser
can used the PCCTS version.

Re: parsing of java interfaces

[Florent Pillet]

Why don't you simply derive the Java parser from the existing C++ parser
?
These two languages are quite close and you'd have a good base to start
with. Plus, you don't need to have "compiler-quality" parsing since the
only
thing the parser needs to do is to provide accurate symbols.

I still think that using the C++ parser is the less expansive solution
in
terms of coding time.

"Gilles J. Seguin" wrote:
> 
> Syd Polk wrote:
> >
> > Cygnus was unwilling to pay for this tool. It is not open source.
> >
> > There are two alternatives:
> >
> > - We can use gcj. gcj has already been modified to generate SN information
> > once for the Code Fusion effort. While this has not been maintained, it is
> > free, and the infrastructure is their for it.
> 
> This is an interesting comment.  The name "Source"-Navigator was
> nearly saying what we try to do.
> 
> Have we some kind of interest in using other methods, like
> using the information provided by the compiler stabs information.
> Basically using the information provided to or used by the
> debugger(gdb).
> 
> > - We can write a new parser from scratch using flex and bison.
> 
> What is the position or the openness for a tool like antlr
> < http://www.antlr.org > for the java parser,  The C parser
> can used the PCCTS version.

-- 
Florent Pillet, Software Architect. e-mail: fpillet@opteway.com
opt[e]way S.A., 2881 route des cretes, BP 308
06906 Sophia Antipolis Cedex, France
Phone: +33 4 92 95 26 13 - Fax: +33 4 92 95 26 03
http://www.opteway.com/