Package naming, disk organization

[Dave]

I'm having fun with Java (really!), but the real-world use of packages
is driving me crazy. If I were a corp. with a web site I might have a
something like this: org.davesjava.firstlgproj for a package
specification. I guess the disk drive files would be something like:
home/org/davesjava/firstlgproj (I use Linux, so there are no '\').

However:
* I don't have a commercial organization (yet), so I would need
something else - but what? Would jsoft.davesjava.firstlgproj be ok? It
seems to work for one trial, but down the road...

* I read that Java programmers like to have a source path and a class
path on the hard drive, which makes sense. So how does that work for
package specifications? Would it be: src/jsoft/davesjava/firstlgproj
and class/jsoft/davesjava/firstlgproj ? Assuming so, would a package
specification of jsoft.davesjava.firstlgproj still be ok?

* There is a conflict between a simple file structure and a conventional
package specification. For example, I may like:
home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that
translates into jsoft.class.firstlgproj - not exactly to convention.

So, I'm looking for some suggestions from people that have been there
done that.

Thanks,
Dave

 

[markspace]

I'm having fun with Java (really!), but the real-world use of packages
is driving me crazy. If I were a corp. with a web site I might have a
something like this: org.davesjava.firstlgproj for a package
specification. I guess the disk drive files would be something like:
home/org/davesjava/firstlgproj (I use Linux, so there are no '\').

However:
* I don't have a commercial organization (yet), so I would need
something else - but what?

If it's just your stuff, make up whatever name you like, it rarely
matters. I make up all sorts of package names and it's never made a
difference.

Just don't use a name like "org.apache" or "com.microsoft" and you are OK.

package specifications? Would it be: src/jsoft/davesjava/firstlgproj
and class/jsoft/davesjava/firstlgproj ? Assuming so, would a package
specification of jsoft.davesjava.firstlgproj still be ok?

Yes, yes and yes.

* There is a conflict between a simple file structure and a conventional
package specification. For example, I may like:
home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that

/home/jsoft/src/firstproj/src/jsoft/davesjava/firstlgproj

I don't like the first "src" in there though. I'd remove it and just
use /home/jsoft/firstproj/src/jsoft/davesjava/firstlgproj.

I use

/home/myname/Dev/proj/projname/src/packagename/name

I don't think I'd like to have a /src directory for ALL sources, that
wouldn't make sense to me. I use Dev/proj/projectname and keep all the
files, source and compiled, in one spot under that project name.

 

[Roedy Green]

* I don't have a commercial organization (yet), so I would need
something else - but what?

You can register a domain for in the order of $10 a year.

See http://mindprod/jgloss/domain.html

You don't have to host a website, but even that can be free.
see
http://mindprod.com/ispvendors.html

 

[Roedy Green]

* I read that Java programmers like to have a source path and a class
path on the hard drive, which makes sense. So how does that work for
package specifications? Would it be: src/jsoft/davesjava/firstlgproj
and class/jsoft/davesjava/firstlgproj ? Assuming so, would a package
specification of jsoft.davesjava.firstlgproj still be ok?

Let your IDE decide how to lay out source and object. It might put
them in the same dir or separate dirs. You almost never need think
about it.

 

[Lew]

I'm having fun with Java (really!), but the real-world use of packages
is driving me crazy. If I were a corp. with a web site I might have a
something like this: org.davesjava.firstlgproj for a package
specification. I guess the disk drive files would be something like:
home/org/davesjava/firstlgproj (I use Linux, so there are no '\').

The disk drive organization in most Java implementations matches the package
organization, rooted at a directory mentioned in the class path.

However:

* I don't have a commercial organization (yet), so I would need

Irrelevant, as others have told you. Use the domain you would have if you had one.

Who says you have to have a commercial organization to have a domain?

Who told you you had to have a domain to use it as your package name? The only rule
is that you cannot use someone else's.

something else - but what? Would jsoft.davesjava.firstlgproj be ok? It

The first element should be a top-level domain, like "com".

Do not use the word "java" in your package names. What's the point? If it isn't
Java it isn't in your Java program. Also, "Java" is trademarked.

seems to work for one trial, but down the road...

What exactly do you fear?

What evidence led you to that concern?

* I read that Java programmers like to have a source path and a class

Huh?

Java programmers don't "like" anything. We do what the platform calls for.

path on the hard drive, which makes sense. So how does that work for
package specifications? Would it be: src/jsoft/davesjava/firstlgproj

Is "src" in your classpath or sourcepath?

and class/jsoft/davesjava/firstlgproj ? Assuming so, would a package

Is "class" in your classpath or sourcepath?

The first element of your package name by convention should equate to a TLD.
Use "com", typically.

specification of jsoft.davesjava.firstlgproj still be ok?

* There is a conflict between a simple file structure and a conventional
package specification. For example, I may like:

No, there isn't.

home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that
translates into jsoft.class.firstlgproj - not exactly to convention.

Don't use "class" or "package" or "java" or any garbage like that in your package names
unless there is a specific semantic to the use of the term. The fact that there are classes
in a package does not need reinforcement in your names. It only serves to add clutter to
do that.

So, I'm looking for some suggestions from people that have been there
done that.

What does the documentation suggest you do?

 

[Eric Sosman]

I'm having fun with Java (really!), but the real-world use of packages
is driving me crazy. If I were a corp. with a web site I might have a
something like this: org.davesjava.firstlgproj for a package
specification. I guess the disk drive files would be something like:
home/org/davesjava/firstlgproj (I use Linux, so there are no '\').

However:
* I don't have a commercial organization (yet), so I would need
something else - but what? Would jsoft.davesjava.firstlgproj be ok? It
seems to work for one trial, but down the road...

* I read that Java programmers like to have a source path and a class
path on the hard drive, which makes sense. So how does that work for
package specifications? Would it be: src/jsoft/davesjava/firstlgproj
and class/jsoft/davesjava/firstlgproj ? Assuming so, would a package
specification of jsoft.davesjava.firstlgproj still be ok?

* There is a conflict between a simple file structure and a conventional
package specification. For example, I may like:
home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that
translates into jsoft.class.firstlgproj - not exactly to convention.

So, I'm looking for some suggestions from people that have been there
done that.

I concur with markspace and Martin Gregorie. As for the
actual package name, it matters a lot less nowadays than it may
have when Java was young. Y'see, the tools have learned about
Java and can easily "refactor" a package: Start with dboland.foo,
later change your mind and choose com.bigcompanythatboughtme.foo,
and the tools will handle the rename -- both of the renamed package
and of references to it in extra-package files.

That, of course, assumes all the relevant sources are visible to
the tool when the rename occurs. If you've already distributed the
dboland.foo package to umpty-leven other people who've been writing
their own code to use it, they may be somewhat perturbed when your
next patch release arrives and changes the world. But as long as the
code is in a "pre-public" stage, dboland.whatever is fine.

 

[markspace]

If you've already distributed the
dboland.foo package to umpty-leven other people who've been writing
their own code to use it, they may be somewhat perturbed when your
next patch release arrives and changes the world.

I've seen smaller, real world libraries do this, although not at the
patch level. When they roll major versions though, they'll switch top
level package names.

MapDB, for example, used to be JDBM and all in the jdbm.stuff package.
Then they were an Apache project for a while and used an
org.apache.mapdb.stuff package name, now they've gone "real" and got an
mapdb.org domain and are releasing under package org.mapdb.stuff.

It's not a huge deal and there's always ways to manage it.

 

[Dave]

I'm having fun with Java (really!), but the real-world use of packages
is driving me crazy. If I were a corp. with a web site I might have a
something like this: org.davesjava.firstlgproj for a package
specification. I guess the disk drive files would be something like:
home/org/davesjava/firstlgproj (I use Linux, so there are no '\').

However:
* I don't have a commercial organization (yet), so I would need
something else - but what? Would jsoft.davesjava.firstlgproj be ok? It
seems to work for one trial, but down the road...

* I read that Java programmers like to have a source path and a class
path on the hard drive, which makes sense. So how does that work for
package specifications? Would it be: src/jsoft/davesjava/firstlgproj
and class/jsoft/davesjava/firstlgproj ? Assuming so, would a package
specification of jsoft.davesjava.firstlgproj still be ok?

* There is a conflict between a simple file structure and a conventional
package specification. For example, I may like:
home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that
translates into jsoft.class.firstlgproj - not exactly to convention.

So, I'm looking for some suggestions from people that have been there
done that.

Thanks,
Dave

Fist, thanks for all of the insight! Based on what everyone has said,
and what I have read (Oracle, other online info), the plan is to:

1. Eventually get URL, but that will have to wait until a few other
shoes have dropped so I don't have to keep changing it (as was mentioned
by a few of you). Something I did not consider, but with the wave of
mergers of companies, I can see that this could be a real headache to
down-stream developers using my packages.

2. For now, use foo.dboland.<proj_name> as the URL. The disk
organization would then be (Linux):
home/user/javadev/src/foo/dboland/<proj_name>
home/user/javadev/class/foo/dboland/<proj_name>
The class path will be: home/user/javadev/class
And the package specification will be: foo.dboland.<proj_name>

3. I have been looking for the source path documentation, but had not
heard of it until it was mentioned in this thread.

Any thoughts/comments?

Thanks again!
Dave

 

[Stefan Ram]

by a few of you). Something I did not consider, but with the wave of
mergers of companies, I can see that this could be a real headache to

What about a GUID as a package name?

like

package guid.02e091ad_d35d_4d2c_b46f_6c6c79e4992f;

, then named projects:

package guid.02e091ad_d35d_4d2c_b46f_6c6c79e4992f.spreadsheet;

?

If this is too long, any random combination should help to
make conflicts unlikely:

package di28Tcx01GGc.spreadsheet;

 

[Jukka Lahtinen]

The first element of your package name by convention should equate to a TLD.
Use "com", typically.

Or to a national top-level domain, like "fi" in Finland.

 

[Arne Vajhøj]

What about a GUID as a package name?

like

package guid.02e091ad_d35d_4d2c_b46f_6c6c79e4992f;

, then named projects:

package guid.02e091ad_d35d_4d2c_b46f_6c6c79e4992f.spreadsheet;

?

If this is too long, any random combination should help to
make conflicts unlikely:

package di28Tcx01GGc.spreadsheet;

Package names are no different than other names, the name
is intended to tell what it is.

Using GUID's will loose the documentation in the name.

Not good.

Arne

 

[markspace]

2. For now, use foo.dboland.<proj_name> as the URL. The disk
organization would then be (Linux):
home/user/javadev/src/foo/dboland/<proj_name>
home/user/javadev/class/foo/dboland/<proj_name>
The class path will be: home/user/javadev/class
And the package specification will be: foo.dboland.<proj_name>

I don't like "foo", too likely to collide with something. Use dboland
as the top name, I think that's much better.

I still don't like the split between src and class at the top level.
It's weird, and as others have pointed out you'll fight most tools
(IDEs, etc.) to do it this way. Easier is project_name/src and
project_name/build/classes.

Getting a domain name is the absolute least of your concerns.

 

[Dave]

I don't like "foo", too likely to collide with something. Use dboland
as the top name, I think that's much better.

I still don't like the split between src and class at the top level.
It's weird, and as others have pointed out you'll fight most tools
(IDEs, etc.) to do it this way. Easier is project_name/src and
project_name/build/classes.

Getting a domain name is the absolute least of your concerns.

This is the one thing (so far) that I really don't like about Java. The
Oracle assumes that developers are corporations with web sites. The
reality is that some are learning a new language, or developing software
for others, etc. So, the package name/path needs to reflect this
diversity. By the way, the idea for a source and a class path is
discussed by the Oracle at:
http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html

I should also point out that I'm a tad old fashion (I guess) because I
use an editor and command line. I do plan to go to an IDE - once I'm
told which one everyone wants to use.

Ok, back to the subject. I want to obey the conventions, but not box
myself in or create future problems. So how about:
* domain (used for general Java development for now): dboland
* source: home/user/javadev/dboland/proj_name/src
* classes: home/user/javadev/dboland/proj_name/classes
// I don't get the need for build/classes.
* CLASSPATH: home/user/javadev/dboland

Comments?

Dave

 

[Jukka Lahtinen]

Ok, back to the subject. I want to obey the conventions, but not box
myself in or create future problems. So how about:
* domain (used for general Java development for now): dboland
* source: home/user/javadev/dboland/proj_name/src
* classes: home/user/javadev/dboland/proj_name/classes
// I don't get the need for build/classes.
* CLASSPATH: home/user/javadev/dboland

CLASSPATH: home/user/javadev/dboland/proj_name/classes

 

[Lew]

This is the one thing (so far) that I really don't like about Java. The

Oracle assumes that developers are corporations with web sites. The

You have been disabused of this notion by several in this thread.

Are you paying attention to the responses?

reality is that some are learning a new language, or developing software
for others, etc. So, the package name/path needs to reflect this
diversity. By the way, the idea for a source and a class path is
Okay.

discussed by the Oracle at:
http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html

I should also point out that I'm a tad old[-]fashion[ed] (I guess) because I

Why the colorful characterization?

use an editor and command line. I do plan to go to an IDE - once I'm

Does "command line" for you include tools like Ant and Gradle?

told which one everyone wants to use.

I recommend you use the one you want to use. Don't be a sheep.

There are three commonly recommended, NetBeans, Eclipse and IntelliJ.
It makes no difference to anyone else which one you prefer, or if
you prefer none.

Ok, back to the subject. I want to obey the conventions, but not box
myself in or create future problems. So how about:

Three things, divergent.

You "obey" conventions (the correct term is "follow") in order to
facilitate social integration. It was ever thus.

Conventions are not strait jackets. Programmers are logical. Use what works.

* domain (used for general Java development for now): dboland

* source: home/user/javadev/dboland/proj_name/src

* classes: home/user/javadev/dboland/proj_name/classes

There are several conventions for the output of the compiler and other
build steps. Raw "classes" isn't really one of them. The IDEs and many
projects use "build/" or "bin/", and beneath that, "classes/".

The reason is that there are many artifacts, not just classes.

There is ample material online as to what is a good project structure.
I strongly suggest you look those up and follow them.

// I don't get the need for build/classes.

So you ignore it without investigation? Tsk.

You will have great difficulties in your programming life.

In this case you made the wrong decision for a large number of
real-world scenarios. Find out why, and under what circumstances
your choice is appropriate, and under which not.

* CLASSPATH: home/user/javadev/dboland

Nope. That will not work.

Classpath is the root of the *class* hierarchy, which you already
specified to be your "classes/" subdirectory. Study the docs.

Comments?

RTFM more.

 

[Arne Vajhøj]

Fist, thanks for all of the insight! Based on what everyone has said,
and what I have read (Oracle, other online info), the plan is to:

1. Eventually get URL, but that will have to wait until a few other
shoes have dropped so I don't have to keep changing it (as was mentioned
by a few of you). Something I did not consider, but with the wave of
mergers of companies, I can see that this could be a real headache to
down-stream developers using my packages.

2. For now, use foo.dboland.<proj_name> as the URL.

I will say as many other - why not do it right from start
and follow the domain convention.

The disk
organization would then be (Linux):
home/user/javadev/src/foo/dboland/<proj_name>
home/user/javadev/class/foo/dboland/<proj_name>
The class path will be: home/user/javadev/class
And the package specification will be: foo.dboland.<proj_name>

You will find that:

home/user/javadev/<proj_name>/src/foo/dboland/<proj_name>
home/user/javadev/<proj_name>/bin/foo/dboland/<proj_name>

work better with both the common IDE's and some command
line tools.

Arne

 

[Arne Vajhøj]

This is the one thing (so far) that I really don't like about Java. The
Oracle assumes that developers are corporations with web sites. The
reality is that some are learning a new language, or developing software
for others, etc. So, the package name/path needs to reflect this
diversity. By the way, the idea for a source and a class path is
discussed by the Oracle at:
http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html

I should also point out that I'm a tad old fashion (I guess) because I
use an editor and command line. I do plan to go to an IDE - once I'm
told which one everyone wants to use.

Ok, back to the subject. I want to obey the conventions, but not box
myself in or create future problems. So how about:
* domain (used for general Java development for now): dboland
* source: home/user/javadev/dboland/proj_name/src
* classes: home/user/javadev/dboland/proj_name/classes
// I don't get the need for build/classes.
* CLASSPATH: home/user/javadev/dboland

The domain should really not be a problem.

Several has already pointed out that you can buy
yourname.tld rather cheap.

tld.yourname.dboland

But you could also get yourname.somefreeservice.tld
for free many places and you could use that.

tld.somefreeservice.yourname.dboland

Arne

 

[Lew]

Martin Gregorie wrote:
....

I maintain a separate directory where I place jar files, /home/java/jarlib
and put that in the CLASSPATH During development I don't bother with

N.b., to "put that in the CLASSPATH" requires the correct syntax, which
Martin elided. Beginners might put the directory itself in the CLASSPATH
without the "*" notation. Make sure you specify what you think you're
specifying.

Putting just the directory in the CLASSPATH means it can find class files
rooted there, but JARs are another matter.

http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/classpath.html

 

[Arne Vajhøj]

Same here - and I've never bothered with any attempt to separate .java
files from the rest of the compiler output. All the tools (javac, ant,
javadocs etc.) can work very nicely with this mix. I know some C
programmers like to separate source from object, but in Java its really
just as easy to leave them in the same place. ant, in particular, is even
has a notation, "org/**/*.class", which means "walk the directory tree
whose root is 'org' and apply this operation to every class file in the
tree. IOW, if it was building a jarfile, it would include all the
directories and class files while omitting any other files in the tree.

The same tools also work with the source and output files
separated.

And it is easier to just view the source files instead of all
files.

And if you start to run tools that generate Java source code
(like WSDL2Java), then having everything in one dir just doesn't
cut it anymore.

Arne

 

[Arved Sandstrom]

Dave wrote:

[ SNIP ]

Don't use "class" or "package" or "java" or any garbage like that in your package names
unless there is a specific semantic to the use of the term. The fact that there are classes
in a package does not need reinforcement in your names. It only serves to add clutter to
do that.


What does the documentation suggest you do?

Nothing much useful in the tutorials, unless you're a corporation with a
domain or domains. The docs don't make it clear that you can use
whatever hierarchy you damned well want for your packages - it bleats
too much about Internet domains. Sun (Oracle) clearly not thinking about
the hundreds of thousands of Java programmers out there w/o a domain name.

Me, I use for personal projects org.ahs.* If the American Horticultural
Society ever gets some of my private code and is pissed, I'll sue 'em.

AHS