131–140 of 192 posts
Please don't use Java 8's default methods in interface's to do multiple inheritance, and code reuse. Prefering this over 'Util' classes is bad as it is inheritance over composition. The default methods were designed to facilitate easier interface migration
>> Good alternatives to using Spring is Google and Square's Dagger library or Google's Guice. They don't use Spring's XML configuration file format, and instead they put the injection logic in annotations and in code Spring has had code-based configurations since 2009[1]; seems a little disingenuous to recommend Guice/Dagger due to this non-existent limitation. [1] http://spring.io/blog/2009/12/22/configuration-simpl…
Spring with a very strict, carefully enforced style guide is probably as good as Dagger or Guice. But there is a cost to maintaining and enforcing a style guide. Better to just use something that doesn't have the bad options.
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.
Can you expand on the later point about final please?
tl;dr: final parameters != immutable and safety, and they look like they ought to. A lot of people write "final" in front of every. single. declaration. And they do that because someone once told them that was good. But then you remember that Java is a language which all non-primitive types are passed by reference, so your 'final' is actually a final reference and not a const immutable object, like you might get in C…
Honestly I don't think final ever makes things worse. I struggle to imagine someone who would misunderstand in the way you describe having any success in Java - references are a pretty fundamental part of the language.
Dependency 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.
public class MyClass {
@Inject private String foo;
}
public class MyClass {
private String foo;
@Inject public MyClass(String foo) {
this.foo = foo;
}
}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…
[1]
public class MyImmutable {
public final String field1;
public final int field2;
public MyImmutable(String field1, int field2) {
// assign
}
// equals, hashcode, toString
}
The 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.
The problem with writing Java without an IDE isn't one of tooling, it's that the language is so very verbose. They're working on that with lambdas and generics inference, but there's a limit to what you can do and remain backwards compatible.
Dependency 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.
I mostly agree with this list but some things I have issues with. The biggest is DI. Having witnessed what a tangled mess large Guice codebases can become where you really have no idea what is providing what I have to say that Spring here gets a bad rap from the all-XML days and (IMHO) it is actually the cleanest and easiest to work with. The author mischaracterizes Spring too: > It has a either code-based wiring or…
But that one place is XML. Better to have it be code, where I can use all my normal tooling ("find references" in my IDE (yes some IDEs have spring support), grepping through .java files, automated refactoring...) to work with it.
> Guice can be many levels deep and tends to descend into ModuleBuilders and conditional logic in modules (which the docs recommend against but tends to be used extensively anyway)
Have you seen the kind of horrors that are possible in Spring XML with conditionals, proxying, interceptors...? Compare like with like.
And in the worst case, if you must put conditional logic in your config, at least if it's in code then you can unit-test it the normal way.
> Testing. Testing is incredibly easy. I'm talking functional testing here, even integration testing. You simply include another XML file that overrides any definitions from the first. Everything else remains the same. Testing with Guice can be horrendous and once you start making extensive use of Modules.override() you should abandon all hope.
Shrug. Not my experience; you get more-or-less equivalent tooling capability with both (that is, you can group your definitions into smaller modules, and you can override specific instances when testing), so if you use them the same way it'll be just as easy or hard.
Earlier quoted context omitted.
Your comment about the "JVM update" was a non sequitur trailing from your rant, but I'm glad to know that you were indeed referring to JDK 1.8. The fact that you get excited in the event these nebulous java devs have "heard" of Clojure/Scala only comes across as patronizing (but I suspect you weaved that in masterfully and deliberately, given your degree in English.) Your anecdotal fallacy hasn't added anything valua…
You have won at the internet. I'm sure you're a joy to be around. I haven't seen the meaningful response that you've added. You really do seem like a troll. If that's not your intention, that's cool. If it is, well, hey, happy trolling dude! Edit* Yep, just checked your comment history, you're a troll. God why do people like you exist.....