13

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...

  • the way current compilers compile, the code can be mechanically decompiled pretty accurately
  • source code can be obfuscated too

...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.

Community
  • 1
  • 1
Dog
  • 7,707
  • 8
  • 40
  • 74

1 Answers1

5

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.

Durandal
  • 19,919
  • 4
  • 36
  • 70
  • 3
    Some good points and bad points. "Reduces startup time. Compiling on every run, takes additional time" You failed to read the full question; @Dog explicitly proposed a caching mechanism which addresses this, and moreover reduces startup time because there is no bytecode verification. Your "bytecode as an assembly language" point is moot and ad-hoc, since it wasn't originally intended for compiling other languages, and has been shown to be horrible for certain other languages. Compiling to JavaScript works just as well. – Harold R. Eason May 27 '13 at 18:28
  • 2
    The size difference of bytecode vs compressed source is trivial. Last point is proven wrong by the existence of Dalvik. The IP and running on small devices points are sort of what I had in mind... – Dog May 27 '13 at 18:42
  • @Dog Unless there was an edit, the last point is "Bytecode is a form of machine code simple enough to execute in hardware directly" and I don't see that being disproven by Android. Android devices don't execute JVM or Dalvik bytecode, but not (necessarily) because they can't but for other reasons. –  May 27 '13 at 19:40
  • @Dog The size difference can be significant if the source code contains extensive comments (as it should). And for the hardware point, check this http://en.wikipedia.org/wiki/Jazelle - that Android doesn't use this approach means nothing in the context of the question. – Durandal May 28 '13 at 14:15
  • @HaroldR.Eason He explicitly stated that the source would be *verified* in point 2, not compiled (maybe it was intended to be implied, but its not clear). He *never* said where/if he wanted to store storing compiled code, in fact he implies that the compilation mode can be changed in point 4. Can be taken either way. – Durandal May 28 '13 at 17:32
  • @HaroldR.Eason And bytecode as an assembly language... while there were no compilers for other languages from the start, the bytecode specification is an explicit part of the VM specification. Thus it was an *open interface* you can write against from the very start. In fact there always have been *bytecode assemblers*. Maybe it wasn't a *goal* for Gosling, but thats how it went. And whats the point of complaining that it works horrible for some languages? Nobody ever said that bytecode compilation was the snake oil to solve everything. You dislike the VM that much? – Durandal May 28 '13 at 17:34
  • @delnan: Some ARMv5TE microcontrollers included a hardware mode ("Jazelle") that could process most JVM instructions directly (see Durandel's "Jazelle" link). Even though such ability turned out to far less useful than intended (even with hardware support, executing JVM directly is slower than running JITted code), a desire to allow hardware execution could easily have influenced the design of the JVM. – supercat Jan 29 '14 at 16:37