Scala and the future of Jelly-JVM

[Ostrzyciel]

I love Scala. It's such a nice language. But, it also comes with a lot of additional overhead that complicates things in a project like Jelly-JVM.

• I had to work around a lot of performance issues, most of which would not exist in Java.
• Using Jelly-JVM requires one to use the Scala library (in a specific version), which adds to the bloat and makes things "less nice" for people not using Scala.
• Maintaining compatibility over multiple Scala versions is a pain. See Add fake Scala 2 builds #105 and Remove support for Scala 2 #150
• Using Jelly-JVM from Java would not look that great, with all these implicits and whatnots.

I'm wondering if it wouldn't make more sense to someday rewrite the whole thing in Java. We could then add user-facing (optional) APIs in Scala, so that Scala fans would have mostly the same experience as they do today.

Open questions:

• How to handle the namespace changes? Some backwards-incompatible changes will surely be needed.
• How do other libraries do this kind of thing?
• Would wrapping the Java APIs in Scala affect the performance negatively?
• How to design the Java APIs to still look "nice", even without all the powerful features of Scala?

This of course is not a first priority. This may be a good thing to reconsider if we will have more compat-breaking features to lump together in something like a 3.0.0 release.

[berezovskyi]

Have not started to use Jelly yet, but keeping an eye on it - great work, hope to get to use it someday soon! I have experience using a Scala lib in a Java project (SHaclEX in Eclipse Lyo), so maybe could offer a few opinions:

Using Jelly-JVM requires one to use the Scala library (in a specific version), which adds to the bloat and makes things "less nice" for people not using Scala.

I think there is more noise/preference about this one than real issues. If you decide you need a certain library, you bring it and its dependencies. Thousands of people use Spark from Java and don't complain (or complain and still do it because it pays the bills). Lots of software needs Electron and therefore is much more bloated than using your lib will (probably) ever be. A more important issue from my side is to minimise a number of deps with high CVE count but I do not consider Scala runtime libs to fall under that.

Maintaining compatibility over multiple Scala versions is a pain.

This one I am actually most curious about. How does it work if I in my Java project depend on two Scala libs (SHaclEX and Jelly Jena, for example), do I have to ensure that they both target the same Scala version (assuming I don't care about bloat but only about correctness)? I see that https://github.com/weso/shaclex/blob/master/build.sbt supports 2.12, 2.13, and 3.2.

Using Jelly-JVM from Java would not look that great, with all these implicits and whatnots.

How to design the Java APIs to still look "nice", even without all the powerful features of Scala?

I think it's fine. I think IO libs like cats are more troublesome to deal with. We had to write our facade class to SHaclEX - if Jelly provides something like this, could be even better. Would also be nice to to not to expose object Xyz Scala declarations to user (as in, making that a prominent part of the public API) because on the Java side you would have to call something like Xyz$.MODULE$. to access its methods/fields. But other than that I don't see an issue - i.e. I am quite fine receiving Option/Either when working in Java.

[Ostrzyciel]

@berezovskyi Hi! Thank you for your perspective, this is very useful!

I think there is more noise/preference about this one than real issues. If you decide you need a certain library, you bring it and its dependencies. Thousands of people use Spark from Java and don't complain (or complain and still do it because it pays the bills). Lots of software needs Electron and therefore is much more bloated than using your lib will (probably) ever be. A more important issue from my side is to minimise a number of deps with high CVE count but I do not consider Scala runtime libs to fall under that.

Fair point. The library with the most CVE potential in Jelly-JVM is Google's protobuf (in Java), but I'm keeping a close eye on it. There aren't really other dependencies of the core module, besides Scala itself.

Maintaining compatibility over multiple Scala versions is a pain.

This one I am actually most curious about. How does it work if I in my Java project depend on two Scala libs (SHaclEX and Jelly Jena, for example), do I have to ensure that they both target the same Scala version (assuming I don't care about bloat but only about correctness)? I see that https://github.com/weso/shaclex/blob/master/build.sbt supports 2.12, 2.13, and 3.2.

As far as I understand, in Scala 2 you'd have to have all libraries using the same MINOR release of Scala. In Scala 3, there is an LTS system where libraries are encouraged to target LTS releases (e.g., 3.3, as in Jelly), because these are supported for multiple years.

In theory, if you used two libraries: one on Scala 3.2, and one on 3.3, you could have compatibility problems. You would have to override the the scala lib dependency one way or the other. In reality, I don't think any problems are likely unless you are using something huge and complex like Cats or Apache Pekko. Jelly-JVM is a simple lib, so it should work fine with whatever Scala 3.x version you throw at it. If you do encounter any compat issues, however, please let me know. Fixing this should be easy.

Historical note: Jelly-JVM used to support Scala 2, mostly because I had a Scala 2 project that I needed to demonstrate working with Jelly. However, making Scala 3 libs work on Scala 2 is a dependency hell, and Scala 2 is legacy tech. If there is a real demand for Scala 2 releases, bringing them back is not out of the question... but reluctantly :)

I think it's fine. I think IO libs like cats are more troublesome to deal with. We had to write our facade class to SHaclEX - if Jelly provides something like this, could be even better. Would also be nice to to expose object Xyz Scala declarations to user (as in, making that a prominent part of the public API) because on the Java side you would have to call something like Xyz$.MODULE$. to access its methods/fields. But other than that I don't see an issue - i.e. I am quite fine receiving Option/Either when working in Java.

OK! A facade class sounds like a reasonable solution. If you end up writing something like this, let me know or just open a PR, this may be useful for more people.

Last point: if you are using Jelly just via RDF4J Rio or Jena RIOT (the I/O components of these libraries), then you won't even see Jelly in your code. Jelly is automatically registered in these just like any RDF format.