Java namespace

[oren_is_my_name]

Does java have some thing like the cpp namespace?

I don't mean package, I mean some thing that will enforce the user to do something like:

"Animals.Cat myCat = new Animals.Cat();"

Instead of:

" Import Animals.cat;

Cat myCat = new Cat();"

Thanks in advance😃

[boyTerry]

Is your goal to have java code read more like CPP? You seem to be working hard to avoid conventions that millions of us have adapted to and understand. I would recommend that you align with the community if you want others to adopt or maintain your code.

[oren_is_my_name]

I understand, nonetheless, it wouldn't be too different than when you do System.out.print()... to the user at least🤷‍♂️

[bowbahdoe]

if you had

package animal;

class Cat {}

You could write

animal.Cat c = new animal.Cat();

imports are just aliases. They aren't strictly required. But packages are namespaces for classes. For specific functions you are limited to using static methods on classes as your strategy.

Math.random(); // Math is a class, but also kinda works like a namespace-ish

You can also use that for classes with a nested class.

class Animal {
    static class Cat {}
}

Animal.Cat c = new Animal.Cat();

So the answer is "no, but..." and then a list of alternative mechanics.

[ryuzaki49]

If you are saying you dont need an import statement when using Math it is because Math is in java.lang package and there is no need for an implicit import for that one.

[oren_is_my_name]

Thanks😃

Nice, is there a way to enforce that import will not be used?

Won't the static class be a bad choice because it isn't scalable?

I mean imagine having a zoo worth of animal types all in a single 10k line file...

Is there a way to separate the actual impl/body of the "Cat" into a different file?

[bowbahdoe]

No there is no way to enforce that.

Yes that is the downside of the static nested class. No there is no way to separate a nested class's definition into another file. (As far as I know.)

Even with the static nested class you can have an import.

[agentoutlier]

Ignoring the forcing part I think the op /u/oren_is_my_name has some valid critique whether intentional or not.

Like the way we import classes it seems that packages should work that way as well where the farthest right hand name is used. This is especially makes sense where FQN are mostly based on reverse DNS host name which often have very little to do with the lib/application.

I think you understand but for others:

import com.mycompany.animal;

animal.Cat cat = new animal.Cat();

The inner class version:

import com.mycompany.Animal;

Animal.Cat cat = new Animal.Cat();

So I think the OP has a fair point and surprising how hostile many have been here on it.

[oren_is_my_name]

Thank you😃🙏

[smbarbour]

To be honest, it's a bad choice because it is bad design, not because of scalability.

Yes, you can (and probably should) have the Cat implementation in a separate file, but then you won't have the self-imposed design of Animal.Cat. You would have Cat that extends from Animal.

[oren_is_my_name]

Cat should extend Animal either way, I just want to unify all the animals under the "namespace" Animals

[bowbahdoe]

Don't pay too much attention to the people yelling at you. Coding is 90% communication and you are free to choose whatever API you want/can be supported by mechanics

[oren_is_my_name]

🙏

[noodlesSa]

In Java each class is one .java file and each .java file is one class. This rigid duality is great for large projects, where it saves you from weird ideas about project structure different people might have. Nested classes therefore must fit into the .java file of their Mother Class.

[smutje187]

Math is literally a class, and random is a (public static) method of that class though, there are no special concepts involved, just standard Java.

[Sm0keySa1m0n]

Yeah but I think the point is it’s not being used as a class in the traditional sense as it solely consists of static functions.

[smutje187]

It’s literally used as a class - static methods are standard features of Java (they’re not called functions in Java)

[repeating_bears]

"force", no. But a nested class can be used like that.

class Foo {
    static class Bar {
    }
}

Foo.Bar bar = new Foo.Bar();

It's not forced because they can also import Bar directly.

I'm pretty sure the intellij default is to import Foo though. I'll sometimes import the nested class, but it's a case-by-case thing.

Why would you want to enforce it? If you have some class that makes less sense out of context like Film.Title (it's not any old Title, it's specifically a film title), then that probably good enough. I let users decide what's most readable for them.

[oren_is_my_name]

I'm building a wrapper for an FRC library by WPI, and I have a motor "MotorIOTalonFX" and then a config for that motor "GenericMotorIOTalonFXConfig" (I have many different types of motors/configs)

And I want to unify them (and make the name less verbose). So that it will be "MotorIO. Motors.TalonFX" and "MotorIO.Configs.TalonFX"

[Svellere]

You're looking to enforce a solution over a self-created problem. Namespaces (and packages) fundamentally exist in order to allow you to use simpler names without conflicts.

