# hashCode

Published articles for hashCode.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## A Curious Case of Mistaken Identity: How Lambdas Break Data Class Hashing

DevFeed: [A Curious Case of Mistaken Identity: How Lambdas Break Data Class Hashing](<https://devfeed.tech/articles/a-curious-case-of-mistaken-identity-how-lambdas-break-data-class-hashing-27333.md>)

Original publisher: [Read original article](<https://blog.mmckenna.me/a-curious-case-of-mistaken-identity>)

Author: Matt McKenna

Published: 2024-11-14T21:44:31Z

Content type: tutorial

Language: en

Sources: [Matt McKenna](<https://devfeed.tech/sources/matt-mckenna.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [hashing](<https://devfeed.tech/topics/hashing.md>), [hash](<https://devfeed.tech/topics/hash.md>), [consistency](<https://devfeed.tech/topics/consistency.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [behavior](<https://devfeed.tech/tags/behavior.md>), [class](<https://devfeed.tech/tags/class.md>), [data-class](<https://devfeed.tech/tags/data-class.md>), [hashcode](<https://devfeed.tech/tags/hashcode.md>), [hashing](<https://devfeed.tech/tags/hashing.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>)

### AI overview

This Kotlin article explains why data class instances containing lambdas may compare as unequal and produce different hash-based behavior. Each lambda instance has a distinct identity, so the article recommends excluding the callback from equality and hashCode calculations, while noting the resulting maintenance cost.

### Source excerpt

Introduction: The Scene of the Crime It was a dark and stormy night. My hands were flying across the keys when suddenly the codebase began to exhibit strange behavior. Hashes, which once returned the same values for identical objects, suddenly became...

## Data Classes and Destructuring

DevFeed: [Data Classes and Destructuring](<https://devfeed.tech/articles/data-classes-and-destructuring-25052.md>)

Original publisher: [Read original article](<https://typealias.com/start/kotlin-data-classes-and-destructuring/>)

Author: author@typealias.com (Dave Leeds)

Published: 2023-10-09T00:00:00Z

Content type: tutorial

Language: en

Sources: [Dave Leeds on Kotlin - typealias.com](<https://devfeed.tech/sources/dave-leeds-on-kotlin-typealias-com.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [class](<https://devfeed.tech/tags/class.md>), [classes](<https://devfeed.tech/tags/classes.md>), [copy](<https://devfeed.tech/tags/copy.md>), [data-class](<https://devfeed.tech/tags/data-class.md>), [destructuring](<https://devfeed.tech/tags/destructuring.md>), [destructuring-assignment](<https://devfeed.tech/tags/destructuring-assignment.md>), [equals](<https://devfeed.tech/tags/equals.md>), [hashcode](<https://devfeed.tech/tags/hashcode.md>), [introduction](<https://devfeed.tech/tags/introduction.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [learn-to-program](<https://devfeed.tech/tags/learn-to-program.md>), [object](<https://devfeed.tech/tags/object.md>), [open](<https://devfeed.tech/tags/open.md>), [operator](<https://devfeed.tech/tags/operator.md>), [override](<https://devfeed.tech/tags/override.md>), [programming](<https://devfeed.tech/tags/programming.md>), [properties](<https://devfeed.tech/tags/properties.md>), [tostring](<https://devfeed.tech/tags/tostring.md>)

### AI overview

A Kotlin tutorial introducing data classes and destructuring. It explains how data classes relate to equals(), hashCode(), and toString(), beginning with reference equality and overriding inherited functions.

### Source excerpt

At the end of the last chapter, we saw how all objects in Kotlin inherit three functions from an open class called Any. Those functions are equals(), hashCode(), and toString(). In this chapter, we're going to learn about data classes, which are super-powered classes that are especially helpful when we've got an immutable class that mainly just holds properties. To better understand data classes, let's first explore each of the three functions above, and see what's involved when we override them!

## Useful Kotlin Features Compared with Java

DevFeed: [Useful Kotlin Features Compared with Java](<https://devfeed.tech/articles/kotlin-useful-but-unfairly-not-mentioned-features-38636.md>)

Original publisher: [Read original article](<https://krossovochkin.com/posts/2020_05_03_kotlin_useful_but_unfairly_not_mentioned_features/>)

Published: 2020-05-03T00:00:00Z

Content type: tutorial

Language: en

Sources: [Vasya Drobushkov](<https://devfeed.tech/sources/vasya-drobushkov.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Java](<https://devfeed.tech/topics/java.md>), [Development](<https://devfeed.tech/topics/development.md>), [Android](<https://devfeed.tech/topics/android.md>)

Tags: [classes](<https://devfeed.tech/tags/classes.md>), [hashcode](<https://devfeed.tech/tags/hashcode.md>), [immutability](<https://devfeed.tech/tags/immutability.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [modifiers](<https://devfeed.tech/tags/modifiers.md>), [package-private](<https://devfeed.tech/tags/package-private.md>), [process](<https://devfeed.tech/tags/process.md>), [smart-cast](<https://devfeed.tech/tags/smart-cast.md>), [visibility](<https://devfeed.tech/tags/visibility.md>)

### AI overview

This article compares Kotlin with Java through several less-discussed language differences. The supplied text covers immutable method-parameter references in Kotlin and contrasts Java visibility modifiers, including protected and package-private access.

### Source excerpt

Source Introduction Many of us first learned Kotlin after Java. Learning process was fairly simple because Kotlin has many similarities when at the same time improves development experience by fighting common pain points Java developer (especially on Java 6, which is common in Android world) has to encounter every day. There are a bunch of articles about cool Kotlin features like immutability, handling nullability, smart-cast, data classes, and so forth. Yes, these features are great. Having to add a bunch of nullability annotations, final keywords, override equals/hashCode methods, create additional local variables after type checks -- all of this adds unnecessary work that needs to be done all the time.

## Why Java hashCode and equals implementations must satisfy the contract

DevFeed: [Why Java hashCode and equals implementations must satisfy the contract](<https://devfeed.tech/articles/consistent-return-of-hashcode-in-java-27260.md>)

Original publisher: [Read original article](<https://blog.pchudzik.com/201610/changing-hashcode/>)

Published: 2016-10-19T00:00:00Z

Content type: tutorial

Language: en

Sources: [Paweł Chudzik](<https://devfeed.tech/sources/pawe-chudzik.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [hash](<https://devfeed.tech/topics/hash.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [test](<https://devfeed.tech/topics/test.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [equals](<https://devfeed.tech/tags/equals.md>), [hash](<https://devfeed.tech/tags/hash.md>), [hashcode](<https://devfeed.tech/tags/hashcode.md>), [implement](<https://devfeed.tech/tags/implement.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [intellij](<https://devfeed.tech/tags/intellij.md>), [java](<https://devfeed.tech/tags/java.md>)

### AI overview

This article explains why Java hashCode and equals implementations must follow their documented contract. It focuses on the requirement that repeated hashCode calls on the same object during one application execution return the same integer, and demonstrates problems caused by violating it.

### Source excerpt

HashCode and equals implementations are hard. Usually, it's tricky to properly implement hashCode and equals method to fully fulfill contract from Java documentation. I'm going to focus on just one the point from the hashCode contract: 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. Read it already? Do it again. Let it sink and think about impact of "hashCode method must consistently return the same integer" Read more

## Code generating beans - mutable and immutable

DevFeed: [Code generating beans - mutable and immutable](<https://devfeed.tech/articles/code-generating-beans-mutable-and-immutable-21991.md>)

Original publisher: [Read original article](<http://blog.joda.org/2016/09/code-generating-beans.html>)

Author: Stephen Colebourne (noreply@blogger.com)

Published: 2016-09-26T01:36:00Z

Content type: opinion

Language: en

Sources: [Stephen Colebourne](<https://devfeed.tech/sources/stephen-colebourne.md>)

Topics: [Code generation](<https://devfeed.tech/topics/code-generation.md>), [Java](<https://devfeed.tech/topics/java.md>), [Data structures](<https://devfeed.tech/topics/data-structures.md>), [Code](<https://devfeed.tech/topics/code.md>), [ide](<https://devfeed.tech/topics/ide.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>)

Tags: [abstract-class](<https://devfeed.tech/tags/abstract-class.md>), [code](<https://devfeed.tech/tags/code.md>), [code-generation](<https://devfeed.tech/tags/code-generation.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [constructor](<https://devfeed.tech/tags/constructor.md>), [data-structure](<https://devfeed.tech/tags/data-structure.md>), [hashcode](<https://devfeed.tech/tags/hashcode.md>), [interface](<https://devfeed.tech/tags/interface.md>), [java](<https://devfeed.tech/tags/java.md>), [javaone](<https://devfeed.tech/tags/javaone.md>), [jodabeans](<https://devfeed.tech/tags/jodabeans.md>), [properties](<https://devfeed.tech/tags/properties.md>), [tostring](<https://devfeed.tech/tags/tostring.md>)

### AI overview

This article discusses Java bean code generation, arguing that immutable beans and data structures are preferable to mutable beans. It compares IDE generation with annotation processors such as AutoValue, Immutables, and VALJOGen, which generate implementations during compilation.

### Source excerpt

Java has long suffered from the pain of beans. To declare a simple data class takes far too much code. At JavaOne 2016, I talked about code generation options - see the slides. Code generation of mutable and immutable beans The Java ecosystem is massive. So many libraries releasd as open source and beyond, which naturally leads to the question as to how those libraries communicate. And it is the basic concept of beans that is the essential glue, despite the ancient specification. How do ORMs (Hibernate etc.), Serialization (Jackson etc.) and Bean Mappers (Dozer etc.) communicate? Via getters and setters. The essential features of beans have moved beyond the JavaBeans spec, and are sometimes referred to as POJOs. The features are: Mutable No-args constructor Getters and Setters equals() / hashCode() / toString() But writing these manually is slow, tedious and error-prone. Code generation should be able to help us here. But should we be using mutable beans in 2016? No, no, no! It is time to be writing immutable data structure (immutable beans). But the only practical way to do so is code generation, especially if you want to have builders. In my talk at JavaOne 2016, I considered various code generation approaches: IDE code generation This is fine as far as it goes, but while the code is likely to be correct immediately after generation, there is still no guarantee that the generated code will stay correct as the class is maintained over time. AutoValue, Immutables and VALJOGen These three projects - AutoValue, Immutables, VALJOGen - use annotation processors to generate code during compilation. The idea is simple - the developer writes an abstract class or interface, and the tool code generates the implementation at compile time. However, these tool all focus on immutable beans, not mutable (Immutables can generate a modifiable bean, but it doesn't match the JavaBeans spec, so many tools will reject it). On the up side, there is no chance to mess up the equals / hash