Method invokes inefficient Number constructor; use static valueOf instead

From FindBugs:

From FindBugs:
Using new Integer(int) is guaranteed to always result in a new object whereas Integer.valueOf(int) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.

Values between -128 and 127 are guaranteed to have corresponding cached instances [...]

org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java +1 -1

@@ -448,7 +448,7 @@ private void resolveDeltas(final long pos, final int oldCRC, int type,
 	private void resolveChildDeltas(final long pos, int type, byte[] data,
 			PackedObjectInfo oe) throws IOException {
 		final ArrayList<UnresolvedDelta> a = baseById.remove(oe);
-		final ArrayList<UnresolvedDelta> b = baseByPos.remove(new Long(pos));
+		final ArrayList<UnresolvedDelta> b = baseByPos.remove(Long.valueOf(pos));
 		int ai = 0, bi = 0;
 		if (a != null && b != null) {
 			while (ai < a.size() && bi < b.size()) {

Why I box with new Long() over Long.valueOf():

 The standard only requires -128..127 to be cached.  A JRE can cache value outside of this range if it chooses, but long has a huge range, its unlikely to cache much beyond this required region.

 Most pack files are in the 10 MB...100+ MB range.  Most objects take more than 100 bytes in a pack, even compressed delta encoded. Thus any object after the first is going to have its offset outside of the cached range.

 In other words, why waste the CPU cycles on the "cached range bounds check" when I'm always going to fail and allocate.  I might as well just allocate

 These sections of code are rather performance critical for the indexing phase of a pack receive, on either side of a connection. I need to shave even more instructions out of the critical paths, as its not fast enough as-is.  Using new Long() is quicker than using Long.valueOf(), so new Long() it is.

From FindBugs: