* Java hiccups @ 2001-01-06 7:57 h j 2001-01-15 16:32 ` Mo DeJong 0 siblings, 1 reply; 6+ messages in thread From: h j @ 2001-01-06 7:57 UTC (permalink / raw) To: sourcenav 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Java hiccups 2001-01-06 7:57 Java hiccups h j @ 2001-01-15 16:32 ` Mo DeJong 2001-01-15 18:16 ` Ben Elliston 0 siblings, 1 reply; 6+ messages in thread From: Mo DeJong @ 2001-01-15 16:32 UTC (permalink / raw) To: sourcenav 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Java hiccups 2001-01-15 16:32 ` Mo DeJong @ 2001-01-15 18:16 ` Ben Elliston 2001-01-15 18:20 ` Mo DeJong 2001-01-15 19:16 ` Crazy Ideas Was: " Timothy M. Shead 0 siblings, 2 replies; 6+ messages in thread From: Ben Elliston @ 2001-01-15 18:16 UTC (permalink / raw) To: Mo DeJong; +Cc: sourcenav 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Java hiccups 2001-01-15 18:16 ` Ben Elliston @ 2001-01-15 18:20 ` Mo DeJong 2001-01-15 19:16 ` Crazy Ideas Was: " Timothy M. Shead 1 sibling, 0 replies; 6+ messages in thread From: Mo DeJong @ 2001-01-15 18:20 UTC (permalink / raw) To: sourcenav 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Crazy Ideas Was: Re: Java hiccups 2001-01-15 18:16 ` Ben Elliston 2001-01-15 18:20 ` Mo DeJong @ 2001-01-15 19:16 ` Timothy M. Shead 2001-01-15 19:36 ` Ian Roxborough 1 sibling, 1 reply; 6+ messages in thread From: Timothy M. Shead @ 2001-01-15 19:16 UTC (permalink / raw) To: egcs; +Cc: sourcenav 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Crazy Ideas Was: Re: Java hiccups 2001-01-15 19:16 ` Crazy Ideas Was: " Timothy M. Shead @ 2001-01-15 19:36 ` Ian Roxborough 0 siblings, 0 replies; 6+ messages in thread From: Ian Roxborough @ 2001-01-15 19:36 UTC (permalink / raw) To: Timothy M. Shead; +Cc: sourcenav 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-01-15 19:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-01-06 7:57 Java hiccups h j 2001-01-15 16:32 ` Mo DeJong 2001-01-15 18:16 ` Ben Elliston 2001-01-15 18:20 ` Mo DeJong 2001-01-15 19:16 ` Crazy Ideas Was: " Timothy M. Shead 2001-01-15 19:36 ` Ian Roxborough
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).