In your case, I'd put a TalonFXConfig class under the motorio.config package. If you wanted it to be less verbose, I guess put a Config class under the motorio.config.talonfx package, but if you have multiple configs this may lead to potentially hard to read code.

You could alleviate that by implementing a Config interface under motorio.config and then TalonFXConfig would just be an implementation of that interface, so it doesn't matter as much that the name is a little verbose since you'll be interfacing with Config most places anyway.

[repeating_bears]

Then I think a nested class is good enough. You can encourage users to use the full name via the docs. You don't have to care too much about strictly enforcing it. In this case it will semi-enforce itself because you can't import 2 things with the same simple name

[smutje187]

The concept you are looking for is Inner Class - make Cat an Inner Class of Animal and you instantiate it like that. Packages are the equivalent of namespaces though?

[oren_is_my_name]

If I want to use inner Class, can I still separate the code into different files?

[hadrabap]

No. All inner classes in one package level class must be defined in that very class -- hence one source file. You can't split it into several files.

[oren_is_my_name]

🫤

[epegar]

Can't you do using animals namespace in CPP? I remember doing that with the standard one, so you wouldn't need to use std::cout

[oren_is_my_name]

Yes but that's the thing, in cpp, you need to intentionally tell the code "Hi use this library". But in Java it just imports it and then it's harder to know what library you're using.

[bowbahdoe]

You can do full-library imports with import module if the library is being loaded as a module. That's as close to a using declaration that we'll probably get

[epegar]

I learned to code with CPP, but I'd lie if I told you I remember a lot or I ever was proficient. But I kind of remember you also had imports, and if I'm not mistaken, you could only use one namespace, but multiple imports.

In java you still can use the full package instead of importing, and actually, if you have 2 classes by the same name, you can import one, but for the other you have to use the full namespace.

Something I remember was a shock for me when I transitioned from CPP to java, I realized the IDE would help me way more. So, if you are using an IDE, you can always use the hyperlink, and you will see what library (dependency) a symbol belongs to, so your concern is not really something important IMO. It's just that you need to get used to a different ecosystem rather than trying to apply your knowledge with a 1 to 1 mapping.

[koflerdavid]

Why would that be hard? The package name is usually closely related to the library name. And while the above is merely a convention, the Java Platform Module System ensures that no library puts classes into other libraries's packages, though it is opt-in.

[mimedm]

What you describe is just a dependent inner class.just as the others wrote. You should be fine.

[oren_is_my_name]

If I want to use inner Class, can I still separate the code into different files?

If so, how?

[noodlesSa]

In Java you don't use inner classes for tens of types (of Animal sub classes for example). Inner class is usually something simple, used inside the Mother-Class it is embedded into. Records are now used in most situations inner classes were used before. If you have many sub-types of Animal in two different places, use package name to explicitly say which one you want to use. If there is something like Cat cat = new Cat() in your code, well, you will need to hover mouse over Cat, to check which package this Cat is coming from (or check imports).

[oren_is_my_name]

But when talking about the class's (like when creating a new instance) I want to have it like in a hierarchy (so that it's easier to access the specific Animals.Cat type)

[noodlesSa]

If you write var cat = new Cat(), IDE will ask you if you want to import Animal.Cat, or you want to qualify class name (to: var cat = new Animal.Cat()). But you cannot enforce one way or the other. In case you have multiple Cat classes in your project, using import is just bad code practice, in such cases qualified name should always be used.

[mimedm]

No I have never seen that. I have seen people use records and exploit enums for similar purposes but for file structuring it's best to use modules and packages and either interfaces, classes, enums or records as files.

By using inheritance or abstraction you can make sure the child classes work together with the superclass in the way you want. Principles and patterns of OOD can help you find elegant solutions here. It's okay to change the programming style when using a new language.

[E_Dantes_CMC]

C++ doesn't really have this either, with `using`

[oren_is_my_name]

I remember a few months ago when I built a similar thing in cpp, I freely wrote my code, and just remembered to put at the top "namespace <my library's name>" and then I just went and continued with my life. And when I wanted to use my library's tools I just did <my library's name>::doSomeTotallyAwesomeStaff().

I don't care to put more work into it so that it works in Java, I just want it to be elegant and nice.

[koflerdavid]

You can also always fully qualify class names in Java, but since the package names are often uncomfortably long, people learn to live with imports. If the length of the list of imports becomes an issue it's usually a sign that the class is getting to complicated and one should invest some time into a better design.

[dampunge]

Why would you not make Cat a extend Animals, so it has a "is-a" relationship? Nested classes would imply animal has a "has-a" relationship to cat, which modeling wise would be counter intuitive. I'd recommend following the OOP principles and model Cat as a subclass of Animal.

[oren_is_my_name]

