Monday, December 11, 2006

Naming Java Packages In OpenJUMP

When I was putting together the Java Package Maps for Vivid’s JUMP and OpenJUMP I noticed some inconsistencies that I would like us to address as a group of developers.

The main inconsistency I noticed was when a portion of a package name was made up ttwo or more terms that are normally separated by a space. (Java doesn’t allow spaces in a package name.) For example, let’s take my package for the work I’ve been doing on OpenJUMP’s Cursor Tools. All my packages at the SurveyOS for OpenJUMP follow this naming convention:

net.surveyos.sourceforge.openjump

I’ve got at least three ways that I can name the package for my Cursor Tools code, and I see packages in OpenJUMP named with all 3 techniques techniques. For example:

[1] net.surveyos.sourceforge.openjump.cursorTools
[2] net.surveyos.sourceforge.openjump.CursorTools
[3] net.surveyos.sourceforge.openjump.cursortools

I think we need to pick one of these techniques for all package names. I’m not sure if one of these methods is more correct than the other two, and I have no real preference for one over the others. But I’d like to use the one everyone else has agreed to use.

I also think it might be to everyone’s benefit if we use the org.openjump package for as much OpenJUMP code as we can. If a developer is writing code for OpenJUMP that is directly tied to the programs other parts, and can’t be used independently, I think it should go in the org.openjump package. As an example, I would need to change my net.surveyos.sourceforge.openjump packages to org.openjump packages. Source code that is used in OpenJUMP but that could be used independently can be prefixed with the vendor or organizations standard package name. For example, I might have some utility classes at the SurveyOS that I want to use in OpenJUMP. I could keep this in the net.surveyos.sourceforge package.

I’d like to hear from other developers on the JPP Mailing List. Are these good ideas, bad ideas, and why do you have that opinion? I think we should make an effort now to get some simple standards in place for package naming. This will help us avoid an ugly source code structure down the road.

The Sunburned Surveyor

0 comments: