I have used https://sparkjava.com/ when I still did Java some years back. It was as thin as they come and a real joy to get started and going.
Jodd – The Unbearable Lightness of Java
71–80 of 239 posts
Re: Jodd – The Unbearable Lightness of Java
#72Earlier quoted context omitted.
It's really very simple, no you don't need to pass around a factory object. You just have a class/classes that construct/wire all of your singleton objects and passes the required dependencies into their respective constructors as necessary. Here is a contrived example of what the wiring code might look like for a web app that uses a database. public static void main(String[] args) { MyConfig config = readConfigFile(…
How is it better to make a dev write out that plumbing and others reread it? I’m made of meat, so I want to automate everything we safely can.
You’re reading and writing the “plumbing” no matter what you do. So, does it matter if you are writing a config file or Java code?
Re: Jodd – The Unbearable Lightness of Java
#73I really like the Go-like simplicity of these libraries, without the cursed architecture astronomy from the 2000s. In general it's interesting times for Java. With all of language improvements from Kotlin/Scala, and upcoming Go-like concurrency it really feels like a renaissance for the language.
"upcoming Go-like concurrency" can you elaborate on this? Java will have CSP at the language level? I find it hard to believe.
Project Loom’s virtual threads (without dedicated OS threads and stacks), which will hopefully relieve devs from manually doing a CPS transform of procedural code into chains of futures for thread pool workers to complete.
Re: Jodd – The Unbearable Lightness of Java
#74Earlier quoted context omitted.
If you take the single responsibility principle even as much as half-seriously, the problem domain more or less decides which things will create which things. If your software platform can't support that, you get spaghetti mess when programmers inevitably build workarounds.
You know, you hear Java repeat things like that a lot, while Go programs just tend to stay simple and readable. It's either the culture or the language causing the problem. shrug
Is that why Google has a DI code generation tool for Go (Wire)?
Re: Jodd – The Unbearable Lightness of Java
#75Earlier quoted context omitted.
Here's what I was thinking of, under "Vert.x Memory Usage": https://www.tikalk.com/posts/2018/04/30/vertx-memory-usage-w... Quote: "But how does Netty do things so fast ? One of the reasons is that it is using native memory pool to store network buffers. If you did some file reading or network action with Vert.x you probably used io.vertx.core.buffer.Buffer class. This class is actually a wrapper around Netty io.nett…
FWIW, here is a fairly minimal example[0] of broadcasting over websockets reusing the same buffer. I'm not very familiar with vert.x(not a netty expert either), but I think the author of that article is ascribing blame to the wrong place. [0]: https://github.com/juggernaut/netty-websocket-broadcast-exam...
Not using websockets, but thanks! I have to look into it again. Right now the service is working fine so I haven't been motivated to work on it again. (in-memory CDN based on vertx-web + Caffeine + custom on-disk LRU cache)
Re: Jodd – The Unbearable Lightness of Java
#76Earlier quoted context omitted.
It's really very simple, no you don't need to pass around a factory object. You just have a class/classes that construct/wire all of your singleton objects and passes the required dependencies into their respective constructors as necessary. Here is a contrived example of what the wiring code might look like for a web app that uses a database. public static void main(String[] args) { MyConfig config = readConfigFile(…
How is it better to make a dev write out that plumbing and others reread it? I’m made of meat, so I want to automate everything we safely can.
Advantages:
- Don't need to depend on a DI library, makes code more modular and portable.
- Faster application initialization time.
- Easy to navigate and understand relationships between classes, good IDE support.
- Easier to break apart and test parts of the application.
- Easy to understand, don't need to learn the intricacies of a complex DI framework.
I'm not saying there is no place for DI frameworks, although I do think they are overused.
Re: Jodd – The Unbearable Lightness of Java
#77Earlier quoted context omitted.
You know, you hear Java repeat things like that a lot, while Go programs just tend to stay simple and readable. It's either the culture or the language causing the problem. shrug
Is that why Google has a DI code generation tool for Go (Wire)?
That thing that's largely not used? Sure, some person who signed Google's onerous employment contract wrote that. Look what other stuff those people are pushing https://cloud.google.com/open-cloud/ and see how it's all "enterprise solutions" while the community adoption is at 694 projects importing wire: https://pkg.go.dev/github.com/google/wire?tab=importedby
Re: Jodd – The Unbearable Lightness of Java
#78I remember the days, when the Spring framework was advertised as a lightweight alternative to Enterprise java beans (ejb); now Spring outgrew the pretence of being lightweight, don't know when that happened. A year and a half ago, i got back to work with java and spring boot, and i was overwhelmed by the prevalence of annotations in spring boot. To cope with all this, i wrote this little project: https://github.com/M…
the pernicious thing about spring is there appears to be 15 different ways to do the same thing. Everyone's idea and enhancement request was thrown in. Plus things got left in that should have been deprecated after better ideas came along or the java language improved to allow new techniques. I'm glad someone is working on a light weight replacement to spring. I had some ideas on a light weight DI framework but never…
> the pernicious thing about spring is there appears to be 15 different ways to do the same thing.
Oh gods below this. I was half wondering if I was writing Perl with how much TMTOWTDI was floating around in the cesspool of Lombok and Spring.
Re: Jodd – The Unbearable Lightness of Java
#79This is great. Java BADLY needs to shed weight and verbosity and in general just catch up with the times.
Having used not only traditional Java and Spring (including "modern" Spring boot) but also alternatives, like eg DropWizard, I MUCH prefer the alternatives.
DropWizard in particular seems to me a more neutral collection of some of the best tools for each job, and it's both simple and easy.
Spring is just Spring, Spring and more Spring, and while it's "easy", it's not simple- there's a lot of magic.
I'm glad to finally be in a team where people are open minded enough to look outside the Spring bubble. TBH these days, we don't even use Java anymore, we use Kotlin + Arrow which is amazing.
Re: Jodd – The Unbearable Lightness of Java
#80Earlier quoted context omitted.
If you take the single responsibility principle even as much as half-seriously, the problem domain more or less decides which things will create which things. If your software platform can't support that, you get spaghetti mess when programmers inevitably build workarounds.
You know, you hear Java repeat things like that a lot, while Go programs just tend to stay simple and readable. It's either the culture or the language causing the problem. shrug
I imagine that is because Go is not used for applications of the same breadth as Java.
Go is typically structured with many relatively small binaries. Each binary can be relatively self-contained.
The way I've seen Java used, it typically has fewer binaries with each binary bundling many services. Many of which include clients for services at the company but a different org - where that other org can just provide a Guice module that sets up the client to call their service and anything that needs it can easily inject it.
I still hate Java but, damn, I see why it's used at B I G companies.