171–180 of 192 posts
>Java 8 has a nice stream and lambda syntax. You could write code like this: final List filtered = list.stream() .filter(s -> s.startsWith("s")) .map(s -> s.toUpperCase()) .collect(Collectors.toList()); >Instead of this: final List filtered = new ArrayList (); for (String str : list) { if (str.startsWith("s") { filtered.add(str.toUpperCase()); } } >This allows you to write more fluent code, which is more readable. I…
>Java 8 has a nice stream and lambda syntax. You could write code like this: final List filtered = list.stream() .filter(s -> s.startsWith("s")) .map(s -> s.toUpperCase()) .collect(Collectors.toList()); >Instead of this: final List filtered = new ArrayList (); for (String str : list) { if (str.startsWith("s") { filtered.add(str.toUpperCase()); } } >This allows you to write more fluent code, which is more readable. I…
I have been coding Java (and C-style) languages for a really long time. And, I still have some cognitive delay when traversing multiple indented scopes. Not a long delay, but long enough to be slightly annoying.
With the lambda style, I can quickly glance down the text column to see what's going on. Stream -> Map -> Filter -> Collect.
After using lambdas enough, one starts to subconsciously cull the stream() and collect() calls. So, when I look at it, I really see Map -> Filter.
But what really, really annoys me is that exception handling can't be applied to the whole stream processing statement. This leads to code that looks like:
collection
.stream()
.map(o -> {
try {
return o.oToC();
} catch(Exception e) {
// handle
}
return new C();
})
.reduce((c1, c2) -> {
try {
return c1.combine(c2);
} catch(Exception e) {
// handle
}
return c1;
});
Earlier quoted context omitted.
jMock isn't great, but Mockito makes it too hard to understand which method you haven't stubbed; I find EasyMock with its explicit replay() step much easier.
JMock at least blows up if you don't mock something. Powermock and Mockito will let it pass. It is a shame JMock's API is so wordy.
Earlier quoted context omitted.
Or you could just use modern JVM languages like Clojure.
I like Clojure, but anyway to make it start faster in a scripting context? I wrote the same script in Clojure and Kotlin, and the Kotlin one loads so much faster.
It uses JavaScriptCore and starts practically instantly. There's some work being done to port it to Linux/Windows as well.
Here's an example:
cat foo.cljs
#!/usr/local/bin/planck
(println "hello world: clojurescript -> planck -> as shell script")
./foo.cljs
hello world: clojurescript -> planck -> as shell script
Planck can be installed using homebrew now as well.
Another promising option is Pixie https://github.com/pixie-lang/pixie
Earlier quoted context omitted.
Java as a language is totally fine! It has everything one might need. The culture totally sucks. Oracle leads the march toward what is the "standard". Jersey is a great leap out of this.
I consider Jersey to be a good example of what is wrong with Java. Annotation driven APIs don't really lend themselves to composability - sparkframework, vertx or ratpack are much better ways of building REST apis with Java 8.
Addendum: I’m also of the opinion that trying to write java code without an IDE is highly inefficient. With an IDE, you can locate all the throws you’re not taking care of quickly, and usually quickly deal with them to get things to compile. Yeah, it’s a bit of housekeeping overhead, but once they are dealt with, they are dealt with, even if it is just passing them upstream.
Re the first bit about 'struct' style, even better (IMO) is to use Lombok; throw an @Data annotation on your class and all you need to do is put your properties in there (private final if need be). Nobody should be writing those boilerplate constructors, getters and setters. If it's generated by your IDE, use Lombok. The best code is no code.
then you suddenly force anyone who uses your code to depend on lombok. I tried to find a compile time only mechanism for lombok - not sure i found it, but it ought to exist!
Earlier quoted context omitted.
The benefits of streams isn't performance improvements for the CPU, but performance improvements for the developer.
i have colleges that claim streams don't necesserily make the code more readable. Imagine a triple nested for-loop - making it a triple nested streams (e.g., where your map method is yet another stream), doesn't seem to really make it any more readable. The only reason to use streams, i think is the possibility to automatically parrelize, and secondarily to make it more readable.
The Java compiler will unroll the methods anyways, so you get easy readability without any loss of performance.
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.
jMock isn't great, but Mockito makes it too hard to understand which method you haven't stubbed; I find EasyMock with its explicit replay() step much easier.
Earlier quoted context omitted.
jMock isn't great, but Mockito makes it too hard to understand which method you haven't stubbed; I find EasyMock with its explicit replay() step much easier.
JMock at least blows up if you don't mock something. Powermock and Mockito will let it pass. It is a shame JMock's API is so wordy.
You had better mock everything, and better put them in the exact order they will occur in, or your test fails.
Most JMock unit tests I see are essentially the exact same code as is being tested, written a second time in the unit test. So if I want to refactor or modify this code in any way, my unit tests break- even if functionally, my tests are doing exactly what their spec says.
With Mockito, I can say 'Hey, if anyone calls this method with parameters sort of like this, give them this response', and then focus on my unit tests actually testing the output for a given input.