Skip to content
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.

Sign up for GitHub

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

Jump to bottom

JavaException.InnerException should return Throwable.getCause(). #1

Closed
jonpryor opened this issue Apr 7, 2015 · 0 comments
Closed

JavaException.InnerException should return Throwable.getCause(). #1

jonpryor opened this issue Apr 7, 2015 · 0 comments

Comments

@jonpryor
Copy link
Member

jonpryor commented Apr 7, 2015

JavaException.InnerException should return Throwable.getCause().
jonpryor added a commit that referenced this issue Apr 7, 2015
@jonpryor
[Java.Interop] JavaException.InnerException should elide Proxies.
d65a1e5 
Fixes: #1

JavaProxyThrowable is an internal type, and as such it shouldn't
"leak" if at all possible, e.g. if someone creates a
java.lang.Throwable in which the `cause` is a managed exception type
such as InvalidOperationException.

Previously, Exception.InnerException would have been the
JavaProxyThrowable, as JavaException._GetCause() would lookup a
JavaException instance. Returning a JavaProxyThrowable is ~useless;
it's not a public API, and thus nothing useful can be done with it
(short of resorting to Reflection).

Fix JavaException._GetCause() so that it instead uses
JavaVM.GetExceptionForThrowable(), which automatically "unwraps"
JavaProxyThrowable instances to return the wrapped Exception.
@jonpryor jonpryor closed this as completed Apr 7, 2015
jonpryor added a commit that referenced this issue Nov 11, 2015
@jonpryor
[Java.Interop] Fix JNI reference count assertions
e6468d2 
The JNI reference count assertions in
JniRuntime.JniObjectReferenceManager were "off," in that the values
they were asserting didn't actually make sense.

Previous logic for JNI local reference create + destroy:

	// Assume localReferenceCount starts at 0, because of course it does
	Assert (localReferenceCount >= 0);  // True; 0 >= 0
	localReferenceCount++;              // localReferenceCount == 1
	...
	Assert (localReferenceCount >= 0);  // True; 1 >= 0
	localReferenceCount--;              // localReferenceCount == 0

The problem with this logic is that it doesn't actually make sense;
when localReferenceCount is incremented to 1, there is one reference
in existence; conceptually, then, the created reference *is* #1.

Meanwhile, at *cleanup*, we first check that localReferenceCount is
valid, *before* we decrement it. We're not validating that e.g.
reference "#1" has been destroyed, or that the number of outstanding
references *after* cleanup is identical to what existed *before* it
was created.

In short, the "dispose" check is in the wrong place. It should be done
*after* decrementing the count, not before:

	Assert (localReferenceCount >= 0);  // True; 0 >= 0
	localReferenceCount++;              // localReferenceCount == 1
	...
	localReferenceCount--;              // localReferenceCount == 0
	Assert (localReferenceCount >= 0);  // True; 0 >= 0

This dovetails nicely with LoggingJniObjectReferenceManagerDecorator
behavior, in that the logging should follow the same pattern as the
count updating: log after create, before delete. If/when reference
lifetimes are entirely nested and not overlapping, this allows for
lrefc value "1" on create to have the same lrefc value "1" on destroy.
jonpryor added a commit to jonpryor/java.interop that referenced this issue Aug 17, 2016
@jonpryor
[Java.Runtime.Environment] Don't Destroy the JVM by default.
eefaa61 
When `JniRuntime.CreationOptions.DestroyRuntimeOnDispose` is true,
`JavaVM::DestroyJavaVM()` will be invoked when the `JniRuntime`
instance is disposed *or* finalized.

`JreRuntime.CreateJreVM()` would *always* set
`DestroyRuntimeOnDispose` to true, because it called
`JNI_CreateJavaVM()`, so *of course* you'd want to destroy the
Java VM, right?

Which brings us to unit tests. I don't know of any "before all test
fixtures run" and "after all test fixtures run" extension points,
which means:

1. The JVM needs to be created implicitly, "on demand."
2. There's no good way to destroy the JVM created in (1) after all
    tests have finished executing.

Which *really* means that the `JreRuntime` instance is *finalized*,
which sets us up for the unholy trifecta of AppDomain unloads,
finalizers, and JVM shutdown:

For unknown reasons, ~randomly, when running the unit tests (e.g.
`make run-tests`), the test runner will *hang*, indefinitely.

Attaching `lldb` and triggering a backtrace shows the unholy trifecta:

