wasn't able to find a test/spec or a reason why RaiseException did (for NativeException) :

-    private static String buildMessage(Throwable exception) {
-        StringBuilder sb = new StringBuilder();
-        StringWriter stackTrace = new StringWriter();
-        exception.printStackTrace(new PrintWriter(stackTrace));
-
-        sb.append("Native Exception: '").append(exception.getClass()).append("'; ");
-        sb.append("Message: ").append(exception.getMessage()).append("; ");
-        sb.append("StackTrace: ").append(stackTrace.getBuffer());
-
-        return sb.toString();
-    }

9.1 sounds like a good place to break away from that message building - which would actually only be seen very rarely (effectively almost never without hacks) even without the patch as RaiseException does re-set the providedMessage field in case of the NativeException constructor path.

another annoyance with NativeException is the cause.stackTrace + backtrace join-ing - which shouldn't be necessary at all ... for now I've kept it for cases where the trace heads do not point to the same location. that means 99% cases it won't show up. except when the head would be filtered away as a JRuby internal. there seem to have been some special NativeException filtering in place previously but with filtering going on elsewhere I did not want to filter twice esp as it seemed unnecessary.

tests on Java as well as Ruby side to cover functionality.

p.s. RubyException got a getMessageAsJavaString (would love to have been able to just change getMessage to return String :) which is used by RaiseException - this way at least for NativeException the String -> RubyString -> String message conversion can be avoided 🎉