• Post Reply Bookmark Topic Watch Topic
  • New Topic

What was before WORA in Java?(Significance of Bytecode/JVM)  RSS feed

 
Abhay Bhatt
Ranch Hand
Posts: 64
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wanted to understand all the hype/significance of this Bytecode and JVM. Because can't you create different 'compilers+executables' for different platforms? Then you can achieve WOCA(write once, compile anywhere) - which means we will write source code file once and can run anywhere. Will it be any much different from WORA?

So, I want to understand exactly what this intermediate step of creating bytecodes, achieving exactly? Because portability, as I pointed out above, could have been achieved otherwise.


Thank you.
 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your argument seems to be "We can create 20 compilers, one for each of the 20 environments where Java runs, and therefore we can create executables for each of those environments." (I've made up the number "20" but it could be close to the correct number.)

That's certainly true. But it certainly isn't what I would describe as "portability". Portability is where I can create one executable and it will run on all of those 20 environments. Then I give you a jar file containing compiled Java classes and I don't have to ask you which environment you're going to run it in. With your idea, I would have to produce 20 jar files, one for each environment. Inevitably I wouldn't bother to do that and I'd only produce one or two for the environments I happen to have available, and then you'd have to hassle me to compile it for your preferred environment, which I wouldn't be able to do because I don't have a copy of its compiler and I don't want to give you my source code so that you could compile it... and so on ad nauseam.
 
Abhay Bhatt
Ranch Hand
Posts: 64
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for answering. If you can please bear with me, I am a bit new to OOPs/Java: -

You seem to say that there is some inherit problem with sharing the source code. Exactly why is it, if so?

I will also like to add here that I am presuming that JVM itself is, in some subtle or nuanced way, a combination of components where:
Component1 translates bytecode to machine code for Processor1 of Platform1
Component2 translates bytecode to machine code for Processor2 of Platform2
Component3 translates bytecode to machine code for Processor3 of Platform3
...and so on.

So, whats the problem with having a kind of super compiler+executer which can compile and execute for every platform?
I also, didn't quite fully understood, the last two lines of your comment.
 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Abhay Bhatt wrote:You seem to say that there is some inherit problem with sharing the source code. Exactly why is it, if so?


People often don't want to share their source code because it contains proprietary information which shouldn't be shared by other people outside the organization. This isn't always the case, as you can see by the proliferation of the open source movement, but sometimes it is.

I will also like to add here that I am presuming that JVM itself is, in some subtle or nuanced way, a combination of components where:
Component1 translates bytecode to machine code for Processor1 of Platform1
Component2 translates bytecode to machine code for Processor2 of Platform2
Component3 translates bytecode to machine code for Processor3 of Platform3
...and so on.


Yes and no. Any platform which supports Java does it through a JVM which is written specifically for that platform. There isn't one JVM which knows about all platforms, instead each JVM supports only one platform. So if you wanted your new system to support Java, you have to write a JVM for that system.

So, whats the problem with having a kind of super compiler+executer which can compile and execute for every platform?


The problem is that a compiler requires source code, so the source code would have to be distributed to all users. I've already explained one problem with that. The other problem is that a compiler+executer would have to recompile the code every time somebody wanted to execute it. And when you consider today's applications which may be using Java classes derived from hundreds of thousands of lines of code, that's a terribly large burden to impose every time you want to start the application.

I also, didn't quite fully understood, the last two lines of your comment.


That's because you assumed that the compiling would be done by the user, I think. By now I've described several reasons why that's impractical; because of those reasons I assumed that the compiling would be done by the distributor of the code. Which is equally impractical for multiple platforms.
 
Fred Kleinschmidt
Bartender
Posts: 571
9
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another reason is that different text editors on different platforms can store the file in different manners. A simple example of this is the newline or Unis/Linux platforms, versus Microsoft's newline/carriage-return. Compilers on one machine might not be able to read the source code written on a different platform. To make a "super compiler", you would have to know about every possible platform and file format.
 
Ivan Jozsef Balazs
Rancher
Posts: 999
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fred Kleinschmidt wrote:Another reason is that different text editors on different platforms can store the file in different manners


I am not sure whether this is usually a problem for the compilers at all. For example the Java compiler is well able to cope with Windows and Unix-styled source code, so might be your C/C++/D whatnot compiler as well. But even then, it is the least difficulty when porting a non-trivial program from one platform to another.
 
Ivan Jozsef Balazs
Rancher
Posts: 999
5
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are C compilers for different platforms. If you code with care, not using implementation details, not relying upon whether a char is signed or not by default, or the size (range) of the type int, etc., then you can strive for portable coding, judiciously using the standard libraries etc. Java comes however out-of-the box with a plethora of libraries covering a wide range of topics including network (socket) programming, XML parsing, encryption/SSL support etc. Being able to portably rely upon these layers is a boon.
 
Tim Moores
Saloon Keeper
Posts: 4019
94
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even in situations where the source code is available, portability is not easy to achieve. Anyone who has written a Configure script (or watched the output of one being executed) can attest to that.
 
Campbell Ritchie
Marshal
Posts: 56518
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fred Kleinschmidt wrote:. . . versus Microsoft's newline/carriage-return. . . .
Minor nitpick: it isn't LF‑CR but CR‑LF.
 
Campbell Ritchie
Marshal
Posts: 56518
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Abhay Bhatt wrote:. . .
Component1 translates bytecode to machine code for Processor1 of Platform1
Component2 translates bytecode to machine code for Processor2 of Platform2
Component3 translates bytecode to machine code for Processor3 of Platform3
...and so on.
. . . .
Why shou‍ld it be necessary to translate bytecode? Java® is describe as an interpreted language, so the JVM can simply execute the bytecode.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16057
88
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note also that different operating systems have completely different APIs.

If you write a program for Windows, using the API of Windows, then there is no way you are going to be able to compile exactly the same source code and make a Linux or macOS executable out of it. Likewise, Linux and macOS have their own APIs and libraries which do not exist on Windows.

There are some attempts to make a generic set of standard APIs and libraries which should make this easier, but often programs written using such APIs and libraries don't look like native programs. Windows users expect programs to work a certain way and have a certain look and feel, and certain keyboard shortcuts that almost all programs have. Linux and macOS users expect a different look and feel, different keyboard shortcuts and other standard features that programs for these platforms have. It's really hard to write a generic program that looks and feels like a native application written for the specific OS.

Also, you cannot expect ordinary (non-programmer) users to understand how to use a compiler to compile source code for their specific OS.

The idea of bytecode was, by the way, not a new invention from the people who came up with Java. It already existed long before that. I remember having a Pascal compiler on my MS-DOS PC in the 1980's which compiled source code to p-code, which is also a kind of bytecode. And before that there were implementations of LISP which had the same idea.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

To pile on .... sorry ...

At the end of the day, whether a language is successful or not, depends on whether people will learn/use it. The source code distribution option just doesn't work. Even today, I can't name a single commercial company (even ones that distribute via open source), willing to freely distribute source without some control.  If Java required distribution of source when it was released, the number of companies willing to convert would have been significantly less.

For fresher developers, IMHO, they are not concerned with WORA, or the better APIs, or the Garbage Collector, etc. etc. They are concerned with getting a job. Period. And that means learning the most popular language(s) possible. If the language can't get traction among companies, why should you learn it? Don't you want to dive into the biggest job pool possible?

Henry
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!