GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-11-07) - page 1 of 10
 
___________________________________________________________________
Show HN: Javalin 1.0 - A Kotlin/Java web framework
185 points by tipsy-
https://javalin.io/news/javalin-1.0.0-stable.html
___________________________________________________________________
 
Zolomon - 6 hours ago
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- - 6 hours ago
  Sorry about that. Getting people to participate on GitHub is
  pretty hard. I feel dirty for doing it, but it helps.
 
meddlepal - 6 hours ago
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.
 
jorgemf - 4 hours ago
I just came here to say I am using your project and I like it. Good
job and thanks!
 
  tipsy- - 3 hours ago
  Thanks, I appreciate it.
 
pvg - 6 hours ago
It says it's 'inspired by Sparkjava', what does it do differently
and/or better?
 
behnood85 - 6 hours ago
Java + Kotlin = Javalin :D
 
  ryenus - 5 hours ago
  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
 
viach - 6 hours ago
Looks like Java version is not that different in terms of
readability and lines of code...
 
  tipsy- - 6 hours ago
  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.
 
danneu - 6 hours ago
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` 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 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
[2]: http://ktor.io
 
  tsvetkov - 1 hours ago
  > Java -> Kotlin is effectively one-way interopCould 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).
 
  stewbrew - 4 hours ago
  "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."Could you please
  explain this.
 
    dradtke - 4 hours ago
    I think it means that a library written in Kotlin is difficult
    or impossible to use from Java.
 
      EddieRingle - 3 hours ago
      Not really true from my experience. For example, here's a
      Markdown library written in Kotlin that you can use with a
      plain Java interface: https://github.com/valich/intellij-
      markdown
 
  hota_mazi - 4 hours ago
  > though I wish you could re-open 3rd party classes to make them
  conform to additional interfaces which you can do with Swift
  protocols.Mmmh really? I just reread the Protocol section of the
  Swift documentation and I didn't find this.If I have a class I
  can't modify and that doesn't conform to protocol `Foo`, can I
  make it conform to that protocol?A similar feature is being
  considered for Kotlin since this opens up all kinds of
  interesting mechanisms (notably, ad hoc polymorphism) but I don't
  see how to do that in Swift right now.
 
    faical - 4 hours ago
    > If I have a class I can't modify and that doesn't conform to
    protocol `Foo`, can I make it conform to that protocol?Yes, you
    can.
 
      fauigerzigerk - 2 hours ago
      Not sure if that's a good thing though. I read some of the
      Swift standard library source code and found it very
      difficult to piece together all the stuff added by
      extensions, where they come from and where the original class
      definition is.Obviously, it's going to be easier if you have
      written the code yourself, but what if someone else needs to
      read it?
 
  tipsy- - 5 hours ago
  Thanks! Yeah, I had to leave a few parts as Java in order to get
  the interop right. Anything that takes an functional interface
  needs to be Java, so the main API entry points are all Java. Most
  other classes and all internal code is Kotlin. I originally wrote
  it all in Java, and ended up with about 30% less code after I
  rewrote it to Kotlin.
 
sorokod - 6 hours ago
How does Javalin comapres to ktor ?
 
matrix - 4 hours ago
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- - 4 hours ago
  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.
 
nmalaguti - 17 minutes ago
How would this compare with something like vert.x? http://vertx.io
 
eptakilo - 6 hours ago
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 - 6 hours ago
  I'm not sure if I would call a framework that uses jetty under
  the hood, that micro...
 
    meddlepal - 6 hours ago
    Why not? Jetty is pretty lightweight as far as JVM http servers
    go...
 
    peeters - 6 hours ago
    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.
 
    oaiey - 3 hours ago
    Well if nancyfx is micro so is Javalin. NancyFX is nowadays
    built on Kestrel from ASP.NET Core.
 
  jordanab - 5 hours ago
  NancyFx was also the first thing I thought off when looking at
  the examples. Before the .NET Core days I always used NancyFx as
  a drop-in REST service when I needed one in a non-web app
  setting, like a Windows service.
 
    m_fayer - 4 hours ago
    Out of curiosity, what about .net core changed this picture for
    you?
 
      dodyg - 4 hours ago
      Now you can use .UseRouter extension to achieve something
      similar in ASP.NET Core 2 (https://github.com/dodyg
      /practical-aspnetcore/blob/master/pr...)
 
        m_fayer - 1 hours ago
        Thanks, it does look nicely similar, but I still far prefer
        NancyFX's modules - this is an awkward context to do all
        this wiring.
 
ajnin - 5 hours ago
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- - 5 hours ago
  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 - 4 hours ago
    There is only one for play as well
 
      tipsy- - 4 hours ago
      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 - 2 hours ago
        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.
 
  nevi-me - 5 hours ago
  From looking at the codebase, looks like there isn't any explicit
  "support Kotlin and Java", because most of the code's written in
  Kotlin.Also, Kotlin and Java are meant to be well interoperable,
  so the Java support sort of comes by default. So it won't be the
  same as Scala + Java. I've been burnt by Apache Spark which has
  an awful Java API compared to Scala (and Python).If someone has a
  better answer, I'd love the education :)
 
ww520 - 6 hours ago
This looks clean and concise.  A very good start. I like it, easy
to pick up. Kudos for releasing 1.0.
 
kentosi - 3 hours ago
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- - 3 hours ago
  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.
 
norswap - 5 hours ago
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 - 1 hours ago
  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.
 
  tipsy- - 5 hours ago
  > for sure, Jetty provides a lot of convenience classes on top of
  that plumbingThat's really the benefit. I have been using jetty
  for years. I trust them a lot more than I trust myself to create
  a web-server. If I were to write everything from scratch, I would
  never have finished the project.
 
  bborud - 5 hours ago
  It depends what you want to focus on:  build a web server or a
  simple REST framework.About a decade ago I worked on the query
  processor component for the Yahoo Vespa platform and I spent a
  month writing a web server to squeeze as much performance out of
  the JVM as possible.  And indeed it was quite a bit faster than
  Jetty.  Speed being a bit significant when you have a stringent
  latency budget.However, I ended up deciding it wasn't really
  worth it.  The extra millisecond or so consumed by Jetty wasn't
  worth the cost of having to maintain a relatively complete
  implementation of HTTP.  So I took out my implementation and put
  Jetty back in.
 
  Scarbutt - 5 hours ago
  There's also undertow, lighter and smaller memory/size footprint.
 
    emmelaich - 1 hours ago
    Yeah looks very good.http://undertow.io/
 
patates - 5 hours ago
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).
 
  gnud - 5 hours ago
  JDBI3 [1] has Kotlin plug-ins [2], and makes it easy to create
  simple DAOs without having to inform the framework about the
  entire database structure.1: https://jdbi.github.io/ 2:
  https://jdbi.github.io/#_sqlobject
 
  mulrian - 5 hours ago
  The library created by
  JetBrains:https://github.com/JetBrains/Exposed
 
  nekitamo - 5 hours ago
  Have you tried jOOQ?https://blog.jooq.org/2017/05/18/10-nice-
  examples-of-writing...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.
 
asplake - 6 hours ago
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
 
agumonkey - 6 hours ago
Still not used to see lambdas in java. Nice I guess
 
rajangdavis - 4 hours ago
Not a Java developer by any means, but I wanted to say this looks
like a very clean and well thought out design.
 
oaiey - 3 hours ago
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.
 
  [deleted]
 
strictfp - 3 hours ago
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- - 3 hours ago
  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.