Java hiccups

Java hiccups

[h j]

Hi,
I am trying this program for a large java project. It is the most stable, fast
and useful product, even compared to some commercial ones.

But it seems that java is not fully supported as yet. Firstly, there is an
important bug: The program does not recognize "java.awt.Component" as
"Component" from the "java.awt" package. It seems like the package concept is
not there at all.

Also, the program has an irritating habit of distinguishing a method
definition and declaration. In java there is no such distinction, but source
navigator shows two entries for each method!

What is the status for java support ? Is there a chance of these issues being
fixed in the near future ?

thanks,
walker

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

Re: Java hiccups

[Mo DeJong]

On 6 Jan 2001, h j wrote:

> Hi,
> I am trying this program for a large java project. It is the most stable, fast
> and useful product, even compared to some commercial ones.
> 
> But it seems that java is not fully supported as yet. Firstly, there is an
> important bug: The program does not recognize "java.awt.Component" as
> "Component" from the "java.awt" package. It seems like the package concept is
> not there at all.

You are correct. We need to fix the Java parser so that it
understands Java packages.

> Also, the program has an irritating habit of distinguishing a method
> definition and declaration. In java there is no such distinction, but source
> navigator shows two entries for each method!

This is a known problem. This sort of thing could also come up in C++
in the case of an inlined method. The question is, what is the right
way to fix this? Should only a single type symbol be written, for
example we could leave off the decl symbol. The problem is, we then
need to do something when the user ran "Goto decl".

> What is the status for java support ? Is there a chance of these
> issues being fixed in the near future ?

We are talking about the "right" way to fix it but it is going
to require some work. The GCJ based parser would work for
Java code that would compile, but fuzzy Java parsing is a much
harder problem.

Mo DeJong
Red Hat Inc

Re: Java hiccups

[Ben Elliston]

mdejong wrote:

   We are talking about the "right" way to fix it but it is going to
   require some work. The GCJ based parser would work for Java code that
   would compile, but fuzzy Java parsing is a much harder problem.

Having had a couple of years to ponder this issue, I'm coming to the
conlusion that perhaps the correct parsing of correct programs should come
before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
should take a back seat?

Ben

Re: Java hiccups

[Mo DeJong]

On Tue, 16 Jan 2001, Ben Elliston wrote:

> mdejong wrote:
> 
>    We are talking about the "right" way to fix it but it is going to
>    require some work. The GCJ based parser would work for Java code that
>    would compile, but fuzzy Java parsing is a much harder problem.
> 
> Having had a couple of years to ponder this issue, I'm coming to the
> conlusion that perhaps the correct parsing of correct programs should come
> before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> should take a back seat?
> 
> Ben

The option we were talking about was using a "normal" parser
first and then if that failed we would fall back to a fuzzy
parser for that one file. It would also be really neat if you
could "go fuzzy" for a single function or class (that
might be a lot harder than it sounds). The devil is
in the details of course.

Mo DeJong
Red Hat Inc

Crazy Ideas Was: Re: Java hiccups

[Timothy M. Shead]

Ben Elliston wrote:

> mdejong wrote:
> 
>    We are talking about the "right" way to fix it but it is going to
>    require some work. The GCJ based parser would work for Java code that
>    would compile, but fuzzy Java parsing is a much harder problem.
> 
> Having had a couple of years to ponder this issue, I'm coming to the
> conlusion that perhaps the correct parsing of correct programs should come
> before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> should take a back seat?
> 
> Ben

I don't know if y'all have any long-term plans for the future of SN, but 
if you do, your remark about correctly parsing correct programs reminded 
me of one of an interesting idea I ran across, one which could eliminate 
these types of problems: database source management.  The idea being 
that, instead of "storing" your program source in files, you keep it 
organized in a central database.  So you'd have tables for classes, 
methods, functions, etc. just like SN's tables, but with the bodies of 
functions/methods/etc in the database as well.  There'd never be a 
"foo.java" or "foo.cpp" - simply a set of "foo" entries in the database. 
  When it's time to compile, the database dumps the source into 
