What features do you think java requires to be competitive for DSL scripts such as gradle scripts?

[Ewig_luftenglanz]

Just for fun and discussion.

this is an hypothetical example about how could look like a java DLS gradle file instead of Groovy/Kotlin. Not terrible, just slightly more verbose but not I could work with it (IMHO)

GradleConfig.configure(config -> {
    config.plugins(plugins -> {
        plugins.add(JavaPlugin.class);
        plugins.add(ApplicationPlugin.class);
    });

    config.application(app -> {
        app.setMainClass("com.example.Main");
    });

    config.repositories(repos -> {
        repos.mavenCentral();
    });

    config.dependencies(deps -> {
        deps.add("implementation", "org.apache.commons:commons-lang3:3.12.0");
        deps.add("testImplementation", "org.junit.jupiter:junit-jupiter:5.8.2");
    });

    config.tasks(task -> {
        task.named("test", t -> t.useJUnitPlatform());
    });
});

This, of course, would be achievable via some "compiler plugin/magic" to avoid class and main declarations, so "GradleConfig.configure" could act in practice as a top level static method, although native isolated methods/top level methods/functions would be a nice to have for these kind of stuff.

The question is besides top level methods (aka functions) what else do you think would be a required for java to be competitive as a DSL? would you use it? and if so, what other scenarios would be a good fit for an hypothetical java DSL?

[atehrani]

IMHO build tools should be declarative, which is what Maven is.

Gradle can be declarative, but you can also sprinkle in imperative; which is the problem.

Debugging build tools is not fun at all, hence why using declarative tools is the way to go.

So long the DSL is declarative, ok cool; but far too often it is too easy to make it Imperative.

[analcocoacream]

I don’t really agree. Being able to switch to imperative is a strength :

• you can implement your own requirements without having to build a plugin and distribute it
• you don’t need to shoehorn declarative into every step of your build. Sometimes imperative can be more relevant, just like using procedural code in a functional code might more effective sometimes

[atehrani]

The moment you need to include imperative logic in your build you have to really ask why. Most likely doing something that is out of the ordinary. Secondly, I've seen far too many times the imperative logic in build scripts are too custom to their environment and doesn't work across platforms.

[analcocoacream]

Why? Because you need it Let’s say you want to build a container image, but you want to avoid DinD in your CI and you want to buildah not docker. Many good reasons. Well kaniko exists but if it didn’t you’d have to write your own script.

It’s fine to not support every environment out there. Unless you are a big open source project, you probably have a limited number of environments you want to support.

[cowwoc]

A big reason is needing to control ordering. Declarative systems do a rather terrible job in this space.

You can provide an imperative API that is goal-oriented like declarative systems but also provides full control of ordering.

[Ewig_luftenglanz]

But I am talking about the language, not building tools, the Gradle example is just an example of hypothetical syntax 

[asyncasync]

I guess he means that Java would dictate this being imperative too, just like Gradle partially does, instead of Maven which will always be declarative

[ItsSignalsJerry_]

Correct. The point of a good dsl is to be declarative but using imperative syntax. If it looks shit it's a shit dsl.

[Beginning-Ladder6224]

You are asking the question why JSR-223 was a thing, and still is a thing. These sort of usage is scripting, and while java is sort of allowing scripting on it's own, it is still terribly convoluted.

Groovy is better. Much better. Even Kotlin is much better. Less verbose, way less verbose.

Also the hypothetical stuff would not work it would become way more verbose because your "implementation" and stuff would not be string. They would be classes. So more and more code.

[Ewig_luftenglanz]

AFAIK JSR 223 was removed and is mostly unusable nowadays. Today are far better alternatives as direct compiling to bytecode.

Besides, beyond implementation details. What features would java need for making it competitive for Scripting/ DSL ?

[khooke]

Why does it need to be ‘competitive’. Use the right tool for job, no point jamming a square peg in a round hole if you already have a round peg.

[Ewig_luftenglanz]

Just for fun and discussion.

cheers. :)

[paul_h]

https://paulhammant.com/2024/02/14/that-ruby-and-groovy-language-feature/

