• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

What difference exactly will come for this case if I override hashcode and equals?

 
Marshal
Posts: 26300
80
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The hashCode() method is defined in the Object class, and therefore if you don't override it in your class then the object's hash code is whatever Object's hashCode() method returns. That's just how Java works. I don't find that particularly significant and I'm not interested in manufacturing "significance" for it.
 
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes.
I mean so many objects get created in java and they get a default hashcode value. Unless we override hashcode method (e.g for storing objects in collections based on hashing), it doesn't look like having any use. But so many objects being given a  default value for useless reason doesnt sound logical to me and I felt there must be some reason.
 
Saloon Keeper
Posts: 12623
273
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason is so that you can use those objects in HashSet and HashMap, even if you don't override equals() and hashCode().
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:The reason is so that you can use those objects in HashSet and HashMap, even if you don't override equals() and hashCode().



But why would someone use them in hashing based collections like HashSet and HashMap without overriding equals and hashcode methods?
 
Paul Clapham
Marshal
Posts: 26300
80
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:But why would someone use them in hashing based collections like HashSet and HashMap without overriding equals and hashcode methods?



If, for example, you have objects which are all to be considered distinct, so you don't have to override equals(), then there's no point in writing a hashCode() method to produce hash codes which are consistent with the equals() method. For example if you had a Swing GUI application with a lot of JButton objects and you wanted to store some of them in a HashSet to be used later. Since none of them are equal to any of the others, then it would be nice if they had hash code values which were all different. But as you know that isn't a requirement, so even "mostly different" would be better than "all the same".

But writing a hashCode() method which provides "mostly different" hash code values for a bunch of objects isn't all that easy. Fortunately that's exactly what Object's hashCode() method does, so not overriding it would be the best strategy.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:you wanted to store some of them in a HashSet to be used later. Since none of them are equal to any of the others


But if we don't have any constraint that duplicates are to be avoided then why use HashSet, a Set, why not instead use a List.
 
Saloon Keeper
Posts: 7618
68
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:From your original post: What difference exactly will it make if my Employee class overrides hashcode and equals methods?


If you are not going to use hash codes then no need to override the one that comes with Object, as has already been stated. A HashSet was just being used as an example of something that makes use of a hash code. If you don't need the capabilities of a Set, then don't use it. Remind me again, what was the point of your original question?
 
Paul Clapham
Marshal
Posts: 26300
80
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:

Paul Clapham wrote:you wanted to store some of them in a HashSet to be used later. Since none of them are equal to any of the others


But if we don't have any constraint that duplicates are to be avoided then why use HashSet, a Set, why not instead use a List.



So you as the Java Designer are saying to me "Sorry, you can't put a JButton into a HashSet unless you produce a subclass which overrides the hashCode() method and use that instead." It's not the job of the Java Designer to put roadblocks in the way of programmers. If I put them into a HashSet I expect it to work properly and it's the job of the Java Designer to make sure that happens.
 
Marshal
Posts: 71730
312
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:. . . so many objects get created . . . a default hashcode value. . . .

No, as Paul has told you they don't have default values for their hash codes. They have distinct values; they have a default hash code calculation algorithm, which is something different.
 
Stephan van Hulst
Saloon Keeper
Posts: 12623
273
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:But if we don't have any constraint that duplicates are to be avoided then why use HashSet, a Set, why not instead use a List.


Because, as I've already explained to you before, you can add multiple references to the same object in a List, but you can't add multiple references to the same object in a Set.
 
Ranch Foreman
Posts: 175
8
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a reason that people might want to use a HashSet rather than a List, even if they are not trying to go out of their way to avoid duplicates per se.
It is relatively very quick to find whether even a quite large HashSet contians a particular element or not, or to find it if it does.
In a List, you can't answer that question or find the element if it does exist unless you either sort it (and keep it sorted) and use a binarySearch() or you iterate thru all of them checking "is this one my element?  Is this one?  Maybe this one?"

So the two properties that are most relevant to get us to use a HashSet rather than a List are:
1. We need to avoid duplicates -- the answer most people are looking for when they ask when we would use one...
2. We desire finding/not-finding elements with a particular value relatively fast when we have a lot of them.

There are two reasons the second requirement is met so well by the HashSet:
1. We can look up by hashCode() and often say "Nope, not here!" without ever calling a single .equals() which might be expensive if the objects themselves contain a lot of data or there are quite a lot of them.
2. Even if it is in there, we will find it much faster by never looking closely at any of the elements which have the wrong .hashCode(), which will be most of them.

None of this matters much if you don't look for elements very often, or if the number of elements is quite small.
I have written real programs that seem to spend almost all their time either adding or looking for elements among a very large total number, it would be terrible to do those in the Caveman way I usually used to use in C programs, looking at all the values every time I wanted to look for one.

