Possible to disable keyword checking in package names

My domain name ends with a in . So all my package names start with a in. Thus all my API users have to do an import like import `in`.foo.bar instead of import in.foo.bar. It is also a bit annoying to have to type the same way every time I declare a new package.

I presume this is because “in” is a keyword. I could be wrong.

Would it be feasible to make package names like in.foo.bar legal rather than having developers to write import `in`.foo.bar ?

Edit: Multiple edits to fix back quote visibility in html

1 Like

It’s an interesting idea: we could, in principle, allow unescaped keywords in package declarations and imports, but require escaping when they are used in expressions. Not sure how difficult this is technically.

Meanwhile, I hope that your users rely on the IDE for auto-adding imports to their code, so they don’t have to actually type the escaped names.

With auto import it works but you still have to explain them why they need to see these different characters for my packages only but not for other packages (more so because the same issue does not happen with java code as opposed to kotlin code)

1 Like

This is definitely a problem for those having “.in” (India) domain. I guess, the problem is still not as simple to solve as it seems either :slight_smile: An ugly hack could be starting the domain with an underscore (_in.example…). I would prefer it to using back-quotes.

Possibly unpopular opinion: why do you have to use your domain exactly?

I know it’s a Java standard, but on the other hand you just put india.whatever.... there wouldn’t be any difference.

I ran into this issue as well.

My use case was when generating code. I wanted to place code into packages based on metadata of json I was parsing.

For data I was parsing, Ansible module metadata, I wanted to structure the code into packages in a way that would match up with how Ansible structured the modules. However, that lead to packages with keywords that needed to be altered or escaped.

I was generating the code via text templating so I had to implement filtering on the problematic words for each case. A code generation library would have made this easier but I’d still have to choose between altering and escaping the package names. The problematic package names were pretty core functions for users and whichever alterations I made would be baked into the public API.

Had I been able to use keywords in package names, then I could have kept my preference of using the generated packages which matched my source material.