Vishal Hegde wrote:does compile time deals with allocating memory to variables and methods and does runtime deals with executing the actual complex code??
The compiler converts the text to bytecode. There are some errors the compiler can pickup and some it can't; those appear as Exceptions if you are lucky.
At runtime the JVM is started and that interprets the bytecode.
compilation means it just checks the syntax for your code & if everything is OK then it convert your code in to byte code.if compiler found any syntax error it will flag this as error .
once you done the compilation, your java interpreter will start actual execution of you program . This will convert your byte code in to machine dependent code & start execution by allocating memory for your variable , object on heap or stack.
Some things, like missing JAR files, can change from the moment you compile to the moment you run. For example, you compile a class with a JAR file on the class path. Then you give this class to someone else but forget to give the JAR file as well. That's a circumstance the compiler cannot predict, and therefore that will be an Exception or Error.
Vishal Hegde wrote:what actually happens at compile time and run time
why are some error shown at runtime and not at compile time???
does compile time deals with allocating memory to variables and methods and does runtime deals with executing the actual complex code??
There's an important principal difference between compilation and execution (running). Compilation is a pure transformation step. A program written in one language is transformed into an equivalent program in another language. The program doesn't actually do anything. Execution is when actual work is performed.
This means that during compilation only errors can be caught that are unrelated to what the program does when it runs. This is mostly limited to syntax errors, that is violations of the rules governing what a program should look like, not what it does.
No memory is allocated a compiletime, but the space needed for certain data are known at compiletime. This includes for example all variables you declare in methods and objects. What cannot be known is for example how many objects you will allocate when the program is run. This means it can be checked at compiletime whether a method or a class contains too many variables. But it can only be known at runtime for example whether a method calls itself repeatedly so many times it consumes all available stack memory, or whether so many objects are allocated that it consumes all heap space.
As a genaral rule it's important that as many errors as possible are cought at compiletime. In fact Java is designed for that. The most important mechanism for this is the strict type system. Java carefully checks that you always assign the right kind of data to the right kind of variables. Another mechanism is generics which was introduced with the sole purpose of making type checking even more thorough.
As a sidenote, the JVM actually performs compilation steps during runtime for performance reasons. This means that Java doesn't have a clean compile-execution separation. It first does a so called static compilation from Java source code to bytecode. Then this bytecode is passed to the JVM for execution. But executing bytecode is slow so the JVM measures how often the bytecode is run and when it detects a "hotspot" of code that's run very frequently it performs a so called dynamic compilation from bytecode to machinecode of the "hotspot" code. So effectively today Java programs are run by machinecode execution.
Vishal Hegde wrote:why are some error shown at runtime and not at compile time???
Look at this example:
What happends if you compile this? And if you run it?
Compiler cannot know which value will have n here: ab[n] so it compiles but then in execution it's known that ab.length is 2 so Exception is thrown
Something must be done about this. Let's start by reading this tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database