Monica had a separate thread about whether HashMap and ArrayList were the two most used data structures.

Nobody pushed the advantages of NavigableSet/NavigableMap that TreeSet and TreeMap give us very much, probably because despite HackerRank, LeetCode, etc. being chock full of problems that are trivial to solve using NavigableSet/NavigableMap and terribly painful without, they just don't come up that often in Real Life.
I look back at some of the problems that cried out for those which I tried to solve due to past ignorance without them, it was cringe-worthy.
Although both HashSet and TreeSet enforce uniqueness, HashSet is all about very fast lookup of random element values, whereas TreeSet/TreeMap is all about making finding the nearest or highest and lowest values very quick and easy.  They are wonderful when that is what you need.  Neither of those use .hashCode() however, only natural sort order or a Comparator.
 
Campbell Ritchie
Marshal
Posts: 71730
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:. . . In a List, you can't answer that question or find the element if it does exist unless you . . . use a binarySearch() or you iterate thru all of them . . .

But a List can accommodate mutable elements, which neither a hash collection not a tree set can; if the elements change their state, other data structures will cease to work correctly.

. . . None of this matters much if you don't look for elements very often, or if the number of elements is quite small. . . .

I think it matters that people learn the correct use of data structures even with a few elements. It means you can go from a 10‑element data structure to a 10,000,000‑element data structure in a matter of seconds.

TreeSet/TreeMap is all about making finding the nearest or highest and lowest values very quick and easy. . . . .

I would say they are primarily about putting unique elements/keys in “sorted” order.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Carey Brown wrote:If you are not going to use hash codes then no need to override the one that comes with Object



Yes, but in those cases, what is the purpose of the 'the one that comes with Object'?

From your original post: What difference exactly will it make if my Employee class overrides hashcode and equals methods?



I had already understood the question that was asked in the original post earlier in this thread.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote: It's not the job of the Java Designer to put roadblocks in the way of programmers. If I put them into a HashSet I expect it to work properly and it's the job of the Java Designer to make sure that happens.


Thanks. Agree. What java designer puts through generics are constraints and what I was talking about are roadblocks.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote: they don't have default values for their hash codes. They have distinct values; they have a default hash code calculation algorithm, which is something different.


Yes, thanks.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
Because, as I've already explained to you before, you can add multiple references to the same object in a List, but you can't add multiple references to the same object in a Set.



Yes. But why do we need to add multiple references in this case?
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks

HashSet is all about very fast lookup of random element values, whereas TreeSet/TreeMap is all about making finding the nearest or highest and lowest values very quick and easy.



By "very fast looksup of random element" do you mean using contains method to check wither an element exists in the set or not?

We can look up by hashCode() and often say "Nope, not here!" without ever calling a single .equals()



How is that possible because hashCode will help in locating the hashbucket in which the reference of the object resides and equals will be the one which will identify the exact object.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:a List can accommodate mutable elements


What does mutable element in a list mean here because what I understand is if something is mutable it is and if it is not it is not so how does it matter if such element is inside the list or a set.

I would say they are primarily about putting unique elements/keys in “sorted” order.



Thanks. I think we may require unique elements in sorted order in cases where we may be required to display those in sorted way e.g on a UI.
 
Carey Brown
Saloon Keeper
Posts: 7618
68
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:

We can look up by hashCode() and often say "Nope, not here!" without ever calling a single .equals()


How is that possible because hashCode will help in locating the hashbucket in which the reference of the object resides and equals will be the one which will identify the exact object.


Looking up something in a HashMap or HashSet has three steps to go through and it will say not found as soon as any one of the steps returns not found.
1) find the bucket <<trivial>>
2) find the matching hash code(s) in the bucket <<cheap>>
3) find the one where equals() is true for the object <<expensive>>
The goal is to avoid step (3) unless there is a reasonable probability that what we are looking at in the Map/Set is really the one we seek.

I reiterate, trying writing your own HashSet (approx 100 lines of code) and you will find these thing out for yourself AND you will remember them.
 
Paul Clapham
Marshal
Posts: 26300
80
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:

Stephan van Hulst wrote:
Because, as I've already explained to you before, you can add multiple references to the same object in a List, but you can't add multiple references to the same object in a Set.



Yes. But why do we need to add multiple references in this case?



What do you mean by "in this case"? I don't recall seeing any specific description of an algorithm which might add multiple references to the same object to anything. I do remember remarking that somebody might write some such code, but asking a specific question about a general idea is pointless. You should be able to imagine the possibility that somebody might write some code which needs to add an object to a container (Set, List, whatever) but might try to add the same object more than once. You shouldn't have to demand a specific example of that before allowing that it might actually happen.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:
asking a specific question about a general idea is pointless.



Sure, we can discard this question.  

Paul Clapham wrote:
What do you mean by "in this case"?.



