Today I got this strange error when compiling with Maven:
"type parameters of TYPE cannot be determined; no unique maximal instance exists for type variable TYPE with upper bounds TYPE,java.lang.Object"
After googling around I found this solution described by Sarath Chandra.
Some weeks ago, I implemented several classes for the CQRS Meta Model. I found myself repeating the same code over and over again, as it was not possible to extend the same base class.
Damn… I wished Java had Mixins! After a short look a Qi4j, which seems a bit too heavy for my little use case, I remembered AspectJ’s Inter-type declarations. You can declare members (fields, methods, and constructors) that are owned by other types!
So here we go – Let’s define some behavior:
/**
* Something that has a comment.
*/
public interface Commentable {
public void setComment(String comment);
public String getComment();
}
Now we’re going to create an aspect that provides the default implementation for the above interface:
/**
* Implements the behavior of an object that has a comment assigned.
*/
public aspect CommentableAspect {
private String Commentable.comment;
public final String Commentable.getComment() {
return this.comment;
}
public final void Commentable.setComment(final String comment) {
this.comment = comment;
}
}
All you have to do now is to implement the interface:
/**
* Class with a comment field.
*/
public class TestClass implements Commentable {
// All methods are already implemented by
// simply adding the interface!
}
That’s it! All the necessary fields and methods are now added by AspectJ. You can now concentrate on composing behavior instead of thinking about a hierarchy of subclasses.
If you’d like to, it’s also possible to override the provided default methods (Caution: You’d have to remove the “final” from the aspect!) . I personally prefer the Design for Extension principle, and my methods are always abstract, final, or have an empty implementation.
Nice post: Managing unmanaged beans in CDI (A Java geek / Nicolas Fränkel’s Blog)
Sometimes, it’s nice to use strong typing instead of repeating the same checks all over the layers and tiers. The interesting thing is that making a class robust against misuse is very similar to using Java Bean Validation.
A classical approach may look like this:
public class User {
private static final Pattern PATTERN = Pattern.compile("[a-z][0-9a-z_\\-]*");
private String name;
public User(String name) {
super();
if (name == null) {
throw new IllegalArgumentException("name == null");
}
String trimmed = name.trim().toLowerCase();
if (trimmed.length() == 0) {
throw new IllegalArgumentException("length name == 0");
}
if (trimmed.length() < 3) {
throw new IllegalArgumentException("length name < 3");
}
if (trimmed.length() > 20) {
throw new IllegalArgumentException("length name > 20");
}
if (!PATTERN.matcher(trimmed).matches()) {
throw new IllegalArgumentException("name pattern violated");
}
this.name = trimmed;
}
}
Using Bean Validation, we could create a custom constraint instead:
@Size(min = 3, max = 20)
@Pattern(regexp = "[a-z][0-9a-z_\\-]*")
@Target({ ElementType.METHOD, ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = {})
@Documented
public @interface UserName {
String message() default "{org.fuin.blog.UserName.message}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
The User class now looks much better:
public class User {
@NotNull
@UserName
private String name;
public User(String name) {
super();
this.name = name;
}
}
But now, the object has lost the ability to protect itself against misuse. It’s no longer a robust object. Maybe someone uses a validator to check if the object is valid; maybe not. In any case, it’s always possible to create invalid objects of this kind.
How about combining both techniques?
Let’s rename the UserName annotation into UserNameStr because it actually works on a string, and this way, we can also avoid a name clash with a new strong type we will create soon:
@Size(min = 3, max = 20)
@Pattern(regexp = "[a-z][0-9a-z_\\-]*")
@Target({ ElementType.METHOD, ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = {})
@Documented
public @interface UserNameStr {
String message() default "{org.fuin.blog.UserNameStr.message}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
Next, we create a base type for all such String based on strong typing:
public abstract class AbstractStringBasedType<T extends AbstractStringBasedType<T>> implements Comparable<T>, Serializable {
private static final long serialVersionUID = 0L;
private static final Validator VALIDATOR;
static {
VALIDATOR = Validation.buildDefaultValidatorFactory().getValidator();
}
public final int hashCode() {
return nullSafeToString().hashCode();
}
public final boolean equals(final Object obj) {
if (this == obj) {
return true;
}
if (obj == null) {
return false;
}
if (getClass() != obj.getClass()) {
return false;
}
final T other = (T) obj;
return nullSafeToString().equals(other.nullSafeToString());
}
public final int compareTo(final T other) {
return this.nullSafeToString().compareTo(other.nullSafeToString());
}
public final int length() {
return nullSafeToString().length();
}
protected final void requireValid(final T value) {
final Set<ConstraintViolation<T>> constraintViolations = VALIDATOR.validate(value);
if (constraintViolations.size() > 0) {
final StringBuffer sb = new StringBuffer();
for (final ConstraintViolation<T> constraintViolation : constraintViolations) {
if (sb.length() > 0) {
sb.append(", ");
}
sb.append("[" + constraintViolation.getPropertyPath() + "] "
+ constraintViolation.getMessage() + " {"
+ constraintViolation.getInvalidValue() + "}");
}
throw new IllegalArgumentException(sb.toString());
}
}
private String nullSafeToString() {
final String str = toString();
if (str == null) {
return "null";
}
return str;
}
public abstract String toString();
}
The refactored UserName class now uses the Bean Validation API to perform a constraint check at the end of the constructor, which means one is no longer able to create invalid objects:
public final class UserName extends AbstractStringBasedType<UserName> {
private static final long serialVersionUID = 0L;
@NotNull
@UserNameStr
private final String userName;
public UserName(final String userName) {
super();
this.userName = userName;
// Always the last line in the constructor!
requireValid(this);
}
public String toString() {
return userName;
}
}
The refactored User class is now even simpler and contains only a @NotNull annotation on the name property:
public class User {
// Only null check here, because all other
// checks are done by user name itself
@NotNull
private UserName name;
public User(UserName name) {
super();
this.name = name;
}
}
Here is a simple example using the UserName type:
public class Example {
public static void main(String[] args) {
Locale.setDefault(Locale.ENGLISH);
try {
new UserName(null);
} catch (IllegalArgumentException ex) {
// [userName] may not be null {null}
}
try {
new UserName("");
} catch (IllegalArgumentException ex) {
// [userName] must match "[a-z][0-9a-z_\-]*" {},
// [userName] size must be between 3 and 20 {}
}
try {
new UserName("_a1");
} catch (IllegalArgumentException ex) {
// [userName] must match "[a-z][0-9a-z_\-]*" {_a1}
}
// Valid name
System.out.println(new UserName("john-2_a"));
}
}
If we don’t want to use the strong typing, it’s easy to use only annotations. This ability is helpful especially where you have to deal with non-Java clients. In these situations, a DTO may contain only a simple annotated String:
public class UserDTO implements Serializable {
private static final long serialVersionUID = 1L;
@NotNull
@UserNameStr
private String name;
public UserDTO(String name) {
super();
this.name = name;
}
}
Now strong types and Bean Validation can live in peaceful coexistence within your application. It’s a good idea to check if your GUI controls support such JS303 enhanced strong types before you start using it. Otherwise, you may lose the ability to validate upfront on the client (e.g. checking input length based on the @Size annotation).
I was recently forced to update my Eclipse installation to version 3.7 (Indigo). After opening some old projects, I got the following error message:
Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:build-helper-maven-plugin:1.5:add-source (execution: add-source, phase: generate-sources) ... Maven Project Build Lifecycle Mapping Problem
The “build-helper-maven-plugin” simply adds a second source folder:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/src-gen/main/java</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
However, with Indigo and M2Eclipse, the source folder was no longer added, and I got compile errors all over the place…
It took me some time to figure out the right solution:
Just install the “M2Extras / buildhelper” plugin!
You can download it here (Eclipse Update Site):
https://repository.sonatype.org/content/repositories/forge-sites/m2e-extras/0.14.0/N/0.14.0.201109282148/
(The exact directory may vary depending on you exact Eclipse version and the latest available M2Extras release)
Great news: We got Greg Young the inventor of “Command Query Separation” (CQRS) for a 3-day course in Hamburg!
Details and registration: http://www.fuin.org/course.html
In development teams, there is often discussion about using the @Ignore tag for failing tests.
In particular, developers who are very enthusiastic about writing unit tests often tend to be very dogmatic about it. They argue, “A test should never be ignored! It’s better to have the build server on Yellow if tests fail. That way we always have an overview of our problems and are forced to fix them!”
What might sound good at first is not a good idea, at least when it comes to large development teams.
If you have several commits from multiple developers and maybe even additional deliveries from different branches to the main development line, the build will definitely break from time to time. How long does it take to fix such an error? Sometimes it may be easy, but in some cases, it may take days to fix a broken test. Now let’s assume that we have implemented the rule that you should never ignore a test. This means that the build may stay Yellow for a long time.
If another developer now updates his workspace with the latest version from the trunk and runs the unit tests locally, he will see failing tests even if he didn’t make any mistakes! That’s pretty bad itself. But he then checks the build server and, after some time looking around, he realizes it wasn’t his fault, as the server is already in the Yellow state. Should he commit now? If he does, he will receive endless emails from the build server about the broken build state that he didn’t cause. If not, his work and maybe the work of others will be blocked until the test is fixed. In a typical, pretty hectic IT project, with it’s almost impossible to meet deadlines, this is not really an option.
What is the solution?
Don’t get me wrong: all failing unit tests should be fixed as fast as possible! But my failure when committing a change should never constrain other team members from doing their work.
I always liked the Joda Time library. Hopefully it’s successor the JSR-310 will be included in Java 8.
The refererence implementation for the JSR-310 is the ThreeTen project that aims to provide a modern date and time library for Java and includes many of the lessons learned in the Joda-Time project.
Take a look at it!
Have you come across similar conversations in the context of large software projects?
Developer: I need an icon for a button.
Boss: You have MS-Paint on your computer. Why don’t you draw it yourself?
Developer: No… I am not a graphic designer… Why don’t we purchase the icons?
Boss: Hmm…We have got an intern, haven’t we? He can do it!
Developer: But he is no graphic designer either… And there are great low-cost icon libraries available to download.
Boss: I wouldn’t know how to book that… The intern will do it!
Sometimes I wonder what makes large companies tick…They spend millions on software and skimp on a few hundred dollars for nice graphics. Unfortunately, the completed applications often look as if an intern has designed the icons.
A leading supplier of icons offers his entire catalogue (approx. 250 sets with around 850,000 icons) for 399 USD. Commissions for individual icons in addition to an existing set cost approx. 50-75 USD per icon. In return you will get designs which are visually pleasing to the end user who interacts with the finished piece of software.
Anyone who allows his developers or interns to design icons, must be crazy.
I recently stumbled across an older article from Greg Young about something called the Specification Pattern. I haven’t heard about it before but the problem sounds familiar to me as I already implemented something similar.
Digging deeper I found an interesting paper from Eric Evans and Martin Fowler explaining the idea in depth: Specifications.
There is also a small Java implementation of the pattern available at Google Code that unforunately seems to be inactive since 2008.
A Java Developer's Life 