Live data from Hacker News

Type-safely embed DSLs directly into Java

github.com

11–20 of 27 posts

Re: Type-safely embed DSLs directly into Java

#11

I'm curious how this works under the hood, looks like it's added as an annotation processor, and the DSL is embedded in specially formatted comments, but not in annotations. This implies to me the annotation processor is processing the comments in a source file? I did not know annotation processors could do this! Also implies comments carry through to the compiled .class files which I did not think they did either (r…

Hi, you can blame me for this. It's a Java compiler plugin[1], which is similar to an annotation processor, but can hook into the compiler at a much earlier stage, which allows it to contribute to all phases of the compiler, including the Parser phase. The Manifold plugin takes full advantage of this, hence its ability to analyze comments, contribute to bytecode generation, etc.

[1] https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com...

Re: Type-safely embed DSLs directly into Java

#12

I'm curious how this works under the hood, looks like it's added as an annotation processor, and the DSL is embedded in specially formatted comments, but not in annotations. This implies to me the annotation processor is processing the comments in a source file? I did not know annotation processors could do this! Also implies comments carry through to the compiled .class files which I did not think they did either (r…

Hi, you can blame me for this. It's a Java compiler plugin[1], which is similar to an annotation processor, but can hook into the compiler at a much earlier stage, which allows it to contribute to all phases of the compiler, including the Parser phase. The Manifold plugin takes full advantage of this, hence its ability to analyze comments, contribute to bytecode generation, etc. [1] https://docs.oracle.com/javase/8/d…

So you have a javascript frontend hooked into the java compiler? Or how does your javascript integration work?

Re: Type-safely embed DSLs directly into Java

#13

Earlier quoted context omitted.

Hi, you can blame me for this. It's a Java compiler plugin[1], which is similar to an annotation processor, but can hook into the compiler at a much earlier stage, which allows it to contribute to all phases of the compiler, including the Parser phase. The Manifold plugin takes full advantage of this, hence its ability to analyze comments, contribute to bytecode generation, etc. [1] https://docs.oracle.com/javase/8/d…

So you have a javascript frontend hooked into the java compiler? Or how does your javascript integration work?

At compile-time manifold-js[1] parses JS and generates Java types (stubs), which forward execution to rhino at runtime. Basically, JS seamlessly mapped onto Java's type system.

[1] https://github.com/manifold-systems/manifold/tree/master/man...

Re: Type-safely embed DSLs directly into Java

#14
Except it is not really embedded in Java, only in comments.

I sincerely hope this dies a quick death.

Java with its jars and infrastructure already makes it plenty convenient to work with resources without them having to be in your face when you are editing the file. Good IDE lets you move between the resource file and the code with a single click.

Re: Type-safely embed DSLs directly into Java

#15
post #14

Except it is not really embedded in Java, only in comments. I sincerely hope this dies a quick death. Java with its jars and infrastructure already makes it plenty convenient to work with resources without them having to be in your face when you are editing the file. Good IDE lets you move between the resource file and the code with a single click.

> Good IDE lets you move between the resource file and the code with a single click.

Well, not exactly. Most IDEs do NOT support clicking through a generated method call to the corresponding element in a resource file. Manifold is all about that. See it in action: http://manifold.systems/images/graphql.mp4

The Manifold fragments discussed here address only a narrow band of use-cases where embedding the resource improves the dev experience, like with queries and such. It's not for everyone, though.

Re: Type-safely embed DSLs directly into Java

#16
post #14

Except it is not really embedded in Java, only in comments. I sincerely hope this dies a quick death. Java with its jars and infrastructure already makes it plenty convenient to work with resources without them having to be in your face when you are editing the file. Good IDE lets you move between the resource file and the code with a single click.

Yeah, I'm not sure I get it either. More power to the author for solving a problem they may have, but I have yet, in my 20+ years experience with Java, had a need to do this kind of code embedding in the source code (whether in comments or not). Sure, it's nice to be able to run other languages at run-time (e.g. GraalVM, etc), but is there really a need to have this kind of language interoperability at compile time?

Re: Type-safely embed DSLs directly into Java

#17
You can write other languages like this in Groovy using Intellij. Intellij allows you to annotate a multiline string as another language, then it will parse and syntax color, autoformat for you. The use case would be when you are templating frontend code snippets on the server side. I'm not sure if its just Groovy though, I'm betting Intellij can probably do this with other languages that have multiline strings.

Re: Type-safely embed DSLs directly into Java

#18
post #16
post #14

Except it is not really embedded in Java, only in comments. I sincerely hope this dies a quick death. Java with its jars and infrastructure already makes it plenty convenient to work with resources without them having to be in your face when you are editing the file. Good IDE lets you move between the resource file and the code with a single click.

Yeah, I'm not sure I get it either. More power to the author for solving a problem they may have, but I have yet, in my 20+ years experience with Java, had a need to do this kind of code embedding in the source code (whether in comments or not). Sure, it's nice to be able to run other languages at run-time (e.g. GraalVM, etc), but is there really a need to have this kind of language interoperability at compile time?

> but is there really a need to have this kind of language interoperability at compile time?

Well, if you want to leverage Java's static type system (and why not?), the answer is, yes. I imagine you'd want type and member references to the other language to resolve statically using the compiler, right? Similarly, why not have the same functionality in your IDE? Plus code completion, usage searching, refactoring?

Now, as I mentioned in an earlier comment, the embedding part of this addresses just a small segment of use-cases e.g., scoped query editing. The vast majority of other cases work directly against resource files, type-safely. Read more about that here:

https://github.com/manifold-systems/manifold

Re: Type-safely embed DSLs directly into Java

#19
post #17

You can write other languages like this in Groovy using Intellij. Intellij allows you to annotate a multiline string as another language, then it will parse and syntax color, autoformat for you. The use case would be when you are templating frontend code snippets on the server side. I'm not sure if its just Groovy though, I'm betting Intellij can probably do this with other languages that have multiline strings.

Right, but that is just syntax highlighting. This is resolving the content of the string type-safely, at compile-time.

Re: Type-safely embed DSLs directly into Java

#20
post #16

Earlier quoted context omitted.

Yeah, I'm not sure I get it either. More power to the author for solving a problem they may have, but I have yet, in my 20+ years experience with Java, had a need to do this kind of code embedding in the source code (whether in comments or not). Sure, it's nice to be able to run other languages at run-time (e.g. GraalVM, etc), but is there really a need to have this kind of language interoperability at compile time?

> but is there really a need to have this kind of language interoperability at compile time? Well, if you want to leverage Java's static type system (and why not?), the answer is, yes. I imagine you'd want type and member references to the other language to resolve statically using the compiler, right? Similarly, why not have the same functionality in your IDE? Plus code completion, usage searching, refactoring? Now,…

I’m not at all contesting your reasons, which I expect were plentiful enough to build this system. I’m simply saying that if I want to use Java’s static type system, I’ll just write in Java. Perhaps I’m an old codger these days in my ripe early 40s.
Post reply on HN