Ankit Garg

The stream package javadoc sums it up pretty well.

javadoc wrote:Consumable. The elements of a stream are only visited once during the life of a stream. Like an Iterator, a new stream must be generated to revisit the same elements of the source.

Alexandros Collie wrote:You misspelled superman in line 8.

That's a great catch

However even if you spell it correctly, the output won't change. The compiler changes String s2 = "Superman" + ""; to String s2 = "Superman"; as at compile time it knows the result of the concatenation. This happens for any String concatenation with literals. So if you wrote String s2 = "Super" + "man";, the compiler will change this to String s2 = "Superman";...

Check the java.lang.Object class which every class in Java inherits from (directly or indirectly), see what methods you see in there.

IMO 3rd option is the least confusing

Isn't this how lambda works, if you need an instance of an interface, and the interface is functional i.e. it only has one abstract method, then you can use any method with the same parameters and return type as an implementation of the interface using lambda. In this case the interface has more methods with default implementation, but for any method to be used as an implementation of the interface, you only need to worry about the abstract method in the interface.

To add to Salvin's answer, can you do this:

Carnivore c = TestClass::size;
In the same way do the lambda in all the other options qualify as implementation of Carnivore interface.

In the first case since you are concatenating two literal values, the compiler can do the concatenation and JVM will have the value in the pool. And since both the literal values are same, both string variables are pointing to the same value in the pool. In the second case since there is a variable involved, compiler cannot do the concatenation. At runtime JVM will do the concatenation and in that case the value doesn't go into the pool.

If the element should be at the first place in the array (which means it is smaller than all elements in the array) i.e. at index 0, you'll get -1 as result (as it can't return you -0 as there is no -0). If the element should be at the 1st index of the array, you'll get -2 and so on. So if the element should be at the last of the array i.e. it is greater than all the elements of the array, you'll get -(array.length + 1). Length of your array is 4, so you'll get -5 in that case. Since the element is greater than all the elements in the array, it should be placed at 5th index of the array which doesn't exist.

But why does not superString add new Object as the generic type says "? super String" and Object is super of String.

Are you still confused? If you are let me try another example

public void manipulateList(List<? super String> stringSuperList) {   stringSuperList.add("and"); // fine   stringSuperList.add(new Object());  // not fine }
Let's say I'm writing this API for anyone to call. The second call doesn't compile. Why? Because there is no guarantee that the List I'm passed can store Object. If the compiler allowed me to add Object to this List, it can break type safety. What if I wrote the following code to call this method:
List<String> strList = new ArrayList<>(); instance.manipulateList(strList); String str = strList.get(0); // I'll always get String from this list
If the  manipulateList method was allowed to add Object to stringSuperList, the above code will end up having an Object in a String list. An Object is-not-a String. If somehow I'm able to add Object to it, when I retrieve the element, I'll get ClassCastException. Generics is supposed to save you from ClassCastException, not let it happen.

Yay you found it

Why can't anyone have your copy? You can have it back whenever you need it

Miroslav Lehotsky wrote:I would just point out that you don't have to return different type of object, you are free to return the same type of object,

True, good catch.

The map method is used to convert a stream of one object to a different object. For example you can convert a stream of some object to stream of String by calling toString on the objects of the steam like this (there are other syntaxes of doing this, I'm just using one of them):
Stream<MyObject> objStream = ...; Stream<String> strStream = objStream.map(o -> o.toString());

Swapna latha wrote:I havenot understood clearly. As per Kathy Sierra and Bert Bates ocp book , ? extends IOException means anything that extends IOException , so we can have even an Exception right. Why Java is not allowing it ? Am i wrong in understanding the concept. Whats the use of Right hand side of the expression which has generic type of Exceptionn .

Your original question is  about ? super IOException, ? extends IOException is a similar case but not exactly the same. Let's look at both cases:

List<? super IOException> means the List can be of type IOException or its ancestors. Note here that List can actually be of type IOException as well. So if Java compiler allows you to add Exception to this list, it would break the type safety as you can see in the example below:
List<IOException> ioExceptionList = new ArrayList<IOException>(); List<? super IOException> list = ioExceptionList; list.add(new Exception());          // not allowed, but if it was allowed, the next line will be a problem IOException ioException = ioExceptionList.get(0); // if the above was allowed, this would throw ClassCastException                                                  // which would break type safety provided by Generics.
Now let's consider the ? extends IOException case. In this case, the List can be IOException or any of its descendants. If the List is actually of some sub-class of IOException, and compiler allows you to add IOException to the list, the following code will break:
List<FileNotFoundException> fileNotFoundExceptions = new ArrayList<FileNotFoundException>(); List<? extends IOException> list = fileNotFoundExceptions; list.add(new IOException());          // not allowed, but if it was allowed, the next line will be a problem FileNotFoundException fileNotFoundException = fileNotFoundExceptions.get(0); // if the above was allowed, this would throw ClassCastException                                                                             // which would break type safety provided by Generics.
Thus add operation is not allowed in either case. If you do a get operation however, you'll see different behavior. In case of ? super IOException, the List could actually be of type Object as well. But in case of ? extends IOException, you know that the elements in the List are compatible with IOException at least. So the get operation would work like this:
List<? super IOException> superList = ...; Object obj = superList.get(0);            // we don't know the type, so without a cast you can only get the value into an Object List<? extends IOException> subList = ...; IOException ioException = subList.get(0); // we know the type is compatible with IOException

Okay so there were two issues with the code, this is what the main method should be like:

   public static void main(String[] args) {        //case : 1        TestFrameWork<Object> tf2 = new TestFrameWork<Object>(23, "Superman");        for (String val : tf2.stringList()) {            System.out.println(val);        }        //case : 2        TestFrameWork tf4 = new TestFrameWork(23, "Darkseid");        for (String val : tf4.stringList()) {            System.out.println(val);        }    }
Now the reason the second loop doesn't compile is that since you are using the TestFrameWork class as a Raw type without the type argument, so the tf4 objects totally works without generics. And that means any method you call on this object will have its Type arguments stripped. So the compiler doesn't consider the stringList method to be returning a List<String> but rather just a List without any type which means it is a plain List of Object for the compiler. I did find it weird though, specially since the stringList method doesn't have anything to do with the type T of the TestFrameWork class. There is this rather detailed FAQ on Generics which might have the reason buried somewhere: http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html

Ng Sharma wrote:Thanks Ankit, nice explanation.

I was just building up on Campbell's insights, so thanks to him for the clarification that the field takes precedence

Maker interfaces are no longer that useful since the introduction of Annotations in Java. The maker interfaces like Serializable and Cloneable serve special purpose from advent of Java. But for any new API you are better off creating an annotation instead.

Campbell Ritchie wrote:As you say, it is a weird piece of code, but I have seen questions about something like that before.

On the certification exam?

I tried this code, and depending on the context compiler can tell whether you are referring to the field or the inner class, but as Campbell said the field takes precedence when there is ambiguity

X.Y.class // inner class
X.Y.getClass() // field
X.Y abc = null // inner class
X.Y = null // field
X.Y.Z = null // field i.e. the Z variable of C class is updated