DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Build a Java Backend That Connects With Salesforce
  • High-Performance Java Serialization to Different Formats
  • Java Memory Management
  • Writing DTOs With Java8, Lombok, and Java14+

Trending

  • From Data Movement to Local Intelligence: The Shift from Centralized to Federated AI
  • Detecting Advanced Persistent Threats Using Behavioral Analytics and Log Correlation
  • Unlocking Smart Meter Insights with Smart Datastream
  • Modernization Is Not Migration
  1. DZone
  2. Coding
  3. Java
  4. Extrinsic vs Intrinsic Equality

Extrinsic vs Intrinsic Equality

By 
Nicolas Fränkel user avatar
Nicolas Fränkel
·
Jan. 27, 14 · Interview
Likes (0)
Comment
Save
Tweet
Share
4.5K Views

Join the DZone community and get the full member experience.

Join For Free

Note: the following article is purely theoretical. I don’t know if it fits a real-life use-case, but the point is just too good to miss :-)

Java’s List sorting has two flavors: one follows the natural ordering of collection objects, the other requires an external comparator.

In the first case, Java assumes objects are naturally ordered. From a code point of view, this means types of objects in the list must implement the Comparable interface. For example, such is the case for String and Date objects. If this is not the case, or if objects cannot be compared to one another (because perhapsthey belong to incompatible type as both String and Date).

The second case happens when the natural order is not relevant and a comparator has to be implemented. For example, strings are sorted according to the character value, meaning case is relevant. When the use-case requires a case-insensitive sort, the following code will do (using Java 8 enhanced syntax):

Collections.sort(strings, (s1, s2) -> s1.compareToIgnoreCase(s2));
The Comparable approach is intrinsic, the Comparator extrinsic; the former case rigid, the latter adaptable to the required context.

What applies to lists, however, cannot be applied to Java sets. Objects added to sets have to define equals() and hashCode() and both properties (one could say that it’s only one since they are so coupled together) are intrinsic. There is no way to define an equality that can change depending on the context in the JDK.

Enters Trove:

The Trove library provide primitive collections with similar APIs to the above. This gap in the JDK is often addressed by using the “wrapper” classes (java.lang.Integer, java.lang.Float, etc.) with Object-based collections. For most applications, however, collections which store primitives directly will require less space and yield significant performance gains.

Let’s be frank, Trove is under-documented. However, it offers what is missing regarding extrinsic equality: it provides a dedicated set implementation, that accepts its own extrinsic equality abstraction.

A sample code would look like that:

HashingStrategy<Date> strategy = new MyCustomStrategy();
 
Set<Date> dates = new TCustomHashSet<Date>(strategy);
A big bonus for using Trove is performance, though:
  1. It probably is the first argument to use Trove
  2. I never tested that in any context

To go further, just have a look at Trove for yourself.

Use case Java (programming language) Trove Object (computer science) Code point Java Development Kit application Strings

Published at DZone with permission of Nicolas Fränkel. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Build a Java Backend That Connects With Salesforce
  • High-Performance Java Serialization to Different Formats
  • Java Memory Management
  • Writing DTOs With Java8, Lombok, and Java14+

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook