Generics in Java

[BuckGup]

I am having a hard time understanding how generics work inside methods. I get what a generic is but I am confused on two things. I am using E for the letter by the way. So if you have 

public E grab(){

}
public E[] dump(){

}

The [ ] I assume is signifying an array of E. But how do you actually use E in a method. I want to instantiate 

private E[] elementData;

in the default constructor being equal to a final int. 

So how do I use E? Like this

E.(whatever)

or do I have to assign E to a variable and then use that variable?

private E myField;

public void method1(E param){
myField = param;
}

 

[BuckGup]

Also adding on how can I check if a generic is empty? I have a class that adds E to it and I want to check if it's empty. As well as how can I nullify all the elements once I purge them? I want to be able to dump the array and output it to the screen but empty the array so it can be used again and if I was to call dump again it won't remove the Es where it was initially dumped

[wasab]

Generics in java is used mostly to check type errors at compile time. It is used in many ADTs, ArrayList is one such example. 

 

To declared a class takes in generics, we can do the below

Spoiler

public class Example<T>{

private T t;

 

public Example (T t){

  this.t = t;

}

public t getElement{

   return t;

}

 

}

Then you can pass in any objects into it. 

 

You may wonder what's the difference between that and just passing an Object? I mean doesn't all classes extend objects so you can technically pass in anything like this?

Spoiler

public class Examle{

private Object object;

public Example(Object object){

       this.object = object;

}

public Object getElement(){

  return Object;

}

}

Well, yes. But you need to type cast it everytime if you are gonna have it return Object. 

E.g.

Spoiler

String xyz = new String("xyz");

Example example = new Example(xyz);

 

// To get the element back and use it

 

String value = (String) example.getElement();

 

 

 

You will need to type cast. What's bad about this? First of all, what if type cast the wrong elements like this? 

Spoiler

 Integer integer = (Integer) example.getElemebt();

Well, it is not a bloody Integer object. It is an String object(note string is declared as an object using new, not literal) 

 

But if you use generics

Spoiler

Example<String> example = new Example<String>(xyz);

And do...

Spoiler

String value = example.getElement;

This is entirely valid. You don't have to typecast so during run time, you won't get an unchecked typecasting exception crashing your entire program. It basically allows compiler to check your silly mistake at compile time and avoid nightmarish typecasting when using ADTs like the ArrayList. 

 

Before this, countless programmers bang their heads on the wall due to type casting mistake. 

 

[wasab]

3 hours ago, BuckGup said:

Also adding on how can I check if a generic is empty? I have a class that adds E to it and I want to check if it's empty. As well as how can I nullify all the elements once I purge them? I want to be able to dump the array and output it to the screen but empty the array so it can be used again and if I was to call dump again it won't remove the Es where it was initially dumped

You have to instantiate a generic array first(if you are actually implementing an ADT) like....

 

 

Spoiler

exampleGenericArray  = (E[]) (new Object[16]);

 

 

I am using 16 here because you don't know what the size of the array is. Or maybe you do? In that case, just replace that number with whatever you want. 

 

To get the size, just do exampleGenericArray.length();

 

Check this document. Its from my previous school where I took intro data structure before I transfer. 

https://www.coursehero.com/tutors-problems/Computer-Science/9793726-I-tried-to-figure-out-these-two-questions-for-a-long-time-but-I-am-st/

 

To see if it is empty, just iterate through it and check if each element is null. Although if you are implementing an ADT, you would keep track of it using a counter. And if you are getting really fancy and make your ADT iterable, you would add a modCount to check for illegal modification as well. 

[straight_stewie]

2 hours ago, wasab said:

Then you can pass in any objects into it. 

Another point to add to this is that if you are using Object to build a data structure instead of generics, you immediately lose type safety. Since all types inherit from Object, the data structure can contain any number of different types simultaneously and you will have no idea what it actually contains.

