Javachannel’s Interesting Links podcast, episode 10

Welcome to the tenth ##java podcast. If we were Neanderthals, our lives would be half over by now. As usual, I think, I’m Joseph Ottinger, dreamreal on the IRC channel, and it’s Tuesday, 2018 January 9. Andrew Lombardi, kinabalu on IRC from Mystic Coders is with me again.
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-10”. The podcast can also be found on iTunes and I’m trying to figure out if it’d be worth it to put it on Youtube, too – sorry, folks, no video from me. I can’t afford the cameras; every time they take a picture of me, they shatter.
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. TechTarget finally gets into the podcast, with Four ways the container ecosystem will evolve in 2018. Kubernetes gets the nod of approval, and… imagine containers being used in IoT. I’m not quite sure how the latter point will work. Is docker communicating with an embedded device, or are they talking about embedded devices RUNNING docker? If so, that’d be challenging. After all, Java’s not been all that successful on constrained devices either, and it has a constrained version. (The other two ways are: increased WIndows adoption in containers, and LinuxKit – derived from the Windows thing.)

2. Meltdown and Spectre – scary words indeed, and deservedly so. Our benefactors at Intel, whose sponsorship we’d accept mostly because we’re cheap and will take money from ANYONE, have blessed us with horrible security in virtually every chip manufactured in the last decade or so. Meltdown allows a program to access the memory of other programs and the host OS; Spectre also breaks isolation between programs. Fixing this requires replacing your physical CPU or patching your OS; the patches have performance implications. If you’re not patched, start looking for patches today. The JVM is not a good vector for delivering either of these flaws, although yawkat’s been playing around with trying it out; this is not the same as the JVM protecting you from other programs exploiting these flaws. Again, thanks, Intel.

3. Riccardo Cardin wrote up “Single-Responsibility Principle Done Right on DZone. He’s addressing one of the SOLID principles from Robert Martin, the “Single Responsibility” principle, which states: “A class should have only one reason to change.” Mr. Cardin understandably says that that’s a qualitative assertion and not a quantitative assertion – and he suggests adding cohesion to the definition, so that “only one reason” means that it has a single purpose – be it serving as a rectangle, or interacting with a database, or what-have-you. That’s still qualitative, really, but it’s a good baseline – a data access object should ONLY interact with a database, not perform calculations on the individual objects (although I guess you could bend the definitions to make THAT work, too, in the case of reporting.)

4. Lorenzo Sciandra wrote up “I thought I understood Open Source – I was wrong,” a well-written post about the open source mindset. He says that he used to see open source as a customer getting a freebie: the maintainers have a product that they give freely to the world. But that’s wrong: open source is all about participation. As soon as you use an open source product, you yourself are an actual owner, even if you’re passive about it; it’s yours, not theirs, and you have a right (and to a degree a responsibility) to participate and contribute to that product. It’s yours. You bit it, you bought it… which means if you find a problem, it’s your responsibility to report and address it.

5. DZone offered us “A Log Message is Executable Code and Comment”. Basically, the author – Dustin Marx – suggests that using a logger for comments actually is a lot more useful than simple code comments; code comments are easy to ignore (even if your IDE highlights them, you get used to seeing the green or blue marker and just skip over them). But a logger event – especially if the log levels are high enough to not hide, like error or severe levels – isn’t something you can ignore. The danger here, of course, is that your comments can actually affect your runtime; interpolation takes time, so you may end up having guards around your comments, a concept I’m struggling with. But it’s a neat idea – if the logger uses a lambda instead of an interpolated value (the lambda can do the interpolation, after all) the logger can do its own guarding and the performance impact MIGHT be minimal.

6. Up next: JaVers compared to Envers. This is a comparison between JaVers and Envers. Both are auditing tools for databases, but they have very different mindsets; Envers stores in an “audit” table that shows the history of the data with an additional version number, while JaVers stores a JSON representation of the object. The article’s pretty well-done – and uses Groovy to show functionality. Who knew – people use Groovy for something outside of Gradle? Crazy. Given that the article was written by the author of JaVers, I can’t say it was completely unbiased. It looks like a decent write-up of both tools, and seems like a fairly useful tool if you it’s a requirement for you. Have you needed to use any data auditing tools like this before?

7. Jiccup is a library inspired by Clojure’s “hiccup” – oddly reminiscent of ECS. It reminds one more of the Jade templating engine over in NodeJS land. You don’t see this thing done much outside of JavaScript libraries (well, except for hiccup, maybe?), so it’s good to see it but it’s really weak compared to what they’ve done with something like Jade. I’m looking forward to seeing if this gets more interest, as it looks like a fairly young project. (ECS is a dead project from Jakarta; each HTML element was represented as an object type, so you’d have an HTML object to which you’d add a head object and a body object, and your body would have a list of paragraph objects… so you’re just building an object model of an HTML page. It was slaughtered, and badly and quickly, by templating.)

8. “Switch Expressions coming to Java?” mentions a Java enhancement to make switch an expression instead of a statement. I’m all for this, but why limit it to switch? Why not try or if? This is one of those features that made me love Scala – before I realized what a puddle of hacks Scala was in the real world – and makes me enjoy Kotlin today. It’d be interesting to see how this works out – there are semantics that need defining, especially in light of backward compatibility – but I love this idea.