flickrj

Thanks for the response. I'm not sure if you're planning any action as a
result of this.

You could use reflective impls for these methods that avoid evaluating
properties that fetch the image data from the urls. The 'transient'
modifier could be used to mark property getters to ignore - this would be
consistent with serialisation.

However you implement equals(), hashCode() has to be consistent with it -
in general that means it has to be based on a *subset* of the properties
you compare in equals(), not necessarily all of them.

The real brake on equals() and hashCode() where the fact that they called
the (deprecated) image-getters. That's odd. Somehow the unit-test has not
revealed that.

An other approach to traverse the class as with reflection would make no
significant difference.

I can't accept this path. Just to consider the id and secret - sure,
that's easy. But that 's not sufficient.

Forgot to mention in the last comment that I'm using rel-1-2.
I've uploaded a patch with simple impls of hashCode() & equals() for
Photo; they just use the id & secret properties.
The impl of equals() isn't perfect; see
http://www.artima.com/lejava/articles/equality.html for a fuller treatment.

I've attached a simple main which obtains a public photo from Flickr &
outputs the time taken to evaluate toString() for it & to evaluate equals()
on itself.

For me the output is

false
x=x?: 1031
Photo hashCode unrecognised object: java.awt.image.BufferedImage
Photo hashCode unrecognised object:
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream
Photo hashCode unrecognised object: java.awt.image.BufferedImage
Photo hashCode unrecognised object:
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream
Photo hashCode unrecognised object: java.awt.image.BufferedImage
Photo hashCode unrecognised object:
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream
Photo hashCode unrecognised object: java.awt.image.BufferedImage
Photo hashCode unrecognised object:
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream
Photo hashCode unrecognised object: java.awt.image.BufferedImage
Photo hashCode unrecognised object:
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream
com.aetrion.flickr.photos.Photo@a9b3486e
toString: 6032

So:
- Photo.equals() takes 1s (in this case) to get the wrong answer
- Photo.toString() takes 6s

Photo.equals() gets the wrong answer here because you end up calling
equals() on two different BufferedImage instances.

I'll upload a patch tomorrow.

I was able to identify one line of output at hashCode(). That's removed. Is
that, what you call noisy?

Slow? In which sense? The whole Test-Case has a runtime of 0.15 seconds.
Considering some overhead for JUnit I see a runtime of about 0.004 Seconds.
This just as a very rough calculation.
In principle it might be possible to implement this with better
performance. Send a patch and we will compare.

Both methods are working on all properties. Otherwise they would'nt be
very usefull.

A Flickr-Photo is identified by its id (and secret). Changing an attribute
will change the java-object. But the Flickr-Photo is always the same.

Oops, for some reason this was added as a feature request, but I intended
to raise it as a bug.