Blog about (Web-) Programming, Graphics and Games.


Does bytecode become obsolete?

Or, more provocative: Will Javascript substitute Java? Java has a certain technical infrastructure, it utilizes bytecode. This exists for following reasons: In the history of programming languages at first there where interpreted languages, e.g. Lisp or Basic. They where slow but portable. Then there came languages like c and c++, where source is compiled to systemspecifc binary. They were fast, but unportable. With Java and bytecode a quite fast AND portable solution emerged. Java source is compiled to system-independent bytecode, which then is executed by the java virtual machine. With later versions of Java, to increase execution speed, just-in-time (jit) compilers were introduced. They compile the bytecode on the fly to systemspecific binary, which than runs faster. Besides the ecosystems of compiled languages, interpreted languages persisted. Script languages like Javascript are there to e.g. control compiled programms or bytecode.

Recently jit-compilers for javascript appeared (Google V8, Mozilla Tracemonkey). Thus Javascript becomes fast and portable, like java, but without bytecode. Bytecode now seems to be an unnessary intermediate step during programm execution. Bytecode means more complexity in IDEs and in language execution. If a jit-compiler works with sourcecode directly, not with bytecode, possibly more optimizations can be done (without the additional abstraction step bytecode). If you get the same results with a less complex solution, you should apply it. With faster script languages, also there will be no need to separate programm logic into scripts and compiled functions. One advantage of bytecode might be that you can have different programming language compiled to it and than be executed on the same virtual machine. Like with JRuby, Jython, Scala than run on the java virtual machine. If you ommit bytecode and want to have the same flexibilty, the execution engine (with the jit-compiler), must be able to read different types of languages. Future will show if that is feasible.

Aside from the technical aspect, lets look at usage fields of Java and Javascript. At first Java was meant to be for the desktop. This didnt fully work out, e.g. Java applets in general couldnt compete with alternative approaches like flash. Java though became very strong on the server. Javascript was also originally there for the desktop, with its improving performance and the new <canvas> html-tag it can increasingly compete with flash and java applets. As of lateley Javascript spread also to the server (e.g. node.js). Thus, also from this point of view, it seems, that Javascript pushes into Java territory.

Two final notes: First, you may replace the term 'java' with 'c#/.net' (or other bytecode/intermediate language platforms) in this text. Second, this considerations only apply to the far future, currently java cannot be replaced by javascript, because of its superior stability, performance, distribution and api. Also, different languages/platforms will stay (in niches). In my perception java/c# (also called managed code) superseded c++ (unmanaged code), yet c++ still exists. In a comparable manner Javascript will displace Java/C#, but all will stay (for now).


zproxy hat gesagt…


Take for example my jsc compilet project.

It can translate .net byte code to other source coudes including javascript, actionscript, java and php.

Because it works with .net byte code, it works with multiple versions of C# compilers.

For example take Linq. It is syntactic sugar which nicely translates to bytecode.

One could think of bytecode as a normalized version of the sourcecode.

See more demos written in C# and converted to javascript here:

pl4n3 hat gesagt…

Interesting project and argument. I agree, that bytecode can be seen as normalized source-code. Question is, if there is the need for external representation of bytecode.. However, if bytecode really dies, one can use your project to switch to Javascript. :)