
Show HN: Javalin, a Java/Kotlin REST API Framework - javalin
https://javalin.io
======
ptx
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.

~~~
paulddraper
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.

~~~
ptx
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)

~~~
paulddraper
> 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.

------
jarym
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?

~~~
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.

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

~~~
javalin
Thanks for spotting that, fixed.

------
lorenzosnap
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.

~~~
javalin
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.

~~~
lorenzosnap
Ok, thanks that sounds fair.

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

~~~
javalin
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.

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

~~~
javalin
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.

