Multiverse 0.4 relies on a javaagent if you want to seamlessly integrate it with the Java language. The problem is that javaagents suck in production environments, so that is why compiletime instrumentation is a logical next step. The biggest step was to redesign the instrumentation so that the same instrumentation can be used for the javaaagent and the static compiler. This was completed a few weeks ago. But the other step was to create a preinstrumented self contained multiverse jar using Maven so that the same jar can be used as agent, as compiler (jarjar rocks) and as library. After 1 day of struggling and some help of an ex colleague (thanks Silvester) I finally solved the last problems.
So for the 0.5 release of Multiverse, expected next week, it is possible to do static instrumentation (which can be integrated into maven) and to combine this with the Multiverse javaagent (used from your IDE). Already instrumented classes can be mixed with the javaagent and instrumented classes are protected against repeated instrumentation.
Another advantage is that projects that don’t want to rely on instrumentation, but take a more programmatic approach (Multiverse 0.5 will contain a new Api for that as well) still can use the preinstrumented transactional datastructures provided by Multiverse:
- 0.4: TransactionalLinkedList (also implements BlockingQueue and BLockingDeque)
- 0.4: TransactionalArrayList
- 0.5: TransactionalReferenceArray
- 0.5: TransactionalTreeMap (also implements the ConcurrentMap interface).
- 0.5: TransactionalTreeSet
- 0.4: TransactionalThreadPoolExecutor (also implements ExecutorService)
In the 0.6 release more transactional datastructures will be added, and more performance optimizations on the existing collections are to be expected as well.