I had meant the case where we don't have any constraint that duplicates are to be avoided.
 
Paul Clapham
Marshal
Posts: 26300
80
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:I had meant the case where we don't have any constraint that duplicates are to be avoided.



Rereading the thread, it does look like you were trying to bring up that non-constraint. But I don't see the point of the question since the entire thread has been about HashSet and hash codes.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:since the entire thread has been about HashSet and hash codes.



Yes, that's true.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Surely you meant, “override”?
.



Yes, Thanks. That was inappropriate word from me. The correct word is 'override'.


Campbell Ritchie wrote:

You mean they must have the same hash code. Not “similar”.


Yes, Thanks. That was again inappropriate word from me. The correct word is 'same'.
 
Jesse Silverman
Ranch Foreman
Posts: 175
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Campbell:

"But a List can accommodate mutable elements, which neither a hash collection nor a tree set can; if the elements change their state, other data structures will cease to work correctly."

Yes, this ties everything together for me and brings things full circle!
I'm working hard at overcoming my addiction to mutability in preparation of adopting easily parallelizable functional coding styles where beneficial and appropriate.

With help from my sponsors here at CodeRanch, where Cows will stand in for Chips, and we prefer not to be Anonymous, tho our classes and methods may sometimes be so.

But hey, sometimes mutability is indeed appropriate, and in those cases the mutable objects in question will either be elements in a List or values being looked up by the immutable keys.

There is a beauty and elegance to all this which comes out once one stops tripping over the basic details.

I'm almost there.

Some people feel they have reached Collections mastery when they can draw out the whole hierarchy of interfaces and abstract and concrete classes, thru IdentityHashMap and PriorityBlockingQueue and WeakHashMap, and to memorize all of their methods by rote -- that is the impression one is left with from some very popular tutorial sources.

But the inter-relationships of .hashCode() / .equals() / .compareTo() / .compare() and immutability vs. mutability is pretty darn essential, and I have seen some people neglect these fundamentals for Trivial Pursuit -- Java Collections Framework Edition.

This thread and its companions from the end of 2020 have done a lot to counter that, and I value everyone's contributions.

Myself, I think I am back to that level of ensuring I know every class and method covered on the 819, knowing that I've gone thru this workplace safety course that will prevent me from seriously injuring myself in the future with improper use of these powerful tools.

Thanks, all.

p.s. One detail I think I see is that of Monica's seeming obsession with the "why" of every object having a .hashCode() value that may never be used.  I think we could ask "If we were doing it all from scratch, wouldn't it be just as good to have a Hashable interface we could implement that had the single default method .hashCode() that we could override as needed, and to just implement this if we want to use our class as a Key or an element in a HashSet?"
I think that would be fine now, I don't see why that would be bad, except we've been sticking our objects in Hashtable since the very beginning and in HashSet and HashMap keys for well over 20 years, and we didn't have default methods in interfaces until Java 8.  So if I'm not missing something, this could be another case of functionality landing where it did because common default functionality could only be in a class until relatively recently.  The only way to guarantee every single class that one wanted to have access to a default .hashCode() implementation was to stick that method in the only Class that every last one of our Classes sub-classes, whether 99% or 50% or 2% of them will ever make use of it in a given program.  I feel it is the same answer about why a .sort( List<> ) method is found in Collections rather than List.  Because we couldn't put default functionality into references until very recently, it all had to go into some class somewhere.
 
Campbell Ritchie
Marshal
Posts: 71730
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:Campbell:. . . this ties everything together for me and brings things full circle!

It is always very pleasing to hear the penny drop

. . . the "why" of every object having a .hashCode() value that may never be used. . . . wouldn't it be just as good to have a Hashable interface . . .

Good idea; I think that would work, but the decision was made to put hashCode() into Object, and that cannot be changed. Find out what Joshua Bloch says about the Cloneable interface: should this have included the clone() method rather than Object? Should the OutputStream#writeObject() method take Object or Serializable as its parameter? There are all sorts of interesting possibilities about different design decisions that might have been made 25 years ago, but which cannot be altered now for fear of breaking backwards compatibility.

. . . why a .sort( List<> ) method is found in Collections rather than List. . . .

It would have been possible to include sort() in the List interface, but that is another decision which could only be altered with default methods.

There is a beauty and elegance to all this

Isn't there Just as any well‑designed machine or structure will have beauty and elegance: bridges, ships, aeroplanes, and computer programs. Unlike my old supervisor who thought programming is an extension of maths, I think programming is a kind of engineering and you are trying to make something.

Never mind that you are in a position where you have to learn all the Collections Framework interfaces for the exam. When you get the test, you will want to know the Collections Framework properly, which means,

I want to able to collect thousands of XXX references and XYZ them with YYY and ZZZ them by the ZYX.

