Hi Jim,
... cut ...
If one uses BSF 3.0 then one can also use JSR-223 (a.k.a. "Java 6
scripting") scripting engines, as long as their Java level does not
exceed the installed Java runtime environment.
---
Ad BSF 2.4: this is the "classic" scripting framework, originating in
Java 1.1 (!), nowadays using Java 1.3 as its base level. There are
quite a few scriping engines available for it, from Javascript
(Rhino) via XSLT (sic! using Xalan) to Prolog (JLog), cf. the BSF
homepage. Next developments that I intend do do will be a scripting
engine that will incorporate JSR-223 scripting engines into the BSF
2.4 framework. Also, another idea would be to create a JSR-223 bridge
to BSF 2.x (to make also those scripting engines available, that do
not exist for JSR-223).
Yes, I'm thoroughly familiar with BSF and used it back in the days
before JSR-223 appeared (and ranted about how Sun had yet again failed
to properly embrace the community's de facto standard with Java).
I was asking about what you're working on for OpenOffice with BSF. Is
there a place where this work is publicly available?
Hmm, yes and no.
:)
What I do is helping maintain BSF 2.4 and getting BSF 3.0 out the door
in a GA form.
W.r.t. OpenOffice: I use BSF to bridge a scripting language named ooRexx
(Open Object Rexx, cf. <http://www.ooRexx.org>) to/from Java. ooRexx is
an object-oriented successor to a "human centric" scripting language
which originated almost 30 years ago on IBM mainframes, named REXX.
(Version 4.0 of ooRexx, a major rewrite/overhaul, is being developed
right now and it is expected within the next few months).
Rexx was later used as a scripting language on Amiga OS, but also on
IBM's OS/2 1.3 Extended Edition, and the 32-Bit version of OS/2 (the
portable Microsoft version of the 32-Bit OS/2 was originally called OS/2
NT, later, when IBM and Microsoft broke up, it was called Windows NT,
"NT" meaning "new technology").
To make a long story short: because of the design principles of REXX
(author Mike F. Cowlishaw, an English gentleman) it is truly an easy to
learn scripting/macro language, ideally suited for end-user type of
programming. The object-oriented successor from IBM followed the same
design principles and got opensourced about four years ago. As I am
situated at the "Wirtschaftsuniversität Wien" (Vienna University of
Economics and Business Adminstration), MIS department, I tested ooRexx
with end-user kind of students, to see whether it is possible to teach
object-oriented concepts, and later, being astonishingly successful with
it, extended that to remote control/script Windows and Windows
applications via D/COM|ActiveX.
In parallel I was looking for a platform independent application of
creating scripting/macro programs with ooRexx. I.e. programs that could
execute unchanged on Windows and Unix operating systems, still being
able to have end-user type of students being able to take full advantage
of it. That's where BSF comes into play and my interest in it,
eventually yielding BSF4Rexx (cf. the current GA-version at
<http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/>, but please note
the latest test versions will be at
<http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/old/2008/>, where today or
tomorrow a new version will be placed, that overcomes the dynamically
defining class problem).
Now, one thing end-user kind of programmers can shine is with
"remote-controlling" end-user applications like Microsoft Office. Having
an openplatform automation/scripting infrastructure available (BSF, and
in my case BSF4Rexx), enables me to use OpenOffice for the same purpose.
This is also important for the students, as they get to learn a free and
legally owned office product, that does not lock them in into a single
operating system, but allows them to freely choose an operating system
of their choice.
Such students, having these kind of experiences, are also "ambassadors"
to the "outside" world, being able to communicate that it is a reality
that OpenOffice can be used *and* automated on multiple platforms.
However, in order for them to being able to tackle OpenOffice
programming a few hurdles need to be mastered:
* the UNO framework,
* the programmatic interface (why and how does one need to
constantly query interfaces),
* and most importantly, documentation, nutshell examples and the like.
For that reason I have been trying different routes:
* assign interested students tasks which they need to solve and
document them in English (such that everyone interested on the
world would be able to study it)
o making them publically available; cf.
<http://wi.wu-wien.ac.at/rgf/diplomarbeiten/> and look for
the keywords "BSF", "BSF4Rexx" and or "OpenOffice", "OOo";
please note, even those works that are not so "shiny" are
still quite helpful for newcomers and costed the students an
incredible amount of effort (especially the very first steps),
o the set of foils that introduces is mostly in English, with
German ones at the end
(http://wi.wu-wien.ac.at/rgf/wu/lehre/autojava/material/folien/AutoJava_10_BSF4Rexx_4_OOo.pdf)
+ it may be the case that for the fall/winter semester
an English set of foils on Automating Windows and Java
with ooRexx get created (depends whether English
lectures of it are offered at the University)
* have students supply OOo snippets,
* using ooRexx language features, make supporting OpenOffice
programming as easy as possible
o using BSF one can use the Java bridge to UNO instead of C++,
o BSF4Rexx would allow to transcribe (strictly typed) Java
programs to untyped (dynamically) typed ooRexx programs,
o having noticed the incredible importance and cumbersomeness
of constantly invoking Runtime.queryInterface(...) an
easier, "Rexx-like" alternative has been made available: it
is sufficient to send the (unqualified!) interface name to
the service object, which alleviates the end-user programmer
from a lot of (cast) coding; e.g.
<http://codesnippets.services.openoffice.org/Writer/Writer.PrintExistingDocument.snip>
(the tilde ~ is the message operator; left of it is the
receiving object, right of it the message that gets sent to it)
o currently, better support for creating ooRexx macros has
been the focal point (hence chasing down the class loader
problem among other things).
It would be possible to enhance the support such, that no explicit
interface requests are needed (like for OOo Basic), but I never made
that version available to students! (Brief reasoning: allowing to forgo
querying interfaces may ease programming for experts, but not for
end-user type of people as they cannot infer from the names of methods
and attributes how the interface is named, if they need to get to the
documentation. Getting used to interface names allows them to build a
conception of how OOo is structured and then are able to infer the
interface names from their needs.)
There is a lot more that has gone into the UNO support module "UNO.CLS",
and especially into the OpenOffice support. There is even a reference
card listing supporting OOo routines, classes and the like (cf.
<http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/current/refcardOOo.pdf>).
---
If you wonder about the applicability of ooRexx: the city of Vienna is
one of the adminstrations that has a strategy in place for moving to
opensource. In this process they are also checking out and deploying
OpenOffice. A year ago there were two little projects, in which
OpenOffice was used to automate business processes in a platform
independent manner. The most interesting thing for me was the fact, that
both projects were nicely mastered by students, whom I would classify as
being MIS-interested "end-user-programming" kind of persons.
It was really great to have witnessed that a "human-centric" language
like ooRexx bridging to Java with the help of BSF4Rexx can make
end-users productive in a suprisingly short timeframe (no need for them
to learn C++ or be really Java-savvy, they only needed to learn how to
read the Java documentation).
I do belive that the place to build consensus is around JSR-223 now,
and a bridge to BSF would be dandy. Right now few language
implementors bother to support either of them.
The point here is: if using BSF 3.0 then you would use the package name
"javax.script" and all the classes therein. As if you had the Java 6
JSR-223 implementation at your hands! And in effect, it *is* a JSR-223
implementation using the same package name and class names and methods
in those classes as defined in JSR-223!
So the code you write will run and remain unchanged, if using Java 6 or
later. This is because in those JRE the native "javax.script" package
will have precedence over an existing BSF 3.0!
So in effect, one could change/enhance/supplement the OpenOffice
scripting framework with one that interfaces with JSR-223. Bundling the
AL 2.0 BSF 3.0 with OpenOffice would make sure that it will run on pre
Java 6 versions of Java or on Java implementations, that do not supply
the JSR-223 Java scripting interface.
There would be no risk here whatsoever, but only enhancing the
applicability in a tremendeous manner.
[And BTW, if Firefox, Opera etc. would employ BSF 3.0, then they could
supply a wealth of scripting languages out of the box on pre Java 6
installations as well. Someone would have to tell them... ;) ]
Maybe all this could be made into a presentation for the upcoming OOo
Con in Peking, such that one would also be able to discuss all of this
(and all the opportunities that go with it) in depth?
So there is a further issue because that that means JSR-223 (and BSF)
support is usually third-party which means we would like the language
implementors to at least provide Maven repositories for their work
(which few do). The Ivy RoundUp project (which G4OO supports) is one
of the helpful workarounds by providing a repository for Ant-based
recipes to support artifacts that aren't in ready-to-use JAR form.
http://code.google.com/p/ivyroundup/
The effort at https://scripting.dev.java.net/ has problems in that it
has so far only supported Java 6 for it's binaries and doesn't (yet)
have a Maven repository either. IFCX has an interim solution for that
here:
http://ifcx.svn.sourceforge.net/viewvc/ifcx/thirdparty/scripting/
Will have to check out those interesting links of yours, Jim!
Good night!
---rony
