Revisiting absolute/relative paths

[Jorge Ortiz-3]

Hi all,

This came up on Twitter today, so I thought I'd re-beat a not-yet-dead horse.

Anyone with a non-trivial Scala code base and a non-trivial number of external dependencies has been bitten by Scala's relative paths.

In Lift's case, this happened when one of our dependencies (Specs) added a dependency (Textile-J) which lived in the "net.java" package. Adding this dependency meant code like the following:

  package net.liftweb
  import java.io.File

  ...

Would fail with:

  error: value io is not a member of package net.java

This was incredibly frustrating because we didn't cause the problem, there was no way to foresee it, and it affected pretty much every single Lift source file. To fix the problem, and preempt future problems of this kind, we _root_.ed every single statement which used an absolute path, including most imports. (The patches aren't pretty. Exhibit A: http://paste.pocoo.org/show/128668/, Exhibit B: http://paste.pocoo.org/show/128662/)

I made a stink about it on the mailing list at the time. The consensus was that it was a problem, and the most popular solution was to allow absolute imports of the form "import .java.io.File" (leading dot), in addition to the current form "import _root_.java.io.File". The leading dot is much more pleasing to the eye than the hideous _root_, but I think this approach is inadequate for the following reasons:

1) It only works well for import statements, but not for other statements that might require absolute paths. Consider the following code:

  val x = foo()
  .bar.baz()

Right now this parses as: val x = foo().bar.baz(). I've used this syntax extensively to break of long chains of method calls, like:

  list
    .map(...)
    .filter(...)
    .drop(...) etc

(I've used this syntax in the past. Now I prefer to wrap such statements in parentheses.)

If leading dots meant absolute paths for all statements, it would parse as: vall x = foo(); _root_.bar.baz();

This presents a dilemma between breaking non-trivial amounts of existing code and disallowing leading-dot absolute paths for non-import statements.

2) It still requires touching every source file. The above-linked patches would be slightly less hideous (with a . instead of a _root_.), but they'd be no less huge. Consistently maintaining this standard across a large codebase is painful, and the risks of ignoring rooted absolute paths are real. (As Lift saw, even a second-degree dependency can break large swaths of your code.)

Those are the reasons why I think the leading-dot proposal is inadequate. (That said, I still think it'd be an improvement over the current situation. At this point I'll take what I can get.) I'm interested in solutions that 1) work for both import and non-import statements, and 2) don't require touching every source file. I'd love to hear any proposals that address these two criteria. I'd like to outline one such proposal below.

Proposal:

All exisitng code has unchanged semantics.

For new code, suppose there is some new syntax to mark a package object as rooted. (This is NOT the proposed syntax. I deliberately don't want to propose any particular syntax.)

  ROOT package object net.liftweb { ... }

Now any code inside the "net.liftweb" package, compiled with the "net.liftweb" package object in the classpath, can only use relative paths for things also inside "net.liftweb". Stuff in, say, "net.java" would require an absolute path. Now the code:

  package net.liftweb
  import java.io.File

Does not give a compile error, because "java." refers to "_root_.java." rather than "_root_.net.java.". If there were a "java" package inside "net.liftweb" this would still be a problem, but that's within Lift's control rather than an artifact of including a dependency.

This works for both import and non-import statements, and avoids having to touch and maintain large numbers of source files. It still means Lift has to be careful about not using packages called "java", "scala", "com", "net", "org", etc., but that's much more manageable than having to _root_ every absolute path.

Thoughts?

--j

[David MacIver]

2009/7/15 Jorge Ortiz <jorge.ortiz@...>:
> Hi all,
>
> This came up on Twitter today, so I thought I'd re-beat a not-yet-dead
> horse.
>
> Anyone with a non-trivial Scala code base and a non-trivial number of
> external dependencies has been bitten by Scala's relative paths.

I don't believe this claim is true. At least not for interesting
values of "bitten". I've never had to spend more than about 5 minutes
at a time fixing issues caused by this, which puts it well under my
radar for significant problems. What you're describing is nearly the
single case where problems caused by this are actually non-trivial to
work around. Everything else can be dealt with by changing an import
or two.

I'd like to propose an alternative solution for this case: Don't use
the Java reverse domain name convention for packages. It's ugly and
useless in the first place, but it's also actively harmful in Scala
because it allows other people to accidentally insert packages into
your namespace like this. Rename net.liftweb to liftweb and your
problem essentially goes away because anyone putting a package into
liftweb is really likely to mean it (and if they don't there are
probably going to be even more clashes).

Admittedly this sort of rename is quite painful for end users because
all their imports get renamed. But conveniently this doesn't actually
affect people too much if they've made sensible use of relative
imports because they only imported net.liftweb once per file. :-)
Also, package objects might allow you to work around it if you can
define package aliases in them.

