Q: Java source and directory structure - 'standard way' ?

From: FISH (joeking_at_merseymail.com)
Date: 01/23/04 

Date: 23 Jan 2004 10:23:31 -0800

Ever have one of those days when you're not sure if it's you who's gone
mad, or the rest of the world?

I have an Open Source project on SourceForge for communication with YSMG
- Yahoo's IM protocol. I keep the project source in three directories,
based upon the code's function: one for the network API code itself, one
for the support APIs (basic chat spam filtering, Swing models, rich text
decoders, etc), and one for the test client built using the network API.

When I compile I use the -d option on Sun's SDK... the compiler builds
the necessary directory tree (if not already there from a previous build)
and places the class files into it.

One or two users have complained that the source is in the wrong direct-
ories and it won't compile. One guy helpfully rearranged the source tree
and mailed me a zip file - telling me this is the 'standard way' to store
Java source.

What they do is they build the package directory tree by hand, place
their .java files into the appropriate directories, and then just
"javac *.java" in each directory of the tree. The result is that, in
the absense of a specified output directory, the class files end up
right next to the source files - but this works because the source
code directory structure has been created to mirror the package names.

This isn't the first time I've seen this done - I've noted a programmer
where I work does the same thing! And although it works, to me it is
less than ideal. I have a hard time accepting that this is the 'standard
way', for several reasons:

1) The compiler should be responsible for organising and creating *ALL*
   its output itself - this includes creating any directories which
   are needed for its representation of the code. The user should not
   need to work this out in advance and provide them.

2) With source and class files intermixed, packing up the source or
   creating a Jar becomes a major headache. Surely the output direct
   -ories should remain _pure_, containing only those files which form
   the package?

3) This scheme pre-supposes that Java compilers will always use direct-
   ories to model their package hierarchy - which might not always be
   the case.

I can think of a handful of other reasons why I think this scheme is
inferior, but I think I've already made my point...! :-) So, the
question is... Is this *really* the 'standard way' (or conventional
way) of holding Java source - or are all these coders just ignorant
of the -d switch ???

-FISH- ><>

Relevant Pages

  • Re: Java server wont run after reboot
    ... Working with classpaths in Java isn't too hard, ... package definitions in your source code. ... Execute from that directory, no classpath definition needed. ... Assuming that you compile your code in the same directory and deposit the ...
    (RedHat)
  • Re: netbeans packages and directory structure SNAFU
    ... Have you ever read the Java Tutorial? ... public class SomeClass ... If you put it in a package like so: ... you can still compile it anywhere via "javac SomeClass.java". ...
    (comp.lang.java.help)
  • Re: Producing a binary install
    ... It did bomb once, about 4 hours into the compile, and demanded I ... Java, and other packages are not available in pre-compiled form. ... install for her over the net, and then do the rest of the install ... Otherwise doing a 'make package' after the port has been installed will create a package for you. ...
    (freebsd-questions)
  • Re: multiple source files
    ... C++ I would have separate translation units ... I would then compile those translation ... is approached in java because I really don't ... In Java you just compile the source files to class files, ...
    (comp.lang.java.programmer)
  • Re: Q: Java source and directory structure - standard way ?
    ... > the absense of a specified output directory, the class files end up ... > code directory structure has been created to mirror the package names. ... > way) of holding Java source - or are all these coders just ignorant ...
    (comp.lang.java)