Where did you get the idea that we can code as we think? A computer thinks quite differently from the way the brain thinks. The whole idea of using the javac compiler is to do lots of error-checking, then produce code which can simply be interpreted. If you had to repeat the error-checking every time you tried to execute any code, you could rely on Java code running at the speed of a snail with arthritis!
Bytecode has the advantage of portability; that is why others have followed the same approach, eg Microsoft with the .NET languages.
Originally posted by Campbell Ritchie: If you had to repeat the error-checking every time you tried to execute any code, you could rely on Java code running at the speed of a snail with arthritis!
Are you sure? I've written ASP, PHP and Python (fortunately I've been spared the Perl experience ), and all can be run from source code and are quite fast.
Of course they are not (as) strongly typed as Java, but all three have array range checking for instance (although PHP's range checking usually produces a notice, not an error / exception).
You guys have sure made a lot of a few little sentences that I can't even understand. Menna Saad, can you maybe explain in different words exactly what you're asking?
I think Campbell and I got the question: why is the translation of source code to byte code still needed.
Campbell Ritchie
Sheriff
Joined: Oct 13, 2005
Posts: 32708
4
posted
0
Rob saying I agree with him? Whatever next? When I tried programming in BASIC a very long time ago, that was interpreted directly from the source, and ran reasonably fast, but in those days we were restricted to 256 lines of code per application. You try that with a big application with 1000000 lines in, and maybe it won't be as fast.
Actually there is another subtle little point, about "coding as we think." Assuming "as" doesn't mean "when" there (and I migh be mistaken), that suggests Menna Saad thinks computers and people "think" the same way. Which we don't.
Another issue is that source is not a good distribution format. If you were a company that sold a product, do you want the code for the product to be source? This holds true for library packages, or even code that you have been consulted to write.
Apart from the small java-enabled gadgets, the reason why the interpretation process in run time is still there is enigmatic(at least for me.) (that's why the hostspot is caching the machine code after interpretation) what I mean is we could have 2 way compilatoin process one that reveals the .class(perfectly compatibable,) and the other would be in the JMV instead of interpretation.
About the javac and the .class I would say the argumet of keeping the source code away from the clients, is way too old fashion, and it will be valid in the 1990s, any trivial decompiler will reveal every single line of the source code.
Regarding Menna's question, I would say we need the compilation process: 1-to be done with compilation errors(that we don't really want to face on the production time) 2-to provide a kind of code optimization(things java compiler do behind the scenes like code inlining ...) I do agree with Menna, that we can enhance the interpreter to do so, but this will cost us more runtime processing cycles. 3-to help Java recognize new custom types.yet this could also be done with the interpretation.
0
), and all can be run from source code and are quite fast.
