43. Xlinting default constructors
We know that a Java class with no explicit constructor gets automatically an “invisible” default constructor for setting default values of the instance variables. The following House class falls in this scenario:
public class House {
private String location;
private float price;
…
}
If this is exactly what we wanted then it is no problem. But, if we are concerned about the fact that the default constructors are exposed by classes to publicly exported packages then we have to consider using JDK 16+.JDK 16+ added dedicated lint meant to warn us about the classes that have default constructors. In order to take advantage of this lint, we have to follow two steps:
export the package containing that class
compile with -Xlint:missing-explicit-ctor (or -Xlint, -Xlint:all)
In our case, we export in module-info the package modern.challenge as follows:
module P43_XlintDefaultConstructor {
exports modern.challenge;
}
Once you compile the code with -Xlint:missing-explicit-ctor you’ll see a warning like in the following figure:
Figure 2.30 – The warning produced by -Xlint:missing-explicit-ctor
Now, you can easily find out what classes have default constructors.
44. Working with the receiver parameter
Starting with JDK 8, we can enrich any of our instance methods with the optional receiver parameter. This is a purely syntactic parameter of enclosing type exposed via the this keyword. The following two snippets of code are identical:
public class Truck {
public void revision1(Truck this) {
Truck thisTruck = this;
System.out.println(“Truck: ” + thisTruck);
}
public void revision2() {
Truck thisTruck = this;
System.out.println(“Truck: ” + thisTruck);
}
}
Do not conclude that revision2() is an overloading of revision1() or vice-versa. Both methods have the same output, the same signature, and produce the same bytecode.The receiver parameter can be used in inner classes as well. Here is an example:
public class PaymentService {
class InvoiceCalculation {
final PaymentService paymentService;
InvoiceCalculation(PaymentService PaymentService.this) {
paymentService = PaymentService.this;
}
}
}
Ok, but why use the receiver parameter? Well, JDK 8 introduced the so-called type annotations which are basically exactly as the name suggests, annotations that can be applied to types. In this context, the receiver parameter was added for annotating the type of object for which the method is called. Check out the following code:
@Target(ElementType.TYPE_USE)
public @interface ValidAddress {}
public String getAddress(@ValidAddress Person this) { … }
Or, check this more elaborated example:
public class Parcel {
public void order(@New Parcel this) {…}
public void shipping(@Ordered Parcel this) {…}
public void deliver(@Shipped Parcel this) {…}
public void cashit(@Delivered Parcel this) {…}
public void done(@Cashed Parcel this) {…}
}
Every client of a Parcel must call these methods in a precise sequence drawn via type annotations and receiver parameters. In other words, an order can be placed only if it is a new order, it can be shipped only if the order was placed, it can be delivered only if it was shipped, it can be paid only if it was delivered, and it can be closed only if it was paid.At this moment, this strict sequence is pointed out only by these hypothetical annotations. But, this is the right road to implement further a static analysis tool that will understand the meaning of these annotations and trigger warnings every time a client of Parcel doesn’t follow this precise sequence.