CODEWITHSUNDEEP
javacompilationportabilitybytecode
Dog
Dog

Reputation: 7787

What is the purpose of bytecode in Java?

Given that I can compile 300 classes in seconds, an implementation of Java could just be given Java source files instead of bytecode as an input, then compile and cache the input source code, and never compile it again (e.g python does this, and lots of language implementations do the same except don't even bother to cache):

  1. This initial compilation experience would be equivalent to the installation process that users are already used to
  2. This would remove the need for implementing the non trivial task of verification in the bytecode interpreter (which really is just reimplementing parts of the compile time checks), reducing implementation complexity.
  3. Java as it currently is, verifies the input bytecode every time it starts, even if it already verified it before. Point 2 would of course reduce startup times because it eliminates this step (although the current Java platform could also cache the "checked" status somewhere to reduce startup times, I'm not sure if it does this)
  4. This would allow implementations to compile however they want (or not at all), e.g for performance. Android doesn't even use Java bytecode, it uses dalvik bytecode, because they claim it's more suitable for their needs (e.g more performant on their hardware). If bytecode didn't exist, this design decision made by Google would have been completely transparent.
  5. This would promote open source

This answers why distribute bytecode instead of native code, but to be clear, I'm wondering why even have a compiled format for distribution at all? Assuming that compilation is important, why not just have the runtime compile source and cache it?

The only remaining rationale I can come up with is for obfuscation, but...

...so this point is reduced to that intuition would say that bytecode is more complicated than source code, thus having a bytecode distribution format allows to trick businessmen into thinking their IP is protected (i.e bytecode would be to "add value", but there is no technical reason for it).

Why is the Java platform designed for distributing bytecode to the user, as opposed to distributing source code to the user? I could not find an explanation of this anywhere on the internet. Is there a big reason I am missing here?

If you give a reason, you should probably state whether it's a reason that the language designers initially had, or a reason that is still valid today.

Upvotes: 13

Views: 3541

Answers (1)

Durandal
Durandal

Reputation: 20059

You are thinking just inside your little world. There are some compelling reasons to compile the source and deliver bytecode instead:

  • Download time (Applets were supposed to become a widely accepted web technology) - the user has no need for the source, so why retain the source? Reducing the amount of information transmitted means faster downloads.
  • Reduces startup time. Compiling on every run, takes additional time. If you can compile 300 classes a second that would mean an additional 5-10 Seconds startup time on the JRE alone nowadays. And machines were a little slower in 1995, you know.
  • Java is aimed at a multitude of platforms. Some platforms are not as powerful as your PC. Think of embedded and mobile devices. They may have neither the storage nor the power to compile code.
  • Bytecode allows any language to be compiled to bytecode - not just Java. There are plenty of other languages that can compile to bytecode. Would you prefer to install a new compiler for each of them?
  • Companies are often reluctant to give "the source" out of their hands. Java would have more acceptance problems if programs were to be delivered "in source".
  • Bytecode is a form of machine code simple enough to execute in hardware directly (There are a few embedded designs that have partial native bytecode support).

I'm sure there are more pros for bytecode I haven't even though about.

Upvotes: 5

Related Questions