-
Notifications
You must be signed in to change notification settings - Fork 544
Generator do not expose nonpublic #260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generator do not expose nonpublic #260
Conversation
…adjuster. api-24.xml.in was already generated with the almost latest tools, but it has some new members probably due to android.jar updates. Others were generated by old tools so they had extraneous generic constraints.
…ster. There were non-breaking API definition files changes caused by dotnet/java-interop#94 This update reflects the changes.
7ccc864
to
5847c2d
Compare
Aside: it would be nice if GitHub would actually show the changes. Fortunately, there's the Many of the changes are due to: - <typeParameter name="V">
- <genericConstraints>
- <genericConstraint type="java.lang.Object">
- </genericConstraint>
- </genericConstraints>
- </typeParameter>
+ <typeParameter name="V"></typeParameter> which seems odd, but should be meaningless. |
Should this include a corresponding Java.Interop bump? It wouldn't be strictly required, since we're not using |
The genericConstraints changes were from older ApiXmlAdjuster fix (they were different from jar2xml outputs which never generated those extraneous elements), not by that Java.Interop changeset. |
While reviewing [DoNotThrowInUnexpectedLocationRule][throw] regarding `JniArrayElements.Elements` we discussed the issue and came up with a slight semantic API overhaul. [throw]: https://github.com/spouliot/gendarme/wiki/Gendarme.Rules.Exceptions.DoNotThrowInUnexpectedLocationRule(2.10) Previously, we had: public abstract partial class JniArrayElements : IDisposable { public IntPtr Elements {get;} public void CopyToJava(); public void Dispose(); public void Release(JniReleaseArrayElementsMode releaseMode); } public sealed class JniInt32ArrayElements : JniArrayElements { public new unsafe int* Elements {get;} } The *idea* of `JniArrayElements` was that it refers to a contiguous blob of memory, starting at address `JniArrayElements.Elements`. The thinking was that `JniArrayElements` would allow reading or otherwise manipulating the memory regions without needing to know the underlying element type. On further discussion, this abstraction was missing something important: the *size* of the region of memory that `JniArrayElements.Elements` refers to. Additionally, with the advent of [C# 7 ref returns][rr], we thought that providing a ref-return indexer would be preferable to using a shadowing/re-declared `Elements` property. [rr]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/ref-returns We also considered using `Span<T>/Memory<T>`; it is not available in mono at this time. It should be possible to add support for them when they are supported. With these changes, the updated public API is: public abstract partial class JniArrayElements : IDisposable { public IntPtr Elements {get;} public int Size {get;} public void CopyToJava(); public void Dispose(); public void Release(JniReleaseArrayElementsMode releaseMode); } public sealed class JniInt32ArrayElements : JniArrayElements { public ref int this [int index] {get;} }
No description provided.