Show HN: I finished v5 of a JVM framework I've spent spent half a decade making

[iammiles]

I just wanted to say thank you for your work. The straightforward docs are some the best in my opinion when you want to go from "How do I do ..." to answer.

I ended up using Javalin with Kotlin and SQLite to build my wedding website.

Most of my projects are lucky to see the light of day, but with a very persistent project manager and a simple lightweight framework, I was able to ship a fantastic product with very little fuss.

[tipsee]

Hey, thank you for using it. Single-page docs are also my favorite, and Javalin/jdbi/SQLite is my goto for quick stuff!

> but with a very persistent project manager

Your partner? :D

[asadawadia]

For anyone who wants to get started with this stack you can do `git clone https://gitlab.com/asad-awadia/kotlin-server-app.git` to get a full maven project with javalin, sqlite with ktorm and jdbi everything setup

[peanut_worm]

just wondering, what did you use SQLite for on a wedding website?

[freedomben]

This looks great! I did Java professionally for years but when all the jobs moved to EE I bailed for Ruby/Rails and similar. Java the language I've always really enjoyed. It's the frameworks and hundreds of design patterns that repelled me. I felt like they were all needlessly complex. If frameworks like this one were more common in Java world, I may never have left.

This looks really nice! I wish more Java devs approached things with KISS and simple in mind, rather than looking at every problem as a way to apply some obscure design pattern that involves 15 levels of abstraction and indirection for a relatively simple microservice.

[adamredwoods]

I just started using this! Spring Boot seemed so convoluted, having to go to a website to even begin. And then to have the Tomcat dependency seemed like a heavy lift just to get a "hello world" working. Virtual threads seems to be the way to go.

Virtual threads in Java 19: https://www.infoq.com/articles/java-virtual-threads/

[dopidopHN]

Excellent resource on virtual thread by one of the authors! Thanks.

I have to see I’m pleased to see Java moving fast those days.

I’m still digesting 17 and 18, but that give me a reason to look at 19.

I honestly project loom was far from reaching that level of “standardness” … so I haven’t looked into it in years

[dang]

Related:

Show HN: Javalin 1.0 – A Kotlin/Java web framework - https://news.ycombinator.com/item?id=15644430 - Nov 2017 (87 comments)

Show HN: Javalin, a Java/Kotlin REST API Framework - https://news.ycombinator.com/item?id=14434089 - May 2017 (21 comments)

[tipsee]

The good old days!

[moralestapia]

Congratulations! This is great!

Java deserves its comeback among the wave of nu-programming we are going through.

[tasuki]

> Java deserves its comeback among the wave of nu-programming we are going through.

What is nu-programming? And why would Java deserve a comeback?

[stefs]

you can also use it with kotlin

[davidoniumz]

I successfully used Javalin in a project using Kotlin + Koin for dependency injection + jOOQ for database access. Was a joy to setup and work in that project.

Thank you!

Congratulations on the major release and keep up the good work.

[tdudzik]

JDBI also could be really nice as a minimalistic layer for a db access

[cies]

Congrats on the release! I reviewed Javalin lately and it was high on my list. We use quite a bit of Kotlin and look for a framework. I really dislike the magic that annotations bring to most popular Java frameworks (and Hibernate). I prefer most is just code". Kotlin helped us a lot in making our code more type safe, especially the KProperty way of referring to methods made a difference.

Though I ended up leaning towards KTor, with Javalin as a close second.

How would anyone with more knowledge compare the two (Javalin and KTor)?

[binkHN]

> ...would anyone with more knowledge compare the two (Javalin and KTor)?

I'd love to hear more on this as well. While I've done some minor stuff with Ktor, because JetBrains, I too would love some insight related to these as well.

[didip]

Javalin is the bomb! I don’t know why Java community likes to make things complicated.

[takoid]

“An idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple, for an idiot anything the more complicated it is the more he will admire it, if you make something so clusterfucked he can't understand it he's gonna think you're a god cause you made it so complicated nobody can understand it. That's how they write journals in Academics, they try to make it so complicated people think you're a genius.” - Terry A. Davis

[manishsharan]

I like Jetty. Javalin is nice for Kotlin but Jetty + java has worked well for me.

[pron]

Very nice!