Finalization:

	thread dotnet#4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
	  ...
	  frame dotnet#10: 0x00000001001ccb4a mono64`mono_gc_run_finalize(obj=<unavailable>, data=<unavailable>) + 938 at gc.c:256 [opt]
	  frame dotnet#11: 0x00000001001cdd4a mono64`finalizer_thread [inlined] finalize_domain_objects + 51 at gc.c:681 [opt]
	  frame dotnet#12: 0x00000001001cdd17 mono64`finalizer_thread(unused=<unavailable>) + 295 at gc.c:730 [opt]

JVM destruction:

	thread dotnet#4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
	  frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame dotnet#1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
	  frame dotnet#2: 0x000000010ba5bc76 libjvm.dylib`os::PlatformEvent::park() + 192
	  frame dotnet#3: 0x000000010ba38e32 libjvm.dylib`ParkCommon(ParkEvent*, long) + 42
	  frame dotnet#4: 0x000000010ba39708 libjvm.dylib`Monitor::IWait(Thread*, long) + 168
	  frame dotnet#5: 0x000000010ba398f0 libjvm.dylib`Monitor::wait(bool, long, bool) + 246
	  frame dotnet#6: 0x000000010bb3dca2 libjvm.dylib`Threads::destroy_vm() + 80
	  frame dotnet#7: 0x000000010b8fd665 libjvm.dylib`jni_DestroyJavaVM + 254

AppDomain unload:

	thread dotnet#37: tid = 0x4038fb, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame dotnet#1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
	  frame dotnet#2: 0x0000000100234a7f mono64`mono_os_cond_timedwait [inlined] mono_os_cond_wait(cond=0x0000000102016e50, mutex=0x0000000102016e10) + 11 at mono-os-mutex.h:105 [opt]
	  frame dotnet#3: 0x0000000100234a74 mono64`mono_os_cond_timedwait(cond=0x0000000102016e50, mutex=0x0000000102016e10, timeout_ms=<unavailable>) + 164 at mono-os-mutex.h:120 [opt]
	  frame dotnet#4: 0x0000000100234828 mono64`_wapi_handle_timedwait_signal_handle(handle=0x0000000000000440, timeout=4294967295, alertable=1, poll=<unavailable>, alerted=0x0000700000a286f4) + 536 at handles.c:1554 [opt]
	  frame dotnet#5: 0x0000000100246370 mono64`wapi_WaitForSingleObjectEx(handle=<unavailable>, timeout=<unavailable>, alertable=<unavailable>) + 592 at wait.c:189 [opt]
	  frame dotnet#6: 0x00000001001c832e mono64`mono_domain_try_unload [inlined] guarded_wait(timeout=4294967295, alertable=1) + 30 at appdomain.c:2390 [opt]
	  frame dotnet#7: 0x00000001001c8310 mono64`mono_domain_try_unload(domain=0x000000010127ccb0, exc=0x0000700000a287a0) + 416 at appdomain.c:2482 [opt]
	  frame dotnet#8: 0x00000001001c7db2 mono64`ves_icall_System_AppDomain_InternalUnload [inlined] mono_domain_unload(domain=<unavailable>) + 20 at appdomain.c:2379 [opt]
	  frame dotnet#9: 0x00000001001c7d9e mono64`ves_icall_System_AppDomain_InternalUnload(domain_id=<unavailable>) + 46 at appdomain.c:2039 [opt]

This randomly results in deadlock, and hung Jenkins bots.

Fix this behavior by altering `JreRuntime.CreateJreVM()` to *not*
override the value of
`JniRuntime.CreationOptions.DestroyRuntimeOnDispose`. This allows the
constructor of the `JreRuntime` instance to decide whether or not the
JVM is destroyed.

In the case of TestJVM, we *don't* want to destroy the JVM.

This prevents the JVM from being destroyed, which in turn prevents the
hang during process shutdown.
jonpryor added a commit that referenced this issue Aug 17, 2016
@jonpryor
[Java.Runtime.Environment] Don't Destroy the JVM by default. (#65)
bee46ef 
When `JniRuntime.CreationOptions.DestroyRuntimeOnDispose` is true,
`JavaVM::DestroyJavaVM()` will be invoked when the `JniRuntime`
instance is disposed *or* finalized.

`JreRuntime.CreateJreVM()` would *always* set
`DestroyRuntimeOnDispose` to true, because it called
`JNI_CreateJavaVM()`, so *of course* you'd want to destroy the
Java VM, right?

