Folks,
Here are some of my observations with respect to compilation and
Java projects -
1. It is so obvious that sometime it is missed by many people....
The Java "import" statement imports the object form i.e. .class file
and not .java file. This is unlike the C/C++ world whereby one
"includes" .h files i.e. source form. This observation may seem
trivial but is the reason why make like behavior was built into
the Java compilers by Sun. The sad thing is that they have not kept
the behavior consistent from one release of JDK to the other.
2. Even though it is a good practice to have one top level class per file
it is not required by Java specifications. Some java compilers may warn
about it though.
3. The restriction that the name of the top level public
class has to match the name of the .java file helps somewhat. The class
files for inner classes have name with same prefix as the name of the
outer
class is also helpful. (OuterClass.class and OuterClass$*.class covers
all the classes).
4. The package statement adds to the complications because it results in
a directory hierarchy. This gives a lot of problems to the beginner
because they may not start with the similar directory hierarchy for the
sources. Also one has to remember to move the source file if one changes
the
package statement inside the .java file.
5. The difference in javac's behavior when one uses or does not use
the -d option is also confusing to many beginners. When one uses the -d
option
javac will create a directory hierarchy under the output directory that
patches the package statement inside the .java file vs. when one does not
use the -d option javac puts the compiled classes in it's current
directory).
6. 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.
What I am trying to point out is that any mechanism that builds a Java
system
has to take into account all these factors.
My 2 yens.
-sandip
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: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 19, 2001 5:05 AM
> To: [EMAIL PROTECTED]
> Subject: PROPOSAL: New Java Build Feature
>
>
> Hi All,
>
> The JDE has a Java build feature that relies on javac
> dependency checking
> to rebuild a project. This feature has been broken by the
> reduced level of
> dependency checking in recent versions of javac.
>
> Lately I have begun using a new approach to using javac for
> building my
> Java projects that appears fast and perfectly reliable. I'm
> considering
> replacing the current Java build scheme with this new version
> and would
> like your feedback.
>
> The new approach relies on automatic creation of special
> classes, called
> compile masters, that reference every Java class in a
> project. The compile
> masters correspond to a makefile. The Java build algorithm creates a
> compile master in the root package and in each descendent
> package, thereby
> creating a hierarchy of compile masters that mirrors the
> package hierarchy.
> It then uses javac to compile the toplevel compile master.
> Compiling the
> root compile master causes javac to check every class in the
> project to
> ensure that it is current and recompile any classes that are
> not current.
>
> The benefits of this approach are:
>
> 1. No need for makefile.
>
> 2. Fast -- only one invocation of javac is needed to rebuild
> a project,
> no matter how big the project is.
>
> 3. Reliable -- every out-of-date class in the project is recompiled.
>
> The Java build feature would include a build-and-run command
> and would also
> allow you to specify multiple projects in a single build
> command to handle
> the cases where one project is dependent on classes in
> another project.
>
> Note that this new build would not replace the JDE's support
> for using make
> to build projects. You could continue to use make as an
> alternative to the
> Java build feature.
>
> What do you think of this proposal?
>
> - Paul
>