That sounds like a reversible skip list.

 
Campbell Ritchie
Marshal
Posts: 71730
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By the way, (challenge) find Bertrand Meyer's book about Eiffel (I think you want Object‑Oriented Software Construction rather than the old language specification). Eiffel has a top class to every inheritance hierarchy called GENERAL, which nobody ever uses. GENERAL has an immediate subtype called ANY, which people do use as a supertype. Find out how many functions and procedures there are in  ANY, and compare that to Object. Which do you prefer?
 
Jesse Silverman
Ranch Foreman
Posts: 175
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've read a lot of things about Bertrand Meyer's works, and Eiffel, and some smaller things from him.

There was a two page extended quote in a header file for portable C event handling in a 3rd party library I used to use in C and C++ which then implored everyone to go read all his books!

I've looked at his various books (he continued writing way past the dates of his works that are usually most commonly cited) and felt...

I hope I find a position with enough long-term stability to actually read some of these.  He writes a LOT about very foundational concepts in OOSE.

His works get to the root of the philosophy of software engineering.

He doesn't think very warmly of many software edifices most of us currently inhabit, they are neither very beautiful nor very soundly built.

So he gets relegated to "Yeah, man, the Design by Contract Guy!" on interview questions.

If I wind up primarily in Java all the time, beyond the 819 there's going to be a lot to know about Spring and Hibernate and ... and ...

The handful of "Great Java Books" everyone writing Java code that needs to work well should be reading are probably ahead in the queue.

Eiffel itself seems to be used about as much as Plan 9 or Oberon.

One can hope that the people making the Big Decisions about Java, .Net, C++ and Python are keeping up with his writings, but I am positioned somewhat downstream from them.

So many of the jobs that I am considering, or are considering me, are like "We have a pretty simple tech stack here.  80% of the code you would be working on is either C++, Java or Scala.  Except for the Python, of course, a lot of the new stuff is Python too."

Frustrating for someone like me who has characteristically known all the basics of whatever I was doing pretty well, and been an aid to those around me who would sometimes forget them or just be unaware of them to the detriment of our projects....the scope of "The Basics" is freaking huge even for someone who doesn't get hung up on "tiny details' like the difference in behavior of Method References vs. Lambda Expressions Regarding Capture of Non-Final Object References or the difference in what "Short-Circuit Evaluation" means for composed Predicate<> functions versus the actual Java Short-Circuit Logical Operators, or "why is everyone explaining the relationship of the String Constant Pool to the Rest of the Strings on the Heap wrongly?"

All of that attention seems to constitute evidence of OCD, but I have seen much smaller and more subtle things to eventually be found to be the cause of bizarre system behavior that somehow missed all Unit Tests and led to a "National Treasure" style Adventure that took days away from doing anything else.  They were mostly in the category of....people would look at some code, quickly say "it does this" and be wrong.  The actual suspect had shown up in the first scene and was thanked for his help as a witness and dismissed.

The nonsense with the Constant Obsession over String Constant Pool details is just that -- just stop using == to compare Strings, folks!
But the combination of the breadth of stuff there is to know right now, and the level of detail I need to know about something to get to to feel comfortable is pretty huge.
Java Puzzlers, indeed!

So Bertrand Meyer is awesome, but probably far down my "Must Read" list for now.  As stated, I sure hope the people making the Big Decisions about Java, C++, C#, Python etc. are managing to find time to read him, tho.
 
Campbell Ritchie
Marshal
Posts: 71730
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:. . . He doesn't think very warmly of many software edifices most of us currently inhabit, they are neither very beautiful nor very soundly built.

Most of his criticisms are well‑merited.

. . . Eiffel itself seems to be used about as much as Plan 9 or Oberon.

They introduced a new version about 2005/2006 which most users weren't happy with. And a lot of Eiffel's popularity was due to Meyer's personaltiy and advocacy.
 
Monica Shiralkar
Ranch Foreman
Posts: 2348
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:

Some people feel they have reached Collections mastery when they can draw out the whole hierarchy of interfaces and abstract and concrete classes, thru IdentityHashMap and PriorityBlockingQueue and WeakHashMap, and to memorize all of their methods by rote -- that is the impression one is left with from some very popular tutorial sources.

But the inter-relationships of .hashCode() / .equals() / .compareTo() / .compare() and immutability vs. mutability is pretty darn essential, and I have seen some people neglect these fundamentals for Trivial Pursuit -- Java Collections Framework Edition.

This thread and its companions from the end of 2020 have done a lot to counter that, and I value everyone's contributions.



Yes. I too had felt so.

Myself, I think I am back to that level of ensuring I know every class and method covered on the 819, knowing that I've gone thru this workplace safety course that will prevent me from seriously injuring myself in the future with improper use of these powerful tools.

Thanks, all.


That is good to know.
 
reply
    Bookmark Topic Watch Topic
  • New Topic