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