[api-xml-adjuster] further fix on generic nested type name parsing. #115
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We have fixed nested generic type name crashes[*1] at 769f944, but that was only to fix the crash. The resulting type name was not parsed correctly - namely, the resulting type name dropped the remainings after the first generic arguments list i.e. in `A<b>.C<d>`, `.C<d>` part had dropped. The cause of the problem is somewhat deep, as JavaTypeName and JavaTypeReference do not consider the possibility that both the nested generic parent and child have generic arguments. Anyhow in JavaTypeName now we store the expected information, by having (hacky) `GenericParent` property to store the expected information. Now it comes with a test so that it should prove the purpose of the change. [*1] https://bugzilla.xamarin.com/show_bug.cgi?id=46344
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this pull request
Apr 19, 2021
Context: https://developercommunity.visualstudio.com/t/illegal-character-exception-in-xamarinandroid-afte/1363149 Changes: dotnet/android-tools@554d45a...d92fc3e * dotnet/android-tools@d92fc3e: [Xamarin.Android.Tools.AndroidSdk] Probe for AdoptOpenJDK Locations (dotnet#115) * dotnet/android-tools@dca30d9: [Xamarin.Android.Tools.AndroidSdk] Probe for Zulu JDK (dotnet#114) * dotnet/android-tools@237642c: [Xamarin.Android.Tools.AndroidSdk] Probe for Microsoft OpenJDK dirs (dotnet#113) * dotnet/android-tools@e618e00: [Xamarin.Android.Tools.AndroidSdk] Fix quotes in %PATH% or %PATHEXT% (dotnet#112)
jonpryor
added a commit
that referenced
this pull request
Apr 20, 2021
Context: https://developercommunity.visualstudio.com/t/illegal-character-exception-in-xamarinandroid-afte/1363149 Changes: dotnet/android-tools@554d45a...d92fc3e * dotnet/android-tools@d92fc3e: [Xamarin.Android.Tools.AndroidSdk] Probe for AdoptOpenJDK Locations (#115) * dotnet/android-tools@dca30d9: [Xamarin.Android.Tools.AndroidSdk] Probe for Zulu JDK (#114) * dotnet/android-tools@237642c: [Xamarin.Android.Tools.AndroidSdk] Probe for Microsoft OpenJDK dirs (#113) * dotnet/android-tools@e618e00: [Xamarin.Android.Tools.AndroidSdk] Fix quotes in %PATH% or %PATHEXT% (#112) Finally, *prefer* JDK 8, as hilarious as that is, for two reasons: 1. `gradlew` fails to execute when running under OpenJDK 14: [ERROR] [system.err] java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7 2. The unit tests added in 69e1b80 currently depend upon the XML formatting conventions of JDK 8, and the tests fail when running under JDK 11 because of whitespace changes in `javax.xml` output. For now, it's currently easier to just require JDK 8. The preferred JDK version is controlled by the new `$(MaxJdkVersion)` YAML variable, which in turn sets `$(JI_MAX_JDK)` (55c56f7) and/or the `$(MaxJdkVersion)` MSBuild property, which `dotnet build -t:Prepare` uses to generate `bin/Build*/JdkInfo.props`. Finally, *for consistency*, update `TestJVM` to look for the generated `JdkInfo.props`. If found, use the `$(JdkJvmPath)` value at `/Project/Chooose/When/PropertyGroup/JdkJvmPath` instead of using `JdkInfo.GetKnownSystemJdkInfos()`, so that the JVM that we built against is also used for unit test execution.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have fixed nested generic type name crashes[*1] at 769f944, but
that was only to fix the crash. The resulting type name was not parsed
correctly - namely, the resulting type name dropped the remainings after
the first generic arguments list i.e. in
A<b>.C<d>,.C<d>part haddropped.
The cause of the problem is somewhat deep, as JavaTypeName and
JavaTypeReference do not consider the possibility that both the nested
generic parent and child have generic arguments.
Anyhow in JavaTypeName now we store the expected information, by
having (hacky)
GenericParentproperty to store the expected information.Now it comes with a test so that it should prove the purpose of the change.
[*1] https://bugzilla.xamarin.com/show_bug.cgi?id=46344