From: http://jira.codehaus.org/browse/JRUBY-6453

In looking at a few native extensions it is clear that we need better facilities for working with Strings and ByteLists (same can maybe be said for IO, but that is a much bigger problem and should be it's own issue).

So far I am not suggesting specific APIs (example below is just illustrative) but we should examine a few common Java native extensions (nokogiri, json, ???) and see how we need to manipulate bytelists and rubystrings and provide something less exposing of internals and brittle.

The one other requirement is that we can make something which works for both 1.8 and 1.9 (and 2.0). If we create two methods where only one requires an encoding we should make it obvious what the difference is:

container.createASCIIString(byte[]);
container.createString(byte[], encoding);

If we had these two forms both just be createString then new developers would probably just use the one without encoding. By providing ASCII in the name it is obvious what decision they are making by calling it.

One last thing. It is clear that we will need to expose access several types of things: Encoding, ByteList, Fixnum? We can cope with this in two ways:

1. Use Ruby . Ruby exposes way too many things we don't want to encourage.
2. Add something to ScriptingContainer for getting/creating (probably some contained class: container.getTypeHelper). This has downside of slowly growing to be a huge mess like Ruby I do favor Project suggestions #2 because it will make it very obvious what we intend on supporting. We can also slowly grow it based on user-feedback (hell they can also work-around lack of missing endorsed way by using break script engine #1 until there is something).