15 ms·

Ask HN: What is a modern Java environment?

132 points by smorgusofborg 5y ago

Hello, I used Java a very long time ago, like 1.6, and I'm wondering what using Java at work in ~web backend looks like today. What elements of your stack would you consider most important? Do most projects lean heavily on Spring Boot or something else? Which IDE? Pointers to refreshers or concise introductions you might give a new hire would be handy too.

PaulHoule 5y ago
IntelliJ idea is the best IDE. JDK8 incorporated a lot of great functional programming ideas (though the streams library is awful.). Up through JDK17 there are many improvements including a more scalable runtime. I haven’t been paid to work with Spring since 2013, every project I’ve worked on since has used Guice, maybe Dropwizard. JAX-RS is the dominant paradigm for web back ends these days, particularly if you are writing single page applications.
- jbellis 5y ago
  I think the Streams designers did an amazing job. One of my favorite things about modern Java. Yes, it's more verbose than Python list comprehensions, but it's both higher-performance (parallelism that just works) and more productive (static typing means it almost always works as intended the first time).
  - PaulHoule 5y ago
    That's just not true about the parallelism. The work stealing mechanism used by streams doesn't really work. Frequently I've seen people get something like a 1.7x speedup on an 8 core machine and was able to get a 7.8x speedup on the same machine using a ThreadPoolExecutor. For common "embarrassingly parallel" problems there are two parameters you need to set: (1) How many threads to use, and (2) How fine to subdivide the problem. Often the basic work unit takes much less time to complete than the time it takes to switch between threads. For instance a raytracer can probably trace one ray in less than the time it takes to communicate between threads. If you try to parallelize a task with too fine a granularity you get a slowdown not a speedup. You might find you get a good speedup over a fairly wide range of granularities (you might do well with anywhere between 100 and 10,000 rays) but batching of some kind is essential. As for the thread count it depends on if the job is CPU bound. A CPU bound job needs about as many threads as you have cores or SMT "threads". If the job is I/O bound you usually need many more threads to maximize performance, but it's tricky. A web crawler might be able to support 100's or 1000's of threads but if you point all those threads at one server you might crash it, get banned, or both. If the awkward streams API bought you good performance and reliability (let's see... just about zero support for error handling) that would be one thing but it doesn't. Static typing working so well is not a special feature of the streams API but rather one of the rather brilliant engineering that went into JDK 8. You can easily write your own "map()" functions and other higher-order functions that do many of the things the Stream API does. It would really be nice to see a better third-party API.
- mhaberl 5y ago
  >I haven’t been paid to work with Spring since 2013, every project I’ve worked on since has used Guice, maybe Dropwizard. This is the opposite of my experience. I worked with Java a lot for the last 10 years or so. In the last 3 years literally each request I got for implementing stuff in Java also required Spring (Spring Boot) - and that was dozens of clients.
biehl 5y ago
Spring Boot is the go-to solution for Java where I work. And definitely Intellij as IDE.
- manishsharan 5y ago
  And Maven. Don't forget Maven.
Hardik_Shah 5y ago
Over the last five years, the Java Platform has seen a tremendous amount of evolution and improvement in a variety of areas, including: language features in Java, Kotlin, and Scala; Functional Programming; dev environments; test workflows; Reactive; Stream processing; and distributed data.
- soco 5y ago
  Is Scala still in trend?
  - isbvhodnvemrwvn 5y ago
    Not really. It hasn't seen growth for a while.
    - hiyer 5y ago
      It's big in the data science world because of Spark. For general purpose JVM apps I see people mostly going with Java or Kotlin.
  - softwarebeware 5y ago
    It's Kotlin now. Kotlin has similar expressibility and extensibility, without Scala pitfalls. (Scala pitfalls that people didn't like included new versions having breaking changes, complexity, theoretical/academic features that weren't necessarily useful to consumer applications, and slow build times).
    - kaba0 5y ago
      New versions don’t have breaking changes, they are just not binary compatible between major version upgrades which is true of many other languages as well. Regarding complexity - scala has many features due to having a small number of clever primitives. Kotlin special cases many common cases, but imo that will be a more complex language down the line. I really don’t know what do you mean by academic features — one can make haskell libs with scala but they are libs, not language features. And build time-wise it is not that much slower than kotlin.
omgmajk 5y ago
IntelliJ Idea for sure.
- sgt 5y ago
  Also using IntellJ. But how is the landscape with the other IDE's these days - is NetBeans keeping up?
  - the-alchemist 5y ago
    Netbeans died an unfortunate death once it moved to the Apache foundation and Sun/Oracle funding died out. https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F01fchg https://trends.google.com/trends/explore?date=today%205-y&q=... Unfortunate, because it had (has?) a great Swing and UML editor, built-in for free. Maybe I'm wrong and it's awesome now, but I haven't used it for a while in favor of Eclipse, and now, IntelliJ. This graph illustrates the IDE popularity between Intellij and Netbeans. IntelliJ became preferred over Netbeans about mid 2014. https://trends.google.com/trends/explore?date=all&geo=US&q=intellij,netbeans https://trends.google.com/trends/explore?date=all&geo=US&q=i...
    - adalu 5y ago
      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.
      - efdee 5y ago
        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.
        thfuran 5y ago
jbellis 5y ago
Good summary of the language-level changes here: https://piotrminkowski.com/2021/02/01/new-developer-friendly-features-after-java-8/ https://piotrminkowski.com/2021/02/01/new-developer-friendly... ETA: actually if you haven't used it since 1.6 you'd want to find an article on Java 8 as well that covers Streams.
mooreds 5y ago
My company's product is primarily written in Java. It's a web based auth system, fwiw. I don't write too much code nowadays, but read a lot. From what I can see, here's the stack: * intellij for an ide (with tons of plugins) * prime MVC (https://github.com/prime-framework/prime-mvc https://github.com/prime-framework/prime-mvc) for the framework * mybatis for SQL/queries * java 17 I've also used dropwizard and spring. If it was a greenfield development with emphasis on developer productivity, I'd go with spring any day. Big dev community, tons of doco, a solution for any problem if you can find it.
davidjfelix 5y ago
* Use SDKMan for runtime and sdk management https://sdkman.io/ https://sdkman.io/ * Try to use Kotlin where allowed (Maybe unpopular and bad faith response given that you asked about Java, but I don't care -- kotlin's Java interop is way more seamless than Scala or Clojure to the point that its often not even noticable) https://kotlinlang.org/ https://kotlinlang.org/ * IntelliJ * Spring is pretty popular, I've seen a lot of people using Vertx * Square libraries like Okio, okhttp, retrofit, wire https://github.com/square https://github.com/square * If you're not using spring, use Dagger for DI https://dagger.dev/dev-guide/ https://dagger.dev/dev-guide/ * Overlook netflix abandonware (another unpopular opinion, I'm sure) * Use gradle, not maven. Use kotlinscript as the config language, not groovy
- oauea 5y ago
  > Try to use Kotlin where allowed If you want a slow build and code that is fun to write but hell to read, that is good advice. > Use kotlinscript as the config language Extremely slow, that is.
  - davidjfelix 5y ago
    I disagree that it's easier to write than read. I tend to think Kotlin is much easier to read than java but harder to write because it tries to enforce good Java patterns at a language level. I agree that these will slow down your build, but not significantly, and at the benefit of developer comfort to make changes. Incremental compilation largely erases these slowdowns.
    - oauea 5y ago
      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.
      - davidjfelix 5y ago
KronisLV 5y ago
IDE: IntelliJ IDEA https://www.jetbrains.com/idea/ https://www.jetbrains.com/idea/ Nothing else seems to come close, they have a Community version, nowadays Eclipse and NetBeans both feel slow but Visual Studio Code with Java plugins lacks refactoring abilities one might expect in an IDE for non-trivial projects. Also, if you get the Ultimate package of their tools, you get all sorts of other useful tools, personally i also enjoy WebStorm and DataGrip for developing front end stuff and working with databases in a separate tool. JDK: whatever the LTS release of JDK is at the time, based on the kind of work that i do (so JDK 17 now) https://adoptium.net/ https://adoptium.net/ As long as you're not stuck with JDK 8, you should be fine in regards to this. But you can definitely enjoy some speed improvements across the releases as well as new language features as well as things like helpful NullPointerException messages. Personally, i'd sometimes also look towards OpenJ9 as an alternate runtime (due to lower memory usage), but that project's future isn't very clear (at least in regards to available container images) last i checked. As for frameworks, pick one of the following: - Spring Boot: mainstay of the Java ecosystem, has a really large amount of integrations and the Boot version also simplifies getting up and running, about as safe of a bet as Rails for Ruby or Django for Python - Dropwizard: probably the closest competitor to Spring Boot in my eyes, but is a more loose collection of a variety of pretty much "standard" libraries, has decent developer experience - Eclipse Vert.X: pick this if you want to work with reactive programming, last i checked it didn't feel quite feature complete, but the performance numbers speak for themselves, even if it feels a bit niche - Quarkus: another modern option that's tailored for the development of performant web services, got a lot of hype in conferences in the past few years - Helidon: pretty similar to Quarkus as far as i'm aware (at least as far as the positioning in the market goes) so figured i'd also mention it In practice, you're most likely to see Spring Boot in existing projects since it's so boring and dependable, though perhaps sometimes you'll also run into the legacy Spring framework (which can be a pain to deal with) or even some of the other ones. Here's a rough performance comparison if you care about that sort of stuff: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite&l=zik0vz-sf&c=8 https://www.techempower.com/benchmarks/#section=data-r20&hw=... Build tools: personally, i just use whatever Docker images to base the apps on when available and something like Ansible when not. For the actual toolchain, Maven is still pretty dependable, i guess Gradle is also okay. You might occasionally run into tools like Bazel or Jib, experiences there might vary. App servers: if you need an application server for some reason (e.g. deploy app as .war), Tomcat is still a good option. If you need the EE functionality (e.g. Java EE which is now Jakarta Java), you might need to reach for something like TomEE or Payara Server, though i haven't needed to do that for a few years at this point, since Spring Boot embeds Tomcat and that is good enough for almost all projects.
mhaberl 5y ago
This is my experience. For context I do a lot of contract work mostly in banking, ecommerce and insurance. - Spring Boot - IntelliJ - Gradle or Maven - Java 8 features (for various reasons most of my clients do not use version > 8)
- arez 5y ago
  what about lombok? Edit: just curious if you think it's standard
  - azth 5y ago
    With records now being supported in Java, wouldn't Lombok be less needed?
    - ivan_gammel 5y ago
      Unfortunately not. Records are not compatible with JPA, so classic beans with getters and setters would still be a choice for many people. Record-friendly ORMs do not exist yet (I’m currently working on one).
      - kaba0 5y ago
        Could you please share your ORM? I would really like to use java with much less reflection.
        ivan_gammel 5y ago
        If you can send me an email at oss+hn[at]esoftworks.com, I will let you know when I will have beta quality code on GitHub. This is a personal side project exploring annotation processing and targeting modern Java (17+), some results will be ready probably in 2-3 weeks.
        ivan_gammel 5y ago
        Feel free to star this repo and comment: https://github.com/ivan-gammel/orm16 https://github.com/ivan-gammel/orm16
matsemann 5y ago
The stack I've seen, used and liked at many clients is: Spring Boot, Kotlin, IntelliJ. Which of course means all the old discussions: Jetty/Tomcat/JBoss/GlassFish, GSON/Jackson, Hikari/C3PO/etc, etc are now mostly moot, since most just use the Boot defaults until they need something else. Kinda nice, actually. Less bikeshedding, can get a project up and running without taking a stand on all these things. Most clients use maven, a few gradle, some used gradle and moved back when no one could understand their config. Gradle might get a second chance now that it can be written using kotlin.
- joshenberg 5y ago
  Can confirm this is my stack at a fortune 500 web/entertainment company.
- luciusdomitius 5y ago
  This is it. The irony is that the modern Java stack uses the JVM & classlib, but a different language. If you want to go full hipster, there is Micronaut (also Quarkus) and if you'd like to go a bit off-charts, there is Dropwizard. I don't think that they offer anything extra over SB though.
  - heurisko 5y ago
    Or for hipsters there's https://www.jhipster.tech/ https://www.jhipster.tech/
    - matsemann 5y ago
      One of my first PRs ever was to that project, back in 2013. Then it was a nice starter project, showing how one could move away from the clunky server side rendering frameworks at the time, instead using AngularJS on the frontend and having a backend. And also included a nice simple Spring setup, before Spring Boot existed. So pretty hip, and very lean. Since then it has.. evolved to something quite big, I feel, where one quickly end up with lots of unknown boilerplate in one's project. I mean, it's probably useful in its own way, almost like a Django alternative or something with batteries included. But not very hipster anymore.
darksaints 5y ago
After doing some "modern" spring boot / hibernate, I came away wondering how anybody ever thought that was a good idea. The switch to kotlin with ktor took less than a day, and my sanity has been preserved.
throwaway4good 5y ago
Spring Boot wrapped in a Docker container and a frontend written in JS using React, Angular or similar. So maybe the frontend and deployment has changed. The rest probably not so much. Java versions 8 and 11 are by far the most common. Lambdas were introduced in version 8.
- throwaway4good 5y ago
  If you ignore the way frontend is made (JS + rest api ws. server-side rendered html) and how stuff is deployed (containers vs. war-files); amazingly little has changed in Java the past 10-15 years.
nigerian1981 5y ago
I’ve seen the Micronaut framework used instead of Spring Boot a lot recently for AWS Lambda
smallerfish 5y ago
Kotlin + Dropwizard. Avoid Hibernate, go with JDBI. If I was starting a new project I'd look at Jooby, which looks pleasant and does very well on TechEmpower benchmarks.
- icedchai 5y ago
  JDBI is pretty slick. We used it as a previous company. Previous experience was with Hibernate, lower level JDBC, and some other half baked proprietary ORMs.
kitd 5y ago
For backend frameworks, I'd look at Quarkus [1] or Micronaut [2]. Both are geared towards configuration, async processing and native compilation, along with a ton of options to integrate with external systems. For something a bit lighter weight, Vert.x [3] is a good option (Quarkus is based on it). [1] - https://quarkus.io/ https://quarkus.io/ [2] - https://micronaut.io/ https://micronaut.io/ [3] - https://vertx.io/ https://vertx.io/ You'll need Java 1.8+, and Maven or Gradle for the toolchain (I prefer the former). Intellij is the best IDE but I get by with VSCode.
- isbvhodnvemrwvn 5y ago
  There's no reason to use 10 years old version of Java. Use 17.
  - kitd 5y ago
    True. I was just stating the minimum level.
AssertErNullNPE 5y ago
I can't speak to how prevalent it is in the industry, but something my team has started doing in our web services is building with GraalVM and deploying native images. The build time can be super long, but the benefit is incredibly fast start-up time, which really benefits horizontal scaling. We're using Quarkus (https://quarkus.io https://quarkus.io), which is largely built on Vertx which was mentioned elsewhere, but other frameworks (Micronaut (https://micronaut.io https://micronaut.io) comes to mind) make it easy and SpringBoot is also working on support. If your doing containers/kubernetes native images feel like the way to go.
vollmond 5y ago
I'm about 3 years out of date on Java, but if I were spinning up a new project it would be: * Latest JDK * Spring Boot * JQuery/Bootstrap * Eclipse (with Vim keybindings plugin) Caveats: * If it was a personal project or only a very small team, I'd start with Kotlin * I haven't tried IntelliJ in quite a while and would give it a shot to see if I wanted to switch off Eclipse now
- luciusdomitius 5y ago
  Make sure you do give it a try and beyond the initial discomfort too. It has improved leaps & bounds.
soco 5y ago
Eclipse as IDE (actually STS - Spring Tools Suite edition) for both Spring Boot and JBoss Tools (yes there's enough work for JEE - WildFly or JBoss EAP). The build would be most of the time Maven (including the assembly plugin) and sometimes would create native Quarkus images for cloud tools (read serverless).
ta988 5y ago
Gradle (with Kotlin syntax), Spring Boot (vertx, ktor or for small or microservices), Kotlin, IntelliJ. That would be a "modern" stack for me. If you can't use Kotlin, Java has improved a lot since 1.6 you will be pleasantly surprised. I recommend you start an intellij (Free edition if you want to, even if I still recommend the paid one) and follow the springboot kotlin tutorial below. That will give you a good idea of what the ecosystem looks like these days. https://spring.io/guides/tutorials/spring-boot-kotlin/ https://spring.io/guides/tutorials/spring-boot-kotlin/
- ta988 5y ago
  Oh and make sure you start with JDK17. I still see people starting projects with 8, you don't want that!
MockObject 5y ago
I've been doing Java non-stop since before 1.6. I just started a new project, and it's * IntelliJ * Standard enterprise Java JEE 9.1 (JSP, JPA, EJB) * Payara app server * Twitter Bootstrap * Maven * Test driven development using TestNG + AssertJ * Postgres + Liquibase for schema management Code samples now come from https://www.baeldung.com/ https://www.baeldung.com/
- ytdytvhxgydvhh 5y ago
  Just curious - you mention JSP. Was that mentioning that yeah, JSP happens to be part of JEE or are you actively using it? I haven’t heard of a new project using JSP for a while.
  - MockObject 5y ago
    Yes, my new project uses actual JSPs. Granted, there aren't tons of pages to be built in this project, and certainly nowhere near the scale that might call for a different option. For even a few dozen pages, JSP is still just fine.
ojhughes 5y ago
Along with the various other libraries and frameworks mentioned; * Testcontainers - seamless support for using Docker in integration tests [1] * Project Reactor - nice framework for reactive programming [2] * Executable Jars - No need to deploy a War file to a servlet container anymore. Build an executable Jar with an embedded container. Spring Boot makes this very easy 1. https://www.testcontainers.org https://www.testcontainers.org 2. https://projectreactor.io https://projectreactor.io
itpragmatik 5y ago
- IntelliJ - Java 17 - SpringBoot 2.6.x - Hibernate - Maven - MySQL or Postgres - Liquibase - Swagger/OpenAPI - Docker
rvcdbn 5y ago
Bazel, ErrorProne, Dagger, AutoValue, IntelliJ
exabrial 5y ago
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 extensively for scaling. ( And I mean extensively... on a modest 512m server, we can push several thousand messages/s reliably to a _lot_ of topics and queues, all with delivered-exactly-once guarantees) 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. For true isolation, we use systemd to create cgroups and chroots and prevent application escapes. For deployment, apps are one-jar'd down to a single executable, then packaged up in a .deb using the jdeb maven plugin. We stick with the unix philosohpy of using /etc/default for env variables that help the app locate their database or LDAP cluster.
- edmcnulty101 5y ago
  Containerization is great. It allows you to write all the infrastructure for you Java app as code and then just simply type 'docker-compose up' to get it running (or whatever your orchestrator). This makes it super portable. Just something to think about. I personally think the win's from Containerization are greater than the challenges.
  - exabrial 5y ago
    I admit we do miss that part. Instead for us it's `sudo apt -y install app-name`
    - cosmotic 5y ago
      installing the app locally isn't as sustainable. The data and configuration for test environments gets scattered across the system and is less reproducible for new comers. As changes are made to the test environment, developers have to then install/update/reconfigure manually. It becomes an nmo effort with less consistency and more error over the single line docker-compose up
splix 5y ago
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 processing data and requests. Takes a time to learn, but it worth it - Thymeleaf for UI - Spock for testing. Highly recommended for designing tests - Testcontainers for integration tests - Micrometer to see what's going on with your app. I.e., to export all internal metrics to use with Prometheus/Grafana/etc For the environment - SDKMan to manager the environment - Gradle Application plugin or Google's Jib to pacakge your app. First prepares a Zip with all binaries, second a Docker container - IntelliJ IDEA - Github Actions - turns out to be the most usable CI. Though the Jetbrains TeamCity may be better for a large team
- farmerbb 5y ago
  > 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 Considering Kotlin is a supported, first-class language on Android, why not write your shared libs in Kotlin as well?
  - splix 5y ago
    I'm talking about open-source libs, i.e., I don't know who is going to use the lib, which env and target language they have, etc. So I think that Java is the best middle ground here because it guaranties the full support of JVM features and 3rd party tools. I mean just avoiding a risk that it would be incompatible with something.
cimi_ 5y ago
We have a multi-project gradle build, all our code is in Kotlin, we use micronaut as our base framework and we use IntelliJ as our IDE - this setup has worked great for us over the past year.
stickfigure 5y ago
I have been thinking of writing up a series of articles on this. Without going into too much detail: * IDEA * Deploy on Google App Engine, Digital Ocean App Platform, Heroku, Elastic Beanstalk, etc - get out of the ops business entirely. * Guice as the backbone, no Spring/Boot. I wrote a tiny dropwizard-like "framework" to make this easier: https://github.com/gwizard/gwizard https://github.com/gwizard/gwizard but there's a laughable amount of code here, you could build it all from scratch with minimal effort. This is about as lightweight as "frameworks" get because Guice does the heavy lifting. * JAX-RS (Resteasy) for the web API. IMO this is the best part of Java web development. HTTP endpoints are simple synchronous Java methods (with a few annotations) and you can test them like simple Java methods. * Lombok. Use @Value heavily. Cuts most of the boilerplate out of Java. * Junit5 + AssertJ. (Or Google Truth, which is almost identical to AssertJ). * Use functional patterns. Try to make all variables and fields final. Use collection streams heavily. Consider vavr.io (I'll admit I haven't used it in anger yet, but I would in a new codebase). * StreamEx. Adds a ton of useful stream behavior; I don't even use basic streams anymore. * Guava. There's just a lot of useful stuff here. * For the database, it really depends on what you're building. Most generic business apps, postgres/hibernate/guice-persist/flyway. Yeah, folks complain about hibernate a lot but it's a decent way to map to objects. Use SQL/native queries, don't bother with JPQL, criteria queries, etc. * Hattery for making http requests (https://github.com/stickfigure/hattery https://github.com/stickfigure/hattery). This is another one of mine. I make zillions of http requests, functional/immutable ergonomics really matter to me. * Github actions for CI. * Maven for the build. Yes, it's terrible, except for every other build system is worse. Gradle seems like it should be better but isn't. I'd really love some innovation here. Sigh.
- smorgusofborg 5y ago
  Cool, it is a lot to start researching but you sound like you use a very similar style to things I am used to in other languages. On guice/gwizard/maven, if I understand correctly I would be defining new guice DI for something like a message broker (and gwizard's solutions for similar modules might serve as a template) while probably just using direct dependencies in maven for something that doesn't need to be mocked in unit tests or replaceable in production?
mnkmnk 5y ago
What’s the JDK version people use today? My company’s stack is still on java 8.
- valbaca 5y ago
  Most of our old services are still on 8, slowly migrating those to 11. Sometimes it's trivial, other times it's a pain. Anything new is at least on 11 and 17 where possible.
gavinray 5y ago
- Language: Java 17/Kotlin - API Layer: Quarkus (most projects https://github.com/quarkusio/quarkus https://github.com/quarkusio/quarkus), Vert.x (small projects https://vertx.io/ https://vertx.io/) - DB: Postgres, in-memory H2 for simple stuff - Testing: JUnit 5, Testcontainers to automatically start + stop DB Docker containers with tests (https://www.testcontainers.org https://www.testcontainers.org) - Mocking: Mockito (https://github.com/mockito/mockito https://github.com/mockito/mockito) or Mockk (Kotlin, https://mockk.io https://mockk.io) - Dependency Injection: CDI (built into Quarkus, for Vert.x you can initalize Weld when the app starts https://weld.cdi-spec.org https://weld.cdi-spec.org) - Build tool: Gradle with Kotlin DSL - Other tools: Kover: automatic code-coverage reports from JaCoCo/IntelliJ (https://github.com/Kotlin/kotlinx-kover) Ktlint + Detekt: Kotlin linting/static analysis (https://ktlint.github.io, https://detekt.github.io/detekt) PMD, Spotbugs, Nullaway: Java linting/static analysis (https://pmd.github.io, https://spotbugs.github.io, https://github.com/uber/NullAway)
seymon 5y ago
Which JDK distribution is used today? There are so many to choose from.
AtlasBarfed 5y ago
IMO: IntelliJ for IDE (Community edition is free). #1 reason is it supports Kotlin and Groovy very well out of the box. Eclipse is still a plugin disaster, and the language support aside from Java is pretty bad, although I haven't bothered to check in a few years since IntelliJ CE was released. Gradle for builds. It is still copy and paste setup, but at least you can do a lot more things than rigid Maven. Groovy + CompileStatic (personally) for the actual JVM language but admittedly I haven't tried Kotlin yet. Even with closures and other improvements, base Java can't compete with either of those. Spring Boot for your enterprisey stuff/REST services which you are likely using it for. It's such a standard at this point. Unit tests: Spock. Spock is awesome. And very well supported by IntelliJ for autoformat, another BIG reason to use IntelliJ. Man, web frameworks on Java that don't just use it for an AJAX service layer? Who knows.
ActorNightly 5y ago
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 to find the endpoint, or SSL certificate error, mainstream clients for things like Redis having issues with multiple connections and unable to switch to master nodes, and so on. The core language itself is very "dirty" (Integer vs int, requiring a class for the main function, e.t.c). The standard way annotation processors add functionality is to basically write out java files, (or in the case of the ever so popular Lombok, they hack the AST). Because of how annotation processors are run, often times an error during annotation processing with dependency injection will result in very cryptic errors, often about things that were working before that you didnt change. And on top of everything, jdb debugger is pure garbage, forcing you to use bloated software like IntelliJ for any decent functionality. Yes, you can learn the ecosystem and its idiosyncrasies, or you could just write the thing in Python or Node with a much more efficient workflow. Network latencies dominate the processing speed these days, and infrastructure is cheap compared to developer time.
- dgb23 5y ago
  > Network latencies dominate the processing speed these days I want to see data on this. It gets repeated over and over but this doesn't match my experience at all. Am I crazy?
  - ActorNightly 5y ago
    It takes me about 250ms to load hackernews as seen on the browser debug network tab. The total compute for that request is minimal. Speeding this up may reduce total infrastructure costs, where if everything is kept static you will see benefits long term, but in terms of reducing total latency, it will be next to irrelevant.
    - dgb23 5y ago
shaman1 5y ago
Spring Boot (embedded Tomcat/Jetty/Netty) 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
fulafel 5y ago
Many use other languages on the JVM. Scala, Clojure, Kotlin etc. Besides the naked functionality, the language communities and cultures have their varying strengths. Eg quality of answers or libraries you easily find. The years long constant stream of deserialization vulnerabilities, like yesterday's Spring RCE, are also largely absent from other JVM languages.

watwut 5y ago

I am using it now because the team is using it, but cant figure out in which way it is supposed to be better then Eclipse. It looks somehow better, but it seems strictly inferior in terms of what it does for me.

self_awareness 5y ago
And what are the functions that you use that work better in Eclipse?
- teknopaul 5y ago
  Eclipse immediately tells you what is broken when you change an api. IntelliJ does not. You can't stop IntelliJ from saving work. I like to kick of a build, and work on some new stuff while it's going on without saving until the build completes. That workflow is impossible in IntelliJ. You have to down tools, for a long build with lots of tests that can make IntelliJ slower over all. IntelliJ generally more responsive for most work, but that's because it's not using Java's type system to find errors as you work, errors are deferred, which often means they take longer over all to fix.
  - ta988 5y ago
    It just takes two check boxes to uncheck to disable that in IntelliJ. I agree it is disturbing that it is a default at first. But it is at least configurable.
    - teknopaul 5y ago
      Which version? It wasn't possible last time I checked and Jetbrains had close-no-fix on various related bug reports.
      - ta988 5y ago
        Last EAP version but it was there at least since last year.
- watwut 5y ago
  Eclipse shows me all errors in whole project at once. This is biggest one. The hierarchy and callers hierarchy always work, I can rely on them way more then in Idea where they sometimes miss things. Much much better full text search. I can search through multiple projects. Not just root. Square selection.
kkjjkgjjgg 5y ago
It costs money, so it is a value statement about you as a developer. Either you are "worth it for your employer", or you are "worth it for yourself". (I personally still use Eclipse)
teknopaul 5y ago
I find both mysteriously stop working on a project for a while so I keep them both. Eclipse has far better refactoring. IntelliJ refactors text files that are not Java and can easily break stuff when eclipse refactors are always safe. IntelliJ updates text strings but it's not always correct in doing so, é. G. A comment that says "_don't_ use a.b.C" might get refactored. In eclipse you can often safley "code backwards" i.e. break an API and then fix all the red dots, usually with auto fix options. IntelliJ misses a lot of necessary fixes until you compile. That can add hours of work to a big change.
jbellis 5y ago
I'm very curious to hear what Eclipse does that IntelliJ does not match.
- teknopaul 5y ago
  Elipse keeps a complete Java representation of the source code in memory, (not the classes) that's why it can find compile errors before saving. This comes at the cost of lost of RAM, some projects are just too big for eclipse so IntelliJ is your only option. But that eclipse model can be used for lots of cool tricks, you have access to it in the plugin API, so for example you can enforce coding standards before even saving code.
  - nradov 5y ago
    I would argue that if a project can't fit into Eclipse with 32 GB RAM then perhaps the code base has become too large to manage and ought to be split into separate projects with dependencies.
    - teknopaul 5y ago
      In eclipse java code is generally already split into projects, in a workspace, you can close projects to save ram. When you can get it all in memory, you get the benefits of eclipse refactoring, when you can't you don't. Ability to write code that is safe to refactor is one of the great things about Java, so it's a shame if you can't benefit from that.
- jillesvangurp 5y ago
  Incremental and partial Java compilation. Partial compilation is the notion that partially compiled software is still usable and something you can debug or introspect on. The IDE compiles while you type, it will detect syntax problems and as soon as you fix them they go away. Error markers in intellij are nowhere near as fast and you can't trust their presence or absence to be correct either. Intellij does that a little bit of incremental compilation. They half integrated the eclipse Java compiler at some point but they never really made using it a thing. Most projects just hand off compilatio to Gradle or maven, which means you lose a lot of time waiting for that and dealing with various caches in intellij and gradle/maven getting out of sync with each other. The process for fixing that generally involves boiling the oceans and running the CPU at 400% for a few minutes. Eclipse compiles two orders of magnitudes faster when you have it properly setup. I'm not exaggerating. It's really good at this. Intellij users have never seen this level of performance. I've tried to explain it a few times to users that insisted they had intellij configured just right. The minimum execution for a unit test after a 1 character code change is the key benchmark for this. Run a test, change something trivial, run it again. If that takes more than half a second and has a noticeable delay, it's not fast. Eclipse user to be closer to 50-100ms. Even on a (now) ten year old laptop. With intellij, it's closer to 3-5 seconds. They have improved things over the years but it never got even close to that level of performance.

oauea 5y ago
Java is on thin ice? It's the most popular business language, for good reason. You seem to have some very odd opinions, but that's fine. Bit rude to call people other people their opinions a "vendetta", though.
- davidjfelix 5y ago
  The reason I'm being terse with you and perhaps a bit rude is that you started this reply thread by insulting my opinions for no reason and then continued to reply with what I believe to be both bad faith readings of my comments and naturally argumentative. I know HN values skepticism, but honestly it's tiresome. Anyways, here's my clarifying my previous comment. Please keep in mind that I fully expect you to read this in bad faith, so I've added sarcasm overtly. Java, for me, personally, in my opinion, is on thin ice. I personally, in my opinion, would never work at a "Java shop" because in my opinion, personally, it conveys a disregard for technical suitability and individuality and supports the idea that engineers should be expendable. I believe, in my opinion, personally, that Java is, as you say, "popular" because it's forced on many workplaces by management. I don't think, in my opinion, personally, that it's a "bad" language, but its heavy use is not proportional to how "good" it is. I don't think my willingness to respond but refusal to be berated by an internet stranger is rude, and yes, I believe you have a vendetta, just like I have a vendetta against Java. If you have to use it, fine -- the above will insulate you from the really terrible things java does, in my opinion, personally. My real advice is don't use java, but see how that's a bad faith response? That's why I kept it to myself.
  - MockObject 5y ago
    So Java isn't on thin ice if it's used heavily.
    - davidjfelix 5y ago
      What do you want to hear? That you're right? Communication is a two way street, try treating it like one. "To be on thin ice" is an expression which means in a precarious or risky situation, but is commonly used in reference to personal regard or favor. !!!!!!YOU'RE RIGHT!!!! (congratulations!) Java is not at risk of falling out of use - it's a very heavily used language with lots of job opportunities. Congratulations again on being technically correct. If that's all you wanted stop reading. I'm saying that writing, maintaining and deploying Java in a manner that is fast, pleasant, sustainable, performant and desirable for developers is already at risk, in my opinion. As a developer, Java is *not* the best solution and taking away the niceties listed puts Java in a place where it is at risk of being unsuitable for the task. This isn't solely a fault of Java, some of this is simply better solutions for problems existing around Java. Java moved quite slowly for a long time and solutions filled that gap. I understand a business' desire to have a uniform programming language that they can hire for, but these days languages look very similar and polyglotism isn't that hard to find. Choosing the right language for the task is an engineering decision just like preserving language uniformity is. I don't think either is wrong, but the more people try to make Java a place that is worse than it's competitors, the more I'll favor choosing a different right language over preserving uniformity. I hope this helps clarify what I saw to be an extremely benign opinion to voice.
Spooky23 5y ago
Java is the COBOL of the 21st century, in both the best and worst sense. Java stacks will be running major companies long after everyone posting in HN today is dead and gone.

jillesvangurp 5y ago

Yes. Perhaps to add to this, use a modern asynchronous IO framework. If you use Spring Boot, ignore some of the legacy stuff that still comes with it and make sure you use webflux with Kotlin co-routines. Also use Asynchronous IO for talking to your database, queues, etc. Kotlin makes all of this easy. Hibernate is something I tend to avoid for various reasons but apparently recent versions of that now also support asynchronous IO. And it is still very popular. If you feel more adventurous. Ktor is also quite nice and a lot more lightweight than spring. They have a pretty big 2.0 release coming up for that with a lot of nice improvements. Ktor is also a nice alternative for doing http clients. Kotlinx serialization is the way to for serialization; especially if you are interested in multiplatform. Spring supports that as well since a few releases. If you use Kotlin, stick with Gradle and use the kotlin scripting variety. Maven is very much a second class citizen in that ecosystem. It's supported (grudgingly) but not that actually that widely used. A lot of older Spring projects might still use it because they started out as maven/java projects and only later added Kotlin. However, if you start from scratch, just use gradle and take the path of the least amount of resistance. You'll have an easier time and essentially all of the Kotlin documentation assumes you use gradle. For things like kotlin multi-platform, maven is an afterthought. I'd be surprised it works at all actually for that.

matsemann 5y ago
I tried to keep my post very little opinionated, and just write what I've seen the last couple of years. While you have some good points in yours, it's not necessarily the best idea to go straight for these "hipper" things if one's trying to break into java dev. Then it's easier to start with the boring stuff everyone use, as that is what one most likely will encounter. As for Hibernate, I've seen a trend of using ORMs less and less. And if it's used, it's in a simple dao layer so that the rest of the application doesn't have to deal with how data is fetched.
heurisko 5y ago
I don't consider synchronous programming as being legacy. For many projects synchronous programming can work just fine, and it lowers complexity.
kaba0 5y ago
I really wouldn’t go the async way unless it was deemed absolutely necessary for maximal performance — it makes reasoning/debugging much harder with often not much gain. Also, if one can just wait a few years, loom will make many part of it obsolete - when blocking code will magically get non-blocking while it retains the readibility.
- WkndTriathlete 5y ago
  I find the big problem with async is the libraries, not necessarily the async piece itself. I looked at Webflux (Project Reactor)/RxJava/etc. years ago and discovered that the composable async components unexpectedly maintain state, and that's really the piece that makes it hard to reason about. I've since switched over to Scala + cats-effect. I found that to be a huge learning curve, but the payoff for me has been library support for easy-to-use and easy-to-understand concurrent and asynchronous programming. I cannot recommend it enough.
- jillesvangurp 5y ago
  I've had very few issues with that. Mostly the async code looks almost identical to the synchronous variant with Kotlin. There's a bit of a learning curve and it helps if you understand parallel and asynchronous programming a little. There is no magic with blocking vs. non blocking. Your IDE will tell you if you are doing it wrong. The fix is usually to have a co-routine context backed by a thread pool and schedule co-routines that block there. Loom won't make any of this obsolete. If anything, co-routines will probably be the most user friendly API to use Loom when it comes available. Loom is a pretty low level API and you probably should not use it directly and instead use something that uses that. Like Kotlin co-routines, which is designed as a high level API that can be backed by all sorts of asynchronous and parallel computing implementations/ Extension functions exist for webflux, rx-java, vert.x, thread pools and much more. Basically, it sits on top of these things. It also works on kotlin native, kotlin-js (in a browser and node-js) and in the JVM where the underlying platform of course provides very different implementations. For the end user, it works pretty much in the same way across these platforms. Loom will just be another low level backend for the co-routine API. It will likely give you some performance benefits if it's available and that's about it. Update the co-routine library, maybe fiddle a bit with your co-routine scope's and you'll be using Loom. I'd expect very little code changes would be needed when the time comes. Perhaps none at all actually (aside from bumping a version number).
icedchai 5y ago
I wouldn't bother with async unless there's a solid reason. Most Java libraries assume a standard, synchronous model and Java threads are relatively cheap these days. There's no point in going against the grain.

omgitsabird 5y ago

> 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?

winrid 5y ago
Because the code runs in a VM already, they are not concerned about isolating further. 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.
- omgitsabird 5y ago
  I guess I was implying that I don't view the benefits between the prior and the later as an onto mapping.
happymellon 5y ago
I think it means that they like to install software and manage servers rather than renting a container cluster to host your app.
exabrial 5y ago
Java apps have been "cloud ready" in a sense for about 20 years. JavaEE had a "WAR" or web archive file format that packaged an entire app up into a single file that could be deployed in an "Web Application Server". IBM wanted web servers to be mainframes, but for webapps. You could even deploy multiple apps in a single JVM, because the server would load each app in a separate classloader, meaning the apps were internally isolated from each other. The JVM even had an attempt at a cgroups like concept, called a Security Manager (that was abandoned, thank goodness), long before cgroups existed. Think WAR file = docker container. Now, a lot of complicated bits were inherited that didn't need to be there when they brought over the mainframe thinking into Java apps, but the WAR format was actually something kind of cool they got right. We in particular, take that WAR format, turn it into an executable, and we have a program that can execute on any hardware on any person's computer, with no pre-reqs except a JVM being installed. We test the _exact_ war file on a ARM RPI , developed on a Mac m1 or x86, and CI on a Linux x86. Alright what does this mean? Lets take a look at another language...say a PHP application.... which may require extension Unix utilities of certain versions installed on the host system. You may need a certain version of PCRE grep, a certain version of curl, etc. This theme carries over to multiple languages, your python or ruby implementation may not support the latest version of libressl, or it might not even support your ABI at all. Docker solves these problems gracefully, by providing a fully configured virtual operating system tuned for running exactly one app. The JVM... well doesn't need that, if written properly. Generally all the libs it uses are written in Java, they include all of their dependencies already, apps can be isolated with classloader boundaries (if that's your thing), you can download a single file and launch it if you use the "one-jar" technique. So yeah, Docker loses a lot of it's luster with Java. It's not that you _cant_ use it, but it you can solve all the problems it does otherwise. Long rambling explanation but there you go.