[Jorge Ortiz-3]

Your alternative is compelling, but it'd be a shame to have to insist on better package names, not because they're better, but because Scala is broken.

In any case, this alternative is not an option for Lift, at least for the foreseeable (backwards-compatible) future.

Given how prevalent this package naming convention is in Java-land, I'd love to hear from other people who've had problems with relative imports. Is not using Java's package naming convention an option?

--j

On Wed, Jul 15, 2009 at 1:14 AM, David MacIver <david.maciver@...> wrote:

2009/7/15 Jorge Ortiz <jorge.ortiz@...>:

> Hi all,
>
> This came up on Twitter today, so I thought I'd re-beat a not-yet-dead
> horse.
>
> Anyone with a non-trivial Scala code base and a non-trivial number of
> external dependencies has been bitten by Scala's relative paths.

I don't believe this claim is true. At least not for interesting
values of "bitten". I've never had to spend more than about 5 minutes
at a time fixing issues caused by this, which puts it well under my
radar for significant problems. What you're describing is nearly the
single case where problems caused by this are actually non-trivial to
work around. Everything else can be dealt with by changing an import
or two.

I'd like to propose an alternative solution for this case: Don't use
the Java reverse domain name convention for packages. It's ugly and
useless in the first place, but it's also actively harmful in Scala
because it allows other people to accidentally insert packages into
your namespace like this. Rename net.liftweb to liftweb and your
problem essentially goes away because anyone putting a package into
liftweb is really likely to mean it (and if they don't there are
probably going to be even more clashes).

Admittedly this sort of rename is quite painful for end users because
all their imports get renamed. But conveniently this doesn't actually
affect people too much if they've made sensible use of relative
imports because they only imported net.liftweb once per file. :-)
Also, package objects might allow you to work around it if you can
define package aliases in them.

[David MacIver]

2009/7/15 Jorge Ortiz <jorge.ortiz@...>:
> Your alternative is compelling, but it'd be a shame to have to insist on
> better package names, not because they're better, but because Scala is
> broken.

I disagree. It would be a shame to have to insist on dramatically
complicating or breaking entirely a working feature of Scala because
people are using a broken package naming convention.

People fixate on the issues with relative package imports because
they're unusual, but it's easy to forget the benefits when you're
doing so and they are many. You could retain some of them by saying in
various places "and this is how imports work in Scala UNLESS YOU'RE
IMPORTING A PACKAGE IN WHICH CASE IT DOES SOMETHING COMPLETELY
DIFFERENT", but you'd lose utility and gain surprising behaviour.

> In any case, this alternative is not an option for Lift, at least for the
> foreseeable (backwards-compatible) future.

Like I said in the comment about package objects, one may be able to
fix that problem. If you can do something like

package object net {
   val liftweb = _root_.liftweb
}

then imports to liftweb remain source compatible. I don't know if this
works, but it sure would be nice if it did. :-)

> Given how prevalent this package naming convention is in Java-land, I'd love
> to hear from other people who've had problems with relative imports.

