From what I understand Java packages often use a company's website as a package namespace.
For example if stackoverflow had a Java widget library it might be called com.stackoverflow.widget.
But what happens if you use an obscure TLD. Is info.example.widget acceptable?
Sure, no problem. Whatever your company's domain name and whatever its TLD is, reverse the order of its components for your Java packages.
The intent of using a domain name is that it helps ensure uniqueness using something that pretty much any organization will already have. That means that no one really needs to be 'responsible' for doling out uniques IDs for package names (or that something ugly like the GUIDs used by COM don't need to be used).
So even if your domain name is obscure, by all means use it - it's still unique.
Related
I can't find a Q/A on SO that answers my exact question, so I figure I'd post it and see what comes back.
As far as the naming convention goes for Java packages, I understand that it's supposed to be the reverse domain name: com.whatever.stuff and I get the rules about no mixed case, hyphens, keywords, etc.
I've also read section 7.7 (Unique-Package-Names) of the Java Language Specification. As far as I can tell, the rules from Java are to use the reverse domain to insure uniqueness... and if you don't have one, go get one:
You form a unique package name by first having (or belonging to an organization that has) an Internet domainname, such as sun.com. - Section 7.7
So if I'm not interested in shelling out the money for a domain name, I don't belong to a company whose name I can piggyback off of, is there any part of the naming convention that I'm missing that should be followed? I'm thinking I can just go name it whatever unique name I feel like at this point, but I was just wondering if I was missing anything.
Note: I would like to release my package for other developers to use, so I didn’t want to just do something that worked on my system, but something more standard if possible.
I added the android tag because the java packages I'm going to be writing are going to be used in an Android application, wasn't sure if there were different opinions from android developers.
If you are going to be distributing a lot of stuff, I would really suggest getting a domain name. Another alternative however would be to use your e-mail: e.g. bob#gmail.com would become com.gmail.bob. This is less common than using domain names but is still done by some and still ensures uniqueness.
One convention is to use the domain name of the hosting provider, e.g.
com.github.myrepositoryname
net.sf.sourceforge.myproject
com.googlecode.myproject
Benefits:
your package namespace will be unique, since the hosting provider won't have two projects of the same name
it's only as expensive as the host's costs, many of which are free
it can be an easy way to fulfil Sonatype's requirements if you want to get your project into Maven Central
Drawbacks:
if you decide to change providers, you either have package structures which are out-of-date, or you introduce backward-incompatible changes to keep the source in line with your new provider
Domain names can be had for free.
For example dyn.com offers free domain names of the form 'whatever.dyndns.org' at http://free.domain.name/
If you are the only coder, you can just use your name.
My name is Jannis Froese, so I would use
jannisfroese.projectname.stuff
or if you want to stay with 'valid' domain names
localhost.jannisfroese.projectname.stuff
(localhost is a reserved top level domain)
Of course this only works if your name is sufficiently unique, so that a collision is unlikely enough
In a professional environment, the convention is to use reverse domain. In an environment that's more associated with yourself, you can use org.projectname.packagename.*.
It's a convention, not a hard and fast rule. You're free to use whichever domain naming style you like.
Every time I look at some Java source code, I find myself surfing in a folder that has folder that has folder that has folder in it etc. Why does Java require so many nested folders, which have nothing else in them except the new subfolder?
For example:
https://github.com/halfninja/android-dragcontrol3d/tree/master/src/uk/co/halfninja/android
That's probably not the worst example, but there are two folders "uk" and "co" that just don't make sense. I see this in Java sources only!
And for example minicraft: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=398
import com.mojang.ld22.gfx.Font;
import com.mojang.ld22.gfx.Screen;
import com.mojang.ld22.gfx.SpriteSheet;
Why not just write:
import gfx.Font;
import gfx.Screen;
import gfx.SpriteSheet;
That's so much cleaner.
(I have never programmed in Java.)
These are there to prevent conflicts with other jars. Having something like the company url in the package name makes it likely to be unique enough to not conflict with someone else's package and classes.
Your example is a good one, since it seems pretty reasonable to imagine two people thinking of using "gfx" as a package name and with classes like Font or Sprite. Now, if you wanted to use both of them, how could you since the package and class name would be the name?
Your way is cleaner, but it assumes nobody else in the world is ever going to create a package called gfx, which is a pretty weak assumption. By prepending your reversed domain name, you create a unique namespace that avoids collisions.
This fits perfectly with the "culture of sharing" that pervades Java programming, in which applications typically combine large libraries from many sources.
In Java, the convention is to name your packages (which correspond to the folder structure containing your code) with information identifying your organization (typically including a TLD and the company name) and project (which might add a few more sections).
Being more specific like this also reduces the likelihood of namespaces accidentally colliding with eachother.
It's merely an organizational technique for preventing namespace conflicts. Nothing more or less. Java package names match the underlying directory structure, so any organizational pattern at the package level will be reflected there. It's typical for teams to start their package names with their organization's name and wax specific. This is simply convention, but it's ingrained and should be followed absent a very good reason.
It's all about Namespaces. With 'Namespaces', you can create 2 classes with the same name, located in different packages/folders. This Namespace logic can also be used for creating 'Access Privileges', etc etc. Below are some links:
1) Namespace
2) Java Package
3) Java Package Naming Conventions
EDIT: Let us assume that you are creating a new project and are using 2 open source frameworks from companies/organizations - comA and comB. Also, let us assume that comA and comB have created a class in their projects with the same classname. Now, with the Java package naming conventions, we have com.comA.SomeClass and com.comB.SomeClass. You can import and use both the classes in your class, without having a conflict. This is just a simple example. There are other uses from this naming convention.
If you want to share code with everyone else, but use generic names without conflict. its considered good practice to include you domain name (backwards)
Everyone write a package called gfx.Font you wouldn't be able to use more than one version in the same application.
You might feel your code will not be shared with the world (or even should not be shared) In which case, a shorted package structure may be simpler.
If you use an IDE, it does a good job of hiding long package structures so you don't need to worry about it.
This is due to recommended packaging structure. In large projects, so many packages/libraries are used and in order not to put source files into same folder with another library, programmers put their source codes into unique folders. As websites are unique, it is a convention to use packaging structure that looks like folder structure of websites.
Java does not require anything: you can just put all your classes in the default package and surf away. But for serious projects that kind of organization is not only wise, it's mandatory. The com.mojang.ld22 part is just a convention:
com = either this or org, java/javax for official packages
mojang = second part is company name
ld22 = third part is application name
Okay, so I'm wanting tips on how to pick a name for my Java packages.
I saw this post: What package naming convention do you use for personal/hobby projects in Java? but this talks about personal projects.
What if for example I wanted to make an API Wrapper, and I develop with others on GitHub? I don't have a domain name.
The domain-name-backwards convention is there to prevent name collisions. Two different companies with the same product name will have different namespaces so everything works fine.
If you don't have a domain then you need to choose a name that is meaningful to you and will not collide with anything else. That's OK; it just means very slightly more work for you to make sure that there isn't an existing product with the name you want, and there may be difficulties if there ever is a name collision.
You won't be the first to do this: the JMockit library is all in the "mockit" namespace with no "com" or "org" prefix.
The recommendation has always been to start with your domain name backwards, then the project name, e.g. com.mycompany.myproject, and continue on with submodules as necessary.
I have a hobby opne source Java project hosted at google code (linkset).
May I use a prefix "com.google.code.linkset" as a package name for this project?
P.S.
I dont own "org.linkset" domain :( but i like the name :)
the name of your packages does not have to reflect the domain it's hosted at.
I think using com.google prefix will mislead your users into thinking the code was developed at google. don't do it unless you want to handle the backfire from your users when they realize it's not.
Since it would be misleading as Omry already mentioned, why not use org.lbownik.util.linkset?
You can use pretty much anything as a package name, provided that it respects the java spec (no keywords, not starting with a number ...)
But really you shouldn't unless you work at Google!
If you name your package com.google.code.linkset it is possible that sometime in the future you will receive a "cease and desist" letter from Google's lawyers, citing your package name as infringing Google's registered trademarks.
EDIT
If you ever do receive such a letter, do not ignore it based on some amateur legal theorizing you read on some website. If you want to resist the demand, you should first talk to a professional lawyer.
I think using com.google in your domain is a mistake, since it will imply that your project is owned/endorsed by Google. However, people have been using net.sourceforge in their Sourceforge-based projects for years, and this is really the same thing. I didn't think that was a good idea, either. So while you can use com.google in your domain, I think it's a bad idea and you should use something else.
If you don't have a somewhat authorative domain-like name for the project, use something that obviously recognizable as not a reversed domain!
Technically, you should be able to use:
hobby.code.linkset
Have a look for example at junit and antlr. It's preferred to use a true hierarchical organization, but for a small hobby project you can start with a name such as this. You should be prepared to later on refactor your code to a real domain, once you have settled and the project grows.
I'm just coming up the learning curve for Java SE & have no problem with the usual Java convention for package names, e.g. com.example.library_name_here.package_name_here
Except.
I've been noticing a failure to abide by this in some fairly well-known packages.
JLine: jline.*
JACOB: com.jacob.* (there is no jacob.com)
JNA: com.sun.jna.* (disclaimer on the site says NOTE: Sun is not sponsoring this project, even though the package name (com.sun.jna) might imply otherwise.)
So I'm wondering, are there instances where the usual reverse-domain-name convention breaks down, and there are good ways to get around it? The only cases I can think of revolve around domain-name ownership issues (e.g. you change the project hosting/domain name, or there's already a well-known package that has "squatter's rights" to your domain, or your ownership of the domain runs out & someone else snaps it up).
edit: if I use my company's domain name, and we are bought out or have a spin-off, what should we do with package names? keep them the same or rename? (I suppose renaming is bad from the point of view that compiled classes referring to the package then lose)
It's a naming convention. There's no real requirement or even expectation that the package name maps to a domain name.
The general idea is that two organizations would not own the same domain, so using the domain name as part of the package ensures that there are no namespace clashes. This is only a recommendation however.
There is a good reason for someone to have packages in the sun namespace. If they are providing an implementation of a public API, it's often necessary to implement the classes in the API's namespace.
If you're making your way up the Java learning curve, I would worry more about making your packaging structure clear so you can easily find the class you are looking for.
Packages are used to avoid ambiguity and collisions between components built by various entities. As long as you follow the convention, and nobody illicitly uses your slice of the package namespace pie, you shouldn't need to worry about what others have used.
The only thing that matters (IMHO) is that the parts of the package name are “sorted” by importance, i.e. that you don’t end up with gui.myprog, util.myprog, main.myprog but with myprog.gui, myprog.util, and myprog.main. Whether the package name really begins with a top-level domain followed by a domain name is of no concern to me.
You can't use language keywords as parts of a package name, that's another case where the domain name convention cannot be applied - tough luck for LONG Building Technologies
But then, the convention is just that, a convention, and pretty much the only reason why it exists is that it minimizes the chance of different projects accidentally choosing the same package name. If you can't follow it, it's not really a big problem.