Skip to content

Java parser: call #encode dynamically when converting the source - #1124

Open
sampokuokkanen wants to merge 1 commit into
ruby:masterfrom
sampokuokkanen:java-parser-dynamic-encode
Open

sampokuokkanen wants to merge 1 commit into
ruby:masterfrom
sampokuokkanen:java-parser-dynamic-encode

Conversation

@sampokuokkanen

Copy link
Copy Markdown
Contributor

On JRuby, convertEncoding called RubyString#encode directly from Java, so a String subclass overriding #encode was ignored. parser.c uses rb_funcall and StringValue. This does the same with callMethod and convertToString, so a non-String return value now raises TypeError rather than a ClassCastException.

UTF-8 and binary sources don't go through this path. The part of test_adversary_encode that was skipped on JRuby now runs there: it fails without this change, and the full suite passes on JRuby 10.1.2.

I benchmarked small and medium US-ASCII and UTF-16LE documents against the old jar and couldn't see a difference beyond noise.

convertEncoding called RubyString#encode directly from Java, so a String
subclass overriding #encode was ignored on JRuby. parser.c uses
rb_funcall followed by StringValue, so do the same: dispatch through
callMethod and convert the result with convertToString, which also turns
a non-String return value into a TypeError instead of a
ClassCastException.

This lets the JRuby-guarded part of test_adversary_encode run everywhere.
@sampokuokkanen

Copy link
Copy Markdown
Contributor Author

@headius
#1122 (review)
This enables us to remove the exclusion you mentioned here.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant