I seems like the Java/Kotlin world largely might be sort of used to waiting 30+ seconds for a recompile after making even a 1 line code change.
I've asked around, and I've heard that yes there are ways to speed it up if you setup everything correctly and have a good strategy in place for using cache.
However, I'm getting the sense that most of the Java projects out there might have a horrific dev experience where the devs might just accept that its Java and that's how it is, in which case, there must be a lot of miserable Java devs who waste most of their day waiting.
Please someone say it isn't so..
The reason for Java building being slow is that for whatever reason, the community that develops Java has been inundated with people who are more concerned with flexing their theoretical computer science knowledge than actually making the language spec adaptable. As such, the core language is extremely lacking in features.
For this reason, people built systems on top of the language, such as build systems, dependency injection systems, testing systems, and so on. But again, for someone to dedicate time to building on top of the crap that is core Java requires a certain mindset, which lends itself to extremely bloated code, or things like making a log statement have code that can fetch code from the internet and execute it.
So when you stack all of these on top of one another, thats where you get long compile times from. You have gradle build system, which is Groovy, which then gets compiled to run on the jvm, which then compiles the annotation processors which often write code to a file on a disk, which then gets included along with the rest of the code, which then gets compiled into class files and then jar files.
Also, during execution, because the common guidance is to use extremely bloated and poorly organized 3d party libraries for basic things, all of these libraries have a startup time associated with it.
Most Universities on the planet teach Java as an introductory language (which makes sense to be honest) but they stop after that.
And then students know how to quicksort in 10 different ways, but not how to MVC or even how to build a web app.
Personally I think that our education system is botched there, because most of the theoretical knowledge is only important in the "paper writing" context. Once it gets into applying that knowledge into practical use, most students are lost because their professor never taught them how.
Only the self-taught students who were bored to death in University are actually the ones capable of doing so.
Respectfully disagree. Depending on what the introductory program wants to focus on Python, a Lisp or even C make more sense than Java.
You have problem with your setup; you're doing something wrong. Incremental compilation is near instant on hardware produced in the last 8+ years. The JVMTI interface moves it into the JVM nearly instantly.
Use an IDE like Intellij. I have coded a lot of Python, back to java/Kotlin now, and I prefer it.
If you're just re-building on the command line every time you make a change, and your build takes 30 seconds, then yeah you wait.
If you're working in an IDE, running your project out of the IDE, then you might have more options. For example, in IntelliJ IDEA, you can often reload changed classes and hot update the running program.
It's pretty common to have quick unit tests so you can cycle thru TDD without having to recompile the world and start-up/reload the application. You can get a few hours of work done with TDD without ever opening the actual application. In legacy enterprise, you're rarely doing green field work. You usually spend time reading coding and planning a safe edit. When you do change a line and have to recompile the world, its common to actively read and plan your next change while waiting.
Though there are many ways of optimizing things, it's all on your (dev) shoulders.
If the dependency tree is such that making a 1 line change still causes a 500 file recompilation, yes, you could be seeing a multiple second wait.
The project before that the build took around 8 minutes.
In both cases I felt it was more how the build was set up rather than something that was inherent to Java. (The 20 minute build was a Spring/Groovy project, the 8 minute one was a Java Swing application.)
This is where using TDD really shined. Modifying the code and running a test took seconds instead.
Sadly I was always one of the few who used this approach. Even seniors would spend days or even an entire sprint doing something that would take me less than a day.
