Super-power compare method? <?>

[Cudmore]

Hi! I'm looking to learn something today, and I have just the question.

In writing a recent program, I found no Java method suited to compare two byte arrays. Maybe the method exists, or maybe not. In any case, this is a learning expedition, and I came up with a simple method designed to compare arrays of values. SontEqual can be adapted to byte, short, char, int, long, etc, and deals with arrays of such values.

static boolean SontEqual (byte[] a, byte[] b) {
     // Compare two byte arrays
     // Method by Matthew Cudmore ^.^
     // ----------
     if (a == null || b == null) return (a == b);
     if (a.length != b.length) return false;
     // ----------
     for (int i = 0; i < a.length; i++)
          if (a[i] != b[i]) return false;
     // ----------
     return true;
}

Now there is a question in mind: can a single method be adapted to represent all numerical primitive types? Or must a separate method be written for each primitive type of array? I'm sure I've seen something of the <?> nature (or whatever it was), and I think it can be done.. Maybe it's got something to do with C++ and not Java. In any case, thanks in advance! I'm about to research this myself, and will post any significant findings for validation. ;)

[jwenting]

first, never name methods starting with a capital letter. That should ONLY be done with classes (by convention, and a good one it is).

As to your question. For primitive types it's rather impossible because of the way generics in Java work (they work only with classes and interfaces).
For those though it's rather sillily easy (took me a while to get it to compile because of a stupid typo I didn't catch in the compiler errors, but the code itself is trivial).

class SomeClass<T> {
	public <T> boolean compare(T[] a, T[] b) {
		for (int i = 0; i < a.length; i++) {
			if (!a[i].equals(b[i])) {
				return false;
			}
		}
		return true;
	}
}

I omitted part of your checks for brevity.

[Cudmore]

:o I noticed that little capital after posting.. Just didn't change it. Please excuse any naive stylistic choices, as I'm not yet completely accustomed to "convention".

And I did stumble upon the Java lesson about Generics here:
http://java.sun.com/docs/books/tutorial/java/generics/index.html

No idea how I found it, because I didn't know what to look for, but now I think I understand this.

Generics work well in source code. However, "type erasure" occurs when compiled, so even if you were to work with Objects and not primitives, you couldn't have a single compiled method represent all possible class types. For deployed libraries, the source would have to be deployed (which is fine) and the generics would be worked out during compilation.

Kay, so I've learned: It's not possible for a single sontEqual method to represent all numerical primitive types. The method would need to be overridden for each supported type if it were to be deployed in a compiled library.

[jwenting]

Yes, the binding is determined at compile time. But that hardly matters in practice, unless you're trying to write a program that's so generic that you don't know even a common basetype at that moment and have no choice but to pass in Object everywhere (at which point generics no longer make sense and you could just as well use Object as the parameter type everywhere).