From: Pat Niemeyer <pat@pa...> - 2005-06-17 17:42:59
> What about anon. comments on the wiki:
> Won't the JSR 199 (http://jcp.org/en/jsr/detail?id=3D199) obviate
> BeanShell JSR or perhaps make some of it redundent?
> If there is a JSR 199, then much of a Java compatible syntax interprete=
> or script language would already be available. Of course, Beanshell and
> PNuts and other languages add scripting extras, but should these extras
> just be in a script syntax extension JSR? Not sure how exactly the JSRs
> interrelate, if they do at all.
Unfortunately JSR199 (and 269, the annotations API) do not go far enough
in terms of defining a standard AST model for the Java language to be
useful to us... For some reason all of the JSRs have stayed away from
this job and I'm not sure that it's appropriate for JSR 274 (BeanShell)
At some point one of the JSRs has to tackle this and when that is done we
can definitely use those interfaces for our internal ASTs...
Or, if more generally you mean - what good is BeanShell if you can just
call the compiler, well interpreting standard Java code is really only
half of what BeanShell does... Scaling Java down to scripting
applications (interpreting loose types, fragments, etc.) is what makes it
useful in a broad range of applications. You could certainly build a
scripting language that uses this API to compile things for you... but th=
parsing and execution is not really the hard part... figuring out what d=
with with some crazy ambiguous name that the user just typed and things
like that are.
Take a look at the CVS history for the BeanShell classes... you'll find
that the ASTs that implement the core syntax hardly *ever* change...
essentially only when we introduce some totally new grammar element (like
the enhanced for-loop). Some of them look essentially the same as the da=
I wrote them... But NameSpace.java, Name.java, things like that have
thousands of revisions. That's where all the action is in a dynamic