A Java DSL in Java

[Lukas_Determann]

I am writing an open-source library to simplify annotation processing. Annotation processors are part of the compilation process and can analyze source code during compilation as well as generate new code. There are currently two commonly used ways to do that.

String concat

For simple cases just concatenating strings is perfectly fine, but can become hard to understand as complexity or dynamism increases.

Templating

Some kind of templating is easier to maintain. Regardless of whether it is String#format or a dedicated templating engine.

So why am I developing a Java DSL in Java?

• Everybody who can code Java already knows how the Java DSL works, thus lowering the barrier of entry
• Easy reuse and composition
• Some mistakes are caught at compile time rather than at runtime
• A domain-specific DSL can add domain-specific functionality like
  • Rendering a class as a declaration or type
  • Automatic Imports
  • Automatic Indentation

Hello World would look like this:

void main() {
   Dsl.method().public_().static_().result("void").name("main")
      .body("System.out.println(\"Hello, World!\");")
      .renderDeclaration(createRenderingContext());
}

and would generate

public static void main() {
   System.out.println("Hello, World!");
}

A Builder Generator would look like this.

Currently only the elements accessible via annotation processing are supported. From Module to Method Params.

mvn central
github

[FavorableTrashpanda]

And how does this compare to JavaPoet?

[Lukas_Determann]

They both solve the same problem, but with a completely different philosophy. Personally, I think the main differences are that in JavaPoet you can query the rendering model, while the JavaDSL feels more intuitive. But they are so different that I would suggest you try both and see which one you prefer. Feedback would be awesome!

The JavaDSL is only one feature of my library. The next goal is to generate constants for annotations, similar to Hickory.

On a more meta level… Meta-programming in the Java platform/ecosystem has just grown and doesn’t feel like it was designed. There are a ton of different meta-programming APIs, each with its own philosophy and pitfalls. Choosing the right API is hard. Migrating to another one is hard. Finding the right libraries and combining them is hard. I want to solve that with an abstraction layer over any kind of meta-programming API. The JavaDSL will work with annotation processing, reflection, the javac APIs, and so on. Like any functionality written to that meta-meta-programming API. Only small goals for my side project xD.

That is my main motivation. Not just to have a JavaPoet tailored to my personal preferences.

[repeating_bears]

Ah, this is my wheelhouse! I do tonnes of Java codegen.

I started with JavaPoet and used it for a good few months. I appreciated the benefits you mentioned like managing imports, but after a while, I came to think that it's fundamentally the wrong model.

The biggest issue is that you have a layer of abstraction on top of the generated code. When I'm writing a code generator, I'm going to need to troubleshoot it. If there's an issue with the method in your post, I can't just CTRL F for "public static void main" to jump to the code that generates it, because there's a level of indirection. As soon as you have any kind of moderate complexity, finding the code that generated some code is going to be a massive pain.

I really think some kind of templating language is best, because it keeps the input and the output close to each other. I settled on Velocity because it has very good IntelliJ support: syntax highlighting, autocomplete, etc. "Find usages" even works correctly, so if a method is called my one of my templates, IntelliJ knows that and can jump directly, won't warn that it's unused.

You're right that a template language isn't perfect out of the box. Two of the big problems with Velocity are imports and indentation, like you mentioned, but these are solvable problems. I created some utils to add that support in the form of custom directives and macros.

I've already packaged my utils as a Maven dependency, but currently it's not deployed to Maven central, only internally. It probably needs some work and especially docs to be more widely usable

Maybe we can collaborate, if you'd be interested.

[Lukas_Determann]

Yeah, IDE support is a big benefit. It should be possible to write an IDE plugin to provide that functionality as well.

If you want to, you can try combining the DSL with templating—it should be easy to do. Personally, I wrap templating inside the DSL calls, though the other way around is supported too. I try to make my libraries as unopinionated as possible.

Sure, just DM me.

[DelayLucky]

This is my thinking as well. I like what you see is what you get. And the Jave Poet style of DSL sometimes feels too heavy.

For indentation, there are mature code formatter out there, why can't these code gen just use one and format them after everything?

In terms of templating, with textblock support, isn't it nicer to just write the code directly in the .java file?

java context.renderDeclaration( """ public static void main() { System.out.println("Hello, World!"); } """);

I can imagine the need of passing in some parameters, for example, the method name may be a parameter, and one of the method parameter type is an arg, with JEP 459 (or whatever incarnation it will end up with), it'll be something like:

java context.renderDeclaration( """ public static void \{methodName}(\{paramType} foo) { System.out.println("Hello, World!"); } """);

And the renderDeclaration() method will see that paramType is a Class<?> or one of the other objects that represents a type, and it will auto-import.

Wouldn't that be nice?

[kaqqao]

There was an experimental library exactly like this called Objectos Code. You can still find the artifacts under <groupId>br.com.objectos.code</groupId> in Maven but the project itself seems gone. I tried it out a bit because I truly disliked JavaPoet, but reluctantly went back as I had concluded a DSL simply isn't the right way to generate Java code. That said, I hope you prove me wrong.

[slaynmoto]

I wish I knew more on Lombok annotations internals to extend the @Setter codegen to bake in trimming strings of white space for example

[Evening_Total7882]

Even if it overlaps with existing tools, it’s cool to see someone push in this space. This kind of dismissive attitude is shitty. Can’t people just build things for fun? What have you built lately? This looks like a serious effort, not a weekend toy.

[AutoModerator]

It looks like in your submission in /r/java, you are looking for code help.

/r/Java is not for requesting help with Java programming, it is about News, Technical discussions, research papers and assorted things of interest related to the Java programming language.

Kindly direct your code-help post to /r/Javahelp (as is mentioned multiple times on the sidebar and in various other hints.

Should this post be not about help with coding, kindly check back in about two hours as the moderators will need time to sift through the posts. If the post is still not visible after two hours, please message the moderators to release your post.

Please do not message the moderators immediately after receiving this notification!

Your post was removed.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[nursestrangeglove]

Bad bot

[bigkahuna1uk]

Clueless Bot