I am studying Data Structures in java and I am having difficulty with using generics in Binary Search Trees.
For our assignment we are to implement a Binary Search Tree using nodes that contain a parent, left and right node as well as a data value.
The data value in our case takes the form of a Pair object. This is what it looks like:
public class Pair<A,B> {
public final A fst;
public final B snd;
public Pair(A x, B y) {
fst = x; snd = y;
}
public String toString() {
return new String("("+fst.toString()+", "+snd.toString()+")");
}
}
Pair is associtated with two different generics with the first part being the Key and the second being the Value associated with that key.
I also need to implement Iterator in my BST class. I am implementing the Iterator in an inner class that looks something like this:
public Iterator<Pair<K,T>> iterator() {
return new BSTMapIter<Pair<K,T>>(this.root, this.size, this.order);
}
private class BSTMapIter<Pair<K,T>> implements Iterator<Pair<K,T>> { <=== Compiler error "> expected"
...
... (Implementation here)
...
}
The problem I am running into is a compiler error saying "> expected" which leads to other compiler errors ("<identifier expected>" etc.). From my understanding it is choking over <Pair<K,T>> but I have no idea why. I am assuming it is a mistake I made with using generics somewhere, but I am not entirely sure where to look.
I apologize if what I have provided is too vague but I have not encountered any problems with Pair in my implementation anywhere else but here in the implementation of the Iterator.
Can anyone tell me what I am doing wrong here???
If any further information is needed, let me know and I will do my best to provide :)
The problem is the way you're trying to make BSTMapIter generic. It needs to be generic in two type parameters, K and T. The Pair part is irrelevant at this point. (It's important when it comes to what interface it implements though.) So the declaration should be:
private class BSTMapIter<K,T> implements Iterator<Pair<K,T>>
However, that's if you want BSTMapIter to be generic in itself. If this is a nested class within a type which already has K and T as type parameters, you probably just want:
private class BSTMapIter implements Iterator<Pair<K,T>>
You also want to instantiate it slightly differently:
// When it's an inner class
public Iterator<Pair<K,T>> iterator() {
return new BSTMapIter(this.root, this.size, this.order);
}
// When it's a standalone generic class
public Iterator<Pair<K,T>> iterator() {
return new BSTMapIter<K, T>(this.root, this.size, this.order);
}
Related
This question already has answers here:
What is a raw type and why shouldn't we use it?
(16 answers)
Closed 2 years ago.
couldn't help but feel the title is kinda vague, sorry about that. I couldn't describe it better.
I'll get a little more into detail; I'm trying to figure out how to get an iterator working the way I want it to outside of the class it's implemented in. I couldn't manage to find any information on my problem. This is part of an assignment for University, AlphaTest.java should be left as is.
I have a class, Alpha, which holds a class which follows the doubly linked list principle, Bravo. Bravo holds the link to the previous and next instance in the list.
I want to be able to iterate through the linked list with an iterator implemented in the Alpha class so that I can easily go through each instance using a for loop like this:
for(Bravo b: alphaInstance) {...}.
I got this to work as intended within the Alpha class itself, but once I try the same outside of the Alpha class, in AlphaTest for example, it doesn't work as intended. Once I try that I'm hit with the following error:
Error:(220, 23) java: incompatible types: java.lang.Object cannot be converted to models.Bravo
It wants me to instantiate the instance as an Object like so:
for(Object o: alphaInstance) {...}
I could of course cast the object to Bravo. But that's not part of the assignment.
See code below to see what's going wrong. The problem can be found in AlphaTest.java.
Alpha.java
class Alpha<E extends Bravo> implements Iterable<Bravo> {
Bravo head;
public Alpha(Bravo head) {
this.head = head;
}
public void example() {
for(Bravo b: this) {
// This works, it's succesfully recognized as an instance of Bravo.
}
}
#Override
public Iterator<Bravo> iterator() {
return new BravoIterator(this.head);
}
private class BravoIterator implements Iterator<Bravo> {
private Bravo currentBravo;
public BravoIterator(Bravo head) {
this.currentBravo = head;
}
#Override
public boolean hasNext() {
return this.currentBravo != null;
}
#Override
public Wagon next() {
Bravo data = this.currentBravo;
this.currentBravo = this.currentBravo.getNextBravo();
return data;
}
#Override
public void remove() {
throw new UnsupportedOperationException();
}
}
}
AlphaTest.java
{...}
#BeforeEach
private void setup() {
// Assume this is a doubly linked list
Bravo bravo = new Bravo(...);
instanceOfAlpha = new Alpha(bravo);
}
public T1_checkImplementationOfIterableInterface() {
for(Bravo b: instanceOfAlpha) { // <---------------------------------------------[This is the problem]
// This does not work, it expects an instance of Object.
}
}
{...}
You've mischaracterized the error.
What's happening is that instanceOfAlpha is an expression whose type ends up being Alpha - you've elided your definition of this variable, but it seems obvious enough, as you're creating the value for this variable with a raw type as well. Alpha would be a so-called raw type - a type that has type parameters, but where the parameters are missing.
The thing is, raw types are a tad odd: Once you go raw, everything about it is raw, even things that aren't using any of the generics you failed to specify. Thus, the iterator() method of your raw Alpha expression returns a raw Iterator (you'd think it returns an Iterator<Bravo>, but it does not). And therefore, iterating over it returns basic Objects. And therefore, your for loop is broken; for (Object b : instanceOfAlpha){} would compile; for (Bravo b : instanceOfAlpha){} won't.
The fix is generally that when the compiler throws warnings in your face that you shouldn't just go ¯_(ツ)_/¯ I don't know what those mean so I'll just be like the 3 monkeys and just wish that whatever I don't understand is hopefully utterly irrelevant.
It's not. The real fix is: Fix your generics so you don't get these warnings.
You haven't pasted enough code to tell you exactly what you need to do here; probably make instanceOfAlpha be declared as a Alpha<?>. More generally, your first paste (of your Alpha class) looks like you just don't get how generics works; most of the places that mention Bravo in that should have been using E instead. generics is a little tricky; perhaps you want to just opt out altogether. Get rid of the <E extends Bravo> part entirely, and then leave the rest pretty much as is, that would also fix things.
So I'm taking a Java class, and one of the assignments we were given involves abstract data types (ADTs). In this assignment, we're supposed to implement an ADT known as Stack through a class called LinkedStack. LinkedStack has one constructor, but in the test cases my professor provided us, a new LinkedStack object can create either a new LinkedList object or a new ArrayList object. My issue with this is that no matter how I define my argument, I still get an error saying that the argument is incompatible with the classes.
I've tried a logical test to see whether the argument was called as a LinkedList or an ArrayList, which I think is a good thing, but I can't figure out how to properly assign the argument.
I've tried setting the argument to a Stack and then casting to a LinkedStack, with a private final variable being of of type "Stack", I've also tried calling the argument as a List, but I can't seem to get rid of the errors preventing me from starting the compiling process.
This is what we start out with:
interface Stack {
public void push(Object d){
}
public Object pop(){
}
public Object peek(){
}
public boolean isEmpty(){
}
}
public class ListStack implements Stack{
public ListStack(/*argument*/){
}
}
//Separate test case file
//example of the test cases
public void peekTest1() {
Stack q = new ListStack(new LinkedList());
// assertion cases follow
}
public void peekTest2() {
Stack q = new ListStack(new ArrayList());
// assertion cases follow
}
If you look for a type that you can use for /*argument*/, you can do it like this:
public class ListStack implements Stack {
public ListStack(List list) {
}
/* note that you must implement all methods from the interface */
}
Why use type List? List is the common interface, implemented by LinkedList and ArrayList. So you can use one of them in the constructor.
Note: You should not use raw types. List and the classes that implement this interface have a type parameter. When possible you should rather use something like List<String> or List<T>. But maybe, you will learn this in a later lesson.
Can I require classes implementing an interface to have a certain static field or method and access/invoke that field or method through a generic type argument?
I have an interface, Arithmetical<T>, which specifies several functions like T plus(T o) and T times(T o). I have as well a Vector<N extends Arithmetical<N>> class, which is intended for vectors (of variable dimension) with components of type N. I ran into an issue, however, when trying to implement the dot product.
I want to implement the method N dot(Vector<N> o). For this, I plan to start with whatever N's zero is and iterate through both Vector<N>s' List<N>s, adding the product of each pair of elements to my total. Is there a way to specify in Arithmetical<T> that all implementing classes must have a static (and preferably final) field ZERO and start dot(Vector<N> o)'s body with something along the lines of N sum = N.ZERO;?
If not, what other approaches might there be to this problem? I want to allow 0-dimensional vectors, so I can't just begin by multiplying the vectors' first components. Is there a way to instantiate an object of a generic type, so I can merely specify a T zero() method in Arithmetical<T>?
I have a reason for not using Java's numerical types—I want to have vectors with complex components.
Here's Arithmetical:
public interface Arithmetical<T> {
public T plus(T o);
public T minus(T o);
public T negate();
public T times(T o);
public T over(T o);
public T inverse();
// Can I put a line here that requires class Complex (below) to define ZERO?
}
Vector:
public class Vector<N extends Arithmetical<N>> {
private List<N> components;
public Vector<N>(List<N> cs) {
this.components = new ArrayList<N>(cs);
}
public N dot(Vector<N> o) {
// Here's where I need help.
}
}
And Complex:
public class Complex implements Arithmetical<Complex> {
public static final Complex ZERO = new Complex(0, 0); // Can I access this value through N if <N extends Arithmetical<N>>?
private double real;
private double imag;
public Complex(double r, double i) {
this.real = r;
this.imag = i;
}
/* Implementation of Arithmetical<Complex> (and some more stuff) not shown... */
}
I'm quite new to Java (and programming in general); I will likely not understand complex (ha) explanations and workarounds.
Thanks!
(Python is a suggested tag... Huh.)
You need a "zero" for every possible implementation type. A constant in the interface won't do, because a constant cannot be overridden and must remain the same.
The solution is to add a new method to your Arithmetical interface:
public T zero();
Each implementation is forced to implement this and return its own version of zero. In this case, you're using it as a starting point for adding; it's the additive identity.
The Complex class implementation would look like this.
#Override
public Complex zero() {
return ZERO;
}
If your instances are mutable, then don't use a constant; just return new Complex(0, 0).
Another idea is to borrow from what Streams do when reduce-ing items and combining them to one single item -- take an identity value that represents the initial state, i.e. no items collected yet -- zero.
public N dot(Vector<N> o, N identity) {
N dotProduct = identity;
// Perform operations on each item in your collection
// to accumulate and return a dot product.
}
The caller will have to supply the identity value.
Complex dotProduct = vectorOfComplex.dotProduct(otherVector, new Complex(0, 0));
Can I put a line here that requires class Complex (below) to define ZERO?
No. The best you can do is to define an interface, for example:
interface ZeroProvider<A extends Arithmetical<A>> {
A zero();
}
and then supply a compatible instance of that where you need to provide a zero, for example:
class ComplexZeroProvider implements ZeroProvider<Complex> {
public Complex zero() { return new Complex(0, 0); }
}
There's something you can do sometimes using reflection in situations like this. If you put the following method in the Vector class, it will invoke a static method N.zero() (with caveats, below):
protected N zero() {
try {
Type s = getClass().getGenericSuperclass();
#SuppressWarnings("unchecked")
Class<N> n = (Class<N>) ((ParameterizedType) s).getActualTypeArguments()[0];
Method zero = n.getMethod("zero");
return n.cast(zero.invoke(null));
} catch (RuntimeException | ReflectiveOperationException x) {
// probably better to make a custom exception type
throw new IllegalArgumentException("illegal type argument", x);
}
}
However, it's important to understand what this is actually doing. This is getting the type argument from the class file of the direct superclass of this. In other words, there must actually be a superclass of this with an actual type argument (which is a class).
The usual idiom then is that you'd create all of your vectors like this:
new Vector<Complex>() {}
instead of this:
new Vector<Complex>()
Or you'd declare subclasses like this:
public class Vector<N> {
// ...
public static class OfComplex extends Vector<Complex> {
}
}
Since you need an actual superclass with a type argument which is a class, instantiations like in the following examples will fail:
new Vector<Complex>()
new Vector() // never use this anyway
new Vector() {} // never use this anyway
// also, you can't do stuff like this:
public Vector<T> copy() {
return new Vector<T>(this) {};
}
In your case I think the suggestions in the other answers are better, but I wanted to post this answer along with the proper explanation and caveats which are sometimes not included. There are cases where this technique is actually good, mainly when you have pretty tight restrictions on how the class in question is extended. Guava TypeToken will also do some of the reflection for you.
Also, this is the best Java can do at doing exactly what you're asking for (at the moment), so it's worthwhile to point out just as a comparison.
I have no particular use for this in mind, but is it possible to write a method that accepts any number of nested lists in Java?
I got as far as this:
private <T extends List<? extends T>> void masterOfLists(final T list) {
}
The small issue with this now is that it never ends. I neither want to lose generics, so simply accepting an Object and try casting it to a List every pass is not an option in my question.
I hoped it would be clear enough, but appereantly it isn't for some, I want the method masterOfLists to accept the following examples (and way more):
masterOfLists(new ArrayList<Object>())
masterOfLists(new ArrayList<List<Object>>())
masterOfLists(new ArrayList<List<List<Object>>>())
masterOfLists(new ArrayList<List<List<List<Object>>>>())
Instead of Object it may also be a concrete type like String.
The used List may be any type of list, like ArrayList or LinkedList or your custom implementation.
Using pure List won't help you here, you need to define a recursive class.
As an additional source of inspiration you can take a look at my code for Recursive Tic-Tac-Toe
You could create a class something like this:
public class Recursive<T> {
List<Recursive<T>> sub;
T value;
boolean hasSub() {
return sub != null;
}
T getValue() {
return value;
}
void forEach(Consumer<T> t) {
if (hasSub())
sub.forEach(t);
else t.accept(value);
}
}
You can use logic in this class to prevent it from both having a sub-list and an actual value, using constructors and/or setters.
And then if you want to iterate over it and print out all the sub-items recursively, you can use
Recursive<T> recursive;
recursive.forEach(System.out::println);
Then your method can look like this:
private <T> void masterOfLists(final Recursive<T> list) {
You won't get anywhere using pure Lists because the generic type of the list is not available at runtime, and the generics will only create a mess for you here. Using a recursive class is much easier.
The 'cheap' solution is to extend the ArrayList class with your own name, and force the Generics on the subclass. The SubClass is still an ArrayList....:
public class NestingList extends ArrayList<NestingList> {
// all we do is set the Generics...
}
I haven't used generics before and I am wondering when I should use them and what the advantages are. I think it might be appropriate for a collection that I made since java always uses generics for collections as well but if I call the methods I created the type is already set in the function so it would give an error anyway. When should I use a generic class? Could you give an example because I am not sure how to use it. At the moment my code is as follows:
public class NodeList {
private static final int MAX_AMOUNT_OF_NODES = 12;
private HashMap<String, Node> nodeList;
public NodeList(){
nodeList = new HashMap<String, Node>(MAX_AMOUNT_OF_NODES);
}
public Node get(String id){
return nodeList.get(id);
}
public boolean add(Node node){
if(nodeList.size() <= MAX_AMOUNT_OF_NODES){
nodeList.put(node.id, node);
return true;
}
return false;
}
}
You can look at the existing API for guidance. For example, all the Collections are generic. That is because all collections contain elements of a type.
From that, it makes sense that generic classes should be used when you would have to create the exact same code again and again for different types. If you have to do that, generics might offer you some benefit.
As far as an example, the docs are a good place to start.
From that link, the first code sample is
public class Box<T> {
// T stands for "Type"
private T t;
public void add(T t) {
this.t = t;
}
public T get() {
return t;
}
}
Conceptually, there is a Box class that is going to contain something. What it contains does not matter, because the type is specific by the programmer. A Box instance can contain basically anything. When the programmer needs to create a box, he/she specifies the type.
Box<SomeClass> myBox = new Box<SomeClass>();
Think about it this way -- if you wanted to create a general Box that could hold anything without generics, you would have to
1) have the field f be an Object, or
2) create a Box class for every type a box could contain.
With generics, you only need one class, and you can specify the exact type. Maybe if you are doing something and your approach involved either 1 or 2 above, it's better to use generics.
If Node is a class that can hold a piece of data with certain type (like String, for example) then you should generify Node and subsequently NodeList to prevent type errors.
If you don't, then you leave it up to the user of your NodeList to ensure that she never adds an Integer when the list is only supposed to hold Strings. Generics is primarily about catching type problems at compile time rather than runtime.
It's pretty simple to do so, change something like this:
public class Node {
Object data;
//...
}
to something like this:
public class Node<T> {
T data;
//...
}
public class NodeList<T> {
public Node<T> get(String id) {
//...
}
public boolean add(Node<T> node) {
//...
}
}
Your NodeList looks like it could potentially have a second type parameter for the key type, which right now you're constraining to String.
You can generically type the methods arguments as well as the class itself. Here's an example from Java's java.util.List interface:
public interface List<E> {
//...
boolean add(E e);
//...
}
Generics are a way for Java to force a collection data structure (HashMap in your case) to accept only a specific types of objects. This means that at compile time, if you tried something like:
nodeList.add(1, new Node());
it would fail and not compile since 1 is not a String object. It is generally a way to write tidier code.
Check this link as well:http://en.wikipedia.org/wiki/Generics_in_Java