61–70 of 192 posts
Two main ones: Mockito is, IMHO, much nicer than jMock. And Immutability is good, but 'final' is... complicated. I find it's often over used by people who don't know why they're using it.
"If you're using Java 8, you can use the excellent new Optional type. If a value may or may not be present, wrap it in an Optional class like this" While I agree with most things, overuse of Optional like this is an antipattern IMO. Having done a lot of Java 8 development, I find Optional is best for return types, but otherwise forcing callers to wrap values in Optional is unnecessary as opposed to something like Sca…
Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.
IMHO Optional just feels like another typical Java dogmatic overabstractionism. "Null pointer exception? So what? Just catch it." Then again, I mostly use C/Asm.
95% agree with these opinions, but have a few disagreements, or perhaps the author had missed some great stuff. Two main ones: Mockito is, IMHO, much nicer than jMock. And Immutability is good, but 'final' is... complicated. I find it's often over used by people who don't know why they're using it.
Earlier quoted context omitted.
What a curious comment. The first portion of your diatribe disparages all java developers, but the latter part of it suggests that you're still working in java shop (perhaps in an ops capacity?) I'm wondering what you meant by JVM 8 because no such thing exists (unless you were talking about the JDK or the JRE.) You must have worked at some sweatshops to spout such biased vitriol.
Well, I was an English major, so I'm glad you were engaged by the "diatribe". And if you were unable to piece it together... and I kinda feel bad if you couldn't. I'm referring to Java 8 language features and OpenJDK 1.8. I get the feeling you knew that though and are being pedantic. You've succeeded though, because I responded. Sadly you missed the part where I said, "Not all Java devs obviously". I have read great…
Earlier quoted context omitted.
Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.
Despite what he says, I don't think Hoare actually invented the "null pointer", as address 0 for "not exists" or "end of list" was probably a common convention ever since linked structures existed and independently discovered by many others. (The other convention would be the all-bits-1 value, but I'd assume that testing for 0 was easier and thus more widely adopted. Also, "0 = nothing" makes great sense.) IMHO Optio…
I can see how a C/Asm programmer wouldn't like it though. Very different mindsets. :)
I've seen numerous posts lamenting the use of typical Java Beans. The problem with the struct approach is that numerous tooling / libraries expects beans with typical getter/setters - Jackson Json, Spring binding, etc. Yes it's possible with configurations and/or annotations to get around this, but IMO, saving a few lines of code in exchange for non-default behavior isn't a valid trade-off. Adding a dependency on Lom…
Another problem with struct approach is inconsistency. Sometimes you want a computed property and you use non-trivial getter. Sometimes you want to do some work in setter. And then client's code will look terrible: point.x * point.x + point.getY() * point.getY(). There are other problems: binary incompatibility; non-trivial refactoring when I need to introduce a getter or setter. Java really need lightweight property…
Some good suggestions in here and some very very bad ones. For example, using Optional as a member type, tuples etc.