Thanks for asking :).
Indeed, the first thing is to have an open-source solution for Java. The main reason for this is that there are people that would like to play with Moose, and within the context of Java, I often get the feedback that people expect the availability of open-source solutions. I know that VerveineJ is available if you ask, but this step of asking looks expensive in the eye of a casual visitor. I would like to achieve a solution that can provide a one-click experience (or something close to that).
Besides being open-source, the main technical difference is that the concrete visiting and model building code is built in Pharo, not in Java. It relies on JNIPort to communicate with the JDT parser, and the visitor on the Java side just forwards the calls to the Pharo code. This implies that we can do live analysis without the intermediary step of generating a large MSE file. However, we are still at the beginning, and it can be that at the end it will prove that there are technical impediments. In that case, we will fall back to a Java-based implementation similar to VerveineJ.
I want to focus this month on getting far enough to understand the limits. There are many details to explore, and that is why I would benefit from help from the community.
If it works, the side-effect benefit of this project is that it will document that Pharo is actually able to communicate with a Java library for real use cases.