Stop unifying InputStream & OutputStream as System.IO.Stream

[jonpryor]

Context: dotnet/android#3646

One of the long-ago design choices we made in binding Java code was we bound java.io.InputStream and java.io.OutputStream as System.IO.Stream, because we thought this would make it easier for new Java code to be used with existing .NET code.

Unfortunately, in the process we forgot about exception handling semantics: Android.Runtime.InputStreamInvoker wraps a Java.IO.InputStream, but does no "exception mapping". Thus, calling System.IO.Stream.Read() may cause a Java.IO.IOException to be thrown, which is not an exception type documented as throwable by Stream.Read().

We can't (easily) fix our existing bindings.

We can prevent new bindings from following this madness.

Update generator so that the e.g. "bind java.io.InputStream as System.IO.Stream" behavior can be controlled via Metadata.xml, and change the default behavior so that java.io.InputStream is bound as Java.IO.InputStream, not System.IO.Stream. (The metadata support is so that existing bindings can enable the previous behavior and maintain API compatibility.)

This way, we won't make the problem worse.

We should also re-evaluate type bindings and stop similar mappings, e.g. XmlPullParserSymbol and XmlResourceParserSymbol.

[jpobst]

I strongly disagree with this. These automatic type conversions are fundamental to our value proposition of allowing easy code interop with .NET code. (Like StreamReader, ZipStream, File.WriteAllText, etc.) The same goes for other conversions we do like List<string>.

I suspect not converting the Exceptions is an explicit decision we made at the time, largely because you can't have it both ways. If you look at the MS System.IO.Stream docs it says it will throw a System.IO.IOException, but if you at the Android BluetoothSocket docs it will say it throws a Java.IO.IOException. We chose to follow the Android docs because we assumed that's the docs developers would reference. (Also it was easier than ensuring we converted 100% of Exception cases, or worse, being inconsistent.)

The only way to have it both ways and for everything to "just work" is to have Java.IO.IOException inherit from System.IO.IOException.

[jpobst]

We have chosen instead to convert Java.IO.IOException's to System.IO.IOException's in our wrapper:

dotnet/android#3841

[tuyen-vuduc]

Unifying InputStream and OutputStream to managed Stream will cause overloaded methods/ctors failed to be bound to .NET :( . Any recommendations?