Spark – A web micro framework for Java and Kotlin | Hacker News Reader

Spark – A web micro framework for Java and Kotlin

sparkjava.com

64 pointsznpy37 comments

I'd recommend Javalin (https://javalin.io/) instead. Same idea, only executed better and it is actively maintained.

Unfortunately it's not being properly maintained anymore. Last maven release was in Jul 10, 2022. It's maven dependencies have security issues and need to be updated to latest version. So if you want to use it you will need to do that.

SparkJava has an actively developed fork/successor called Javalin[1]. It's straightforward to convert from SparkJava to Javalin. The latter is written in Kotlin but fully supports ordinary Java.

While the rest of the Java world was devolving into annotation hell, AOP and other nightmares, these microframeworks showcased what happens when you leverage modern Java language features. A small but enthusiastic following has developed and they pop up now and then.

[1] https://javalin.io/

As a tiny data point, I've used javalin having moved from scala to kotlin and it's absolutely fantastic.

I've used Javalin as well and now I understand why it all looked pretty familiar, but I kept thinking "Javalin did x better". I can recommend Javalin as well! Having used the Spring Framework, this is a delight in comparison. Especially the setup is infinitely easier. (I know Spring Boot exists, but that's just a preselected pile of software that I have to understand)

The spring boot dread: which of the defaults are a terrible idea to replace, and which of the defaults are a terrible idea to keep?

I do wonder, when looking at the examples, if it might be nice to have a spark/javalin-like that depends on okhttp and reuses everything that appears on both sides of the connection. okhttpd if you like, even if perhaps still best built on top of jetty, like spark/javalin. Might have some skill reuse benefits, but might also cause some unintended shortcut accidents when the type system can't tell upstream from downstream objects.

A big advantage that Javalin and some of the other micro-frameworks have over Spring Boot have is that by picking Spring boot, you are also implicitly picking Spring's custom Java classloader and packaging, and Maven or Gradle as a build tool.

The tooling for building Spring Boot apps from other build systems like Bazel has problems, and while you can forego it and build your Spring Boot apps with Bazel's java_binary targets, you really don't want to.

Javalin by contrast is a plain boring Java dependency and you can pull it into any Java app with ease.

I do miss the better support for OpenAPI in Spring Boot though - Javalin's support is still missing a lot of functionality, but it is being very actively developed.

I could be wrong, but I think Vertx would be a better choice? https://vertx.io/

It's actively maintained with full time developers, performant, supports Kotlin out of the box, and has more features?

I’d say Javalin is more of a successor. Vert.x is too focused on reactive programming to qualify as a successor IMO.

I've used vert.x in a big project once. I don't ever want to do that again. Performance is pretty good, but the developer experience is beyond clunky.

My current favourite Java server framework is Micronaut.

Great performance and easy to develop for!

https://micronaut.io/

Another vote for Micronaut. I’ve moved a Vert.x project to it recently. I love it. I will say though there are a lot of footguns and the wide variety of choices e.g. for persistence, views, etc make it hard to figure out the “right” way to do things. But the framework just really clicks for me.

I kinda liked the freedom to choose persistence myself, it was one of the things that enabled us to choose it at Mojang, since at the time it wasn't clear if we were going to migrate to a different cloud or not, being able to replace the persistence layer was essential.

As for footguns, I agree there are plenty, but in my experience at least, fewer than in most Frameworks I've used.

Didn't use views much, we built a JSON API, so there wasn't much need for it.

One thing I really liked about it was that it was so easy to get in touch with the Devs, and they so quick to fix things!

We started implementing our API with it before they released 1.0, and as such there were plenty of bugs in the beginning. Quite frequently we submitted a bug report, and there'd be a new version released the same or the next day with a fix for it! Very impressive!

I might've had bad luck with the team where I used vert.x but I've seen a few things in there I would categorize as foot-howitzers, I guess it's just hard to create a framework that can be used for anything without also enabling users to blow their feet off.

Sorry about the rambling comment, just happy to share my thoughts with a fellow Micronaut fan <3

Reactive garbage.

The community of vert.x is quite active. There’s a Discord server where discussions, releases info and help questions are being published in live chat.

Vert.x has already adopted VTs and in general its documentation is still one of the best I‘ve seen.

Really impressive work on the toolkit all these years. I love working with it.

