Over a million developers have joined DZone.

Java Getting Back to the Browser?

DZone's Guide to

Java Getting Back to the Browser?

Remember applets? Remember them going away? Well, Java is attempting to make it back into the browser with WebAssembly. Is this a good thing?

· Java Zone ·
Free Resource

Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.

Betteridge's law of headlines apply.

This article talks about WebAssembly and can be read to get a first glimpse of it. At the same time, I articulate my opinion and doubts. The summary is that WebAssembly is an interesting approach and we will see what it will become.

There was a time when we could run Java applets in browsers. There were a lot of problems with that, although the idea was not total nonsense. Nobody could tell that the future of browser programmability was not Java. Today, we know that JavaScript was the winner and that the applet,  deprecated in Java 9, is going to be removed from later Java versions. This, however, does not mean that JavaScript is without issues and is the only and best possible solution for the purpose that a person can imagine.

JavaScript has language problems. There is a lot of WTF included in the language. The largest shortage, in my opinion, is that it is a single language. Developers are different and like different languages. Projects are different and are best solved by different programming languages. Even Java would not so immensely successful without the JVM infrastructure supported by so many different languages. There are a lot of languages that run on the JVM, even such crap as ScriptBasic.

Now, you can say that the same is true for the JavaScript infrastructure. There are other languages that are compiled to JavaScript. For example, there is TypeScript or even Java with the GWT toolkit. JavaScript is a target language, especially with asm.js. But still, it is a high level, object-oriented, memory-managed language. It is nothing like machine code.

Compiling to JavaScript invokes the compiler once, then the JavaScript syntax analyzer, internal bytecode, and then the JIT compiler. Isn't that a bit too many compilers until we get to the bits that are fed into the CPU? Why should we download the textual format of JavaScript to the browser and compile it into bytecode each time a page is opened? The textual format may be larger, though compression technologies are fairly advanced, and the compilation runs millions of times on the client computer, emitting a lot of carbon into the air, where we already have enough — no need for more.

(Derail: Somebody told me that he has an advanced compression algorithm that can compress any file into one bit. There is no issue with the compression. Decompression is problematic though.)

Why can't we have some bytecode-based virtual machine in the browser? Something that the JVM was for applets. This is something that the WebAssembly people were thinking in 2015.

WebAssembly is a standard program format to be executed in the browser nearly as fast as native code. The original idea was to "complement JavaScript to speed up performance-critical parts of web applications and later on to enable web development in other languages than JavaScript." (Wikipedia)

Today, the interpreter runs in Firefox, Chromium, Google Chrome, Microsoft Edge, and Safari. You can download a binary program to the browser and invoke it from JavaScript. There is also some tooling supporting developing programs in "assembly" and also on higher level languages.


The binary web assembly contains blocks. Each block describes some characteristics of the code. I would say that most of the blocks are definition and structure tables and there is one that is the code itself. There is a block that lists the functions that the code exports, and which can be invoked from JavaScript. Also, there is a block that lists the methods that the code wants to invoke from the JavaScript code.

The assembly code is really assembly. When I started to play with it, I had some nostalgic feeling. Working with these hex codes is similar to programming the Sinclair ZX80 in Z80 assembly when we had to convert the code manually to hex on paper and then we had to "POKE" the codes from BASIC to the memory. (If you understand what I am talking about, you are seasoned. I wanted to write 'old,' but my editor told me that is rude. I am just kidding. I have no editor.)

I will not list all the features of the language. If you are interested, visit the WebAssembly page. There is a consumable documentation about the binary format.

There are, however, some interesting features that I want to talk about to later express my opinions.

No Objects

The WebAssembly VM is not an object-oriented VM. It does not know objects, classes, or any similar high-level structures. It really looks like some machine language. It has some primitive types, like i32, i64, f32, and f64 — and that is it. The compiler that compiles high-level language has to use these.


The memory management is also up to the application. It is assembly. There is no garbage collector. The code works on a (virtually) continuous memory segment that can grow or shrink via system call, and it is totally up to the application to decide which code fragment uses which memory address.

Two Stacks

There are two stacks the VM works with. One is the operation stack for arithmetic operations. The other one is the call stack. There are functions that can call each other and return to the caller. The call sequence is stored in a stack. This is a very usual approach. The only shortage is that there is no possibility to mark the call stack and purge it when an exception happens. The only possibility to handle a try/catch programming structure is to generate code before and after function calls that check for exception conditions — and if the exception is not caught on the caller function level, then the code has to return to the higher-level caller. This way, the exception handling walks through the call stack with the extra generated code around each function call. This slows down not only the exception handling but also the function calls.

Single Thread

There is no threading in WebAssembly.

Support, Tooling

The fact that most of the browsers support WebAssembly is only half the solution. There have to be developer tools supporting the concept to have code that can be executed.

There is an LLVM-backed compiler solution, so technically any language that is compiled to LLVM should be compilable to WebAssembly and run in the browser. There is a C compiler in the tooling, and you can also compile RUST to WebAssembly. There is also a textual format in case you want to program directly at the assembly level.


Security is at least questionable. First of all, WebAssembly is binary, therefore it is not possible, or at least complex, to look at and analyze the code. The download of the code does not require channel encryption (TLS), therefore it is vulnerable to MITM attack. Similarly, WebAssembly does not support code signatures that would assert that the code was not tampered with since being generated in the (hopefully protected) development environment.

WebAssembly runs in a sandbox, just like JavaScript or like Flash was running. Fairly questionable architecture from a security point of view.

You can read more on the security questions in this article.


WebAssembly was developed for to years to reach a Minimal Viable Product (MVP) that can be used as a PoC. There are features like garbage collection, multi-thread support, exception handling support, SIMD type instructions, and DOM access support directly from WebAssembly, which are developed after MVP.

I can say after playing with WebAssembly over the course of a weekend that it is an interesting and nice toy. But in its current state, it is a toy, nothing more. Without the features planned after MVP, I see only one viable use case: WebAssembly is the perfect tool to deploy malicious mining code on client machines. In addition to that, any implementation flaw in the engine is a security risk. Note that these security risks come from a browser functionality that gives no value to the average user. You can disable WebAssembly in some browsers. It is a little worrisome that it is enabled by default, although it is needed only for early adopters for PoC and not commercial projects. If I were paranoid, I would say that the browser vendors, like Google, have a hidden agenda with the WebAssembly engine in the browser.

I am afraid that we see no security issues currently with WebAssembly only because the technology is new and IT felons have not learned the tools yet. I am almost certain that the security holes are currently lurking in the current code waiting to be exploited. Disable WebAssembly in your browser until you want to use it. Perhaps in a few years (or decades).

The original aim was to amend JavaScript. With the features after MVP, I strongly believe that WebAssembly will rather aim to replace JavaScript than to amend it. There will be a time when we will be able to write applications to run in the browser in Golang, Swift, Java, C, Rust, or whatever language we want to. So looking at the question in the title "will Java get back to the browser?" the answer is definitely NO. But some kind of VM technology, JIT, or bytecode definitely will sometime in the future.

But not yet.

Learn how the Actor model provides a simple but powerful way to design and implement reactive applications that can distribute work across clusters of cores and servers. Brought to you in partnership with Lightbend.

java ,webassembly ,opinion ,browser ,javascript ,security ,web dev

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}