We Keep Coding

<E> and <Object> differences and usage

Can someone explain me what are the differences by using E or Object for example in a class for Lists, and their singular usage and definition.
I have to use them in LinkedLists to implement methods.

Assuming that E comes from element, i would consider using generics in Collections when the method that compiles says that it took an array of a certain type, and returns an array of the same type.
On the other hand you can't mix oranges and apples. You would be able to add an Object to your String list if you could pass a string list to a method that expects object lists. (And not all objects are strings)

The syntax you've written as <E> refers to Generics.
Generics provide a way to re-use the same code generalized for different data types while still maintaining strict type checks at compile time. For example, as you mentioned, If you'd use a data structure handling elements of type Object, you wouldn't have type safety when adding or getting its elements because any class instance could be passed and retrieved from it. This would lead to error-prone code where elements retrieved from your data structure should be cast first to the expected data type in order to be used or in the worst scenario not being of the right type and knowing this only at run-time with no way to prevent it.
Because of this, Generics aid the developer allowing him/her to establish for each different situation the generic Type Parameter with a specific Type Argument (a non-primitive type). This not only provides much more flexibility and re-usability of your code, but once you've established that a generic Type Parameter E stands for a specific data type (Integer, String or other), then the compiler will make sure that every operation that your object will perform with the Type Parameter E will be compliant with the specific Type Argument you've put in place of E.
public class Test {
public static void main(String[] args) {
//Here I can add mixed non-primitive types because they're also instances of Object and therefor compliant to the expected type
List listObj = new ArrayList();
listObj.add(Integer.valueOf(5));
listObj.add("Hello");
listObj.add(Double.valueOf(3.77));
//Here I can't retrieve the elements with their right type even though I know I've placed an Integer, a String and a Double in its first, second and third position
Integer i1 = listObj.get(0);
String s1 = listObj.get(1);
Double d1 = listObj.get(2);
//Here I'm defining a generic list working only with Integer (for this specific instance)
List<Integer> listGenInt = new ArrayList<>();
listGenInt.add(Integer.valueOf(5));
//If I try to add any other type but Integer I'd get an error at compile time
listGenInt.add("Hello");
listGenInt.add(Double.valueOf(3.77));
//Here I can only expect to retrieve elements of the data type I've established for this object during its declaration (Integer)
Integer i2 = listGenInt.get(0);
//Here I'd get an error If I'd try read its elements with any data type but Integer
String s2 = listGenInt.get(1);
Double d2 = listGenInt.get(2);
//Here I'm defining a generic list working only with String (for this specific instance)
List<String> listGenStr = new ArrayList<>();
listGenStr.add("Hello");
//If I try to add any other type but String I'd get an error at compile time
listGenStr.add(Integer.valueOf(5));
listGenStr.add(Double.valueOf(3.77));
//Here I can only expect to retrieve elements of the data type I've established for this object during its declaration (String)
String s3 = listGenStr.get(1);
//Here I'd get an error If I'd try read its elements with any data type but String
Integer i3 = listGenStr.get(0);
Double d3 = listGenStr.get(2);
}
}
Here, there is also a link with examples and further explanations from the official tutorials by Oracle.
https://docs.oracle.com/javase/tutorial/extra/generics/intro.html

Understanding generics in Java

Can someone explain to me what this code is doing, I am new to java.
Queue <TreeNode> queue = new LinkedList<TreeNode>();
I believe this code creates a Queue with the variable name queue that is of type TreeNode, what does the right side mean? Is it assigning the Queue to be a Linked List of type TreeNode?

Class java.util.Queue uses type parameters to assure that you won't add type other than it was created with.
If you create Queue like:
Queue <TreeNode> queue = new LinkedList<TreeNode>();
It means queue can store only TreeNode objects. This is used for type checking in methods add,offer,remove,poll.

Yes to understand this you must have at least little understanding of generics in java. The generics are very important feature of java and java collection framework use this feature in full form. Let me describe your statement given below.
Queue <TreeNode> queue = new LinkedList<TreeNode>();
Here First thing to be notice is that almost all collection classes and interface are generic in nature. That means they can store any type of data in them. See the below example.
List list = new ArrayList();
String sObj = "stringObj";
Integer iObj = 1;
MainTest classObj = new MainTest();
list.add(sObj); //Storing string
list.add(iObj); // Stroing int
list.add(classObj); //Storing class object
Here you can see that i have created a ArrayList and referenced it through a List reference variable. Here you can notice this i have not metioned any class here so by default it will store all object types of objects. Now if we come to your code that means you are restricting the collection to store only one type of objects which is TreeaNode .So that any other type of object will be added in this collection any more. In you statement in left side you are Creating a reference variable with name queue whose data type is Queue of TreeNode while on right side you are assigning a object of LinkedList which can store only TreeNode objects int to you queue reference variable.That means you queue will not be allowed to add any object in it excluding TreeNode. This assignment is possible both classes Queue and LinkedList implements Collection interface.

