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.
Related
I was working with Typescript and Javascript and I stopped for a bit thinking about namespaces and how we organize code in Java.
Now, pretty often I see multiple classes with the same purpose, just for use with different data, being placed in different packages with different names.
While placing those classes in different packages is a good practice to maintain the project/module in a good state, why would we have to give them different names? I mean, their purpose is the same.
I can answer this question myself: because often we use those classes inside the same unit and they would clash, thus requiring a long full package specification for one or the other.
But aren't we violating the DRY principle? We should use our directory (package) structure to understand in which domain space those classes works.
As I wrote above, I suppose many developers aren't respecting this DRY principle just to avoid long package names. Then, why are we creating those monstruos package hierarchies?
Googling "Java packages best practices" results in suggestions such as:
com.mycompany.myproduct.[...]
Where do those suggestions come from? Aren't we just wasting space?
We obviously do not want to write that every time.
MyClass myInstance;
com.mycompany.myproduct.mypackage.MyClass myOtherInstance;
But it could have been
myfeature.MyClass myInstance
myotherfeature.MyClass myInstance;
We could even specify the full package for both.
So, where do those best practices come from?
As it has been said, this convention dates back to the first releases of Java.
Name clashes could be easily solved by qualifying the imported dependency (such as a classpath library) classes with their short packages' hierarchy, emphasizing and keeping cleaner our own code. It is also important to remember we have access to the package-level visibility, which seems overlooked nowdays.
As a commenter points out, this convention was established at the very beginning of Java, to allow a global namespace to be used for all classes.
One thing about Java that influences this -- and is different from TypeScript and JavaScript -- the name of a class and its package (as well as all the names of classes and packages it uses) is fixed at compile time. You can't recombine classes into a different hierarchy without modifying their source code. So it's not as flexible as an interpreted language where you can just move the hierarchy around and change the locations from which you load code.
You can, of course, put everything in your application in the top-level package, for example, and be pretty confident you'll get away with it. You'll be able to do that as long as everyone else follows the existing convention. Once they stop doing that, and libraries start putting classes wherever they want, you'll have collisions, and you'll have to change your application. Or libraries will start colliding with each other, and if you don't have the source, you won't really be able to fix it.
So there are good reasons.
My opinion-based part of this -- sticking with conventions and a language's (or platform's) culture makes sense. Even if the conventions are silly, in our view. There's a place for breaking them but the advantages have to be pretty big. Other developers will be used to the convention, tools will make assumptions about the conventions ... usually it makes sense to go with the flow.
Does it really make sense to use getters and setters for every property in Java? If you understand the domain you're using well, it very well might not. But stop doing it and your code isn't going to make sense to other members of your team, you'll have to continuously revisit the decision as people join, and so forth.
If it's a one-person project and always will be, of course, you can do what you want.
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.
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.