3 ms·

That's really cool. I think there's still a lot of untapped potential in Java & Kotlin tooling, despite how far ahead of most other languages the IDE story is t

That's really cool. I think there's still a lot of untapped potential in Java & Kotlin tooling, despite how far ahead of most other languages the IDE story is there anyway. Your HTTP use case was a good one as that is still very tedious generally. There are some less well integrated solutions that have come up from time to time, but in general being able to run the HTTP request once and from then on mock the request/result easily would be great. Hot reload seems to be something that comes and goes. Android Studio has had it and then not had it and then had it again several times. The cases in which it works seem to be fairly arbitrary. Improvements in this space would be great.

artpar 3y ago
Yeah I understand what you mean when you say hot reloading is something that comes and goes. There are a variety of edge cases even though there is increasing support from the jvm vendors and also jrebel has been done a lot of work in that direction. We are trying to rely on those efforts for atomic run difference detectors. In our internal testing we figured that for method level changes even the default jvm vendor based hot reloading works to a great extent for most modern stacks (spring/dropwizard/play framework) . About android, just want to point out that our current builds are not compatible with android since dalvik has different ways of working (register based) compared to desktop jvms (stack based)