android java implementation flaws .. are they documented?

Question

I'm playing with a simple android app using the emmulator running android-7 (2.1) and a moto-defy running android-8 (2.2).

I ran into an interesting problem whereby a CSV parsing application failed on the emmulator, but succeeded on the defy and in regular java apps (using sun java).

I tracked the problem down and the cause is that android-7's implementation of StringReader does not support a negative skip operation:

Android-7:

/**
 * Skips {@code amount} characters in the source string. Subsequent calls of
 * {@code read} methods will not return these characters unless {@code
 * reset()} is used.
 *
 * @param ns
 *            the maximum number of characters to skip.
 * @return the number of characters actually skipped or 0 if {@code ns < 0}.
 * @throws IOException
 *             if this reader is closed.
 * @see #mark(int)
 * @see #markSupported()
 * @see #reset()
 */
@Override
public long skip(long ns) throws IOException {
    synchronized (lock) {
        if (isClosed()) {
            throw new IOException(Msg.getString("K0083")); //$NON-NLS-1$
        }
        if (ns <= 0) {
            return 0;
        }
        long skipped = 0;
        if (ns < this.count - pos) {
            pos = pos + (int) ns;
            skipped = ns;
        } else {
            skipped = this.count - pos;
            pos = this.count;
        }
        return skipped;
    }
}

J2SE 1.6:

/**
 * Skips the specified number of characters in the stream. Returns
 * the number of characters that were skipped.
 *
 * <p>The <code>ns</code> parameter may be negative, even though the
 * <code>skip</code> method of the {@link Reader} superclass throws
 * an exception in this case. Negative values of <code>ns</code> cause the
 * stream to skip backwards. Negative return values indicate a skip
 * backwards. It is not possible to skip backwards past the beginning of
 * the string.
 *
 * <p>If the entire string has been read or skipped, then this method has
 * no effect and always returns 0.
 *
 * @exception  IOException  If an I/O error occurs
 */
public long skip(long ns) throws IOException {
    synchronized (lock) {
        ensureOpen();
        if (next >= length)
            return 0;
        // Bound skip by beginning and end of the source
        long n = Math.min(length - next, ns);
        n = Math.max(-next, n);
        next += n;
        return n;
    }
}

Therefore, instead of skipping backwards (the parser uses this to pre-read a character in certain cases) the android version remains one character forward.

My question is, are the various incompatibilities and variations from the J2SE spec documented anywhere? If not, what other problems have you guys run into.

Thanks, p.

Answer 1

One place to look is the Android issue tracker.

Another place to look is the Apache Harmony issue tracker.

Admittedly, using the issue trackers will involve searching rather than browsing a web of carefully categorized issues. You could think of this as an opportunity ...

---

FWIW - searching the Harmony issue tracker shows there have been a few issues with the behaviour of skip in various stream classes. One issue complained that the behavior of some class didn't match the javadoc ... and that was closed saying that it DID match the RI behaviour, and that the bug was therefore in the javadoc.

My take is that Sun / Oracle bear a lot of the blame for this kind of thing because of their refusal to license the TCK to the Apache Harmony project under reasonable terms.