The link below describes what a generic is in Java and why they are used.
https://docs.oracle.com/javase/tutorial/java/generics/why.html
By Using generics we make sure the type safety of our objects.
In your question
Queue <TreeNode> queue = new LinkedList<TreeNode>();
you have created queue with generic type "TreeNode". So it'll allow only those objects which will instanceOf "TreeNode" class.

A Generic allows you to specify what type of reference a DataStructure will store. In your example the List will variables of type TreeNode.
But you can store any type, including your own user defined types such as classes.

Java 2D Int Arraylist

I dont quite understand what is the problem with the second declaration.
// Compiles fine
ArrayList<ArrayList<String>> array = new ArrayList<ArrayList<String>>();
// error (Unexpected type, expected -reference ,found :int)
ArrayList<ArrayList<int>> intarray = new ArrayList<ArrayList<int>>();

ArrayList is an implementation of List<T>, your problem is that you are trying to create an arraylist of int, its impossible since int is not an object. using Integer will solve your problem.
ArrayList<ArrayList<Integer>> intarray = new ArrayList<ArrayList<Integer>>();

The way generics work is simple. The header of List looks a little like this:
public interface List<T>
Where T is some Object. However, int is not a subclass of Object. It is a primitive. So how do we get around this? We use Integer. Integer is the wrapper class for int. This allows us to use int values in a List, because when we add them, they get auto boxed into Integer.
Primitive types are actually scheduled for deprecation in Java 10. Taken from Wikipedia:
There is speculation of removing primitive data types, as well as moving towards 64-bit addressable arrays to support large data sets somewhere around 2018.
Just a Note on your Code
In Java, the convention is to have the declaration using the most generic type and the definition using the most specific concrete class. For example:
List myList;
// List is the interface type. This is as generic as we can go realistically.
myList = new ArrayList();
// This is a specific, concrete type.
This means that if you want to use another type of List, you won't need to change much of your code. You can just swap out the implementation.
Extra Reading
Read about Wrapper Classes.
Read about Auto Boxing and Unboxing.
Read about Primitive Types.

You can only make List of Objects. int is a primitive type.
Try use:
ArrayList<ArrayList<Integer>> intarray = new ArrayList<ArrayList<Integer>>();

You must create an ArrayList<Integer> not an ArrayList<int>
A class(Arraylist in your case) can be a type of a CLASS (Integer)

ArrayList does not except primitive types as an argument. It only accepts Object types you should use:
ArrayList<ArrayList<Integer>> intArray = new ArrayList<ArrayList<Integer>>();

ArrayList Generic without Type

recently I read a piece of code which seems weird to me. As we know, we need to initialize the generic type in collections when we need to use them. Also, we know Collections can contain Collections as their elements.
The code:
public class Solution {
public static void main(String args[]) {
ArrayList res = returnlist();
System.out.print(res.get(0));
}
public static ArrayList<ArrayList<Integer>> returnlist() {
ArrayList result = new ArrayList();
ArrayList<Integer> content = new ArrayList<Integer>();
content.add(1);
result.add(content);
return result;
}}
My question is
why can we use ArrayList result = new ArrayList(); to create an object, since we have not gave the collection the actual type of element.
why can we use result.add(content); to add a collection to a collection with collection "result" is just a plain collection. We have not defined it as a ArrayList of ArrayList

Java generic collections are not stored with a type to ensure backwards compatibility with pre J2SE 5.0. Type information is removed when added to a generic collection. This is called Type Erasure.
This means that a generic collection can be assigned to a non generic reference and objects in a generic typed collection can be placed in an non generic, nontyped collection.
All Java generics really does is make sure you can't add the wrong type to a generic list and saves you from doing an explicit cast on retrieval; even though it is still done implicitly.
Further to this
the Java section of this answer goes a little deeper into what I just said
this article also covers basically what you were asking in a more complete way
other things to watch out for with Type Erasure

Just adding up to provide summarized answer
Old way :
(A) ArrayList result = new ArrayList();
will create an Arraylist to hold "Object"
New Way :
ArrayList<Integer> content = new ArrayList<Integer>();
this represents an Arraylist which will hold "Integer" objects. This was introduced for compile-time type check purposes.
why ?
Consider the first case. Its input type is Object. We know that Object is the super class of all classes. We can pass in an Integer object, String object and so on. When fetching the data the developer has to perform proper type casting. Say if the developer initially thinks the code will accept Integer objects so he adds the following typecast while fetching the data
Integer integer=(Integer) content.get(0);
This is supposed to work. But if mistakenly he passes a String it will result in run-time error.
How it can be avoided ?
By introducing compile time checks
How it works ?
when we specify parameterized type only Integer objects can be added to the ArrayList collection. Else it will show error.
content.add(3); // will work
content.add("HARSHAD"); // error shown
If parameterized generic types are for type checking purposes how correct data can be retrieved from the list ?
The compiler implicitly performs type conversion. See the sample code
List<Integer> list=new ArrayList<Integer>();
list.add(1);
list.add(2);
Integer integer=list.get(0);
System.out.println(integer);
What the compiler actually does when you perform compilation ?
//perform type erasure
(B) List list=new ArrayList();
list.add(1);
list.add(2);
// the arraylist inturn accepts Object when you run the code
//add casting
Integer integer=(Integer)list.get(0);
Conclusion
If you see the codes (A) and (B) both are the same. Only difference is that in the second case the compiler implicitly does the same operation.
Finally to answer your question ...
ArrayList result = new ArrayList();
is allowed for backward compatibility purposes. Although this is not recommended.
Official link from Oracle docs explaining the same concept.

