Iava Version 0.6
Table of Contents
Copyright Notice
What is Iava?
What is the difference
between Java and Iava?
What can Iava be used for?
Other scripting
languages for the Java platform
Installation and Usage of Iava
Version and Change History
Known Limitations and Bugs
Copyright Notice and Terms of Usage
The Iava source code and binaries are copyrighted 1998 by Mathias
Richter. Permission for the use of this
software and the source code is granted for non-commercial use
exclusively under the following terms:
-
This software is provided "as is". Under no circumstances may the copyright
holder and author of this
software be held liable for any damages or losses resulting in the
use of this software.
-
This copyright notice must always be part of all copies or redistributions
of this software (source code
and binaries (ie. class files, jar files, etc.).
-
I (Mathias Richter) as owner of the copyright am provided with information
about modifications, bugs,
bug fixes and uses of this software (mathias@acm.org).
For commercial use please contact me directly (mathias@acm.org).
By keeping a copy of this software (source
code and/or binaries) you demonstrate acceptance of these terms.
What is Iava?
Iava is an interpreter that implements a subset of the JavaTM
programming language.
The philosophy of Iava is to provide a scripting language that integrates
seamlessly with
compiled JavaTM applications and the
JavaTM platform. The motivation for using
the JavaTM
language syntax is to provide the possibility to migrate scripted
code into compiled
code without having to rewrite it. Thus, features of an application
can be imlemented as
scripts and after they have proven useful, they can be integrated into
the compiled
code by copy-paste.
By using a subset of the JavaTM syntax
and semantics, adding scripting to applications
does no longer force developers to maintain two different systems with
two different
languages. The border between compiled code and scripted parts of an
application
becomes (almost) invisible.
What is the difference
between JavaTM an Iava?
There are no class declarations in Iava. This means you cannot define classes,
or anonymous classes in Iava scripts. Apart from this limitation, Iava
provides the
full syntax and semantics of the JavaTM
programming language. Iava scripts can declare
public or private methods. Public methods can be invoked by scriptable
objects, i.e. objects embedding the Iava interpreter. Private methods
are only
accessible from within scripts (using this mechanism, fpr example ActionListeners
can be
created and used from within scripts, refer to the API
documentation of the Scriptable
interface for details).
What can Iava be used for?
There are lots of good reasons for integrating scripting into an application.
In practice,
a lot of examples of scripted systems come to mind: The first to name
is certainly the
UNIX system (closely followed by almost every serious operating system).
Other
prominent examples are Emacs and for Macintosh programmers the text
editor Alpha
(based on Tcl). Here is just a short list of those motivations
that spawned the Iava project:
-
Extensibility and adaptability: Applications providing scripting
can be augmented
by functionality as needed and without recompilation. Applications
can "open"
dedicated elements of their architecture for scripting and leave others
"closed".
-
Prototyping: Certain functionality of application systems can be
realised using
scripts to prove their usefulness. The decision to "hardwire" some
scripted part
of an application into the compiled code can be made later. Because
Iava has
the same syntax and semantics as JavaTM,
this "hardwiring" is reduced to copy-paste
and recompile.
-
Component interconnection: Scripting provides a very interactive
means for
interconnecting software components like JavaBeans in an application
environment.
-
Testing: A scripting language allows the creation of test scripts
which allow for the
interactive execution and analysis of test cases.
Other scripting
languages for the JavaTM platform
There are quite a few scripting languages that provide integration with
the JavaTM platform. There
exists an excellent site which summarises existing languages
for the Java virtual machine.
Installation and Usage of Iava
Iava needs Swing from version 1.01 in order to be used with the IavaConsole
window. Follow
the installation instructions for Swing to set the classpath.
Just plug the location of the file "iava.jar" into your classpath.
The Iava interpreter can be invoked
on the command line by java Iava.Iava [-p] [-w | <sourcefile.iava>].
The option -p turns on profiling to the file ./profile.txt
while the option -w brings on a simple
interpreter window with a few self-explanatory features. Invokation
without a source file starts
the Iava command line (tab at the end of a line serves as a line continuation).
For integrating Iava with your application to make it scripted, please
refer to the API documentation.
Version and Change history
Version 0.3 was the first version released (to a close circle of friends).
Changes from Version 0.3 to Version 0.4
1. Changed the IavaConsole from AWT to Swing 101 and thus eliminated text
selection bug from
java.awt.TextArea. Changes to the GUI of the IavaConsole
include separate windows which allow
the observation of declared symbols and methods.
2. Added IavaRuntime scoping policy (global scope, script scope).
3. Added listener infrastructure for method declaration/method call
observation and symbol
declaration observation.
Changes from Version 0.4 to Version 0.5
1. Exceptions and Errors which occurred as part of the execution of a scripted
method
called from compiled code are now accessible. The
class IError has been made
public for that purpose and provides a method for
getting the original Error or Exception
it wraps.
2. Fixed a bug in the interpretation of primary expressions: calls
using "this" as a reference
did not work properly in verson 0.4.
3. Fixed a number of minor bugs.
Changes from Version 0.5 to Version 0.6
1. Fixed a bug in the logical operators "&&" and "||".
2. The Iava interpreter used to output errors/exceptions directly to
System.out/err. This
was impractical, because embedding classes might
want to be informed about errors
in script execution. So now, the interpreter methods
"interpret" and "interpretFile" throw
IErrors (which are derived from Error and do not
have to be caught by calling code)
which the calling code is free to catch or ignore.
3. Took out the classes IavaListener and IavaTalker of the framework.
Known Limitations and Bugs
The following bugs are known to me:
Unfixed as of Version 0.6
-
In the HTML-Documentation generated with javadoc, the documentation for
Scriptable
contains a code example. In the middle of the example, the code is not
displayed properly.
The displayed code doesn't make sense at all. I'm working on that.
Unfixed as of Version 0.5
-
Important: If a method was overriden in a class used by a script, and the
script tries to
call the original method in the superclass by referencing "super",
the call will still be directed
to the overriding method. References to not-overridden methods and
fields in the superclass
using "super" as reference do work, however.
Unfixed as of Version 0.4
-
If a script calls a method which cannot be found (because it is not defined),
the interpreter
does not issue an "undefined method error" but sometimes throws a "null
pointer exception".
Unfixed as of Version 0.3
-
No class declarations whatsoever. This is not a bug, but a limitation of
the reflection
API. As soon as Sun extends reflection to allow the dynamic creation
of classes,
I'll implement it.
-
No labeled statements. But hey, it's better practice to use continue
and break
without labels, anyway. This is not a bug, because I don't like
labeled statements
and hence didn't bother to implement them.
-
No assignment operators yet. IMHO, they're syntactic sugar and too much
sugar
is not good for the teeth, not? But, hell, I might implement them,
if you insist.
-
Due to a bug in the reflection API, using reflection to invoke a public
method of an
object whose constructor is not public results in an error. This happens
for example
when you use Enumerators. This bug has already been registered with
the Sun bug
database.
-
Exceptions sometimes show the stack trace of the interpreter code and not
the
stack trace of your scripted code. There's not much I can do about
this, because
JavaTM only allows to append
to a stack trace, but not to manipulate it in other ways.