Hacker News Reader

Comment by daxfohl | Hacker News Reader

> Because of the way Node works we can attach debuggers, and set breakpoint steps through the code. If you wanted to debug these groovy scripts in the past, you would make some code changes upload it to the edge layer, run it, see if it breaks, make some more changes, upload it again, and so on

Can anyone expand on this? I haven't worked with Groovy, but most languages have debuggers that let you attach to an existing process. Is this something especially great about Node, or something especially horrible about Groovy?

View on HN

Yes, Groovy does have a debugger. It is just the Java debugger. I use it nearly every day to work on a Grails project. Also, yes, you can attach it to an existing process. As far as I can tell, that comment doesn't make any sense.

I haven't used Groovy, but some quick googling suggests it might have issues with remote debugging.

Also, if that quote is related to the surrounding paragraphs, it sounds like the biggest upgrade isn't so much the node.js debugger, as it is the services being rewritten in a decoupled, non-monolithic way. So now devs can test with local copies of software, instead of requiring an entire infrastructure to be online just to test a single function.

The decoupling and microservice mindset aren't specific to node.js, you can achieve those benefits in any language, however it is more idiomatic in node than other stacks,

Apache Groovy (around v 1.0 or 1.5) used to produce bytecode that could easily be decompiled to Java code, but since version 1.6, the bytecode generated was changed so it couldn't be decompiled with the tool I was using at the time -- I forget what it was, could have been JAD. I know the JVM situation has changed a lot since then, but that breaking change was just one of those many little things that put people off using Groovy for anything more serious than quick'n'dirty scripting. I wouldn't imagine it would be easy to write a Groovy debugger if the bytecode generated is still so non-standard it can't be decompiled to Java source.

Why would you need a decompiler to write a debugger for Groovy? The groovy compiler supports including source code line numbers and variable names in compiled jar files (just like Java). As a result you can use any Java debugger to debug Groovy.

Also, why would you expect that Groovy can be compiled and then decompiled to Java? This doesn't even work 100% going from Java to Java, and Groovy is going to have idioms that doesn't map easily to Java idioms.

> The groovy compiler supports including source code line numbers and variable names in compiled jar files

I haven't used Groovy since v 1.8, and certainly didn't know about this facility then.

> why would you expect that Groovy can be compiled and then decompiled to Java?

It worked in Groovy 1.0, and the decompiles to Java were useful back then when Groovy often had unexpected behavior.

I'm pretty sure Groovy has a debugger too.

Reply on news.ycombinator.com