Ultimately, Scala is going to have to grow up and develop its own
conventions in places. Clearly any conventions it arrives at are going
to be heavily Java inspired, but we need to figure out the cases where
Scala needs a different convention, or where a different convention
would be beneficial. This is very distinctly one of them in my
opinion.

> Is not
> using Java's package naming convention an option?

Even if it's not an option for old code, I would very strongly
recommend it as the default for new.

[David MacIver]

2009/7/15 David MacIver <david.maciver@...>:
> 2009/7/15 Jorge Ortiz <jorge.ortiz@...>:
>> Your alternative is compelling, but it'd be a shame to have to insist on
>> better package names, not because they're better, but because Scala is
>> broken.
>
> I disagree. It would be a shame to have to insist on dramatically
> complicating or breaking entirely a working feature of Scala because
> people are using a broken package naming convention.

Oh, I should have said:

I don't consider your proposal an instance of this. It's more targeted
at people suggesting package imports should not be relative, or should
be some bizarre mix of relative and absolute, etc.

I don't particularly agree with your proposal, but only because I
don't think it's a good idea to change the language to support what I
consider to be broken behaviour. It's certainly by far the most
appealing language level solution to the "problem" I've seen
suggested, and if there was a general consensus that it would be
really helpful I wouldn't argue against it.

[Miles Sabin]

On Wed, Jul 15, 2009 at 9:44 AM, David MacIver<david.maciver@...> wrote:
> I disagree. It would be a shame to have to insist on dramatically
> complicating or breaking entirely a working feature of Scala because
> people are using a broken package naming convention.

That's a very tendentious claim ;-)

In what way is the reverse domain name convention more broken than the
alternatives?

Cheers,


Miles

--
Miles Sabin
tel: [phone]
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[Ricky Clarkson]

Just to record my suggestion from the discussion in #scala:

import x._ should behave as it does today, importing everything from
the nearest thing called x.
import x.y should look in the nearest x for a member called y and
import that.  If it's not there, look in the next nearest x,
recursively.

Jorge said:

"It's problematic because adding classes ANYWHERE in your package
hierarchy might break some code in non-obvious ways.  It's too brittle
to rely on."

I agree, but think it is much less likely to be a problem than the
current situation.  Also, my suggestion does not break any existing
code and requires no changes to existing code to be useful.

2009/7/15 Jorge Ortiz <jorge.ortiz@...>:

