I play with records and found something that doesn’t look logical to me: Record: Code: However, if I do: Is that expected? Because RecordComponent implements AnnotatedElement, so I thought RecordComponent should have info about annotations. Are my expectations wrong? Answer This depends on the specified permitted targets of the annotation. The record component has an associated constructor parameter, field, accessor
Tag: java-record
Using Java records as JPA embeddables
I want to use Java records as embeddable objects with JPA. For example I want to wrap the ID in a record to make it typesafe: But If I try to persist it with Hibernate 5.4.32 I get the following error: So it looks like Hibernate would treat the record Id like an entity, although it is an @Embeddable. The
Java record serialization and repeated calls to canonical constructor
In this post about serializable records it is stated that Deserialization creates a new record object by invoking a record class’s canonical constructor, passing values deserialized from the stream as arguments to the canonical constructor. This is secure because it means the record class can validate the values before assigning them to fields, just like when an ordinary Java program
What annotation targets are applicable to Java records?
I have an annotation used for methods or fields defined like this: I wanted to prevent users from using this on a record since it wouldn’t make sense for this annotation to be used in that context. It seems doing this should not compile since I don’t specify ElementType.PARAMETER as a valid @Target. The following compiles fine though: But this
Why can’t enum and record be combined?
Recently I was just creating another enum type. I took advantage of the fact that in Java, an enum is a special type of class (and not a named integer constant, like in C#). I made it with two fields, an all-arg constructor and getters for both fields. This is an example: Then I thought that Java 14’s record keyword
Java records with nullable components
I really like the addition of records in Java 14, at least as a preview feature, as it helps to reduce my need to use lombok for simple, immutable “data holders”. But I’m having an issue with the implementation of nullable components. I’m trying to avoid returning null in my codebase to indicate that a value might not be present.
Lombok getter/setter vs Java 14 record
I love project Lombok but in these days I’m reading and trying some of the new features of java 14. Inside the new capability, there is the record keyword that allows creating a class with already built-in the following functionality: constructor, private final fields, accessors, equals/hashCode, getters, toString methods. Now my question is: is better to rely on the feature
Java 14 records and arrays
Given the following code: It seems, obviously, that array’s toString, equals methods are used (instead of static methods, Arrays::equals,Arrays::deepEquals or Array::toString). So I guess Java 14 Records (JEP 359) don’t work too well with arrays, the respective methods have to be generated with an IDE (which at least in IntelliJ, by default generates “useful” methods, i.e. they use the static