Javachannel's Interesting Links podcast, episode 9

Welcome to the ninth ##java podcast. If we were using octal, we’d be on the eleventh podcast by now. It’s hosted by Joseph Ottinger (dreamreal) and Andrew Lombardi (kinabalu on irc) from Mystic Coders and, as a guest, Tracy Snell (waz) on the IRC channel, and it’s Friday, 2017 December 29.
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; 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-9”. The podcast can also be found on iTunes.
You can submit to the podcast, too, by using the channel bot; ~submit, followed by an interesting url, along with maybe a comment that shows us what you think is interesting about the url. Yes, you have to have a url; this is not necessarily entirely sourced material, but we definitely prefer sourced material over random thoughts.

  1. Up first we have Eugen Paraschiv, from Baeldung, with “How Memory Leaks Happen in a Java Application“. Most Java coders don’t really think about memory leaks, because the JVM is so good at, well, not leaking memory – but it’s still doable, especially when you have long-lasting data structures sticking around, like caches, that can retain references to object trees long past their usefulness. Eugen points out the obvious suspects – the use of static, for example, to retain references for the duration of the reference to the class – and also points out String.intern() as a culprit for some. That’s more a Java 7 and earlier problem than a Java 8 problem, since Java 8 handles interned strings differently. He points out unclosed resources as an obvious problem – unreleased filehandles, et cetera – and points out badly defined classes being used in collections (as Object’s implementation of equals() and hashCode() make retrieval difficult and therefore those objects will last as long as the Set does). He follows it all up with some ways to detect memory leaks. Well done article, although some of the approaches that lead to memory leaks are a lot less of an impact than he implies, especially with the current releases of the JVM. (This does not mean that it’s okay to be ignorant.)
  2. Some notes on null-intolerant Java,” from Dominic Fox, says that ”Null-intolerant Java is Java in which there are no internal null checks”. There are a few variants of this; there’re libraries that guarantee no methods will return null, other forms that use Optional, or just throw exceptions if you use a null when you’re not supposed to, or that will defensively check for null on library entry so that you fail immediately if you try to pass in a null when you’re not supposed to. He also mentions Kotlin’s null-checking – using the word “nugatory” for the first time in my experience. (It means “of no value,” just in case you’re wondering or you’re having difficulty inferring it from context.) His criticism of Kotlin in this case is that the null-checks are there whether you want them or not, and there’s a performance cost to them… but I’m not sure how well or deeply he’s measured. It’s actually a pretty decently written article; he mentions Optional – as he should, really – but also describes it sanely, meaning that he doesn’t say something stupid like “use Optional everywhere for nullable values.”

  3. The Java subreddit r/java has a comment thread called “What are features that make Java stand apart from other languages?” Lots of interesting comments; the JVM features highly, the language’s simplicity features, the ecosystem, even the JCP gets a positive mention or two. It’s an interesting DISCUSSION. What do you think makes Java stand out? One of the things I’ve liked in Java that’s changing, though, is the preference for a single idiom; when you look at Scala, you can achieve a given task in eight wildly incompatible ways, but Java’s historically had ONE way to do most things, and that’s changing. I’m not suggesting that that’s a BAD thing, but it’s something that’s changing. Essential conservatism in motion, folks!

  4. RxTest is a Kotlin library meant to help test RxJava flows. (Is that what RxJava calls their pipeline processing mechanisms? I don’t know.) It’s easy to test the simpler parts of event handling mechanisms – you pass it some input, see if you get the right output – but testing flows tends to be a little more involved, because most of it’s asynchronous and it’s hard to test entire streams of processes. Good idea, expressed cleanly, although if you don’t know Kotlin it might be a good time to learn some of it. (This does not mean there aren’t ways to test RxJava event handling in pure Java – it’s just neat to see DSLs for stuff like this.) Also mentioned in this section: awaitility, a library whose name Joe apparently cannot pronounce.

  5. Along the same topic: DZone also has an article on designing a DSL in Kotlin, entitled “Kotlin DSL: From Theory to Practice.” Oddly enough, it also creates a testing DSL, for a learning environment. You’d think that people would use other problem domains for DSLs more often – but it seems like most examples are build tools or testing libraries. It’s still interesting stuff. Have you ever used or implemented a DSL? How broadly used was it, how successful do you think it was, and why?

  6. Dan Luu wrote up an article called “Computer latency: 1977-2017” (therefore: “-40,” duh), using a keypress and the time it takes to display that key as a measure of latency. He goes into OS mechanics (simpler OSes display faster, regardless of processor speed) and display refresh rates… really fascinating stuff, even if it’s not Java-related at all. (I kinda wish he’d measured a JVM on some of these platforms, although that would expand his testing matrix considerably.) (Also mentioned in this section: Rastan, an old video game. And it’s “Rastan,” not “Rathstan,” which is what Joe was mistranslating it into. Memory is what it is, apparently.)

  7. DZone is back with “Alan Kay Was Wrong (About Him Being Wrong),” an article talking about one of the primary ways to describe how objects interact: “messaging.” (Alan Kay – a person, with a name – is considered one of the fathers of object-oriented programming, BTW.) It used to be that you’d describe an object as “communicating” with another object by way of method calls, so you’d say something like “the model is ‘sent to’ the renderer, with the print method.” Nowadays, if you’re not working with Objective C, that sounds a little quaint, I think, but it’s still a way of thinking about data flow. The article is suggesting that Kay – who questioned the analogy – was absolutely right when you think about the objects in question being representative of modules rather than finely-grained objects. With Java 9 supporting module granularity, who knows – this analogy may be back in vogue when people really start using Java 9 modules in practice.

