A file system for organising java stuff ?
maksim at swin.edu.au
Thu Jan 14 22:48:45 PST 1999
Apologies for cross posting this to both mail-lists, but I wanted to get
as broad a response about this from people using java & these are the
java-related groups that I'm subscribed to.
Anyways, what occurred to me during the new years break is to arrange my
java stuff into a file system along the lines used in linux systems
(unix in general?).
As it says below, this was all pretty much a thing that came to me and
sounded good as I jotted it down. I don't mean for this to be foisted
upon anyone, but it's helped me organise my files and I thought that if
other people liked the idea and wanted to use it then it might make life
a bit easier (or maybe it's a really stupid idea and everyone already
does it a better way) - in any case please let me know.
JFS - Java File System
This is the system I have decided to use for organising all my Java
related files. It is
based loosely on the linux standard filesystem organisation.
The highlevel directories are:
|-/bin This holds all PLATFORM SPECIFIC executables used by java apps,
| including non-binary files like platform specific shell scripts.
|-/lib This holds all of the class files, arranged in directories as
| their packages.
|-/zlib This holds class files which are packaged (and possibly
| zip or jar files.
|-/res This holds all "java-wide" resources such as icons.
|-/src As the name suggests this contains java source code. Note that
| can also hold non-java source code as long as that code produces
| java bytecode class files, e.g. JPython.
|-/doc This holds all of JavaDoc programming documentation for the
| code in the JSFS, note all USER documentation should go into the
| man dir structure and NOT here.
|-/tmp Location for temporary files created by Java apps.
|-/man Here goes all user documentation, manuals, howto, faqs, etc.
| A X-platform format such as HTML is preferred, although other types
| are exceptable as long as java-based readers are provided or
| are fairly X-platform, e.g. PDF, ASCII, (PostScript??).
|-/etc Here go all the (Java) system-wide config files these should
| use the java "properties" format so that a the config files are
| human-readable text and a nice graphical way can be provided for
| any setting in a standard way.
|-/var And here go all of the config files used by java apps. These
should preferrably use the java's "properties" format.
The root directory of the above structure can be anywhere. I currently
above in a subdir called ~/Java, but I suppose having it is /usr/local
a good system-wide place to put it on a *nix box (really it's not very
as long as there is some way to point the JVM to it).
Some things that I'm still not sure about is for instance should the JVM
into the bin directory heirarchy or should it be outside, in whatever
underlying platform puts it's executables, at the moment I think it
the later. Likewise for the standard JDK API classes, at the moment I
they should go in the zlib dir, but I'm not even sure if the concept of
zlib is a good idea, if it should be a top-level dir or inside lib (see
for more on this issue). It is a new concept, not one taken form
so I'm on pretty shacky ground here, I'll leave it to time, experience
feedback to decide it's future. The res directory heiracrchy is another
where I have gone out on a limb. I think it would be useful to have
like this, where things like common icons, bitmaps, sounds, whatever
stored for use by all java apps (again any comments on this would be
Another thing up for grabs with the lib & zlib directories is which
should be searched by the JVM when looking for classes. At the moment I
suggest lib then zlib, since the main reason for having a lib (for me
is the ability to quickly and easily drop-in replacements and new
class files that I'm working on. However with the availability of
virtual-filesystems to present a zip/jar archive files as if they are
the filesystem (see the Midnight Commander program for what I mean) this
soon become a moot issue and the lib and zlib could be combined into a
lib directory containing _only_ archive files (the avoidance of
clashes in this case is an issue in it self).
I think that one problem with the above, in fact with systems in general
as linux and java, which have continually revised libraries is
unixy systems, soft-links often seem to be used to address this problem,
it's not a X-platform solution and not even ideal on those platforms
support it. I'm sure greater minds than mine have considered this
at the moment I'm not aware of anything better than soft-links which is
intend to use for the moment-I leave this an an open-issue and invite
I would appreciate any feedback (short of all-out flames) as this was a
the moment idea that made more and more sense as I wrote it up, but
probably stand a good deal of improvement.
"...handing C++ to the average programmer seems roughly comparable to
handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
More information about the kaffe