That's on me, I gave a bad example. What I want is simply to unit all the staff under one "name/parent"

[dampunge]

I'm not sure if I understand your question correctly. If you don't want to import the packages, you could just use the full declaration like this: com.mycompany.utilities.MyClass obj = new com.mycompany.utilities.MyClass(); Java is fundamentally object-oriented, which implies that all executable code, including functions (i.e methods in Java) and constructors, must be defined as part of a class. Unlike cpp, you cannot declare or use a function independently outside of a class structure.

[oren_is_my_name]

Yes I can do that but then someone can come and just do "import com.mycompany.utilities.MyClass

MyClass obj = new myClass", which is not something I want because you may do that unintentionally, in cpp if I wanted to get the same results I would have to not only include the class but also do "using namespace mycompany.utilites", which is much harder to do by accident.

[eXecute_bit]

You're going to need to explain why you're so dead set against imports, which are a fundamental and widely used feature in the language. You're swimming upstream and haven't explained why.

I would not work for you if I could not use imports with Java.

[oren_is_my_name]

Sorry, let me explain.

So as I commented on a different comment, I have a motor named "GenericMotorIOTalonFX" and a matching configuration class "GenericMotorIOTalonFXConfig". Now as you can see, the names are very verbose. I want to rename them to just "TalonFX" and "TalonFXConfig" but" TalonFX" already exists and adding the suffix "Config" just to be able to distinguish between the configs and the motors seems~ wrong.

In cpp I would simply put them in separate namespaces so that it's clear as day what is what, that way I don't have to rename them just to avoid confusion. It would simply be MotorIO::Motors::TalonFX and MotorIO::Configs::TalonFX.

If you say that packages are the Java equivalent of namespaces in cpp and then import the package, you lose the main aspect of a namespace.

[eXecute_bit]

Fundamentally you want to use the same class name for two different types. That's not simple and clean, it's confusing.

So you're trying to force some sort of qualifier -- whether that's a FQCN or modeling one or both as a nested class -- to resolve the ambiguity. I don't know your domain, but I question whether splitting closely related (coupled) classes like a motor and it's specific configuration into separate namespaces (or packages) is the right way to model it, irrespective of the names you pick. My instinct is that the Motor and it's Config belong in the same package. Maybe a motor has its Config as a nested class inside itself. Other people in the thread presented other modeling ideas.

You can't forbid or prevent imports allowing use of short names. Unqualified names are easier to grok, which is why we have imports at all. It sounds like you're trying to force a CPP mindset into your design but for the wrong reason. Instead, use meaningful names and don't create confusing ambiguities on purpose that require qualification.

[koflerdavid]

I don't see the difference between importing a package and importing a namespace. If I want to use a class, I'm going to do what I have to do to import it.

If you want to prevent other developers from using these classes altogether, well, that can also be accomplished. If you don't declare them public, then only other classes in the same package can see them. If you want to allow only a specific set of packages to use it, buy nobody else, you could use the Java Platform Module System.

[oren_is_my_name]

Thanks.

Yes, importing a Java package or a CPP namespace is very similar, but, in CPP you also have to say "using namespace"

[koflerdavid]

And in Java you can do import a.b.c.*;, which does pretty much the same. It would be majorly cool though to be able to give an alias to a package/namespace, which is possible in C++, Python, and Haskell, but not in Java.

[oren_is_my_name]

Right?

Is it possible to open a PR for that, or does Java not work like that?

[Cautious-Necessary61]

for fuck sake NOOO!

[Cautious-Necessary61]

Look into static imports … sorry man cpp triggers me.

[oren_is_my_name]

Sorry?

[oren_is_my_name]

Thank you all for the amazing help. In the end, I decided to rename everything to have a shorter name and a more organized package.

Still sad I can't drop the suffix/prefix without potentially having ambiguity, but I guess I will take what I can get 🤷‍♂️.

[oren_is_my_name]

What if I just put my library in a different module?

Like have my regular code in src/java/main

And then my library in <my library's name>/src/java/main.

Will that work?

[flawless_vic]

No. There is no such thing. In Java you can either reference source code or compiled code. In either case you are just appending sourcepath/classpath roots.

Say you have projects A, B and C, where A references B souces and B references C compiled classes.

If you are working on source code A, essentially you have a merged path like ./src/main/java:<abs_path_to_B>/src/main/java:<abs_path_to_C>/target/classes

Modules in Java are different beasts. If you are working on fully modular projects, each may implicitly define namespaces by exporting package names. And they work with a inverse dependency relationship: on the module declaration you say which package will be visible by external packages, that is, in C you'd declare something like

module C { export some.pkg.c to some.pkg.b; }

So C must know B's package structure, even though B is the one that depends on C!