Just a minor nitpick (for those who care about the details of OpenJDK's development): virtual threads are not Project Loom, but rather one of the JEPs contributed to the JDK by Project Loom. There are two in JDK 19 (425 and 428), another in advanced stages (429), and there will probably be more. OpenJDK Projects aren't features but teams working on producing features focused on some area and then offering them to the JDK.

[tipsee]

> Just a minor nitpick (for those who care about the details of OpenJDK's development): virtual threads are not Project Loom, but rather one of the JEPs contributed to the JDK by Project Loom.

Thanks for clearing that up. Would adding a "from" be sufficient?

and it uses Virtual Threads (“Project Loom”) by default

and it uses Virtual Threads (from “Project Loom”) by default

[zmmmmm]

Well done! Can't wait to see Loom become the default for web frameworks.

Also spotted the Vue plugin - great to see this as so many light weight web apps with a few pages can benefit from using Vue but setting up all the build chain is such a drama that it's usually not worth it. Look forward to trying it out.

[tipsee]

Thank you! The Vue support is the thing in Javalin I'm the most proud of. There are a hundred web frameworks for the JVM, but none of them have anything close to the Vue support Javalin has. Some people think it's trash, but for me it's perfect.

[stevoski]

This is Javalin and it is great. We switched to it a few months ago from another micro-framework.

[tipsee]

Indeed it is! May I asked what you switched from?

[potency]

Curious as to what has kept you motivated to continue working on the project this long? So many open source developers don't last nearly as long or jump to something new once the novelty of the project wears off.

[tipsee]

I've been dogfooding it hard, which is a great incentive to keep working on it. I think we have 20 Javalin projects where I work. It's also gotten pretty popular lately (3m downloads last 12months), which of course helps a lot :)

[Matthias247]

Looks interesting!

One question about the response methods: If I would be using something like `ctx.result(inputStream)` - would it block the [lightweight] thread until all data is written. Or would the handler return and the data transfer happen in the background?

One use-case I've only see marginally addressed in some frameworks is being able to run code past the point where all data is written - e.g. to record logs and metrics around the outcome of a request - e.g. whether the client hung up or all data was stored in socket buffers. If sending the result "blocks", that kind of code can be added naturally with a try/finally block around it.

As far as I understand the docs, it might not block, but one might be able to install an "After" handler? Or would that also only run before the response is actually sent?

[tipsee]

If I would be using something like `ctx.result(inputStream)` - would it block the [lightweight] thread until all data is written. Or would the handler return and the data transfer happen in the background?

There is no difference between OS threads and virtual threads in this scenario, and everything in Javalin is blocking (by default).

The `ctx.result()` method doesn't actually write anything directly, it sets a result that will be written later. If you add an "After" handler, this also happens before the request is written. When the request is finally written, it's written on the same thread, and it is a blocking operation.

There is a `RequestLogger` you can hook into that fires after the response has been written.

[michaelcampbell]

Before I saw the site, I just saw the headline and thought, "Another one I might look at, after I do something serious in Javalin".

[the-alchemist]

Some quick questions: - are you using an already-existing HTTP engine, like Jetty or Tomcat?

- how do virtual threads fit into a web framework?

- do virtual threads make debugging more difficult? (A more general JVM question, I suppose)

- any performance / readability benefit, or just a coolness factor?

[tipsee]

are you using an already-existing HTTP engine, like Jetty or Tomcat?

Yes, Javalin is built on top of Jetty.

- how do virtual threads fit into a web framework?

Most JVM web frameworks (Jetty included) have a thread based request lifecyle (one thread handles one request from beginning to end). The java.lang.Threads are extremely expensive (~1mb memory), while Virtual Threads are very cheap (~0mb memory). We also have another ThreadPool for JSON streaming, and one for writing async responses. Using Virtual Threads for these things reduces overall memory pressure.

- do virtual threads make debugging more difficult? (A more general JVM question, I suppose)

Not that I know, but I've never used this in production myself.

- any performance / readability benefit, or just a coolness factor?

The alternative here is java.lang.Threads, so primarily the memory footprint. There is no readability difference. When developing, you don't see this at all.

[rkalla]

Nothing to do with the project, but I read through it, so...

1. It's built natively on Jetty - very tight integration, not just some libs running in a Jetty container.

2. Web is inherently Request/Response - all of this can be handled with dramatically less resource requirements using Virtual Threads. Web is sort of the absolutely-best-use-case for Virtual Threads where as a Game Engine would be the opposite of that (one critical rendering thread and MAYBE a few extra long-lived threads for processing physics, audio, etc.)

3. I haven't tried debugging a Loom project but it's been in incubation for just under 100 years so I have to imagine this has been figured out.

4. About twice the throughput and 1/2 the latency of full OS threads - https://github.com/ebarlas/project-loom-comparison

[ekvintroj]

I usted Javalin a few months ago for a kotlin api. It's awesome!

[jpgvm]

I have used Javalin for a number of Kotlin backend projects of late, thanks for all your hard work!

[simonw]

I find that hello world example very pleasant to look at. Love that it's effectively a one-liner.

    public static void main(String[] args) {
        var app = Javalin.create(/*config*/)
            .get("/", ctx -> ctx.result("Hello World"))
            .start(7070);
    }

[jannes]

Looks very similar to Express.js which came out in 2011 and has been one of the most popular frameworks in the Node.js world.

https://expressjs.com/en/starter/hello-world.html

[floodfx]

I haven’t written Java or Kotlin in years but this makes me want to try it again. Nice work!

[sgt]

Great work. It's fascinating to see how "modern" Java looks these days.

[abraxas]

Java always was fine for those of us who refused to get suckered into the j2ee/ejb vortex of nonsense.