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.
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)
acceptsnull
as 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.