Could you be more explicit, perhaps with an example? Do you simply mean you prefer function/constructor parameters over DI?
Calling a constructor is DI. ‘new’ is the only DI framework required. Benefits: Unbelievably fast startup time No magic No annotations, XML or YAML required No classpath scanning related security vulnerabilities Conpletely deterministic In no other language is ‘calling a constructor’ considered so complicated a framework is required. Try it!
When I switched from Java to Go and started doing DI like this, I was amazed at how simple and efficient DI could be. I was taught DI with Spring and never fully grasped why and how it worked. With Go it just clicked and to this day I still have no idea why DI libs are so complicated. If I ever come back to Java, I’ll make sure to do DI manually.
I'll guess and say Spark. Not the big data Spark. This one: sparkjava.com A nice piece of work in its own right.
You guessed correctly! Spark was fine, but was abandoned. Which means it was stuck using an end-of-life’d version of Jetty. Which meant that we could no longer pass security audits. Whereas Javalin continues to get frequently updated.
Spark ruined me. Everyone expects Spring, but dealing with Spring and all the pointless annotation magic is a misery; I find myself longing to just use Spark and forgo all that crap.
I suppose I'll try Javalin then next time I have the choice.
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.
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.
Not trash at all, thanks for making it.
In general thanks for keeping Javalin simple and opinionated, it is my goto when I get to decide!
this is very cool. quick question though - do u have a gradle build setup ? im new to java and saw this problem on spring boot. That you needed to have this bunch of complex directory structures cos of the way java packages worked. for e.g. the test directories were parallel to the src directory, so they could be named with the same package name. for a single file...i can just run java. but it would be nice to see a…
That's not a spring thing, but a java tools convention (having a src and test folder etc). Nothing stops you from doing it differently, but most tools work out of the box if you follow that setup. So better to just do it than having to fight with / configure every part of your pipeline.
im not disputing that. im wondering if javalin came with one out-of-the-box is all.
Calling a constructor is DI. ‘new’ is the only DI framework required. Benefits: Unbelievably fast startup time No magic No annotations, XML or YAML required No classpath scanning related security vulnerabilities Conpletely deterministic In no other language is ‘calling a constructor’ considered so complicated a framework is required. Try it!
I have a few questions about this approach, cards on the table I mainly deal in C# where DI (through the framework) is the default. How do you manage the initialization of all of the dependencies? Do you need some sort of "root" where everything is initialized and passed in? That was all I could come up with while keeping it testable and that doesn't sound maintainable once you build up the number of dependencies.
What dependencies are multiplying? I organize my code so that the very top level of the api has all external dependencies injected there, there is no public classes below a single exposed class that would need to be directly injected into. The only thing I need to actually inject are things that are outside of my memory space, ie network calls, event buses, dbs. If it's not using something outside of my memory space I am just using new inside my classes, it's far easier to test.
For example, if I'm adding a new feature to allow a user to change their address, I would have a single class at the top level "CustomerAddressChange" or whatever. I would inject an interface that wraps everything external, and that is the only thing that anything would be injected into. My tests would all stub only that interface. Everything else is done without any sort of DI container.
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 log…
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.
I'll guess and say Spark. Not the big data Spark. This one: sparkjava.com A nice piece of work in its own right.
You guessed correctly! Spark was fine, but was abandoned. Which means it was stuck using an end-of-life’d version of Jetty. Which meant that we could no longer pass security audits. Whereas Javalin continues to get frequently updated.
> Spark was fine, but was abandoned.
Aw, that's sad to hear. I've been out of JVM-in-anger space for awhile, but I always liked Spark when I was.