Java's package identifiers doesn't work at all, since organizations are far more transient than code (Like, even Sun doesn't exist anymore). And even if my organization still exists, one would think I should be able to hand over code to someone else, without them having to claim that they're me.
For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree, just because you went through a rebranding or a merger.
> Java's package identifiers doesn't work at all, since organizations are far more transient than code (Like, even Sun doesn't exist anymore).
Seems to be working for multiple decades without issues ?. If an organization is acquired (like Sun), they still have access to their namespace. It doesn't magically go away.
> For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree..
This is just your opinion. Many people like this systematic nature of directory hierarchy for segregation. Also, you do not require to follow this source language convention in case you don't like it. It is only required that the compiled class be in a nested directory structure for class-loader pickup
Ie You can still you put custom_src/foo/MyClass.java with package com.bingo.tringo;, it’ll still compile, and Maven will output: target/classes/com/bingo/tringo/MyClass.class
> Seems to be working for multiple decades without issues?
I noted a pretty damn big issue that invalidates the whole idea that the domain is a stable identifier. It's a big problem in practice, even if you're happy with keeping the old domains you may want to transfer code to someone else without giving them your domain. The solution is apparently to pretend that the problem doesn't exist. Which may be fine for Java but shouldn't be a trap that other languages need to repeat.
To me it looks like there is an obvious solution: a package should be able to issue an update to change its name.
Something like
- maintainers of package com.foo.pkg want to transfer it to com.bar.pgk
- com.bar creates their own pgk clone and marks it as a successor to com.foo.pkg (with a specific version)
- com.foo.pkg pushes an update with that specific version marked as superseded by com.bar.pgk
- package managers warn users at update time that a change in namespace happened and ask for consent
This could be extended to multiple forks to let the user choose
I feel it would work fine
You can easily transfer code to someone else without giving them your domain. Nothing prevents another project from publishing your code into their published GAV. This is NOT Golang - the G in GAV is decoupled from the actual domain.
> The solution is apparently to pretend that the problem doesn't exist.
No, the problem really doesn't exist.