Overview

Whenever sedonac is used to compile it a kit, it generates Java bytecode as part of the kit file. Essentially what this means is that all kit files are also Java JAR files. The "lib/sedona.jar" file contains the runtime code used to execute Sedona code on a Java VM.

The "jsvm" Launcher

The jsvm launcher is used to run the Sedona Framework on a Java VM. On Windows the launcher is "bin/jsvm.exe" and on Unix it is "bin/jsvm.sh". See Setup chapter on setting up your environment. To run a Sedona Framework application on the JVM pass the name of an SAB file:

D:\sedona\pub\apps>jsvm test.sab
Java Sedona VM
initKitConsts (234ms)
-- MESSAGE [sys::App] starting
-- MESSAGE [sox::SoxService] started port=1876
-- MESSAGE [web::WebService] started port=80
-- MESSAGE [sys::App] running

Note that jsvm differs from svm in that you don't pass the scode file. Instead the list of kits to load is inferred from the sab file itself. You can deploy the Sedona Framework on a Java runtime with only "sedona.jar" - you do not need to deploy "sedonac.jar" if you only require runtime capabilities.

If you need to boot the jsvm without the launcher, you can use this command line:

java -cp {lib}sedona.jar -Dsedona.home={home} sedona.vm.Jsvm {app}

where

• {lib} is the path to the sedona.jar file (if not in default classpath)
• {home} is the path to your installation (e.g. D:\sedona)
• {app} is the app filename to be executed

Interop

The following table illustrates how Sedona Framework classes are mapped into the Java type system:

Sedona	Java
void	void
bool	byte
byte	byte
short	short
int	int
long	long
float	float
double	double
sys::Obj	java.lang.Object
sys::Str	sedona.vm.StrRef
sys::Kit	sedona.vm.IKit
sys::Type	sedona.vm.IType
sys::Slot	sedona.vm.ISlot
sys::Component	sedona.vm.IComponent
bool[]	bool[]
byte[]	byte[]
short[]	short[]
int[]	int[]
long[]	long[]
float[]	float[]
double[]	double[]
sys::Obj[]	java.lang.Object[]

A few things to note:

• Most of the primitives and arrays map as expected
• Sedona bool is mapped to Java as a byte with zero indicating false, one indicating true, and two indicating null
• In general most Sedona Framework classes are passed around as java.lang.Object on the Java side. This means you can write Java code that works with the Sedona Framework without complicated classpath issues - you only need to include "sedona.jar" in your classpath.
• Some special classes like Kit, Type, Slot, and Component receive special support to implement a predefined Java interface. This makes it easy to write Java code that uses Sedona reflection.
• Sedona strings are stored in byte arrays with a null terminator. This is modelled in the Java VM using the StrRef class, which consists of a byte[] reference and an offset into that byte array.

Native Methods

In order to run on the JVM, every native method is required to have a Java implementation. Native methods are implemented in a Java source file using the following naming convention:

• For kit myKit, Java package name is sedona.vm.myKit
• For class MyClass, Java class name is MyClass_n
• Java method name same as Sedona method name
• Java method always takes an extra Context parameter

The Java method is always defined as a static. If the Sedona method is not static, then the Java method has an implcit first parameter typed as Object:

// methods for acme::Foo
class Foo
{
  native static int bar(float a)
  native void baz(long a)
}

// Java implementation of native methods
package sedona.vm.acme.Foo;
public class Foo_n
{
  public static int bar(float a, Context cx) { ... }
  public static void  baz(Object self, long a, Context cx) { ... }
}

The "sedona.jar" included in the distribution includes native methods for sys and inet. Any additional native methods must be made available in the Java classpath.