Show HN: Javalin, a Java/Kotlin REST API Framework | Hacker News Reader

Show HN: Javalin, a Java/Kotlin REST API Framework

javalin.io

50 pointsjavalin21 comments

The "Fully Fluent API" seems to be a style adopted as a workaround for the clumsiness of the Java language, as far as I can tell. In Kotlin it's not necessary and just looks a bit weird.

This example in Java:

  Javalin app = Javalin.create()
      .port(7000)

  app.start()
     .awaitInitialization()
     .stop()
     .awaitTermination();

could be written more naturally in Kotlin:

  val app = Javalin.create().apply {
      port = 7000
  }
  
  with(app) {
      start()
      awaitInitialization()
      stop()
      awaitTermination()
  }

...except that Javalin doesn't seem to implement the normal convention for getters and setters, so the apply block wouldn't work.

Thanks, this is good feedback. I'm still at the stage where I'm "writing Java in Kotlin".

Is "with" a keyword, or is it just convention - I haven't been able to find it documented anywhere. It seems like it's just doing a function with receiver under the hood.

It's an ordinary function: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/with.htm...

Thank you - searching for the word with was unfruitful for me.

This is a recurring theme with Kotlin: inline receiver functions with a lambda parameter are an amazingly versatile tool for building functions that implement what would be a language feature/syntactic sugar in other languages. `with` here is a good example, but `let` and `use` are other good examples of this in play (`use` gives you try-with-resource, let plays nicely with the ?. safe navigation operator to execute code on non-null objects `maybeNullObject?.let { doStuffWith(it) }`)

Are you really saving much? Non-fluent API:

    Javalin app = Javalin.create()
    app.port(7000)

    app.start()
    app.awaitInitialization()
    app.stop()
    app.awaitTermination()

And three lines shorter than the kotlin one.

In this case we happened to have a variable already defined with a short name, but in other cases the name might be longer or you might have to introduce a temporary variable. If you don't need the reference to app in the rest of the program, you can do away with the name entirely:

  with(Javalin.create()) {
      port = 7000
      start()
      awaitInitialization()
      stop()
      awaitTermination()
  }

When in comes to the question of how much this is saving us... the Java designers seem to have thought it was worth something, since Java has a somewhat similar feature: a method calling another method on the same object can leave out "this".

Python on the other hand doesn't have the implicit "this", so the JUnit API (the unittest module in Python) actually becomes uglier in Python. Instead of this in Java:

  class TestNumbers extends TestCase {
      public void testArithmetic() {
          assertTrue(1 + 1, 2)
          assertFalse(10 * 10, 100)
      }
  }

Python needs an explicit self variable:

  class TestNumbers(unittest.TestCase):
      def test_arithmetic(self):
          self.assertEqual(1 + 1, 2)
          self.assertEqual(10 * 10, 100)

> the Java designers seem to have thought it was worth something, since Java has a somewhat similar feature: a method calling another method on the same object can leave out "this".

True, though the reason what that Java should be "familiar", so it did the same thing as C++.

IMO, Python did the right thing by not having magic variables.

Functional code + this starts getting messy, ala JS.

This looks nice but so far I'm thrilled with ktor (which is very much in development).

Some of the main draws are:

- It supports multiple server hosts (Jetty, Netty, Tomcat as well as running as a servlet)

- It's Kotlin done by the JetBrains guys so very much Kotlin to the core

- It supports co-routines

Not trying to throw water on your hard work, but what reasons would I want to consider Javalin?

> but what reasons would I want to consider Javalin?

I'm not really trying to convince devs whose main language is Kotlin to use Javalin, it's made more for Java devs and Java devs who are looking to switch to Kotlin.

That being said..! Ktor Hello World example isn't very pretty, and I can't find the docs. All I found was a mostly empty wiki. Where are the official docs?

By the way, pull-requests for other embedded servers would be very welcome in Javalin.

The Kotlin sample on the homepage isn't idiomatic, i.e. the handler should be written outside of the parentheses.

Thanks for spotting that, fixed.

So Javelin is written in Java, not in Kotlin. I don't mean to sound unfair but isn't it that saying "a Java/Kotlin blah blah" just a kind of marketing trick ? If I get Kotlin right every Java solution is also Kotlin compatible.

There's a difference between just being compatible and nice to work with. Javalin is being developed with Kotlin in mind. I'm a Java dev who wants to transition to writing Kotlin, but most companies are not very eager to make the switch. Javalin is intended to help ease this transition.

Ok, thanks that sounds fair.

How is this pronounced? Like it's spelled, or like "javelin?"

Good question. I'm Norwegian, and I always pronounce it "ya-va-lin" when I talk about it in Norwegian. Let's say that's the official pronunciation.

how is this different from Spark Java aside from the name that is

I should probably create a comparison chart, but in short:

Javalin has no static API, and no concept of "Routes and Filters". In spark Routes have a return value, in Javalin you just have "Handlers" which operate on the request and response. Javalin can do automatic object-mapping to and from json, and has lifecycle events.

Javalin has a built in mechanism for auth (AccessManager)

Javalin has no WebSocket support, and doesn't do static file handling (it leaves this to the embedded server). Javalin runs before-handlers before static files, Spark does not.

Javalin has a fluent api.

Javalin is implemented as a servlet, not a filter.

After-handlers are run after everything (even in case of exceptions), (Spark has after-after filters).

There are many more small differences. I'm one of the maintainers of Sparkjava. Javalin is the result of using Spark daily for the past two years, fixing minor annoyances and including new concepts I would find myself implementing over and over again.

It looks like express so it's got to be hip.

Reply on news.ycombinator.com