4 ms·
1. Oracle. 2. "Better the devil you know". A lot of people don't trust JIT and especially GC to do their jobs well. Seeing the plethora of alternatives and o
by notacoward 11y ago
1. Oracle.
2. "Better the devil you know". A lot of people don't trust JIT and especially GC to do their jobs well. Seeing the plethora of alternatives and options that have come along over the years doesn't help. Those things might be awesome by now, they might solve way more problems than they create, but too late. A lot of people have already taken a look and decided to stick with what they know.
3. Oracle.
4. Deployment headaches. Forget developers for a moment. Consider users. The JVM is no trivial thing resource-wise, even compared to other VMs. A lot of users don't want to add that much bloat, plus a whole parallel set of libraries installed "through the back door" instead of via the system package manager, then solve all of the tuning/sizing and dependency problems, to run one app. Developers who care about their users listen to this feedback.
5. Oracle. I know it seems like I'm making a joke here, but that pernicious influence a serious negative for a lot of developers and users.
- azth 11y ago> A lot of people don't trust JIT and especially GC to do their jobs well. Practically all major languages other than C or C++ rely on GC. That point makes no sense. The JVM is used in so many critical infrastructure projects (let alone web apps like OP was referring to), and so the JIT point is also incorrect.
- notacoward 11y agoPoint's waaaaaay over there, dude. This isn't about what is or should be. It's about what people perceive and how that affects their decisions. People who've been programming twice as long as the JVM has existed might still have a few funny ideas about it.
- azth 11y agoFair enough.