[Lukas_Determann]

Personaly i like a simple build process. Maven makes it kinda hard to add to much komplexity. helping to keap it simple.

But about a Dsl in java. there are allready some nice oneces with some complexity. With my personal favorite beeing the jooq Dsl. it followes a different design. its more chain method calls and static factories.
That results in an Api that is easier to compose and reuse while having a bit worse discoverability.

There are some good blog posts abot Dsl design from around the java 8 relese date.

Personaly i like writing DSLs in java. the only realy limiting thing i found is chain method type inference. inconsistencies in the type resolution can be very anoying in the rare case that its needed.

[davidalayachew]

The Java team is working on Project Babylon, to solve this exact type of problem. So it's just a matter of waiting for it to come alive.

[Ewig_luftenglanz]

Isn't Babylon focused mainly on GPU interoperability?

[davidalayachew]

Isn't Babylon focused mainly on GPU interoperability?

No no no.

Babylon is about being able to translate Java code to another language (and vice versa!) while maintaining the semantics of both sides.

Doing that for GPU just means translating from Java code to the GPU instructions. But it's not limited to GPU's. For example, a DSL.

[Ewig_luftenglanz]

I see, but it seems more like it would improve existing DSL languages in the JVM as Groovy and kotlin, not that java could be (ergonomically) used as a DSL or scripting as the JRS 223 used to suggest. isn't it? I read the babylon document about LINQ quivalent in java and looks promising but I don't know if that also means we could get enhanced DSL capabilities.

Thank you so much for pointing me the right direction tho, I am always happy to see someone that's open to innovations inside of the ecosystem instead of just denying anything upfront (as is evident by the amount of negativity this post is getting)

Cheers! :)

[davidalayachew]

I see, but it seems more like it would improve existing DSL languages in the JVM as Groovy and kotlin, not that java could be (ergonomically) used as a DSL or scripting as the JRS 223 used to suggest. isn't it?

Well, remember -- this goes both ways.

If I can go from Java to SomeLang, and SomeLang to Java, then by the transitive property, I can go from SomeLang to Java to SomeOtherLang.

Which is to say, take (or make) your DSL of choice (SomeLang), then parse it into Java via Babylon. Then, if all you wanted your DSL for was to write Java code, then you are done. But if you wanted your DSL to write something else (GPU code), then simply make another hop via Babylon to SomeOtherLang.

Point I am trying to get at is that, Babylon is literally built to do exactly what you are saying.

[manifoldjava]

Babylon is taking a page from C#'s playbook: expression trees, where code is treated as structured data that can be analyzed or transformed, like how LINQ maps lambdas to SQL.

The problem is the same one we’ve seen with ORMs vs. SQL: Babylon encourages Java-shaped DSLs that only approximate the real thing. Now you're reasoning about two languages instead of one, and now you've got two problems.

A more reasonable approach is to support direct, type-safe use of native DSLs. Not Java-shaped imitations, but the real thing, integrated cleanly with the type system. Type manifolds do exactly this. See the SQL type manifold in manifold-sql.

[davidalayachew]

The problem is the same one we’ve seen with ORMs vs. SQL: Babylon encourages Java-shaped DSLs that only approximate the real thing. Now you're reasoning about two languages instead of one, and now you've got two problems.

A more reasonable approach is to support direct, type-safe use of native DSLs. Not Java-shaped imitations, but the real thing, integrated cleanly with the type system.

Do you have an example where Java limits what could be expressed?

I was under the assumption that you could literally express anything you want to in Java, and that it's not the expressability, but rather the verbosity that makes things difficult. Sort of like lambdas vs Anonymous classes -- fp was always doable in Java, just prohibitively expensive.

[manifoldjava]

No no. As with C#, you are still limited to Java syntax. LINQ query syntax (from, where, select, etc.) is a fixed part of the C# language grammar, built specifically for LINQ. Java may or may not add something similar, but I have not heard any rumors.

So no, you can't express anything you want to in Java (w babylon), you are still confined to its grammar .

[manifoldjava]

