Interesting in running the current version of Java (and its compiler) on your Fedora instance? It’s easy:
sudo dnf install java-11-openjdk-devel
sudo alternatives --config java # select Java 11
sudo alternatives --config javac # if necessary, select java 11
Note that this is still labeled as the “early access” version as of this writing – but the early access version is virtually identical to the released version.
It’s only been six months, so it’s finally time for a new podcast. This one doesn’t even pretend to go over the mountains of killer content from ##java since the last podcast – it focuses on some of the more recent links, and that’s it. Well, apart from talking about the Java ecosystem a bit, especially in contrast with Python, an upstart language that’s making a lot of headway lately thanks to a giant upsurge in data science applications.
(A bit of irony: the very first paragraph in the podcast says it’s only been “four months” when it’s actually been six. Yikes.)
But there are some interesting links, and here are the ones the podcast focused on!
- The Apache Maven compiler plugin has been updated to 3.8.0, includes module-info support; default Java version is now 1.6, only two versions out of date
- NetBeans 9.0 has been released, and both Netbeans users rejoiced. You go, you two!
- https://github.com/GoogleContainerTools/jib is a gradle/maven plugin that builds a docker container easily. May not work well with https://aboullaite.me/docker-distroless-image/ but there’s more than one way to skin a firetruck.
- String literals are targeted for JDK 12 as the first preview language feature.
- JDT-Codemining is an eclipse plugin that decorates various nodes in your java code with live-updating useful info. Examples: * Did this @Test pass in last test run? * What are the param names for this method call? And an IDEA plugin that pulls completions from a public repository: Codota.
- “YAML: Probably not so great after all” is not a great article, but it points out that YAML might contain insecure data (like commands to run that aren’t wise) but does have a good point that the YAML spec is enormous for such a simple-looking document format. An alternative lately seems to be TOML, though: https://github.com/toml-lang/toml and a Java library for TOML (with no recommendation) is: https://github.com/mwanji/toml4j
- https://github.com/schibsted/jslt provides XSLT-type transformations for JSON.
- https://blogs.oracle.com/java-platform-group/a-quick-summary-on-the-new-java-se-subscription – an important rollup from Oracle on the nature of new Java releases. Chances are Oracle’ll be fine, what with corporations handing them money for the Oracle JVM and support… but everyone else should go ahead and use OpenJDK.
- https://itnext.io/pros-and-cons-of-functional-programming-32cdf527e1c2 is a decent rollup of functional programming. The best summary I’ve seen for it is still a book, though: Functional Programming in Scala. The book is good. Scala is not. 😀
- https://jaxenter.com/understanding-jakarta-series-tijms-147953.html brings up the idea that Jakarta EE (the new name for Java EE) might be more useful as a collection of specifications than as a deployment environment. The age of the containers might have passed, killed off by the new and ascendant microcontainers.
- https://javachannel.org/java-books/ – the channel website finally has a list of recommended Java books! If you think this list needs to be amended, feel free to send in your suggestions.
- Quick hit from ##java: files to commit in the source repository? the entire project folder, ignoring .classpath, .project, .settings/, *.iml, *.ipr, .idea/, and *~.
This was written with the new editor plugin for WordPress, called “Gutenberg.” It’s a lot like Medium.com’s editor. It’s effective for writing… unless you have any actual features you want in the text.
Welcome to the twelfth ##java podcast. Your hosts are Joseph Ottinger, dreamreal on the IRC channel, and Andrew Lombardi (kinabalu on IRC) from Mystic Coders. It’s Tuesday, January 23, 2018.
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
Optional in 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.
Welcome to the fourth ##java podcast. I’m Joseph Ottinger, dreamreal on the IRC channel, and it’s Monday, 2017 October 16.
This podcast covers news and interesting things from the ##java IRC channel; 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.
- Worth noting, not because it’s Java-related but because we’re all on the same Internet: there’s a security vulnerability with WPA2, the wireless encryption used by, well, pretty much everyone. Check your routers for security patches; if they’re not available, they should be soon, and if they’re not available soon, consider getting a good router.
- Effective Java is one of the recommended books from the channel regulars; it covers a lot of things that affect efficiently written Java. However, Josh Bloch is working on an update for the third edition of Effective Java. It’s available for pre-order. Highly recommended; Josh Bloch is one of the people who really knows Java, to the point where he says he can write code in Java such that he can influence how the JIT works, to make it more efficient than code mere mortals like you or I would write. So when he has a book on writing effective Java, it’s probably pretty authoritative.
- Facebook apparently uses their own build system, called “Buck.” It’s supposedly really fast; it apparently supports a lot of languages, which is a good thing; it does not, however, use the same build structure for source that Maven and Gradle use. That’s sort of okay; the Maven convention (which is what Gradle uses) is idiomatic in Java only because Maven itself became idiomatic, but it’s still something to consider if you’re moving to something different. My thought is that Buck might be cool but in a java-centric project, it’s probably not of sufficient interest to really move the needle. I looked; I considered; I moved on, seeing nothing really compelling in the description or tutorial that made me think “Wow!” like I did with, well, both Maven and Gradle, both of which I use regularly.
- Excelsior JET – who makes an ahead-of-time compiler for the JVM, so you can deploy your Java applications as native binaries – has an interesting post called “The Folder of God.” No, it’s not a religious post, although religious fervor might be involved if you hate Windows enough. Basically, there’s a way to create a folder in Windows such that Java programs running from that folder will crash, every time. (I don’t know why you’d actually do that in practice.) It’s an actual Java bug, not an Excelsior bug – but Excelsior experiences the bug nonetheless. It’s apparently been addressed in the Java sources, but your JVM might not be updated with the fix. It’s fascinating reading, even if only to make you glad you’re not using Windows.
- A report by realm.io suggests that “Java (on Android) is dying. There aren’t simply more Kotlin builders: they’re also switching their apps to Kotlin. In fact, 20% of apps built with Java before Google I/O are now being built in Kotlin. Kotlin may even change how Java is used on the server, too.” As a Kotlin user myself, I can say that the transition to Kotlin in dreamreal-land is progressing rather nicely… but what’s more relevant is that Kotlin on Android is increasing momentum, and that may very well drive server-side development as well, as there’s a strong tendency to be homogenous even if interoperability between languages like Kotlin and Java is quite strong. The channel recently had a discussion about Java’s checked exceptions, a feature Kotlin doesn’t share (because nobody really likes checked exceptions and the JVM itself doesn’t have them – they’re a
javac thing, not a JVM thing); checked exceptions are actually a good thing in that they force you to think about your exception handling, but there’s no guarantee you’re going to actually handle your exceptions well, so they end up being an unnecessary burden in many peoples’ minds. Worth thinking about, in any event…
- Something that comes up fairly often in the channel is the use of the Oracle JDK vs. OpenJDK, and what the differences are between them. I always said it was in a set of closed-source libraries used in Oracle JDK, such that some features might be present in Oracle’s JVM that OpenJDK did not have. Well, while that was true at one point, it’s like all Internet knowledge: it erodes. The Adopt OpenJDK project has a page on Differences between Adopt OpenJDK binaries and Oracle JDK Binaries that actually walks through the differences, which is a really short list: font rasterizers, color management, and graphics renderers. That doesn’t compare the differences with other implementations of the JVM – Zulu and whatnot – but what it does say is that OpenJDK and Oracle’s JDK are really closely aligned right now, just as designed.
- The Jooq blog has an article called Benchmarking JDK String.replace() vs Apache Commons StringUtils.replace(). It walks through an optimization process and measures the effectiveness, offering a ton of apologies for what might appear to be premature optimization along the way; the upshot is that Java 9’s
String.replace() works better than it used to, which might affect which implementation to use. (It turns out that Java 9’s version is slower for matches in long strings but faster for matches in short strings, which – in practice – are probably more common.) They ended up staying with Apache’s implementation for now if only because most people are still on Java 8 and thus the performance improvements are worthwhile. It’s a fascinating read.
- Wrapping up, we have an article from Baeldung called “Introduction to Caffeine“. Caffeine is a caching library; the article walks through its use, as one might expect. All that’s fine. What the article does not do, though, is differentiate why one might use Caffeine as opposed to one of the other caching libraries out there, like EHCache, or Guava Cache – which inspired Caffeine, actually. Channel inhabitant dudeji – which I don’t know how to pronounce – points out that Caffeine has time-to-live (as most of them do) but also automatic elimination based on unused keys; I can see some use in that, although I’d be concerned that the cache was deciding that a key was unused more aggressively than I’d have liked. I’m sure it’s tunable, though.