Start

Messaging between Java and the page

Send messages both ways between your Java code and the page, and build a small request and response layer on top.

Java and the page run in one process and exchange messages directly. There is no HTTP server and no socket between them.

Plain messages

window.onMessage(text -> window.postMessage("You said: " + text));   // page -> Java -> page
jolt.postMessage("hi");                       // page -> Java
jolt.onMessage(message => console.log(message)); // Java -> page
  • window.eval(script) runs a script in the page and returns a CompletableFuture<String> with the JSON result.
  • window.addInitScript(script) runs before the page's own scripts.
  • Every Application and WebWindow method may be called from any thread.
  • app.openExternal(URI) opens an http, https or mailto address in the user's browser or mail program (since 0.2.5).
Message listeners run on the UI thread. Never block there, for example by calling .get() on an eval result. Hand slow work to another thread and post the answer when it is ready.

Calling Java functions from the page

For real apps, add a small request and response layer on top of messages. The page sends {"id": 1, "method": "notes.add", "params": {...}} and Java answers {"id": 1, "result": ...} or {"id": 1, "error": "..."}. The notes example has both halves (Rpc.java and ui/index.html), about 40 lines each, and they work with any JSON library.

new Rpc(window)
    .on("notes.list", params -> store.list())
    .on("notes.add",  params -> store.add(params.get("text").getAsString()));
const note = await call('notes.add', { text: 'Buy milk' });

Where the messages come from

Only pages your SecurityPolicy trusts can reach onMessage, so a page you did not intend to load can never call your Java handlers.