The goal of Bck2Brwsr Java virtual machine was to create small, fast, but limited Java runtime. One of such limitations was no support for starting new Threads - when attempted the VM thrown SecurityException.
However many people expressed interest (like issue 6539) in having full threads with classical Java semantics supported. In general it is possible, just it requires more complicated and slower code to be generated. Anyway, if there is a support, it is worth to try it.
The rest of this page outlines the expected steps to get threading back to browser and status of their implementation.
Milestone 1: start/wait/notify
The goal is to get the basic Java threading primitives running. We need a sample application that will start multiple threads do some communication between them. We need to verify its behavior in real HotSpot VM. Then let's modify the Bck2Brwsr VM to execute the code in a browser and behave the same.
Download the sample application. Unzip, change directory next to the root pom.xml. Then:
# build the code $ mvn clean install # verify it runs in real HotSpot VM (and with JavaFX) $ mvn -f client/pom.xml exec:java # try it in a browser $ mvn -f client-web/pom.xml package bck2brwsr:show
Milestone 2: Support for Java Concurrent. Part I.
Modern Java applications are using concurrent utilities (like ReentrantLock and these need to be supported as well. Supporting all of them may require a bit of time, but supporting a subset should be possible and is subject of this part one milestone.
The set of classes to be supported is to be defined by the supporter(s) of the effort.
Milestone 3: Generate Portable Code
Milestone 4: Release
Wrap up the previous milestones into production quality code and release official Bck2Brwsr version with support for threading. The challenges include finding a way to introduce the new format compatibly and not regress in performance when people don't use threads at all. Will require some new APIs for controlling the Bck2Brwsr compiler and doing Bck2BrwsrLibraries packaging.
Milestone 5: Support for Java Concurrent. Part II.
Implement the rest of Java concurrent utilities.
Milestone 6: Performance
Address performance issues discovered in previous milestones. One of such expected issues is increased size of download caused by including concurrent classes and libraries. That should be addressed by splitting the runtime into parts and downloading only the needed ones (identified by static analysis and/or runtime needs). The other issue is potential slowdown when using threads - address that by optimizing the pieces of code known to not require threading at all and designing a way for these optimized and thread ready parts to co-exists. Take into account optimizations done by browsers to speed up the code natively.