Ira Go wrote:
Integer is the lower bound - it is at the bottom of allowed types. <? super Number> wildcard bound is a subset of <? super Integer>. Maybe that is why <? super Number> is called a subtype of <? super Integer>
List<? super Number> is a subtype of List<? super Integer>
Mark Liu wrote:As a result, they can understand human language,
Ron McLeod wrote:Collections#addAll does not return an updated collection; it returns a boolean indicating if the collection was changed.
Given the following code that appears inside a method:
var values = new ArrayList<String>();
//INSERT CODE HERE
What can be inserted at the given location without causing any compilation error?
values.sort( (a, b) -> a.compareTo(b) ); values.forEach( System.out::println );
java: boolean cannot be dereferenced
Stephan van Hulst wrote:
Calling the method m1() on an object of type C will always call C.m1(). It doesn't matter that the reference that points to the object is of type A, the referenced object is still an object of type C. Casting the reference to a different type also doesn't make a difference. The object that the reference points to remains of type C.
This is the entire point of polymorphism: the behavior of an object is always determined by the actual type of the object at runtime, no matter the type of the reference that point to it.
Paul Clapham wrote:
And the code is an example of trying to access class A's m1(), which fails. Casting "this" to type A doesn't make it an object of type A, only a reference of type A. We know that in polymorphism it's the type of the object that determines which version of the method is called.
You cannot access class A's m1() from class C for the same object ( i.e. this).
...
at enthuware.inheritance.C.m1(Try2.java:22)
at enthuware.inheritance.C.m1(Try2.java:22)
at enthuware.inheritance.C.m1(Try2.java:22)
at enthuware.inheritance.C.m1(Try2.java:22)
at enthuware.inheritance.C.m1(Try2.java:22)
at enthuware.inheritance.C.m1(Try2.java:22)
at enthuware.inheritance.C.m1(Try2.java:22)
Process finished with exit code 1
Mike Simmons wrote:
That call to k++ is also protected by the lock, even though the doAnotherProtected() method called unlock on the same lock. Basically, a reentrant lock counts how many times it has been locked, and how many times it has been unlocked. And it only really unlocks when the number of unlock calls is equal to the number of lock calls. So you can have an arbitrary number of nested lock / unlock pairs, and the lock will not be released until the first, outermost pair of lock/unlock calls is finally exited.
thanksStephan van Hulst wrote:That is correct.
Stephan van Hulst wrote:A critical section that is protected by a reentrant lock can be reentered by the same thread.
This includes entering a different critical section that is protected by the same lock:
Campbell Ritchie wrote:Please avoid abbreviations like “ctor” ...
IG has told you,
Ira Go wrote:I found it confusing too.
The first line means the call to another constructor. So whatever needs to be done to the parameters, it must happen when the other constructor is called. The chain of constructors will end up with the canonical constructor and the record's data will be set final at that point. When you return from the call to the other constructor, the fields will be set and will be final/immutable. So you can't do anything after the call to that constructor which happened on the first line.