Generics were added to Java only in Java 5. Before that, when you use a collection, it always meant collection of objects. The old syntax is left as is for backward compatibility. So ArrayList result = new ArrayList() is actually creating an ArrayList<Object>. Since ArrayList is also an object, you can add content to the variable result.

why can we use ArrayList result = new ArrayList(); to create an object, since we have not give the collection the actual type of element.
Because java wants to it backward compatible. Generics is more of compiler feature for ensure type safety, collections can store any type of object at runtime.
Java compiler will not give you compiler error for this but it must have given you compiler warning that it is unsafe to use generic classes without type.

It may be a remnant from before generics came along to java (Java 4 or 5 I think).

Why autoboxing is not supporting in collection.toArray() in java

Is there no any short cut to do this nicely?
That ugly two loops (One loop to read the pmList and second loop to add to the markupArray) is the only option (Instead of ArrayUtils).
ArrayList<Double> pmList = new ArrayList<Double>();
pmList.add(0.1); // adding through a loop in real time.
pmList.add(0.1);
pmList.add(0.1);
pmList.add(0.1);
double[] markupArray = new double[pmList.size()];
arkupArray = pmList.toArray(markupArray); // This says The method toArray(T[]) in the type ArrayList<Double> is not applicable for the arguments (double[])

Simply use a Double[] array, instead of double[] then everything works fine. If you know the size of the list ahead of time, you can also skip the list and insert directly into the array. It might even be worth to traverse the input two times: Once for retrieving its size and once for insertion.
Auto boxing only works for primitive types, not for arrays of primitive types. A double[] array is no T[] array, since a type parameter T must always be an Object. While a double may be autoboxed to T (with T=Double), a double[] cannot be autoboxed to T[].
The reason why arrays are not autoboxed is probably that this operation would be very costly: Boxing an array means creating a new array and boxing each element. For large arrays, this has a huge performance hit. You don't want such a costly operation to be done implicitly, hence no autoboxing for arrays. In addition, boxing a complete array would yield a new array. Thus, when writing to the new array, the changes would not write through to the old array. So you see, there are some semantics problems with array-boxing, so it is not supported.
If you must return a double[] array, then your must either write your own function or use a third-party library like Guava (see msandiford's answer). The Java Collections framework has no methods for (un)boxing of arrays.

You could use TDoubleArraList or guava's primitive list collection.
You could also determine the size in advance in one loop and add the values in another.

Why not make your own shortcut?
static double[] doubleListToArray(List<Double> list) {
int k = 0;
double[] result = new double[list.size()];
for(double value : list)
result[k++] = value;
return result;
}

Google guava has Doubles#asList(...) and Doubles#toArray(...) which provide conversions from double[] to List<Double> and from Collection<? extends Number> to double[] respectively.

You are right that this is not very intuitive at first look. However, this limitation is related to the way the Java language implements generic types and auto-boxing:
Generic types are erased at runtime. This implies that any ArrayList<Double> is represented by a single compiled Java class ArrayList which is shared with other generic representations of ArrayList such as for example ArrayList<String>. As a consequence, the compiled method ArrayList::toArray does not (and must not) know what generic type an instance represents as the single compiled method must be applicable for any generic type. As the elements could therefore be anything like String or Double, you need to provide an array to the method. The method can then check the type of the target array at runtime and check the elements that are filled into the array at runtime to be assignable to the array's component type. All this logic can be implemented by a single compiled method.
Secondly, auto-boxing and -unboxing is something that only exists at compile time. This means that the statements
Integer i = 42;
int j = i;
are compiled as if you wrote
Integer i = new Integer(42);
int j = i.intValue();
It is the Java compiler that adds the boxing instructions for you. The Java runtime applies a slightly different type system where boxing is not considered. As a consequence, the single compiled method ArrayList::toArray that we mentioned in (1) cannot know that this boxing needs to be applied as we argued that the method must be applicable for any type T which might not always represent a Double.
In theory, you could alter the implementation of ArrayList::toArray to explicitly checks if an array's component type and a lists element type are applicable for unboxing but this approach would result in several branches which would add quite a runtime overhead to the method. Rather, write a small utility method that specializes on the Double type and applies the implicit unboxing due to the specialization. An iteration over all list items suffices for this purpose, this is how the ArrayList::toArray is implemented as well. If your array is small, consider to use an array of boxed values Double[] instead of double[]. If your array is however large, lives long or you are restrained to primitive types in order to comply to a third-party API, use the utility. Also, look out for implementations of primitive collections if you want to ungo the overall boxing. With Java 8, use a Stream in order to inline the array conversion.