Well, it’s the end of the calendar year – may the new year bring you health, wealth, happiness, and comfort as you attempt to spread the same. We wish you all the best in everything you do.

Interesting Links, 31 Oct 2016 (and 25 Dec 1038)

  • kumuluzEE is “A lightweight framework for developing microservices using standard Java EE technologies and migrating existing Java EE applications to microservices.” It’s not immediately clear from the web page what makes it ideal for migrating to microservices, but there it is.
  • Don’t Even use COUNT(*) For Primary Key Existence Checks” has some valuable performance advice, and considers multiple DB implementations while offering it.

Now for some Scala stuff:

  • Quo Vadis, Scala?” has some considerations of the value of Scala on the larger JVM ecosystem. Turns out that Scala has more impact than some think it does, and less impact than others think. Go figure. 🙂
  • Sbt makes me want to give up Scala” has some well-considered criticisms of the Simple Build Tool, SBT, Scala’s primary delivery mechanism. Well-written and justified; if a build tool is the primary contact point someone has with a language, and that build tool is slow and uncomfortable to use, well… that impression is going to stick with people. SBT is really powerful… and it sucks. This post walks through a lot of why.
  • From user tetero, apparently inspired by the SBT link, “Scala Collections: Why Not?” is a video presentation by Paul Phillips that feels like it’s a rant about why he’s leaving Scala: it doesn’t do things the way he wants. Sure, what he wants would be good (simplicity, accuracy, honesty, clarity) and it highlights what people see as the worst in Scala: the community’s hardheadedness about how good Scala really is. It turns out to be an anti-Scala rant, in the end, but the truth is that Scala is better than he makes it sound and just as bad as he makes it sound. Use Scala if it works for you, and don’t, if it doesn’t. (The user in question said that this video was part of what led him to Clojure. There’s nothing wrong with Clojure, but like most things, it’s not perfect and Scala’s type system oddities seem like a poor sole motivator.)

Interesting Links – 17 Oct 2016

  • JEP 295: Ahead-of-Time Compilation offers deployers a chance to compile the base Java modules to native code. This can save time on some optimizations, but it’s understandably limited (and should be).
  • The Halstead Metrics (also known as “Halsted metrics”) discusses code complexity in Java. Worth considering; this particular explanation comes courtesy of JHawk, a commercial code metrics tool, not to be confused with “j-hawk“, an open source testing tool.
  • Experimenting with “mutation testing” and Kotlin is a neat post describing PIT, a testing tool that changes your source code and runs your tests – if your tests don’t fail, your tests are probably bad (or your code’s awful.)

Interesting Links, 2016 Sep 13

  • Technical Itch: JVM guaranteed safepoints, Safepoints in HotSpot JVM, and Dynamic Deoptimization came up in conversation.
  • – selckin says it’s basically “take a peek under the hood at the java bytecode for fun and profit.” Interesting site, though, it basically runs javap and procyon (a java decompiler) over submitted code and shows you the bytecode and associates it with the lines of java (or kotlin, or scala) that generated that bytecode.
  • NetBeans Proposal suggests a migration of NetBeans (possibly a fork?) from Oracle to Apache, opening up NetBeans to Apache’s governance model and a wider community. Considering the noises Oracle’s made around NetBeans being deprecated (and therefore likely abandoned), this sounds like a great idea.