
Mim - The Build System You’ve Always Wanted
The case for feature branchs / Branch Per Task Workflow / Gitflow Intro Screencast
Are patents a form of employment restriction? i.e. restraint of trade
Google should base Android on Newspeak
Building a better IDE thru prediction
Refactoring Given/When/Then
H264 Free for all
Half Arsed Agile Manifesto

Theme music “Past within a future” by Fractals, used under Creative Commons.

Illegal Argument Episode 50

Greg, Mark and Richard get together weekly and talk about things of interest in the Java community. Greg works for SimWorks (http://www.simworks.com) who specialize in mobile phone software. Mark works for SecureMX (www.smx.co.nz). Richard works for Blue Train Software (http://www.bluetrainsoftware.com)

Technology

Tech News

Podcasting

Gadgets

Software How-To

News

 Last week, Greg and I had the pleasure of sitting down with Andres Almiray from Oracle to discuss this week's release of Java 22. I was hoping to get this episode out sooner but ended up fighting it out with a fever. Alert Notification  https://blogs.oracle.com/java/post/java-on-macos-14-4  Java 22 Released Tomorrow  JDK 22 Release Notes: https://jdk.java.net/22/release-notes JavaFX Release Notes:  https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-22.md Does Java 22 Kill Build Tools? https://inside.java/202,4/02/15/newscast-63/ Update on String Templates (JEP 459) (most likely to preview in 23)  https://mail.openjdk.org/pipermail/amber-spec-experts/2024-March/004010.html — First preview feature to be unshipped and reworked entirely?  Misc  Apache Maven 4.0.0-alpha-13 released — This is the first release that requires Java 17! Welcome to Claro! — The Claro Programming Language https://docs.clarolang.com/chapter_1.html Introducing the Daggerverse - Dagger Devin AI Website — The First AI Software Engineer Cognition  Free OracleDb 23c Release  Oracle Database Free — https://www.oracle.com/database/free/ Oracle Database Free Container / Docker images — https://github.com/gvenzl/oci-oracle-free Oracle NoSQL Database — https://www.oracle.com/database/nosql/technologies/nosql/ JSON in Oracle Database Office Hours: Binary JSON formats  https://apexadb.oracle.com/ords/r/tech/catalog/session-landing-page?p2_event_id=15268317198142239082325102977690035505&debug;=LEVEL7&session;=213101861572582  

178: Java 22 Released! And I Am The Technical Debt

 It's been a long time (again) between recording/discussions, but finally, for the end of the year, we locked some time to record. Java  9 Outdated Ideas About Java - Azul | Better Java Performance, Superior Java Support Hidden gems in Java 19, Part 1: The not-so-hidden JEPs  JDK 20: The new features in Java 20 | InfoWorld  JDK 21: The new features in Java 21 | InfoWorld  Java 21 to drop generational Shenandoah GC  Why Your Choice of Java Virtual Machine (JVM) Matters More Than Ever - Azul | Better Java Performance, Superior Java Support  JDK 22: The new features in Java 22 | InfoWorld The Java Playground - Dev.java JEP draft: Null-Restricted Value Class Types (Preview) JEP draft: No longer require super() and this() to appear first in a constructor  Minborg's Java Pot: Java 20: Colossal Sparse Memory Segments  Golang   What’s New in Go 1.21 a Comprehensive Notes | by Younis Jad | Lyonas | Medium Go 1.20 Release Notes - The Go Programming Language [Go 1.21 Release Notes - The Go Programming Language](https://tip.golang.org/doc/go1.21 Go 1.22 Release Notes - The Go Programming Language (soon to be released)  Misc  GitHub - MichaelMure/git-bug: Distributed, offline-first bug tracker embedded in git, with bridges  So you want to write a package manager | by sam boyer | Medium Versioning non-project repositories (config, pipelines)  Semverbot looks good, but I found a bug: blang/semver only supports "v" prefix's · Issue #58 · restechnica/semverbot · GitHub   DORA -  Use Four Keys metrics like change failure rate to measure your DevOps performance | Google Cloud Blog Software Design and Maintainability  On bad advice  Why DevOps is failing: It's Not You, It's The Tools - GigaOm  An architect’s journal -Embracing Simplicity in Software Architecture Diagramming | by Asanka Abeysinghe | architect2architect  Building Great Teams   dagger.io | Replacing your Dockerfile with Go code  Replace a Dockerfile with Go | Dagger Dagger Java SDK examples:  sample  Healing The Poisoned Repository | Theory In Practice    

New Year, Old Year? What Year!?!

 Non-tech Music Banter   An Updated Look At Concert Merchandise Sales & Trends in 2022 Why Venues Take Merch Cuts  The Taylor Swift Economy: The largest music tour in history is a hospitality phenomenon   A litany of languages and their passing, software archaeology and the issues of adopting new languages?  Clojure - (next Rich)   JDK 21 to be released next month: JDK 21 Release Candidates & JVM Language Summit has a good overview.  JEP 430: String Templates (Preview)  Not a fan of the syntax, but also appreciate it's not just "string interpolation", it makes it very clear you're doing something different. I like that it's easily expandable and not too different from other languages that use r"Raw String here". NOTE: String Template Processing is runtime, not compile time, as Mark was thinking, as with being able to work well with Freemarker templates – which may work, but not as I implied.   JEP 431: Sequenced Collections look like a nice improvement for consistency – annoying for library writers who may find it more useful, tho. Mark: 440: Record Patterns and 441: Pattern Matching for switch – having used these a bit now I love them, in places they fit – they work well for Algebraic Data Type style things, but should be used in moderation tho. JEP 443: Unnamed Patterns and Variables (Preview)  It's a small win, but not having to name things “ignore” or “expected” etc.   JEP 445: Unnamed Classes and Instance Main Methods (Preview)  Initially didn't think I'd find much interest in this, but the more I experiment with Dagger.IO pipelines, and with the forthcoming Java SDK I can see this being enjoyable. JBang as an alternative    JEP draft: Prepare to Restrict The Use of JNI - JDK 22 to start warning on JNI usage…  The Reddit thread is well - as you expect :)  JEP draft: Prepare to Restrict The Use of JNI (Updated): r/java   Flame threads on the JNI command flag option.   Quick Fire Last Minute things:  Dagger, a ❤️  story | Flipt Blog Tutorial · arxanas/git-branchless Wiki · GitHub   BONUS Material  Apache Wicket PatternFly Elements - PatternFly Elements     

176 - Better Late Than Never?

 Episode 175 - 18 And Life Until last week, I was going to open the show saying it's been a long time since we last recorded, but we slipped in an interview with the guys from plz.review - so that's not exactly true anymore. It has, however, still been a while since we've had a normal, full session of discussion and argument. Delayed: The publishing/editing of this episode was unfortunately delayed due to me finally catching Covid. plz.review Updates  Github "integration" is available, we even had GerritForge - Home page listed in the show notes, as part of GerritForge there's GerritHub for online hosted Gerrit+GitHub integration which uses Gerrit's replication plugin, and a Github integration for authentication/authorization. Patch sets and comments remain in Gerrit.  JDK Related Since the last main episode, Java 18 was released (and earlier this week JDK 18.0.2 was released with various security and docker improvements.)  Java 19 is currently in Rampdown Phase Two with a GA release slated for 2022/09/20  405: Record Patterns (Preview) 422: Linux/RISC-V Port 424: Foreign Function & Memory API (Preview) 425: Virtual Threads (Preview) 426: Vector API (Fourth Incubator) 427: Pattern Matching for switch (Third Preview) 428: Structured Concurrency (Incubator)   Rust 1.63: Scoped Threads : rust. Similar to the forthcoming Structured Concurrency for Java.      Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses - Interestingly no replies to that post at all. Value type companions, encapsulated Project Leyden: Beginnings (r/java discussion) Testing clean cleaner cleanup – Inside.java - Replacing finalizers with Cleaners.  Tooling   SD Times Open-Source Project of the Week: Adoptium - SD Times  IntelliJ IDEA 2022.2 Goes Beta  | The IntelliJ IDEA Blog - Switches from running with Jetbrains' JDK11 to JDK17 IntelliJ IDEA 2022.2 Is Out! | The IntelliJ IDEA Blog JetBrains Fleet: The Next-Generation IDE by JetBrains  Java / JVM  Hibernate ORM 6.0 Delivers Improved Performance Languages   Kotlin/Native vs. C++ vs. Freepascal vs. Python: A Comparison | by Alex Maryin | Apr, 2022 | Better Programming Kotlin 1.7.0 Released | The Kotlin Blog  Scala 3.1.3 released! | The Scala Programming Language   Build  Bazel   Announcing Bazel & JetBrains co-maintenance of IntelliJ IDEA Bazel Plugin - Bazel Bazel Community Update - 5/16/22 - YouTube Manage external dependencies with Bzlmod  |  Bazel   Apache Maven Wrapper – Maven Wrapper    Alternate Languages  Celebrating 50 Years of Smalltalk | by Richard Kenneth Eng | Jul, 2022 | ITNEXT  Help Microsoft shape the Azure SDK for Rust  Shaving 40% Off Google’s B-Tree Implementation with Go Generics - ScyllaDB Zaplib post-mortem - Zaplib docs - Post-mortem of porting JS to Rust/WASM  Simplifying Go Concurrency with Futures  Common Lisp - Repl Style. Dev visually with CLOG Builder : Common_Lisp OCaml 5 and new Website  1.5. Summary — OCaml Programming: Correct + Efficient + Beautiful - new OCaml site launched Ocaml 5 concurrency tutorial - concurrent OCaml is finally here (almost) GitHub - ocaml-multicore/eio: Effects-based direct-style IO for multicore OCaml  Will OCaml 5+ multicore be fragile? - #17 by gasche - Learning - OCaml   C++   C++ 23 to introduce module support | InfoWorld GitHub - carbon-language/carbon-lang: Carbon language specification and documentation. - An experimental successor to C++  Looks like it's getting a lot of flack on Twitter -  Twitter: Carbon C++ Results      Security  Reflections on Log4J Security Issues Weeks after breach, the Heroku GitHub connections remains on ice  Misc   Major Version Numbers are Not Sacred Decentralized Identifiers (DIDs) v1.0 is a W3C Recommendation | W3C News   Decentralized Identifiers (DIDs) v1.0    An open-source tool to seed your dev database with real data : golang  How Apple, Google, and Microsoft will kill passwords and phishing in one stroke | Ars Technica  Complexity is killing software developers | InfoWorld  

175: 18 And Life...

 Reddit Post:  Improving on the GitHub code review comment experience : programming Blog Post:  Bit Complete Blog: Improving on the GitHub code review comment experience | Bit Complete Inc. YouTube Introduction Video: Introduction to plz.review - YouTube Website: plz.review Guests: Dylan Trotter, Matt Schweitz It's been a while since recording, and as it happens, just before organizing the next episode, full of “discussion” on the recent Java 18, and forth-coming Java 19 release, I came across an r/programming post from Dylan Trotter from Bit Complete about their new stacked code review tool for Github. After reading the post, linked blog post, and introductory YouTube video, I reached out to discuss the product, the problems with Github's default PR model, and code review in general. Contents  00:00:03.754 Introduction 00:01:07.236 Bit Complete History 00:02:24.492 What Makes A Good Code Review? 00:12:32.219 DORA (not the Explorer) 00:14:38.308 Bisecting Squashed Commits 00:18:51.617 The plz.review Solution 00:19:08.934 plz.review Stacks - Grouping PRs Together 00:21:36.969 plz.review Revisions: Force push solutions 00:25:37.590 plz.review Migration - Moving from Gerrit? 00:29:34.371 Gerrit and Github Integration 00:32:23.516 Compromising your workflow to fit Github PRs 00:39:41.700 Code Review as Mentorship / Education 00:41:26.759 Github: Social Coding brought code-review to mainstream 00:45:52.124 Long Lived Support Branches 00:50:03.479 How to signup for plx.review  Overview Before we get into plz specifics - I assume both Dylan and Matt have some interesting takes on what makes a good review:  What makes a good review? What constitutes good review "hygiene"?  Mark: IMHO A review/commit/PR should ideally do one thing. What the "thing" may be intangible, but ideally:  If you're going to reformat code, keep it in a commit separate from business logic changes. If you're updating dependencies, keep them separate from business logic changes, however do include code changes to ensure the build continues to build and pass tests.  If a dependency update introduces breaking API changes, keep that dependency change along with the implementation for it.        Laurence Tratt: Programming Style Influences Practical guide to DORA metrics | Swarmia  DevOps Research and Assessment - The four DORA metrics are:  Deployment frequency: How often a software team pushes changes to production Change lead time: The time it takes to get committed code to run in production Change failure rate: The share of incidents, rollbacks, and failures out of all deployments Time to restore service: The time it takes to restore service in production after an incident   The first three metrics I can see being highly impacted by small changes, automated testing and CI integration. These all intersect with code reviews – having visibility that a proposed change actually compiles, passes tests, and doesn't introduce any new security issues before a co-worker even looks at the change speeds up the process.  Stacked code reviews promote  keeping pull requests small | Swarmia changes (with small being a subjective size),   We've spoken on code formatters before on the show, keeping consistency for reviews is a good thing regardless of being automated or not.    plz.review The project/platform appears to solve several issues we're facing with Gerrit, and our adoption of Azure Devops:  Azure Devops is unable to pull from patch-sets, due to the private rev nature of Gerrit Writing custom Azure function(s) to listen to Gerrit events and manually trigger a Devops build is viable, but not ideal.  The prospect of abandoning Gerrit and switching to Githubs force push and squash approach makes me cry,  Coming from the Gerrit Code Review Tool it's great to find a stacked review tool for Github, having people getting in the habit of force pushing to remotes just promotes bad hygiene IMHO. Looking at the available docs, several interesting things come to mind: Comparison: Gerrit and GerritForge - Home page - which I've used in the past for some open source work (GitHub - repaint-io/maven-tiles: Injecting maven configurations by composition rather than inheritance originally used GerritForge).  Gerrit keeps all patch-sets - and lets you compare diffs between patch-sets, is that also mirrored within plz.review? I guess Github would only track to latest/amended PR.  Looks like the plz command line generates its own form of Change-Id footer: plz-review-url which tracks revisions of a change linking to https://plz.review/review/NNNN - which doesn't appear to be name-spaced in any way (company or repo). Gerrit's UI is getting better, but still leaves a lot to be desired – I still wish improvements to commenting/UX were more of a focus. plz.review's UI also seems simple in design (not necessarily a bad thing), UI/UX design is hard in general, the requirements of a stack version control also seem to make it a tricky balance between fully featured, and clean….`   Gerrit Migration – Given git patch-sets/comments are all in git refs, is there a migration strategy to expose them into plz.review/github?  Is there a potential migration strategy? plz.review feels early in the development stage. Such things may not have been considered, or deemed out-of-scope for the system.     Comparison: Graphite — Modern code review for fast-moving teams - Open Source CLI/web dashboard stacked review tool based on Git, designed to work with Github. - Graphite beta demo [December 2021][V2] - YouTube - Stacked diffs for fast-moving code review - The Changelog: Software Development, Open Source (Change Log Podcast Interview). Automated bot responses - with CI/test results often being published back into Github PR's as validations for viable PR merges, do these get reflected in the plz UI, or even -2 rejections? Dealing with commits outside of plz.review - such as automated release commits that push direct to GH / potential conflict resolution (having access to Gerrit's local git repo has often been a godsend). What's the business model for plz - per repo charge? per organisation? per user?  

Illegal Argument Episode 50

Download our free app to listen on your phone