1

I wonder what use case InputSource is there for? In other words, is there any situation where InputSource can’t be replaced by StreamSource? In still other words, why do these two classes exist in the JDK?

AFAICS: Both classes lie in the java.xml module, and their APIs are almost identical, the only difference being that InputSource has an “encoding” parameter; and that StreamSource is part of a hierarchy (as it implements Source), which makes it nicer to use in some contexts (you can decide to accept a Source if that is enough for your purpose when designing your API). Furthermore, they both were introduced in Java 1.4.

As also pointed out here, these classes are used in different parts of the JDK API: “A Parser can take its input from an InputSource, but not from a StreamSource. A Transformer can take its input from a StreamSource, but not from an InputSource.” But this does not explain why the designers of the JDK API decided to introduce two apparently redundant classes for the purpose of representing a source. Hence, my question.

(Slightly related: difference between InputSource and InputStream.)

Olivier Cailloux
  • 977
  • 9
  • 24
  • 2
    You answered your own question, didn't you? "Because these have origins in two initially unrelated XML APIs and java doesn't just delete something simply because it is obsolete or superfluous; that would break backwards compatibility". – rzwitserloot Sep 15 '21 at 14:03
  • You seem to assume that these two classes are related because they have the world ‘Source’ in their names. But they are not. StreamSource is a transformation source. InputSource is specific to SAX, which is an interface [defined outside of Java SE](http://www.saxproject.org). – VGR Sep 15 '21 at 15:37
  • @rzwitserloot I considered this possibility, but thought that this was not the right answer, as both classes were integrated in the Java API at the same time (version 1.4), as I noted. The [answer from Michael Kay](https://stackoverflow.com/a/69197436) gives the piece of information (that I ignored) which completes the puzzle. – Olivier Cailloux Sep 16 '21 at 08:40

1 Answers1

2

It's always difficult to answer questions of the form "why did the designers of X decide to do it this way" when you aren't one of the designers and don't have access to the minutes of their meetings, but in this case there is a simple answer: they decided to adopt existing APIs that were designed by third parties, and to adopt them "as is" rather than trying to integrate them and remove redundancy.

It doesn't help, of course, that Java interfaces are (or were until recently) cast in stone: once released, they can't be changed or extended in any way without creating an incompatibility.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164