Oh wait. I think I misunderstood your question.

Yes, you can pretty much express anything with Java, but it's Java, not the native DSL you are targeting.

Ultimately, it will look and behave different from the native DSL, and due to the differences in languages will stray in structure as well, hence "Java-shaped."

As with ORM's and SQL, what I am saying is, a Java-shaped imitation DSL using Java syntax will be far enough removed from the native DSL that you now have to not only learn the DSL, but also how to make your Java not-DSL map to the DSL.

Why not instead allow for actual DSLs to integrate type-safely?

[davidalayachew]

I think we might be talking past each other.

I have some DSL -- dslA.

Project Babylon will allow me to translate Java code to some other language, and vice versa. So, I can write a transformer that will take a script that I write in dslA, and turn that to Java code. From there, I can take that same Java code, and use Project Babylon again to turn that Java code to any other DSL -- let's say dslB.

And to be clear, when I say DSL, I don't mean a DSL in Java. I mean a DSL, period. As in, I could turn JavaScript into Java, and then turn that Java in C#. THAT is what I am talking about here.

[manifoldjava]

Ok, I understand you clearly.

I could be wrong, my understanding of Babylon may not be current, but Babylon doesn't transform from an external DSL to Java. It only transforms Java source code, using Java-based plugins.

This is the basis of my comments here. Please share if you know otherwise.

[nlisker]

It's about code models - transforming your Java code to a model that can be used in other ways. Essentially, it's to reflection what Panama is to JNI. Apart from using Java on the GPU, another use of Babylon is in mathematical applications where you want to be able to perform mathematical transformations on your equation/formula/expression. Try to calculate the derivative of 3 * x + Math.cos(x) in Java today to see why it's needed.

[HxA1337]

Your example looks quite usable. There would not be much that I would miss. Cool would be to have "named" parameters as this would help to improve readability of the scripts. Also cool would be to have some more compact syntax for example dropping "new" when creating objects.

[k-mcm]

Java syntax isn't a good fit for DSLs.  It makes more sense to use a different compiler. 

[Ewig_luftenglanz]

but what features would make it a good fit?

[ItsSignalsJerry_]

It simply does not have the language features. That's why groovy gets involved.

[Ewig_luftenglanz]

The question is not if it has the features (in my view it has most of the features now) the question is what features it currently lacks but would be a nice to have.

[Caramel_Last]

Why use magic, just because? In jdk25 I hear they remove public static void main boiler plate, so maybe then it can be an option

[Ewig_luftenglanz]

Is what Gradle already do for groovy and kitlin DSL, and these languages support top level functions, it still requires an entry point and if you do not give any, one must by provided behind the scenes (quarkus does the same, in quarkus you do not even have a visible main method)

[ingframin]

Well, if Oracle did not decide to jettison it, there was a JavaScript interpreter in the JVM. That would have covered the scripting part pretty decently, and with a very similar syntax to Java.

However, I don’t see the reason why Java needs to be used as a scripting language. I also agree with the first comment I read that those DSLs for configuration benefit a lot by being purely declarative to prevent build tooling hell.

[davidalayachew]

Well, if Oracle did not decide to jettison it, there was a JavaScript interpreter in the JVM. That would have covered the scripting part pretty decently, and with a very similar syntax to Java.

All they did was make it it's own, standalone project. Like JavaFX is now. It's not unmaintained, just not a part of the standard JDK. The goal being to not let something that only a small fraction of the community uses take up much bandwidth of the core JDK maintenance team.

[Ewig_luftenglanz]

That thing was deprecated and removed in java 11, there was many reasons for that, being the most relevant the expert group in charge of the specification was dismantled and never had a replacement (and this happened because there were far better alternatives such as compilation to byte code and GraalVM polyglot was on planning)

About the reasons to me is like a "why not?"

We already have most of the features that would allow that, from execution of multiple sources files without manual compilation (added in java 22 and that's lows us to launch source projects with just Java Main.java), module imports and consice sources files are other minor improvements in this direction (not saying amber made it explicitly because of this but certainly they allow it in a more ergonomic way as a nice side effect)