7 ms·

It's getting better, it doesn't all have to be Spring Boot and JBoss. There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang

• cess11 6mo ago
  If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with. https://www.wildfly.org/ https://www.wildfly.org/ I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for. As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.
  • zokier 6mo ago
    > As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway. Bazel is the most obvious contender and very different from Maven in almost every possible way.
    • cess11 6mo ago
      Not really, no. It is similar but worse than Maven in that it requires quite a bit of time investment to configure, and shares the drawback of Gradle that it is configured in a programming language instead of a configuration language. Switching out Maven for a larger maintenance burden might be reasonable in a large organisation that is swimming in competent employees, but most do not. As for obvious contender, I'd say that would be Gradle, which is harder to get someone started with than Maven and due to the DSL allows you to invent weirder footguns.
      • rubzah 6mo ago
        Did everyone just agree to forget about Gradle? It was everywhere not too long ago. I think I even prefer it to Maven, in a choice between a rock and a hard place type of way.
        • cess11 6mo ago
          I don't think so, but the pain points have become more widely known and taken the edge off the hype.
  • brightball 6mo ago
    JBoss was great back in the day. I remember when there was a JRuby port of it called Torquebox that I loved. Eventually though, I found Elixir and it gave me everything I was looking for from that stack.
    • cess11 6mo ago
      Yeah, same, but Elixir gigs aren't as common as Java gigs. However, if one ends up in a Java role, chances are that Elixir would be a good porting target for the systems since it typically can replicate the architecture but with less fuss and has pretty good support for interfacing with Java.
  • mands 6mo ago
    Yep, I'm using JBoss as a catch-all for older "big-iron" style Application Servers - modern Jakarta EE (10 onwards) is much more slimmed down, and a solid option. unsure re Maven, 4.0.0 has been around the corner for years, but I think there is space for a modern alternative that is JPMS first, supports semantic versioning (i.e. tilde/carat notation) with lockfiles, and doesn't require a bunch of plugins out of the box for common use-cases. Maybe Mill (https://mill-build.org https://mill-build.org) - i've yet to try it.
    • cess11 6mo ago
      Mill looks kind of nice on the surface but I haven't seen it in action in any serious project. I suspect the flexible DSL might come with a maintenance burden. XML is nice, if your pom.xml is massive, just suck it in through JAXB and program against it, perhaps render it to a web page. XSLT can also be helpful. We're not supposed to look at XML as plain text.
  • cmwelsh 6mo ago
    As you’re familiar with the JBoss space, why would someone use an enterprise container over a simple HTTP server (Tomcat, Jetty, etc)? Currently I’m trying to externalize as much as possible to the service mesh. I want teams to stand up a basic unencrypted HTTP server that accepts the company headers and just works with as minimal of a runtime as possible.
    • gf000 6mo ago
      I wouldn't use application servers today, but they were solving many of the same issues as whole kubernetes clusters do, decades ago. The Java (now Jakarta) EE standard on top is a good base for third party implementations to "speak a common language", e.g. it's not that hard to move between Quarkus/spring/micronaut etc, even if not all support the actual standard.
• selfmodruntime 6mo ago
  There's also Javalin for oneshot java projects where you write your webserver like you'd write express.js
• nixpulvis 6mo ago
  I never want to read another Bean or log4j config ever again.
  • bigbuppo 6mo ago
    Didn't they all switch to convention over configuration and dependency injection so now your configuration is your source code?
    • lmm 6mo ago
      Some people did but that's actually worse. Your configuration comes magically out of nowhere and when it breaks you can't fix it.
      • rubzah 6mo ago
        Nobody ever wanted to wire up RPC endpoints, in the form of Enterprise JavaBeans(tm), using XML files. That is one for the history books of ridiculous technology.
        • lmm 6mo ago
          XML files are bad. Invisible magic is worse. The sensible way to wire up a bunch of RPC endpoints is, like the sensible way to do most things, plain old code.
• deleted 6mo ago
  [deleted]
• chrisweekly 6mo ago
  A friend and former colleague was agog about Quarkus and it does look pretty compelling.
• jiehong 6mo ago
  Quarkus is better, but isn’t that amazing IMO. It’s still very much an annotation festival in the code, making the framework quite lengthy to learn for newcomers (gotta learn Java and the whole quarkus annotation DSL with it). Go is verbose, but it is much more explicit and only uses standard language things instead of a whole annotation DSL.
  • mands 6mo ago
    Helidon SE (https://helidon.io/#se https://helidon.io/#se) or Javalin (https://javalin.io/ https://javalin.io/) would be more in that vein - straight-forward modern Java, super fast.
    • cryptos 6mo ago
      In my opinion Helidon is the most refreshing of these frameworks. It supports virtual threads from the ground up and comes with clean, function, mostly annotation free APIs. It really looks like a Java framework should look today.
  • gf000 6mo ago
    There are non-DSL frameworks in Java. It's just that arguably the benefits of a DSL outweigh learning them. Putting an annotation on a method is much easier than registering this method at n places in ordinary code, which could look any number of ways. If you move to a new project, in the first case can just immediately jump into framework-related stuff, while in the second all this logic has to be untangled first. And let's be honest, Spring/Quarkus probably got their abstraction right after n iterations, which is not necessarily true of a random team.
• Nursie 6mo ago
  Having used micronaut for a few years now, I hate it. Maybe it's innate to trying to use a a fully fledged server-style framework in a serverless context, but I don't think it's suitable. In fact I think the whole idea ("Hey, let's bludgeon spring-like metaphors into an entirely new setting") was a poor one. Java itself I've enjoyed more and more over time as the language has evolved into something much more expressive, and without all the enterprise crap. My hope is that one day frameworks like Micronaut will end up discarded too.
  • never_inline 6mo ago
    It was a while back (when I was a worse programmer) I found both Micronaut and Quarkus dev experience more palatable than spring. what did you dislike? Pervasive DI? Annotations? configuration mess?
    • Nursie 6mo ago
      Never done much Spring, so I don't have a lot to compare to. But ... I'm not a massive fan of using annotations in concept, because they obfuscate what's taking place. Unlike in (say) Python, where annotations are effectively functions wrapping the function they annotate, in java they're more akin to a customisable preprocessor. Obviously I do use them, liberally, because that's the way things are done, but I'm not a big fan. And using any modern framework relies on these a lot. Micronaut gripes - 1. It works great until it doesn't, and you have a special case, and then you have to dig into source to figure out what on earth is going on. 2. Keeping up with latest isn't always easy, micronaut 3->4 was a huge effort. 3. For all it's called micronaut, the produced packages are pretty huge. Serverless-specific gripes - 1. What I'm receiving isn't really an http message over a socket. It's an AWS gateway event with everything already read and packaged up. So there's no reason that (for instance) I shouldn't access the message body in a request filter, because I don't give a crap about the jetty server-loop being non-blocking. 2. Startup time is terrible. And when I managed to get a native compiled version to actually run, it got worse. A lot of this seems to be down to hibernate, but there's a big gap between startup and any logging from the framework at all. We've tried a bunch of stuff to remediate, so far with little success. In general I think that serverless is such a different paradigm from a long-running server that approaching it from the point of view of "how can we make this the same so developers who've never thought outside of the spring-like box can still be productive?" was wrong from the outset.
• nekitamo 6mo ago
  I'd like to mention the web framework I'm using these days, Jooby: https://jooby.io/ https://jooby.io/ I've found it quite satisfying compared to the other "new" ones. As for the original topic, I just want to echo what others have said, and say that I am happiest in Java when writing it as if it were Golang code. That an the first-class runtime and performance and deep ecosystem make it a great choice in 2026.
  • deepakarora3 6mo ago
    I one hundred percent support the above. Jooby is a great performant framework, simple to use with tons of flexibility and features. Super happy with it!
• e3bc54b2 6mo ago
  > a better build system is sorely needed - one of the things that Go / Rust did right Honestly there are only two reasons I wouldn't pick up Java for personal projects, difficult to build single executable (Graal is still very un-ergonomic), ridiculous build systems. I can kind of live with former, but Gradle is so very extraordinarily terrible that I don't know where to begin. Problem is, it solves some real problems (in extremely bad way) that people keep using it. I long of a cargo-style revolution in Java world. (No, the newly popped up alternatives haven't really cut it so far)
• peterashford 6mo ago
  Not sure if I agree about the Go build system. Causes me endless issues at work - and my workmates, going by the number of complaints