3 ms·

> Of course, a Java programmer takes it for granted that you restart things every time you change code. But that sucks. Did you not read to the section about j

> Of course, a Java programmer takes it for granted that you restart things every time you change code. But that sucks. Did you not read to the section about jRebel/Play and not needing to restart? But I do agree with you that server startup time isn't as big a deal if you don't have to restart after each change.

aries1980 12y ago
These makes some debugging tricky because of the indirections the frameworks introduce and also comes with performance hit. A long start up time makes more difficult your integration/functional tests that it should.
- neeme 12y ago
  JRebel IDE plugins integrate with your IDE debugger to hide the indirection from you. Works for me. If it does not work for you (or the performance hit is non-negligible) then I suggest you contact their support, they usually fix stuff in couple of days (from my personal experience). And, AFAIK, Play! is also fully debuggable. What's bothering you?
  - aries1980 12y ago
    Yes, the IDE hides the indirections, but not in the bytecode. I mean when I need to profile or debug the binary and optimise e.g. the GC or the heap usage, I am stucked, right?
paulmd 12y ago
Right, but the traditional core ecosystem tools have pretty poor performance (long deploys, etc). Point is there is something there that "needs to be fixed". There are tools that do that, but those are hard sells in an enterprise environment for a lot of reasons. Businesses tend to be wary of building long-term solutions in flavor-of-the-week frameworks/environments/etc. Even when it's just a dev tool, even assuming that the tool behaves exactly like a real production environment, there's overhead to throwing away your workflow that Just Works and getting everyone used to something new. And developer culture right now is that there's a new must-have "Hottest Tool/Framework/Library That Will PUMP UP YOUR PRODUCTIVITY!" every couple months. And rightly or wrongly those tools are often a hard sell to management when there's ongoing costs - we can't get funding for a JIRA server let alone JRebel. Yes, the time it saves me would be worth more than $1.50 per work-day, but that's often not how managers look at it.

aries1980 12y ago

These makes some debugging tricky because of the indirections the frameworks introduce and also comes with performance hit. A long start up time makes more difficult your integration/functional tests that it should.

neeme 12y ago
JRebel IDE plugins integrate with your IDE debugger to hide the indirection from you. Works for me. If it does not work for you (or the performance hit is non-negligible) then I suggest you contact their support, they usually fix stuff in couple of days (from my personal experience). And, AFAIK, Play! is also fully debuggable. What's bothering you?
- aries1980 12y ago
  Yes, the IDE hides the indirections, but not in the bytecode. I mean when I need to profile or debug the binary and optimise e.g. the GC or the heap usage, I am stucked, right?

paulmd 12y ago

Right, but the traditional core ecosystem tools have pretty poor performance (long deploys, etc). Point is there is something there that "needs to be fixed". There are tools that do that, but those are hard sells in an enterprise environment for a lot of reasons. Businesses tend to be wary of building long-term solutions in flavor-of-the-week frameworks/environments/etc. Even when it's just a dev tool, even assuming that the tool behaves exactly like a real production environment, there's overhead to throwing away your workflow that Just Works and getting everyone used to something new. And developer culture right now is that there's a new must-have "Hottest Tool/Framework/Library That Will PUMP UP YOUR PRODUCTIVITY!" every couple months. And rightly or wrongly those tools are often a hard sell to management when there's ongoing costs - we can't get funding for a JIRA server let alone JRebel. Yes, the time it saves me would be worth more than $1.50 per work-day, but that's often not how managers look at it.