Hacker News Reader

Comment by sorokod | Hacker News Reader

For me, any functionality that requires a compiler plugin, automatically raises the bar for adopting that functionality. Any extra features have to be contrasted with essentially modifying the language.

View on HN

I would only use this if I couldn’t use Kotlin, which has excellent extension method ergonomics that compile to basically the same thing as this.

Yep. It will be a footgun for environments with and without JAVAOPTs.

Better off transforming .java code at compile-time into .class'es in a .jar that always works at runtime.

Fluent transforms the abstract syntax tree at compile-time resulting in .class'es in a .jar that always work at runtime. There are no runtime dependencies.

Oh shit, you're right. I thought it was java and not javac. My middle night toilet writing on HN failed. :) It makes much more sense because "why would you have a plugin at runtime and not just pass a classpath or jar?" Still, maven and all tools, including language servers, that could compile or interpret it outside of a pom.xml would need that detail or they would break.

This topic makes me think of what other sort of compile-time mutation plugins could be had, including streamlining customizations with a per-project convention. Maybe Erlang bit syntax and matching for Java?

The JDK team won't like this. As it is Fluent, Lombok, and (I presume) Manifold are using all sorts of unsupported hacks to access compiler internals. If you restrict yourself to the compiler plugin API you don't get much mileage.

Reply on news.ycombinator.com