> Hi all,
>
> This came up on Twitter today, so I thought I'd re-beat a not-yet-dead
> horse.
>
> Anyone with a non-trivial Scala code base and a non-trivial number of
> external dependencies has been bitten by Scala's relative paths.
>
> In Lift's case, this happened when one of our dependencies (Specs) added a
> dependency (Textile-J) which lived in the "net.java" package. Adding this
> dependency meant code like the following:
>
>   package net.liftweb
>   import java.io.File
>
>   ...
>
> Would fail with:
>
>   error: value io is not a member of package net.java
>
> This was incredibly frustrating because we didn't cause the problem, there
> was no way to foresee it, and it affected pretty much every single Lift
> source file. To fix the problem, and preempt future problems of this kind,
> we _root_.ed every single statement which used an absolute path, including
> most imports. (The patches aren't pretty. Exhibit A:
> http://paste.pocoo.org/show/128668/, Exhibit B:
> http://paste.pocoo.org/show/128662/)
>
> I made a stink about it on the mailing list at the time. The consensus was
> that it was a problem, and the most popular solution was to allow absolute
> imports of the form "import .java.io.File" (leading dot), in addition to the
> current form "import _root_.java.io.File". The leading dot is much more
> pleasing to the eye than the hideous _root_, but I think this approach is
> inadequate for the following reasons:
>
> 1) It only works well for import statements, but not for other statements
> that might require absolute paths. Consider the following code:
>
>   val x = foo()
>   .bar.baz()
>
> Right now this parses as: val x = foo().bar.baz(). I've used this syntax
> extensively to break of long chains of method calls, like:
>
>   list
>     .map(...)
>     .filter(...)
>     .drop(...) etc
>
> (I've used this syntax in the past. Now I prefer to wrap such statements in
> parentheses.)
>
> If leading dots meant absolute paths for all statements, it would parse as:
> vall x = foo(); _root_.bar.baz();
>
> This presents a dilemma between breaking non-trivial amounts of existing
> code and disallowing leading-dot absolute paths for non-import statements.
>
> 2) It still requires touching every source file. The above-linked patches
> would be slightly less hideous (with a . instead of a _root_.), but they'd
> be no less huge. Consistently maintaining this standard across a large
> codebase is painful, and the risks of ignoring rooted absolute paths are
> real. (As Lift saw, even a second-degree dependency can break large swaths
> of your code.)
>
> Those are the reasons why I think the leading-dot proposal is inadequate.
> (That said, I still think it'd be an improvement over the current situation.
> At this point I'll take what I can get.) I'm interested in solutions that 1)
> work for both import and non-import statements, and 2) don't require
> touching every source file. I'd love to hear any proposals that address
> these two criteria. I'd like to outline one such proposal below.
>
> Proposal:
>
> All exisitng code has unchanged semantics.
>
> For new code, suppose there is some new syntax to mark a package object as
> rooted. (This is NOT the proposed syntax. I deliberately don't want to
> propose any particular syntax.)
>
>   ROOT package object net.liftweb { ... }
>
> Now any code inside the "net.liftweb" package, compiled with the
> "net.liftweb" package object in the classpath, can only use relative paths
> for things also inside "net.liftweb". Stuff in, say, "net.java" would
> require an absolute path. Now the code:
>
>   package net.liftweb
>   import java.io.File
>
> Does not give a compile error, because "java." refers to "_root_.java."
> rather than "_root_.net.java.". If there were a "java" package inside
> "net.liftweb" this would still be a problem, but that's within Lift's
> control rather than an artifact of including a dependency.
>
> This works for both import and non-import statements, and avoids having to
> touch and maintain large numbers of source files. It still means Lift has to
> be careful about not using packages called "java", "scala", "com", "net",
> "org", etc., but that's much more manageable than having to _root_ every
> absolute path.
>
> Thoughts?
>
> --j
>

--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...

[David MacIver]

2009/7/15 Miles Sabin <miles@...>:
> On Wed, Jul 15, 2009 at 9:44 AM, David MacIver<david.maciver@...> wrote:
>> I disagree. It would be a shame to have to insist on dramatically
>> complicating or breaking entirely a working feature of Scala because
>> people are using a broken package naming convention.
>
> That's a very tendentious claim ;-)

that's a very requiringmetolookitupinthedictionary word. ;-)

>
> In what way is the reverse domain name convention more broken than the
> alternatives?

In exactly the way I said above: It makes it far too easy for other
people to accidentally inject packages into your namespace.

[Johannes Rudolph-2]

On Wed, Jul 15, 2009 at 1:08 PM, Miles Sabin<miles@...> wrote:
> On Wed, Jul 15, 2009 at 9:44 AM, David MacIver<david.maciver@...> wrote:
>> I disagree. It would be a shame to have to insist on dramatically
>> complicating or breaking entirely a working feature of Scala because
>> people are using a broken package naming convention.
>
> That's a very tendentious claim ;-)
>
> In what way is the reverse domain name convention more broken than the
> alternatives?
In Scala it is quantitatively more broken because using TLDs as first
part of the package name is much more probable to produce collisions
than anything longer than 3 characters. Qualitatively because there is
no obvious reason why a package has to belong to a DNS address or this
aside, why packages have to be grouped by country.

Reverse domain names make sense in the moment you actually e.g. use
DNS to check signatures against certificates published through DNS.

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[Miles Sabin]

On Wed, Jul 15, 2009 at 12:18 PM, David MacIver<david.maciver@...> wrote:
>> In what way is the reverse domain name convention more broken than the
>> alternatives?
>
> In exactly the way I said above: It makes it far too easy for other
> people to accidentally inject packages into your namespace.

