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

From: Raymond DeCampo (rdecampo_at_spam-I-am-not.twcny.rr.com)
Date: 01/28/04

  • Next message: Raymond DeCampo: "Re: Search advanced TextArea (bold, underline, different font-sizes...)"
    Date: Wed, 28 Jan 2004 02:06:55 GMT
    
    

    FISH wrote:
    > Raymond DeCampo <rdecampo@spam-I-am-not.twcny.rr.com> wrote in message news:<qjGQb.76871$Su5.30054@twister.nyroc.rr.com>...
    >
    >>Let me address your concerns:
    >>
    >>1) The compiler does create the output; the source code and the
    >>directories it is contained in are input.
    >
    >
    > Ah yes, but in Java the package 'hierarchy' is part of the output, so
    > surely it is more correct that the directories should be constructed
    > by the compiler - by referencing the source - than created by the
    > programmer by hand...?
    >
    >
    I do not understand your point of view. The package structure is NOT
    dictated by the compiler. The programmer dictates to the compiler what
    the package structure should be via the "package" directive. So the
    package hierarchy is in fact totally controlled by the programmer and
    the source.

    >
    >>2) One can still use the -d flag to separate source and class files.
    >
    >
    > Which begs the question, why not use -d all the time? (Then you never
    > get source and binary intermixed in the same directories!)
    >

    As a matter of fact, I always do. I think most tools also support and
    encourage this separation. It has nothing to do with the question of
    how one should organize one's source code however.

    > Hmmmm... :-)
    >
    >
    >
    >>3) I was going to dismiss this concern as silly, but the JLS does
    >>explicitly mention using a database to store classes, so that would have
    >>been wrong of me. However, I doubt this is a serious concern for the
    >>near future.
    >
    >
    > I think this pretty much answers the question for me. The fact that
    > it 'works for now' would suggest to me that this union (in the C
    > sense of the word) of source and output directories it is not a
    > desirable way to structure code - and obviously not a 'standard way'.
    >
    > It works because the compiler will output to the same directory as
    > the source, if not directed. I'm not sure if this default behaviour
    > can be guaranteed in future, or on all compilers - so I'd rather
    > avoid it.

    I'm not sure what "it works" refers to. We agree that the source and
    class files should be separate. I am advocating structuring the source
    code based on the package hierarchy; you are advocating structuring the
    source code in an arbitrary manner based on logical groupings of
    functionality. As far as I can see, my method is a subcase of yours so
    I certainly hope you think it works!

    >
    >
    >
    >>Finally, let me suggest that you try out ANT. ANT provides a way of
    >>easily specifying how to build your code. It can run the compiler and
    >>jar the files. As an added bonus you can distribute the build script
    >>and everyone working on the code will be able to build it in the same way.
    >
    >
    > I already use Ant, thanks :-) In fact the package I mentioned is
    > actually used in one of the many extensions to Ant, called ImTask.
    >

    In that case, let me say thanks for adding to the wealth of open source
    tools.

    >
    > Thanks for your input, but I think I'll stick to packaging the source
    > in a way that makes sense to the project, and leave the compiler to
    > figure out how it wants to implementent the package 'hierarchy' - it
    > probably has a better idea than I do :-)
    >

    I hope you take this discussion in the spirit of which it is given --
    simply an academic discussion about source code organization. I haven't
    meant to insult you in any way nor do I really care how you organize
    your source code...it was just a fun topic. After all, the real measure
    of code is how it runs, not what directory it lives in.

    Ray


  • Next message: Raymond DeCampo: "Re: Search advanced TextArea (bold, underline, different font-sizes...)"

    Relevant Pages

    • Re: Freeware download corrupt (?)
      ... > a list of all functions in a package that fall in that category. ... > conflict with a function of that name in a future version of the CRTL. ... > But the compiler doesn't do that, so for now we're on our own. ... I create a package with a routine in it called "highwater". ...
      (comp.os.vms)
    • Re: PL/I, COBOL, Advantages, Equivalence, et al
      ... SPARK will allow a variable to have a value that conforms ... might be that a package somewhere will look like this ... An Ada compiler may issue a warning; ... LC> Ada/SPARK support a boolean type? ...
      (comp.lang.pl1)
    • Re: How to use packages?
      ... libraries in assembly could be created and imported for use. ... package so that some very cool libraries could be created in ways that I ... This would be very wrong -- basically giving away a Lisp compiler ... For example (given the name as.exe for the assembler): ...
      (comp.lang.lisp)
    • RE: Visual studio 2003 .NET versus its own Command Prompt
      ... > package in the lab. ... > command line compiler which cames with it. ... library, which is a .lib file, for it to know where in the DLL the functions ...
      (microsoft.public.vc.language)
    • Re: Frage zu Packages und our
      ... Der Compiler selbst schaut jedoch bei einem unqualifizierten ... Laufzeit tatsächlich auf die globale (Package) Variable zugegriffen. ... von "my" ident sind - denn ein innerhalb eines Scopes deklariertes ...
      (de.comp.lang.perl.misc)