objectionary / opeo-maven-plugin

Maven plugin to remove Bytecode opcodes from XMIR as much as possible
http://www.objectionary.com/opeo-maven-plugin/
MIT License
7 stars 2 forks source link

Java -> bytecode -> EO mapping for inlining #14

Open maxonfjvipon opened 1 year ago

maxonfjvipon commented 1 year ago

I have such java code:

new B(new A(42)).bar();

This code is translated to the EO that looks like this:

seq > @
  opcode > NEW-187-27
    "org/eolang/ineo/B"
  opcode > DUP-89-28
  opcode > NEW-187-29
    "org/eolang/ineo/A"
  opcode > DUP-89-30
  opcode > BIPUSH-16-31
    42
  opcode > INVOKESPECIAL-183-32
    "org/eolang/ineo/A"
    "<init>"
    "(I)V"
  opcode > INVOKESPECIAL-183-33
    "org/eolang/ineo/B"
    "<init>"
    "(Lorg/eolang/ineo/A;)V"
  opcode > INVOKEVIRTUAL-182-34
    "org/eolang/ineo/B"
    "bar"
    "()I"
  opcode > POP-87-35
  opcode > RETURN-177-36

If we simplify the code and get rid of all "syntax noice" that is needed to be able to convert such EO back to bytecode we get the next EO code:

a 42 > a1
a1.new
b a1 > b1
b1.new
b1.bar

This code is flat and it loses object composition. In order to be able to make inlining I would be happy if simplified example of translated EO would look like:

(b (a 42).new).new.bar

This code is as close as possible to what we originally had in java.

volodya-lombrozo commented 1 year ago

@maxonfjvipon Got it. I'll try to implement it.

yegor256 commented 1 year ago

@volodya-lombrozo @maxonfjvipon I suggest to close this ticket and DON'T implement this functionality. Instead, this particular plugin should only translate Bytecode into EO with opcode object per each instruction.

volodya-lombrozo commented 1 year ago

@yegor256 I agree, but I suggest to close this ticket only after moving this issue into another repository (together with the integration test which we already wrote https://github.com/objectionary/jeo-maven-plugin/pull/264)