Revisiting Java in 2021 – Part II

There's been a lot of sensible work in the core codebase since then to move towards more coherent idioms, unfortunately the 'we can make Scala into Haskell' crowd have since taken up the mantle and everyone has become obsessed with the idea that no boilerplate starter project is complete without cats or similar which perpetuates barely-legible and unnecessary confusion in situations that should be simple.

This might not be something to pin on the language designers, if you're using certain third-party libraries. Indeed it is possible to name a method pretty much whatever you want, with some constraints[0]. Wanna call it "!^"? Go ahead! But, this is afoul of the naming convention in many cases[1]--acknowledging that the convention may have previously been a bit more lax in this regard.

OTOH the distinction between "::" and ":::", and the implications of stuff like "<:" often do require a refresher if they're not part of one's day-to-day.

[0] https://stackoverflow.com/questions/7656937/valid-identifier... [1] https://docs.scala-lang.org/style/naming-conventions.html

https://docs.scala-lang.org/cheatsheets/

Double arrow seems to have multiple uses - for anonymous functions (like in js) and for pass-by-reference arguments (I guess scala is pass-by-value by default).

(Surprised at how Erlang-y it feels, especially WRT pattern matching)

It's not clear whether Loom will be a big hit. Personally, I think the Actor model is the best application level concurrency "primitive", and Loom is just about fibers & continuations, both of which are parts of Actors but aren't really Actors themselves.

I'm kind of curious about this. What kind of lifetimes are you looking at for JVMs? Are you trying to use Java in lambdas on demand to user requests? What kind of warmup time are you seeing right now?

One way to get into it is to build something real, first on bare bones (e.g. 'javac Main.java; java Main'), then bare bones Maven, then finally pick a great starting project which itself curates some of the best techniques and libraries currently available for the platform. I am partial to Dropwizard. Do not skip the first two steps though, because if you dive immediately into Dropwizard you'll be disoriented.

I would also suggest avoiding IDEs at the beginning. They hinder more than help at the beginning. One fun thing to do is download the JDK and the docs and source (usually a separate download, alas) and then disconnect your laptop from the internet. See how far you can get with it! Sadly, File IO in Java has always been verbose, but it is probably useful for you to suffer through it.

What will keep you in the office to all hours is the ecosystem. Now the ecosystem is probably best in class so don't mistake this as a slight, but it's huge and complex.

Learning Gradle (or Maven), understanding how to make building java apps fast (because the default is slow package assembly times), learning some of the large frameworks (if you go down that route) can keep you occupied for years.

If you're fresh to java, i'd probably encourage you to try avoiding the incumbents like Spring and see how you go? Without Spring, Java is actually pretty efficient. A hello-world rest service with spring results in around 6,000 classes being loaded.

That said - spring, used idiomatically, is a productivity boosting powerhouse.

More recent changes are relatively smaller and probably don't need a full book to cover.

Would recommend it after Effective Java (3rd edition).

skim over Java 5 syntax. It should be very easy to understand for anyone with programming experience.

Explore Java 8, 11, 17 features, but try to map all the syntax to Java 5, because those features usually are just a syntax sugar and I think that it's easier to understand those features this way.

Do not dive into standard library too much. It's vast and you can spend a lot of time studying it, but that's not necessary to start.

It should take few days of learning and experimenting.

After that you have to choose a framework, because Java applications are very framework-heavy ones. And that's where most of complexity comes from. People usually use Spring these days, so that's probably would be the most reasonable choice. There's no easy path, you'll struggle a lot and that's unavoidable. Modern Java Frameworks are full of hard to grasp concepts, tricky magic code and 20-year old roots buried in the depths of stacktraces.

Stackoverflow a lot, and you'll eventually naturally learn most things you need to know.

At some point I'd recommend to prepare for Oracle Java Certification (Oracle Certified Professional). It's a very good exam with lots of core Java topics and with some gained experience you'll structurize everything in your brain and you'll learn few things that avoided your attention before. I don't suggest to actually pass the exam, as that would cost some money and effort, so it's up for you to decide, but preparing to exam is very worthwhile time investment.

I don't see why I should force my company into vendor lock-in (IntelliJ/Kotlin) on what is otherwise an open platform (Java/OpenJDK).

https://github.com/JetBrains/intellij-community

As others have mentioned, with Kotlin you're pretty much limited to Jetbrains' IDE, you have a new runtime dependency, not just a compiler, which is rapidly changing and requires updates on the code base frequenly (one of my projects used Kotlin for testing with KotlinTest - which recently changed names to KTest I think - and it was horrible to have to re-write most of my hundreds of tests to be able to upgrade when they went from JUnit 4 to 5 and in the process re-wrote all of it, basically), the compiler is slower and it starts to feel very much once you have thousands of lines of code... not to mention that there's a fairly big overhead of not only having to have javac installed, but also the Kotlin compiler and standard library... also, you probably want to use Gradle with the Kotlin DSL which in my view is really, really slow and unpleasant to work with - though they've finally been improving this recently - in the last couple of years.

So, yeah, I like to write Kotlin code better than Java, but due to all of these factors and the fact that Java is now fairly close to Kotlin in functionality, if I had to start a big project today, I would pick Java for sure.

I‘m planning on revisiting Scala at some point

The only people I EVER encounter with any confusion around Java licensing are students, entry-level devs, and people from other ecosystems who parrot things they hear on Internet forums.

OpenJDK is free and open source. It imposes no license restrictions on your server-side applications, and these days imposes virtually no limitations on retribution of the JDK itself with traditionally-shipped applications.

Oracle's own binary build of the OpenJDK source code is a commercially licensed thing, because it comes with some extra proprietary tools that people might care about when profiling applications in a large enterprise. But there are other OpenJDK builds with no cost or licensing restrictions whatsoever, from Azul, IBM, Amazon, and others. Outside of the largest and most conservative Oracle shops, virtually everyone uses one of these free JDK builds.

So much nonsense FUD is made from "lack of commercial support" for the non-Oracle JDK builds. Not "having someone to sue" if something goes wrong, etc. For one thing, who are you supposed to sue when you have a problem with Python or Node? If you want someone to be financially liable to you, then you have to financially pay someone to take on that liability. In practice though, have you ever even heard of a lawsuit over a JDK bug? This is nonsense.

Java has way more web framworks from what I've seen (could be a good or bad thing), and more alternative languages that you can pick from.

I very much doubt reflection is going anywhere. For one, GraalVM native images support reflection, you just have to state ahead of time what you plan to reflect over.

WASM+JVM works. You can run WASM on top of the JVM. There's a Truffle interpreter for it, which means WASM code gets JITCd by the JVM itself and you can interop in and out. Check out GraalWASM.

  val numVowels = getDTO()?.string?.let(::countVowels) ?: 0