Month: August 2018

The JavaChannel Podcast, Episode XVII (17)

The XVIIth podcast is live! … one wonders why the Roman Empire didn’t last much longer, doesn’t one. One also wonders how long one can refer to oneself in the whatever-person this is. (It’s… second-person? No, folks, it’s “third person.” English grammer fumbling and lesson over.)
In this podcast, we chase a few things: the discussion topic centers back around on Python vs. Java, and why one might encounter one over the other in certain situations.
We also jump down the gullets of a lot of varied topics, only some of which are Java, but most are at least sort-of relevant:

  • Expanded switch statements in java! … Stuff we can look forward to in Java 12. Java’s looking more and more like Kotlin all the time.
  • Hibernate with Kotlin – powered by Spring Boot describes, of all things, using Kotlin, Hibernate, and Spring Boot together. (The summary has a good laundry list of things to pay attention to.)
  • Another Java Enhancement Proposal: the Java Thread Sanitizer. It would provide a dynamic data race detector implementation for Java and native JNI code utilizing ThreadSanitizer in OpenJDK with interpreter and C1 support… and while it’s great that tools like this might exist, it’s fantastic that they’re apparently rarely needed if they show up twenty years after Java’s release.
  • The Left Hand of Equals is not strictly java related, but still interesting. It mostly centers around what it means for one object to be equal to another. I wonder if the channel blog should have recommended LINKS as well as books….
  • TomEE: Running with Systemd is a pretty fair walkthrough, and should be applicable to other app servers as well… that is, if appservers are still relevant in the world where microservice containers do be existin, mon.
  • https://brilliant.org/ is a kinda neat site for math and logic skills. If you use it, don’t forget to take the question surveys, because that’s how it’ll improve.
  • How to Be a Person Who Can Make a Damn Decision is the first of at least two annoying links for Andrew – this one says it’s “how to be a person who can” but actually mostly documents people being those kinds of people. We also have the resurgence of the podcast drinking game; take a shot whenever game theory is mentioned. However, the article doesn’t really have a lot of takeaways, apart from pointing out that the ability to make a decision quickly is probably a worthwhile skill to have.
  • OpenPDF 1.2.1 has been released. Joe didn’t even know about this library. No idea how useful it is; this release doesn’t look like a big one from the surface, but still: the more libraries out there, the merrier, right? (Unless they’re logging libraries.)
  • 7 Scientific Benefits of Reading Printed Books is the second annoying link for Andrew. It goes over some, uh, tenuous reasons print books are worth reading, some of which were taken exception to. Joe thought it was worth thinking about when e-books are ALL the rage for programming topics…
  • Other tangential topics:
    • https://hmijailblog.blogspot.com/2018/08/you-could-have-invented-lmax-disruptor.html I hated reading this, so I stopped.
    • https://perens.com/2018/08/22/new-intel-microcode-license-restriction-is-not-acceptable/ Apparently Intel was saying not to publish benchmarks, which is kinda gross. However, worth noting is that after the initial scraping of this article, Intel backed down and changed the police. Way to go, Bruce Perens!

The JavaChannel Podcast, vol 16

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!

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.

Gradle Properties

Gradle supports properties in builds just like Maven does, but the actual documentation and examples are harder to come by. This article will show you something that actually works.
In Maven, you typically have a dependencyManagement section that declares the dependencies with versions; I typically put the versions in a properties block so that they’re all located in a nice, handy, easy-to-manage place. See https://github.com/jottinger/ml/blob/master/pom.xml for a simple example; it’s not consistent with the property usage, but the idea should be clear. I have my versions all coalesced into an easy place to update them, and the changes propagate through the entire project.
Gradle examples rarely do anything like this. Therefore, for your edification, here’s a simple example:
gradle.properties:

aws_sdk_version=1.11.377
kotlin_version=1.2.50

build.gradle:

buildscript {
  repositories {
    mavenCentral()
  }
  dependencies {
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
  }
}
apply plugin: 'java'
apply plugin: 'kotlin'
repositories {
    mavenCentral()
    jcenter()
}
dependencies {
    compile "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
    compile "com.amazonaws:aws-java-sdk:$aws_sdk_version"
}
tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).all {
    kotlinOptions {
        jvmTarget = "1.8"
        javaParameters = true
    }
}

You can use a constraints block in the dependencies to do the same thing as dependencyManagement in Maven; that would look like this:

dependencies {
    constraints {
        implementation "com.amazonaws:aws-java-sdk:$aws_sdk_version"
    }
}

This would allow submodules (or this module) to use a simpler dependency declaration, leaving off the version, just like Maven can do:

dependencies {
    compile "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
    compile "com.amazonaws:aws-java-sdk"
}

If you don’t want to use gradle.properties, that’s doable too (as pointed out by channel member matsurago) – you can put it in the buildscript block, as so:

buildscript {
  ext.aws_sdk_version="1.11.377"
}