TL;DR
„…The problem with boxing is that it is [ad-hoc] and expensive; extensive work has gone on under the hood to address both of these concerns“ — Brian Goetz, State of Valhalla, March 2020
That makes me suspect that those changes to the spec you refer to are preparing the language for the planned „Codes like a class, works like an int“ capabilities of L-World discussed in the above link.
„…Could anyone give me some explanation with examples?…“
The example in the 2016 bug report linked to in the comments (plus the 2013 one that one links to) gives the best example of #4 in your list. Based on those, here's an example of #5 in your list…
< I extends Integer > void soAns0( I intRef ) {
int intPrim;
long longPrim = /* (3) a widening primitive conversion */
intPrim = /* (2) an unboxing conversion */
intRef; /* (1) a widening reference */
}
„…If possible, please also explain its practical usage…“
The natural numbers are often referred to as „integers“. The Java Language Tutorial shows one practical usage of restricting the natural numbers to only be of type Integer…
public class NaturalNumber<T extends Integer> {
private T n;
public NaturalNumber(T n) { this.n = n; }
public boolean isEven() {
return n.intValue() % 2 == 0;
}
// …
}
There's also this example in the API documentation for RowFilter<M,I>…
…
public boolean include(Entry<? extends PersonModel, ? extends Integer> entry) {
…
Person person = personModel.getPerson(entry.getIdentifier());
…
}
…
Another use case where T extends Integer might be appropriate is if you want to explicitly forbid your class from being parameterized with any other type of Number AND explicitly forbid adding Integers into that parameterized type — by leveraging the Get/Put Principle.
Say you have some code that, given some number, will create that number of objects.
If you want to forbid bad actors from overwhelming your system by bombarding it with Long.MAX_VALUE number of DOS attempts, bounding <T extends Short> could be one way to limit the number of objects that would get created in any one method call.
„…What do these various existing programs look like? Are they java code?…“
A search on github for T extends Integer turns up eighty-thousand some hits.
„…What does interoperability with capture mean?…“
I defer the definitive explanation of capture conversion to the JLS itself.
„…and why is it important?…“
Capture conversion is important because of it's connection to type inference.
The notation ‹Integer <: α› in the JLS' section on type inference is more or less a formal way of expressing Integer extends Integer (what T extends Integer effectively means)…
…
From Arrays.asList(1, 2.0), we have the constraint formulas ‹1 → α› and ‹2.0 → > α›. Through reduction, these will become the constraint formulas ‹int → α› and
‹double → α›, and then ‹Integer <: α› and ‹Double <: α›.
…
Given that, it's not surprising that the JDK uses <T extends Integer> a lot for Generics/Type Inference related tests of the JDK itself.
Here's my absolute favorite use of <T extends Integer> in the wild.
Mostly though, I would bet those unboxing-/widening-related changes to the spec have more than a little to do with Valhalla.
final, I do not see the point of those two cases either. Those phrases, however, are repeated in § 5.3, § 5.5 and partially § 5.6. – Disciplinantfinalmakes importance here? – Mhopublic class MyBoolean extends Boolean { ... }, for example, it would be logical thatboolean bool = myBoolean;works. But since we cannot extend from the wrappers, I do not understand how we can get into a situation where we need to first widen the reference (from something that is a subtype of a wrapper) and then unbox. – DisciplinantInteger bigNumber = 10000000; Byte littleNumber = 5; long l = (bigNumber=littleNumber+2);would demonstrate both - widening followed by unboxing and widening followed by unboxing followed by a widening primitive conversion. However, this is OK for JDK 8 alike. Just tested. – Mho<T extends Integer>asints. – Prut<T extends Integer>(or more precisely<? extends Integer>) could easily be infered and not explicitly written by the developer, which can quite easily be constructed. – Sanity<T extends Integer>is obviously non-sensical (since the wrappers are final), but it's not in itself an invalid type signature. And type inferrence (which often happens when closures are applied) can often lead to types that look like that (you don't tend to see those type definitions, which is the whole point of type inference). Now if something was inferred to be of the typeT extends Integerthen it would be nice if you could use it as if it was just anint. This rule simply allows that. – SanityT extends Integerwithout an example. – FeleciafeledyList<? extends Integer>as if they were ints. So the change really took practical cases into account. But what is interoperability with capture? And what are the various existing code look like? Are they java code? – Feleciafeledy