If you've read through the background section, you probably have some idea of what the tool is intended to do. There's really a few separate phases to my vision for it, and I'm not sure if anything other than the first one is really all that possible.

The Initial Goal

My first intent was really just to have a way to write javascript using the Java syntax, IDE, and compiler. That's still the first-order goal of the project: just to make javascript a bit more refactoring-friendly and to make the OO syntax less punishing by writing in Java instead. The Java wouldn't need to even run properly at that level so long as it compiled and so long as the javascript it produces works.

The goal really breaks down further into a bunch of subtasks. The simplest one is just parsing a normal Java class and performing the most basic of transformations on it: declaring variables with var when necessary, appending "this." to member variable accesses, declaring constructors as functions and ensuring they always come first in the file, handling subtyping, etc. Things get a bit more complicated when it comes to features that aren't in Java, like eval and foreach and closures, but there are ways to hack those in too. There are a few much more complicated goals that would be really nice to have too, though I'm not sure how possible they are:

• Support a limited form of method overloading. There's no method overloading in javascript, but it would probably be possible when coming from Java by detecting overloaded methods and hacking up a unique name for each overload, which the callers would then use instead. In javascript it wouldn't be proper method overloading, but it would be in Java. The tool would have to be very careful, though, about complaining about method overrides that depend on dynamic dispatch (i.e. foo(Object, Object) and foo(String, Object)).
• Support packinging/namespaces. Javascript has no built in package or namespace mechanism, and once you get beyond a few dozen classes you really start to miss having some way to logically organize everything. It seems like this one shouldn't be too hard.
• Handle proper ordering of the files. One of the most maddening parts of javascript is the fact that your classes aren't really classes, they're code that generates a class at runtime. That means that if class Sub extends class Parent, class Parent had better already be defined when Sub gets defined or else you won't get any inheritance. It's a serious headache once you get any sort of deep inheritance hierarchy. There might be other ways to solve it in pure javascript using wrapper methods to generate classes or something like that, but I never figured one out, and it seems like it would just be easiest to do static dependency analysis at gen time and then spit out the files in the proper order. Note that dependency problems also come into play if you have any sort of static class references.

On top of all of that, it should be possible to write unit tests in Java (so they can be refactored as well) and have those turned into javascript unit tests. Finally, one more meta-goal is that the tool should complain whenever it encounters a construct that it can't process correctly, either because it won't work in Javascript or because it simply hasn't yet been coded to do that, rather than just silently generating bad javascript.

DOM Libraries

If anyone ever actually uses the tool, sooner or later they're going to want to write a bunch of DOM stuff (I certainly would have if I'd had this while doing my prototype work). As someone who was pretty new to DOM manipulation, it was definitely frustrating that the documentation isn't all that great, required constantly looking things up on external web sites (instead of having my IDE auto-complete it for me), and it was difficult to figure out from the documentation what would work on which browsers. Having a full set of DOM interfaces, at the very least, would make it much easier for an unfamiliar programmer to figure out what to do, and having different subclasses (or different implementations, see the next section) of those interfaces would make it much more obvious which things work on which browsers. That could be a daunting task, especially implementing the methods, but just having the interfaces coded in Java such that a good IDE can interpret them would make it much easier to work with.

Identical Runtime Behavior

I think it would be even cooler if all the helper classes and such could be coded in such a way that running the Java code would behave exactly the same as running the javascript code. Unit tests could then be coded in Java and run in Java. That by itself seems nice simply since the tools to run Java unit tests (and to automate them) are pretty advanced compared to the tools for Javascript, but I think some real cool things could come out of having different library implementations that correspond to different web browser versions, so that it would be possible to run your unit tests against different simulated browsers to check for incompatibilities.