While the 'Pitfalls' paper was implemented on top of the Testarossa compiler technology (that underlies the OMR compiler technology), the OMR project has spent a lot of engineering effort to make the technology more modular and easier to interact with.
While it doesn't invalidate the reasoning behind the 'Pitfalls' paper, we think that we're addressing the problem in a fairly different manner: Instead of providing a fully featured JIT compiler that you need to wedge the language into, we've instead chosen to create a more modular system that lets the JIT compiler be more customized to the target language and VM.
Alas, our connection Eclipse is only a legal one. We are an Eclipse Foundation project, but not directly related to the IDE. So won't have any impact on eclim. Sorry!
When you say "native languages" you mean a statically compiled language?
It's been done before with the technology underlying the OMR compiler component, however there is some work that would need to be done to support this.
In principle though, there's no reason it couldn't be done.
Thanks! That's definitely the exact hope we have for OMR as well.
Similarly, improvements in OMR can be shared among all languages using it; ie, because we build both IBM's Java JDK and Ruby on top of OMR, Ruby can benefit from investment in Java, and Java can benefit from improvements in the Ruby community.
Officially, OMR is a meaningless title, like LLVM. Similar to LLVM, it once stood for something, but then we realized that it didn't actually match the project's 'charter' quite as well as we had hoped... but had grown fond of the name (also... finding new names is super hard).
Original definition was 'Open Managed Runtimes', but we can do more than just managed runtimes with OMR technology, and so that seemed to sell it short.