No, it's the _combination_ of the reverse domain name conventions and
relative package names which is responsible for that.

Given that the reverse domain name convention has to stay for Java
compatibility, I'd rather see the relative import rules tweaked.

Cheers,


Miles

--
Miles Sabin
tel: [phone]
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[David MacIver]

2009/7/15 Miles Sabin <miles@...>:
> On Wed, Jul 15, 2009 at 12:18 PM, David MacIver<david.maciver@...> wrote:
>>> In what way is the reverse domain name convention more broken than the
>>> alternatives?
>>
>> In exactly the way I said above: It makes it far too easy for other
>> people to accidentally inject packages into your namespace.
>
> No, it's the _combination_ of the reverse domain name conventions and
> relative package names which is responsible for that.

Yes. The combination of a useful feature and a useless convention is
broken. I know which one I prefer.

> Given that the reverse domain name convention has to stay for Java
> compatibility, I'd rather see the relative import rules tweaked.

The problem with "tweaking" them is that you end up with import rules
which are less consistent and more confusing than the current ones, or
you lose useful behaviour. Basically you're asking to increase
confusion and/or reduce functionality in order to support a largely
useless convention.

[Miles Sabin]

On Wed, Jul 15, 2009 at 12:33 PM, David MacIver<david.maciver@...> wrote:
> The problem with "tweaking" them is that you end up with import rules
> which are less consistent and more confusing than the current ones, or
> you lose useful behaviour. Basically you're asking to increase
> confusion and/or reduce functionality in order to support a largely
> useless convention.

You seem to be having a Java-interoperability blindspot today ... the
Java convention is non-negotiable here.

Cheers,


Miles

--
Miles Sabin
tel: [phone]
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[David MacIver]

2009/7/15 Miles Sabin <miles@...>:
> On Wed, Jul 15, 2009 at 12:33 PM, David MacIver<david.maciver@...> wrote:
>> The problem with "tweaking" them is that you end up with import rules
>> which are less consistent and more confusing than the current ones, or
>> you lose useful behaviour. Basically you're asking to increase
>> confusion and/or reduce functionality in order to support a largely
>> useless convention.
>
> You seem to be having a Java-interoperability blindspot today ... the
> Java convention is non-negotiable here.

No it bloody well isn't.

Further, I'm sick and tired of this rule being inconsistently applied.
Why is this non-negotiable when e.g. generation of static methods is
left to languish? If Java interop is so vitally important why doesn't
Scala have raw types? Why are Scala arrays not covariant when Java
ones are? Everything's a trade off, and sometimes Java interop gets
sacrificed a bit for the sake of sane language design.

A bit of extra inconvenience at the interop point is a fact of life.
No one's suggesting forbidding the import of domain name packages,
just that by not using it in your Scala code you can make your life
dramatically easier and that breaking good features for the sake of
people who can't be bothered to do that is madness.

[Miles Sabin]

On Wed, Jul 15, 2009 at 12:40 PM, David MacIver<david.maciver@...> wrote:
>> You seem to be having a Java-interoperability blindspot today ... the
>> Java convention is non-negotiable here.
>
> No it bloody well isn't.

Says you ;-)

<snip/>

> A bit of extra inconvenience at the interop point is a fact of life.
> No one's suggesting forbidding the import of domain name packages,
> just that by not using it in your Scala code you can make your life
> dramatically easier and that breaking good features for the sake of
> people who can't be bothered to do that is madness.

Actually, I'm not even sure I understand how the your alternative is
supposed to work. You suggested renaming "net.liftweb" to "liftweb",
so are you proposing abandoning heirarchy altogether? Ie.

  net.liftweb      => liftweb
  net.liftweb.util => liftweb_util

Or is it just the unfortunately-common-in-non-root-positions "net" TLD
you want to avoid?

Cheers,


Miles

--
Miles Sabin
tel: [phone]
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[David MacIver]