Which brings us to unit tests. I don't know of any "before all test
fixtures run" and "after all test fixtures run" extension points,
which means:

1. The JVM needs to be created implicitly, "on demand."
2. There's no good way to destroy the JVM created in (1) after all
    tests have finished executing.

Which *really* means that the `JreRuntime` instance is *finalized*,
which sets us up for the unholy trifecta of AppDomain unloads,
finalizers, and JVM shutdown:

For unknown reasons, ~randomly, when running the unit tests (e.g.
`make run-tests`), the test runner will *hang*, indefinitely.

Attaching `lldb` and triggering a backtrace shows the unholy trifecta:

Finalization:

	thread #4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
	  ...
	  frame #10: 0x00000001001ccb4a mono64`mono_gc_run_finalize(obj=<unavailable>, data=<unavailable>) + 938 at gc.c:256 [opt]
	  frame #11: 0x00000001001cdd4a mono64`finalizer_thread [inlined] finalize_domain_objects + 51 at gc.c:681 [opt]
	  frame #12: 0x00000001001cdd17 mono64`finalizer_thread(unused=<unavailable>) + 295 at gc.c:730 [opt]

JVM destruction:

	thread #4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
	  frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame #1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
	  frame #2: 0x000000010ba5bc76 libjvm.dylib`os::PlatformEvent::park() + 192
	  frame #3: 0x000000010ba38e32 libjvm.dylib`ParkCommon(ParkEvent*, long) + 42
	  frame #4: 0x000000010ba39708 libjvm.dylib`Monitor::IWait(Thread*, long) + 168
	  frame #5: 0x000000010ba398f0 libjvm.dylib`Monitor::wait(bool, long, bool) + 246
	  frame #6: 0x000000010bb3dca2 libjvm.dylib`Threads::destroy_vm() + 80
	  frame #7: 0x000000010b8fd665 libjvm.dylib`jni_DestroyJavaVM + 254

AppDomain unload:

	thread #37: tid = 0x4038fb, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame #1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
	  frame #2: 0x0000000100234a7f mono64`mono_os_cond_timedwait [inlined] mono_os_cond_wait(cond=0x0000000102016e50, mutex=0x0000000102016e10) + 11 at mono-os-mutex.h:105 [opt]
	  frame #3: 0x0000000100234a74 mono64`mono_os_cond_timedwait(cond=0x0000000102016e50, mutex=0x0000000102016e10, timeout_ms=<unavailable>) + 164 at mono-os-mutex.h:120 [opt]
	  frame #4: 0x0000000100234828 mono64`_wapi_handle_timedwait_signal_handle(handle=0x0000000000000440, timeout=4294967295, alertable=1, poll=<unavailable>, alerted=0x0000700000a286f4) + 536 at handles.c:1554 [opt]
	  frame #5: 0x0000000100246370 mono64`wapi_WaitForSingleObjectEx(handle=<unavailable>, timeout=<unavailable>, alertable=<unavailable>) + 592 at wait.c:189 [opt]
	  frame #6: 0x00000001001c832e mono64`mono_domain_try_unload [inlined] guarded_wait(timeout=4294967295, alertable=1) + 30 at appdomain.c:2390 [opt]
	  frame #7: 0x00000001001c8310 mono64`mono_domain_try_unload(domain=0x000000010127ccb0, exc=0x0000700000a287a0) + 416 at appdomain.c:2482 [opt]
	  frame #8: 0x00000001001c7db2 mono64`ves_icall_System_AppDomain_InternalUnload [inlined] mono_domain_unload(domain=<unavailable>) + 20 at appdomain.c:2379 [opt]
	  frame #9: 0x00000001001c7d9e mono64`ves_icall_System_AppDomain_InternalUnload(domain_id=<unavailable>) + 46 at appdomain.c:2039 [opt]

This randomly results in deadlock, and hung Jenkins bots.

Fix this behavior by altering `JreRuntime.CreateJreVM()` to *not*
override the value of
`JniRuntime.CreationOptions.DestroyRuntimeOnDispose`. This allows the
constructor of the `JreRuntime` instance to decide whether or not the
JVM is destroyed.

In the case of TestJVM, we *don't* want to destroy the JVM.

