Subj : Re: wrestling a rhino down to the ground (experiences with 5R5 source) To : mda@discerning.com From : Igor Bukanov Date : Fri Aug 01 2003 11:55 am Mark D. Anderson wrote: > I've been playing with the Rhino source code (cvs, mozilla/js/rhino) a > little bit this past week with an interest towards how useful it would > be for some JavaScript code transformation tools, using it as a pretty > printer, potentially a javadoc-like tool, etc. > > This is a summary of what I've confronted so far and what I did about > it, when I could figure anything out. > > 1. org.mozilla.javascript.tools.* is no longer part of the js.jar . > This is a change from 5R4_1. There appears to be no target to produce > a different jar containing them (say jstools.jar). That is strange, build.xml for ant from mozilla/js/rhino includes all the tools into js.jar by default. > Furthermore, > js/rhino/toolsrc/build.xml wants to download some swing-ex stuff > before it does anything. > > To work around this, I figured out to do: > cd js/rhino > ant -Dswing-ex-available=true > > and make my CLASSPATH be: > /Users/mda/workspaces/mozilla/js/rhino/build/rhino1_5R5pre/js.jar:/Users/mda/workspaces/mozilla/js/rhino/toolsrc > (that is, just use class files directly from the toolsrc area). Well, the download is for debugger and ant should do it once only if files are not there. .... > 3. The indenting in the decompiler is hardcoded. > There is an "indent" parameter, but it is only the initial top-level > indent. > > To deal with that, I made a small edit in Parser.java: > static int OFFSET = 4; // how much to indent > static int SETBACK = 2; // less how much for case labels > > public static void setDecompileOpts(int offset, int case_setback) > { > OFFSET = offset; > SETBACK = case_setback; > } > This is a reasonable suggestion, but it should not be done via mutable static variables. Rhino can be used by 2 independent application under the single JVM and static variables that present already cause enough troubles. > 4. The debug flags in Context.java are final. > I can't believe there is really any performance benefit to this, so > I edited Context.java to have: > // debug flags > static boolean printTrees = false; > static boolean printICode = false; > > public static void setPrintTrees(boolean pt) {printTrees = pt;} > public static void setPrintICode(boolean pi) {printICode = pi;} > > Note that this is particularly necessary because Node.toStringTree > checks the value of Context.printTrees (rather than just doing what > it is asked). The benefit is simple. It allows to shrink Rhino classes size and memory consumption and not to include the code useful only for debugging. In memory constrained Java embeddings (like PDA/cell phones with JVM) this is essential and every kilobyte helps. > 5. There appears to be no easy way to retrieve source name and line > number from NativeScript. You can do it currently by using the debugger interface, see org.mozilla.javascript.debug.Debugger.handleCompilationDone and methods in org.mozilla.javascript.debug.DebuggableScript. But if you need a more direct way to get that info, I suggest to file an enhancement report for Rhino at bugzilla.mozilla.org. As regarding the rest of questions/suggestions about Parser/TokenStream details, note that Rhino needs to interpret JS with reasonable speed/memory consumption and to get that while supporting pure interpretation and byte code generation some parts has to be done in a less generic way then possible. But IMO for pretty printing/source transformation you do not need access to the parser tree. If parser would have an option to include line number information/comments into token character array which is effectively a serialized version of parse tree, then source code transformer can work with that form directly and not depend on details of Parser/TokenStream. Regards, Igor .