121–130 of 153 posts
Lombok
Gradle, Guava
JUnit 5, testcontainers, WireMock
Logback, Slf4j
Okhttp, Open Feign, RestTemplate
Micrometer
OpenApi, swagger
Liquidbase, jooq - db stuff
This is your run of the mill stack
Dropwizard, Vert.X seem to be less used nowadays, Spring has mostly won the show
Heard people using Kotlin, Quarkus, Micronaut but that's niche stuff
Here is what we use and I'd recommend to others. The most common: - Kotlin for most of the backend code, but Java for shared libs. We still use Java 8 for some libs which may be used in Android, that's an unfortunate reality - Gradle for build config - Spring for application architecture And few things that may significantly improve your dev process, but are not so common: - Spring Reactor (and Webflux) for processin…
Considering Kotlin is a supported, first-class language on Android, why not write your shared libs in Kotlin as well?
I'll chime in my opinion: Java is getting something right that I don't see much elsewhere: Dependency Injection. Combine this with a mocking framework and you can write _actual_ isolated unit tests for every single part of your stack. We're fans of CDI, it's a more polished Spring framework without the legacy weight. We're developing in Quarkus, MicroProfile, and bigger monoliths in Apache TomEE. We use ActiveMQ exte…
If it takes too much effort to write that anonymous inner class, then the Interface may be too big and need broken up. Or maybe you're hiding too much state and need to rethink the API.
Personally, after the log4j fiasco, I wouldn't touch Java. The standard ecosystem setup is to use all the major 3p libraries for all your functionality (Jaxrs, swagger, log4j, jersey, e.t.c) While this generally works, the ecosystem is full of holes (like log4j), and crappy behavior. You get things like "javax.ws.rs.ProcessingException: Already connected", exceptions which mask underlying issues like not being able t…
Earlier quoted context omitted.
Extension methods? Aliases? Countless more features that are designed to make your code hard to read & understand. Build scripts are generally written once and executed hundreds or thousands of times. It makes far more sense to optimize their performance rather than ease of writing.
It's okay to have a different opinion, but personally I'd never work at a place that did that. Java is already on thin ice and this is simply how I tolerate it and how I've seen successful java teams operate in cloud environments. If you are really seeing dramatic build times, I don't blame you for investigating them, but I'm not going to forgo years of DX improvements just because I heard on the internet one time th…
Java stacks will be running major companies long after everyone posting in HN today is dead and gone.
Earlier quoted context omitted.
Netbeans was really great, maybe still is, but the noise jetbrains made with the astroturfing advertizing has jetbrains dominating everything. IMHO Netbeans was ahead of idea in many ways. But since they didn't buy commenteers to hype their product it's pretty much nowhere, at least I don't know anyone who uses it.
I'm someone who has regularly recommends Jetbrains software (including IntelliJ and Resharper) to others in comments, and now I'm wondering if they forgot to send me my check.
I'll chime in my opinion: Java is getting something right that I don't see much elsewhere: Dependency Injection. Combine this with a mocking framework and you can write _actual_ isolated unit tests for every single part of your stack. We're fans of CDI, it's a more polished Spring framework without the legacy weight. We're developing in Quarkus, MicroProfile, and bigger monoliths in Apache TomEE. We use ActiveMQ exte…
What does this mean?
I'll chime in my opinion: Java is getting something right that I don't see much elsewhere: Dependency Injection. Combine this with a mocking framework and you can write _actual_ isolated unit tests for every single part of your stack. We're fans of CDI, it's a more polished Spring framework without the legacy weight. We're developing in Quarkus, MicroProfile, and bigger monoliths in Apache TomEE. We use ActiveMQ exte…
> We avoid the fanfare of Docker, as really it's not needed for Java apps; they're somewhat self-contained anyway and it created more problems than it solved. What does this mean?
For example, if you're writing code in C++ targeting Linux, using Docker helps with reproducible builds and deploying on any hardware.
But if you have a VM, there are less advantages. There still are some, of course, with orchestration etc if you want it.
I'll chime in my opinion: Java is getting something right that I don't see much elsewhere: Dependency Injection. Combine this with a mocking framework and you can write _actual_ isolated unit tests for every single part of your stack. We're fans of CDI, it's a more polished Spring framework without the legacy weight. We're developing in Quarkus, MicroProfile, and bigger monoliths in Apache TomEE. We use ActiveMQ exte…
> We avoid the fanfare of Docker, as really it's not needed for Java apps; they're somewhat self-contained anyway and it created more problems than it solved. What does this mean?