Javalin: Javalin 3.0 wishlist/discussion

[tipsy]

This issue is for suggesting breaking changes.

I have one main thing on the list for Javalin 3, which is making it easier to create a JavalinServlet for use outside of Jetty. This means creating a separation between the server and the servlet (currently everything is lumped together in the Javalin class). It would be nice if this could support static files and file uploads.

This might make the initial setup slightly harder for the people who use Javalin with jetty (99%?), so we have to be very careful.

JavalinServlet could be released as a separate dependency, javalin-servlet, which javalin depends on.

Should also consider:

• Rewrite to Java (sadly, Kotlin interop isn't as good as we thought)
• Interfaces for testing
• Reconsider plugin architecture. Currently they're singletons (JavalinJson, JavalinRenderer). Maybe they should be put on the app.
• Remove case-insensitive path matching ?
• Do something about config? (ref #508)
• Do something about WsSession (also vs Context?)
• ~Rework casting and validation~ (DONE)
• Javalin logger to easily disable built in logging (in case people are building a framework on top?)

[tweenietomatoes]

Please don't get angry to me, but maybe changing embedded server with Netty. 🤐
Ok you already mentioned it.

So, making everything full async?
Adding, databaseish thingies.

[tipsy]

Javalin will stay with Jetty. If JavalinServlet is pulled out as a separate thing though, it should be pretty easy to run Javalin on Netty.

[fwgreen]

Will Javalin 3.0 be based on Jetty 10, or staying on Jetty 9? My vote is for moving to 10, though it brings with it a Java 11 requirement.

[tipsy]

If jetty 10 is ready we'll probably move. What's the road map?

[fwgreen]

I haven't seen a roadmap of sorts anywhere. I vaguely remember an old post (from last year) about them delaying the release of Jetty 10 until they were certain about Oracle's new licensing scheme. The real question is how many Javalin users will be remaining on JDK 8 when Oracle pulls the plug on free support?

[ghost]

1) Moving to Netty is 180 degrees shift in what Javalin always was, at least for me, so -1 here. (Asynchronous processing)
2) I'd vote against moving to Jetty 10 simply because of Java 11 requirement. There are still places where Javalin could be used, but its not possible to migrate from Java 8 since it brings effort and AdoptOpenJdk Azul IBM Amazon and others are still providing support for Java 8 and they will continue to do so for couple more years.
3) rewriting to Java can be an advertisement move, Kotlin users won't even notice if we have a good wind, Java users who have their project's requirements written in stone and vendor locked on Java might pick it up

[SmithKevin]

I don't think Jetty 10 will be ready in the near future (https://github.com/eclipse/jetty.project/milestones), but I would be for migrating to it when ready along with moving to Java 11. Java release schedules have been forever changed (new version every 6 months) so holding on to the old Java 8 ways of sticking to a version for as long as possible seems backwards. If you want a little background on the new Java thinking I'd recommend this talk https://www.youtube.com/watch?v=MFfTqUQxFTs. They no longer want the mentality of "holding off till a large release is stable" but instead consistently moving little by little so jumping versions is no longer a big deal. I think the quicker Javalin jumps on this train, the better because the hardest part is the leap off Java 8. Javalin 2.x should continue to get bug and security fixes for those who need to stay on 8 for whatever reason.

In terms of features, I don't really have much. I've been using it for a lot of different containerized microservices and it fits the bill nicely. I'd be against it getting too opinionated and bloated. If you need to work with databases, pull in your favorite DB lib (ie JDBI). If you do decide to try to bundle in support for larger features I think it should just be another module on top of the Javalin core to keep things as lightweight as possible. Interfaces to make testing a little easier would be great.

[rizalp]

Could you add support to bind to unix socket? It seems possible to do it: https://github.com/travisspencer/jetty-domain-sockets-example/blob/master/unix-socket-server/src/main/java/com/travisspencer/test/UnixSocketServer.java

This will be a good Idea in case javalin is being proxied from upstream server like Nginx, and both are on the same host

[tipsy]

@rizalp what kind of support are you thinking about? Javalin will run on any Jetty server, so it should work with the example you linked to.

[rizalp]

@tipsy apologize, didn't know that it could be configurable https://javalin.io/documentation#custom-server

[tipsy]

No worries!

[firxworx]

I think the default behaviour should be for javalin to issue a 404 if there's no path to a given endpoint, and 405 if the endpoint exists but the client is attempting to use an unsupported method.

Currently javalin gives a 404 for all cases, even when the path exists but the method is wrong. If one uses prefer405over404() then 404 is simply swapped with 405 in all cases. I am not aware of a way to easily/quickly default to the desired behaviour.

Javalin's ability to issue 405's w/ correct Allow header in the response is helpful

[firxworx]

