java icon indicating copy to clipboard operation
java copied to clipboard

Convoluted codegen build process

Open fabienrenaud opened this issue 7 years ago • 3 comments

I can not wrap my head around how the codegen build process is supposed to work smoothly... I did get it to work (with gradle), but steps were convoluted.

The StaticCodeGenerator expects to find .java file from the current directory and yet have the .class file of the same class available in its classpath. When both conditions are satisfied, it generates sources (encoder+decoder packages) and puts them in the source directory (src/main/java) which then needs to be compiled again.

In gradle language, the series of tasks are: clean compileJava jsoniterCodegen clean build Note: I have to run clean after the 'jsoniterCodegen' otherwise gradle doesn't run compileJava task again.

Although it can work. Compiling the entire project twice, or running the custom jsoniterCodegen task manually every time it may be needed isn't nice (and is slow).

There are a couple of ways of fixing this:

  • don't build java sources, write bytecode .class directly. this opens to the possibility of running the custom jsoniter task after :compileJava, during the :classes task (which is part of the build lifecycle for the java gradle plugin). I understand this is a v0.x though so the java sources may be kept around for as long as easy debugging of generated code may be necessary.
  • don't create any dependency between DemoCodegenConfig and jsoniter lib (just use reflection at build time to check whether it implements both methods). This way, it would be possible run a simple javac on the java file and move it to the right place (which StaticCodeGenerator could do too).

In addition, it would be nice if I could specify where to put the new files; I like to put my generated sources in a specific directory. I could do that if this if check was dropped: https://github.com/json-iterator/java/blob/88e45d032e58a3cd380dd26c138d8012fe6c8c2e/src/main/java/com/jsoniter/StaticCodeGenerator.java#L14 or if there was an option for the target source directory where StaticCodeGenerator should write java files.

Let me know if anything is unclear.

fabienrenaud avatar May 22 '17 16:05 fabienrenaud

  • generating the .class is not option. static codegen is not there for performance reason, but to support platform like Android. Will gradle pickup the .class, and include them into the apk? I am familiar with android development. If that is true, I can codegen .class file.
  • don't create any dependency between DemoCodegenConfig and jsoniter lib (just use reflection at build time to check whether it implements both methods). Can you elaborate on this? javac => static codegen => javac again, This process is convoluted because I need to use reflection api to read your model classes. I don't see any other way to simplify these. Unless rewrite everything without reflection api.
  • The argument to specify codegen target directory will be added

taowen avatar May 23 '17 00:05 taowen

What about generating bytecode directly (form class files and using reflection) instead of java code? Just like annotation processors usually do...

fabienrenaud avatar May 23 '17 03:05 fabienrenaud

I can provide that as an option.

taowen avatar May 23 '17 05:05 taowen