-
Hi, As I begin my journey of exploring using J2CL for compiling domain model and validation logic for Spring applications (with JavaScript initially but my target is Wasm), I am leveraging the J2CL Maven plugin sample and try to add validation logic with Yavi, a functional validation library, and hit some issues related to the fact that the transpilation is done leveraging the sources not the bytecode. The related repository can be found here. I am going to experiment by adding more sources and likely leverage a subset of Yavi in order to get my sample compiling, but I would be interested to learn more about this technical characteristic of J2CL in order to have more context for what I experiment now and plan later. FWIW my background for Java compilation is mostly GraalVM native image. Could it be possible to share more details on the reasons that led to this choice, and if there are any plans to change this for WebAssembly support or not? I saw that a switch to Javac for the default frontend is mentioned in #93, not sure if that will change something or not. Best regards, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
J2CL is a source-to-source compiler; there was in depth analysis at the beginning of the project but the essence is, J2CL targets idiomatic and understandable JavaScript and we didn't want to lose source level information or try to reverse engineer from byte-code. We don't have plans to change that. Javac related item in the roadmap is about changing the frontend to use Javac instead of JDT but both are working on source code. I haven't checked recently; it might be a longshot but perhaps nowadays there is decent enough decompiler that you can use to supply source? |
Beta Was this translation helpful? Give feedback.
J2CL is a source-to-source compiler; there was in depth analysis at the beginning of the project but the essence is, J2CL targets idiomatic and understandable JavaScript and we didn't want to lose source level information or try to reverse engineer from byte-code.
We don't have plans to change that. Javac related item in the roadmap is about changing the frontend to use Javac instead of JDT but both are working on source code.
I haven't checked recently; it might be a longshot but perhaps nowadays there is decent enough decompiler that you can use to supply source?