We Keep Coding

Difference between Collections.sort(list) and Collections.sort(list,comparator)

What's the difference between:
public FlyingRabbit(){
list = new ArrayList<Sellable>();
}
public void sort(Comparator<Sellable> comp) {
Collections.sort(list, comp);
}
and:
public class CompareCategory implements Comparator<Sellable> {
#Override
public int compare(Sellable s1, Sellable s2) {
return (s1.getCategory()).compareTo(s2.getCategory());
}
}
I'm confused about why do I need to use the Comparator comp instead of using compare inside CompareCategory.

Collections.sort(List<T>) sorts the given List by the natural ordering of its elements. The natural ordering of an object can be defined by implementing the Comparable interface in the corresponding class. This interface provides a single method, compareTo, which returns
a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.
On the other hand, Collections.sort(List<T>, Comparator<T>) orders the List's elements according to the given Comparator. Their natural ordering will be ignored for the sorting. This second method comes in hand when the List's elements already possess their natural ordering but we want to order them by a different criteria.
Here's a simple example with a Person class displaying name, last name and age.
class Person implements Comparable<Person> {
private String name, lastName;
private int age;
public Person(String name, String lastName, int age) {
this.name = name;
this.lastName = lastName;
this.age = age;
}
public String getName() {
return name;
}
public String getLastName() {
return lastName;
}
public int getAge() {
return age;
}
#Override
public int compareTo(Person o) {
//Defining Person's natural ordering by creating a comparator and comparing by last name and then name the current object and the given paramter
return Comparator.comparing(Person::getLastName).thenComparing(Person::getName).compare(this, o);
}
#Override
public String toString() {
return String.format("%s %s %d", name, lastName, age);
}
public static void main(String[] args) {
List<Person> list = new ArrayList<>(List.of(
new Person("Matt", "O'Brien", 30),
new Person("Conan", "O'Brien", 25),
new Person("Frank", "Johnson", 50)
));
//Original unordered list
System.out.println(list);
//List ordered by Person's natural ordering (last name and then name)
Collections.sort(list);
System.out.println(list);
//List ordered by custom criteria (age)
Collections.sort(list, Comparator.comparing(Person::getAge));
System.out.println(list);
}
}

If Sellable implements the interface Comparable you can use Collections.sort(list).
Otherwise you should create own Comparator and use Collections.sort(list, comparator). Because there must be a rule by which to compare elements of the Sellable type.

