Is it common for Java devs to wait 30s+ for a recompile after making any change?
I'm mostly used to Python programming..
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.. In most enterprise settings yes. You can make personal projects in Java fast if you don't use any of the build systems and call javac/jar directly with shell scripts, but then again, why would you ever chose Java in the first place. 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 of the phenomena you describe are kind of the result of hiring students straight after or even during their Bachelor's degree. 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. > Most Universities on the planet teach Java as an introductory language (which makes sense to be honest) Respectfully disagree. Depending on what the introductory program wants to focus on Python, a Lisp or even C make more sense than Java. No. 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. No. I work for a Fortune 100, we use Quarkus for lot projects, the dev reload is amazing, it just takes less than a second to reflect the change. It fast enough that I feel like I work with a Python project. I use spring boot and java/kotlin, but professionally and for side-projects, changes are "instant" on side-projects and greenfield projects. Legacy enterprise is another story, there the answer is "it depends". Use an IDE like Intellij. I have coded a lot of Python, back to java/Kotlin now, and I prefer it. What setup do you have that it's "instant"? I put a decent amount of effort into reducing my apps startup time for local development but it's still on the order of 3-10s It depends on your workflow doesn't 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. The IDEs support incremental recompilation and it usually takes at most a couple of seconds - unless your project is huge and you work on some core module on which everything else depends. That's not common in Java though (more common in C++ codebases, where people like to have for example their own custom collection classes). Absolutely not. @exabrial nailed it. Any modern IDE used for Java development does incremental compilation so fast you can't even notice it happening. Now if you trigger a full build of your project using Maven or Gradle or something, then maybe. But that would largely be true using any compiled language. No, it's not normal to wait for the IDE. Maybe you need more RAM, to adjust JVM settings in your IDE, fix some weird issue. IntelliJ has index updater bugs after releases sometimes, for example, and the Bazel plugin has lots of problems. Yes, but its not as bad as it sounds! 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. My first two jobs as a java programmer had multiple minute build times. It was really an incredible mess. That was 10+ years ago, however, so I have no idea if that's still normal. Yes. Java is old, java is big, java is not hipster, java infra is complex (often terribly and not dev friendly). Though there are many ways of optimizing things, it's all on your (dev) shoulders. I don't have a lot of Java experience, but this definitely doesn't line up. For any compiled language, modern compilers for C++/Java are generally fast enough for most codebases, BUT companies need to invest in their actual build processes to keep things optimal. 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. I have no recent experience with Java, but in C# it is literally a few seconds. Can't imagine Java taking much longer unless you either have a gigantic codebase, or a very slow laptop. This is not a substantive comments but I would ecstatic it if the C++ builds at my work only 30 seconds. The last project I worked on, the build took around 20 minutes. 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. That's Java, baby. Even for the people who have a better set up.. most companies are using older version of Java with older dev tools.