Hacker News Reader

Comment by kaba0 | Hacker News Reader

One should probably also mention its sibling project, J2Cl which translates Java to Javascript (with very very good quality might I say!).

With android apps being written in Java, Google (and anyone actually) can share code between the web, android and ios at the same time. I’m no google employee, but from what I’ve read they do use this to share the difficult logic of google drive apps between all platforms, while letting the platform-native frontend do the rest.

View on HN

> J2Cl which translates Java to Javascript

Oh that's sure an interesting project. A shame it apparently requires the use of Bazel as the build system. I wish I could just add it as a module to my existing Maven project and rewrite my frontend code from TypeScript to Java — but that's Google, and Google can never stop inventing their own ways of building things.

edit: I might try https://github.com/Vertispan/j2clmavenplugin

I've never used bazel before. Is it that bad?

As far as I know it’s not necessarily bad, it’s just not standard, especially not for java projects, so it may require strange file hierarchies.

Bazel doesn't enforce a structure. Bazel makes you add WORKSPACE and BUILD files throughout your project to describe your targets and their dependencies.

Doesn't matter whether it's good or bad, I already have an existing Maven project I would like to try this in. Besides, Maven and Gradle are simply what I'm used to when working with Java projects. Yet another build system is about the last thing I need. I consider building Java to be a fully solved problem.

I use it in a few projects, all are polyglot monorepos. I think bazel really shines in that setting. I have one tool to interact with my codebase. I use it to manage all build, test, and deploy, but also code generation, running local dev servers. I think its worth the hassle of setting it up for large multi language projects.

There are third-party maven and gradle integrations and plugins at various stages. And you can also run bazel -s to log the exact commands it is running (basically j2cl with annotation processing plus closure-compiler). Though extracting good pairings of j2cl, closure-compiler, gwt and jre-emul libs etc tends to become a pointless chore with j2cl, closure-compiler being updated all the time without documented releases other than timestamps. Last I checked, closure-compiler was at a 2020ish rev in a recent j2cl bazel build checkout only slightly newer than the initial 2019 release, with j2cl apparently focussing on kotlin and also an experimental wasm target requiring wasmgc hence Chrome.

It's a pity Google doesn't anymore see value in external input/testing for j2cl and closure-compiler since these are decent projects.

TeaVM converts Java to JS, and it has first-class maven support.

https://teavm.org

It runs byte code in a JS-(or WASM) implemented JVM, isn’t it?

It is really fast, but slightly different than J2CL.

TeaVM transpiles Java bytecode to native JS, only keeping the required classes. The output is compact, efficient, and fast to download in a browser. No interpreter or runtime is used, which makes TeaVM apps fast and light.

Oh I see. The difference is that it works from class files, not source (making other jvm languages supported as well)

We are mostly targeting enabling GWT applications to be able to (relatively seamlessly) update to J2CL as a compiler, but are definitely interested in apps or libraries starting their lives as a plain Java project and expose it to JS/TS/closure in a variety of ways.

Aside from the github repo, most of the conversation as we work on this happens at https://gitter.im/vertispan/j2cl - feel free to stop by to ask any questions or share a use case that seems under-represented.

Reply on news.ycombinator.com