Add support for more JVM languages.

[squidfarts]

Conserving Meson, it supports Java, so there should be other JVM languages supported, correct?

The jar function should be the perfect candidate for compiling other JVM languages like Groovy, Kotlin, Scala, to a jar file.

By making the jar function the main target for compiling JVM languages it would become a generic function instead of being a Java only function. And this would open potential possibilities for more polymorphism between programming languages.

This would be perfect for a multi language build tool.

[jpakkane]

We do want to support other JVM languages. The limitation, as always, is time.

[squidfarts]

Well it is true that time is an important resource. However it would be nice if the jar command would be more generic and support more JVM languages. I would think that Kotlin would be a good pick for starting because it is one hundred percent compatible with Java (at this time) and it is a fairly new language with a healthy community that seems to keep growing.

[jkbbwr]

Speaking of it will probably be important to handle JVM dependencies ala maven/gradle or you wont get very far.

[squidfarts]

What about a module for Maven and or Gradle, I know Meson has one for CMake.

[sequencer]

Any progress on this issue? Scala users have been fed up with sbt :p

[dcbaker]

I've toyed a tiny bit with scala using meson, but I don't think there's been any serious work that's gone into it. If you want to work on it I'd be happy to advise :)

[dcbaker]

Ironically one of the main reasons I didn't pick scala for a project I worked on a while back was sbt, lol

[sequencer]

Ironically one of the main reasons I didn't pick scala for a project I worked on a while back was sbt, lol

LOL. I suggest you can use mill to replace sbt. But finally I think we need a meson support ;p

So basically, there are some jobs to be resolved:

1. BSP server to integrate with IDE.
2. support maven with coursier
3. scalac plugin.
4. how to compose a publish module and way to manage the dependency.

But most of them seems possible to resolve.

[jkbbwr]

The biggest issue we have is using meson to invoke java JNI header compiler stuff. The generator abstraction is really brittle.

[dcbaker]

There's https://github.com/mesonbuild/meson/pull/8229, would that solve the JNI problem?

[jkbbwr]

No, the issue was more invoking the java header generator for existing java code. I can't dig up a specific example at the moment but it would generate the files in a non-standard way.

[dcbaker]

okay

[tristan957]

No, the issue was more invoking the java header generator for existing java code.

Are you talking about this from javac:

  -h <directory>             Specify where to place generated native header files

This only creates stubs correct? Would it be useful for Meson to do this in the first place? I am not sure there is any benfit here from a Meson POV if I understand you correctly @jkbbwr.

java = import('java')
generated_include_dir = java.generate_native_headers(path / to / dir)
javac_c_ext = shared_module(..., include_directories: [ generated_include_dir ])

Maybe there is usefulness?

[jkbbwr]

Yea, so currently we have a make file that kicks off the stub generation but it doesn't generate them in a way that meson will actually accept them.

We are finding meson to be very brittle lately. This was another situation that really stung.

We ended up wrapping meson + maven with make.

[tristan957]

@xclaesse is this a good use case for a Java module?

[tristan957]

@jkbbwr I am confused how a custom target wouldn't solve your issue for now.