I'd prefer it as a record as there is less boilerplate, but would there be issues?
IntelliJ is suggesting that I turn a basic Java class @Service like this:
@Service
public class LocationService {
private final PlaceRepository placeRepository;
@Autowired
public LocationService(PlaceRepository placeRepository) {
this.placeRepository = placeRepository;
}
public List<PlaceDto> findPlacesByRegionId(Long regionId){
return placeRepository.findByRegionId(regionId).stream().map(place -> new PlaceDto(place.getId(), place.getName())).toList();
}
}
into a Java record @Service like this:
@Service
public record LocationService(PlaceRepository placeRepository) {
public List<PlaceDto> findPlacesByRegionId(Long regionId) {
return placeRepository.findByRegionId(regionId).stream().map(place -> new PlaceDto(place.getId(), place.getName())).toList();
}
}
Let me quote Oracle guy:
JEP 395 says:
[Records] are classes that act as transparent carriers for immutable data.
So by creating a record you're telling the compiler, your colleagues, the whole wide world that this type is about data. More precisely, data that's (shallowly) immutable and transparently accessible. That's the core semantic - everything else follows from here.
If this semantic doesn't apply to the type you want to create, then you shouldn't create a record. If you do it anyways (maybe lured in by the promise of no boilerplate or because you think records are equivalent to @Data/@Value or data classes), you're muddying your design and chances are good that it will come back to bite you. So don't.
UPD.
I have spent a couple of minutes to figure out what was the root cause of your statement that "IntelliJ is suggesting that I turn a basic Java class @Service like this". And have found the following discussion: https://youtrack.jetbrains.com/issue/IDEA-252036
Thereby:
You could do that, but records have getters (well without get prefix). Which Service Layer shouldn't have. Your Service Facade exposes public methods which also are usually @Transactional, you don't want to mix them with methods that no one is going to use.
Also, records define equals() & hashCode() which aren't needed for Service classes either.
In the end the only common theme between Records and Services is that all fields are usually final and all of them are usually passed via constructor. This isn't much of commonality. So it sounds like a bad idea to use records for this.