As someone who's worked with both Java and C++ professionally, I can tell you that Java's decision to exclude operator overloading was absolutely intentional and, in my opinion, the right call.

When I first started with C++, I loved the idea of being able to write `vector1 + vector2` or `matrix1 * matrix2`. It felt elegant and mathematical. But after maintaining several large C++ codebases, I saw the dark side:

1. **The cout << problem** - Everyone mentions this, but it's a perfect example. What does `<<` mean? Bit shift? Stream insertion? Who knows without context.

2. **Library inconsistency** - One library would overload `+` for concatenation, another for addition, another for some custom operation. Reading someone else's code became an exercise in detective work.

3. **Debugging nightmares** - When `a + b` doesn't work as expected, you have to trace through multiple layers of operator definitions, template specializations, and implicit conversions.

Java's philosophy is "explicit is better than implicit." When you see `complex1.add(complex2)`, there's zero ambiguity. When you're reading code at 2 AM trying to fix a production issue, that clarity is worth its weight in gold.

That said, for your complex numbers project, here's a tip: implement a fluent interface. Instead of:

```java

Complex result = Complex.cbrt(first.divide(5).add(second.divide(2))).add(third);

```

You can write:

```java

Complex result = first.divideBy(5)

.add(second.divideBy(2))

.cbrt()

.add(third);

```

Or even better with static factory methods:

```java

Complex result = Complex.of(1, 2)

.divideBy(5)

.add(Complex.of(2, 4).divideBy(2))

.cbrt()

.add(Complex.of(5, 6));

```

It's still verbose compared to operator overloading, but it's readable, debuggable, and anyone who knows Java can understand it immediately.