In areas where kotlin interop isn't as good (speaking generally as I am not aware of specifics) have these been reported to jetbrains / kotlin community? They seem decently responsive at supporting kotlin and addressing issues; one wonders if trouble spots could possibly be resolved in upcoming releases?

[tipsy]

@firxworx, the behavior you want for 405 sounds like how it's supposed to work. There's even code there for looking through the avaibale handlers for different verbs. Maybe it's a bug?

Jetbrains are aware, they just disagree about the use of SAM Interfaces. They say use functions instead, but that leads to pretty bad developer experience for Java devs. The issue has been open on their tracker for two or three years now.

[tweenietomatoes]

there's a tons of discussion about that opened since 2016.

[wherkamp]

Rewrite to Java (sadly, Kotlin interop isn't as good as we thought)
I know. Kotlin + Java causes issues when wanting Javadocs or documentation overall. So that will be nice.

[pkkummermo]

Remove the need for kebab-case in keys for path-params.

Right now we get IllegalArgumentEx when trying to use

get("/my-path/:entityId/"...

due to the restrictions put on different casing for paths. This doesn't really make sense due to the :entityId being a key, and not a part of the built path.

Either remove the restriction of different casing as default or fix so the keys can be "whatever-cased".

[tipsy]

@tobiasdrechsel Use this issue if you have any suggestions for Javalin 3.

[tobiasdrechsel]

Right now I only have two suggestions in mind.

1. Micrometer support.

I have used Micrometer in the past and I'm very pleased about it.
For those who don't know what Micrometer is:

Micrometer provides a simple facade over the instrumentation clients for the most popular monitoring systems, allowing you to instrument your JVM-based application code without vendor lock-in. Think SLF4J, but for metrics.

We could build it on top of the existing approach.
They provide an implementation for the StatisticsHandler, JettyServerThreadPoolMetrics and InstrumentedQueuedThreadPool.

IMO Micrometer support itself would not require much effort. At the same time it might be a strong argument in favour of Javalin, especially for larger projects.
On top of that we could add more metrics which are unique to Javalin.

More information about the concepts of micrometer.

1. Switch to Gradle

I personally prefer Gradle over Maven. And I think with their Kotlin DSL they made a huge step in the right direction. And if Javalin is indeed rewritten in Java we can at least keep some kotlin code in the project :wink:

I know that everyone has his own favourite build system and I don't want to offend anyone. So if the build system is not open to discussion it is fine for me, I just wanted to propose it.

[tipsy]

@tobiasdrechsel Is there any reason we can't enable Micrometer support in 2.X ?

Gradle vs Maven doesn't affect end users, and I don't particularly care, so it could be introduced now. I don't think we should though, since most people still start learning Maven, then switch to Gradle. Maven lowers the barrier of entry for new contributors, which I consider important.

[tobiasdrechsel]

@tobiasdrechsel Is there any reason we can't enable Micrometer support in 2.X ?

I thought about that too and it shouldn't create breaking changes.
Should I create an issue and work on it?

Gradle vs Maven doesn't affect end users, and I don't particularly care, so it could be introduced now. I don't think we should though, since most people still start learning Maven, then switch to Gradle. Maven lowers the barrier of entry for new contributors, which I consider important.

For me it was exactly vice versa but I see your point and agree.
Maybe you can add the question "What is your primary build system?" or something like that to your summer survey. It might give us more insight on the users (and possible future contributors) preferences.

[tipsy]

I thought about that too and it shouldn't create breaking changes.
Should I create an issue and work on it?

That would be great!

For me it was exactly vice versa but I see your point and agree.
Maybe you can add the question "What is your primary build system?" or something like that to your > summer survey. It might give us more insight on the users (and possible future contributors) preferences.

Thanks, will do that.

[wherkamp]

MimeType enum would be nice https://gist.github.com/wherkamp/96f436833789cf4c1e6dd252017aa110
Interfaces. So I would like everything you interact with to be an Interface. Context and Javalin. It would be nice for testing. ( I feel like I am wording this badly )

[tipsy]

@wherkamp Jetty should handle all the mime types for static files, why do you need an enum?

[wherkamp]

ctx.contentType(MimeType.PNG);
It would be more for simplicity.

[tipsy]

I just tried to bump to Kotlin 1.3.21 because Kotlin Jackson depends on Kotlin 1.3.X. But tests break because there's a bug in Kotlin 1.3.X where method names can't have parens (like 'test myMethod() works'). How did they not discover that...? Another argument for switching to Java.

Edit: I started porting some classes to Java today, and I'd forgotten just how much better Kotlin is.

[fwgreen]

@tipsy Does the -Xsanitize-parentheses workaround not resolve the problem for you?

[tipsy]

Maybe it will, but if I bump then anyone using Javalin also have to know about this bug and how to fix it.