temporary file form to feed the compiler.  Advantages would include:

* Minimize parsing (at least for new projects) - since the code is going 
into the database as it's written (presumeably through some type of GUI) 
the parsing can be kept to a bare minimum (with much, much less to go 
wrong).
* More complex searches / cross references.
* Faster compile times - since the database can easily cross-reference 
function/method calls, it can avoid compiling the ones that are never used.
* Faster compiled executables - the database could perform static 
analysis of call patterns, and organize compiled code to minimize cache 
hits, something that's impractical when working with files.
* Better source management - tools like CVS track changes to text files 
at a generic level.  The database could track changes at a 
per-function/method level, and provide context for a "group" of changes 
that go together (something CVS doesn't do).  It could advise you when a 
change is going to affect other people, and advise them when you do.
* Integrated documentation - it would be possible for the database to 
help keep documentation in sync with the code - if you change an 
argument to a function/method, it can (optionally, of course!) nag you 
to update the corresponding comments.

Way out there, I know - the idea of abandoning files is scary, but worth 
looking at :)

Regards,
Timothy M. Shead

Re: Crazy Ideas Was: Re: Java hiccups

[Ian Roxborough]

Mmmmmmmm, yes, something I've heard about a few times.
The biggest benefit would be  NO MORE CODING STANDARDS!
Yippee, no more whining about this coding standard verse
that one.  You just set any coding standard you want in
your editor and nobody will ever care.

And many great advantages for doing code refactoring as well.

A more realistic way would be to store source code in
XML format, which then could be read into either a xref and symbol
database or into a compiler (or into an editor of course).
But when you try to deal with file based languages, Java is bad
for this (path = package name), as is C due to the use of static, you
start to have some problems.

Ian.

"Timothy M. Shead" wrote:
> 
> Ben Elliston wrote:
> 
> > mdejong wrote:
> >
> >    We are talking about the "right" way to fix it but it is going to
> >    require some work. The GCJ based parser would work for Java code that
> >    would compile, but fuzzy Java parsing is a much harder problem.
> >
> > Having had a couple of years to ponder this issue, I'm coming to the
> > conlusion that perhaps the correct parsing of correct programs should come
> > before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> > should take a back seat?
> >
> > Ben
> 
> I don't know if y'all have any long-term plans for the future of SN, but
> if you do, your remark about correctly parsing correct programs reminded
> me of one of an interesting idea I ran across, one which could eliminate
> these types of problems: database source management.  The idea being
> that, instead of "storing" your program source in files, you keep it
> organized in a central database.  So you'd have tables for classes,
> methods, functions, etc. just like SN's tables, but with the bodies of
> functions/methods/etc in the database as well.  There'd never be a
> "foo.java" or "foo.cpp" - simply a set of "foo" entries in the database.
>   When it's time to compile, the database dumps the source into
> temporary file form to feed the compiler.  Advantages would include:
> 
> * Minimize parsing (at least for new projects) - since the code is going
> into the database as it's written (presumeably through some type of GUI)
> the parsing can be kept to a bare minimum (with much, much less to go
> wrong).
> * More complex searches / cross references.
> * Faster compile times - since the database can easily cross-reference
> function/method calls, it can avoid compiling the ones that are never used.
> * Faster compiled executables - the database could perform static
> analysis of call patterns, and organize compiled code to minimize cache
> hits, something that's impractical when working with files.
> * Better source management - tools like CVS track changes to text files
> at a generic level.  The database could track changes at a
> per-function/method level, and provide context for a "group" of changes
> that go together (something CVS doesn't do).  It could advise you when a
> change is going to affect other people, and advise them when you do.
> * Integrated documentation - it would be possible for the database to
> help keep documentation in sync with the code - if you change an
> argument to a function/method, it can (optionally, of course!) nag you
> to update the corresponding comments.
> 
> Way out there, I know - the idea of abandoning files is scary, but worth
> looking at :)
> 
> Regards,
> Timothy M. Shead

