• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

remove specific object from ArrayList

 
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:Also, if a class like Coordinate is to be used as a map key, make sure it's immutable. Making all fields final is a good first step.



Most importantly, it would allow you to cache the hashcode and always return the same field value. That would be fast indeed ;-)

That's what String.hashCode() does (it caches the value in the hash field):

 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

A.J. Côté wrote:Keep in mind the OP use case; he wants to shuffle the coordinate around. If coordinate had final final fields, he would be much more costly to change the coordinate because he would have to create a new object every time thus offsetting the gains because of the load on the garbage collector...


And this is where micro-optimization can get far too "focused". My old Dell, which finally crapped out on me after 9 years, could create 20,000,000 objects with a couple of private members a second; and it wasn't particularly quick, even for its time.

The great advantage of immutable objects is that they can be cached (probably in some kind of HashMap, like an LRU-Map). And even if that doesn't apply, they can often reuse internal structures (like arrays) in ways that mutable objects can't. I like 'em so much that unless I have an object that really does have a 'state', they're what I choose - even if I can't fully justify my decision - because to me, it just makes sense.

And if you really are into the realm where the difference between a shift or a multiply means life or death, the chances are that Java - fast as it is now - is NOT the right tool.

I guess that makes it 4¢ now, :-)

Winston
 
Marshal
Posts: 79061
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote: . . .
1) The method is doubleToLongBits.

I was right when I said I had misspelt it


2) The the cast isn't redundant. All of these operators produce longs since at least one argument is a long.

Doesn't += do a widening and narrowing conversion so the result is widened to a long and then narrowed to an int, so you can use it for a hash code method as long as it is deterministic and predictable. It will work without the cast.

. . .
So your code a bit more readable:. . . .

What makes you think I was writing readable code ? I was trying to show how unreadable the Joshua Bloch version of hashCode is. If you look in a book like Horstmann and Cornell, you find they have a much more readable version:-I had forgotten about Objects#hash; thank you for reminding me. I remember a long time ago you said you had written your own version of some of the Objects class' methods, as did lots of other people.

I shall check my Java7 version of H&C to see whether they use Objects#hash.
 
Sheriff
Posts: 22780
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:


If this was written in the post Java-5.0 era, this is just awful. Even in Java 5.0 through 7 anybody knows that they should use Long.valueOf(l) instead of new Long(l). Java 8 makes the Long object itself unnecessary.
 
Campbell Ritchie
Marshal
Posts: 79061
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I shall check that. It may have been copied from older versions of the book before valueOf was available.
 
Campbell Ritchie
Marshal
Posts: 79061
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I looked in my Java7 edition of H&C, pages 234-236 I think. On page 236bit describes the two Objects class methods.
On page 235 there is an example including + new Double(...).hashCode()
So that code has obviously not been updated since Java5 came out.
 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hmmmm.... thanks for all the input! Getting back to an ArrayList.... Would parsing the List with a for-each loop and when the object with specific coordinates are found, add that object to another toBeEmptied List work by emptying the second list? Would the object be deleted from the first list too, since both references are just pointing to the object? Am I understanding Object reference right?
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ted Schrey wrote:hmmmm.... thanks for all the input! Getting back to an ArrayList.... Would parsing the List with a for-each loop and when the object with specific coordinates are found, add that object to another toBeEmptied List work by emptying the second list? Would the object be deleted from the first list too, since both references are just pointing to the object? Am I understanding Object reference right?



How many Objects will be in your collection?

What is the grid size?
 
Ted Schrey
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
the grid size is open... determined by parameter. Same for number of Objects. For my current purpose, I'd keep grid between 10x10 and 25x25 with no more than a dozen Objects moving in random directions.
 
Ted Schrey
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just did what I asked about in a short test class, and it didn't work, so no need to respond... clearing the second array did just that and only that... it did not "destroy" the object so the first array apparently still was pointing to it.
 
Ted Schrey
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry about this... my test code was bad... I did list2.removeAll(List1), but is should be list1.removeAll(list2) where list 2 is the one created to hold the objects I want removed...and it did work, but I get the feeling from your first inquiry that it must be very inefficient?
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ted Schrey wrote:the grid size is open... determined by parameter. Same for number of Objects. For my current purpose, I'd keep grid between 10x10 and 25x25 with no more than a dozen Objects moving in random directions.


And for a grid of that size, if all you need to know is whether the position is "occupied", I'd definitely consider a BitSet, viz:Not sure if it's what you want, but it gives you an idea of what it can do - and it's VERY fast.
It also has a lot of other neat features - including a clear() method.

HIH

Winston
 
Campbell Ritchie
Marshal
Posts: 79061
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because you are working with individual bits there is no need to calculate hash codes. You can set a bit with the | (=bitwise OR) operator and unset it with the bitwise AND operator … & ~0x0001_0000

Note the use of the one's complement operator to convert a number with 1 bit set to a number with only that single bit unset.
~0x0001_0000 is 0xfffe_ffff
It has the same precedence as !b -n and ++n, so much higher than AND.
 
reply
    Bookmark Topic Watch Topic
  • New Topic