This prevents the JVM from being destroyed, which in turn prevents the
hang during process shutdown.
@jonpryor jonpryor mentioned this issue May 19, 2020
Closed
jonpryor added a commit to jonpryor/java.interop that referenced this issue Oct 19, 2020
@jonpryor
Bump to mono/LineEditor@06a4ddfd
e9e622d 
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070

Changes: mono/LineEditor@5a7e3e2...3fa0c2e

  * mono/LineEditor@3fa0c2e: Fix NuGet publishing errors (dotnet#9)
  * mono/LineEditor@06a4ddf: Bump `$(PackageVersion)` to 5.4.1.
  * mono/LineEditor@bce1b7f: Enable .pdb files for Release config & add AzDO build script (dotnet#8)
  * mono/LineEditor@4831e1a: Merge pull request dotnet#6 from terrajobst/code-of-conduct
  * mono/LineEditor@5b4a4aa: Link Code of Conduct
  * mono/LineEditor@410ca3d: Merge pull request dotnet#2 from VEIT-Electronics/master
  * mono/LineEditor@3d802e7: Merge pull request dotnet#1 from VEIT-Electronics/bugfix/ENG-232-line-editor-completions
  * mono/LineEditor@0d43552: fix: text overriding was only platform specific (check platform)

The most important piece is mono/LineEditor@bce1b7f, which will allow
us to redistribute `LineEditor.pdb` in the Xamarin.Android installers.
@jonpryor jonpryor mentioned this issue Oct 19, 2020
Merged
jonpryor added a commit to jonpryor/java.interop that referenced this issue Oct 19, 2020
@jonpryor
Bump to mono/LineEditor@3fa0c2eb
fd36d04 
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070

Changes: mono/LineEditor@5a7e3e2...3fa0c2e

  * mono/LineEditor@3fa0c2e: Fix NuGet publishing errors (dotnet#9)
  * mono/LineEditor@06a4ddf: Bump `$(PackageVersion)` to 5.4.1.
  * mono/LineEditor@bce1b7f: Enable .pdb files for Release config & add AzDO build script (dotnet#8)
  * mono/LineEditor@4831e1a: Merge pull request dotnet#6 from terrajobst/code-of-conduct
  * mono/LineEditor@5b4a4aa: Link Code of Conduct
  * mono/LineEditor@410ca3d: Merge pull request dotnet#2 from VEIT-Electronics/master
  * mono/LineEditor@3d802e7: Merge pull request dotnet#1 from VEIT-Electronics/bugfix/ENG-232-line-editor-completions
  * mono/LineEditor@0d43552: fix: text overriding was only platform specific (check platform)

The most important piece is mono/LineEditor@bce1b7f, which will allow
us to redistribute `LineEditor.pdb` in the Xamarin.Android installers.
jonpryor added a commit to jonpryor/java.interop that referenced this issue Oct 20, 2020
@jonpryor
Bump to mono/LineEditor@3fa0c2eb
60e34b3 
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070

Changes: mono/LineEditor@5a7e3e2...3fa0c2e

  * mono/LineEditor@3fa0c2e: Fix NuGet publishing errors (dotnet#9)
  * mono/LineEditor@06a4ddf: Bump `$(PackageVersion)` to 5.4.1.
  * mono/LineEditor@bce1b7f: Enable .pdb files for Release config & add AzDO build script (dotnet#8)
  * mono/LineEditor@4831e1a: Merge pull request dotnet#6 from terrajobst/code-of-conduct
  * mono/LineEditor@5b4a4aa: Link Code of Conduct
  * mono/LineEditor@410ca3d: Merge pull request dotnet#2 from VEIT-Electronics/master
  * mono/LineEditor@3d802e7: Merge pull request dotnet#1 from VEIT-Electronics/bugfix/ENG-232-line-editor-completions
  * mono/LineEditor@0d43552: fix: text overriding was only platform specific (check platform)

The most important piece is mono/LineEditor@bce1b7f, which will allow
us to redistribute `LineEditor.pdb` in the Xamarin.Android installers.

Use `LineEditor.pdb` by adding a post-`Build` target to
`logcat-parse/Directory.Build.targets` which copies `LineEditor.pdb`
into `$(OutputPath)`.  This will allow the Xamarin.Android installer
to include `LineEditor.pdb` into the installer packages.
jonpryor added a commit to jonpryor/java.interop that referenced this issue Oct 20, 2020
@jonpryor
Bump to mono/LineEditor@3fa0c2eb
21d905f 
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070

Changes: mono/LineEditor@5a7e3e2...3fa0c2e

  * mono/LineEditor@3fa0c2e: Fix NuGet publishing errors (dotnet#9)
  * mono/LineEditor@06a4ddf: Bump `$(PackageVersion)` to 5.4.1.
  * mono/LineEditor@bce1b7f: Enable .pdb files for Release config & add AzDO build script (dotnet#8)
  * mono/LineEditor@4831e1a: Merge pull request dotnet#6 from terrajobst/code-of-conduct
  * mono/LineEditor@5b4a4aa: Link Code of Conduct
  * mono/LineEditor@410ca3d: Merge pull request dotnet#2 from VEIT-Electronics/master
  * mono/LineEditor@3d802e7: Merge pull request dotnet#1 from VEIT-Electronics/bugfix/ENG-232-line-editor-completions
  * mono/LineEditor@0d43552: fix: text overriding was only platform specific (check platform)

The most important piece is mono/LineEditor@bce1b7f, which will allow
us to redistribute `LineEditor.pdb` in the Xamarin.Android installers.

Add a post-`Build` target to `logcat-parse/Directory.Build.targets`
which copies `LineEditor.pdb` into `$(OutputPath)`.  This will allow
the Xamarin.Android installer to include `LineEditor.pdb` into the
installer packages.
jonpryor added a commit that referenced this issue Oct 20, 2020
@jonpryor
Bump to mono/LineEditor@3fa0c2eb (#740)
da74abd 
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070

Changes: mono/LineEditor@5a7e3e2...3fa0c2e

  * mono/LineEditor@3fa0c2e: Fix NuGet publishing errors (#9)
  * mono/LineEditor@06a4ddf: Bump `$(PackageVersion)` to 5.4.1.
  * mono/LineEditor@bce1b7f: Enable .pdb files for Release config & add AzDO build script (#8)
  * mono/LineEditor@4831e1a: Merge pull request #6 from terrajobst/code-of-conduct
  * mono/LineEditor@5b4a4aa: Link Code of Conduct
  * mono/LineEditor@410ca3d: Merge pull request #2 from VEIT-Electronics/master
  * mono/LineEditor@3d802e7: Merge pull request #1 from VEIT-Electronics/bugfix/ENG-232-line-editor-completions
  * mono/LineEditor@0d43552: fix: text overriding was only platform specific (check platform)

The most important piece is mono/LineEditor@bce1b7f, which will allow
us to redistribute `LineEditor.pdb` in the Xamarin.Android installers.

Add a post-`Build` target to `logcat-parse/Directory.Build.targets`
which copies `LineEditor.pdb` into `$(OutputPath)`.  This will allow
the Xamarin.Android installer to include `LineEditor.pdb` into the
installer packages.
jonpryor added a commit to jonpryor/java.interop that referenced this issue Dec 10, 2020
@jonpryor
[java-source-utils] Better support orphaned Javadocs
55bb626 
Context: dotnet#687 (comment)

What happens when there's a "regular" Java comment in between a
Javadoc comment and a member?

	/* partial */ class Object {
	    /** Create and return a copy of this object… */
	    // BEGIN Android-changed: Use native local helper for clone()
	    // …
	    protected Object clone() throws CloneNotSupportedException {…}
	}

What happens is that the Javadoc becomes *orphaned*.

Commit 69e1b80 attempted to handle such orphaned Javadocs via
heuristic, using the first orphaned Javadoc comment in the parent
scope.  This didn't work reliably, as the parent scope could contain
multiple "*unrelated*" orphaned Javadoc comments:

	class Outer {
	    /** Orphaned dotnet#1 */
	    // cause orphaning
	    class Inner {}

	    void m() {}
	}

Because containing types are fully processed before contained types,
`Outer.m()` would grab the Javadoc for `Outer.Inner` before
`Outer.Inner` would have a chance to grab it.

Re-work the logic to associate orphaned Javadocs with their members,
by requiring that the Javadoc comment begin *before* the member of
interest, and *after* any preceding members.  This should prevent
incorrect correlation of orphaned Javadoc comment blocks.

Additionally, update gradle to use javaparser 3.18.0, from 3.16.1.
jonpryor added a commit to jonpryor/java.interop that referenced this issue Dec 10, 2020
@jonpryor
[java-source-utils] Better support orphaned Javadocs
3ac772f 
Context: dotnet#687 (comment)

What happens when there's a "regular" Java comment in between a
Javadoc comment and a member?

	/* partial */ class Object {
	    /** Create and return a copy of this object… */
	    // BEGIN Android-changed: Use native local helper for clone()
	    // …
	    protected Object clone() throws CloneNotSupportedException {…}
	}

What happens is that the Javadoc becomes *orphaned*.

Commit 69e1b80 attempted to handle such orphaned Javadocs via
heuristic, using the first orphaned Javadoc comment in the parent
scope.  This didn't work reliably, as the parent scope could contain
multiple "*unrelated*" orphaned Javadoc comments:

	class Outer {
	    /** Orphaned dotnet#1 */
	    // cause orphaning
	    class Inner {}

	    void m() {}
	}

Because containing types are fully processed before contained types,
`Outer.m()` would grab the Javadoc for `Outer.Inner` before
`Outer.Inner` would have a chance to grab it.

Re-work the logic to associate orphaned Javadocs with their members,
by requiring that the Javadoc comment begin *before* the member of
interest, and *after* any preceding members.  This should prevent
incorrect correlation of orphaned Javadoc comment blocks.

Additionally, update gradle to use javaparser 3.18.0, from 3.16.1:

  * javaparser/javaparser@javaparser-parent-3.16.1...javaparser-parent-3.18.0
jonpryor added a commit that referenced this issue Dec 10, 2020
@jonpryor
[java-source-utils] Better support orphaned Javadocs (#757)
c1bc5c8 
Context: #687 (comment)

What happens when there's a "regular" Java comment in between a
Javadoc comment and a member?

	/* partial */ class Object {
	    /** Create and return a copy of this object… */
	    // BEGIN Android-changed: Use native local helper for clone()
	    // …
	    protected Object clone() throws CloneNotSupportedException {…}
	}

What happens is that the Javadoc becomes *orphaned*.

Commit 69e1b80 attempted to handle such orphaned Javadocs via
heuristic, using the first orphaned Javadoc comment in the parent
scope.  This didn't work reliably, as the parent scope could contain
multiple "*unrelated*" orphaned Javadoc comments:

	class Outer {
	    /** Orphaned #1 */
	    // cause orphaning
	    class Inner {}

	    void m() {}
	}

Because containing types are fully processed before contained types,
`Outer.m()` would grab the Javadoc for `Outer.Inner` before
`Outer.Inner` would have a chance to grab it.

Re-work the logic to associate orphaned Javadocs with their members,
by requiring that the Javadoc comment begin *before* the member of
interest, and *after* any preceding members.  This should prevent
incorrect correlation of orphaned Javadoc comment blocks.

Additionally, update gradle to use javaparser 3.18.0, from 3.16.1:

  * javaparser/javaparser@javaparser-parent-3.16.1...javaparser-parent-3.18.0
pjcollins pushed a commit to pjcollins/java.interop that referenced this issue Dec 17, 2020
@jonpryor @pjcollins
Bump to mono/LineEditor@3fa0c2eb (dotnet#740)
e78aef2 
Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070

Changes: mono/LineEditor@5a7e3e2...3fa0c2e

  * mono/LineEditor@3fa0c2e: Fix NuGet publishing errors (dotnet#9)
  * mono/LineEditor@06a4ddf: Bump `$(PackageVersion)` to 5.4.1.
  * mono/LineEditor@bce1b7f: Enable .pdb files for Release config & add AzDO build script (dotnet#8)
  * mono/LineEditor@4831e1a: Merge pull request dotnet#6 from terrajobst/code-of-conduct
  * mono/LineEditor@5b4a4aa: Link Code of Conduct
  * mono/LineEditor@410ca3d: Merge pull request dotnet#2 from VEIT-Electronics/master
  * mono/LineEditor@3d802e7: Merge pull request dotnet#1 from VEIT-Electronics/bugfix/ENG-232-line-editor-completions
  * mono/LineEditor@0d43552: fix: text overriding was only platform specific (check platform)

The most important piece is mono/LineEditor@bce1b7f, which will allow
us to redistribute `LineEditor.pdb` in the Xamarin.Android installers.

Add a post-`Build` target to `logcat-parse/Directory.Build.targets`
which copies `LineEditor.pdb` into `$(OutputPath)`.  This will allow
the Xamarin.Android installer to include `LineEditor.pdb` into the
installer packages.
@pjcollins pjcollins mentioned this issue Dec 17, 2020
Closed
@github-actions github-actions bot locked and limited conversation to collaborators Apr 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jonpryor