Registering project names on


For us old folks who actually like the domain name as package space, what about keeping a database of packages at so we could use that:


This gives a pretty short name, that is still namespaced in a way that avoids collisions*

  • note, sadly scala-lang has a - which is not legal, so perhaps someone could have org.scala_lang in the future.


How should that work? Some web interface where you can claim a name? Should that come with publishing rights on Sonatype somehow?


Hey @oscar, good to see you around!

I didn’t understand your suggestion. Do you want to be able to register names on the Scala namespace? If so, what’s the reason?


@jvican To make package names globally unique on the JVM and prevent accidental collisions, it’s recommended to start package names with (reversed) domain names—so that the DNS system functions as a global top-level registry. People used to actually stick to such rules, especially in Java and in Eclipse—and Eclipse seems big enough that you’d get actual problems otherwise.

So if Google creates JVM package, there’s no chance somebody outside Google also creates Somebody inside Google could, but it’s assumed an organization can prevent collisions internally—for instance via some sort of registry like @oscar suggests!

May I ask if this should be an optional Scala Platform benefit, or is this a derailing of the original proposal?


Yes, I am familiar with this. What I don’t understand is why Oscar wants to have access to the Scala namespace or a Scala-owned namespace for contributors. Can you elaborate @oscar?

This has been discussed in depth here:

You can read that thread for the context. To answer your question more directly, no @Blaisorblade, the Scala Platform won’t have a common namespace. :slight_smile:


I suffer at the office with java-orthodox package names like

Also, tabs instead of spaces. I recently joked that this is why our team works in different time zones separated by vast expanses of desert wasteland, to avoid interpersonal conflict.

Scala’s loosey-goosey package names, compilation units and file locations are not just hip style, they are an expression of true sanity, or at least says that this is something we shouldn’t drive ourselves crazy about.

I’d go for a “scalang” prefix to announce “I favor a scala API and probably you’ll never call me from java or groovy”.

Maybe lightbend could write a little sbt plugin that would consult a registry and then register my package name scalang.funstuff when I publish my “com.github.myname.funstuff” jar.

The contraction “scalang” sounds like a world word, and not just a west european word, and for that reason I’d favor its adoption for other purposes, too.


I really like scalang, but I see no reason why we should provide this namespace to open source developers. I hope Oscar elaborates on this point. On my side, I may even use it for the Scala Platform.


I think the issue is that getting a “real” domain to back a given package is potentially costly and a hassle to maintain. “” packages tend to be unstable while their ease of acquisition makes them increasingly common.

If scalang.* could be used for packages that meet a certain bar wrt. permanence it might help those packages to grow and stabilize.


A domain costs about $1 per month, and a single domain can be used to host all the projects you maintain. If you’re just using ownership to own a code namespace, the only maintenance required is to make the payments and keep your address updated—and nobody actually polices the latter.

There are doubtless some developers out there for whom $1 / month is hardship, but I don’t think that’s something for which people need to optimize, especially since there are a number of free alternatives already mentioned like io.github.