I actually have a ton of professional Java experience and have done a lot of microcontroller stuff of late (for fun mainly) and if you go at doing software for ARM Cortex-M microcontrollers the Java way you’re going to end with overengineered bloatware.
It’s however not a Java-only thing: most of those things have too little memory and processing resources for designing the whole software in a pure OO way, plus you’re pretty much coding directly on the low-level (with at most a thin Hardware Abstraction Layer between your code and direct register manipulation) so only ever having used high-level OO languages isn’t really good preparation for it, something which applies not only for people with only Java experience but also for those whose entire experience is with things like C#.Net as well as all smartphone frameworks and languages (Objective-C, Kotlin, Swift).
I used to write a lot of performance-critical Java (oxymoron I know) for wearables, and one time I got a code reviewer who only did server-side Java, and the differences in our philosophies were staggering.
He wanted me to convert all my code to functional style, using optionals and streams instead of simple null checks and array iterations. When explained that those things are slower and take more memory it was like I was speaking an alien language. He never even had to consider that code would be running on a system with limited RAM and CPU cycles, didn’t even understand how that was possible.
This may be an unpopular opinion, but I like some of the ideas behind functional programming.
An excellent example would be where you have a stream of data that you need to process. With streams, filters, maps, and (to a lesser extent) reduction functions, you’re encouraged to write maintainable code. As long as everything isn’t horribly coupled and lambdas are replaced with named functions, you end up with a nicely readable pipeline that describes what happens at each stage. Having a bunch of smaller functions is great for unit testing, too!
But in Java… yeah, no. Java, the JVM and Java bytecode is not optimized for that style of programming.
As far as the language itself goes, the lack of suffix functions hurts readability. If we have code to do some specific, common operation over streams, we’re stuck with nesting. For instance,
That would be much easier to read at a glance if we had a pipeline operator or something like Kotlin extension functions.
varresult= data.stream()
.map(parseData)
.filter(ParsedData::isValid)
.map(ParsedData::getValue)
.sortAndSumEveryNthValue(2) // suffix form
.map(value -> value / 2)
...
Even JavaScript added a pipeline operator to solve this kind of nesting problem.
And then we have the issues caused by the implementation of the language. Everything except primitives are an object, and only objects can be passed into generic functions.
Lambda functions? Short-lived instances of anonymous classes that implement some interface.
Generics over a primitive type (e.g. HashMap<Integer, String>)? Short-lived boxed primitives that automatically desugar to the primitive type.
If I wanted my functional code to be as fast as writing everything in an imperative style, I would have to trust that the JIT performs appropriate optimizations. Unfortunately, I don’t. There’s a lot that needs to be optimized:
Inlining lambdas and small functions.
Recognizing boxed primitives and replacing them with raw primitives.
Escape analysis and avoiding heap memory allocations for temporary objects.
Avoiding unnecessary copying by constructing object fields in-place.
Converting the stream to a loop.
I’m sure some of those are implemented, but as far as benchmarks have shown, Streams are still slower in Java 17. That’s not to say that Java’s functional programming APIs should be avoided at all costs—that’s premature optimization. But in hot loops or places where performance is critical, they are not the optimal choice.
Outside of Java but still within the JVM ecosystem, Kotlin actually has the capability to inline functions passed to higher-order functions at compile time.
I actually have a ton of professional Java experience and have done a lot of microcontroller stuff of late (for fun mainly) and if you go at doing software for ARM Cortex-M microcontrollers the Java way you’re going to end with overengineered bloatware.
It’s however not a Java-only thing: most of those things have too little memory and processing resources for designing the whole software in a pure OO way, plus you’re pretty much coding directly on the low-level (with at most a thin Hardware Abstraction Layer between your code and direct register manipulation) so only ever having used high-level OO languages isn’t really good preparation for it, something which applies not only for people with only Java experience but also for those whose entire experience is with things like C#.Net as well as all smartphone frameworks and languages (Objective-C, Kotlin, Swift).
I used to write a lot of performance-critical Java (oxymoron I know) for wearables, and one time I got a code reviewer who only did server-side Java, and the differences in our philosophies were staggering.
He wanted me to convert all my code to functional style, using optionals and streams instead of simple null checks and array iterations. When explained that those things are slower and take more memory it was like I was speaking an alien language. He never even had to consider that code would be running on a system with limited RAM and CPU cycles, didn’t even understand how that was possible.
This may be an unpopular opinion, but I like some of the ideas behind functional programming.
An excellent example would be where you have a stream of data that you need to process. With streams, filters, maps, and (to a lesser extent) reduction functions, you’re encouraged to write maintainable code. As long as everything isn’t horribly coupled and lambdas are replaced with named functions, you end up with a nicely readable pipeline that describes what happens at each stage. Having a bunch of smaller functions is great for unit testing, too!
But in Java… yeah, no. Java, the JVM and Java bytecode is not optimized for that style of programming.
As far as the language itself goes, the lack of suffix functions hurts readability. If we have code to do some specific, common operation over streams, we’re stuck with nesting. For instance,
var result = sortAndSumEveryNthValue(2, data.stream() .map(parseData) .filter(ParsedData::isValid) .map(ParsedData::getValue) ) .map(value -> value / 2) ...That would be much easier to read at a glance if we had a pipeline operator or something like Kotlin extension functions.
var result = data.stream() .map(parseData) .filter(ParsedData::isValid) .map(ParsedData::getValue) .sortAndSumEveryNthValue(2) // suffix form .map(value -> value / 2) ...Even JavaScript added a pipeline operator to solve this kind of nesting problem.
And then we have the issues caused by the implementation of the language. Everything except primitives are an object, and only objects can be passed into generic functions.
Lambda functions? Short-lived instances of anonymous classes that implement some interface.
Generics over a primitive type (e.g.
HashMap<Integer, String>)? Short-lived boxed primitives that automatically desugar to the primitive type.If I wanted my functional code to be as fast as writing everything in an imperative style, I would have to trust that the JIT performs appropriate optimizations. Unfortunately, I don’t. There’s a lot that needs to be optimized:
I’m sure some of those are implemented, but as far as benchmarks have shown, Streams are still slower in Java 17. That’s not to say that Java’s functional programming APIs should be avoided at all costs—that’s premature optimization. But in hot loops or places where performance is critical, they are not the optimal choice.
Outside of Java but still within the JVM ecosystem, Kotlin actually has the capability to inline functions passed to higher-order functions at compile time.
/rant