Bashj programming guide

This is a complement to the general bashj presentation page.

Understanding the architecture of bashj

The key idea behind bashj is the execution of a bashj server. It is a JVM instance performing essentially two tasks

1. translating bashj code into bash code
2. execute any java method call for any running bashj client

The benefit of this is the extreme efficiency of this minimal architecture, taking advantage of combined strengths of java & bash.

The following slide explains the global flows of bashj

Bashj overview.png

But the developper of a bashs script should be aware of the fact that any global component of the JVM (static variables, Threads,...) will be shared with all other bashj clients launched.

For instance if a client modifies a static variable during the execution of a bashj script, the next execution of the same script will start with the modified value of that variable. This may be convenient ... or not, depending on siuations.

Similarly, if a bashj client launches a Thread without closing it, this Thread will survive in the server JVM (which may not be the intention).

Composition of a bashj script file

A bashj script contains typically 3 components

1. the header
2. the java section
3. the bash section

Header

The shebang header is a mandatory line

#!/usr/bin/bashj

Java section

The java section is optional. Without this part, the script behaves exactly as a bash script file with the same content.

The java section starts with a line

#@java

and it ends with a line

#@bash

Bash section

The bash section is also optional.

If absent, the execution becomes a pure java 'interpreter' (see below).

If present, it includes standard bash lines, with the possible presence of java calls.

The java calls are detected by the processor thread. They are coded:

<class>.<method>(<arguments...)

For instance

Math.hypot(4.0,3.0) 

The result of such calls may be used to produce bash shell values, and for instance:

echo Math.hypot(4.0,3.0) 

ZZ = Math.hypot($XX,$YY) 

It is recommended not to use complex bash expressions as arguments to java method calls.

It is not possible to embed bashj java class calls (  Math.log(Math.sin($X)) will not work).

Java static fields are detected like java methods, like

piValue=Math.PI

Knowing how the detection / substitution works, it is the developer responsibility to avoid in the bash section unintended detectable expressions. The source processor is unable to handle and avoid all complex bash constructions. For instance this bash line

tr Math.PI z < $FILE  # Noooo !

is strange but valid with bash, but it is likely to raise unwanted results with bashj...

Using bashj as a pure java 'interpreter'

It is possible to create a bashj page without any bash line. In this case, the interpreter will automatically call and execute the method  static void main(String... a) , as in this example:

#!/usr/bin/bashj
#@java

static void main(String... a)
{u.p("Hello world, welcome to bashj");}

This minimal but complete code will execute as expected.

Convenience u methods

Various convenience methods are include with bashj. It is recommended to cheks their list using the command

bashj -u

or their javadoc.

Swinging bash

As any other java package, it is possible to take advantage of Swing UI components, and this provides (through bashj) a windowing interface to bash.

Here is a minimal example:

#!/usr/bin/bashj
#@java
import javax.swing.JFrame;
import javax.swing.JOptionPane;

static void main(String... a)
{JOptionPane.showMessageDialog​(new JFrame(),"Welcome to bashj swing UI");}

Inter process communication using bashj

Given the persistence features of the bashj server, it is easy to set up fast IPC between bashj scripts.

The following u methods allow to set() and get() inter process variables:

public static void set(String key,String value,boolean scriptSpecific,boolean persist)
public static String get(String key,boolean scriptSpecific,boolean persist)

public static void set(String key,String value)
public static String get(String key)

The scriptSpecific flag indicates whether this value is shared or not with other scripts. These values will be kept during successive calls of the calling scripts, until the server is stopped.

The persist flag indicates whether the values should persist in the host  file system. These values will be saved when the server is stopped.

The simple calls (without boolean parameters) assume scriptSpecific is true, persist is false.