Differences

This shows you the differences between two versions of the page.

--- at:tutorial:symbiosis [2007/07/27 10:25] – changes tvcutsem
+++ at:tutorial:symbiosis [2008/10/22 16:52] – updated tvcutsem
@@ Line 2: / Line 2: @@
 ====== Symbiosis with Java ======
-AmbientTalk is fully implemented in Java and runs on top of the JVM.  Java provides an extensive class library that can be accessed from within AmbientTalk.  In other words, Java classes can be instantiated and messages can be sent to Java objects from within AmbientTalk.
+AmbientTalk is entirely implemented in Java and runs on top of the JVM. Java provides an extensive class library that can be accessed from within AmbientTalk.  In other words, Java classes can be instantiated and messages can be sent to Java objects from within AmbientTalk.
-The reverse, namely that AmbientTalk objects can accessed from within Java is also possible.  AmbientTalk objects are reified at the Java level such that the Java language can be used to send messages and create new objects.
+The reverse, accessing AmbientTalk objects from within Java, is also possible.  AmbientTalk objects are represented in Java as objects implementing a certain Java interface.
-This chapter explains how both sides of this symbiotic relationship between Java and AmbientTalk can be leveraged. The goal of this symbiotic relationship is to complement the advantages of both languages and to alleviate their disadvantages.  For example, AmbientTalk can use the extensive class library from Java and Java can benefit from AmbientTalk's superior concurrency abstractions.
+This chapter explains how to program using this "symbiotic relationship" between AmbientTalk and Java. By means of this "symbiosis" AmbientTalk can use the extensive class library from Java and Java can benefit from AmbientTalk's superior concurrency abstractions.
 ===== Symbiosis Architecture =====
 AmbientTalk has been implemented in Java. Because of this, Java plays two roles: it is both a symbiont language and the implementation language of AmbientTalk (and hence of the linguistic symbiosis itself). The figure below illustrates the different objects that play a part in the AmbientTalk/Java symbiosis, according to the implementation model of Inter-language reflection. AmbientTalk objects are physically implemented as Java objects. This is illustrated by means of the "represents" relationship. To enable symbiosis, additional objects are required which denote the //appearance// of objects from one language in the other language. At the implementation level, such appearances are implemented as //wrapper// objects, which wrap an object from a different language and which perform the protocol mapping which translates between the semantics of the symbiont languages.
@@ Line 125: / Line 126: @@
 <code>
 >def test := /.at.tutorial.symbiosis
->><object:7974034>
+>><obj:{super,super:=,Vector,Vector:=,aVector,...}>
 >test.showSymbiosis()
 ping!
@@ Line 131: / Line 132: @@
 >>42
 </code>
+==== Starting an AmbientTalk interpreter from Java ====
+So far, the examples have illustrated how to reuse Java code from within AmbientTalk. They have shown how to access Java classes, instantiate them and invoke methods on the resulting objects. Moreover,  AmbientTalk objects can be passed as parameters to such Java methods, provided that the method expects an interface type. Whereas the ability to reuse Java code from within AmbientTalk provides  means to e.g. build applications which offer a graphical user interface or which talk to a database, it is also often useful to embed AmbientTalk in an existing Java application.
+Embedding AmbientTalk in an application, requires one to start an AmbientTalk virtual machine, a task performed by the EmbeddableAmbientTalk class. Java programs start a virtual machine by sending an instance of this class the ''initialize'' message. The corresponding method expects the following arguments in order to be able to correctly initialize the resulting virtual machine and evaluation actor: a parsed version of the init file, a set of fields which should be visible in every actor created on the virtual machine and the network on which the virtual machine will broadcast its presence. The example below shows the default settings:
+<code>
+EmbeddedAmbientTalk vm = new EmbeddedAmbientTalk();
+vm.initialize(
+	NATParser.parse(
+		initFile.getName(),
+		Evaluator.loadContentOfFile(initFile)),
+	new SharedActorField[] {
+		vm.computeSystemObject(arguments),
+		vm.computeWorkingDirectory(),
+		vm.computeObjectPath(objectPath) },
+	"AmbientTalk");
+</code>
+The code excerpt also illustrates that the EmbeddableAmbientTalk class provides methods to create definitions for fields such as ''system'' which by default offers I/O through the console and provides access to the program arguments, ''~'' which allows addressing source files located in the working directory (i.e. the directory from which the Java application was started) and the object path (''lobby'' or ''/'') which allows loading files situated in a library path.
+Once the virtual machine is properly initialized, the embedding program can start to evaluate AmbientTalk code. The EmbeddedAmbientTalk class provides two methods to do this, namely ''evalAndPrint'' and ''evalAndWrap''. The former method can be used to write the result of evaluating the code to a PrintStream, which is used for instance to build the Interactive AmbientTalk (iat) shell. The latter can be used to return the resulting object, albeit wrapped as an object adhering to a particular interface. This wrapped object can then be used further by the Java application. In the example below we create a controller instance in a model-view-controller application by evaluating an AmbientTalk source file. This controller will take care of the distribution aspects and will be sent messages by the views when they request changes:
+<code>
+public interface Controller {
+	public void executeEvent(ApplicationEvent evt);
+	public void executeEventWithoutUndo(ApplicationEvent evt);
+	public void undo();
+}
+...
+private Controller controller =
+	(Controller) vm.evalAndWrap(
+		Evaluator.loadContentsOfFile("controller.at"),
+		Controller.class);
+</code>
+The corresponding AmbientTalk code should then return an object which implements the three methods to modify the model, and can be used to detect other reachable controllers with which it can exchange ApplicationEvents.
+<note>
+When starting an AmbientTalk virtual machine from a Java application, the resulting system is inherently multithreaded. The wrappers created by the ''evalAndWrap'' method will ensure that the Java code cannot break the concurrency properties of AmbientTalk. Moreover, by default this wrapper will ensure that the Java thread waits for the result of evaluating the AmbientTalk code which prevents concurrent access on possible Java objects used by the evaluated code. For more detailed information on this topic we refer to our [[ftp://prog.vub.ac.be/tech_report/2007/vub-prog-tr-07-15.pdf|ICDL2007 paper]].
+</note>