If you are on Kotlin, ktor is a nice framework. And it works outside the JVM too. Ktor client works in the browser, on native, wasm, and on the jvm. Ktor server is mainly for the jvm but also works on native.

There are actually two ways to use ktor-server with native.

1) you can use Graal and compile your jvm project with that.

2) you can use kotlin-native and produce native code directly.

And I would not be surprised to see some wasm support come together either when the kotlin wasm compiler has had a chance to mature a bit.

But short term, targeting the jvm is the easiest. Either way, ktor is a nice framework.

I've been working on a framework built on top of Ktor for a while now with the intention of providing SSR capabilities with the HTML and CSS DSL and auto generated bindings to generate JavaScript from Kotlin multiplatform code in order to provide interactivity.

The only stumbling block I've encountered is the hot reloading support, for whatever reason only half the application is reloaded (some classes are and others aren't). This has been enough of an enigma for me to plan a switch to vertx.io.

Massive shame because I think the general Ktor framework is brilliant and I especially appreciate their adoption of the Kotlin Multiplatform.

I have limited experience with ktor, but I know that Graal can do hot reload well (better than hotswapagent). Maybe worth an experiment.

I've inherited an old legacy spark project. I find the developer experience and tooling of Spring Boot to be much better and it's well suited to building microservices.

Spark is nice, I switched to usinh jersey+jetty though, you get the mature API of jax-rs and everything in under 6MiB of dependencies. you can even use the jdk http server to be even smaller.

I'm very happy with that setup.

My ActivityPub project, Smithereen, is built on this. Though I had to fork it to add the ability to stream responses. By default it really insists on rendering everything fully into a string and only then serving it to the client. I also updated its dependencies and added support for Java 21 virtual threads.

https://github.com/grishka/Smithereen

My fork of Spark: https://github.com/grishka/spark

So many memories of this library. They were early movers of Sinatra style web framework in java before spring boot.

Have deployed 10s of services into production build on java spark. Still works like charm.

Last update was 2 years ago. I think this should be avoided for production use. Unless is so stable it need not be used.

Been using this for years, it’s tight. Sample app:

https://github.com/manifold-systems/manifold-sample-graphql-...

looks nice, but it has a name collision with apache spark

SparkJava has been around since just about the time that Spark became Apache Spark. 10 years ago-ish.

Which doesn't really matter. At some point you have to admit defeat, and find a new name to distinguish yourself - if not for any other reason then just for SEO optimization: you want to be the first Google result when someone searches your name.

What‘s rubbing me the wrong way is the author pitting against NodeJS/Typescript on the front page without real arguments. You can pit your framework against another, but show me how it makes my life easier in comparison. Argue with features and developer experience, not with personal opinions.

„and unlike a lot of JavaScript web frameworks, Spark won’t be deprecated tomorrow.“

Especially if you can’t hold your promise. Deprecations are a normal thing in every software driven by individuals. We lose interest, get kids, etc.

I came here to say this too.

The funniest part is comparing it to expressJS, which hasn’t changed much in 10 years, and saying unlike JS frameworks, it won’t be deprecated tomorrow.

I remember stumbling upon it like 10 years ago. IIRC Per took a year off work (parental leave?) and built it as a fun project. A very thin layer on top of the java standard. I used it for a few side projects and also hosted the official javadocs back in the day on one of my servers. If you need something tiny and simple on the JVM spark is still a valid choice although there are tons of alternatives nowadays.

How is sprint boot + java thèse days? I have a client that wants to pick it up for a suite of services (and Java) but my experience with it 5+ years ago was that it was an overengineered painful thing to use. I would much prefer they use a Kotlin + ktor/vertx + jooq combo but I have a hard time convincing them.

This appears to be a server-side web framework only.

If your interest is one language (Java or Kotlin) full-stack for a single-page app, you will be interested in my Flavour book: https://frequal.com/Flavour/book.html

At my company we dropped Spark in favor of Ktor since it's not properly maintained.

I've been using this for years, simple and gets the job done. Perfect when you just want to add an http endpoint to an existing java application quickly without including tons of libraries.

It might be prudent to avoid name collision with an ubiquitous open source technology also in the jvm ecosystem.

This framework is older than that "ubiquitous" technology.

and we already have a bunch of these.

it's been around for a long time.

Reply on news.ycombinator.com