You don't need to provide a comparator when objects contained in the list implement Comparable interface.
Comparator & Comparator
That's how the purpose of this interface defined by the documention:
This interface imposes a total ordering on the objects of each class
that implements it. This ordering is referred to as the class's
natural ordering, and the class's compareTo method is referred to as
its natural comparison method.
On the other hand, comparator - is an object that is used to provide an ordering for collections of objects that don't have a natural ordering, i.e. there's no obvious specific way in which these object can be ordered, and their class doesn't implement Comparable.
Comparators are handy when objects are required to be ordered in differently depending on the situation. For instance, you have a class Student, and students can be sorted by their names, ids, grades, etc. And you can create a comparator for each of these cases either by creating a class implementing the interface Comparator and overrides method compare() (like in the code you've listed) or by making use of the static methods like Comparator.comparing() introduced with Java 8.
With that said, interfaces Comparator and Comparable serve the same purpose (to facilitate comparison of object), but have different use cases.
Caution: don't mix things together by creating a comparator inside the compareTo() method, as it's shown in another answer. It's a terrible idea. Why? Because such an implementation will create a new comparator for every invocation of this method. To sort a list of 10.000.000 elements, 10.000.000 * log(10.000.000) comparisons will be required, with each comparison compareTo() will be called and a new instance of comparator will be created. It'll have a negative impact on the application performance because creation of objects is costful, it requires memory allocation and then gives loads of work to the garbage collector.
Fluent sorting
In order to sort a list, you can use static methods sort() from the Collections utility class, that are part of the JDK since the very early version. And you could find lots code-snippets on the Internet, where Collection.sort() is being used.
With Java 8 method List#sort() was introduced in the List interface and you no longer need to resort to static methods from the Collections class. Instead you can directly invoke method sort() on the list, note that it always expects a comparator as an argument. If elements of the list implement Comparable you should pass null instead:
If the specified comparator is null then all elements in this list
must implement the Comparable interface and the elements' natural
ordering should be used.
myList.sort(null); // only if element of the implement Comparable

Comparable and Comaprator interfaces

It is generally said that comparator is used to have multiple sorting sequences of collection of objects while comparable is used to have single sorting sequence.
What is the use of comparator interface in java when it is possible to have multiple sorting sequences using comparable interface?
import java.util.*;
enum CompareValue {RollNo, Marks;}
class Student implements Comparable<Student> {
public int marks;
public int rollNo;
public static CompareValue comparator = CompareValue.RollNo;
Student (int marks, int rollNo) {
this.marks = marks;
this.rollNo = rollNo;
}
public int compareTo(Student s) {
switch (comparator) {
case RollNo:
return this.rollNo - s.rollNo;
case Marks:
return this.marks - s.marks;
}
return 0;
}
}
public class Test
{
public static void main (String[] args)
{
Student s1 = new Student(59, 103);
Student s2 = new Student(87, 102);
Student s3 = new Student(78, 101);
Student students[] = {s1, s2, s3};
Arrays.sort(students);
System.out.println("Student list sorted by rollno");
for (Student s:students) {
System.out.println(s.rollNo + " - " + s.marks);
}
Student.comparator = CompareValue.Marks;
System.out.println("Student list sorted by marks");
Arrays.sort(students);
for (Student s:students) {
System.out.println(s.rollNo + " - " + s.marks);
}
}
}

When your compareTo method has different behaviors based on the value of some static variable, you are basically introducing a global setting that controls the natural ordering of the Student class.
This could be confusing and counter intuitive to users of your class.
Besides, it makes the implementation of compareTo awkward, especially if you have more than two implementations, and each implementation depends on multiple instance variables.
Comparator is a much more suitable interface to supply multiple different comparisons for instances of the same class, each implementation having its own compare() logic.

When you have objects that do not implement comparable, but you would like to sort a collection consisting them, you would either have to extend them just to sort your collection or provide a comparator that compares them even though they are not comparable.
Or you might want to compare sort those objects in a different manner then their natural sort.
Imagine such an example.
String is an object that is comparable. Imagine you want to sort a collection of strings based on their hashCode instead of the string natural order. How would you do it without creating a comparator?

What you have shown there is indeed multiple sort orders using Comparable, but don't you think it's too much boiler plate code? Let's say if you have added a new field to the class called name, and now you want to sort by name. You'd have to:
add a new case to the enum
add a new case to the compareTo.
Another disadvantage of using the approach you showed is that it is not necessarily clear what this means:
Arrays.sort(student);
You would have to look through your code and check what value you have set the comparator.
Also, if I were using your class and I want to sort by something else, I would have to create a Comparator anyway, because I can't edit your class.
But if you use Comparator, you solve all of these problems:
Arrays.sort(students, Comparator.comparing(Student::getName));
Therefore, Comparable is only useful when there is one natural order, like dates and times for example.

If we look at the Comparable and Comparator interfaces and what they mean, everything will be clear.
Comparable:
This is an internal property of a JAVA class i.e. it assumes that whenever one uses the internal compareTo() method, one is using it for the specified object.
public int compareTo(T o);
Therefore, in implementation of this method we use this which is the current object and compare it to some other object of same type. These can be treated as defaults or use for natural ordering.
Like 1 comes before 2 and so on. This is the natural ordering.
Comparator:
This is property which actually is not tightly bound to the Java class itself. Comparators are used to actually provide a method to be used by some other services (like Collections.sort()) for achieving a particular goal.
int compare(T o1, T o2);
By this we mean, You can have multiple Comparators, providing different ways of achieving different goals wherein the actual service can pick any two objects and compare them.
This can be used to provide custom ordering, like using some equation we can come up with an ordering where f(1) actually comes after f(2) and so on. This equation will likely be achieving some order which solves a use-case.

Understanding HashSet

Well here is my question, Can "HashSet Objects" have elements duplicated??
If I read the Set Interface definition, I see:
A collection that contains no duplicate elements. More formally, sets contain no pair of elements e1 and e2 such that e1.equals(e2), and at most one null element. As implied by its name, this interface models the mathematical set abstraction.
And now we are going to write a simple example:
Define class A:
public class A {
#Override
public boolean equals(Object obj) {
return true;
}
}
Now execute this code;
Set<A> set = new HashSet<A>();
set.add(new A());
set.add(new A());
System.out.println(set.toString());
And this is the result:
[com.maths.graphs.A#b9e9a3, com.maths.graphs.A#18806f7]
Why a class what implements Set Interface like HashSet contains elements duplicated?
Thanks!!

You have broken the equals-hashcode contract.
If you override the equals method you must also override the hashCode() method such that:
Two objects which are equal give the same hash, and preferably unequal
objects are highly likely to give different hashcodes
This is important because many objects (unsurprisingly including the HashSet) use the hashcode as a quick, efficient early step to eliminate unequal objects. This is what has happened here since the hashcodes of the different As will be different as they are still using the implementation of .hashCode() provided within object.
If you were to create the class A as follows it would not allow more than 1 A in the set
public class A {
#Override
public boolean equals(Object obj) {
return true;
}
#Override
public int hashCode() {
int hash = 1; //any number since in this case all objects of class A are equal to everything
return hash;
}
}
From the javadoc
public int hashCode()
Returns a hash code value for the object. This method is supported for
the benefit of hash tables such as those provided by HashMap.
The general contract of hashCode is:
Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently
return the same integer, provided no information used in equals
comparisons on the object is modified. This integer need not remain
consistent from one execution of an application to another execution
of the same application.
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must
produce the same integer result.
It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on
each of the two objects must produce distinct integer results.
However, the programmer should be aware that producing distinct
integer results for unequal objects may improve the performance of
hash tables.
Most IDEs will object if you do not include an overriding HashCode method when overiding the equals method and can generate a hashCode method for you.
Notes
Strictly speaking my hashCode() method doesn't completely satisfy the contract. Since A#equals(Object obj) equals anything including objects which are not of type A it is impossible to fully satisfy the contract. Ideally the equals method would be changed to the following as well to cover all bases
#Override
public boolean equals(Object obj) {
if (obj instanceof A){
return true;
}else{
return false;
}
}

Here the HashSet does not have duplicates, as the two add methods add new objects in the HashSet and these are different Objects. The reason that the hash codes for the two elements of the set are different for this reason. Try changing the code to:
Set<A> set = new HashSet<A>();
A a = new A();
set.add(a);
set.add(a);
System.out.println(set.toString());
and you will see that there is only one value in the set.
Or just add the following in you code and check
#Override
public int hashCode() {
return 31;
}

You have violated the hashCode() method contract i.e for same key it should return same hashcode() every time

Does ArrayList use the hashCode method of added objects when adding them

Does the following code use the hashCode method of my Scooter class:
void using_ArrayList(){
List coll=new ArrayList();
Scooter s1=new Scooter();
s1.setNumber("HR26KC345352344");
s1.setHorse_power(123.321);
s1.setYear_of_made(1997);
Scooter s2=new Scooter();
s2.setNumber("HR26KC34535");
s2.setHorse_power(123.321);
s2.setYear_of_made(1997);
Scooter s3=new Scooter();
s3.setNumber("HR26KC345352344");
s3.setHorse_power(123.321);
s3.setYear_of_made(1997);
coll.add(s1);
coll.add(s2);
coll.add(s3);
Scooter s=new Scooter();
s.setNumber("HR26KC345352344");
System.out.println(coll.contains(s));
}
Scooter Class:
class Scooter{
private String number;
private double horse_power;
private int year_of_made;
public String getNumber() {
return number;
}
public void setNumber(String number) {
this.number = number;
}
public double getHorse_power() {
return horse_power;
}
public void setHorse_power(double horse_power) {
this.horse_power = horse_power;
}
public int getYear_of_made() {
return year_of_made;
}
public void setYear_of_made(int year_of_made) {
this.year_of_made = year_of_made;
}
public boolean equals(Object o){
if((o instanceof Scooter)&&((Scooter)o).getNumber()==this.getNumber()){
System.out.println("EQUALS:TRUE"); //OK
return true;
}
else{
System.out.println("EQUALS:FALSE"); //OK
return false;
}
}
public int hashCode(){
System.out.println("HASHCODE");// NOT able To reach here...
return number.length();
}
}
I am able to reach equals() method. But not able to reach hashCode() method. Does hashCode() method is NOT used by ArrayList collection? Please tell me, as I am new to Java-Collections.

Unlike, say, a HashMap, an ArrayList does not need to use the hashCode() method since the order of the elements in an ArrayList is determined by the order in which they were inserted, and not by hashing.

Does hashCode() method is NOT used by ArrayList collection?
I assume that you mean the hashCode() methods of the elements of the ArrayList. The only case where the element hashCode() methods are called by the ArrayList object, is when computing the hash code of the ArrayList itself.
You can confirm this by looking at the source code, or reading the javadocs. (The behaviour is specified in the List API and implemented in AbstractList ...)
So, it is expected that you do not see calls to hashCode() in your example, either from List.add or List.contains. In particular, contains iterates the list elements calling equals on each one until a call returns true. The ArrayList implementation does nothing clever to make contains go fast.
I would also like to point out that the explanation given in this answer is incorrect:
"Unlike, say, a HashMap, an ArrayList does not need to use the hashCode() method since the order of the elements in an ArrayList is determined by the order in which they were inserted, and not by hashing."
This is incorrect in a couple of respects:
The order of an ArrayList is not determined by the order in which elements are added. It is determined by the order and position of the additions (and other operations).
The reason for using hashCode in HashMap is NOT to determine an order. (Indeed, the order of a HashMap is nonsensical ... to a first approximation.) Hashing (via hashCode) is actually used to provide O(1) lookup by key.
LinkedHashMap is a counter-example to the stated reasoning. It preserves insertion order AND use hashCode.
In fact, the two issues (element order and use of hashing) are orthogonal. The actual reasons that hashCode() isn't used for lookup in ArrayList are more pragmatic:
The addition of a hash table-like data structure would increase the ArrayList's memory overheads by a factor of at least 5 per element, and probably more.
Implementing BOTH O(1) hash-based lookup based on elements values (for contains) AND O(1) lookup by element position (for get) in the same data structure is very complicated.
ArrayList is designed to be memory and time efficient for a subset of use-cases. Hashing would be a hindrance in those use-cases. But either way, it doesn't use it.

It is obvious from your code, it doesn't use the hashCode. This methods is used in hashes, not linear collections like ArrayList. And search there is performed in O(N)

Hashcode is used in only those collections which needs to identify unique values.
so its used in Set kind of collections.
in arraylist duplicates are allowed and hence no concept of checking hashcode.

Need explanation of this program in java [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I'm trying to understand, how the compareTo method is called in this program.
class Student implements Comparable {
String dept, name;
public Student(String dept, String name) {
this.dept = dept;
this.name = name;
}
public String getDepartment() {
return dept;
}
public String getName() {
return name;
}
public String toString() {
return "[dept=" + dept + ",name=" + name + "]";
}
public int compareTo(Object obj) {
Student emp = (Student) obj;
System.out.println("Compare to : " +dept.compareTo(emp.getDepartment()));
int deptComp = dept.compareTo(emp.getDepartment());
return ((deptComp == 0) ? name.compareTo(emp.getName()) : deptComp);
}
public boolean equals(Object obj) {
if (!(obj instanceof Student)) {
return false;
}
Student emp = (Student) obj;
boolean ii = dept.equals(emp.getDepartment()) && name.equals(emp.getName());
System.out.println("Boolean equal :" +ii);
return ii ;
}
public int hashCode() {
int i2 = 31 * dept.hashCode() + name.hashCode();
System.out.println("HashCode :" + i2);
return i2;
}
}
public class CompareClass {
public static void main(String args[]) {
Student st[] = { new Student("Finance", "A"),
new Student("Finance", "B"), new Student("Finance", "C"),
new Student("Engineering", "D"),
new Student("Engineering", "E"),
new Student("Engineering", "F"), new Student("Sales", "G"),
new Student("Sales", "H"), new Student("Support", "I"), };
Set set = new TreeSet(Arrays.asList(st));
System.out.println(Arrays.asList(st));
System.out.println(set);
}
}
Why is Arrays.asList(st) used?
What is use of equals() and hashcode()?

Why Arrays.asList(st) is used ?
Because the TreeSet constructor TreeSet(Collection c) accepts a Collection and not a String[] , hence you convert the String[] to a List which is a Collection using the method List asList(T... a). Note here , the array is same as varargs in this case.
What is use of equals() and hashcode() ?
Object class provides two methods hashcode() and equals() to represent the identity of an object.
You are using a TreeSet in your code . As per the documentation:
the ordering maintained by a set (whether or not an explicit comparator is provided) must be consistent with equals if it is to correctly implement the Set interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a TreeSet instance performs all element comparisons using its compareTo (or compare) method, so two elements that are deemed equal by this method are, from the standpoint of the set, equal.
Hence in your case , implementing Comparable and overriding compareTo() is enough .
Suggested Reading:
Overriding equals and hashCode in Java.
Hashset vs Treeset
What is the difference between compare() and compareTo()?

.equals() is used because you are comparing two Objects.

There is a very good explanation of the Comparable interface in the Oracle documentation: http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html
In this code, Arrays.asList(st) is used basically because the author thought it was simpler to instantiate an Array in Java and convert it to a List than it is to create an ArrayList and call .add for each item. It's really not critical to what is going on, though. Another thing that happens on that same line is where the magic is.
Set set = new TreeSet(Arrays.asList(st));
This creates a TreeSet from the list. It is worth taking a look at this post: What is the difference between Set and List? briefly. In a Set, all elements are unique, so when you create a Set from a List that contains duplicates the Set constructor will throw the extra items away. How does it determine what elements are duplicates? It uses the methods of the Comparable interface. Similarly, a List is sorted but a Set is not so the implementation can choose to store the items in the Set in whatever order is most efficient. In the case of a TreeSet it handily explains how it does it right at the top of the Oracle documentation:
Note that the ordering maintained by a set (whether or not an explicit
comparator is provided) must be consistent with equals if it is to
correctly implement the Set interface. (See Comparable or Comparator
for a precise definition of consistent with equals.) This is so
because the Set interface is defined in terms of the equals operation,
but a TreeSet instance performs all element comparisons using its
compareTo (or compare) method, so two elements that are deemed equal
by this method are, from the standpoint of the set, equal. The
behavior of a set is well-defined even if its ordering is inconsistent
with equals; it just fails to obey the general contract of the Set
interface.

Some of the Java API was built around arrays and some of it was built around collections. asList is basically an adapter that lets your array be accessed like a collection.
Some data structures and algorithms operate on what's called the "hash" of a piece of data. This is done largely for performance reasons. In most cases the hash is a single number representing a particular object. You can see how this might be useful for sorting a collection quickly or checking equivalence.
equals exists of course to test if two objects represent the same thing.

I m trying to understand ,how the compareTo method is called in this program.
Because what you use here is a TreeSet, which implements SortedSet, and for which uniqueness is calculated by comparing elements using their natural ordering, and not equality.
Classes implementing Comparable of themselves, or a superclass of themselves, can be compared to one another. For classes which do not, you can supply a Comparator instead.
When you add an element to a SortedSet, the set will first compare it to elements already present in the set, and only add it if no comparison gives 0. See below for a demonstration.
See also Collections.sort().
1.Why Arrays.asList(st) is used ?
because this is Java 1.4 code. In Java 5, you'd use Arrays.asList(s1, s2, etc) (ie, a varargs method).
2.What is use of equals() and hashcode() ?
In this case, none.
Sample program (with generics this time) illustrating the difference between a SortedSet and a HashSet, using BigDecimal:
final BigDecimal one = BigDecimal.ONE;
final BigDecimal oneDotZero = new BigDecimal("1.0");
one.equals(oneDotZero); // false
one.compareTo(oneDotZero); // 0
// HashSet: uses .equals() and .hashCode();
final Set<BigDecimal> hashset = new HashSet<>();
hashset.add(one); hashset.add(oneDotZero);
hashset.size(); // 2
// TreeSet: uses Comparable
final Set<BigDecimal> treeset = new TreeSet<>();
treeset.add(one); treeset.add(oneDotZero);
treeset.size(); // 1

.equals and .hashcode are methods inherited from the Object class in java by every class.
When creating your own class you would usually override these two default implementations because the default Object function generally does not lead to the desired behavior.
They are there for good measure really, but as it is they are not being used.