2009/7/15 Miles Sabin <miles@...>:
> On Wed, Jul 15, 2009 at 12:40 PM, David MacIver<david.maciver@...> wrote:
>>> You seem to be having a Java-interoperability blindspot today ... the
>>> Java convention is non-negotiable here.
>>
>> No it bloody well isn't.
>
> Says you ;-)

Well, if we're going to let the argument descend to that level, so's your mom.

>> A bit of extra inconvenience at the interop point is a fact of life.
>> No one's suggesting forbidding the import of domain name packages,
>> just that by not using it in your Scala code you can make your life
>> dramatically easier and that breaking good features for the sake of
>> people who can't be bothered to do that is madness.
>
> Actually, I'm not even sure I understand how the your alternative is
> supposed to work. You suggested renaming "net.liftweb" to "liftweb",
> so are you proposing abandoning heirarchy altogether? Ie.
>
>  net.liftweb      => liftweb
>  net.liftweb.util => liftweb_util
>
> Or is it just the unfortunately-common-in-non-root-positions "net" TLD
> you want to avoid?

The latter. I'm not suggesting removing uses of hierarchical packages
(if we had to do that then clearly something *would* be amiss), I'm
suggesting ensuring your root package name is unique.

[Florian Hars-3]

Johannes Rudolph schrieb:
> Qualitatively because there is no obvious reason why a package has to
> belong to a DNS address

Uniqueness. You can name your classes any way you want without any fear
of name clashes if your package name corresponds to a (sub)domain you
control. Things like org.specs._ are inexcusable, though.

- Florian.

[Miles Sabin]

On Wed, Jul 15, 2009 at 12:56 PM, David MacIver<david.maciver@...> wrote:
>> Or is it just the unfortunately-common-in-non-root-positions "net" TLD
>> you want to avoid?
>
> The latter. I'm not suggesting removing uses of hierarchical packages
> (if we had to do that then clearly something *would* be amiss), I'm
> suggesting ensuring your root package name is unique.

Wow, so lets re-reinvent the global namespace registry (again ;-).

Piggy-backing on DNS is a no-brainer here ... what do you suggest instead?

Cheers,


Miles

--
Miles Sabin
tel: [phone]
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[David MacIver]

2009/7/15 Miles Sabin <miles@...>:
> On Wed, Jul 15, 2009 at 9:44 AM, David MacIver<david.maciver@...> wrote:
>> You could retain some of them by saying in
>> various places "and this is how imports work in Scala UNLESS YOU'RE
>> IMPORTING A PACKAGE IN WHICH CASE IT DOES SOMETHING COMPLETELY
>> DIFFERENT"
>
> I think you're exaggerating the difficulties here.

I think I'm not. Packages currently scope and import exactly like any
other identifier. What you are proposing is equivalent to one of:

a) Packages should scope and import differently from other identifiers
b) Scala should not have lexical scoping

I am being charitable and assuming that you would prefer a to b.

[Miles Sabin]

On Wed, Jul 15, 2009 at 1:06 PM, David MacIver<david.maciver@...> wrote:

> 2009/7/15 Miles Sabin <miles@...>:
>> On Wed, Jul 15, 2009 at 12:56 PM, David MacIver<david.maciver@...> wrote:
>>>> Or is it just the unfortunately-common-in-non-root-positions "net" TLD
>>>> you want to avoid?
>>>
>>> The latter. I'm not suggesting removing uses of hierarchical packages
>>> (if we had to do that then clearly something *would* be amiss), I'm
>>> suggesting ensuring your root package name is unique.
>>
>> Wow, so lets re-reinvent the global namespace registry (again ;-).
>>
>> Piggy-backing on DNS is a no-brainer here ... what do you suggest instead?
>
> Project names, as with the vast majority of other languages out there.
>
> It's not like there are multiple liftwebs, or sbinarys,

Project name clashes happen all the time (remember, name clashes can
happen between non-public projects as well as public ones).

