If you really want to describe modern Java, you should probably mention RxJava and TestNG.
TestNG may have been considered a "modern" alternative years ago, but today jUnit4 has caught up with most (if not all) of testNG's features.
Better Java – Resources for Writing Modern Java
21–30 of 192 posts
Re: Better Java – Resources for Writing Modern Java
#22Dependency Injection (frameworks) -1 Use constructors. This makes perfectly testable classes and is vastly simpler than encouraging more XML as code. Any proper dependency injection framework should work quite well with regular constructors.
Your comment is unclear. Are you encouraging people to NOT use DI frameworks, or using them only with constructor-based injection?
Re: Better Java – Resources for Writing Modern Java
#23I'm surprised he didn't mention AutoValue [1] or Lombok (using @Data and @Builder) in his section about data objects and builders. I prefer AutoValue, but both approaches cut down on a lot of the boilerplate (and they also generate sensible equals(), hashCode(), toString(), etc).
It's also kind of a nitpick, but I disagree with his preference for Guava's Maps.newHashMap() vs new HashMap(). I'm pretty sure the only reason those static methods exist is because pre-Java 7 didn't have the diamond operator.
Re: Better Java – Resources for Writing Modern Java
#24Dependency Injection (frameworks) -1 Use constructors. This makes perfectly testable classes and is vastly simpler than encouraging more XML as code. Any proper dependency injection framework should work quite well with regular constructors.
Constructors have their problems. First: constructor calling is not readable because Java misses named parameters. It's fine when there are 2-3 dependencies, but not more. Second: circular dependency is not possible. So I prefer to use setter dependencies, as they don't have those problems.
Re: Better Java – Resources for Writing Modern Java
#25There is some good stuff in here, and a lot of bad.
SparkJava (mentioned) is the great hope for sane java web development:
Having to convert out to streams for data structure manipulation with lambdas is insane. It would have been very healthy for the core java team to pull in someone with a lot of ruby experience so they could get that API right.
Too bad: the JVM and associated tools are fantastic.
Re: Better Java – Resources for Writing Modern Java
#26I'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 syntax which would solve all those problems. I don't understand why it isn't introduced yet.
Re: Better Java – Resources for Writing Modern Java
#27"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…
I'm curious, which aspects of An Opinionated Guide to Modern Java have dated?
Re: Better Java – Resources for Writing Modern Java
#28"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…
I'm also not a fan of passing Optionals into methods. Most of the time it's easier and cleaner just to write an additional method without that optional parameter.
Re: Better Java – Resources for Writing Modern Java
#29'Formatting is so much less important than most programmers make it out to be. Does consistency show that you care about your craft and does it help others read? Absolutely. But let's not waste a day adding spaces to if blocks so that it "matches".'
I do agree that it's less important, but it's so easy to do that there is no excuse for not doing it or giving out such rubbish advice. Anyone that wastes a day on formatting is doing it wrong. The problem with advice like this is that people take it to the extreme and ignore formatting altogether. That leads to someone being frustrated and formatting all the files automatically (as should be done anyway) which then leads to possible conflict and crappy diffs. Instead, you could have had professional programmers work on these. In an industry that's touting how code readability is so important (and it is), this advice is toxic. We're finally getting people to realize that readability is the most important part for most code because it is. Honestly, formatting is important in this inconsequential reply, in essays, in everything we write except short chat messages. Imsurenoonewouldliketoreadsentenceslikethis just like no one wants to read obfuscated, unformatted, crappy code. So yeah, I disagree strongly because formatting is important, get one style, get proper tools to automate it, and then you don't have to spend a day putting in spaces (which is ridiculous).
Re: Better Java – Resources for Writing Modern Java
#30The only way it seems you can be effective with Java is with an IDE to do most of the heavy lifting. What would be better is if Java shipped with more focused command-line tools and better defaults that allow me to productive immediately without the need to learn something as hefty as IntelliJ / Eclipse. This could lessen the barrier of entry to Java and widen community adoption.
Or you could just use modern JVM languages like Clojure.
Lisp? Lisp syntax makes less sense than lambda and stream which have ruined Java.