Since we first said that we were planning on basing our new Aion Virtual Machine on the JVM, there have been a lot of questions but the most common one that we get is “why?”. The question is a good one but it comes from a place of assuming that the WASM decision made by some other projects is somehow the default answer.

Here, I will attempt to explain why we went in this direction from the perspective of both why the original arguments against are not show-stopping but also how addressing these challenges opens up a vast opportunity of technical performance and robustness along with a global and engaged ecosystem.

Original concerns

“Oracle Intellectual Property”

This concern goes all the way back to the initial eWASM design documents. It is true that one wouldn’t want to modify and redistribute Oracle’s JVM or claim that the VM they built from the IP is a “Java” VM. However, this assumes that the only option was in modifying the JVM to accomplish this. We went in a different direction, building a layer on top of the standard JVM to give us only what we require while still leveraging the full power of the underlying system.

“The class file format is big/complex”

While it is possible to write a very large class (methods can be 64 KiB of bytecode), most are actually very small. It is, after all, also possible to build a very large EVM contract, but this typically isn’t considered a reason not to touch Solidity.

Much of the “complexity” is actually connected to the explicit organization of the class file, where much of the data is stored out-of-line. While the disagreement between inline data and out-of-line data is an old philosophical argument we don’t want to touch here, the meaning of the data is expressed in either case.

“Includes features useless in the blockchain space”

This is typically referring to things like network access or file IO and it is true that you wouldn’t want to expose those to code running on the blockchain. That said, there is a distinction worth making here (which isn’t present in EVM): These things are library routines, not part of the core bytecode language. This means that deciding to expose them within your environment is a secondary decision, beyond the bytecode.

“Nondeterminism in class library and core functionality”

Part of this is just an extension of the previous point: if you don’t want blockchain code asking for a random number, don’t provide access to that API.

Beyond that, however, there are some areas where nondeterminism can be exposed. An obvious example of this is the identity hash code. There are various ways to force this to a constant but, in our implementation, we replaced it with a deterministic counter.

We won’t go into details of how we accomplished that, in this article, but we will explain that in a future deep dive.

“How to manage denial-of-service”

For the most part, the answer is “much like one does with EVM”: pay for bytecode execution, memory allocation, and IO. The only additional point is “per API call”. This requires much of the restriction design mentioned above in order to constrain the scope of what is “Java” to the point where this becomes a containable space.

Again, these details will be explained in a future article.

You may see a bit of a common theme here, in that we solve many of these problems by reducing their scope to the point where they aren’t much larger than the scope EVM needed to solve. Exactly how this is accomplished and what restrictions/constraints were added will be explained in greater detail over the coming weeks.

Where we see a benefit

Java Tooling and Type System

One of the first things we found useful once we started building test DApps for AVM was how easy it is to write correct code in Java due to the ability to construct complex user-defined types combined with the compiler immediately verifying this and even our IDEs being able to provide code completion and verification, out of the box.

This doesn’t even begin to tap into the treasure trove of open source tools which have grown around the Java ecosystem, many of which can be applied to this environment to improve quality and velocity.

JIT Performance

We are able to keep frequently-used contracts in-memory so that the JVM’s just-in-time compiler has an opportunity to compile and optimize the DApp code.

Reliable and Mature Implementation

The core of the JVM is a very mature piece of software, changing little between releases and being used for a myriad of purposes, across countless environments, for over 2 decades. Anything we can do to leverage that history avoids potential pit-falls.

Robust Concurrency Support

Multi-threading has always been a core consideration of the JVM. We are able to leverage this to increase the throughput of our implementation by executing transactions concurrently, as opposed to most blockchain VMs which execute one transaction at a time.

Understanding Data Relationships

Using the type-safety of the Java heap, we are able to observe data relationships within a given DApp to optimize IO by seeing data as connected graphs of meaning, not just flat key-value entries.

Java and JVM Language Popularity

The scale and maturity of the Java developer community is a well-established fact (still #1 in both 2017 and 2018) and this doesn’t include the growing developer communities around other JVM languages (as Heroku is quick to point out).

Tapping into the potential of such a community is a big reason to leverage the JVM in the blockchain space.

Tooling from Prototype to Mature

Given that the blockchain space is very new, much of the tooling around it is still optimized for prototype or otherwise small projects.

The Java ecosystem has had a long time to build tooling and patterns to address the needs of both the small-scale but also the large-scale.

Instead of waiting for this to develop, as needed, adopting Java allows us to fast-forward into a more deeply fleshed-out space for development, testing, validation, integration, deployment, and monitoring.

Future

Now that we have explained “Why Java”, next time we will look at the other part of this common question: “Why not WASM?”

In the next couple weeks you’ll get to get your hands on what were talking about: Deploy .jar!