Re: a few beginners questions ....
Roedy Green wrote:
Bleh, another page that assumes that everyone owns their own domain
name (and can afford to keep it in perpetuity, for as long as their
I don't see that assumption embodied anywhere on that link.
Java code will be in service, and remember the lesson learned in the
y2k crisis -- that is always a lot longer than you think it will be or
I have an interesting suggestion for getting unique package names that
is free, and just as sure to avoid name clashes, and only depends on
one web site with proven staying power sticking around.
"Proven"? Now you are assuming that tinurl will be around in perpetuity,
which in light of the Y2K+1 "crisis" may not be safe.
If you have your own domain and are fairly sure nobody else will have
it decades from now go ahead and use Sun's suggested naming
convention. Otherwise (and this shouldn't clash with it) find a page
Key words being "suggested" and "convention". In point of fact, the
convention allows you to make up your own package "domains" and does not in
any way require that you actually possess that domain, e.g., registered with
on the web that is "yours", e.g. a forum thread you started, your
profile on a forum site, the page at Google Groups with the first post
of a Usenet thread you started, etc.; and feed its URL to http://tinyurl.com
to get a TinyURL linking to it. Remember it links to a page that is in
some way YOURS. Now just start your package name with the gobbledygook
at the end of your TinyURL, after the last slash in the TinyURL. It
should be unique and stay that way, and it's very unlikely to be
"com", "org", or some other TLD.
This is a very good suggestion, if you feel the need to tie your fake "domain"
with something in the outside world, often a good idea.
and avoid clashing with anyone else who uses either this method or the
"official" method for picking package names, since http://tinyurl.com/3asyxw
It's "official" as a suggestion, not a mandate, and obviously only for those
who actually do have some assurance that they can keep their domain for a
while, as, say, companies like IBM or Oracle, or organizations like PostgreSQL
have. There is no real requirement that your packages' "domains" actually
correspond to real domains - a point in favor of your tinyurl trick. Sun
suggests their suggestion just as a way of getting a likely unique package
name, which is the real goal.
Consider - if Oracle Corp. somehow lost the "oracle.com" domain, how much real
additional difficulty will new packages in the "com.oracle.*" patterns cause?
Likely not too very much - most folks using "old" com.oracle packages will
not upgrade to newer ones, and most folks using newer ones likely will not
want the old ones.
Also, it's a practical convention - anyone is permitted to write
"com.oracle.*" packages, but it isn't in our interest usually to create such
name conflicts. The idea is to allow packages from many places to coexist
The tinyurl trick is a clever way to get such unique names. So is using a
package scheme based on your own name or other unlikely string, e.g.,
Even if others use a similar top-level package hierarchy, chances are good the
specific packages won't collide. It's not as clean or objective or (for now)
reliable as the tinyurl trick, though.