As always, this podcast is basically interesting content pulled from various sources, and funneled through the ##java IRC channel on freenode. You can find the show notes at the channel’s website, at javachannel.org; you can find all of the podcasts using the tag (or even “category”) “podcast”, and each podcast is tagged with its own identifier, too, so you can find this one by searching for the tag “podcast-12”.
Not an “interesting link,” but we discuss data formats – JSON, XML, HOCON, YAML, Avro, protobuff, Thrift…
Java 9.0.4 has been released, as part of the scheduled January update. NOTE: This is the final planned release for JDK 9. This is scary; see also Azul’s post, “Java: Stable, Secure and Free. Choose Two out of Three,” which points out that with Java’s new rapid-release schedule, you’re going to have to be out of date, insecure, or financially on the hook to … someone to keep up with security releases. We’ve been wanting new features in Java for a long time; we’ve been wanting more churn in the JVM, too. Looks like we, as an ecosystem, might get to experience what Scala goes through every few months, except at least we have the option of stability somewhere.
Speaking of Scala, we have “10 reasons to Learn Scala Programming Language.” It actually has some decent points to make… but makes them with Scala. That’s dumb. There’s nothing that Scala really offers you that Kotlin doesn’t, and that’s assuming Java 8 and Java 9’s improvements don’t turn your crank themselves. It’s almost got a point with Spark and Kafka (well, it mentions Spark, Play, and Akka, and I’m going to pretend that the author meant to say “Kafka” instead), but… when that’s your real lever for learning a language, it’s time to admit that the language was a mistake.
DZone: “Java 8: Oogway’s Advice on Optional” is yet another attempt to justify
Optionalin Java. It has a fair point to make: “Optional is not a replacement for the null check. Rather, it tries to tell the caller about the nature of the returned value and implicitly reminds the caller to handle the absent cases.” But … okay. So what? In the end, you still have to write what is effectively pretty simple code, and adding the semantic turns out in practice to mostly add noise to your code without actually making it any better.
DZone: “An Introduction to Hollow Jars”, which I found fascinating but I don’t know why. A “hollow jar” is apparently a deployment mechanism where you have two deployable components: the main one, the “hollow jar” basically has the other component – which is the actual application code – in its classpath, and serves to invoke the entry point of the application. The invoker would theoretically change very rarely, and therefore could be baked into a docker image or some other base image, and the component that changes more often would be soft-loaded at runtime.