3 ms·
I tried at the conference to get people to agree that hotswap (i.e. reloading classes in a running system) was something that the JVM needed to add, so that the
by akeefer 16y ago
I tried at the conference to get people to agree that hotswap (i.e. reloading classes in a running system) was something that the JVM needed to add, so that the 99.9% of JVM users programming in Java can have a more dynamic programming experience. It really matters when it's there (especially for people that develop server software, which is a large part of the Java community), and there's a real, ingenious solution already implemented as part of the MLVM project that works well enough for me to use in development all-day every day.
When I brought it up during this discussion, I got nowhere, and people basically looked at me like I was an idiot. It was pretty disappointing to see that a room full of language guys just didn't care about anything that would improve Java itself; the discussion pretty much entirely focused around small-scale stuff that would make it easier to efficiently implement dynamic languages on the JVM.
- delano 16y agoDynamically reloading classes is a nightmare in production systems. I'm not a .NET guy by any means, but one thing that it has that others could use it code signing. This is precisely the opposite of dynamic reloading and it's much more valuable. The win-win is leveraging the power of a dynamic language at development time and the power of something like the JVM at production time.
- akeefer 16y agoYeah, I agree that it's a nightmare in production, but it's absolutely indispensable in development situations where you can tolerate the occasional weirdness or failure. If you're developing a server app (or a thick-client app), avoiding a sever restart every time you change anything is a huge, huge win. And again, it's not like it's not implementable: there's already an implementation, for the JVM, that works.
- delano 16y agoThat's true. It would be helpful to have dynamic reloading as an option with the JVM.