> and it's certainly not like adding a net. or a com. to the beginnings of
> them would make it less confusing or problematic if there were.

Ownership of domain names can be confusing and problematic, but that's
someone else's problem ... which is a Good Thing.

> There's no enforcement of (and indeed often no correspondence with)
> sites and package names anyway, so using DNS hardly guaratnees one is
> free of problems.

I don't believe this has ever been a problem in the Java world ... can
you point to a non-hypothetical  example?

> Further, attempting to enforce such is particularly
> annoying for open source code. projects start off life on some open
> source code hosting  and then move elsewhere (I'm sure as hell not
> moving sbinary to a com.github.sbinary package now that it's in
> github). Do you really want to suggest that they should register their
> own domain name for the project from the word go, or that they should
> be piggy backing off the domain name of the origin?

If they're publishing a significant public project, then yes, they
should register a domain name or use an umbrella. Most projects do one
or the other. If it's not a significant public project then renaming
packages doesn't matter.

--
Miles Sabin
tel: [phone]
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[David MacIver]

2009/7/15 Miles Sabin <miles@...>:

> On Wed, Jul 15, 2009 at 1:06 PM, David MacIver<david.maciver@...> wrote:
>> 2009/7/15 Miles Sabin <miles@...>:
>>> On Wed, Jul 15, 2009 at 12:56 PM, David MacIver<david.maciver@...> wrote:
>>>>> Or is it just the unfortunately-common-in-non-root-positions "net" TLD
>>>>> you want to avoid?
>>>>
>>>> The latter. I'm not suggesting removing uses of hierarchical packages
>>>> (if we had to do that then clearly something *would* be amiss), I'm
>>>> suggesting ensuring your root package name is unique.
>>>
>>> Wow, so lets re-reinvent the global namespace registry (again ;-).
>>>
>>> Piggy-backing on DNS is a no-brainer here ... what do you suggest instead?
>>
>> Project names, as with the vast majority of other languages out there.
>>
>> It's not like there are multiple liftwebs, or sbinarys,
>
> Project name clashes happen all the time (remember, name clashes can
> happen between non-public projects as well as public ones).

private projects can take a public top level which is not likely to clash.

mycompany.ourproject

is vulnerable to injections from elsewhere in mycompany, but not from
joe random out on the net.

>> and it's certainly not like adding a net. or a com. to the beginnings of
>> them would make it less confusing or problematic if there were.
>
> Ownership of domain names can be confusing and problematic, but that's
> someone else's problem ... which is a Good Thing.
>
>> There's no enforcement of (and indeed often no correspondence with)
>> sites and package names anyway, so using DNS hardly guaratnees one is
>> free of problems.
>
> I don't believe this has ever been a problem in the Java world ... can

I don't believe that you don't believe it. Or at least I find it
highly surprising.

> you point to a non-hypothetical  example?

hibernate used to be net.sf.hibernate and is now org.hibernate. I'd
have to dredge through my memory more than I care to do at the minute,
but I've definitely run into this four or five times where a project
has moved off sourceforge and either retained its net.sf packages
(thus leaving packages pointing at a stale project) or changed their
name (thus leaving a trail of broken examples and stale
documentation).

>> Further, attempting to enforce such is particularly
>> annoying for open source code. projects start off life on some open
>> source code hosting  and then move elsewhere (I'm sure as hell not
>> moving sbinary to a com.github.sbinary package now that it's in
>> github). Do you really want to suggest that they should register their
>> own domain name for the project from the word go, or that they should
>> be piggy backing off the domain name of the origin?
>
> If they're publishing a significant public project, then yes, they
> should register a domain name or use an umbrella. Most projects do one
> or the other. If it's not a significant public project then renaming
> packages doesn't matter.

You seem to be acting as if this is the only reasonable behaviour.
This is perplexing. It's behaviour that is almost unique to Java -
basically every other language gets away without doing it and somehow
their packaging system hasn't come tumbling down around their ears.