
Show HN: Javalin 1.0 – A Kotlin/Java web framework - tipsy-
https://javalin.io/news/javalin-1.0.0-stable.html
======
danneu
Good job reaching a stable release.

I have a Kotlin microframework that never made it past hobby-level
stability[1].

One thing I found out is that you really have to write a library in Java if
you want it to be used in both Java and Kotlin. Java -> Kotlin is effectively
one-way interop.

I also found async programming to be really hard in Java which is why I
wrapped Jetty. Meanwhile async APIs like Netty and Undertow were completely
exotic to me.

For example, I couldn't figure out how to go from `Request -> Response` to
`Request -> Promise<Response>` by wrapping Netty.

One thing I did find out was that Kotlin is probably my favorite language.
Very similar to Swift, though I wish you could re-open 3rd party classes to
make them conform to additional interfaces which you can do with Swift
protocols.

I also never figured out how to hot reload code without restarting the server.
Even JRebel didn't work for me. Looking at Jetbrains' own framework, their
code that implements reloading is pretty intimidating[2].

OP is also the author of
[https://github.com/tipsy/j2html](https://github.com/tipsy/j2html) which I've
been using in my own small servers. I couldn't figure out a better way to get
typesafe html templating in the ecosystem.

[1]: [https://github.com/danneu/kog](https://github.com/danneu/kog) [2]:
[http://ktor.io](http://ktor.io)

~~~
tsvetkov
> Java -> Kotlin is effectively one-way interop

Could you provide some more details? I'm a bit surprised by your statement
because Kotlin team has put a lot of effort into providing mostly seamless two
way interop. Kotlin project itself is ~50% Java (specifically to test
interop).

~~~
danneu
I'm really rusty, but if I can recall the simplest example correctly, you
can't just naively go from this Kotlin code:

    
    
        Server { req -> Response().html("<h1>Hello world</h1>") }
    

to this Java code:

    
    
        new Server(req -> new Response().html("<h1>Hello world</h1>") 
    

Because Server is implemented in Kotlin and the Java lambda certainly isn't a
kotlin.Function.

If that's a bad example (foggy memory), another one would be the use of
@DslMarker or reflection to build my type-safe router:
[https://github.com/danneu/kog#type-safe-
routing](https://github.com/danneu/kog#type-safe-routing). Or how about inline
functions with reified generics.

Kotlin does have Kotlin->Jvm interop annotations, but my take-away was that
you would have to put some thought into your API and possibly make concessions
so that you could sufficiently annotate it to the point that it's pleasant to
use from Java. Not everything maps.

For example, you can see that OP went the route of using Java at the interface
edges yet Kotlin internally to solve interop for their project.

I admit that "effectively one-way interop" is too heavy-handed of a statement,
but there's definitely asymmetry that I ran into on my own project. For
example, I would not recommend building something in Kotlin in the hopes that,
once you're done, you can just sprinkle on some @Jvm annotations and end up
with an API that's compelling to use from Java.

~~~
nostrademons
That's because the concept of a typed lambda function doesn't really exist in
Java; in Java 8 lambdas are syntactic sugar for SAM-type object creation.
(There are other interface warts too: @DslMarker and parameterized receivers,
as you mention; treatment of void vs. Unit; different default collection
types; destructuring data types, and the need to clutter your code with 'new'
if you use them a lot; etc.)

It's similar to any interop problem: if you want your library to be accessible
from lots of languages, its interface better be the lowest common denominator
of the features they support.

There's nothing stopping you, though, from defining your interfaces in Java
and then implementing those interfaces in Kotlin. The Kotlin interop code even
will do a good job letting you use Kotlin's syntactic sugar for this, eg. you
can pass Kotlin lambdas to functions that expect a SAM-type, or use 'with()'
to treat a conventional builder pattern as a DSL.

------
norswap
Can someone illuminate me on the necessity/benefits of embedding Jetty? I can
never seem to understand what it offers that java.nio does not on a
fundamental plumbing level (for sure, Jetty provides a lot of convenience
classes on top of that plumbing), yet I see a lot of projects that could
potentially get away with the plumbing embed Jetty and its thousand(s?) of
minimally documented classes.

~~~
le-mark
_I can never seem to understand what it offers that java.nio does not on a
fundamental plumbing level (for sure, Jetty provides a lot of convenience
classes on top of that plumbing)_

Creating a minimalist server is an interesting excercise, everyone should do
it to see how it's done imo. BUT it's the stuff like parsing http headers,
query parameters, and request bodies (formencoded, chunked files?) that make a
solution like Jetty worth while. Again, writing an http parser is a valuable
learning experience, but your boss _really_ doesn't want you spending time on
it, OR paying to support it going forward.

As an aside, it used to be a thing in the late 90's early 2000's for every
application out there to have it's own "XYZ Transport Protocol" ie XYZTP, and
it really, really _sucked_.

~~~
saurik
And it isn't like this stuff is exactly trivial: with content transfer
encodings, trailers, and exotic stuff like Expect: 100-continue, no one ever
does this stuff correctly when they think they can just throw it together :/.

------
kentosi
Great framework. I hope it takes off.

Oh a separate note, I'm relieved that for once the java version of demo code
isn't twice as long as $otherJvmLanguage. Java's come a long way.

~~~
tipsy-
Thanks! Java8+ is what you make of it really. The syntax and standard APIs are
still a bit clunky compared to $otherJvmLanguage, but you can make great APIs
in Java.

------
patates
This is a bit off-topic, but, as we are already discussing Kotlin, for a
person new to the whole Java world, does anyone have a suggestion for a good
ORM which plays nicely with Kotlin? (Elephant in the room being Hibernate but
I'm intimidated by the complexity. Looking for something way more
lightweight).

~~~
nekitamo
Have you tried jOOQ?

[https://blog.jooq.org/2017/05/18/10-nice-examples-of-
writing...](https://blog.jooq.org/2017/05/18/10-nice-examples-of-writing-sql-
in-kotlin-with-jooq/)

It might be a bit too lightweight for your tastes, but I'm very satisfied with
it. Never used it with Kotlin tho, but according to the above link it seems to
be supported just fine.

------
eptakilo
This reminds me of NancyFx for .Net and Flask for Python. I enjoy micro-
frameworks like these, They make web development a bit less intimidating.

I hope this projects takes off.

~~~
merb
I'm not sure if I would call a framework that uses jetty under the hood, that
micro...

~~~
peeters
Personally I don't use macro/micro to describe the bytecode footprint, but
rather the API/conceptual footprint. If Jetty is secure and performant, and
Javalin keeps it encapsulated, I think micro is a fair descriptor still.

------
matrix
Looks nice and clean. What use cases make this a better choice than Ktor? This
is an important question to answer because Ktor seems a bit more complete, has
more contributors, and is backed by IntelliJ.

One big point in Javalin's favor: it does have more documentation than Ktor,
which is currently missing some rather important parts (e.g. having no
documentation for authentication and authorization is kinda unforgivable).

~~~
tipsy-
I'm slightly biased of course, but Javalin is just a lot simpler to use. That
might be because it's inherently simpler, or because Ktor's docs (as you
pointed out) are very incomplete. I've tried to setup simple apps in Ktor to
compare how it feels to write apps in it compared to Javalin, but I have given
up on a lot of them because of the lack of documentation.

Other than that, Javalin is aimed at java-devs who have switched (or are
interested in switching) to Kotlin, and works equally well in Java and Kotlin.
Ktor is probably a better fit if you're a Kotlin purist.

------
jorgemf
I just came here to say I am using your project and I like it. Good job and
thanks!

~~~
tipsy-
Thanks, I appreciate it.

------
ajnin
I'm glad more frameworks follow the simple and concise way of Spark.

However, why support both Java and Kotlin, it seems that would create more
work with no real need ? Admittedly, I've been burned in the past with Play!
which said they would support both Java and Scala but using the Java version I
always felt a lot behind in feature support.

~~~
tipsy-
It's not that much more work. You have to be careful with a few concepts (like
SAM/Functional interfaces), but most of the time you can just write in Kotlin.
I want to support both because a lot of companies are probably like the one I
work for, where there are a lot of java-devs, and a few of them are pushing
for kotlin. This seems like a good compromise to me.

Play was two different projects tho? There is only one Javalin source.

~~~
eeperson
There is only one for play as well

~~~
tipsy-
Okay, poorly worded. I think (please correct me if I'm wrong) that in play you
have distinct parts of the code-base that are for Java developers, while other
parts are for Scala developers.

In Javalin, although some parts are written in Kotlin and some parts are
written in Java, there is 0 duplication. If one part is written in Kotlin,
both Java and Kotlin developers use that part. If a part is written in Java,
both Java and Kotlin developers use that part.

~~~
eeperson
That is correct. There are 2 separate APIs (that come from a single project).
This is because Scala can support a bunch of functionality that Java (and
Kotlin) can't support (type classes, higher kinded types, etc.). So your
options are to hamstring the API for Scala or have 2 separate APIs.

------
rajangdavis
Not a Java developer by any means, but I wanted to say this looks like a very
clean and well thought out design.

------
pvg
It says it's 'inspired by Sparkjava', what does it do differently and/or
better?

------
viach
Looks like Java version is not that different in terms of readability and
lines of code...

~~~
tipsy-
That's the point. It's not a framework for kotlin purists, but for java-
shops/java-devs who want to try out kotlin. It should work more or less the
same in both languages.

------
strictfp
Awesome! Why are routes added after the server has started? That makes me a
bit worried, I would like to initialize the app completely before accepting
requests, that's more or less necessary when under high load...

~~~
tipsy-
You can add them before starting the server if you want. I usually put them
after just because I like separating them out. Should only take a few
milliseconds to add them.

------
asplake
How would I find it coming from Flask and SQLAlchemy? Seems only a matter of
time before such a transition comes quite easily, have been watching Kotlin
and Swift with interest

------
sorokod
How does Javalin comapres to ktor ?

------
meddlepal
I've been thinking about porting from sparkjava (another jvm jetty based
microframework) to this. Cool. My problem with Sparkjava is the slow
development time.

------
oaiey
I wonder what the benefits of this API surface is? Yes, it is beautiful but
what are the benefits? Declaring some routes and map them to lambdas or
functions is not exactly something new and also not that mission critical. Why
not working on something established?

I am a C# dev and neck deep in .NET Core with all its flexibility. Maybe that
is the reason I miss the point.

~~~
wiineeth
Hey man, im currently learning web dev and want to learn asp.net core for web
development, im attracted to it after seeing that Stackoverflow uses it and
also bcoz i can do a little bit of C#. Your thoughts?

------
5ersi
Does Javalin have support for REST endpoint versioning?

I.e. does it support any of versioning types mentioned here:
[https://www.troyhunt.com/your-api-versioning-is-wrong-
which-...](https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/)

------
ww520
This looks clean and concise. A very good start. I like it, easy to pick up.
Kudos for releasing 1.0.

------
Zolomon
That github pop-up was quite infuriating. Made me lose concentration and close
the page when I realized it was just to get stars on github.

~~~
tipsy-
Sorry about that. Getting people to participate on GitHub is pretty hard. I
feel dirty for doing it, but it helps.

~~~
michel-slm
I find it kind of cute myself (and went ahead and starred it) but I could see
how others might find it distracting.

------
agumonkey
Still not used to see lambdas in java. Nice I guess

------
nmalaguti
How would this compare with something like vert.x?
[http://vertx.io](http://vertx.io)

~~~
tipsy-
Javalin is better suited for smaller/simpler projects (the library is a lot
easier to understand and easier to setup). Vertx is a lot more powerful. If I
ever found myself in a position where I'd need to create a massive and
performant service (10m+ daily users), I'd probably choose vertx.

------
kochthesecond
How about metrics/healthchecks?

~~~
mustardo
A more featured glue "framework" [http://www.dropwizard.io/1.2.0/docs/getting-
started.html#met...](http://www.dropwizard.io/1.2.0/docs/getting-
started.html#metrics-for-metrics)

~~~
kochthesecond
I've used dropwizard for years, that is why I was asking ;-)

------
behnood85
Java + Kotlin = Javalin :D

~~~
ryenus
Except Oracle lawyers wouldn't like Java being literally used as part of the
name, though I hate to say this.

That's why javaslang was renamed to Vavr: [https://github.com/vavr-
io/vavr](https://github.com/vavr-io/vavr)

------
xaduha
Not interested in new web frameworks until they appear here

[https://www.techempower.com/benchmarks/#section=data-r14](https://www.techempower.com/benchmarks/#section=data-r14)

------
el_tone
.

