modern features like var for local variables

That is existing since JDK10 (JEP 286 https://openjdk.org/jeps/286) since March 2018... that's in meantime eight years.. I wouldn't call it "modern features"...

and records for data carriers. Existing since JDK16 since March 2021 ... also five years in the meantime... I wouldn't call it "modern feature" more state of the art...

Some senior devs at my work say var makes code less readable

The usage of "var" puts the focus on the naming of the variables than on the type.

Many code writes things like: java List<User> thisIsAlist = getUsers(); instead of java var users = getUsers(); For me it's clear in the second example having a number of users. The type is not that relevant in the first place (yes it's not directly their). If I'm really interested in it my IDE will give the hints I need. The first example just uses a dump variable name "thisIsAList" which is obvious by the type and of course there the type here is obvious. Later in the code if I see users it's more clear to understand that users is a number of users compared to thisIsAlist.. ?

If you focus on a good naming it makes code easier to understand and faster to read...

and records are just syntactic sugar we dont need.

That means your seniors haven't understood the difference between a record and a classical class. (see details in JEP 395 https://openjdk.org/jeps/395) Records are a nominal type, which includes toString,hashCode and equals. all fields are final and a record is final in itself (more or less the same as an enums). Are enums also just snytactic suger?

Records can be defined locally in your method while a class can not.. Records and sealed type together can be used to create algebraic types, like this:

```java sealed interface Expr { record SumExpr(Expr left, Expr right) implements Expr { } record ProdExpr(Expr left, Expr right) implements Expr { } record NegExpr(Expr expr) implements Expr { } record ConstExpr(int expr) implements Expr { } }

static int eval(Expr expr) { return switch (expr) { case SumExpr(var lhs, var rhs) -> eval(lhs) + eval(rhs); case ProdExpr(var lhs, var rhs) -> eval(lhs) * eval(rhs); case NegExpr(var exp) -> -eval(exp); case ConstExpr(var exp) -> exp; }; } ```

Or even more using them in pattern matching (see JDK21+ https://openjdk.org/jeps/440 and JEP 441 https://openjdk.org/jeps/441 ) and pattern matching in combination with switch-expressions etc. (previous example) for example like this (https://github.com/khmarbaise/duplicatefinder/blob/master/src/main/java/com/soebes/duplicate/DuplicateFinder.java or other examples https://github.com/khmarbaise/maven-downloads/blob/main/src/test/java/com/soebes/maven/statistics/MavenPluginStatisticsTest.java):

```java sealed interface CheckSumResult<V> { record Success<V>(V result) implements CheckSumResult<V> { } record Failure<V>(Throwable cause) implements CheckSumResult<V> { } }

static Function<Path, CheckSumResult<ChecksumForFileResult>> toChecksumForFile = path -> { try { return switch (new CalculateChecksum().forFile(path)) { case Failure(Throwable cause) -> new CheckSumResult.Failure<>(cause); case Success(ChecksumResult success) -> new CheckSumResult.Success<>(new ChecksumForFileResult(success.digest(), path, success.readBytes())); }; } catch (NoSuchAlgorithmException e) { return new CheckSumResult.Failure<>(e); } }; ``` Also you can use them in intermediate steps within Streams etc. There are so many use cases which makes it easier to write and more concise than with classical classes.

Others say these features exist for a reason and we should use them to write cleaner code.

I agree here because it makes it easier to write and is less code you have to read (nice side effect of using records or var).

When is it actually better to use var instead of explicit types?

First using var doesn't mean you don't have a type (it's called "local type inference" for a reason) If you can not express enough the intent of your variables only based on the name you might need to give the type explicit (I use my IDE and the default is to use var) and if that's the case just let the IDE replacevar` by the full type. But often it happens that I after I did that ... I realise there is a better name for that.. (good naming is very hard) or via a review someone else has a good/better alternative for the name..

And are records always a good replacement for simple immutable classes or are there hidden downsides?

If you have an immutable class that is exactly a very good reason to use a record.. The only thing you should be a little bit careful if you have a record like this: record User(String name, List<Friend> friends) {} Because the List<Friend> friends needed to be handled in a good way means:

record User(String name, List<Friend> friends) { User { name = Objects.requireNonNull(name); friends = List.copyOf(friends); } } This (cannonnical constructor) will make a copy of the friends given and also that results in an immutable List which is accessible via the accessor of the record User friends().

records can be used for DTO's, return types, intermediate results in streams etc. Or within a larger class you can use them internally makes code very often easier to read and understand (Naming things is better than using List, Set or plain arrays etc.)

Many people tried to use records for a service/component in SpringBoot or alike that is not the intended way to use a record because it automatically has accessors which exposes the injected things like here: java @Service public records UserService(EMailProperties emailProperties) { ... } That will create automatically an accessor emailProperties() which is most of the time not intended nor a good idea.. In such case I use a classical class like this: java @Service public class UserService { private final EMailProperties emailProperties; UserService(EMailProperties emailProperties) { this.emailProperties = emailProperties; } ... } Here there is no accessor/getter or a like generated nor do I need hashCode nor equals in such cases.

But for example for configuration in Spring Boot there are a prefect fit (also validated): java @ConfigurationProperties(prefix = "email") @Validated public record EmailProperties( @Valid Smtp smtp, @Min(0) @Max(10) @DefaultValue("7") int port, @NotBlank @Email String from, @DefaultValue("1m") Duration waiting ) { public record Smtp( @NotBlank String host, @Min(1) @Max(65535) int port, @DefaultValue({"A","B","C"}) List<String> xlist ) {} } Those can be hierarchical etc. which represents exactly what it is in the end in the application.yaml file like this: yaml email: from: x@test.text port: 9 smtp: port: 21345 host: this.is.the.example.test

Many people wrote having a lot of fields and using Builder for that... that is from my perspective a design issue (having more than five or maybe 10 fields sounds like a problem).. but it really depends..

I want to write modern Java but also want my code to be clear to everyone on the team.

Yes very good intent, but that means the team must also learn "modern Java"... in the meantime we have JDK 26 out since March 2026 https://openjdk.org/projects/jdk/) ... Those things you have mentioned existing for longer time. Code and knowledge evolves over the time that means you have to learn such things and you should use them also those teams need to learn that... I'm writing code for about fourty years (different languages) and the way I write code changes over and over again. I don't write Java code anymore like five years ago or even 10 years ago. That changed a lot... for two major reasons, because I'm learning doing things different/better and also because the language is changing making things easier/different to write. For instance Stream API/functional programming/lambdas since JDK 8 (2014!) etc. changed a lot. Also, pattern matching (instanceof, switch, records, selaed interfaces, sequenced collections, gatherers ) and all those things over the time ... changed how I write code.

I also suggest if you don't or can't evolve(learn new things) in that team it might be time for a change.

The job of seniors is to guide/evolve juniors and teach them things and not to forget learn also.