Sep 7, 2022 | updated Sep 27, 2022 | 5 min read
Share: Twitter LinkedIn Bluesky Threads Mastodon Email Copy
Part 9 of 14 in the Java-Full-Stack-New-Noteworthy series.
java-full-stack-new-noteworthy

Java Full-Stack Report September 2022: New & Noteworthy


This is an old version! Click below for the current one.

See Current Version


What’s This?

Here are the most important news for Java developers from last month — in my opinion, at least.

Archive
2022 Aug Jul Jun May Apr Mar Feb Jan

Table Of Contents

New & Noteworthy

Java Champion James Ward on the State of Java and JVM Languages

James Ward is a Java Champion and Kotlin Product Manager at Google. He hosts the “Happy Path Programming” podcast with Bruce “Thinking in Java” Eckel. In one episode, Eckel spoke of “people who are still trapped in the Java world.” Ward agreed and called default mutability in Java the “trillion-dollar mistake” (referencing the “billion-dollar mistake” of NullPointerExceptions). That got me curious. So I interviewed James for InfoQ. Here are the key points:

  • Java is still a great language, but Kotlin is a faster-developing, incremental alternative, while Scala takes Functional Programming to some extremes.
  • James prefers languages that let him write more correct code through a high level of validation at compile time.
  • Through Scala, James found programming paradigms and experiences that have altered his way of thinking.
  • Default mutability in Java is a “trillion-dollar mistake” because it makes it hard to reason about what the code does.
  • Project Loom’s approach is a game-changer because it removes the cognitive overload of reactive programming.

And what about the “trapped in the Java world” business? His answer was that it means “using old programming paradigms”. He wiggled out of that one well! 😁

IEEE’s Annual Top Programming Languages 2022

The “Spectrum” magazine of the Institute of Electrical and Electronics Engineers (IEEE) has an annual ranking of programming languages. The good news: Java’s doing well. And SQL is doing surprisingly well.

The IEEE uses the following data sources: Google searches, mentions on Twitter, questions at Stack Overflow, posts on Reddit, mentions in the IEEE Xplore Digital Library (over 3.6 million conference and journal articles), stars & pull requests on GitHub., the IEEE Jobs Site and the CareerBuilder job site. Here are the highlights:

  • When looking at all data except job ads, Java is #5 with 70.2 points, Scala #15 with 8.7, and Kotlin #19 with 5.7. Python leads with 100 points, C# is #4 with 87, and JavaScript is #7 with 40.5.
  • Looking at jobs only, Java is #2 with 95.1, Scala is #10 with 16.8, and Kotlin is #17 with 8. SQL leads with 100, Python is #3 with 88.2, JavaScript is #4 with 71.2, and C# is #5 with 63.2.
  • In the “Trending” section, Java is #2 with 74.2, Kotlin #23 with 8.2, and Scala #24 with 7.7. Python leads with 100, JavaScript is #4 with 60.2, and C# is #6 with 48.6.

So Python leads overall, and Java is holding its own. Interestingly, Scala is the #2 JVM language here, not Kotlin.

No matter whether SQL is a programming language in the same league as Java or Python, it’s #1 in jobs and #6 in the other data sources. The IEEE thinks this is a real trend, and SQL is indeed becoming more important. They argue that even for data science and machine learning experts, knowledge of SQL is beneficial.

Developers Decide the Software Architecture with The “Advice Process”

How do you decide on architecture in your projects? Do you have architects deciding that for you? Are you deciding this in isolation? Or does the loudest voice in the room win?

Here’s another approach — the “Advice process”. It’s decentralized! Here’s how Andrew Harmel-Law from Thoughtworks describes it:

  • Anyone can make an architectural decision.

  • But before making the decision, the decision-taker must consult two groups: The first is everyone who will be meaningfully affected by the decision. The second is people with expertise in the area the decision is being taken.

The “decision-takers” are the developers who implement the software. They don’t have to agree with the advice they get, but “they must listen to and record it”.

Now, doesn’t that devalue software architects and other experts? Won’t developers ignore their advice and “do what they want”?

Well, they already do! At least, that’s what the article claims. It quotes Alberto Brandolini, “it is the developer’s assumptions which get shipped to production”. And if it’s the “developer’s version of the architecture” that ships anyway, letting developers decide the architecture makes that plain to see for everybody.

The article describes the four supporting elements:

  • Architectural Decision Records (ADRs) as the “thinking and recording tool”,
  • A weekly, hour-long Architecture Advisory Forum as the “time and place for conversations”,
  • Team-sourced Architectural Principles as the backbone, and
  • An opinionated guide to current trends in languages, frameworks, tools, platforms, and techniques (“Your own Technology Radar”)

James Ward and Bruce “Thinking in Java” Eckel interviewed Andrew on their podcast. It’s a good introduction and discussion of the topic.