For example (this is in C#, because I'm more comfortable with it, but the concept applies to Java as well):

class Program
{
  static void Main(string[] args)
  {
    ArrayList imGonnaFailYou = new ArrayList();
    
    imGonnaFailYou.Add(new Parent("1"));
    imGonnaFailYou.Add(new Child("1", "2"));
    imGonnaFailYou.Add(new Unrelated());
    
    foreach (object danger in imGonnaFailYou)
    {
      // This block will compile just fine, but error at runtime
      // when danger is Unrelated;
      Parent test = (Parent)danger;
      Console.WriteLine(test.LastName);
    }
  }
}

class Parent
{
  public string FamilyName { get; private set; }
  
  public Parent(string lastName) => FamilyName = lastName;
}

class Child : Parent
{
  public string FirstName { get; private set; }
  
  public Child(string lastName, string firstName)
  {
    FamilyName = lastName;
    FirstName = firstName;
  }
}

class Unrelated
{
  public string foo = "Hi! I'm unrelated";
}

This is why Generics are so powerful: You get to write a thing once, and use it all over the place, while maintaining type safety.

[BuckGup]

6 hours ago, wasab said:

You have to instantiate a generic array first(if you are actually implementing an ADT) like....

 

 

  Hide contents

exampleGenericArray  = (E[]) (new Object[16]);

 

 

I am using 16 here because you don't know what the size of the array is. Or maybe you do? In that case, just replace that number with whatever you want. 

 

To get the size, just do exampleGenericArray.length();

 

Check this document. Its from my previous school where I took intro data structure before I transfer. 

https://www.coursehero.com/tutors-problems/Computer-Science/9793726-I-tried-to-figure-out-these-two-questions-for-a-long-time-but-I-am-st/

 

To see if it is empty, just iterate through it and check if each element is null. Although if you are implementing an ADT, you would keep track of it using a counter. And if you are getting really fancy and make your ADT iterable, you would add a modCount to check for illegal modification as well. 

For an array can't I just say 

ArrayList<E> elementData = new ArrayList<>(DEFAULT_CAPACITY);

As then the array elementData of E is at deault capacity

 

Except in the dump class meant to print out then null every element when I try to use elementData is just saying Expected Array type found java.util.ArrayList<E>. Same goes for returning elementData. Says found E requires E [ ]. But isn't an array of E E[ ]?

[Timotheus2]

If you want to call methods of generic parameters, you can limit the allowed generics with a common ancestor Class/Interface.

public class Example<E extends Element>{ 

That way you can only use inheritors of Element and Element itself for E. Therefore you can call any method defined in Element without any casting:

public void method(E param) {
	param.doSomething();
}

 

[wasab]

44 minutes ago, BuckGup said:

For an array can't I just say 

ArrayList<E> elementData = new ArrayList<>(DEFAULT_CAPACITY);

As then the array elementData of E is at deault capacity

 

Except in the dump class meant to print out then null every element when I try to use elementData is just saying Expected Array type found java.util.ArrayList<E>. Same goes for returning elementData. Says found E requires E [ ]. But isn't an array of E E[ ]?

If you are curious, the size of the array inside the ArrayList is dynamic. The ArrayList will automatically allocate more space to the generic array once it is full. 

BUT

ArrayList and array are not the same thing. 

If you are using java ArrayList, you don't worry need to worry about the size of the array it coontains and all those nitty gritty details. They are all abstracted away from you.

Just read oracle's documentations. It listed clearly what methods you can call on the ArrayList and what each of them do. 

E.g. call .size() if you want the number of elements inside the ArrayList. 

https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html

[Yamoto42]

Yeah, the big problem with generics in Java is type erasure.

Simply put, type parameters are effectively lost at runtime...and it can really messes with overloading and reflection.

What you actually get from the compiler is something like:

// This is your code
public class GenericExample<T> {

	private T myVar;

	public T getVar() { return myVar; }
    
    public void setVar(T var) { myVar = var; }

	static main(String ... args) {
    
    	GenericExample<MyOtherClass> tmp = new GenericExample<>();
        
        MyOtherClass var = 1;
        tmp.setVar(var);
        var = tmp.getBar();
    
    }
}

// This is what the compiler actually compiles
public class GenericExample {

	private Object myVar;

	public Object getVar() { return myVar; }
    
    public void setVar(Object var) { myVar = var; }

	static main(String ... args) {
    
    	GenericExample tmp = new GenericExample();
        
        MyOtherClass var = 1;
        tmp.setVar(var);                   // Because of compile time checking, there may not be a hard type check here.
        var = (MyOtherClass)tmp.getBar();
    
    }
}

You will notice that the compiled class looses its reference to T.  Type restrictions are also solved by inserting casts.

// Example classes
public interface Customer {
	boolean likesSpam();
}

public class GrahamChapman implements Customer {
	public boolean likesSpam() { return false; }
}

// What you wrote
public class Server<T extends Customer> {

	private T myCustomer;
  
  	public Server(T customer) {
      myCustomer = customer;
    }
    
	public String getBreakfast() {
    
    	if (!myCustomer.likesSpam())
        	return "Spam";
        else
        	return "Eggs";
    }
  
  	public static main() {
      
      Server<GrahamChapman> eric = new Server<>(new GrahamChapman());
      
      String meal = eric.getBreakfast();
    }

}

// What gets compiled
public class Server {

	private Object myCustomer;
  
  	public Server(Object customer) {
      myCustomer = customer;
    }
    
	public String getBreakfast() {
    
      Customer tmp = (Customer)myCustomer;
      
    	if (!tmp.likesSpam())
        	return "Spam";
        else
        	return "Eggs";
    }
  
  	public static main() {
      
      Server eric = new Server(new GrahamChapman());
      
      String meal = eric.getBreakfast();
    }

}

You'll see again, the type itself looses the actual type information, and the compiler just inserts cases where needed.

Without getting into too much detail about dynamic dispatch, a good example of a side effect are the types Collection<Double> and Collection<Integer>:  Or more specifically the singular type Collection.

public class TypeErasureExample {
  
 public double sum(Collection<Double> values) { ... }
  
 public int sum(Collection<Integer> values { ... }
  
}

Because generics are implement as type Object, then cast to T, the original type T is not stored as part of the type.  Ergo, if the above were allowed to compile the runtime would see:

public class CompiledTypeErasure {
  
 public double sum(Collection values) { ... }
  
 public int sum(Collection values) { ... }
  
}

And (as return types are not part of a method signature in Java) not know what method to actually call.

[BuckGup]

1 hour ago, wasab said:

If you are curious, the size of the array inside the ArrayList is dynamic. The ArrayList will automatically allocate more space to the generic array once it is full. 

BUT

ArrayList and array are not the same thing. 

If you are using java ArrayList, you don't worry need to worry about the size of the array it coontains and all those nitty gritty details. They are all abstracted away from you.

Just read oracle's documentations. It listed clearly what methods you can call on the ArrayList and what each of them do. 

E.g. call .size() if you want the number of elements inside the ArrayList. 

https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html

Right but my question is E[] is not an array list so when I try to go through it with a for loop and null each element .size() is not found. So do I make an array of E[]  or make a new E [] of a random object? 

[Franck]

Didn't recall generics were that complicated in Java. I mean at that point reflection might be easier to handle.

[straight_stewie]

8 minutes ago, Franck said:

Didn't recall generics were that complicated in Java. I mean at that point reflection might be easier to handle.

I've always found type theory to generally be the one of the most difficult things to reason about.

Reading ECMA 334 shows some interesting insights into how the pure reasoning behind type theory is translated into the type system you might see in a mature language, and what trade offs are made along the way.

In actual practice, the only trouble I've personally run into with generics is more of a gripe with C#: Why do numeric types not have a common ancestor?
And it's really funny, because the language implementors know they overlooked that, and when they are asked about it pretty much just say "Sorry, we didn't think about it at the time, but it would be a breaking change to add now. There really isn't another reason we can't or shouldn't have done it."

[wasab]

1 hour ago, BuckGup said:

Right but my question is E[] is not an array list so when I try to go through it with a for loop and null each element .size() is not found. So do I make an array of E[]  or make a new E [] of a random object? 

Array has no .size(). Each array much be instantiated to a fixed size. You can't change it's size later. By empty, you actually mean how many items in the array are not null. Array can be the length(or size if you prefer to call it that) of any number but each of its element can be null which is essentially an empty array. 

[Franck]

31 minutes ago, straight_stewie said:

In actual practice, the only trouble I've personally run into with generics is more of a gripe with C#: Why do numeric types not have a common ancestor?

I am curious to understand what you consider the common ancestor on numeric types ? did you mean being a struct as their base ?

 

All i can see is the 4 groups 16, 32, 64 and 128 so they have a difference.

[straight_stewie]

1 minute ago, Franck said:

I am curious to understand what you consider the common ancestor on numeric types ? did you mean being a struct as their base ?

What I should have said was: I wish they all implemented some interface which declares the basic numeric and bitwise operations.

That way we could safely build generics that only accept numeric types, and safely operate on them as such.

[Franck]

11 minutes ago, straight_stewie said:

What I should have said was: I wish they all implemented some interface which declares the basic numeric and bitwise operations.

That way we could safely build generics that only accept numeric types, and safely operate on them as such.

Ah ok i get what you mean. Yeah there is none by default to capture all numerics.

 

Still you wouldn't want to catch a short and a decimal in the same generics. Mixing 16 bits and 128 bits is looking for trouble 

[straight_stewie]

20 minutes ago, Franck said:

Still you wouldn't want to catch a short and a decimal in the same generics. Mixing 16 bits and 128 bits is looking for trouble

If it's generic, it can only be the one type at a time.

class MyClass<T> where T : iNumeric
{
  // do foo
}

 

If users want to set T to iNumeric instead of a concrete type then that's up to them, as long as we are upfront about why that might not be a good idea.

[Franck]

5 minutes ago, straight_stewie said:

If it's generic, it can only be the one type at a time.

class MyClass<T> where T : iNumeric
{
  // do foo
}

 

If users want to set T to iNumeric instead of a concrete type then that's up to them, as long as we are upfront about why that might not be a good idea.

True, conceptually it make sense and be more straightforward as everything will work the same way aka no exceptions.

 

I actually never encountered a case where I needed to have a basetype in generics. I can't imagine a case where i would absolutely need to do that. If i needed, it mean there is a hidden class or extension that is not there that should be.

[straight_stewie]

25 minutes ago, Franck said:

I actually never encountered a case where I needed to have a basetype in generics. I can't imagine a case where i would absolutely need to do that.

Lexicographically sorted collections are one example I can think of.

Everything that you put in to a sorted collection must be comparable, otherwise we wouldn't know what order to put them in. One simple way to do this in C#:

public class MySortedCollection<T> where T : IComparable
{
  // do fun sorted collection things.
}

 

[Franck]

3 minutes ago, straight_stewie said:

Lexicographically sorted collections are one example I can think of.

Everything that you put in to a sorted collection must be comparable, otherwise we wouldn't know what order to put them in. One simple way to do this in C#:

public class MySortedCollection<T> where T : IComparable
{
  // do fun sorted collection things.
}

 

Oh yeah right, good example. In Java you would use something similar.

 

I was in my C# mindset and i would never have done it with generics i would have simply let it use it's default comparer or supply a custom one to the class as a parameter which doesn't require generics as it can use reflection and grab the proper comparer. There are lots of work around you simply can avoid for the base type.

[reniat]

1 hour ago, Franck said:

I actually never encountered a case where I needed to have a basetype in generics

There are some trippy but sometimes useful design patterns that use that. One that i've used in the past to solve a particularly weird design problem was the Curiously Recurring Template Pattern, which let consumers consume a basic builder pattern while letting subclasses utlitize the parent builder, all while making sure each level could validate their own builders fields. It's not really a "java" pattern, as it stems from C++ template metaprogramming, but it was still useful for us when trying to work with existing legacy java code.
 

base class example: https://gist.github.com/reniat/d81a43f0fb78c69eee240e0afc7364ab

sub class example: https://gist.github.com/reniat/14faf20ba802555a827cfc9460ddf223

 

consumption examples:

OriginalClass originalClass = new OriginalClass.Builder().setString("test1").build();
SubClass subClass = new SubClass.Builder().setString("test2").setBool(true).build();

 

The idea is the you abstract all the complexity away from the consumers, while letting you subclass a class protected by a builder pattern while still letting each class in the hierarchy be in charge of its own build validation. It was useful for us mainly because we were consuming it in existing code all over the place and needed to maintain passivity in the base class, so the basic .build() structure wasn't up for changing. 
 

Obviously you wouldn't throw a pattern like this around. Code like "<T extends BaseBuilder<T, S>, S>" is a bit...extra, but it worked for us nicely.