question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Issue with Kotlin and Scala interoperability (WsContext/Context)

See original GitHub issue

I’ve created a Github repository that is a SSCCE for the problem. The README there contains more information and details for reproducing the error. https://github.com/adamnfish/javalin-sscce

Actual behavior (the bug)

The message method on WsMessageContext is not callable from Scala. Compiling a project that uses that method gives the following error:

[error] <...>/javalin-sscce/src/main/scala/com/adamnfish/Main.scala:11:14: ambiguous reference to overloaded definition,
[error] both method message in class WsMessageContext of type [T]()T
[error] and  method message in class WsMessageContext of type ()String
[error] match argument types ()
[error]         wctx.message()
[error]              ^
[error] one error found
[error] (Compile / compileIncremental) Compilation failed

Expected behavior

I’d like to be able to use the websockets functionality from Scala, but without any way to call the message method, the library is not very useful.

There may be a way to fix this directly, I’m not familiar with Kotlin but it looks like a problem with how the reification works with Scala. If not solved directly, adding an alternative method that does the same job with a different name would be enough to disambiguate the methods for Scala.

To Reproduce

This repository contains a trivial Scala application that shows the problem. The README contains instructions for reproducing the issue. https://github.com/adamnfish/javalin-sscce

Additional context

I realise Scala is not a priority for the project, but I’ve been very happy with Javalin’s HTTP API from Scala in the past for setting up local development servers. It’d be fantastic to be able to do the same for Websockets servers.

Going one step further, the reification method can also cause Scala to incorrectly compile the project. replacing the message method call with an explicitly typed message method call does compile, but the application fails at runtime.

// does not compile
ws.onMessage {  ctx =>
  ctx.message()
}

// compiles, but crashes at runtime
ws.onMessage {  ctx =>
  cts.message[String]()
}

An excerpt from the stacktrace:

java.lang.UnsupportedOperationException: This function has a reified type parameter and thus can only be inlined at compilation time, not called directly.
	at kotlin.jvm.internal.Intrinsics.throwUndefinedForReified(Intrinsics.java:202)
	at kotlin.jvm.internal.Intrinsics.throwUndefinedForReified(Intrinsics.java:196)
	at kotlin.jvm.internal.Intrinsics.reifiedOperationMarker(Intrinsics.java:206)
	at io.javalin.websocket.WsMessageContext.message(WsContext.kt:85)
	at com.adamnfish.Main$.$anonfun$main$2(Main.scala:12)
        ...

As above, I realise Scala is not a priority for this codebase so this second issue is less likely to be a problem from javalin’s point of view - the goal being to be convenient to use from Kotlin and Java.

For the first problem, it is sad that the library is inaccessible to Scala users at present. Fixing this problem is certainly achievable by adding an unambiguous way to access the message body.

Please let me know if I’ve missed something obvious, or if I can offer any more detail in the repository that demonstrates the difficulty.

Thank you for your time!

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:9 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
tipsycommented, Mar 20, 2021

This was fixed when moving the reified methods out as extensions.

0reactions
Playacemcommented, Jun 7, 2020

@adamnfish Seems like you got the new javalin-without-jetty artifact instead of the regular javalin. I am unsure why this is happening. @tipsy Jitpack might be confused by the new multi module architecture. Compare with this project I found searching the jitpack.io issues: https://jitpack.io/#tangentq-admin/RichTextEditor/v2.0.15 There you can select a sub project but the option is missing for the javalin page.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Issue with Kotlin and Scala interoperability (WsContext/Context)
I've created a Github repository that is a SSCCE for the problem. The README there contains more information and details for reproducing the ......
Read more >
Why Kotlin Did Succeed — And Scala Not - Medium
Having Java and Kotlin side-by-side in a project is no hassle due to extensive compatibility and platform types. Additionally, nullable types ...
Read more >
A Comparison Between Kotlin and Scala - Baeldung
Examine the key characteristics and features of Scala and Kotlin, and how they compare against each other.
Read more >
Kotlin vs Scala: Which Problems Do They Solve? - SuperKotlin
A comparison between Kotlin and Scala focused on what they are good for and pragmatic aspects. An article for developers and technical ...
Read more >
Java is Great but Kotlin and Scala will Take over it Soon
Both Kotlin and Scala have great interoperability with Java, enabling ecosystem sharing. JVM developers have many options for great ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found