Why can't I just write obj.name instead of obj.getName()
You can, simply make name public. In many cases they are POJOs and encapsulation is not needed. It's more a problem of the frameworks that require them to be beans (have a getter and a setter). Hibernate for instance.
the infamous XYUtils classes
I agree that the syntax is not optimal, but the goal of this classes is to allow NULL therefore you can't use instance methods (many of them already exist in the Java API by the way). They must be static and take the string, collection ... as a parameter.
The almighty dispatch
Perhaps instead of overloading print you should use polymorphism and move the print method to the corresponding classes (defining a Printable interface to make it better) Seems more natural.
First of all, Java is fine as-is. We are talking mostly about "quality of life" enhancements here. Of course you can work without them, countless successful Java projects show that.
Public properties: if I find a junior developer doing that at our company, I'll have a serious word with them. I'm absolutely not willing, under no circumstances, to give up on accessor methods. That point isn't debatable for me. However, I see nothing wrong with some syntactic sugar on the caller side.
Extension methods: I think there's a misunderstanding here. Using a static util method in an extension-like fashion does not change its semantics, at all. If myStringUtilFunction(s)accepts null as its parameter, you can write null.myStringUtilFunction() and it will run just fine. It may look awkward (and nobody would do that), but the result is the same as when calling it the old-fashioned way.
Dispatch: I agree, in some cases you can use polymorphism to avoid the issue alltogether. And I think that if you can, by all means do it. But there are cases where code like in the example I outlined is unavoidable. Sometimes you need to separate the algorithm from the objects it runs on. You can work around it by implementing a full-blown variant of the visitor pattern (which really is nothing else than a double dispatch in fancy disguise), but that's a lot of code and a lot of chances for bugs to creep in. I think it would be nice (and in particular it wouldn't hurt) to have this option in Java. If you have no use for it - that's perfectly fine, you could safely ignore it.
Public properties
Even when Sun defined core J2EE patterns (a couple of decades ago) recommended using public properties for transfer objects (aka DTOs) check this oracle.com/technetwork/java/transf... Maybe your junior dev read that !
I don't say it should be used blindly, but in this case IMHO is acceptable. In other cases (Hibernate for instance) is a requirement to implement lazy initialization.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why can't I just write obj.name instead of obj.getName()
You can, simply make name public. In many cases they are POJOs and encapsulation is not needed. It's more a problem of the frameworks that require them to be beans (have a getter and a setter). Hibernate for instance.
the infamous XYUtils classes
I agree that the syntax is not optimal, but the goal of this classes is to allow NULL therefore you can't use instance methods (many of them already exist in the Java API by the way). They must be static and take the string, collection ... as a parameter.
The almighty dispatch
Perhaps instead of overloading print you should use polymorphism and move the print method to the corresponding classes (defining a Printable interface to make it better) Seems more natural.
First of all, Java is fine as-is. We are talking mostly about "quality of life" enhancements here. Of course you can work without them, countless successful Java projects show that.
Public properties: if I find a junior developer doing that at our company, I'll have a serious word with them. I'm absolutely not willing, under no circumstances, to give up on accessor methods. That point isn't debatable for me. However, I see nothing wrong with some syntactic sugar on the caller side.
Extension methods: I think there's a misunderstanding here. Using a static util method in an extension-like fashion does not change its semantics, at all. If
myStringUtilFunction(s)acceptsnullas its parameter, you can writenull.myStringUtilFunction()and it will run just fine. It may look awkward (and nobody would do that), but the result is the same as when calling it the old-fashioned way.Dispatch: I agree, in some cases you can use polymorphism to avoid the issue alltogether. And I think that if you can, by all means do it. But there are cases where code like in the example I outlined is unavoidable. Sometimes you need to separate the algorithm from the objects it runs on. You can work around it by implementing a full-blown variant of the visitor pattern (which really is nothing else than a double dispatch in fancy disguise), but that's a lot of code and a lot of chances for bugs to creep in. I think it would be nice (and in particular it wouldn't hurt) to have this option in Java. If you have no use for it - that's perfectly fine, you could safely ignore it.
Public properties
Even when Sun defined core J2EE patterns (a couple of decades ago) recommended using public properties for transfer objects (aka DTOs) check this oracle.com/technetwork/java/transf... Maybe your junior dev read that !
I don't say it should be used blindly, but in this case IMHO is acceptable. In other cases (Hibernate for instance) is a requirement to implement lazy initialization.