JarCastingJava bean support code
Common code for Java beans, used in my other projects. Having this code in a library cuts down on boilerplate.
Status of the project
Sonarqube
Release history
| Date | Version | Comment |
|---|---|---|
| <2021-04-18 Sun 22:47> | 1.1.2 | Add a “Bill of Materials” (BoM) |
| <2021-04-15 Thu 00:43> | 1.1.1 | Get common maven dependencies and maven plugin config from parent |
| <2021-04-11 Sun 21:43> | 1.1.0 | Built with karaf 4.3.0 and OSGi 7 |
| <2019-12-31 Tue 00:47> | 1.0.0 | Adds bean base class Immutable implementing hashCode() and equals() |
Overview of the project
Immutable
This is an OSGi bundle that contains the class Immutable which serves as a base class for immutable Java beans and provides the beans with implementations of hashCode() and equals().
The Object.hashCode() and Object.equals() methods must be overriden from their default Object implmentations in data objects, if those data objects are to work properly in maps and sets. However, writing hashCode() and equals() methods manually is boring. It consists of creating a lot of boilerplate code, and that boilerplate needs to have tests written if I don’t wish to have sonar complain about test coverage, increasing the code that has to be modified when the bean changes.
IDEs like eclipse and IntelliJ can create hashCode() and equals() methods, but the auto-generated code may need a little tinkering, and the tests needs to be handwritten, or your code coverage will become low enough for sonar to complain. And if the beans change the IDE can recreate the methods, but the tests still needs to be changed manually
The apache commons-lang3 HashCodeBuilder has methods to create hashCode() using reflection, but using reflections means there is a performance cost. However, since the beans used in my jackson/jersey REST APIs are invariably immutable, it is possible to create the hashCode() lazily and then cache it. And that’s what the Immutable bean base class found in this library does.
The equals() method also depends on the hashCode(), so it may not be entirely comparison proof, but for the first version I’m trying it out.
To use the latest version of the OSGi bundle in a maven project, or just use it as a plain JAR file, add the following dependencies (commons-lang3 is a provided dependency in the beans.immutable pom, so won’t become a transitive dependency and must be added explicitly to a project using beans.immutable, even if the project is just using beans.immutable as a plain JAR file):
<dependencies>
<dependency>
<groupId>no.priv.bang.beans</groupId>
<artifactId>beans.immutable</artifactId>
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.9</version>
</dependency>
</dependencies>
To use the latest version of the OSGi bundle in a maven project, building an OSGi bundle intended for use in apache karaf:
- Add a provided dependency to beans.immutable (to make things compile) and a test dependency to commons-lang3 (to prevent tests from failing in startup. If you already have a dependency to commons-lang3 you don’t need this test dependency):
<dependencies> <dependency> <groupId>no.priv.bang.beans</groupId> <artifactId>beans.immutable</artifactId> <version>1.1.2</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.9</version> <scope>test</scope> </dependency> </dependencies>
- Add a load of the feature repository containing beans.immutable and depend on the beans-immutable feature from your projects template feature.xml (src/main/feature/feature.xml):
<features> <repository>mvn:no.priv.bang.beans/beans/1.1.2/xml/features</repository> <feature name="my-feature"> <feature>beans-immutable</feature> </feature> </features>
License
This code is licensed under the Apache license v. 2. See the LICENSE file for details.