Integrate more into (functional) Scala environment

[UkonnRa]

Hi, I am a big fan of Vertx and Scala, so I am very glad to see vertx-scala is growing better and better. While using vertx-scala, there are some annoying problems.

Common Scala

Type issue

Now vertx-scala use original java types instead of their scala alternatives, like the example, which may cause problems when integrate with other scala libraries. At least, it is not that clean. :-)

Functional Scala

Support more functional libraries

I hope vertx-scala can integrate some functional scala libs like Scala Cats and their environment like vertx-kotlin-coroutine, like circe, refined, fs2 and so on. All of them are well-known toolkits in functional scala world!

[codepitbull]

Thank you for your feedback :)

Type issue

I am very well aware of this. The vertx-scala for Vert.x 3 is a full wrapper around VErt.x-APIs.
That allowed me to use native Scala-types but introduced a severe issue:
Mapping can get very expensive:

• Every instance requires an instance of the mapping class
• Mapping back and forth between Java and Scala-types gets very expensive on the GC side

Issue one could be resolved using value classes BUT this wouldn't hiode the exisitngf Java-methods, leading to confusing, mixed API.
Issue two was actually my primary concern since I ran into this working with some fast data examples.

So far the cleanest solution I've found is using value classes to add Scala-features like Futures.

I am still considering to add additional methods to convert between Scala and Java versions but I am quite a bit afraid to produce an inconistent, leaky API.

Functional Scala

Well, I am always open for PRs ;)
But on a more serious note: Since switching jobs I am working with Scala in my freetime only. Providing an API based on one of these libs would require far more experience with them than just playing around with them.

[UkonnRa]

Type Issue

As a brief discussion in SO, converting from Scala Collections/primitive types to Java alternatives will not cause performance issue. But you may try more scenario in Vertx ;-)

And put the performance test on my computer:

[info] Benchmark                  Mode  Cnt   Score   Error  Units
[info] BenchScala._consumeJava   thrpt   20  73.424 ± 3.021  ops/s
[info] BenchScala._consumeScala  thrpt   20  74.641 ± 7.513  ops/s

No difference at all, IMO.

If it's correct, I hope when generating code, you can hide things like jmap.map(p => p._1 -> p._2.asJava).asJava inside. And just don't let users (me :-)) to handle this converting stuff manually.

Thanks a lot!

[codepitbull]

This is a very interesting link.
My observations were that deep forward/backward mapping leads to rather excessive allocations.
Vert.x supports nested structures inside collections which leads to a lot of allocations.
This isn't necessarily a speed problem but can impact the application with excessive garbage collection.
Also: The mapping code gets VERY complicated, especially when things are handed back to java.
Still: I guess I should put numbers to these probably outdated results.
I hope to get some time next week and I will do a little spike in a separate branch to see how hard it would be with my current approach.

Thanks for being persistend ;)

[DavidGregory084]

@UkonnRa I have experimented with integrating Vert.x into Monix if that is useful to you: https://github.com/DavidGregory084/vertices

I have added some conversions to the generated code, but at the moment it's limited to converting Java's boxed primitives to Scala's equivalents.

There are also some type class instances for Vert.x things here.

[DavidGregory084]

I've considered trying the same approach with cats-effect but I don't know it well and don't need the flexibility personally. I could be convinced to try though.

[UkonnRa]

@DavidGregory084 WOW, that IS REALLY what I want! I may try to look at this project. What's the performance comparing with the official Java/Scala API?

[DavidGregory084]

@UkonnRa I haven't done performance testing as I'm not using this in performance-critial code or anything that runs in production. I expect it to be competitive with scala.concurrent.Future because Monix Task generally has better performance (see e.g. https://github.com/ThoughtWorksInc/Dsl.scala/wiki/Benchmarks:-Dsl.scala-vs-Monix-vs-Cats-Effect-vs-Scalaz-Concurrent-vs-Scala-Async-vs-Scala-Continuation and https://kubuszok.com/2019/io-monad-which-why-and-how/#cats-io-vs-monix-task-vs-zio).

[codepitbull]

HEy everyone. Sorry for the long delay but I have rethought a lot of what I was doing in the meantime.
I have just megred a hugh PR I built over the course of the past 2 weeks.
It completely removes Freemarker since it wasn't adding any value and also readds mapping of collections.
It's still not 100% done (generated docs still suck) but I willrefine it more in the comming weeks.

Maybe this can be a basis of more discussions.

I am completely open to add new modules to vertx-lang-scala, what I am doin will remain as sort of a basis by providing the basic API wrapper which we casn put other things on top.

I would be very happy to hget some feedback on the current state.