4 ms·

The danger with generating source code is that you now depend on source rules which may have changed, never applied to your source language, or are made more co

The danger with generating source code is that you now depend on source rules which may have changed, never applied to your source language, or are made more complicated by class loading refs. I’d definitely go for byte code generation, and possibly using constant dynamic to handle any really tricky constants, over source code any day.

SpaghettiCthulu 3y ago
I would go for `MethodHandle`s and lambda metafactory over bytecode where possible. Much easier to avoid and debug bugs in the generation (better errors than those provided by Hotspot's verifier), and avoids needing to worry about constant dynamic at all. Of course, once you need to implement more than one method, you can no longer just use lambda metafactory. A while back I actually implemented some utilities for generating classes at runtime and "linking" constants into them using constant dynamic. One day I might clean it up and release it as a library.
- chaokunyang 3y ago
  Good point, I used `lambda metafactory` too in fury, but only for some `constructor/getters`. I implements some Function utils to generate lambda function, see https://github.com/alipay/fury/blob/main/java/fury-core/src/main/java/io/fury/util/function/Functions.java https://github.com/alipay/fury/blob/main/java/fury-core/src/... I'm not sure whether `MethodHandle` can generate the most complicated code, since the serialization logic here are more complicated even than the manual written code.
- chaokunyang 3y ago
  Looking forward to your library
chaokunyang 3y ago
We used https://github.com/janino-compiler/janino https://github.com/janino-compiler/janino to compile the generated code at runtime It's stable and the compiler used by spark/flink. Janino can generated the bytecode for fury generated java code. I must agree that generating bytecode directly has it's advantages, the abstraction is more low-level, thus more flexible, except more complicated for developing.

SpaghettiCthulu 3y ago

I would go for `MethodHandle`s and lambda metafactory over bytecode where possible. Much easier to avoid and debug bugs in the generation (better errors than those provided by Hotspot's verifier), and avoids needing to worry about constant dynamic at all. Of course, once you need to implement more than one method, you can no longer just use lambda metafactory. A while back I actually implemented some utilities for generating classes at runtime and "linking" constants into them using constant dynamic. One day I might clean it up and release it as a library.

chaokunyang 3y ago
Good point, I used `lambda metafactory` too in fury, but only for some `constructor/getters`. I implements some Function utils to generate lambda function, see https://github.com/alipay/fury/blob/main/java/fury-core/src/main/java/io/fury/util/function/Functions.java https://github.com/alipay/fury/blob/main/java/fury-core/src/... I'm not sure whether `MethodHandle` can generate the most complicated code, since the serialization logic here are more complicated even than the manual written code.
chaokunyang 3y ago
Looking forward to your library

chaokunyang 3y ago

We used https://github.com/janino-compiler/janino https://github.com/janino-compiler/janino to compile the generated code at runtime It's stable and the compiler used by spark/flink. Janino can generated the bytecode for fury generated java code. I must agree that generating bytecode directly has it's advantages, the abstraction is more low-level, thus more flexible, except more complicated for developing.