Another route is to generate bytecodes, but make sure the generated bytecodes are the same as what a Java compiler would generate. Then you can use a java decompiler on them. Probably doesn't help in the debugger, but does help you understand what your compiler generates.
Best, Martin John Wilson wrote: > 2009/11/22 Matt Fowles <[email protected]>: >> Robert~ >> >> Ease of debugging mostly. Our production environment always goes straight >> to bytecode, but when we are debugging the compiler it is much nicer to be >> able to step through java code and get links from it back to compiler code >> the generated it. > > > We looked at this in the early days of Groovy. It my be a decent route > for your language but it wasn't great for Groovy. The problem is that > there are some Java features (e.g. checked exceptions) which are > enforced by the compiler but not the JVM. If your language shares all > the restrictions that the Java compiler enforces then it's a perfectly > good option. Groovy doesn't share many of the Java restrictions so it > didn't seem worth it. > > Also generating bytecodes is not that hard once you get up the > learning curve a bit so I think most people end up just going straight > to bytecode because it's easier in the end. > > John Wilson > > -- > > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=. > > -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=.
