RE: PROPOSAL: New Java Build Feature (LONG)
In practice, I've found the depend task in Ant to be very reliable, and compensates for defficiencies in using Javac's (or Jike's) dependency analysis within Ant. In particular, if an interface changes in a way that breaks a dependent class, but that dependent class is not itself out of date, the error is undetectable by the compiler, but can be discovered by the depend task. The cases where the depend task does not accurately compute dependencies are these (from the Ant docs): 1. If the Java compiler optimizes away a class relationship, there can be a source dependency without a class dependency. -- The class dependency is more relevant anyway, so in general this is not a problem. 2. Non public classes cause two problems. Firstly depend cannot relate the class file to a source file. In the future this may be addressed using the source file attribute in the classfile. Secondly, neither depend nor the compiler tasks can detect when a non public class is missing. Inner classes are handled by the depend task. -- As long as inner classes are handled, I'm happy. The failure to detect non-public classes is a problem, but in my experience not a critical one (our project has no non-public classes). Cheers, David -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 8:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PROPOSAL: New Java Build Feature (LONG) At 07:29 PM 3/21/2001 -0800, you wrote: I stand corrected - the depend task works exactly as Mark says it does. Mark, thanks for bringing this to my attention. Nevertheless, the Ant depend task admittedly does not detect all dependencies. I therefore question its value. I would not want to rely on a build program that could result in an invalid build or have to continually evaluate changes that I make to the source to determine their impact on the validity of the build program. I guess you could say that the Ant depend task, though not perfect, does a better job of dependency analysis than javac and thus could be used like javac, i.e, compile and if the app works, fine. If not, recompile everything to make sure that the problem is not due to dependency analysis failures. I find that javac dependency analysis is good enough for most compiles and I only occasionally have to rebuild the entire application. So I'm not sure there would be much motivation for me to go to the trouble of setting up an Ant build based on the Ant depend task. - Paul
dependancy building with JDE (again)
As paul has said, it would be nice to have a dependancy build built into the JDE. Such a feature should not be reliant on any one compiler or any external system (except perhaps some elisp code). Sandip posted a very usefull list of pitfalls for dependancy rebuilding and I've been thinking about it since. Sandip's point 6 says: It is not always possible to predict the name of the source file based on the name of .class file in every legal case. If one is following a model whereby the .class files are in a different place than the .java file on has to provide the location of .java files in addition to CLASSPATH. Also just based on the name of the .java files one cannot predict the names and locations of all the output .class files that may result from the compilation. It requires parsing of the .java file. That is why automated make file generation fails for Java. i.e. there is no equivalent of .c.o rule for java. This has been the biggest problem for me trying to implement dependancy tracking, I've tired various things and they all fall down with this. It struck me that there is a possible solution to this. When a class file is compiled with the -g switch the source file name that is was compiled from is embedded in the class (this is how the debugger knows which class file to load). It wouldn't be hard to adpat the debugger's strategy for finding a source file based on the class file to a rebuilder. This is what a rebuilder based on this would do: - create a list 'classeslist' of all the .class files in the destination directory - create an assoc-list 'sourceslist' of all the .source files in the source path - for each .class file in 'classeslist' - obtain the source file from the class file - get the source file name from the 'sourceslist' - compare the .class last modified time with the .java last modified time - add the .java to a list 'recompilelist' if the .class time is eariler - for each source file in the 'sourceslist' that isn't in the 'classeslist' - add the source file to the 'recompilelist' - compile all the files in 'recompilelist' with an @ list argument to the compiler I think this would work. It could be done in elisp (with a java tool [use the bsh?] to help extract the source file name for class files). There are two potential problems: o Performance the number of file accesses would be large - each .class file would have to be opened and examined to establish the name of the corresponding source file. Some sort of caching system could be used to alleviate that I suppose. o Applicability this only works when the .class files have been compiled with the -g switch. Without it there will be no source file attribute in the class and no way of relating the class to the source file. Maybe this isn't such a big deal because developers don't tend to compile without -g. One can always recompile everything with -g after a release has been made, or compile releases into a seperate directory. Does anyone see any merit in this? It's different enough from my current dependancy system for me to want to see an audience before I build it. If enough people are interested though, and think it might work, I'll develop it and see how it goes. Nic Ferrier
RE: dependency building with JDE (again)
Nic,
I would like to add to some of what you have said
Nic Ferrier wrote:
snip 8-snip
It struck me that there is a possible solution to this. When a class
file is compiled with the -g switch the source file name that is was
compiled from is embedded in the class (this is how the debugger knows
which class file to load).
The name of the source file (without the directory part) is always stored
in the .class file whether or not you compile the source .java file
with -g option. The name of the java source file is stored
as a class file attribute. It is not required by the JVM Spec but is
true for most compilers (i.e. to store the source file name even if -g
was not specified).
(Reference -
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#79
868)
In fact you have to use -g:none to prevent the javac from storing that
attribute...
Here is the output from my JDK1.3 javac -
"
Usage: javac options source files
where possible options include:
-gGenerate all debugging info
-g:none Generate no debugging info
-g:{lines,vars,source}Generate only some debugging info
snip 8-snip
"
Mind you - this gives you only the name of the source file. Fortunately the
.class file also contains the information about the name of the package
to which this Class belongs. Putting these two pieces together it is
possible to come up with the name the source file relative to the
SOURCEPATH.
This assumes though that the user is following the same directory structure
for
the sources as for the packages of classes. I have known instances where
that was not being followed. This is a problem only for novice Java
programmers
though - because they soon learn that the tools like debuggers cannot find
their
source files. This has been a big problem for people coming from c/c++
environments.
This is one of the biggest point I wanted to make in my write-up earlier.
It wouldn't be hard to adapt the debugger's strategy for finding a
source file based on the class file to a rebuilder.
This is what a rebuilder based on this would do:
- create a list 'classeslist' of all the .class files in the
destination directory
- create an assoc-list 'sourceslist' of all the .source files in the
source path
- for each .class file in 'classeslist'
- obtain the source file from the class file
- get the source file name from the 'sourceslist'
- compare the .class last modified time with the .java last
modified time
- add the .java to a list 'recompilelist' if the .class time is
eariler
- for each source file in the 'sourceslist' that isn't in the
'classeslist'
- add the source file to the 'recompilelist'
- compile all the files in 'recompilelist' with an @ list argument to
the compiler
I think this would work. It could be done in elisp (with a java tool
[use the bsh?] to help extract the source file name for class files).
There are a few toolkits available to get the info from class files -
BECL- http://bcel.sourceforge.net/
IBM's BCT -
http://www.alphaworks.ibm.com/aw.nsf/techmain/B1DD3263E75AD55C882568AC008364
A9?OpenDocument
C. Mcmanis's- http://www.mcmanis.com/~cmcmanis/java/dump/index.html
and others.
The above only deals with the out datedness of the class with respect
to it's source file. This does not deal with how other classes that
may depend on the class, that may have to be compiled.
The "Depend" optional task available with Ant does it the way it should
really be done. Read all about it at -
http://jakarta.apache.org/ant/manual/OptionalTasks/depend.html
Here is an excerpt from the web page -
"To determine the class dependencies, the depend task analyses the class
files of all class files passed to it. Depend does not parse your source
code in any way but relies upon the class references encoded into the class
files by the compiler. This is generally faster than parsing the Java
source."
Mind you - it is a separate task from the 'javac' task. In other words it
has nothing to do
with -depend flag of javac task or compiler.
I have heard that "Depend" task works very well for most cases.
I suspect that the Ant tasks can be run outside of Ant also (with some
tweacking). May be that's
what we need to do for adapting it for JDE ...
Hope this clarifies things...
-sandip
convert existing .java file?
I have set up my (defun my-jde-mode-hook () the way I like it. Now when I load an existing .java file I notice that the jde options only apply to new code that I add to that file using emacs. How can I re-format the entire file so that the hook options can be applied to the entire file? --== Sent via Deja.com ==-- http://www.deja.com/
2.2.7beta3 doesn't find java-executable
Hallo, I upgrade von jde2.2.5 to 2.2.7beta3. Now jde do not find my java executable. I will get the message: Searching for program: No such file or directory, java in minibuffer, if I try to use run-app or start-debugger. jde-run-java-vm is still 'java' and my PATH points right, too. "Compile App" works fine, althought I don't use full path in jde-compiler, too. I use XEmacs 21.1.10 on Debian/GNU 2.2 Sorry, I can't programing lisp and find this little bug. Can anybody help and fix it for the next beta? Thank you, Rick
RE: convert existing .java file?
C-x h M-x indent-region Ret HTH, Sandip V. Chitale work: (408) 535 1791 email: [EMAIL PROTECTED] web: http://www.brokat.com March 22.-28.2001 CeBIT Visit Brokat Technologies in Pavilion P32, our new location! -Original Message- From: Sing HU [mailto:[EMAIL PROTECTED]] Sent: Friday, March 23, 2001 1:31 PM To: [EMAIL PROTECTED] Subject: convert existing .java file? I have set up my (defun my-jde-mode-hook () the way I like it. Now when I load an existing .java file I notice that the jde options only apply to new code that I add to that file using emacs. How can I re-format the entire file so that the hook options can be applied to the entire file? --== Sent via Deja.com ==-- http://www.deja.com/
RE: dependency building with JDE (again)
"Sandip Chitale" [EMAIL PROTECTED] 23-Mar-01 9:27:27 PM The name of the source file (without the directory part) is always stored in the .class file whether or not you compile the source .java file with -g option. Didn't know that - thanks. Mind you - this gives you only the name of the source file. Fortunately the .class file also contains the information about the name of the package to which this Class belongs. Putting these two pieces together it is possible to come up with the name the source file relative to the SOURCEPATH. This assumes though that the user is following the same directory structure for the sources as for the packages of classes. I have known instances where that was not being followed. Yes... but if that is the case the name will be unique won't it? I can imagine a situation where you don't create a package based directory structure for your files but it should be possible to map the name found in the class file to the source files somehow in whatever configuration the source files are in. As long as you have the build structure in a directory. If you don't then this depend rebuild==full rebuild. I think I can prove that if necessary. There are a few toolkits available to get the info from class files - I use gnu,bytecode which is a self contained part of the Kawa system (Kawa is a Scheme-JVM compiler). The above only deals with the out datedness of the class with respect to it's source file. This does not deal with how other classes that may depend on the class, that may have to be compiled. Not if you examine *every* file in the build dir and *every* file in the source dir and compile the mismatches. I'm not talking about a single file depend being used to extrapolate all of the depends - I'm talking about a project depend. The "Depend" optional task available with Ant does it the way it should really be done. Read all about it at - I don't like Ant. It's not (L)GPLed. Nic
RE: dependency building with JDE (again)
I can imagine a situation where you don't create a package based directory structure for your files but it should be possible to map the name found in the class file to the source files somehow in whatever configuration the source files are in. As long as you have the build structure in a directory. If you don't then this depend rebuild==full rebuild. I think I can prove that if necessary. Spoke to soon - and without adequate thought: Define a class a.Test and store it in file: b/Test.java Define a class b.Test and store it in file: a/Test.java compile this and you get: a/Test.java - destination/b/Test.class b/Test.java - destination/a/Test.class naturally any system analysing the files will presume that b.Test relates to b/Test.java. Whoops. Nic
RE: dependency building with JDE (again)
I can imagine a situation where you don't create a package based directory structure for your files but it should be possible to map the name found in the class file to the source files somehow in whatever configuration the source files are in. As long as you have the build structure in a directory. If you don't then this depend rebuild==full rebuild. I think I can prove that if necessary. Spoke to soon - and without adequate thought: Define a class a.Test and store it in file: b/Test.java Define a class b.Test and store it in file: a/Test.java compile this and you get: a/Test.java - destination/b/Test.class b/Test.java - destination/a/Test.class naturally any system analysing the files will presume that b.Test relates to b/Test.java. Whoops. Fortunately :) a very unlikely scenario...unless the user is modifying the package statments inside the source file but forgetting to move the files.. :( -sandip
Re: 2.2.7beta3 doesn't find java-executable
At 10:41 PM 3/23/2001 +0100, Rick Janda [EMAIL PROTECTED] wrote: Hallo, I upgrade von jde2.2.5 to 2.2.7beta3. Now jde do not find my java executable. I will get the message: Searching for program: No such file or directory, java in minibuffer, if I try to use run-app or start-debugger. jde-run-java-vm is still 'java' and my PATH points right, too. "Compile App" works fine, althought I don't use full path in jde-compiler, too. I use XEmacs 21.1.10 on Debian/GNU 2.2 Sorry, I can't programing lisp and find this little bug. Can anybody help and fix it for the next beta? Nobody else has reported this problem and I don't have it on my system. So I doubt it is a bug. The JDE launches javac and java differently. It uses a subordinate shell to launch javac. It launches java directly as a subprocess of Emacs. It is possible that the JDK bin directory is in the shell command path but not in the Emacs command path. To test this, type M-x which java. If Emacs cannot find java, neither will the JDE. - Paul
