Welcome to the eighth ##java podcast. Iâ€™m Joseph Ottinger, dreamreal on the IRC channel, and itâ€™s Thursday, 2017 December 20. Andrew Lombardi from Mystic Coders is with me again.
Please donâ€™t forget: this is your podcast, with your content too. You can contribute by using a carrier pigeon and sending us notes encoded with rot13 – twice if you want to be really secure – or by using javabot on the IRC channel, with ~submit and an http link, or you can also write content for the channel blog at javachannel.org, or you can even just tell us that somethingâ€™s interestingâ€¦ weâ€™ll pick it up from there.
“Non-Blocking vs. blocking I/O: Go with blocking.” is an article by ##javaâ€™s surial. In it, heâ€™s talking about asynchronous code, especially with respect to I/Oâ€¦ and his assertion is that you really donâ€™t want to do it. If you decide you do (and there are reasons to) then you should at least rely on some of the libraries that already exist to make it easierâ€¦ but he mostly points out that it isnâ€™t worth it for most programmers. Interesting read, especially when you consider that Python and Node.JS live and die on this programming model.
“To self-doubting developers: are you good enough?” is an article meant to make you mediocre programmers feel better about yourselves. It talks about the processes and exercises that we all more or less had to go through to achieve competence. Itâ€™s not a long post, but it has some good points; programming is practice and art, just like athletics, really – and sometimes you lose, sometimes you plateau, sometimes you have to put in time that someone else might not have to put in. Sometimes the other guy is a natural at some things, and your effort is required to give you the edgeâ€¦ but the good news is that you can put in the effort.
Jason Whaley posted a link called “Incident review: API and Dashboard outage on 10 October 2017” that went into a Postgres multinode deployment failure. Itâ€™s a payments company, so the outage is a pretty big deal for them; the short form is that they had a series of failures at the wrong time, and the postgres installation failed. Thatâ€™s something we donâ€™t hear about very often – either because people are ashamed of it, or hiding it, or some other more nefarious reason, perhaps. More reasons why Iâ€™m a developer and not in DevOps? Some pretty in-depth analysis on multi-master Postgres and unintended consequences of architecture. Appears that aside from the Postgres-specific things mentioned here, it probably is a good idea to regularly introduce fault into your infrastructure to test it, to see where the problems are you didnâ€™t intend. And the automation erodes knowledge.
“Want to Become the Best at What You Do? Read this.” goes over five steps to being all that you can be including quoting â€œEye of the Tigerâ€ for added insult. Several of the ideas in here are valid though, focusing on improving your skills / self-improvement and putting yourself out there in a vulnerable way. All the items have a â€œThe Secretâ€ type of vibe around them though, which is a bit of a turn off. Love the process, better yourself, make a positive impact on the world, sounds pretty good.
A user on ##java posted a reference to zerocell – a simple open source library to read Excel spreadsheets into Java POJOs. Apache POI is the go-to for this, but POI is a little long in the tooth; itâ€™s always nice to see people creating new solutions. I donâ€™t have any Excel spreadsheets that I need converted into POJOs handy – and I donâ€™t think Iâ€™ve EVER had them… except maybe once.
“Understanding and Overcoming Coderâ€™s Block” is YET ANOTHER lifestyle article for this podcast; itâ€™s addressing those times when someone who might otherwise be a good coder – or writer, or anything – encounters the inability to write anything worthwhile. Itâ€™s focused on code, but itâ€™s pretty general even so: reasons include a lack of clarity on what youâ€™re trying to achieve, or a lack of decisiveness about how to solve a problem, or maybe the problem just seems too big to solve, or maybe even that youâ€™re just not all that jazzed about the project youâ€™re working on. It also addresses external factors – you know, real life – that might be getting in the way. Lastly, it includes some tips for each of those problems to perhaps point the way forward.
“The Myth of the Interchangeable Developer” is yet another lifestyle article that points out what we all know but that recruiters and managers seem to be ignorant about: we all have specific skillsets. If Iâ€™m a good services developer, it doesnâ€™t necessarily follow that Iâ€™m a good UI developer, for example… it doesnâ€™t mean that I canâ€™t learn, but it certainly implies that thereâ€™s an extra cost in time or aptitude for me to actually design a UI.
“Understanding Monads: a guide for the perplexed” is an article trying to explain monads yet again. Maybe itâ€™s me, but Iâ€™m thinking that monads might be one of those formal terms thatâ€™s useful but not useful enough, because theyâ€™ve been around forever but people still donâ€™t get them. Maybe thereâ€™s a giant set of programmers who shouldnâ€™t be allowed to program… but my feeling is that â€˜monadâ€™ is mostly jargon. To me itâ€™s a stateless bit of code that defers state elsewhere, so itâ€™s â€œfunctionally pure.â€ Lots of languages that rely on asynchronous programming have a similar concept, but they donâ€™t necessarily call them â€œmonadsâ€ (and they can store state elsewhere, too, so maybe theyâ€™re cheating.) Itâ€™s a decent article, but if you donâ€™t understand monads, it may not .. actually change anything for you. But maybe it will.
Ah, Project Valhalla. DZone has an article – pretty old now, actually, a month or two – that talks about Valhalla. No Valkyries, unfortunately, but value types instead: object references that are referred to just like primitives. This means that Java might get some forms of reification… but itâ€™s hard to say. The main thing I wanted to see from the article was more clear example code; thereâ€™s one that boxes an integer in a generic class, without specifying the integer type, but Iâ€™m not actually seeing where thereâ€™s a real benefit in code yet.
One of my favorite subjects is up next: “Why Senior Devs Write Dumb Code and How to Spot a Junior From A Mile Away.” Want to find a junior developer? Find someone who spends four hours tuning a bit of code that will run â€¦ once every four hours. Overexerting yourself trying to write the perfect bit of code every timeâ€¦ thatâ€™s a junior developer. Of course, we all know some senior developers who do the same sort of thingâ€¦ and we tolerate them, but itâ€™s just tolerance. I donâ€™t write supercomplicated code if I can help it, and Iâ€™d rather provide simple code to get something simple done if I can, even if that means Iâ€™m wasting a few hundred K of RAM or a few dozen milliseconds. I mean, sure, if we need those milliseconds or that RAM, we can tune for thatâ€¦ but we do that when necessary and not otherwise. A summary might be: hesitate to wax locquacious when your innate desire is to extrude tendrils for others to admire your skill; alternatively, allow their senses to inhale your greatness despite their inability to immediately perceive how impressive your capabilities are, especially in comparison to their own.
Welcome to the sixth ##java podcast. Iâ€™m Joseph Ottinger, dreamreal on the IRC channel, and itâ€™s Monday, 2017 October 30. Scary! Tomorrow’s Halloween.
This podcast covers news and interesting things from the ##java IRC channel on Freenode; if you see something interesting thatâ€™s related to Java, feel free to submit it to the channel bot, with ~submit and a URL to the interesting thing, or you can also write an article for the channel blog as well; Iâ€™m pretty sure that if itâ€™s interesting enough to write about and post on the channel blog, itâ€™s interesting enough to include in the podcast. (And guess what? That happened this week. See entry #4!)
- First up we have two articles about NoSQL from Matt Raible and Okta.com – “NoSQL Options for Java Developers” and “NoSQL Options for Java Developers, Part II.” They were published almost a month apart. In Part I, Matt mostly focuses on a very general overview of the NoSQL landscape and how he chose what NoSQL products to focus on – which ended up being MongoDB, Redis, Cassandra, Neo4J, and Postgres JSON. In Part II he encourages more of a discussion from some NoSQL luminaries about those five. They’re sharing stories and anecdotes about the databases, and it’s interesting reading, even if a little light on content – but they do have some interesting quips to throw out. One in particular stood out to me: you really should justify using something other than Postgres these days, and while I’m a big proponent of NoSQL, I totally agree. They also point out that some people see NoSQL as a magic bandaid for performance, and that’s simply not the case, at all.
- Up next we have “A Gentle Introduction to the Bag-of-Words Model.” The Bag-of-Words is a very common way to help trim down inputs for automated learning, or artificial intelligence; one of the things about AI is that it’s painfully easy to overwhelm systems with irrelevant input. This article introduces one of the most common ways to trim input, by providing a focus on words used most commonly in a bit of text – a corpus – or maybe the least common words in that corpus, too, really. (Which set of words you choose depends somewhat on what you’re trying to do.) Interesting article, fairly well done, I thought. Not heavy on code – in fact, painfully light on code – but bag-of-words is actually really easy to write, so that’s not a big deal.
- Java 9 is all the rage these days, even though I don’t know anyone who’s actually deploying it yet. Our next article is “Making JSR 305 Work On Java 9,” which focuses on using the annotations for software defect detection – JSR 305 – along with annotations from
javax.annotation, which apparently doesn’t work very well in Java 9, due to the packages being split across multiple jars. Part of the problem is the implementation of the JSR 305 annotations themselves; it’s not really been a problem in the non-modular world, but Java 9 is more strict (and should be) about how modules are implemented. The article shows some workarounds and actually does enable the use of the various annotations (and has some warnings along the way) but I think the greater takeaway is that Java 9 is a sea change for Java. It’s probably one that was necessary – sure, we had OSGi and Java EE to help modularize the JVM, but there were and are crucial limits to those approaches that Java 9 is actually trying to address – but even though it’s been necessary there’s still a lot of pain and technology transfer involved.
- We also have some content from ##java denizen
yawkat: “How (not) to extend standard collection classes.” It came from a discussion on ##java about someone needing a bounded
PriorityQueue. I was being really pragmatic and short-sighted, and suggested just overriding the
add() to enforce a limit, but the truth is, that is short-sighted – and yawkat wrote this article discussing why and how to actually extend such classes properly. Very well done, and it’s much appreciated.
- Another note about future releases of Java – I was going to say “Java 9” but apparently that numbering system is endangered. There’s a JSR – JSR 383 – for Java 18.3, the release scheduled for March 2018. The main difference I see is in local variable type inference, JEP 286. Type inference is cool – Scala and Kotlin have it and rely on it – and it’s great that Java will get it soon too, but the “Java 18.3” name is going to take some getting used to. I still don’t like it. Maybe this is part of their Halloween pranking: “Boo! It’s Java 18.3!” to which my response is, well, “booooo.”
- WildFly 11 Final is available. There are lots of improvements here – not many of them are earth-shattering, I think (and I’m waiting for them to go to WildFly Orange or WildFly Jet Fuel, following Oracle’s ridiculous naming practices – okay, I’ll shut up about how I don’t like “18.3” from here on out.) Anyway, WildFly is the fully open source version of JBossAS; it really is a great product. I prefer it to all of the other Java EE containers these days, even though I usually work on distributed services and not monolithic servers any more. I use a lot of the Java EE APIs without using an actual traditional Java EE container, and that’s the current trend I’m seeing – but I’m pretty sure that my data set is pretty constrained. Congratulations on the release, WildFly people.
- InfoQ comes in with the JUnit 5 release announcement. JUnit5 changes some annotations and introduces lambdas into the testing mechanism. It also changes the runner mechanism. It requires Java 8, but that’s okay; everyone should be on Java 8 by now anyway. I really like that JUnit is moving forward; I’m mainly a TestNG user, but TestNG has been pushing JUnit to add features, and I imagine that JUnit will likewise push TestNG to add features. Everyone wins.
- Up next we have “Project Loom: Fibers and Continuations for the Java Virtual Machine.” This feels really familiar, actually – there used to be a Continuations feature as part of RIFE, and that was around years ago. But here we have an official continuations and fibers suggestion; fibers are lightweight threads, and continuations allow scheduling of tasks on those lightweight threads. I’m not doing it justice here, but it looks great; it’s a long article, worth the read, notable more for its existence than its actual technical content at this point (but the technical content is a good read. Many other platforms have features like this, so it’s good that Java might get them.)
- The Gradle project has published “The State of Gradle Java 9 Support,” an article going over the increasingly popular build tool’s support for and integration with Java 9. Multi-release jars still rely on an external plugin, but the module system is supported by Gradle’s dependency resolution, from the looks of it. This is an excellent practice to have, on Gradle’s part – let people know what is supported, how it works, how to use it, and set the expectation that changes will be discussed and documented. It’s almost like open source; open discussion and knowledge transfer.
- Lastly, there’s a call for votes on the OpenJDK mailing lists for a new garbage collector, ZGC. It’s currently a skunkworks project of sorts for Oracle, and is aimed at providing low latency for multi-terabyte heaps, a phrase that gives me the willies. I’ve worked with large heaps before – but mainly through things like Azul’s Zing platform. It’s really neat that the Java ecosystem keeps changing like this, though, in that we gain new feature sets all the time and Java just gets better and better. Now if we could only maintain sane version naming and remember to work together…