Re: Crazy Ideas Was: Re: Java hiccups

[Eray Ozkural (exa)]

dave.banham@tde.alstom.com wrote:
> 
> People on this list have equally suggested that SN should be able to produce
> (reverse-engineer) UML diagrams of the source code. A lot of CASE tools already
> do this.

UML... Three magic letters. It makes you deal with code without understanding
it right?

Sorry, just couldn't resist the temptation. :)

If you have a good visualization of code, you probably don't need any
braindead PDL dumps. Except for showing them to the management. Anyway, I
showed non-UML "pretty pictures" of code to our very senior software
engineer and he was equally pleased.

> And the next logical step would be to allow the user to input the
> diagrams and for the code to be generated.

Does this require less cognitive load than writing code?

:)))))


Regards,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

RE: Crazy Ideas Was: Re: Java hiccups

[Kirby, Dave]

Not such a crazy idea.  Take a look at IBM's VisualAge for Java, which does
exactly that (i.e. keep the code in a repository instead of text files).  It
is based on VisualAge for Smalltalk, and of course Smalltalk has done things
this way from the beginning. 

I haven't used VA myself, since I am developing in C++, but I know lots of
Java developers swear by it, especially in the XP community.  You can even
get a refactoring browser for it.

For a discussion on its merits & some links, see
http://www.c2.com/cgi/wiki?VisualAge

Regards,

	Dave Kirby



> -----Original Message-----
> From: Timothy M. Shead [ mailto:tshead@k-3d.com ]
> Sent: 16 January 2001 03:16
> Cc: sourcenav@sourceware.cygnus.com
> Subject: Crazy Ideas Was: Re: Java hiccups
> 
> 
> Ben Elliston wrote:
> 
> > mdejong wrote:
> > 
> >    We are talking about the "right" way to fix it but it is going to
> >    require some work. The GCJ based parser would work for 
> Java code that
> >    would compile, but fuzzy Java parsing is a much harder problem.
> > 
> > Having had a couple of years to ponder this issue, I'm coming to the
> > conlusion that perhaps the correct parsing of correct 
> programs should come
> > before the best-effort parsing of incorrect programs.  
> Perhaps fuzzy parsing
> > should take a back seat?
> > 
> > Ben
> 
> I don't know if y'all have any long-term plans for the future 
> of SN, but 
> if you do, your remark about correctly parsing correct 
> programs reminded 
> me of one of an interesting idea I ran across, one which 
> could eliminate 
> these types of problems: database source management.  The idea being 
> that, instead of "storing" your program source in files, you keep it 
> organized in a central database.  So you'd have tables for classes, 
> methods, functions, etc. just like SN's tables, but with the 
> bodies of 
> functions/methods/etc in the database as well.  There'd never be a 
> "foo.java" or "foo.cpp" - simply a set of "foo" entries in 
> the database. 
>   When it's time to compile, the database dumps the source into 
> temporary file form to feed the compiler.  Advantages would include:
> 
> * Minimize parsing (at least for new projects) - since the 
> code is going 
> into the database as it's written (presumeably through some 
> type of GUI) 
> the parsing can be kept to a bare minimum (with much, much less to go 
> wrong).
> * More complex searches / cross references.
> * Faster compile times - since the database can easily 
> cross-reference 
> function/method calls, it can avoid compiling the ones that 
> are never used.
> * Faster compiled executables - the database could perform static 
> analysis of call patterns, and organize compiled code to 
> minimize cache 
> hits, something that's impractical when working with files.
> * Better source management - tools like CVS track changes to 
> text files 
> at a generic level.  The database could track changes at a 
> per-function/method level, and provide context for a "group" 
> of changes 
> that go together (something CVS doesn't do).  It could advise 
> you when a 
> change is going to affect other people, and advise them when you do.
> * Integrated documentation - it would be possible for the database to 
> help keep documentation in sync with the code - if you change an 
> argument to a function/method, it can (optionally, of 
> course!) nag you 
> to update the corresponding comments.
> 
> Way out there, I know - the idea of abandoning files is 
> scary, but worth 
> looking at :)
> 
> Regards,
> Timothy M. Shead
> 
> 

