0

Compiled byte code by Eclipse and JDK are different. Then how does the JVM understand both the byte codes? Example:

package com.hcl.raj.utilities;

public class StringTest {

  /**
   * @param args
   */
  public static void main(String[] args) {
    // TODO Auto-generated method stub
    String name = "Rajkumar";
    byte[] byteCodes = new byte[] {15,22,35,48};
    String str1 = new String(byteCodes);
    System.out.println(str1);
  }
}

The compiled code of the above source code by JDK and Eclipse are different.

Original attempt to post compiled code removed due to encoding and formatting issues

Martin Serrano
  • 3,727
  • 1
  • 35
  • 48
Rajkumar
  • 269
  • 2
  • 6
  • 13
  • 2
    I think they are differ in meta information, which is not used by JVM(or used in special cases - debug info,...). Maybe they are differ in bytecode too but JVM have specification and all compilers must follow it. – ice Aug 21 '12 at 10:48

4 Answers4

4

First of all, is the bytecode different, or is the difference only in other parts of the class file? A class file can contain a lot of optional information (for debugging).

But even if the bytecode itself is different, they behave like synonyms. Even in a language as tightly defined as Java bytecodes, you can express the same behaviour in different ways.

For example, switch/case statements can be compiled into either of two different opcodes: tableswitch or lookupswitch. They both do the same thing essentially, so in certain cases a compiler is more or less free to choose between them.

What is important though that these differences are all within the limits of standard bytecode, regardless of platforms or any other external circumstances, no Java compliant compiler will produce bytecode that a similarly compliant VM can't interpret (assuming that they support the same version of Java).

Community
  • 1
  • 1
biziclop
  • 48,926
  • 12
  • 77
  • 104
3

There is a huge chapter in the JLS dedicated to specifying the Java class file format, which is really the whole point of having that format in the first place. The javac compiler holds no special authority on the format of the files it happens to produce.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
2

Eclipse uses an SDK internally (which can be the same you used to directly generate your bytecode, or another one). Also, different SDKs can generate different Bytecode (for example if the JDK is from a diferent company or a diferent version), but if they meet the bytecode specification when they generate bytecode, they will be well interpreted by a JVM that also follows that specification.

Mr.Eddart
  • 10,050
  • 13
  • 49
  • 77
  • Eclipse compiler does not compile the variable name and includes the same variable name into the byte code while the Java compiler compiles the variable name too. How does JVM identify this variable name? – Rajkumar Aug 21 '12 at 11:05
  • The JDK (the one used by eclipse or outside eclipse) can be configured to put info (like the variable names, code line numbers, etc) in the compiled bytecode. What you mean that JVM identifies the variable name? do you mean that you see the variable name when you decompile the bytecode? – Mr.Eddart Aug 21 '12 at 11:08
  • @Rajkumar In the byte code, only offsets (integers) are used. Debugging information can be added to map the numbers to variable names. – Peter Lawrey Aug 21 '12 at 11:12
0

Java bytecode is portable, this is one of key feature of java. You can read some info here. If you want to discover how this portability exactly works you can browse specification.

Community
  • 1
  • 1
gkuzmin
  • 2,414
  • 17
  • 24