> > See http://mindprod.com/jgloss/import.html
>
[quoted text clipped - 21 lines]
>
> For example, this thread is at GG at
http://groups.google.com/group/comp.lang.java.programmer/browse_thread/threa
d/18b10e6375d30558/8baef761725d7b9c#8baef761725d7b9c
> which gives a TinyURL of
>
[quoted text clipped - 13 lines]
> different thread at the same GG URL posted above rather than it always
> linking to either this thread or a 404 page.
Ok neither of you answered to my questions, but thanks.
Mark Space - 08 Jul 2007 02:44 GMT
>>> drop the static. You are doing an ordinary import.
> Ok neither of you answered to my questions, but thanks.
Actually I think he did.
Roedy Green - 09 Jul 2007 20:20 GMT
>Ok neither of you answered to my questions, but thanks.
That is no way to persuade people to spend more time working to help
you. I did answer your questions. You did not understand or perhaps
did not like the answers.
Simple ask a follow on question. There no need to flog your slaves for
failing to please your highness. You are not owed any answers.
You did not ask about package naming, and apparently you did not
follow the link from import to package.
See http://mindprod.com/jgloss/package.html
There is a very simple solution if the $8 a year is too onerous to get
you a domain.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Twisted - 10 Jul 2007 04:49 GMT
On Jul 9, 3:20 pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> There is a very simple solution if the $8 a year is too onerous to get
> you a domain.
$8 a year *in perpetuity*, or however long your code will be in use
(and y2k taught us that assuming it won't be in use for more than
forty years is foolhardy). The bigger risk isn't that you can't afford
it but that you'll forget to pay it and let the name lapse. Then
someone else grabs it. Then they release code of their own with
clashing names...
Arne Vajhøj - 11 Jul 2007 03:45 GMT
> On Jul 9, 3:20 pm, Roedy Green <see_webs...@mindprod.com.invalid>
> wrote:
[quoted text clipped - 7 lines]
> someone else grabs it. Then they release code of their own with
> clashing names...
probability(you forget to pay for the domain) *
probability(the other guy also write Java code) *
probability(your code and their code will be used together)
is not that frightening in my view.
Arne
> 3asyxw.thomas.projectname.module.Class
Eh. Identifiers starting with digits might be a problem. I suggest
amending this to always prepend an "a", whether or not the tinyurl
code starts with a digit, e.g.
a3asyxw.thomas.projectname.module.Class.
>> See http://mindprod.com/jgloss/import.html
>
> 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
> plan for!)
> 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
InterNIC.
> 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
[quoted text clipped - 4 lines]
> 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
peacefully.
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.,
package person.doe.john.q.genies.lamp;
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.

Signature
Lew