Re: Crazy Ideas Was: Re: Java hiccups

[dave.banham]

The fundamental flaw with Tim's suggestion is that it forgets to incorporate the
design process - there is no mechanism for placing the code in the database in
an organised manner. Modern software engineering tools (i.e. CASE tools) already
do this. At one end of the scale there are CASE tools that act as a sort of IDE
by allowing function bodies, etc., to be populated from within the design model,
e.g. Rational Rose from Rational (www.rational.com). At the other end of the
scale the CASE tool generates all the source code from a very detailed model,
e.g. Bridgepoint from Project Technology (www.projtech.com).

People on this list have equally suggested that SN should be able to produce
(reverse-engineer) UML diagrams of the source code. A lot of CASE tools already
do this. And the next logical step would be to allow the user to input the
diagrams and for the code to be generated.

It is probably true to say that if we were all using the latest CASE tools we
wouldn't be using SN since there wouldn't be a need for it. However, *good* CASE
tools tend to cost a lot of money and a fair amount of skill to use effectively.
So I guess that most of us on this list are here because SN is free open source,
is relatively easy to use and, most importantly, doesn't require management
approval to use it.

SN is also a good tool for understanding a diverse code base and this is
probably where it should remain. So rather than expand SN vertically, process
wise, it would be better to expand it breadth wise by providing wide ranging
language support of a high quality.

Regards
Dave Banham




To:
cc:   sourcenav@sourceware.cygnus.com
Subject:  Crazy Ideas Was: Re: Java hiccups



Ben Elliston wrote:

> mdejong wrote:
>
>    We are talking about the "right" way to fix it but it is going to
>    require some work. The GCJ based parser would work for Java code that
>    would compile, but fuzzy Java parsing is a much harder problem.
>
> Having had a couple of years to ponder this issue, I'm coming to the
> conlusion that perhaps the correct parsing of correct programs should come
> before the best-effort parsing of incorrect programs.  Perhaps fuzzy parsing
> should take a back seat?
>
> Ben

I don't know if y'all have any long-term plans for the future of SN, but
if you do, your remark about correctly parsing correct programs reminded
me of one of an interesting idea I ran across, one which could eliminate
these types of problems: database source management.  The idea being
that, instead of "storing" your program source in files, you keep it
organized in a central database.  So you'd have tables for classes,
methods, functions, etc. just like SN's tables, but with the bodies of
functions/methods/etc in the database as well.  There'd never be a
"foo.java" or "foo.cpp" - simply a set of "foo" entries in the database.
  When it's time to compile, the database dumps the source into
temporary file form to feed the compiler.  Advantages would include:

* Minimize parsing (at least for new projects) - since the code is going
into the database as it's written (presumeably through some type of GUI)
the parsing can be kept to a bare minimum (with much, much less to go
wrong).
* More complex searches / cross references.
* Faster compile times - since the database can easily cross-reference
function/method calls, it can avoid compiling the ones that are never used.
* Faster compiled executables - the database could perform static
analysis of call patterns, and organize compiled code to minimize cache
hits, something that's impractical when working with files.
* Better source management - tools like CVS track changes to text files
at a generic level.  The database could track changes at a
per-function/method level, and provide context for a "group" of changes
that go together (something CVS doesn't do).  It could advise you when a
change is going to affect other people, and advise them when you do.
* Integrated documentation - it would be possible for the database to
help keep documentation in sync with the code - if you change an
argument to a function/method, it can (optionally, of course!) nag you
to update the corresponding comments.

Way out there, I know - the idea of abandoning files is scary, but worth
looking at :)

Regards,
Timothy M. Shead