That's probably the first time I see a java web framework api that actually makes me want to try it.
Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
111–120 of 139 posts
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#112Earlier quoted context omitted.
just wondering, what did you use SQLite for on a wedding website?
Similar to other use cases mentioned already, it was a way for us to create a privacy-focused site to manage guests and give guests the opportunity to update their RSVP, dietary needs, and requested song for the DJ. Additionally there were a few sections of the site where my fiancée could update content as she saw fit by logging in and hitting save. We found the database useful to keep track of RSVPs, gifts, and who…
Re: pass phrases, my go-to for projects like that is to put a unique hash or something in the URL for each different person. The experience for users is that there's no password to remember or anything like that. They're not going to remember the URL anyway.
You can put the hash in a #xxxx part of the URL so it doesn't show up in logs if thats important to you. The downside is you need to give everyone their own URL (maybe via a QR code on a paper invite). But you already had to give everyone a pass-phrase so whatever :)
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#113Some 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?
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
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#114Earlier quoted context omitted.
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!
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.
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#115Earlier quoted context omitted.
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.
I'm also a fan of the manual DI approach - I strongly dislike the magic.
I think it helps if you are building test/fakes of your deps that don't really need as many sub-dependencies. Generally you in a test `@BeforeAll` construct a bunch of objects or for a program you do it in `main`.
I did work on a project while I was at Google that was really big and a decade old that instead had a class with a bunch of lazy getters for each item in the dependency graph, then tests would override or reset the getters with testing versions as needed. It was a little clunky but I preferred that approach over the projects I worked on that used dagger.
If you've read through the Dagger dev-guide [0] there is *a lot* in there, while the manual approach it's usually just `new` which is a really simple concept on it's own :) I think this is the right tradeoff because reading code is harder than writing code, so it's worth the extra setup. In practice I haven't seen it to amount to be an overwhelming amount.
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#116Earlier quoted context omitted.
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.
[deleted]
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#117Earlier quoted context omitted.
Indeed it is! May I asked what you switched from?
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.
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#118Great work. It's fascinating to see how "modern" Java looks these days.
Java always was fine for those of us who refused to get suckered into the j2ee/ejb vortex of nonsense.
I was sucked into Java EE. Still got the battle scars to prove it. Trench warfare mostly, wallowing through mud.
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#119Javalin is also super good at serving content via a web API, too. To external clients or within a bigger app. I wonder how Loom will speed up concurrent calls to my APIs served by Javalin.
Re: Show HN: I finished v5 of a JVM framework I've spent spent half a decade making
#120Congrats on v5. Have you tried it yet with GraalVM and native compilation? Any gotchas?
Thanks! We had some interest in running Javalin on GraalVM in the past, but no one has updated the tutorial in many years. It used to work though, so I bet it still would, if you really wanted it to.
My concern would be around reflection, which I think you said gets used when running with virtual threads? and which native compilation can't handle easily. It may need a Quarkus-like pre-build step to generate glue code to work round it.