Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think.

It could also be when he's hitting "run test" it's actually "compile and run"...



> Well no, startup is fast, period. You're probably just giving the class loader a ton of work on startup? I would start with checking that I think.

Ok, maybe I misspoke about the "JVM" startup. But the time between `mvn test` and it actually logging the first line of user code was in the region of 15 seconds. Every java project I've worked on has had startup time issues once they're bigger than a toy project.

Saying "the JVm startup is fine, it's just the class loader that's slow" reinforces the point of "it's slow to startup"

> It could also be when he's hitting "run test" it's actually "compile and run"...

This would be true in C# too, and in go. Both of those tools have much quicker compilation times IME than java, which is just a nice plus.


BTW, I wonder if any test frameworks are using the hot reloading JVMs yet? Would also solve this problem.


That's mostly because nobody cares enough to optimize it, but if you split code into modules so your number of classes, including dependencies, is smaller, then your tests will start quickly. Usually it's dependencies and DI that's the cause of this I think.

Aren't Go's compile times about the same as Java's? Of course it depends on what tooling you use to package the jars.


Well I could switch to a programming language that isn't so slowed down by ahead-of-time compilation. Maybe a JIT language?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: