I am a beginner in java,for understanding java memory management i was reading book 'Java Memory Management By Maaike van Putten , Seán Kennedy ' I encountered this statement "To be able to execute applications, the JVM has roughly three components in place. One is used to load all the classes, the class loader. This is actually a complex process in itself; the classes are loaded and the bytecode is verified."
what does class loader verify in bytecode (As i read all syntax verification ,access verification is done while generating bytecode not after generated and loading) can explain what exactly class loader is trying to verify in bytecode
I don’t know which other two components this book identified, but I have the strong feeling that the book oversimplifies things or uses terms in different ways than other sources.
There is not a single class loader “used to load all the classes” but an arbitrary number of them. Even the simplest setup features three of them,
The responsibility of the class loaders isn’t linking nor verifying, despite you might find contradicting sources for historical reasons. The main responsibility of a class loader is to locate the definition of a class, read it into a byte array or ByteBuffer, and pass it to the JVM. It’s the JVM which performs linking and verification.
In the very first Java version, the responsibilities were not as well defined as today, therefore sources from that time or sources blatantly copying from such outdated sources may still tell different things.
Of course, one could try to explain a Java execution environment by splitting it into arbitrary conceptional components and even use names clashing with terms used in other documentations. That’s not necessarily wrong, but obviously will cause confusion as soon as you try to match this explanation with other sources.
When you generate bytecode, e.g. by compiling source code, the bytecode is in theory correct and consistent but there are strong reasons not to trust the bytecode blindly in an execution environment.
There is no guaranty that all components (libraries or classes) used in the execution environment are the same version used when compiling. Classes or libraries could have changed in an incompatible way after the classes or libraries using them had been compiled.
There is no guarantee that all tools involved (compilers or other code generators) were free of bugs
There could be intentional modifications to the compiled code, to circumvent access restrictions or compromise the execution environment in some other way.
This was more an issue of the past, when Applets or Webstart applications, in other words, code downloaded from arbitrary internet sources supposed to run with a security manager, were a thing.
A summary is given in The Java Language Specification:
Verification ensures that the binary representation of a class or interface is structurally correct. For example, it checks that every instruction has a valid operation code; that every branch instruction branches to the start of some other instruction, rather than into the middle of an instruction; that every method is provided with a structurally correct signature; and that every instruction obeys the type discipline of the Java Virtual Machine.
There’s also a chapter in The Java Virtual Machine Specification acknowledging the rationale given above:
Even though a compiler for the Java programming language must only produce class files that satisfy all the static and structural constraints in the previous sections, the Java Virtual Machine has no guarantee that any file it is asked to load was generated by that compiler or is properly formed. Applications such as web browsers do not download source code, which they then compile; these applications download already-compiled class files. The browser needs to determine whether the class file was produced by a trustworthy compiler or by an adversary attempting to exploit the Java Virtual Machine.
An additional problem with compile-time checking is version skew. …