Before swc4j was born,
1. I was deeply disappointed by Antlr. My blog https://blog.caoccao.com/hello-swc4j-goodbye-antlr-f9a63e45a... explains why. 2. I could use Babel in Node.js on JVM (using another project Javet created by me) to meet the business requirements, but Babel's performance is 10x-100x worse than swc's. 3. There was nothing else better. 4. swc is one of the best solutions in front-end toolchain. It's well maintained. Its community is healty. It is being used by Node.js and Deno.
So I decided to try to embed swc in JVM. After a month of intensive development from scratch, swc4j was alive. In my opinion, its design has to be a genuine swc library bridged by JNI or other native interop mechanisms on JVM for the following reasons.
1. The dev cost of reinventing the wheels on JVM is unbearable to me. Tracking the JS / TS / JSX / TSX / ... specs from time to time requires a dedicated team. 2. The performance overhead is subtle. 3. The behavior is identical to the genuine swc. That brings confidence to the swc4j users.
Hope these make sense.