0

Books about basics of Java told some compiler behaviors. For instance in the book - OCA Oracle Certified Associate Java SE 8 Programmer I Study Guide,

  • Chapter 1 Java Building Blocks > Creating Objects > Constructors: For most classes, you don’t have to code a constructor—the compiler will supply a do nothing" default constructor for you.
  • Chapter 2 Operators and Statements > Understanding Java Statements > The for Statement > The for-each Statement > Real World Scenario - Comparing for and for-each Loops: Java actually converts the for-each loop into a standard for loop during compilation
  • ...

All the books only told this, but they never proved it practically with some special tools. So I would like to know is it possible to see such compiler behavior by means of some tools or just programmatically so that we can drill down the explanation from the books?

I tried the javap, which listed only the public instance members with the assembly instructions. I also tried the online decompile tool http://www.javadecompilers.com/, which decompiles exactly the original source code other than the intermediate code as those books told.

Rui
  • 3,454
  • 6
  • 37
  • 70
  • 1
    There is no guarantee that a compiler will perform these steps at all. The only guarantee is about how the final code will behave. – biziclop Jul 29 '17 at 13:22
  • 1
    @biziclop If there is not guarantee, those authorized books would not demonstrate very affirmatively – Rui Jul 29 '17 at 13:24
  • This sounds like a waste of time. There is no cleartext version that would have all classes extend `Object` or such. It's sourcecode to bytecode, nothing in between. – Kayaman Jul 29 '17 at 13:27
  • Some of this behavior is dependent on the version of Java. These were tweaks added in different versions. Auto-boxing used to not be available. The guarantee is dependent on the JVM specification. The specification specifies how the bytecode must be to work. I agree with @Kayaman. This is a simple text conversion to bytecode. Not much practical value in debugging it. – ProgrammersBlock Jul 29 '17 at 13:28
  • @Kayaman If it is a waste of time, why those books explain the behavior of the Java compiler? I actually didn't care so much about this before, either. But I realized that only simple explanation without any proof is way easy to forget as those books didn't tell the essense – Rui Jul 29 '17 at 13:28
  • Because explaining how the compiler works is important. But you don't understand how the compiler works, thinking there's an intermediate step that doesn't exist. – Kayaman Jul 29 '17 at 13:30
  • No need to get defensive. I don't know who authorised those books, I don't know what exactly is written then, what their purpose is, but what I do know is that the only authoritative source is the [Java Language Specification](https://docs.oracle.com/javase/specs/jls/se8/html/index.html), and the rules there only specify how the final code is supposed to behave, not what intermediate stages a compiler should perform. – biziclop Jul 29 '17 at 13:32
  • The JVM Specification is not the Java Language Specification. It specifies how the bytecode must be in order to work in a Java Virtual Machine. http://docs.oracle.com/javase/specs/jvms/se7/html/index.html – ProgrammersBlock Jul 29 '17 at 13:35
  • @Kayaman If the intermediate step doesn't exist, how come those books told for instance "Java actually converts the *for-each* loop into a standard for loop during compilation"? – Rui Jul 29 '17 at 13:43
  • 1
    It means there is no special bytecode generated for `for-each`. It gets compiled to a regular for loop. It doesn't mean that the literal code would be converted from `for(String s : foo)` to `for(int i = 0;i < foo.size(); i++)`. – Kayaman Jul 29 '17 at 13:49
  • 2
    If you want to know how a specific Java compiler works, read its source code (and if it isn't open source, you're probably out of luck). If you want to know how compilers in general work, read a book (or two) on compilers. But there is no "intermediate code" to be read with "special tools" as you're asking about. And if you want an explanation of (or an attack on) something some specific book said, then *quote* that particular book, in context, rather than informing us what it said. Otherwise waste of time is as good as we can do. – arcy Jul 29 '17 at 13:50
  • @Kayaman This time you gave more valuable comments :) But it did not answer my question :) For instance, I guess the answer of my question is in the source code of Java compiler related to David Conrad's mentioned AST - abstract syntax tree – Rui Jul 29 '17 at 13:54
  • @arcy Thanks a lot for your suggestion :) Great! You are welcome to give similar answers to this post – Rui Jul 29 '17 at 13:56
  • I'm pretty sure objects in the Sun compiler tree API (mentioned in that linked Q&A) override `toString()` so that you can print the AST as source code, but I have a suspicion that annotation processing occurs before any transformations are applied. I don't have time to test it myself today, unfortunately. – Radiodef Jul 29 '17 at 14:08
  • @Radiodef Thanks a lot for the valuable hint :) This is what I would like to know! But of course would like to drill down to it when there is free time. You are welcome to answer when you have time to try with the compiler tree API – Rui Jul 29 '17 at 14:12
  • Maybe some of the *hidden* `-XX` arguments of Java will help you. For example you can view exactly how it translates bytecode into machine code with `java -XX:+PrintCompilation MyJavaClass` [OpenJDK disassembler](https://github.com/abak/openjdk-hsdis). – Zabuzard Jul 29 '17 at 14:47
  • Write the same thing twice, one with foreach, one with for. Then look at the generated bytecode. If both are the same, you have your answer. – Polygnome Jul 29 '17 at 14:54
  • 1
    @Polygnome Great! Thanks sooo much for your suggestion. I actually really tried based on you suggestion, and found that the for-each loop with Iterable object really generates the same bytecode as the normal for loop with the same type of Iterable object. Cool! – Rui Jul 29 '17 at 18:01

1 Answers1

0

There is probably no way to "prove the books are right" this is just how compiler works and there is no way to see that step by step

EDIT: ok if you want to prove the books are right you can look at compilers source and AST but that's all

  • The Compiler tree API is even avaible (http://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/), there must be a way to prove. The Java compiler per se is coded by our human beings – Rui Jul 29 '17 at 14:44
  • well if you want you can look at the source code of java compiler because the Compiler Tree is still only a end result of compilers work –  Jul 29 '17 at 14:48
  • makes some sense :) – Rui Jul 29 '17 at 14:51